From owner-mpls@UU.NET Wed May 1 07:51:18 2002 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 HAA22756 for ; Wed, 1 May 2002 07:51:17 -0400 (EDT) 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 QQmmyp12370; Wed, 1 May 2002 11:50:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmyp09708 for mpls-outgoing; Wed, 1 May 2002 11:49: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 QQmmyp09701 for ; Wed, 1 May 2002 11:49:49 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 QQmmyp21405 for ; Wed, 1 May 2002 11:49:41 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 QQmmyp04541 for ; Wed, 1 May 2002 11:49:41 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 g41BneT18502; Wed, 1 May 2002 04:49:40 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id g41BneG33790; Wed, 1 May 2002 04:49:40 -0700 (PDT) (envelope-from kireeti) Date: Wed, 1 May 2002 04:49:40 -0700 (PDT) From: Kireeti Kompella Message-Id: <200205011149.g41BneG33790@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: Signaling documents ... Cc: mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk FYI: CCAMP & MPLS WG Last Call has completed on the Generalized Signaling documents, i.e.: draft-ietf-mpls-generalized-cr-ldp-06.txt draft-ietf-mpls-generalized-rsvp-te-07.txt draft-ietf-mpls-generalized-signaling-08.txt and they have been handed over to the ADs for IESG consideration as Proposed Standards. Kireeti. From owner-mpls@UU.NET Wed May 1 11:32:45 2002 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 LAA03393 for ; Wed, 1 May 2002 11:32:45 -0400 (EDT) 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 QQmmze12214; Wed, 1 May 2002 15:31:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmze24838 for mpls-outgoing; Wed, 1 May 2002 15:31: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 QQmmze24833 for ; Wed, 1 May 2002 15:31:06 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 QQmmze24075 for ; Wed, 1 May 2002 15:30:17 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmmze29105 for ; Wed, 1 May 2002 15:30:16 GMT 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 LAA04959 for ; Wed, 1 May 2002 11:30:16 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA16082 for mpls@uu.net; Wed, 1 May 2002 11:30:16 -0400 (EDT) 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 QQmmvz10562 for ; Tue, 30 Apr 2002 18:57: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 QQmmvz25089 for ; Tue, 30 Apr 2002 18:57:04 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f16.sea1.hotmail.com [207.68.163.16]) id QQmmvz13484 for ; Tue, 30 Apr 2002 18:57:03 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 30 Apr 2002 11:57:03 -0700 Received: from 65.223.109.2 by sea1fd.sea1.hotmail.msn.com with HTTP; Tue, 30 Apr 2002 18:57:03 GMT X-Originating-IP: [65.223.109.2] From: "No name" To: mpls@UU.NET Subject: RFC3209 Date: Tue, 30 Apr 2002 11:57:03 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Apr 2002 18:57:03.0238 (UTC) FILETIME=[D0C4BA60:01C1F078] Sender: owner-mpls@UU.NET Precedence: bulk Hi This questions is about the handling of "RRO too large for MTU" cases. "If the newly added subobject causes the RRO to be too big to fit in a Path (or Resv) message, the RRO object SHALL be dropped from the message and message processing continues as normal. A PathErr (or ResvErr) message SHOULD be sent back to the sender (or receiver). An error code of "Notify" and an error value of "RRO too large for MTU" is used. If the receiver receives such a ResvErr, it SHOULD send a PathErr message with error code of "Notify" and an error value of "RRO notification". " IF adding the EGRESS's IPv4 subobject to the RRO makes the RRO too large for MTU, will it send a RESVERR or PATHERR, my guess is it should send a Patherror upstream. I apologize if this has been answered before, but i put this question up since i couldnt find any specific discussion that answers my question. regards Manish _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-mpls@UU.NET Wed May 1 13:15:07 2002 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 NAA09264 for ; Wed, 1 May 2002 13:15:07 -0400 (EDT) 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 QQmmzk12487; Wed, 1 May 2002 17:13:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmzk16549 for mpls-outgoing; Wed, 1 May 2002 17:13:29 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 QQmmzk16544 for ; Wed, 1 May 2002 17:13: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 QQmmzk24942 for ; Wed, 1 May 2002 17:12:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmmzk14282 for ; Wed, 1 May 2002 17:12:02 GMT 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 NAA11088 for ; Wed, 1 May 2002 13:12:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA26685 for mpls@uu.net; Wed, 1 May 2002 13:12:02 -0400 (EDT) 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 QQmmzk15727 for ; Wed, 1 May 2002 17:10:31 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 QQmmzk21007 for ; Wed, 1 May 2002 17:10:24 GMT Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmmzk03519 for ; Wed, 1 May 2002 17:10:19 GMT Received: (qmail 22895 invoked by uid 104); 1 May 2002 17:10:18 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4199. . Clean. Processed in 1.690571 secs); 01 May 2002 17:10:18 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 1 May 2002 17:10:15 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g41HA8p26227; Wed, 1 May 2002 10:10:08 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Wed, 1 May 2002 10:10:11 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A76E@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'No name'" , mpls@UU.NET Subject: RE: RFC3209 Date: Wed, 1 May 2002 10:10:05 -0700 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, A related question: Is the RESV RRO appended to the Path RRO or the PATH RRO is stripped off in the RESV message? My reading of RFC3209 is that the PATH RRO is stripped off, before sending RESV message. If this is the case then the Egress never adds its address to the PATH RRO. It only adds its address to the RESV RRO, and therefore the Notify message should be sent to the EGRESS. However, any such Notify sent to Egress will be converted to Path Error message which will then be sent to the ingress. So practically it should not make any difference to generate the PathError at the egress or to sent Notify to the egress which then converts it to PathErorr. -Shahram > -----Original Message----- > From: No name [mailto:nonamelinux@hotmail.com] > Sent: Tuesday, April 30, 2002 2:57 PM > To: mpls@UU.NET > Subject: RFC3209 > > > Hi > > This questions is about the handling of "RRO too large for MTU" cases. > > "If the newly added subobject causes the RRO to be too big to fit in a > Path (or Resv) message, the RRO object SHALL be dropped from > the message > and message processing continues as normal. A PathErr (or ResvErr) > message SHOULD be sent back to the sender (or receiver). An > error code of "Notify" and an error value of "RRO too large for MTU" > is used. If the receiver receives such a ResvErr, it SHOULD send a > PathErr message with error code of "Notify" and an error value of > "RRO notification". " > > > IF adding the EGRESS's IPv4 subobject to the RRO makes the > RRO too large for > MTU, will it send a RESVERR or PATHERR, > my guess is it should send a Patherror upstream. > > I apologize if this has been answered before, but i put this > question up > since i couldnt find any specific discussion that answers my question. > > regards > > Manish > > > > > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > From owner-mpls@UU.NET Wed May 1 16:09:50 2002 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 QAA26154 for ; Wed, 1 May 2002 16:09:49 -0400 (EDT) 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 QQmmzs24362; Wed, 1 May 2002 19:08:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmzs08051 for mpls-outgoing; Wed, 1 May 2002 19:08: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 QQmmzs08044 for ; Wed, 1 May 2002 19:08:37 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 QQmmzs14615 for ; Wed, 1 May 2002 19:07:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmmzs27097 for ; Wed, 1 May 2002 19:07:02 GMT 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 PAA19030 for ; Wed, 1 May 2002 15:07:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA08894 for mpls@uu.net; Wed, 1 May 2002 15:07:01 -0400 (EDT) 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 QQmmzs03844 for ; Wed, 1 May 2002 19:06: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 QQmmzs27890 for ; Wed, 1 May 2002 19:04:50 GMT Received: from nero.doit.wisc.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nero.doit.wisc.edu [128.104.17.130]) id QQmmzs24517 for ; Wed, 1 May 2002 19:04:50 GMT Received: (from jleu@localhost) by nero.doit.wisc.edu (8.11.6/8.11.6) id g41Kokh32392 for mpls@uu.net; Wed, 1 May 2002 15:50:47 -0500 Date: Wed, 1 May 2002 15:50:45 -0500 From: "James R. Leu" To: mpls@UU.NET Subject: RFC3036: "change in next hop" question (re-post) Message-ID: <20020501155045.A32387@nero.doit.wisc.edu> Reply-To: jleu@mindspring.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Organization: none Sender: owner-mpls@UU.NET Precedence: bulk Hello, (Excuse me if this has already been discussed, just send me the pointer and I'll be on my way.) In "Detect Change in FEC Next Hop" Note 4 states: 4. Regardless of the Label Request procedure in use by the LSR, it must send a label request if the conditions in NH.8 hold. Therefore it executes the Send_Label_Request procedure directly rather than perform LSR Label Request procedure. .. but when looking at NH.8: NH.8 Execute procedure Send_Message (Old Next Hop, Label Abort Request, FEC, TLV), where TLV is a Label Request Message ID TLV that carries the message ID of the pending label request. .. I do not see any conditions to hold true. I'm thinking Note 4 was unchanged when the "Label Abort Request" support was added many revisions ago. I think the conditions that need to hold true are: NH.6 Does LSR have a label request pending with Old Next Hop? If not, goto NH.10. NH.7 Is LSR using Conservative label retention? If not, goto NH.10. Could anyone shed any light on this? If not, does anyone remember what revision added the "Label Abort Request" message? Thanks, Jim -- James R. Leu From owner-mpls@UU.NET Wed May 1 16:40:57 2002 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 QAA29505 for ; Wed, 1 May 2002 16:40:57 -0400 (EDT) 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 QQmmzy29674; Wed, 1 May 2002 20:40:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmzy08639 for mpls-outgoing; Wed, 1 May 2002 20:39: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 QQmmzy08634 for ; Wed, 1 May 2002 20:39: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 QQmmzy29904 for ; Wed, 1 May 2002 20:39:37 GMT Received: from hebe.or.intel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: jffdns02.or.intel.com [134.134.248.4]) id QQmmzy28964 for ; Wed, 1 May 2002 20:39:36 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by hebe.or.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.35 2002/04/27 00:24:14 root Exp $) with SMTP id g41KdZh12784 for ; Wed, 1 May 2002 20:39:35 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002050113470200590 ; Wed, 01 May 2002 13:47:02 -0700 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 May 2002 13:39:35 -0700 Message-ID: From: "Feng, Mark" To: "'Shahram Davari'" , "'No name'", mpls@UU.NET Subject: RE: RFC3209 Date: Wed, 1 May 2002 13:39:33 -0700 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 Please see comments below. - Mark > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, May 01, 2002 10:10 AM > To: 'No name'; mpls@UU.NET > Subject: RE: RFC3209 > > > Hi, > > A related question: > > Is the RESV RRO appended to the Path RRO or the PATH RRO is > stripped off > in the RESV message? > The Resv RROs specifies the reverse path. The Path RRO shouldn't be appended. > My reading of RFC3209 is that the PATH RRO is stripped off, > before sending RESV message. > If this is the case then the Egress never adds its address to > the PATH RRO. It only adds its > address to the RESV RRO, and therefore the Notify message > should be sent to the EGRESS. > > However, any such Notify sent to Egress will be converted to > Path Error message which will then be > sent to the ingress. So practically it should not make any > difference to generate the PathError > at the egress or to sent Notify to the egress which then > converts it to PathErorr. > > -Shahram > > > -----Original Message----- > > From: No name [mailto:nonamelinux@hotmail.com] > > Sent: Tuesday, April 30, 2002 2:57 PM > > To: mpls@UU.NET > > Subject: RFC3209 > > > > > > Hi > > > > This questions is about the handling of "RRO too large for > MTU" cases. > > > > "If the newly added subobject causes the RRO to be too big > to fit in a > > Path (or Resv) message, the RRO object SHALL be dropped from > > the message > > and message processing continues as normal. A PathErr (or > ResvErr) > > message SHOULD be sent back to the sender (or receiver). An > > error code of "Notify" and an error value of "RRO too large for MTU" > > is used. If the receiver receives such a ResvErr, it SHOULD send a > > PathErr message with error code of "Notify" and an error value of > > "RRO notification". " > > > > > > IF adding the EGRESS's IPv4 subobject to the RRO makes the > > RRO too large for > > MTU, will it send a RESVERR or PATHERR, > > my guess is it should send a Patherror upstream. > > The egress cannot send ResvErr. Where would that go? It should send a PathErr, so that the ingress node can take action. But I am not sure the possibility of such error in the egress node, considering the limiting size is the IP packet size. > > I apologize if this has been answered before, but i put this > > question up > > since i couldnt find any specific discussion that answers > my question. > > > > regards > > > > Manish > > > > > > > > > > > > > > _________________________________________________________________ > > Chat with friends online, try MSN Messenger: > http://messenger.msn.com > > > From owner-mpls@UU.NET Wed May 1 17:07:58 2002 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 RAA02085 for ; Wed, 1 May 2002 17:07:58 -0400 (EDT) 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 QQmmzu28735; Wed, 1 May 2002 19:33:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmzu11623 for mpls-outgoing; Wed, 1 May 2002 19:33: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 QQmmzu11618 for ; Wed, 1 May 2002 19:33:32 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 QQmmzu05469 for ; Wed, 1 May 2002 19:32:29 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandmail.sandburst.com [216.57.132.42]) id QQmmzu14396 for ; Wed, 1 May 2002 19:32:28 GMT Message-ID: <3CD042C6.7BF07D86@sandburst.com> Date: Wed, 01 May 2002 15:32:22 -0400 From: Eric Gray MIME-Version: 1.0 To: jleu@mindspring.com Cc: mpls@UU.NET Subject: Re: RFC3036: "change in next hop" question (re-post) References: <20020501155045.A32387@nero.doit.wisc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jim, A pending label request for an old next hop and conservative label retention could be considered to be the conditions that hold in NH.8 since these MUST be true if you have reached NH.8... You wrote: > Hello, > > (Excuse me if this has already been discussed, just > send me the pointer and I'll be on my way.) > > In "Detect Change in FEC Next Hop" Note 4 states: > > 4. Regardless of the Label Request procedure in use by the LSR, it > must send a label request if the conditions in NH.8 hold. > Therefore it executes the Send_Label_Request procedure directly > rather than perform LSR Label Request procedure. > > .. but when looking at NH.8: > > NH.8 Execute procedure Send_Message (Old Next Hop, Label Abort > Request, FEC, TLV), where TLV is a Label Request Message > ID TLV that carries the message ID of the pending label > request. > > .. I do not see any conditions to hold true. I'm thinking Note 4 was > unchanged when the "Label Abort Request" support was added many revisions ago. > I think the conditions that need to hold true are: > > NH.6 Does LSR have a label request pending with Old Next Hop? > If not, goto NH.10. > > NH.7 Is LSR using Conservative label retention? > If not, goto NH.10. > > Could anyone shed any light on this? If not, does anyone remember > what revision added the "Label Abort Request" message? > > Thanks, > Jim > -- > James R. Leu -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray From owner-mpls@UU.NET Wed May 1 18:15:42 2002 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 SAA11094 for ; Wed, 1 May 2002 18:15:41 -0400 (EDT) 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 QQmnae28252; Wed, 1 May 2002 22:14:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnae00209 for mpls-outgoing; Wed, 1 May 2002 22:14: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 QQmnae00203 for ; Wed, 1 May 2002 22:14:33 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 QQmnae20899 for ; Wed, 1 May 2002 22:14:24 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 QQmnae03978 for ; Wed, 1 May 2002 22:14:24 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.1/Switch-2.2.0) with ESMTP id g41MEMW12071 for ; Wed, 1 May 2002 18:14:23 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2GN8DYTW>; Thu, 2 May 2002 00:14:21 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: Martin Dubuc , "Wijnen, Bert (Bert)" , Loa Andersson , George Swallow , "Thomas Nadeau (E-mail)" , sudheer@nayna.com, jplang@calient.net, mpls@UU.NET, Scott Bradner Subject: RE: WG Last call - draft-ietf-mpls-bundle-mib-01.txt Date: Thu, 2 May 2002 00:14:14 +0200 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 Sorry to say so, but when I see something in WG (or whatever) Last Call and I see so many syntax issues, I sort of think: oh well... I will not waste my time I suspect many other MIB people may do the same. Why don't you fix those things first? Bert > -----Original Message----- > From: Martin Dubuc [mailto:Martin.Dubuc@meriton.com] > Sent: Thursday, May 02, 2002 12:03 AM > To: Wijnen, Bert (Bert); Loa Andersson; George Swallow; Thomas Nadeau > (E-mail); sudheer@nayna.com; jplang@calient.net; mpls@UU.NET; Scott > Bradner > Subject: RE: WG Last call - draft-ietf-mpls-bundle-mib-01.txt > > > Bert, > > I requested Last Call for the link bundling MIB at the same > time as LMP MIB. I didn't know before these two requests that > I could use a stricter level of error checking with smilint. > I do intend to clean up both LMP and link bundling MIBs of > all errors reported by smilint with the highest level of checking. > > I still believe that the link bundling MIB addresses key > concepts and is worth going to Last Call at this point. > > Regards, > > Martin > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Wednesday, May 01, 2002 5:45 PM > To: Loa Andersson; George Swallow; Thomas Nadeau (E-mail); > Martin Dubuc; > sudheer@nayna.com; jplang@calient.net > Cc: Scott Bradner > Subject: RE: WG Last call - draft-ietf-mpls-bundle-mib-01.txt > > > I really wonder how you can do a WG Last Call for this doc. > If I do a SMICng compile to do syntax check, I get > 14 errors and 22 warnings. I have not looked at the content yet. > But if WGs deliver this type of stuff to the ADs, then I > wonder if we should in fact even spend time on it? > > Sorry, but I get rather frustrated of this. I think I mentioned > this type of concern many times to this WG and to some of the > authors before. > > Bert > ------------ SMICng log --------------- > In file mplsbundle.mi2 > 80: REVISION > 81: "200105223200Z" -- 22 May 2001 12:00:00 EST > ^ > W: REVISION value "200105223200Z" is not a valid extended UTC time > 1124: > 1125: OBJECT teLinkRowStatus > ^ > W: MIN-ACCESS value identical to access specified for > "teLinkRowStatus" > 1132: > 1133: OBJECT teLinkStorageType > ^ > W: MIN-ACCESS value identical to access specified for > "teLinkStorageType" > 1140: > 1141: OBJECT teLinkDescrRowStatus > ^ > W: MIN-ACCESS value identical to access specified for > "teLinkDescrRowStatus" > 1147: > 1148: OBJECT teLinkDescrStorageType > ^ > W: MIN-ACCESS value identical to access specified for > "teLinkDescrStorageType" > 1156: OBJECT teLinkOspfLinkId > 1157: SYNTAX INTEGER { pointToPoint(1) } > ^ > E: Syntax type does not match that for "teLinkOspfLinkId" > 1155: > 1156: OBJECT teLinkOspfLinkId > ^ > E: MIN-ACCESS value incompatible with access specified for > "teLinkOspfLinkId" > 1163: > 1164: OBJECT srlgRowStatus > ^ > W: MIN-ACCESS value identical to access specified for "srlgRowStatus" > 1171: > 1172: OBJECT srlgStorageType > ^ > W: MIN-ACCESS value identical to access specified for > "srlgStorageType" > 1179: > 1180: OBJECT teLinkBandwidthRowStatus > ^ > W: MIN-ACCESS value identical to access specified for > "teLinkBandwidthRowStatus" > 1187: > 1188: OBJECT teLinkBandwidthStorageType > ^ > W: MIN-ACCESS value identical to access specified for > "teLinkBandwidthStorageType" > 1195: > 1196: OBJECT dataBearingChannelRowStatus > ^ > W: MIN-ACCESS value identical to access specified for > "dataBearingChannelRowStatus" > 1203: > 1204: OBJECT dataBearingChannelStorageType > ^ > W: MIN-ACCESS value identical to access specified for > "dataBearingChannelStorageType" > 1211: > 1212: OBJECT dataBearingChannelDescrRowStatus > ^ > W: MIN-ACCESS value identical to access specified for > "dataBearingChannelDescrRowStatus" > 1218: > 1219: OBJECT dataBearingChannelDescrStorageType > ^ > W: MIN-ACCESS value identical to access specified for > "dataBearingChannelDescrStorageType" > 1226: > 1227: OBJECT dataBearingChannelBwRowStatus > ^ > W: MIN-ACCESS value identical to access specified for > "dataBearingChannelBwRowStatus" > 1234: > 1235: OBJECT dataBearingChannelBwStorageType > ^ > W: MIN-ACCESS value identical to access specified for > "dataBearingChannelBwStorageType" > 1211: > 1212: OBJECT dataBearingChannelDescrRowStatus > ^ > E: OBJECT-TYPE "dataBearingChannelDescrRowStatus" is not in a > MANDATORY or conditional group for module "LINK-BUNDLING-MIB" > 1218: > 1219: OBJECT dataBearingChannelDescrStorageType > ^ > E: OBJECT-TYPE "dataBearingChannelDescrStorageType" is not in > a MANDATORY or conditional group for module "LINK-BUNDLING-MIB" > 1226: > 1227: OBJECT dataBearingChannelBwRowStatus > ^ > E: OBJECT-TYPE "dataBearingChannelBwRowStatus" is not in a > MANDATORY or conditional group for module "LINK-BUNDLING-MIB" > 1234: > 1235: OBJECT dataBearingChannelBwStorageType > ^ > E: OBJECT-TYPE "dataBearingChannelBwStorageType" is not in a > MANDATORY or conditional group for module "LINK-BUNDLING-MIB" > 1314: OBJECT teLinkOspfLinkId > 1315: SYNTAX INTEGER { pointToPoint(1) } > ^ > E: Syntax type does not match that for "teLinkOspfLinkId" > 1313: > 1314: OBJECT teLinkOspfLinkId > ^ > W: MIN-ACCESS value identical to access specified for > "teLinkOspfLinkId" > 1375: > 1376: OBJECT dataBearingChannelEncodingType > ^ > E: OBJECT-TYPE "dataBearingChannelEncodingType" is not in a > MANDATORY or conditional group for module "LINK-BUNDLING-MIB" > 1380: > 1381: OBJECT dataBearingChannelDescrPriority > ^ > E: OBJECT-TYPE "dataBearingChannelDescrPriority" is not in a > MANDATORY or conditional group for module "LINK-BUNDLING-MIB" > 1385: > 1386: OBJECT dataBearingChannelMinReservableBandwidth > ^ > E: OBJECT-TYPE "dataBearingChannelMinReservableBandwidth" is > not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB" > 1390: > 1391: OBJECT dataBearingChannelDescrRowStatus > ^ > E: OBJECT-TYPE "dataBearingChannelDescrRowStatus" is not in a > MANDATORY or conditional group for module "LINK-BUNDLING-MIB" > 1397: > 1398: OBJECT dataBearingChannelDescrStorageType > ^ > E: OBJECT-TYPE "dataBearingChannelDescrStorageType" is not in > a MANDATORY or conditional group for module "LINK-BUNDLING-MIB" > 1405: > 1406: OBJECT dataBearingChannelBwRowStatus > ^ > E: OBJECT-TYPE "dataBearingChannelBwRowStatus" is not in a > MANDATORY or conditional group for module "LINK-BUNDLING-MIB" > 1413: > 1414: OBJECT dataBearingChannelBwStorageType > ^ > E: OBJECT-TYPE "dataBearingChannelBwStorageType" is not in a > MANDATORY or conditional group for module "LINK-BUNDLING-MIB" > 4: MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, > 5: experimental, Integer32, Unsigned32 > ^ > W: "Integer32" imported but not used > 10: > 11: TEXTUAL-CONVENTION, TruthValue, RowStatus, StorageType, > ^ > W: "TEXTUAL-CONVENTION" imported but not used > 11: TEXTUAL-CONVENTION, TruthValue, RowStatus, StorageType, > 12: RowPointer, TimeStamp > ^ > W: "RowPointer" imported but not used > ^ > W: "TimeStamp" imported but not used > 14: > 15: InterfaceIndex, InterfaceIndexOrZero, ifIndex > ^ > W: "InterfaceIndex" imported but not used > 21: > 22: InetAddressType, InetAddress > ^ > W: "InetAddressType" imported but not used > > *** 14 errors and 22 warnings in parsing > From owner-mpls@UU.NET Thu May 2 09:08:58 2002 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 JAA21814 for ; Thu, 2 May 2002 09:08:58 -0400 (EDT) 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 QQmncm18807; Thu, 2 May 2002 13:07:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmncm09966 for mpls-outgoing; Thu, 2 May 2002 13:07: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 QQmncm09893 for ; Thu, 2 May 2002 13:07:12 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 QQmncm02863 for ; Thu, 2 May 2002 13:06:04 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmncm17178 for ; Thu, 2 May 2002 13:06:03 GMT 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 JAA29551 for ; Thu, 2 May 2002 09:06:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA20288 for mpls@uu.net; Thu, 2 May 2002 09:06:02 -0400 (EDT) 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 QQmncm04241 for ; Thu, 2 May 2002 13:05:18 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 QQmncm28779 for ; Thu, 2 May 2002 13:04:36 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmncm15788 for ; Thu, 2 May 2002 13:04:36 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 18:43:35 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06049810@HARITHA> From: "Vijayanand C - CTD, Chennai." To: mpls@UU.NET Subject: FW: CR LDP fast reroute - New draft( repost) Date: Thu, 2 May 2002 18:36:30 +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 all, I would like to know your views on the below-mentioned draft which I submitted some time back. Thanks in advance Regards, Vijay -----Original Message----- From: Vijayanand C - CTD, Chennai. [mailto:vijayc@ctd.hcltech.com] Sent: Thursday, April 11, 2002 6:20 PM To: mpls@UU.NET Subject: CR LDP fast reroute - New draft Hello all, A new draft has on CR LDP fast reroute has been posted whose details are given below. I invite your comments on this draft. Regards, Vijay A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Fast Reroute Extensions to CRLDP Author(s) : C. Vijayanand Filename : draft-vijay-mpls-crldp-fastreroute-00.txt Pages : 10 Date : 10-Apr-02 This document describes the use of CR-LDP [CRLDP] to establish backup LSP tunnels for local repair of LSP tunnels established by CR-LDP. This document proposes extensions to existing CR-LDP for setting up backup tunnels for protecting LSPs on an exclusive bandwidth basis or shared bandwidth basis as desired by the initiator of the tunnel at the head end node. Several backup segments are maintained for a single LSP and they are meant to provide link and node failure protection along various segments of the LSP. Sharing of backup segments across multiple LSPs is also facilitated to achieve scalability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vijay-mpls-crldp-fastreroute-00.tx t From owner-mpls@UU.NET Thu May 2 09:50:14 2002 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 JAA25859 for ; Thu, 2 May 2002 09:50:14 -0400 (EDT) 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 QQmncp03989; Thu, 2 May 2002 13:49:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQmncp14254 for mpls-outgoing; Thu, 2 May 2002 13:49: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 QQmncp14249 for ; Thu, 2 May 2002 13:48:58 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 QQmncp12737 for ; Thu, 2 May 2002 13:48:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmncp02473 for ; Thu, 2 May 2002 13:48:02 GMT 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 JAA03046 for ; Thu, 2 May 2002 09:48:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA25153 for mpls@uu.net; Thu, 2 May 2002 09:48:02 -0400 (EDT) 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 QQmncp14186 for ; Thu, 2 May 2002 13:47:19 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 QQmncp19927 for ; Thu, 2 May 2002 13:46:57 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmncp01153 for ; Thu, 2 May 2002 13:46:56 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 JAA25848; Thu, 2 May 2002 09:46:50 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200205021346.JAA25848@workhorse.fictitious.org> To: "Vijayanand C - CTD, Chennai." cc: mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: FW: CR LDP fast reroute - New draft( repost) In-reply-to: Your message of "Thu, 02 May 2002 18:36:30 +0530." <55E277B99171E041ABF5F4B1C6DDCA06049810@HARITHA> Date: Thu, 02 May 2002 09:46:50 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <55E277B99171E041ABF5F4B1C6DDCA06049810@HARITHA>, "Vijayanand C - CT D, Chennai." writes: > Hello all, > I would like to know your views on the below-mentioned draft which I > submitted some time back. > > Thanks in advance > Regards, > Vijay Vijay, We have yet to have a customer request CRLDP therefore we have no interest in CRLDP. Maybe there is a rough consensus yawn. Curtis From owner-mpls@UU.NET Thu May 2 10:38:18 2002 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 KAA01061 for ; Thu, 2 May 2002 10:38:14 -0400 (EDT) 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 QQmncs25906; Thu, 2 May 2002 14:36:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQmncs09843 for mpls-outgoing; Thu, 2 May 2002 14:36: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 QQmncs09838 for ; Thu, 2 May 2002 14:36: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 QQmncs28117 for ; Thu, 2 May 2002 14:36:11 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmncs13214 for ; Thu, 2 May 2002 14:36:10 GMT 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 KAA06486 for ; Thu, 2 May 2002 10:36:10 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA00244 for mpls@uu.net; Thu, 2 May 2002 10:36:10 -0400 (EDT) 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 QQmnae19590 for ; Wed, 1 May 2002 22:05: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 QQmnae09112 for ; Wed, 1 May 2002 22:04:15 GMT Received: from edgsvr04.edgeflow.edgeflow.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: owa.meriton.com [209.202.126.190]) id QQmnae17833 for ; Wed, 1 May 2002 22:04:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Last call - draft-ietf-mpls-bundle-mib-01.txt Date: Wed, 1 May 2002 18:02:32 -0400 Message-ID: <2B192BF55E1A4440A1176A12D86600C915C890@edgsvr04.edgeflow.edgeflow.com> Thread-Topic: WG Last call - draft-ietf-mpls-bundle-mib-01.txt Thread-Index: AcHxWUICPeoRkfruQoSGuTcfFqa7xwAAdihA From: "Martin Dubuc" To: "Wijnen, Bert (Bert)" , "Loa Andersson" , "George Swallow" , "Thomas Nadeau (E-mail)" , , , , "Scott Bradner" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA01061 Bert, I requested Last Call for the link bundling MIB at the same time as LMP MIB. I didn't know before these two requests that I could use a stricter level of error checking with smilint. I do intend to clean up both LMP and link bundling MIBs of all errors reported by smilint with the highest level of checking. I still believe that the link bundling MIB addresses key concepts and is worth going to Last Call at this point. Regards, Martin -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Wednesday, May 01, 2002 5:45 PM To: Loa Andersson; George Swallow; Thomas Nadeau (E-mail); Martin Dubuc; sudheer@nayna.com; jplang@calient.net Cc: Scott Bradner Subject: RE: WG Last call - draft-ietf-mpls-bundle-mib-01.txt I really wonder how you can do a WG Last Call for this doc. If I do a SMICng compile to do syntax check, I get 14 errors and 22 warnings. I have not looked at the content yet. But if WGs deliver this type of stuff to the ADs, then I wonder if we should in fact even spend time on it? Sorry, but I get rather frustrated of this. I think I mentioned this type of concern many times to this WG and to some of the authors before. Bert ------------ SMICng log --------------- In file mplsbundle.mi2 80: REVISION 81: "200105223200Z" -- 22 May 2001 12:00:00 EST ^ W: REVISION value "200105223200Z" is not a valid extended UTC time 1124: 1125: OBJECT teLinkRowStatus ^ W: MIN-ACCESS value identical to access specified for "teLinkRowStatus" 1132: 1133: OBJECT teLinkStorageType ^ W: MIN-ACCESS value identical to access specified for "teLinkStorageType" 1140: 1141: OBJECT teLinkDescrRowStatus ^ W: MIN-ACCESS value identical to access specified for "teLinkDescrRowStatus" 1147: 1148: OBJECT teLinkDescrStorageType ^ W: MIN-ACCESS value identical to access specified for "teLinkDescrStorageType" 1156: OBJECT teLinkOspfLinkId 1157: SYNTAX INTEGER { pointToPoint(1) } ^ E: Syntax type does not match that for "teLinkOspfLinkId" 1155: 1156: OBJECT teLinkOspfLinkId ^ E: MIN-ACCESS value incompatible with access specified for "teLinkOspfLinkId" 1163: 1164: OBJECT srlgRowStatus ^ W: MIN-ACCESS value identical to access specified for "srlgRowStatus" 1171: 1172: OBJECT srlgStorageType ^ W: MIN-ACCESS value identical to access specified for "srlgStorageType" 1179: 1180: OBJECT teLinkBandwidthRowStatus ^ W: MIN-ACCESS value identical to access specified for "teLinkBandwidthRowStatus" 1187: 1188: OBJECT teLinkBandwidthStorageType ^ W: MIN-ACCESS value identical to access specified for "teLinkBandwidthStorageType" 1195: 1196: OBJECT dataBearingChannelRowStatus ^ W: MIN-ACCESS value identical to access specified for "dataBearingChannelRowStatus" 1203: 1204: OBJECT dataBearingChannelStorageType ^ W: MIN-ACCESS value identical to access specified for "dataBearingChannelStorageType" 1211: 1212: OBJECT dataBearingChannelDescrRowStatus ^ W: MIN-ACCESS value identical to access specified for "dataBearingChannelDescrRowStatus" 1218: 1219: OBJECT dataBearingChannelDescrStorageType ^ W: MIN-ACCESS value identical to access specified for "dataBearingChannelDescrStorageType" 1226: 1227: OBJECT dataBearingChannelBwRowStatus ^ W: MIN-ACCESS value identical to access specified for "dataBearingChannelBwRowStatus" 1234: 1235: OBJECT dataBearingChannelBwStorageType ^ W: MIN-ACCESS value identical to access specified for "dataBearingChannelBwStorageType" 1211: 1212: OBJECT dataBearingChannelDescrRowStatus ^ E: OBJECT-TYPE "dataBearingChannelDescrRowStatus" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB" 1218: 1219: OBJECT dataBearingChannelDescrStorageType ^ E: OBJECT-TYPE "dataBearingChannelDescrStorageType" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB" 1226: 1227: OBJECT dataBearingChannelBwRowStatus ^ E: OBJECT-TYPE "dataBearingChannelBwRowStatus" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB" 1234: 1235: OBJECT dataBearingChannelBwStorageType ^ E: OBJECT-TYPE "dataBearingChannelBwStorageType" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB" 1314: OBJECT teLinkOspfLinkId 1315: SYNTAX INTEGER { pointToPoint(1) } ^ E: Syntax type does not match that for "teLinkOspfLinkId" 1313: 1314: OBJECT teLinkOspfLinkId ^ W: MIN-ACCESS value identical to access specified for "teLinkOspfLinkId" 1375: 1376: OBJECT dataBearingChannelEncodingType ^ E: OBJECT-TYPE "dataBearingChannelEncodingType" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB" 1380: 1381: OBJECT dataBearingChannelDescrPriority ^ E: OBJECT-TYPE "dataBearingChannelDescrPriority" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB" 1385: 1386: OBJECT dataBearingChannelMinReservableBandwidth ^ E: OBJECT-TYPE "dataBearingChannelMinReservableBandwidth" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB" 1390: 1391: OBJECT dataBearingChannelDescrRowStatus ^ E: OBJECT-TYPE "dataBearingChannelDescrRowStatus" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB" 1397: 1398: OBJECT dataBearingChannelDescrStorageType ^ E: OBJECT-TYPE "dataBearingChannelDescrStorageType" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB" 1405: 1406: OBJECT dataBearingChannelBwRowStatus ^ E: OBJECT-TYPE "dataBearingChannelBwRowStatus" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB" 1413: 1414: OBJECT dataBearingChannelBwStorageType ^ E: OBJECT-TYPE "dataBearingChannelBwStorageType" is not in a MANDATORY or conditional group for module "LINK-BUNDLING-MIB" 4: MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, 5: experimental, Integer32, Unsigned32 ^ W: "Integer32" imported but not used 10: 11: TEXTUAL-CONVENTION, TruthValue, RowStatus, StorageType, ^ W: "TEXTUAL-CONVENTION" imported but not used 11: TEXTUAL-CONVENTION, TruthValue, RowStatus, StorageType, 12: RowPointer, TimeStamp ^ W: "RowPointer" imported but not used ^ W: "TimeStamp" imported but not used 14: 15: InterfaceIndex, InterfaceIndexOrZero, ifIndex ^ W: "InterfaceIndex" imported but not used 21: 22: InetAddressType, InetAddress ^ W: "InetAddressType" imported but not used *** 14 errors and 22 warnings in parsing From owner-mpls@UU.NET Thu May 2 15:06:38 2002 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 PAA27517 for ; Thu, 2 May 2002 15:06:38 -0400 (EDT) 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 QQmndk26419; Thu, 2 May 2002 19:05:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmndk10616 for mpls-outgoing; Thu, 2 May 2002 19:05:11 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 QQmndk10594 for ; Thu, 2 May 2002 19:05:03 GMT Received: from dgismtp05.wcomnet.com by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dgismtp05.wcomnet.com [166.38.58.88]) id QQmndk16713 for ; Thu, 2 May 2002 19:03:55 GMT Received: from CONVERSION-DAEMON.dgismtp05.wcomnet.com by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) id <0GVH00501ZLYFU@dgismtp05.wcomnet.com> for mpls@UU.NET; Thu, 02 May 2002 19:03:34 +0000 (GMT) Received: from dgismtp05.wcomnet.com by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GVH00501ZLYFV@dgismtp05.wcomnet.com> for mpls@UU.NET; Thu, 02 May 2002 19:03:34 +0000 (GMT) Received: from dmcdysan ([166.32.198.25]) by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GVH002P9ZLWVB@dgismtp05.wcomnet.com>; Thu, 02 May 2002 19:03:34 +0000 (GMT) Date: Thu, 02 May 2002 15:05:26 -0400 From: Dave McDysan Subject: FYI: WorldCom Vote/Comments - ITU-T Y.1710 (Corr. 1) and Y.1711 To: mpls@UU.NET, ppvpn@ppvpn.francetelecom.com, ccamp@ops.ietf.org, pwe3-admin@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Message-Flag: Follow up Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit WorldCom has submmited comments on draft recommendations ITU-T Y.1710 (Corr. 1) and Y.1711 to the ITU-T with a vote of "We do not support this text. Reasons are given in the attachment." It is not yet clear whether these comments will be handled at the Japan meeting in July or at the next SG13 meeting in Oct-Nov'02. WorldCom is trying to get clarification. These comments have been posted by the ITU-T secretariat at: http://www.itu.int/itudoc/itu-t/aap/sg13aap/recaap/y.1710c1/arc/ar1.html and http://www.itu.int/itudoc/itu-t/aap/sg13aap/recaap/y.1711/arc/ar1.html However, access require a TIES account which an ITU member can request by sending a form to the ITU-T. After getting the TIES access, you may sign up for ITU-T SG13, Question 3, email list "tsg13q3@itu.int" at http://www.itu.int/ITU-T/studygroups/com13/edh/subscribe.html if you want to be part of email discussion on these and other related comments. WorldCom has also advised ITU-T SG13,Question 3 participants of these comments who are responsible for development of these recommendations in SG13. If your company is an ITU-T member and is interested in this subject, we encourage you to participate in the process. The WorldCom comments on the subject documents are reproduced below for your information. Dave ============================================================================ = ITU-T Draft Recommendations Y.1710 (Corr. 1) (WorldCom Comments - Additional Review) 1. General Comments Although never clearly stated in Y.1710, based upon related discussion and documents submitted to the IETF, this recommendation appears to assume that MPLS is a layer two service, requiring OAM functionality that exists independently of any layer three technology. This assumption is not consistent with the cited IETF references of RFC 3031 and 3032, which only address IP over MPLS. Furthermore, as detailed below, some requirements strive to preclude OAM mechanisms that rely upon IP. The IETF has no efforts in place to define MPLS as a layered network service in its own right. It is incumbent upon those who would augment MPLS so that it can become a layered service on its own to explain why existing services, for example, FR and ATM, do not suffice. This must be done with the concurrence and cooperation of the IETF, since two bodies developing standards for the same protocol will likely result in a lack of interoperability. We suggest that those seeking to use MPLS to deliver multiple services should explore the IETF PWE3 work. It may be more appropriate to build OAM functionality into the PWE endpoints than in the MPLS layer as proposed in Y.1710 and Y.1711. We also have a number of questions. Can the proposed mechanisms be implemented without fundamental changes to the deployed MPLS base? Will the proposed mechanisms provide any useful functionality in the face of penultimate hop popping? Will the proposed mechanisms provide any useful functionality in the face of LSP merging? Will the proposed mechanisms provide any useful functionality in the face of unidirectional LSPs? Finally, we believe that there are several process issues with these proposals: a. First, in general defining OAM prior to the standardization of a service appears to be the wrong order of doing things. b. Second, defining requirements and a proposed solution to them in parallel is an approach that seems to preclude the critical examination of alternative solutions. We strongly recommend that the ITU-T focus on defining the problem scope and associated requirements BEFORE taking up any specific solution. c. Finally, in the IETF way of doing things it is perfectly acceptable for vendors or service providers to develop experimental implementations of the protocol(s) defined in Y.1711 and bring the results of this work back to the IETF. 2. Detailed Comments 2.1 Section 1 Scope - Since the plural is used in "MPLS networks," does the scope include MPLS LSPs that traverse multiple service providers? If so, this should be explicitly stated. - Since only RFC 3031 and 3032 are cited as references for MPLS, the scope is restricted to IP over MPLS networks. Although other efforts are in progress to standardize other services over MPLS, until these standards are complete and stable, definition of the means to operate and maintain (OAM) them are premature. 2.2 Section 3 Definitions - Why is control information excluded from these definitions? How relevant are definitions to IP over MPLS from the cited M.20 Recommendation intended to define migration from analogue to digital circuits? 2.3 Section 5 Introduction - What is the basis of determining whether a solution is "architecturally correct?" Suggest that the reference for a correct architecture be cited and agreed to,or strike this phrase. - Suggest that instead of "maintain correct connectivity," what is actually required is to "maintain and confirm configured connectivity." This should also be stated in the bulleted list in the second paragraph. - The claim in the last sentence that an LSP is tied to availability and QoS SLAs for customer traffic is suspect. An LSP is only part of an IP service. For example, IP traffic may be load balanced across more than one LSP, or may traverse router hops that do not use MPLS. Even in a pseudo-wire over MPLS application, the entire customer service may not be over MPLS. The fact that MPLS is often only part of the overall service needs to be stated in the scope and carried throughout the requirements structure. 2.4 Section 6 Motivation for MPLS Functions - General Comment * A number of terms used in this section are not used in the MPLS standards cited in section 2, and should be replaced with standard terminology. For example, the Y.1710 terminology in quotes should be replaced as follows with terminology from RFCs 3031 and 3032: > "client" = packet or network layer > "server" = link layer > "MPLS nesting capability" = label stacking > "control-plane" = control protocol > "user-plane" = forwarding * It is unclear why much of this text and reasoning is needed in a requirements document. If retained, this text needs definitions of all terms and better explanation of the concepts addressed. Some detailed comments below attempt to draw out some of the issues with this text. - Item 1 * First paragraph: The level of MPLS label stacking is limited by at least the MTU size of the link layer. * Second paragraph: Need better description or an example of a "MPLS control-plane OAM function" in order to provide appropriate motivation. . First dash: What is "user-plane" for customer traffic and signalling? If these do not have the same processing or failure conditions, then is this an implementation issue that is outside the scope of standards? Wouldn't the same argument of the last sentence apply equally to MPLS OAM packets? . Second dash: This is outside the scope of RFC 3031. . Third dash: This is not worded as a problem. . Next to last paragraph: The assertion that well defined and interoperable MPLS control protocols and (as yet undefined) MPLS OAM mechanisms be defined independently so that they can evolve independently is questionable. For example, as stated earlier, it seems highly desirable that in order for MPLS OAM mechanisms to confirm configured connectivity that a dependence of OAM on control protocol configuration makes sense. The last paragraph of item 1 that the solution is control-plane independent appears to be in contradiction with RFC 3031, which requires and IP control plane in every MPLS LSR. - Item 2 * See comment in section 5. An LSP is not necessarily directly related to a customer service. - Items 3 & 5 * Seem to be making the same point. Also, most of this information is repeated in section 7. - Item 6 * The example of "squelching of traffic" is unclear. Wouldn't the preferred solution be to correctly direct the traffic? Is squelching an intermediate step toward this goal? - Item 8 * Interaction of protection and restoration between multiple technological layers operating under different paradigms is a complex and as yet not completely understood subject. 2.5 Section 7 Requirements for MPLS OAM Functions - Item 1 * "on-demand" and "continuous" are not defined. - Item 2 * Why is notification of a control protocol not mentioned? - Item 3 * This requirement is vague. How would one determine whether a particular solution met this requirement? Last sentence is redundant with item 4. - Item 4 * The terms "fabric", "swapped" and "self-replication" are not defined in the document or any of the references cited. Need a definition of "simple loss of LSP connectivity". - Item 5 * A very general statement which leaves it unclear as to what the specific requirement is on MPLS OAM. Needs clarification. - Item 9 * Where is the definition for a LSN? RFC 3032 defines a Label Switching Router LSR), and suggest use of this term. It appears that this requirement would apply to the egress LSR. What happens when penultimate hop popping is implemented? - Item 10 * As mentioned earlier, MPLS is not currently defined as a service and hence availability and QoS are not meaningful in the conventional sense. Also, the reference to Y.1711 should be removed. A requirement should not be defined in terms of a specific solution. - Item 11 * Since only RFC 3031 and 3032 are cited as normative references for MPLS, the scope is restricted to IP over MPLS networks. Since only support for an IP "client" network is all that is defined, this requirement for OAM is premature until protocols (or at least the architecture for them) for support of other "client" networks are standardized. - Item 12 * Since only RFC 3031 and 3032 are cited as normative references for MPLS, the scope is restricted to IP over MPLS networks. This requirement has no architectural or protocol standards basis. - Item 14 * Why preclude observance of normal operation as part of OAM? - Item 16 * Second sentence is stated as a solution. Delete. 3. Additional Comments Several important requirements are also missing. We note at least the following: - Since MPLS LSPs are unidirectional, OAM mechanisms that require communication in the opposite direction cannot rely on the existence of an LSP in the opposite direction between the ingress and egress LSR. - Depending upon interpretation of the scope, support for MPLS OAM across multiple service providers may be a requirement. - When MPLS label stacking is employed, the OAM mechanisms must operate correctly at each level of label stacking. - MPLS OAM must work correctly with and without penultimate hop popping. - There needs to be some requirements that scope how large the MPLS OAM identifier space needs to be. For IP over MPLS, the number of LSPs that can exist can be quite large. If other services are considered (e.g., IP VPN, PWE3), then the identifier space needs to be correspondingly large. - It is highly desirable to be able to determine the actual path that an LSP takes. ============================================================================ = ITU-T Draft Recommendations Y.1711 (WorldCom Comments - Additional Review) Since the MPLS OAM mechanisms described in this recommendation are based on the requirements defined in recommendation Y.1710 (Corr. 1), it will be premature to approve Y.1711 until the comments submitted by WorldCom on Y.1710 (Corr. 1) are resolved. WorldCom's general comments on Y.1710 (Corr. 1) are also applicable to Y.1711, and are repeated below for the sake of completeness. Although never clearly stated in Y.1711, based upon related discussion and documents submitted to the IETF, this recommendation appears to assume that MPLS is a layer two service, requiring OAM functionality that exists independently of any layer three technology. This assumption is not consistent with the cited IETF references of RFC 3031 and 3032, which only address IP over MPLS. Furthermore, as detailed below, some requirements strive to preclude OAM mechanisms that rely upon IP. The IETF has no efforts in place to define MPLS as a layered network service in its own right. It is incumbent upon those who would augment MPLS so that it can become a layered service on its own to explain why existing services, for example, FR and ATM, do not suffice. This must be done with the concurrence and cooperation of the IETF, since two bodies developing standards for the same protocol will likely result in a lack of interoperability. We suggest that those seeking to use MPLS to deliver multiple services should explore the IETF PWE3 work. It may be more appropriate to build OAM functionality into the PWE endpoints than in the MPLS layer as proposed in Y.1711. We also have a number of questions. Can the proposed mechanisms be implemented without fundamental changes to the deployed MPLS base? Will the proposed mechanisms provide any useful functionality in the face of penultimate hop popping? Will the proposed mechanisms provide any useful functionality in the face of LSP merging? Will the proposed mechanisms provide any useful functionality in the face of unidirectional LSPs? Finally, we believe that there are several process issues with these proposals: a. First, in general defining OAM prior to the standardization of a service appears to be the wrong order of doing things. b. Second, defining requirements and a proposed solution to them in parallel is an approach that seems to preclude the critical examination of alternative solutions. We strongly recommend that the ITU-T focus on defining the problem scope and associated requirements BEFORE taking up any specific solution. c. Finally, in the IETF way of doing things it is perfectly acceptable for vendors or service providers to develop experimental implementations of the protocol(s) defined in Y.1711 and bring the results of this work back to the IETF. From owner-mpls@UU.NET Thu May 2 17:03:17 2002 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 RAA07405 for ; Thu, 2 May 2002 17:03:16 -0400 (EDT) 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 QQmnds15067; Thu, 2 May 2002 21:02:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnds01726 for mpls-outgoing; Thu, 2 May 2002 21:02:15 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 QQmnds01572 for ; Thu, 2 May 2002 21:02: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 QQmndr19403 for ; Thu, 2 May 2002 20:59:30 GMT Received: from dnsmx2pya.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32]) id QQmndr09731 for ; Thu, 2 May 2002 20:59:30 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id QAA22051 for ; Thu, 2 May 2002 16:51:28 -0400 (EDT) Subject: For ldp if loop detection is disabled must the LSR still check for loops? To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Michael W. Maszczak" Date: Thu, 2 May 2002 16:51:22 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 05/02/2002 04:51:29 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk LDP Clarifications needed: The ldp spec (rfc3036) appears to require the LSR to detect loops (send a loop detected Notification message) even if loop detection is disabled. If loop detection is enabled, the ldp spec (rfc3036) requires that the LSR include Hop Count and Path Vector TLVs in Label Request and Label Mapping messages, in addition to requiring that the LST to detect loops. Is this interpretation correct? If so than an LSR with loop detection disabled will always send a loop detected Notification message when it receives a Label Request that contains a Path Vector TLV with at least one LSRID. Mike From owner-mpls@UU.NET Fri May 3 13:22:24 2002 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 NAA20298 for ; Fri, 3 May 2002 13:22:24 -0400 (EDT) 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 QQmngm11427; Fri, 3 May 2002 15:10:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQmngm12844 for mpls-outgoing; Fri, 3 May 2002 15:10:01 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 QQmngm12822 for ; Fri, 3 May 2002 15:09:58 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 QQmngm21078 for ; Fri, 3 May 2002 15:09:44 GMT Received: from web11203.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11203.mail.yahoo.com [216.136.131.185]) id QQmngm18259 for ; Fri, 3 May 2002 15:09:43 GMT Message-ID: <20020503150943.2579.qmail@web11203.mail.yahoo.com> Received: from [216.191.227.34] by web11203.mail.yahoo.com via HTTP; Fri, 03 May 2002 11:09:43 EDT Date: Fri, 3 May 2002 11:09:43 -0400 (EDT) From: gary tam Subject: Static LSP Configuration To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk hi there, I want to check whether Cisco and others are supporting static LSP in their core router. If anyone has experience in configuring Static LSP with Cisco, Juniper, and Riverstone core routers, please give me a hand or point me to proper links. Thanks, Takumu ______________________________________________________________________ Games, Movies, Music & Sports! http://entertainment.yahoo.ca From owner-mpls@UU.NET Fri May 3 13:25:54 2002 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 NAA20378 for ; Fri, 3 May 2002 13:25:53 -0400 (EDT) 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 QQmngv29017; Fri, 3 May 2002 17:25:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmngv07554 for mpls-outgoing; Fri, 3 May 2002 17:24: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 QQmngv07549 for ; Fri, 3 May 2002 17:24: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 QQmngv03247 for ; Fri, 3 May 2002 17:24:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmngv27685 for ; Fri, 3 May 2002 17:24:02 GMT 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 NAA04431 for ; Fri, 3 May 2002 13:24:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA04807 for mpls@uu.net; Fri, 3 May 2002 13:24:02 -0400 (EDT) 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 QQmngv07495 for ; Fri, 3 May 2002 17:23:33 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 QQmngv26012 for ; Fri, 3 May 2002 17:23:27 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQmngv01858 for ; Fri, 3 May 2002 17:23:26 GMT Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA11962; Fri, 3 May 2002 13:23:25 -0400 (EDT) Date: Fri, 3 May 2002 13:23:25 -0400 (EDT) From: Ajay Simha To: gary tam cc: mpls@UU.NET Subject: Re: Static LSP Configuration In-Reply-To: <20020503150943.2579.qmail@web11203.mail.yahoo.com> Message-ID: References: <20020503150943.2579.qmail@web11203.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 3 May 2002, gary tam wrote: Wrong alias for these type of questions. I will answer you offline :) -ajay gt>hi there, gt> gt>I want to check whether Cisco and others are gt>supporting static LSP in their core router. If anyone gt>has experience in configuring Static LSP with Cisco, gt>Juniper, and Riverstone core routers, please give me a gt>hand or point me to proper links. gt> gt>Thanks, gt>Takumu gt> gt> gt>______________________________________________________________________ gt>Games, Movies, Music & Sports! http://entertainment.yahoo.ca gt> -- From owner-mpls@UU.NET Fri May 3 17:23:19 2002 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 RAA01371 for ; Fri, 3 May 2002 17:23:19 -0400 (EDT) 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 QQmnhl17770; Fri, 3 May 2002 21:21:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnhl24045 for mpls-outgoing; Fri, 3 May 2002 21:21: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 QQmnhl24040 for ; Fri, 3 May 2002 21:21:32 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 QQmnhl02012 for ; Fri, 3 May 2002 21:21:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnhl09381 for ; Fri, 3 May 2002 21:21:02 GMT 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 RAA26454 for ; Fri, 3 May 2002 17:21:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA00746 for mpls@uu.net; Fri, 3 May 2002 17:21:02 -0400 (EDT) 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 QQmnhl24000 for ; Fri, 3 May 2002 21:20:27 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 QQmnhl24384 for ; Fri, 3 May 2002 21:18:43 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 QQmnhl16666 for ; Fri, 3 May 2002 21:18:42 GMT Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g43LIff19321 for ; Fri, 3 May 2002 17:18:41 -0400 (EDT) Received: from lucent.com (mantegna.ho.lucent.com [135.17.34.61]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA28060; Fri, 3 May 2002 17:18:39 -0400 (EDT) Message-ID: <3CD2FEB0.CE978CA@lucent.com> Date: Fri, 03 May 2002 17:18:40 -0400 From: "Denis A. Khotimsky" Organization: Bell Labs -- Lucent Technologies, USA X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: CFP: IEEE Communications Magazine issue on IP-Oriented Quality of Service Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit [Our apologies if you receive multiple copies of this announcement] ======================================================================== CALL FOR PAPERS IEEE Communications Magazine Feature Topic on IP-Oriented Quality of Service (QoS) The "best effort" Internet delivery cannot be used for the new multimedia applications. New technologies and new standards are necessary to offer Quality of Service (QoS) for these multimedia applications. Therefore new communication architectures integrate mechanisms allowing to guarantee QoS services as well as high rate for the communications. This special issue of IEEE Communications Magazine seeks to survey and present the research and engineering work in QoS field. The focused tutorial and survey contributions are solicited on (but not restricted to) the following subject categories: * QoS in heterogeneous networks * QoS for wireless and mobile * QoS in WAN * QoS routing * Experiences with QoS * Simulation models for QoS * QoS and metrics * Charging and pricing for QoS * Platform support for QoS * Standardization and QoS Submission Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for clarity and grammatical accuracy, and will be copyedited according to the Magazine's style. Mathematical equations should not be used (in justified cases up to three simple equations could be allowed, provided the consent of the Guest Editor; more than three equations require permission from the Editor-in-Chief). Articles should have no more than 4,500 words, no more than 6 tables+figures, and no more than 15 references. Guidelines for prospective authors can be found on-line at http://www.comsoc.org/pubs/commag/sub_guidelines.html. Please send PDF (preferred), Microsoft Word, or PostScript formatted papers to oneof the guest editors no later than May 31, 2002. Accepted papers will also be included in Communications Interactive (CI), the online version of Communications Magazine. Manuscript Due 31 May 2002 Acceptance Notification 1 August 2002 Final Manuscript Due 15 September 2002 Publication Date December 2002 Guest Editors Pascal Lorenz Universite de Haute Alsace IUT de Colmar 34 rue du Grillenbreit - 68008 Colmar - FRANCE Phone: +33 3 89 20 23 66 Fax: +33 3 89 20 23 59 Email: lorenz@ieee.org Abbas Jamalipour School of Electrical and Information Engineering University of Sydney Sydney NSW 2006, Australia Phone: +61 2 9351 2843 Fax: +61 2 9351 3847 Email: a.jamalipour@ieee.org Denis Khotimsky Lucent Bell Labs 101 Crawfords Corner Road Holmdel, New Jersey 07733-3030 USA Phone: +1-732-949-9673 Fax: +1-732-949-5477 Email: dkhotimsky@lucent.com From owner-mpls@UU.NET Fri May 3 17:52:39 2002 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 RAA01819 for ; Fri, 3 May 2002 17:52:39 -0400 (EDT) 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 QQmnhn15601; Fri, 3 May 2002 21:51:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnhn26376 for mpls-outgoing; Fri, 3 May 2002 21:51:12 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 QQmnhn26371 for ; Fri, 3 May 2002 21:51:02 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 QQmnhn22063 for ; Fri, 3 May 2002 21:50:05 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnhn14060 for ; Fri, 3 May 2002 21:50:02 GMT 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 RAA27848 for ; Fri, 3 May 2002 17:50:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA03884 for mpls@uu.net; Fri, 3 May 2002 17:50:02 -0400 (EDT) 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 QQmnhn26307 for ; Fri, 3 May 2002 21:49:19 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 QQmnhn01021 for ; Fri, 3 May 2002 21:48:48 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmnhn12691 for ; Fri, 3 May 2002 21:48:47 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 RAA33580; Fri, 3 May 2002 17:48:42 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200205032148.RAA33580@workhorse.fictitious.org> To: gary tam cc: mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Static LSP Configuration In-reply-to: Your message of "Fri, 03 May 2002 11:09:43 EDT." <20020503150943.2579.qmail@web11203.mail.yahoo.com> Date: Fri, 03 May 2002 17:48:42 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20020503150943.2579.qmail@web11203.mail.yahoo.com>, gary tam writes : > hi there, > > I want to check whether Cisco and others are > supporting static LSP in their core router. If anyone > has experience in configuring Static LSP with Cisco, > Juniper, and Riverstone core routers, please give me a > hand or point me to proper links. > > Thanks, > Takumu Well ... yes and no. We stuck capability in to support explicit-path but since the departure of some wanna-be ISPs and change of mind of other wanna-be ISPs there seems to be no need for the feature as far as I can tell. No one that ever had a real network running has asked for this feature afaik. Two or three years ago we had wierd requests like inter-AS MPLS with explicit MPLS paths but those went away. We never had anything approaching a credible customer request for the really static MPLS where the user sets insegments and outsegments via CLI or SNMP. I think that was an imaginary need concocted by SNMP fanatics. Anyone have evidence to the contrary (an ISP or a router vendor with customers doing this in a production network)? Maybe there is some use of this in edge boxes. Static IP routes are common on customer premise LANs and in use at some ISP customer aggrigation routers so maybe static MPLS is used for some singly connected edge gadgets. That I don't know about. We do core, gateway and large aggregation, and not edge or CPE. Curtis From owner-mpls@UU.NET Fri May 3 23:11:39 2002 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 XAA08449 for ; Fri, 3 May 2002 23:11:39 -0400 (EDT) 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 QQmnii26975; Sat, 4 May 2002 03:10:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnii01869 for mpls-outgoing; Sat, 4 May 2002 03:10: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 QQmnii01814 for ; Sat, 4 May 2002 03:10:15 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 QQmnii23212 for ; Sat, 4 May 2002 03:08:56 GMT Received: from 21cn.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [61.140.60.248]) id QQmnii11434 for ; Sat, 4 May 2002 03:08:54 GMT Received: from 21cn.com([10.2.1.5]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm73cd3520c; Sat, 04 May 2002 11:10:16 +0800 Received: from cmr0.ash.ops.us.uu.net([198.5.241.38]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm73cceae6b; Tue, 30 Apr 2002 17:05:40 +0800 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 QQmmum03143; Tue, 30 Apr 2002 09:07:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmum13450 for mpls-outgoing; Tue, 30 Apr 2002 09:07: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 QQmmum13352 for ; Tue, 30 Apr 2002 09:06: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 QQmmum29775 for ; Tue, 30 Apr 2002 09:05:58 GMT Received: from tomp.smb.utfors.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQmmum01020 for ; Tue, 30 Apr 2002 09:05:57 GMT Received: from utfors.se ([172.20.0.78]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id GVDITN00.DZC for ; Tue, 30 Apr 2002 11:10:35 +0200 Message-ID: <3CCE5E74.9070207@utfors.se> Date: Tue, 30 Apr 2002 11:05:56 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mpls wg Subject: WG Last call - draft-ietf-mpls-bundle-mib-01.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by cmr0.ash.ops.us.uu.net id QQmmum03143 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA08449 This message initiates a two week WG last call on: Link Bundling Management Information Base With my liberal approach to weeks this last call ends May 15 at 2400 GMT. /Loa -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Sat May 4 09:58:11 2002 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 JAA24255 for ; Sat, 4 May 2002 09:58:11 -0400 (EDT) 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 QQmnjz18472; Sat, 4 May 2002 13:57:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnjz00689 for mpls-outgoing; Sat, 4 May 2002 13:56:56 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 QQmnjz00684 for ; Sat, 4 May 2002 13:56:55 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 QQmnjz08589 for ; Sat, 4 May 2002 13:56:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnjz17115 for ; Sat, 4 May 2002 13:56:02 GMT 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 JAA23178 for ; Sat, 4 May 2002 09:56:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA06072 for mpls@uu.net; Sat, 4 May 2002 09:56:02 -0400 (EDT) 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 QQmnjz00463 for ; Sat, 4 May 2002 13:55:03 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 QQmnjz24924 for ; Sat, 4 May 2002 13:53:33 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQmnjz05470 for ; Sat, 4 May 2002 13:53:33 GMT Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA03866; Sat, 4 May 2002 09:53:23 -0400 (EDT) Date: Sat, 4 May 2002 09:53:23 -0400 (EDT) From: Ajay Simha To: curtis@fictitious.org cc: gary tam , Subject: Re: Static LSP Configuration In-Reply-To: <200205032148.RAA33580@workhorse.fictitious.org> Message-ID: References: <200205032148.RAA33580@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 3 May 2002, Curtis Villamizar wrote: CV> CV>In message <20020503150943.2579.qmail@web11203.mail.yahoo.com>, gary tam writes CV>: CV>> hi there, CV>> CV>> I want to check whether Cisco and others are CV>> supporting static LSP in their core router. If anyone CV>> has experience in configuring Static LSP with Cisco, CV>> Juniper, and Riverstone core routers, please give me a CV>> hand or point me to proper links. CV>> CV>> Thanks, CV>> Takumu CV> CV> CV>Well ... yes and no. We stuck capability in to support explicit-path I don't know who the we in "We skuck.." is :) CV>but since the departure of some wanna-be ISPs and change of mind of CV>other wanna-be ISPs there seems to be no need for the feature as far CV>as I can tell. No one that ever had a real network running has asked CV>for this feature afaik. Two or three years ago we had wierd requests CV>like inter-AS MPLS with explicit MPLS paths but those went away. CV> CV>We never had anything approaching a credible customer request for the CV>really static MPLS where the user sets insegments and outsegments via CV>CLI or SNMP. I think that was an imaginary need concocted by SNMP CV>fanatics. Anyone have evidence to the contrary (an ISP or a router CV>vendor with customers doing this in a production network)? SNMP merely reflects what is out there or what may be out there via CLI. You cannot add new function with SNMP :) So the real question should be (relevant to this mailing list) - are static labels based LSPs an actual requirement - if so what percentage of the SPs actually want it and why. CV> CV>Maybe there is some use of this in edge boxes. Static IP routes are CV>common on customer premise LANs and in use at some ISP customer CV>aggrigation routers so maybe static MPLS is used for some singly CV>connected edge gadgets. That I don't know about. We do core, gateway CV>and large aggregation, and not edge or CPE. CV> CV>Curtis CV> -- From owner-mpls@UU.NET Sat May 4 14:01:06 2002 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 OAA27578 for ; Sat, 4 May 2002 14:01:06 -0400 (EDT) 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 QQmnkq15422; Sat, 4 May 2002 18:00:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnkp16580 for mpls-outgoing; Sat, 4 May 2002 17:59:56 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 QQmnkp16575 for ; Sat, 4 May 2002 17:59: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 QQmnkp13777 for ; Sat, 4 May 2002 17:59:04 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnkp13702 for ; Sat, 4 May 2002 17:59:03 GMT 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 NAA01001 for ; Sat, 4 May 2002 13:59:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA29324 for mpls@uu.net; Sat, 4 May 2002 13:59:02 -0400 (EDT) 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 QQmnkp16530 for ; Sat, 4 May 2002 17:58:16 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 QQmnkp11145 for ; Sat, 4 May 2002 17:57:54 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmnkp20425 for ; Sat, 4 May 2002 17:57:52 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 NAA37977; Sat, 4 May 2002 13:57:33 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200205041757.NAA37977@workhorse.fictitious.org> To: Ajay Simha cc: curtis@fictitious.org, gary tam , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Static LSP Configuration In-reply-to: Your message of "Sat, 04 May 2002 09:53:23 EDT." Date: Sat, 04 May 2002 13:57:33 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , Ajay Simha writes: > On Fri, 3 May 2002, Curtis Villamizar wrote: > > CV>Well ... yes and no. We stuck capability in to support explicit-path > > I don't know who the we in "We skuck.." is :) ^ stuck That's excusable (the spelling error is too). :) Since you didn't recognize the name -- former ANS person involved in T3-NSFNET work - former UUNET - now at Avici. fictitious.org is the DNS name of my home. Alta Vista sez - "We found 3,928 results" - its mostly junk, a few papers, presentation, RFCs. :) > CV>but since the departure of some wanna-be ISPs and change of mind of > CV>other wanna-be ISPs there seems to be no need for the feature as far > CV>as I can tell. No one that ever had a real network running has asked > CV>for this feature afaik. Two or three years ago we had wierd requests > CV>like inter-AS MPLS with explicit MPLS paths but those went away. > CV> > CV>We never had anything approaching a credible customer request for the > CV>really static MPLS where the user sets insegments and outsegments via > CV>CLI or SNMP. I think that was an imaginary need concocted by SNMP > CV>fanatics. Anyone have evidence to the contrary (an ISP or a router > CV>vendor with customers doing this in a production network)? > > SNMP merely reflects what is out there or what may be out there via CLI. You > cannot add new function with SNMP :) Thanks for stating the obvious. > So the real question should be (relevant to this mailing list) - are static > labels based LSPs an actual requirement - if so what percentage of the SPs > actually want it and why. Thanks for restating my question. Why don't you try answering it instead. Now its my turn to state the obvious and restate the question. The question was "Anyone have evidence to the contrary (an ISP or a router vendor with customers doing this in a production network)?". "This" in the former sentence is "the really static MPLS where the user sets insegments and outsegments via CLI or SNMP". I (someone at Avici involved in MPLS) have never personally seen such as request. Do you (someone at Cisco) know of an ISP doing this in a production network? If an ISP wants to speak up in favor of static LSPs (ones where the user sets insegments and outsegments via CLI or SNMP), then by all means do so. If not, at the very least, some SNMP read/write variables can be specified as read only. Not that it matters since most vendors support these as read-only and simply document it. Personally, I think these static LSPs are not useful (or their ATM equivalent, PVC - not SPVC), but I welcome comments to the contrary. Curtis From owner-mpls@UU.NET Sat May 4 15:11:04 2002 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 PAA28175 for ; Sat, 4 May 2002 15:11:03 -0400 (EDT) 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 QQmnku28348; Sat, 4 May 2002 19:10:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnku05067 for mpls-outgoing; Sat, 4 May 2002 19:09: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 QQmnku05040 for ; Sat, 4 May 2002 19:09:36 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 QQmnku03313 for ; Sat, 4 May 2002 19:09:32 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f227.law15.hotmail.com [64.4.23.227]) id QQmnku20853 for ; Sat, 4 May 2002 19:09:32 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 4 May 2002 12:09:31 -0700 Received: from 155.245.254.253 by lw15fd.law15.hotmail.msn.com with HTTP; Sat, 04 May 2002 19:09:31 GMT X-Originating-IP: [155.245.254.253] From: "Christopher Poh" To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Implicit Peering Date: Sat, 04 May 2002 19:09:31 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 May 2002 19:09:31.0371 (UTC) FILETIME=[3857C3B0:01C1F39F] Sender: owner-mpls@UU.NET Precedence: bulk Hello, I posted some questions about implicit peering sometime back, but it was ignored. Anyway, could anyone kind enough to provide me with links or literature about implicit peering to establish tunnels in MPLS, please? Thank you. Chris _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-mpls@UU.NET Sat May 4 15:19:30 2002 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 PAA28287 for ; Sat, 4 May 2002 15:19:29 -0400 (EDT) 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 QQmnkv10817; Sat, 4 May 2002 19:18:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnkv06915 for mpls-outgoing; Sat, 4 May 2002 19:18:24 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 QQmnkv06910 for ; Sat, 4 May 2002 19:18:17 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 QQmnkv03708 for ; Sat, 4 May 2002 19:18:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnkv03990 for ; Sat, 4 May 2002 19:18:04 GMT 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 PAA03283 for ; Sat, 4 May 2002 15:18:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA07423 for mpls@uu.net; Sat, 4 May 2002 15:18:02 -0400 (EDT) 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 QQmnkv06867 for ; Sat, 4 May 2002 19:16:56 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 QQmnku25781 for ; Sat, 4 May 2002 19:14:12 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQmnku28626 for ; Sat, 4 May 2002 19:14:12 GMT Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA06658; Sat, 4 May 2002 15:14:01 -0400 (EDT) Date: Sat, 4 May 2002 15:14:01 -0400 (EDT) From: Ajay Simha To: curtis@fictitious.org cc: gary tam , Subject: Re: Static LSP Configuration In-Reply-To: <200205041757.NAA37977@workhorse.fictitious.org> Message-ID: References: <200205041757.NAA37977@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Sat, 4 May 2002, Curtis Villamizar wrote: CV> CV>In message , Ajay CV>Simha writes: CV>> On Fri, 3 May 2002, Curtis Villamizar wrote: CV>> CV>> CV>Well ... yes and no. We stuck capability in to support explicit-path CV>> CV>> I don't know who the we in "We skuck.." is :) CV> ^ stuck CV> CV>That's excusable (the spelling error is too). :) Thanks for fixing it :) CV> CV>Since you didn't recognize the name -- former ANS person involved in CV>T3-NSFNET work - former UUNET - now at Avici. fictitious.org is the CV>DNS name of my home. Alta Vista sez - "We found 3,928 results" - its CV>mostly junk, a few papers, presentation, RFCs. :) Sorry for not recognizing the name - you are THE Curtis... Thousand appologies :) Now for the real issue... CV> CV>> CV>but since the departure of some wanna-be ISPs and change of mind of CV>> CV>other wanna-be ISPs there seems to be no need for the feature as far CV>> CV>as I can tell. No one that ever had a real network running has asked CV>> CV>for this feature afaik. Two or three years ago we had wierd requests CV>> CV>like inter-AS MPLS with explicit MPLS paths but those went away. CV>> CV> CV>> CV>We never had anything approaching a credible customer request for the CV>> CV>really static MPLS where the user sets insegments and outsegments via CV>> CV>CLI or SNMP. I think that was an imaginary need concocted by SNMP CV>> CV>fanatics. Anyone have evidence to the contrary (an ISP or a router CV>> CV>vendor with customers doing this in a production network)? CV>> CV>> SNMP merely reflects what is out there or what may be out there via CLI. You CV>> cannot add new function with SNMP :) CV> CV>Thanks for stating the obvious. CV> CV>> So the real question should be (relevant to this mailing list) - are static CV>> labels based LSPs an actual requirement - if so what percentage of the SPs CV>> actually want it and why. CV> CV>Thanks for restating my question. Why don't you try answering it CV>instead. I think static labels based LSPs will become a nightmare to manage in a production size network. I have had a few customers ask for it but without a really good reason. The only time it may actually be useful (IMHO) is an some InterAS VPNs where the two providers don't want to actually exchange label (whether one considers it safe or not). CV> CV>Now its my turn to state the obvious and restate the question. The CV>question was "Anyone have evidence to the contrary (an ISP or a router CV>vendor with customers doing this in a production network)?". "This" CV>in the former sentence is "the really static MPLS where the user sets CV>insegments and outsegments via CLI or SNMP". I (someone at Avici CV>involved in MPLS) have never personally seen such as request. Do you CV>(someone at Cisco) know of an ISP doing this in a production network? CV> CV>If an ISP wants to speak up in favor of static LSPs (ones where the CV>user sets insegments and outsegments via CLI or SNMP), then by all CV>means do so. If not, at the very least, some SNMP read/write CV>variables can be specified as read only. Not that it matters since CV>most vendors support these as read-only and simply document it. CV> CV>Personally, I think these static LSPs are not useful (or their ATM CV>equivalent, PVC - not SPVC), but I welcome comments to the contrary. I agree. -ajay CV> CV>Curtis CV> -- From owner-mpls@UU.NET Sat May 4 16:30:52 2002 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 QAA28935 for ; Sat, 4 May 2002 16:30:52 -0400 (EDT) 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 QQmnla13204; Sat, 4 May 2002 20:30:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnkz03982 for mpls-outgoing; Sat, 4 May 2002 20:29:47 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 QQmnkz03977 for ; Sat, 4 May 2002 20:29: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 QQmnkz06012 for ; Sat, 4 May 2002 20:29:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnkz20589 for ; Sat, 4 May 2002 20:29:02 GMT 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 QAA04245 for ; Sat, 4 May 2002 16:29:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA14601 for mpls@uu.net; Sat, 4 May 2002 16:29:02 -0400 (EDT) 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 QQmnkz03938 for ; Sat, 4 May 2002 20:28:09 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 QQmnkz02419 for ; Sat, 4 May 2002 20:27:53 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmnkz18692 for ; Sat, 4 May 2002 20:27:52 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 QAA38455; Sat, 4 May 2002 16:27:36 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200205042027.QAA38455@workhorse.fictitious.org> To: Ajay Simha cc: curtis@fictitious.org, gary tam , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Static LSP Configuration In-reply-to: Your message of "Sat, 04 May 2002 15:14:01 EDT." Date: Sat, 04 May 2002 16:27:36 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , Ajay Simha writes: > > I think static labels based LSPs will become a nightmare to manage in a > production size network. I have had a few customers ask for it but without a > really good reason. > > The only time it may actually be useful (IMHO) is an some InterAS VPNs where > the two providers don't want to actually exchange label (whether one consider > s > it safe or not). In the last case you mentioned here, there are clearly better ways to do this. I've also seen this same request and that was among the "wierd requests 2-3 years ago" that I think have gone away. I think that particular request is only slightly more alive than features needed for Enron's bandwidth brokering. Regardless of whether this is a credible customer request, there is a better way, LDP just works across AS and for TE use simple loose hops from the ingress. It will require some authentication at the inter-AS borders if this is interprovider and it would help to implement the AS hop type in RSVP. If we are talking about inter-AS within a provider, there is already someone doing that running MPLS/TE in each AS and LDP/VPN across AS inside TE and I'm confident they wouldn't consider static LSPs even for a moment, nor are they interested in doing a single TE hop through both AS. Plus each AS has IGP areas. btw- retorical question - with static LSPs, what happens when a link goes down? Curtis From owner-mpls@UU.NET Sat May 4 21:00:39 2002 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 VAA01361 for ; Sat, 4 May 2002 21:00:39 -0400 (EDT) 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 QQmnlr26453; Sun, 5 May 2002 00:59:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnlr22225 for mpls-outgoing; Sun, 5 May 2002 00:58:57 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 QQmnlr22217 for ; Sun, 5 May 2002 00:58: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 QQmnlr24582 for ; Sun, 5 May 2002 00:58:37 GMT Received: from mailsrv.coronanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [67.104.79.164]) id QQmnlr28941 for ; Sun, 5 May 2002 00:58:37 GMT Received: by mailsrv.coronanetworks.com with Internet Mail Service (5.5.2655.55) id ; Sat, 4 May 2002 18:03:15 -0700 Message-ID: From: Brijesh Kumar To: "'Curtis Villamizar '" , "'Ajay Simha '" Cc: "'curtis@fictitious.org '" , "'gary tam '" , "'mpls@UU.NET '" Subject: RE: Static LSP Configuration Date: Sat, 4 May 2002 18:03:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Curtis, I am kind of curious why won't you think that static LSP may be used as a tool for simple manual traffic engineering within a small portion of the network? Also, on your: >>btw- retorical question - with static LSPs, what happens when a link goes down? Should the expected behaviour need to be any different than when someone routes with static routes? Cheers, --brijesh -----Original Message----- From: Curtis Villamizar To: Ajay Simha Cc: curtis@fictitious.org; gary tam; mpls@UU.NET Sent: 04/05/02 1:27 PM Subject: Re: Static LSP Configuration In message , Ajay Simha writes: > > I think static labels based LSPs will become a nightmare to manage in a > production size network. I have had a few customers ask for it but without a > really good reason. > > The only time it may actually be useful (IMHO) is an some InterAS VPNs where > the two providers don't want to actually exchange label (whether one consider > s > it safe or not). In the last case you mentioned here, there are clearly better ways to do this. I've also seen this same request and that was among the "wierd requests 2-3 years ago" that I think have gone away. I think that particular request is only slightly more alive than features needed for Enron's bandwidth brokering. Regardless of whether this is a credible customer request, there is a better way, LDP just works across AS and for TE use simple loose hops from the ingress. It will require some authentication at the inter-AS borders if this is interprovider and it would help to implement the AS hop type in RSVP. If we are talking about inter-AS within a provider, there is already someone doing that running MPLS/TE in each AS and LDP/VPN across AS inside TE and I'm confident they wouldn't consider static LSPs even for a moment, nor are they interested in doing a single TE hop through both AS. Plus each AS has IGP areas. btw- retorical question - with static LSPs, what happens when a link goes down? Curtis From owner-mpls@UU.NET Sun May 5 11:28:08 2002 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 LAA20085 for ; Sun, 5 May 2002 11:28:08 -0400 (EDT) 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 QQmnnx01750; Sun, 5 May 2002 15:18:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnnx26443 for mpls-outgoing; Sun, 5 May 2002 15:18: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 QQmnnx26434 for ; Sun, 5 May 2002 15:18: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 QQmnnx04943 for ; Sun, 5 May 2002 15:16:04 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnnx27813 for ; Sun, 5 May 2002 15:16:02 GMT 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 LAA02048 for ; Sun, 5 May 2002 11:16:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA01614 for mpls@uu.net; Sun, 5 May 2002 11:16:01 -0400 (EDT) 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 QQmnnx26149 for ; Sun, 5 May 2002 15:15:10 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 QQmnnw00430 for ; Sun, 5 May 2002 15:14:38 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQmnnw29827 for ; Sun, 5 May 2002 15:14:38 GMT Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA16824; Sun, 5 May 2002 11:14:20 -0400 (EDT) Date: Sun, 5 May 2002 11:14:20 -0400 (EDT) From: Ajay Simha To: Brijesh Kumar cc: "'Curtis Villamizar '" , "'curtis@fictitious.org '" , "'gary tam '" , "'mpls@UU.NET '" Subject: RE: Static LSP Configuration In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Sat, 4 May 2002, Brijesh Kumar wrote: BK> BK>Curtis, BK> BK>I am kind of curious why won't you think that static LSP may be used as a BK>tool for simple manual traffic engineering within a small portion of the BK>network? Brijesh, This would work great in a lab environment where things don't change. In any production network, how are you going to keep track of which labels go which way? Why not build a network using static routes instead? Static label like static routes may lead to forwarding loops with the slightest misconfiguration. -ajay BK> BK>Also, on your: BK>>>btw- retorical question - with static LSPs, what happens when a link BK>goes down? BK> BK>Should the expected behaviour need to be any different than when someone BK>routes with static routes? BK> BK>Cheers, BK> BK>--brijesh BK> BK> BK> BK> BK> BK>-----Original Message----- BK>From: Curtis Villamizar BK>To: Ajay Simha BK>Cc: curtis@fictitious.org; gary tam; mpls@UU.NET BK>Sent: 04/05/02 1:27 PM BK>Subject: Re: Static LSP Configuration BK> BK> BK>In message BK>, Ajay BK> Simha writes: BK>> BK>> I think static labels based LSPs will become a nightmare to manage in BK>a BK>> production size network. I have had a few customers ask for it but BK>without a BK>> really good reason. BK>> BK>> The only time it may actually be useful (IMHO) is an some InterAS VPNs BK>where BK>> the two providers don't want to actually exchange label (whether one BK>consider BK>> s BK>> it safe or not). BK> BK> BK>In the last case you mentioned here, there are clearly better ways to BK>do this. I've also seen this same request and that was among the BK>"wierd requests 2-3 years ago" that I think have gone away. I think BK>that particular request is only slightly more alive than features BK>needed for Enron's bandwidth brokering. BK> BK>Regardless of whether this is a credible customer request, there is a BK>better way, LDP just works across AS and for TE use simple loose hops BK>from the ingress. It will require some authentication at the inter-AS BK>borders if this is interprovider and it would help to implement the AS BK>hop type in RSVP. If we are talking about inter-AS within a provider, BK>there is already someone doing that running MPLS/TE in each AS and BK>LDP/VPN across AS inside TE and I'm confident they wouldn't consider BK>static LSPs even for a moment, nor are they interested in doing a BK>single TE hop through both AS. Plus each AS has IGP areas. BK> BK>btw- retorical question - with static LSPs, what happens when a link BK>goes down? BK> BK>Curtis BK> -- From owner-mpls@UU.NET Sun May 5 11:59:42 2002 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 LAA20622 for ; Sun, 5 May 2002 11:59:42 -0400 (EDT) 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 QQmnnz22320; Sun, 5 May 2002 15:58:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnnz29297 for mpls-outgoing; Sun, 5 May 2002 15:58: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 QQmnnz29292 for ; Sun, 5 May 2002 15:58:44 GMT Received: from pmismtp05.wcomnet.com by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pmismtp05.wcomnet.com [166.38.62.53]) id QQmnnz12114 for ; Sun, 5 May 2002 15:56:56 GMT Received: from CONVERSION-DAEMON.pmismtp05.wcomnet.com by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) id <0GVN00701AK4W5@pmismtp05.wcomnet.com> for mpls@UU.NET; Sun, 05 May 2002 15:56:49 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GVN00901AYPC3@pmismtp05.wcomnet.com> for mpls@UU.NET; Sun, 05 May 2002 15:56:49 +0000 (GMT) Received: from rbonica ([166.60.19.105]) by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GVN00LTGAYMEO@pmismtp05.wcomnet.com>; Sun, 05 May 2002 15:56:49 +0000 (GMT) Date: Sun, 05 May 2002 11:49:04 -0400 From: Ron Bonica Subject: RE: Static LSP Configuration In-reply-to: To: Brijesh Kumar , "'Curtis Villamizar '" , "'Ajay Simha '" Cc: curtis@fictitious.org, "'gary tam '" , mpls@UU.NET Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > Also, on your: > >>btw- retorical question - with static LSPs, what happens when a link > goes down? > > Should the expected behaviour need to be any different than when someone > routes with static routes? > > Cheers, > > --brijesh > > Brijesh, Statically configured LSPs blackhole traffic when a link in the middle of the LSP fails. The LSR immediately upstream of the failure discards all traffic belonging to the LSP. This is because that LSR may not look beyond the MPLS label to forward the traffic. See RFC 3031 Sections 3.18 and 3.22 for details. Ron From owner-mpls@UU.NET Mon May 6 01:29:03 2002 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 BAA29832 for ; Mon, 6 May 2002 01:29:03 -0400 (EDT) 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 QQmnqb10089; Mon, 6 May 2002 05:27:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnqb08206 for mpls-outgoing; Mon, 6 May 2002 05:27:36 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 QQmnqb08201 for ; Mon, 6 May 2002 05:27:34 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 QQmnqb10890 for ; Mon, 6 May 2002 05:27:05 GMT From: neil.2.harrison@bt.com Received: from cbibipnt02.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmnqb09278 for ; Mon, 6 May 2002 05:27:04 GMT Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Mon, 6 May 2002 06:27:09 +0100 Message-ID: To: Ronald.P.Bonica@wcom.com Cc: mpls@UU.NET Subject: RE: Static LSP Configuration Date: Mon, 6 May 2002 06:26:58 +0100 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 > > Also, on your: > > >>btw- retorical question - with static LSPs, what happens > when a link > > goes down? > > > > Should the expected behaviour need to be any different > than when someone > > routes with static routes? > > > > Cheers, > > > > --brijesh > > > > > > Brijesh, > > Statically configured LSPs blackhole traffic when a link in > the middle of > the LSP fails. > > The LSR immediately upstream of the failure discards all > traffic belonging > to the LSP. This is because that LSR may not look beyond the > MPLS label to > forward the traffic. See RFC 3031 Sections 3.18 and 3.22 for details. > > Ron NH=> Ron, I agree discarding traffic is the only safe thing to do here. However, if you were running some form of connectivity verification from source/sink on the LSP that has failed you could at least detect this and take appropriate action....which could include invoking prot-sw. regards, Neil > From owner-mpls@UU.NET Mon May 6 09:20:42 2002 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 JAA17642 for ; Mon, 6 May 2002 09:20:41 -0400 (EDT) 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 QQmnrh25952; Mon, 6 May 2002 13:19:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnrh09820 for mpls-outgoing; Mon, 6 May 2002 13:19: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 QQmnrh09811 for ; Mon, 6 May 2002 13:19: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 QQmnrh28262 for ; Mon, 6 May 2002 13:19:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnrh29053 for ; Mon, 6 May 2002 13:18:54 GMT 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 JAA00794 for ; Mon, 6 May 2002 09:18:54 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA07058 for mpls@uu.net; Mon, 6 May 2002 09:18:54 -0400 (EDT) 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 QQmnog21012 for ; Sun, 5 May 2002 17:43:20 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 QQmnog12570 for ; Sun, 5 May 2002 17:42:41 GMT Received: from web12506.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web12506.mail.yahoo.com [216.136.173.198]) id QQmnog29025 for ; Sun, 5 May 2002 17:42:40 GMT Message-ID: <20020505174240.7233.qmail@web12506.mail.yahoo.com> Received: from [12.81.6.214] by web12506.mail.yahoo.com via HTTP; Sun, 05 May 2002 10:42:40 PDT Date: Sun, 5 May 2002 10:42:40 -0700 (PDT) From: Sukanta ganguly Subject: RE: Static LSP Configuration To: Ron Bonica , Brijesh Kumar , "'Curtis Villamizar '" , "'Ajay Simha '" Cc: curtis@fictitious.org, "'gary tam '" , mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk In a fairly controlled and static environment it may work, but in other situations it will create unresolved links and packet drops, with no recovery to the failure. SG --- Ron Bonica wrote: > > > > Also, on your: > > >>btw- retorical question - with static LSPs, what > happens when a link > > goes down? > > > > Should the expected behaviour need to be any > different than when someone > > routes with static routes? > > > > Cheers, > > > > --brijesh > > > > > > Brijesh, > > Statically configured LSPs blackhole traffic when a > link in the middle of > the LSP fails. > > The LSR immediately upstream of the failure discards > all traffic belonging > to the LSP. This is because that LSR may not look > beyond the MPLS label to > forward the traffic. See RFC 3031 Sections 3.18 and > 3.22 for details. > > > Ron > __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com From owner-mpls@UU.NET Mon May 6 09:37:13 2002 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 JAA18319 for ; Mon, 6 May 2002 09:37:13 -0400 (EDT) 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 QQmnri17855; Mon, 6 May 2002 13:36:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnri10875 for mpls-outgoing; Mon, 6 May 2002 13:35: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 QQmnri10861 for ; Mon, 6 May 2002 13:35:31 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 QQmnri06985 for ; Mon, 6 May 2002 13:34:11 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnri19307 for ; Mon, 6 May 2002 13:34:02 GMT 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 JAA01529 for ; Mon, 6 May 2002 09:34:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA09045 for mpls@uu.net; Mon, 6 May 2002 09:34:02 -0400 (EDT) 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 QQmnri10796 for ; Mon, 6 May 2002 13:32:59 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 QQmnri13373 for ; Mon, 6 May 2002 13:32:06 GMT Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmnri16559 for ; Mon, 6 May 2002 13:32:06 GMT Received: (qmail 13447 invoked by uid 104); 6 May 2002 13:31:50 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4201. . Clean. Processed in 0.435735 secs); 06 May 2002 13:31:50 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 6 May 2002 13:31:49 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g46DVkp13772; Mon, 6 May 2002 06:31:46 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 6 May 2002 06:31:44 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A782@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Sukanta ganguly'" , Ron Bonica , Brijesh Kumar , "'Curtis Villamizar '" , "'Ajay Simha '" Cc: curtis@fictitious.org, "'gary tam '" , mpls@UU.NET Subject: RE: Static LSP Configuration Date: Mon, 6 May 2002 06:31:41 -0700 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, If one wants to have only 2 LSPs (one working and one backup) in his network, why should he run LDP? -Shahram > -----Original Message----- > From: Sukanta ganguly [mailto:sganguly@yahoo.com] > Sent: Sunday, May 05, 2002 1:43 PM > To: Ron Bonica; Brijesh Kumar; 'Curtis Villamizar '; 'Ajay Simha ' > Cc: curtis@fictitious.org; 'gary tam '; mpls@UU.NET > Subject: RE: Static LSP Configuration > > > In a fairly controlled and static environment it may > work, but in other situations it will create > unresolved links and packet drops, with no recovery to > the failure. > > SG > > --- Ron Bonica wrote: > > > > > > Also, on your: > > > >>btw- retorical question - with static LSPs, what > > happens when a link > > > goes down? > > > > > > Should the expected behaviour need to be any > > different than when someone > > > routes with static routes? > > > > > > Cheers, > > > > > > --brijesh > > > > > > > > > > Brijesh, > > > > Statically configured LSPs blackhole traffic when a > > link in the middle of > > the LSP fails. > > > > The LSR immediately upstream of the failure discards > > all traffic belonging > > to the LSP. This is because that LSR may not look > > beyond the MPLS label to > > forward the traffic. See RFC 3031 Sections 3.18 and > > 3.22 for details. > > > > > > Ron > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - your guide to health and wellness > http://health.yahoo.com > From owner-mpls@UU.NET Mon May 6 09:59:57 2002 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 JAA19317 for ; Mon, 6 May 2002 09:59:57 -0400 (EDT) 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 QQmnrj23349; Mon, 6 May 2002 13:59:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnrj13060 for mpls-outgoing; Mon, 6 May 2002 13:58: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 QQmnrj13055 for ; Mon, 6 May 2002 13:58:26 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 QQmnrj24469 for ; Mon, 6 May 2002 13:58:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnrj21983 for ; Mon, 6 May 2002 13:58:02 GMT 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 JAA02833 for ; Mon, 6 May 2002 09:58:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA12418 for mpls@uu.net; Mon, 6 May 2002 09:58:01 -0400 (EDT) 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 QQmnrj13010 for ; Mon, 6 May 2002 13:56:52 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 QQmnrj29389 for ; Mon, 6 May 2002 13:56:19 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 QQmnrj15101 for ; Mon, 6 May 2002 13:56:18 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 g46Du6aC009836; Mon, 6 May 2002 09:56:08 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122]) by bucket.cisco.com (Mirapoint) with ESMTP id AAZ30650; Mon, 6 May 2002 09:55:39 -0400 (EDT) Message-Id: <4.3.2.7.2.20020506095524.023d3db8@bucket> X-Sender: tnadeau@bucket X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 May 2002 09:55:38 -0400 To: Shahram Davari From: "Thomas D. Nadeau" Subject: RE: Static LSP Configuration Cc: "'Sukanta ganguly'" , Ron Bonica , Brijesh Kumar , "'Curtis Villamizar '" , "'Ajay Simha '" , curtis@fictitious.org, "'gary tam '" , mpls@UU.NET In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE84A782@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >If one wants to have only 2 LSPs (one working and one backup) in his >network, why should >he run LDP? Because 2 LSPs is not a realistic example. --Tom >-Shahram > > > -----Original Message----- > > From: Sukanta ganguly [mailto:sganguly@yahoo.com] > > Sent: Sunday, May 05, 2002 1:43 PM > > To: Ron Bonica; Brijesh Kumar; 'Curtis Villamizar '; 'Ajay Simha ' > > Cc: curtis@fictitious.org; 'gary tam '; mpls@UU.NET > > Subject: RE: Static LSP Configuration > > > > > > In a fairly controlled and static environment it may > > work, but in other situations it will create > > unresolved links and packet drops, with no recovery to > > the failure. > > > > SG > > > > --- Ron Bonica wrote: > > > > > > > > Also, on your: > > > > >>btw- retorical question - with static LSPs, what > > > happens when a link > > > > goes down? > > > > > > > > Should the expected behaviour need to be any > > > different than when someone > > > > routes with static routes? > > > > > > > > Cheers, > > > > > > > > --brijesh > > > > > > > > > > > > > > Brijesh, > > > > > > Statically configured LSPs blackhole traffic when a > > > link in the middle of > > > the LSP fails. > > > > > > The LSR immediately upstream of the failure discards > > > all traffic belonging > > > to the LSP. This is because that LSR may not look > > > beyond the MPLS label to > > > forward the traffic. See RFC 3031 Sections 3.18 and > > > 3.22 for details. > > > > > > > > > Ron > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Health - your guide to health and wellness > > http://health.yahoo.com > > ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Mon May 6 10:01:22 2002 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 KAA19447 for ; Mon, 6 May 2002 10:01:22 -0400 (EDT) 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 QQmnrk21180; Mon, 6 May 2002 14:00:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnrk15398 for mpls-outgoing; Mon, 6 May 2002 14:00: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 QQmnrk15314 for ; Mon, 6 May 2002 14:00: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 QQmnrj27958 for ; Mon, 6 May 2002 13:59:51 GMT Received: from web11208.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11208.mail.yahoo.com [216.136.131.190]) id QQmnrj08596 for ; Mon, 6 May 2002 13:59:50 GMT Message-ID: <20020506135949.87793.qmail@web11208.mail.yahoo.com> Received: from [216.191.227.34] by web11208.mail.yahoo.com via HTTP; Mon, 06 May 2002 09:59:49 EDT Date: Mon, 6 May 2002 09:59:49 -0400 (EDT) From: Gary Tam Subject: RE: Static LSP Configuration To: Ron Bonica , Brijesh Kumar , "'Curtis Villamizar '" , "'Ajay Simha '" Cc: curtis@fictitious.org, "'gary tam '" , mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Thanks all, I think I get my answer that Cisco is not supporting static LSP configuration. Oh well, ... Don't you think static LSP will be useful for L2 VPN in stitching two access domains together. In most case, the L2 Access network does not have to support any of the complicated signaling procotocls, but still enjoy the benifit of utilizing MPLS. See the following example: (Access1) 1 - 2 (Core) 3 - 4 (Access2) In this example, the network operator needs only to setup the L2 FEC at ingress LSP, assign and maintain labels on 1,2,3,&4 as to setup the static LSP between the two access doamins and the core network. In the core network ( between port 2 and 3), it can be nested LSP trunking setup by CR-LDP/RSVP-TE. This will not change anything in case of failure between 2 and 3 with the obvious exception of port 2 and 3. The static LSP (1,2,3,4) will likely be Martini-encapsulated Tunnel for some L2 VLAN/MPLS VCs as well. The L2 FEC can be either MAC DA, VLAN, Coustomer ID, and ATM VC, etc. Gary --- Ron Bonica wrote: > > > > Also, on your: > > >>btw- retorical question - with static LSPs, what > happens when a link > > goes down? > > > > Should the expected behaviour need to be any > different than when someone > > routes with static routes? > > > > Cheers, > > > > --brijesh > > > > > > Brijesh, > > Statically configured LSPs blackhole traffic when a > link in the middle of > the LSP fails. > > The LSR immediately upstream of the failure discards > all traffic belonging > to the LSP. This is because that LSR may not look > beyond the MPLS label to > forward the traffic. See RFC 3031 Sections 3.18 and > 3.22 for details. > > > Ron > ______________________________________________________________________ Games, Movies, Music & Sports! http://entertainment.yahoo.ca From owner-mpls@UU.NET Mon May 6 10:28:50 2002 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 KAA21123 for ; Mon, 6 May 2002 10:28:49 -0400 (EDT) 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 QQmnrl27939; Mon, 6 May 2002 14:27:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnrl07513 for mpls-outgoing; Mon, 6 May 2002 14:27: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 QQmnrl07504 for ; Mon, 6 May 2002 14:27:12 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 QQmnrl07864 for ; Mon, 6 May 2002 14:27:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnrl02034 for ; Mon, 6 May 2002 14:27:02 GMT 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 KAA04792 for ; Mon, 6 May 2002 10:27:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA15860 for mpls@uu.net; Mon, 6 May 2002 10:27:01 -0400 (EDT) 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 QQmnrl07463 for ; Mon, 6 May 2002 14:26:16 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 QQmnrl18557 for ; Mon, 6 May 2002 14:25:48 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 QQmnrl25290 for ; Mon, 6 May 2002 14:25:48 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 g46EQD2p013055; Mon, 6 May 2002 10:26:13 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122]) by bucket.cisco.com (Mirapoint) with ESMTP id AAZ31239; Mon, 6 May 2002 10:25:46 -0400 (EDT) Message-Id: <4.3.2.7.2.20020506102458.02485ab0@bucket> X-Sender: tnadeau@bucket X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 May 2002 10:25:45 -0400 To: Gary Tam From: "Thomas D. Nadeau" Subject: RE: Static LSP Configuration Cc: mpls@UU.NET In-Reply-To: <20020506135949.87793.qmail@web11208.mail.yahoo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Gary, FYI, this mailing list is not for discussion of vendor- specific issues. Please keep that offline or on mplsops. --Tom >I think I get my answer that Cisco is not supporting >static LSP configuration. > >Oh well, ... > >Don't you think static LSP will be useful for L2 VPN >in stitching two access domains together. In most >case, the L2 Access network does not have to support >any of the complicated signaling procotocls, but still >enjoy the benifit of utilizing MPLS. See the following >example: > > (Access1) 1 - 2 (Core) 3 - 4 (Access2) > >In this example, the network operator needs only to >setup the L2 FEC at ingress LSP, assign and maintain >labels on 1,2,3,&4 as to setup the static LSP between >the two access doamins and the core network. > >In the core network ( between port 2 and 3), it can be >nested LSP trunking setup by CR-LDP/RSVP-TE. This will >not change anything in case of failure between 2 and 3 >with the obvious exception of port 2 and 3. > >The static LSP (1,2,3,4) will likely be >Martini-encapsulated Tunnel for some L2 VLAN/MPLS VCs >as well. The L2 FEC can be either MAC DA, VLAN, >Coustomer ID, and ATM VC, etc. > >Gary > > >--- Ron Bonica wrote: > > > > > > Also, on your: > > > >>btw- retorical question - with static LSPs, what > > happens when a link > > > goes down? > > > > > > Should the expected behaviour need to be any > > different than when someone > > > routes with static routes? > > > > > > Cheers, > > > > > > --brijesh > > > > > > > > > > Brijesh, > > > > Statically configured LSPs blackhole traffic when a > > link in the middle of > > the LSP fails. > > > > The LSR immediately upstream of the failure discards > > all traffic belonging > > to the LSP. This is because that LSR may not look > > beyond the MPLS label to > > forward the traffic. See RFC 3031 Sections 3.18 and > > 3.22 for details. > > > > > > Ron > > > > >______________________________________________________________________ >Games, Movies, Music & Sports! http://entertainment.yahoo.ca ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Mon May 6 10:49:44 2002 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 KAA21998 for ; Mon, 6 May 2002 10:49:44 -0400 (EDT) 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 QQmnrn27523; Mon, 6 May 2002 14:49:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnrn09432 for mpls-outgoing; Mon, 6 May 2002 14:48:43 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 QQmnrn09425 for ; Mon, 6 May 2002 14:48:41 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 QQmnrn15505 for ; Mon, 6 May 2002 14:48:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnrn29951 for ; Mon, 6 May 2002 14:48:02 GMT 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 KAA07603 for ; Mon, 6 May 2002 10:48:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA18282 for mpls@uu.net; Mon, 6 May 2002 10:48:02 -0400 (EDT) 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 QQmnrn09308 for ; Mon, 6 May 2002 14:46: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 QQmnrn05541 for ; Mon, 6 May 2002 14:46:26 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmnrn27802 for ; Mon, 6 May 2002 14:46:24 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 KAA45971; Mon, 6 May 2002 10:46:06 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200205061446.KAA45971@workhorse.fictitious.org> To: Gary Tam cc: Ron Bonica , Brijesh Kumar , "'Curtis Villamizar '" , "'Ajay Simha '" , curtis@fictitious.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Static LSP Configuration In-reply-to: Your message of "Mon, 06 May 2002 09:59:49 EDT." <20020506135949.87793.qmail@web11208.mail.yahoo.com> Date: Mon, 06 May 2002 10:46:06 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20020506135949.87793.qmail@web11208.mail.yahoo.com>, Gary Tam write s: > > In the core network ( between port 2 and 3), it can be > nested LSP trunking setup by CR-LDP/RSVP-TE. This will > not change anything in case of failure between 2 and 3 > with the obvious exception of port 2 and 3. > > The static LSP (1,2,3,4) will likely be > Martini-encapsulated Tunnel for some L2 VLAN/MPLS VCs > as well. The L2 FEC can be either MAC DA, VLAN, > Coustomer ID, and ATM VC, etc. > > Gary Gary, I didn't think I was going to have to answer my own retorical question "what happens with static LSPs if a link goes down". If any link fails you're sunk. You could in principle create a second static LSP (a static standby) but with no signaling there is no way to tell the ingress to use it. Even with a prmary and standby (regardless of whether the primary and/or standby are static or dynamic), occassionally multiple faults occur for which SRLGs do not cover the possibility and where it would be prohibitively expensive to do so. A examples examples from my experience are power outage in Manhattan during generator maintenance (famous for taking the FAA network down), Amtrak train wreck in NJ (famous for nearly taking out NYC due to damaged fiber on both sides of the track), hurricane brushing NC and VA causing damage and flooding (famous for taking out MAE-E connectivity to Europe during an IETF), extensive flooding in US midwest, earthquake in San Diego, Raritan River bridge failure in NJ, gas main leak in LA forcing CO to cut power, exploding rat in SF power transfer switch, and the list goes on and on. You can't write SRLGs to cover this. The only viable solution is to dynamically route. Some providers talk about using an explicit-path specified at the ingress with a dynamically routed backup (disjoint and either pre-signaled or just pre-computed, or dynamically rerouted after failure). This does not use static insegments and outsegments, it uses singaled LSPs with configured paths. Even talk of this approach (explicit primary path) is becoming more rare because when failure occurs and when optimal layout is most needed it often makes sense to allow primaries were not broken by the fault to pick alternate less congested paths. second retorical question - Why don't IP providers build their backbones out of static routes? I'm hope we don't get any responses. Curtis From owner-mpls@UU.NET Mon May 6 11:23:03 2002 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 LAA23565 for ; Mon, 6 May 2002 11:23:03 -0400 (EDT) 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 QQmnrp20143; Mon, 6 May 2002 15:22:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnrp04022 for mpls-outgoing; Mon, 6 May 2002 15:21: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 QQmnrp04017 for ; Mon, 6 May 2002 15:21:32 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 QQmnrp17249 for ; Mon, 6 May 2002 15:20:59 GMT Received: from web11205.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11205.mail.yahoo.com [216.136.131.187]) id QQmnrp18305 for ; Mon, 6 May 2002 15:20:58 GMT Message-ID: <20020506152057.64359.qmail@web11205.mail.yahoo.com> Received: from [216.191.227.34] by web11205.mail.yahoo.com via HTTP; Mon, 06 May 2002 11:20:57 EDT Date: Mon, 6 May 2002 11:20:57 -0400 (EDT) From: Gary Tam Subject: Re: Static LSP Configuration To: curtis@fictitious.org Cc: Ron Bonica , Brijesh Kumar , "'Curtis Villamizar '" , "'Ajay Simha '" , curtis@fictitious.org, mpls@UU.NET In-Reply-To: <200205061446.KAA45971@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Curtis, You have some good points. I agree with you that dynamic signaling is good and essential. But for protection, you do not have to have dynamic signaling protocol. You need 2 disjointed LSPs, and a fast fault detection / propagation mechanism (could be an OAM control flow or other means for the targeted DA). In this case, when there is a link/fiber cut, the failure can be detected at where the fault occurs and be propagated to where the switch takes place. In terms of global/segmented protection, the local-node detects the failure instantly and propagates failure condition to the targeted DA of the switch node. The switch-node performs the switch-over activity as soon as it gets the switch-over message. In the entire proceess, there is no dynamic signaling here. Besides, it will be too slow and costly to do protection with RSVP-signaling - ie 50ms protection. Even if you scale the RSVP/LDP Hello intervals to 5ms, there are lots of issues such as link flapping, lots of hellos. etc. In the Access domain, ie 802.1Q, VLAN/SVLAN is widely used for data forwarding and customer data separation. There is no urgent need for an Ethernet network to implement RSVP-TE or CR-LDP. So static LSP-Stitching will be a cheap and inexpensive solution for L2 VPN. Gary --- Curtis Villamizar wrote: > > In message > <20020506135949.87793.qmail@web11208.mail.yahoo.com>, > Gary Tam write > s: > > > > In the core network ( between port 2 and 3), it > can be > > nested LSP trunking setup by CR-LDP/RSVP-TE. This > will > > not change anything in case of failure between 2 > and 3 > > with the obvious exception of port 2 and 3. > > > > The static LSP (1,2,3,4) will likely be > > Martini-encapsulated Tunnel for some L2 VLAN/MPLS > VCs > > as well. The L2 FEC can be either MAC DA, VLAN, > > Coustomer ID, and ATM VC, etc. > > > > Gary > > > Gary, > > I didn't think I was going to have to answer my own > retorical question > "what happens with static LSPs if a link goes down". > If any link > fails you're sunk. You could in principle create a > second static LSP > (a static standby) but with no signaling there is no > way to tell the > ingress to use it. > > Even with a prmary and standby (regardless of > whether the primary > and/or standby are static or dynamic), occassionally > multiple faults > occur for which SRLGs do not cover the possibility > and where it would > be prohibitively expensive to do so. A examples > examples from my > experience are power outage in Manhattan during > generator maintenance > (famous for taking the FAA network down), Amtrak > train wreck in NJ > (famous for nearly taking out NYC due to damaged > fiber on both sides > of the track), hurricane brushing NC and VA causing > damage and > flooding (famous for taking out MAE-E connectivity > to Europe during an > IETF), extensive flooding in US midwest, earthquake > in San Diego, > Raritan River bridge failure in NJ, gas main leak in > LA forcing CO to > cut power, exploding rat in SF power transfer > switch, and the list > goes on and on. You can't write SRLGs to cover > this. The only viable > solution is to dynamically route. > > Some providers talk about using an explicit-path > specified at the > ingress with a dynamically routed backup (disjoint > and either > pre-signaled or just pre-computed, or dynamically > rerouted after > failure). This does not use static insegments and > outsegments, it > uses singaled LSPs with configured paths. Even talk > of this approach > (explicit primary path) is becoming more rare > because when failure > occurs and when optimal layout is most needed it > often makes sense to > allow primaries were not broken by the fault to pick > alternate less > congested paths. > > second retorical question - Why don't IP providers > build their > backbones out of static routes? I'm hope we don't > get any don't know why they don't do that IP static routes > would seem like a > really great idea> responses. > > Curtis ______________________________________________________________________ Games, Movies, Music & Sports! http://entertainment.yahoo.ca From owner-mpls@UU.NET Mon May 6 11:32:38 2002 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 LAA23810 for ; Mon, 6 May 2002 11:32:37 -0400 (EDT) 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 QQmnrq05719; Mon, 6 May 2002 15:31:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnrq04790 for mpls-outgoing; Mon, 6 May 2002 15:31: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 QQmnrq04782 for ; Mon, 6 May 2002 15:30: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 QQmnrq23468 for ; Mon, 6 May 2002 15:30:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnrq03622 for ; Mon, 6 May 2002 15:30:03 GMT 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 LAA11808 for ; Mon, 6 May 2002 11:30:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA22987 for mpls@uu.net; Mon, 6 May 2002 11:30:02 -0400 (EDT) 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 QQmnrp04704 for ; Mon, 6 May 2002 15:29:04 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 QQmnrp07319 for ; Mon, 6 May 2002 15:28:24 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQmnrp21561 for ; Mon, 6 May 2002 15:28:24 GMT Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA05145; Mon, 6 May 2002 11:28:09 -0400 (EDT) Date: Mon, 6 May 2002 11:28:09 -0400 (EDT) From: Ajay Simha To: Gary Tam cc: curtis@fictitious.org, Ron Bonica , Brijesh Kumar , "'Curtis Villamizar '" , Subject: Re: Static LSP Configuration In-Reply-To: <20020506152057.64359.qmail@web11205.mail.yahoo.com> Message-ID: References: <20020506152057.64359.qmail@web11205.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Mon, 6 May 2002, Gary Tam wrote: GT>Hi Curtis, GT> GT>You have some good points. I agree with you that GT>dynamic signaling is good and essential. GT> GT>But for protection, you do not have to have dynamic GT>signaling protocol. You need 2 disjointed LSPs, and a GT>fast fault detection / propagation mechanism (could be GT>an OAM control flow or other means for the targeted GT>DA). In this case, when there is a link/fiber cut, the GT>failure can be detected at where the fault occurs and GT>be propagated to where the switch takes place. In GT>terms of global/segmented protection, the local-node GT>detects the failure instantly and propagates failure GT>condition to the targeted DA of the switch node. The GT>switch-node performs the switch-over activity as soon GT>as it gets the switch-over message. In the entire GT>proceess, there is no dynamic signaling here. Besides, GT>it will be too slow and costly to do protection with GT>RSVP-signaling - ie 50ms protection. Even if you scale Not true. GT>the RSVP/LDP Hello intervals to 5ms, there are lots of GT>issues such as link flapping, lots of hellos. etc. GT> You could use sonet alarms for detection. Any how would OAM control flow solve any lost pkts? -ajay GT>In the Access domain, ie 802.1Q, VLAN/SVLAN is widely GT>used for data forwarding and customer data separation. GT>There is no urgent need for an Ethernet network to GT>implement RSVP-TE or CR-LDP. So static LSP-Stitching GT>will be a cheap and inexpensive solution for L2 VPN. GT> GT>Gary GT> GT> GT>--- Curtis Villamizar GT> wrote: GT>> GT>> In message GT>> GT><20020506135949.87793.qmail@web11208.mail.yahoo.com>, GT>> Gary Tam write GT>> s: GT>> > GT>> > In the core network ( between port 2 and 3), it GT>> can be GT>> > nested LSP trunking setup by CR-LDP/RSVP-TE. This GT>> will GT>> > not change anything in case of failure between 2 GT>> and 3 GT>> > with the obvious exception of port 2 and 3. GT>> > GT>> > The static LSP (1,2,3,4) will likely be GT>> > Martini-encapsulated Tunnel for some L2 VLAN/MPLS GT>> VCs GT>> > as well. The L2 FEC can be either MAC DA, VLAN, GT>> > Coustomer ID, and ATM VC, etc. GT>> > GT>> > Gary GT>> GT>> GT>> Gary, GT>> GT>> I didn't think I was going to have to answer my own GT>> retorical question GT>> "what happens with static LSPs if a link goes down". GT>> If any link GT>> fails you're sunk. You could in principle create a GT>> second static LSP GT>> (a static standby) but with no signaling there is no GT>> way to tell the GT>> ingress to use it. GT>> GT>> Even with a prmary and standby (regardless of GT>> whether the primary GT>> and/or standby are static or dynamic), occassionally GT>> multiple faults GT>> occur for which SRLGs do not cover the possibility GT>> and where it would GT>> be prohibitively expensive to do so. A examples GT>> examples from my GT>> experience are power outage in Manhattan during GT>> generator maintenance GT>> (famous for taking the FAA network down), Amtrak GT>> train wreck in NJ GT>> (famous for nearly taking out NYC due to damaged GT>> fiber on both sides GT>> of the track), hurricane brushing NC and VA causing GT>> damage and GT>> flooding (famous for taking out MAE-E connectivity GT>> to Europe during an GT>> IETF), extensive flooding in US midwest, earthquake GT>> in San Diego, GT>> Raritan River bridge failure in NJ, gas main leak in GT>> LA forcing CO to GT>> cut power, exploding rat in SF power transfer GT>> switch, and the list GT>> goes on and on. You can't write SRLGs to cover GT>> this. The only viable GT>> solution is to dynamically route. GT>> GT>> Some providers talk about using an explicit-path GT>> specified at the GT>> ingress with a dynamically routed backup (disjoint GT>> and either GT>> pre-signaled or just pre-computed, or dynamically GT>> rerouted after GT>> failure). This does not use static insegments and GT>> outsegments, it GT>> uses singaled LSPs with configured paths. Even talk GT>> of this approach GT>> (explicit primary path) is becoming more rare GT>> because when failure GT>> occurs and when optimal layout is most needed it GT>> often makes sense to GT>> allow primaries were not broken by the fault to pick GT>> alternate less GT>> congested paths. GT>> GT>> second retorical question - Why don't IP providers GT>> build their GT>> backbones out of static routes? I'm hope we don't GT>> get any > don't know why they don't do that IP static routes GT>> would seem like a GT>> really great idea> responses. GT>> GT>> Curtis GT> GT> GT>______________________________________________________________________ GT>Games, Movies, Music & Sports! http://entertainment.yahoo.ca GT> -- From owner-mpls@UU.NET Mon May 6 11:43:59 2002 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 LAA24228 for ; Mon, 6 May 2002 11:43:59 -0400 (EDT) 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 QQmnrq16940; Mon, 6 May 2002 15:43:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnrq05743 for mpls-outgoing; Mon, 6 May 2002 15:42:56 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 QQmnrq05738 for ; Mon, 6 May 2002 15:42:49 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 QQmnrq21630 for ; Mon, 6 May 2002 15:42:19 GMT Received: from web11207.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11207.mail.yahoo.com [216.136.131.189]) id QQmnrq06912 for ; Mon, 6 May 2002 15:42:18 GMT Message-ID: <20020506154218.58140.qmail@web11207.mail.yahoo.com> Received: from [216.191.227.34] by web11207.mail.yahoo.com via HTTP; Mon, 06 May 2002 11:42:18 EDT Date: Mon, 6 May 2002 11:42:18 -0400 (EDT) From: Gary Tam Subject: Re: Static LSP Configuration To: Ajay Simha Cc: curtis@fictitious.org, Ron Bonica , Brijesh Kumar , "'Curtis Villamizar '" , mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk yes, you can rely on the Physical Optical driver to monitor the incoming signal/power level, and/or synchornization (using PLL/CDR). But without a fast propagation mechanism, you cannot archieve sub 50ms global protection. I do not see how you can do it with RSVP or LDP over 5-10 hop path. --- Ajay Simha wrote: > On Mon, 6 May 2002, Gary Tam wrote: > > GT>Hi Curtis, > GT> > GT>You have some good points. I agree with you that > GT>dynamic signaling is good and essential. > GT> > GT>But for protection, you do not have to have > dynamic > GT>signaling protocol. You need 2 disjointed LSPs, > and a > GT>fast fault detection / propagation mechanism > (could be > GT>an OAM control flow or other means for the > targeted > GT>DA). In this case, when there is a link/fiber > cut, the > GT>failure can be detected at where the fault occurs > and > GT>be propagated to where the switch takes place. In > GT>terms of global/segmented protection, the > local-node > GT>detects the failure instantly and propagates > failure > GT>condition to the targeted DA of the switch node. > The > GT>switch-node performs the switch-over activity as > soon > GT>as it gets the switch-over message. In the entire > GT>proceess, there is no dynamic signaling here. > Besides, > GT>it will be too slow and costly to do protection > with > GT>RSVP-signaling - ie 50ms protection. Even if you > scale > > Not true. > GT>the RSVP/LDP Hello intervals to 5ms, there are > lots of > GT>issues such as link flapping, lots of hellos. > etc. > GT> > > You could use sonet alarms for detection. Any how > would OAM control flow > solve any lost pkts? > > -ajay > GT>In the Access domain, ie 802.1Q, VLAN/SVLAN is > widely > GT>used for data forwarding and customer data > separation. > GT>There is no urgent need for an Ethernet network > to > GT>implement RSVP-TE or CR-LDP. So static > LSP-Stitching > GT>will be a cheap and inexpensive solution for L2 > VPN. > GT> > GT>Gary > GT> > GT> > GT>--- Curtis Villamizar > GT> wrote: > GT>> > GT>> In message > GT>> > GT><20020506135949.87793.qmail@web11208.mail.yahoo.com>, > GT>> Gary Tam write > GT>> s: > GT>> > > GT>> > In the core network ( between port 2 and 3), > it > GT>> can be > GT>> > nested LSP trunking setup by CR-LDP/RSVP-TE. > This > GT>> will > GT>> > not change anything in case of failure > between 2 > GT>> and 3 > GT>> > with the obvious exception of port 2 and 3. > GT>> > > GT>> > The static LSP (1,2,3,4) will likely be > GT>> > Martini-encapsulated Tunnel for some L2 > VLAN/MPLS > GT>> VCs > GT>> > as well. The L2 FEC can be either MAC DA, > VLAN, > GT>> > Coustomer ID, and ATM VC, etc. > GT>> > > GT>> > Gary > GT>> > GT>> > GT>> Gary, > GT>> > GT>> I didn't think I was going to have to answer my > own > GT>> retorical question > GT>> "what happens with static LSPs if a link goes > down". > GT>> If any link > GT>> fails you're sunk. You could in principle > create a > GT>> second static LSP > GT>> (a static standby) but with no signaling there > is no > GT>> way to tell the > GT>> ingress to use it. > GT>> > GT>> Even with a prmary and standby (regardless of > GT>> whether the primary > GT>> and/or standby are static or dynamic), > occassionally > GT>> multiple faults > GT>> occur for which SRLGs do not cover the > possibility > GT>> and where it would > GT>> be prohibitively expensive to do so. A > examples > GT>> examples from my > GT>> experience are power outage in Manhattan during > GT>> generator maintenance > GT>> (famous for taking the FAA network down), > Amtrak > GT>> train wreck in NJ > GT>> (famous for nearly taking out NYC due to > damaged > GT>> fiber on both sides > GT>> of the track), hurricane brushing NC and VA > causing > GT>> damage and > GT>> flooding (famous for taking out MAE-E > connectivity > GT>> to Europe during an > GT>> IETF), extensive flooding in US midwest, > earthquake > GT>> in San Diego, > GT>> Raritan River bridge failure in NJ, gas main > leak in > GT>> LA forcing CO to > GT>> cut power, exploding rat in SF power transfer > GT>> switch, and the list > GT>> goes on and on. You can't write SRLGs to cover > GT>> this. The only viable > GT>> solution is to dynamically route. > GT>> > GT>> Some providers talk about using an > explicit-path > GT>> specified at the > GT>> ingress with a dynamically routed backup > (disjoint > GT>> and either > GT>> pre-signaled or just pre-computed, or > dynamically > GT>> rerouted after > GT>> failure). This does not use static insegments > and > GT>> outsegments, it > GT>> uses singaled LSPs with configured paths. Even > talk > GT>> of this approach > GT>> (explicit primary path) is becoming more rare > GT>> because when failure > GT>> occurs and when optimal layout is most needed > it > GT>> often makes sense to > GT>> allow primaries were not broken by the fault to > pick > GT>> alternate less > GT>> congested paths. > GT>> > GT>> second retorical question - Why don't IP > providers > GT>> build their > GT>> backbones out of static routes? I'm hope we > don't > GT>> get any GT>> don't know why they don't do that IP static > routes > GT>> would seem like a > GT>> really great idea> responses. > GT>> > GT>> Curtis > GT> > GT> > GT>______________________________________________________________________ > GT>Games, Movies, Music & Sports! > http://entertainment.yahoo.ca > GT> > > -- > ______________________________________________________________________ Games, Movies, Music & Sports! http://entertainment.yahoo.ca From owner-mpls@UU.NET Mon May 6 11:52:50 2002 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 LAA24433 for ; Mon, 6 May 2002 11:52:50 -0400 (EDT) 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 QQmnrr16655; Mon, 6 May 2002 15:51:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnrr06631 for mpls-outgoing; Mon, 6 May 2002 15:51:15 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 QQmnrr06626 for ; Mon, 6 May 2002 15:51: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 QQmnrr26978 for ; Mon, 6 May 2002 15:50:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnrr03102 for ; Mon, 6 May 2002 15:50:01 GMT 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 LAA13362 for ; Mon, 6 May 2002 11:50:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA25550 for mpls@uu.net; Mon, 6 May 2002 11:50:01 -0400 (EDT) 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 QQmnrr06508 for ; Mon, 6 May 2002 15:48: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 QQmnrr20116 for ; Mon, 6 May 2002 15:48:03 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQmnrr12879 for ; Mon, 6 May 2002 15:48:03 GMT Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA05895; Mon, 6 May 2002 11:47:48 -0400 (EDT) Date: Mon, 6 May 2002 11:47:48 -0400 (EDT) From: Ajay Simha To: Gary Tam cc: curtis@fictitious.org, Ron Bonica , Brijesh Kumar , "'Curtis Villamizar '" , Subject: Re: Static LSP Configuration In-Reply-To: <20020506154218.58140.qmail@web11207.mail.yahoo.com> Message-ID: References: <20020506154218.58140.qmail@web11207.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Mon, 6 May 2002, Gary Tam wrote: GT>yes, you can rely on the Physical Optical driver to GT>monitor the incoming signal/power level, and/or GT>synchornization (using PLL/CDR). But without a fast GT>propagation mechanism, you cannot archieve sub 50ms GT>global protection. I do not see how you can do it with GT>RSVP or LDP over 5-10 hop path. One could argue that with Global protection the number of LSPs that you'd have in the network increases so much so that static LSPs would no longer be an option. With Local Protection as specified in draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt draft you can achieve ~ 50ms protection. Also RSVP hellos are link-local. -ajay GT> GT>--- Ajay Simha wrote: GT>> On Mon, 6 May 2002, Gary Tam wrote: GT>> GT>> GT>Hi Curtis, GT>> GT> GT>> GT>You have some good points. I agree with you that GT>> GT>dynamic signaling is good and essential. GT>> GT> GT>> GT>But for protection, you do not have to have GT>> dynamic GT>> GT>signaling protocol. You need 2 disjointed LSPs, GT>> and a GT>> GT>fast fault detection / propagation mechanism GT>> (could be GT>> GT>an OAM control flow or other means for the GT>> targeted GT>> GT>DA). In this case, when there is a link/fiber GT>> cut, the GT>> GT>failure can be detected at where the fault occurs GT>> and GT>> GT>be propagated to where the switch takes place. In GT>> GT>terms of global/segmented protection, the GT>> local-node GT>> GT>detects the failure instantly and propagates GT>> failure GT>> GT>condition to the targeted DA of the switch node. GT>> The GT>> GT>switch-node performs the switch-over activity as GT>> soon GT>> GT>as it gets the switch-over message. In the entire GT>> GT>proceess, there is no dynamic signaling here. GT>> Besides, GT>> GT>it will be too slow and costly to do protection GT>> with GT>> GT>RSVP-signaling - ie 50ms protection. Even if you GT>> scale GT>> GT>> Not true. GT>> GT>the RSVP/LDP Hello intervals to 5ms, there are GT>> lots of GT>> GT>issues such as link flapping, lots of hellos. GT>> etc. GT>> GT> GT>> GT>> You could use sonet alarms for detection. Any how GT>> would OAM control flow GT>> solve any lost pkts? GT>> GT>> -ajay GT>> GT>In the Access domain, ie 802.1Q, VLAN/SVLAN is GT>> widely GT>> GT>used for data forwarding and customer data GT>> separation. GT>> GT>There is no urgent need for an Ethernet network GT>> to GT>> GT>implement RSVP-TE or CR-LDP. So static GT>> LSP-Stitching GT>> GT>will be a cheap and inexpensive solution for L2 GT>> VPN. GT>> GT> GT>> GT>Gary GT>> GT> GT>> GT> GT>> GT>--- Curtis Villamizar GT>> GT> wrote: GT>> GT>> GT>> GT>> In message GT>> GT>> GT>> GT>GT><20020506135949.87793.qmail@web11208.mail.yahoo.com>, GT>> GT>> Gary Tam write GT>> GT>> s: GT>> GT>> > GT>> GT>> > In the core network ( between port 2 and 3), GT>> it GT>> GT>> can be GT>> GT>> > nested LSP trunking setup by CR-LDP/RSVP-TE. GT>> This GT>> GT>> will GT>> GT>> > not change anything in case of failure GT>> between 2 GT>> GT>> and 3 GT>> GT>> > with the obvious exception of port 2 and 3. GT>> GT>> > GT>> GT>> > The static LSP (1,2,3,4) will likely be GT>> GT>> > Martini-encapsulated Tunnel for some L2 GT>> VLAN/MPLS GT>> GT>> VCs GT>> GT>> > as well. The L2 FEC can be either MAC DA, GT>> VLAN, GT>> GT>> > Coustomer ID, and ATM VC, etc. GT>> GT>> > GT>> GT>> > Gary GT>> GT>> GT>> GT>> GT>> GT>> Gary, GT>> GT>> GT>> GT>> I didn't think I was going to have to answer my GT>> own GT>> GT>> retorical question GT>> GT>> "what happens with static LSPs if a link goes GT>> down". GT>> GT>> If any link GT>> GT>> fails you're sunk. You could in principle GT>> create a GT>> GT>> second static LSP GT>> GT>> (a static standby) but with no signaling there GT>> is no GT>> GT>> way to tell the GT>> GT>> ingress to use it. GT>> GT>> GT>> GT>> Even with a prmary and standby (regardless of GT>> GT>> whether the primary GT>> GT>> and/or standby are static or dynamic), GT>> occassionally GT>> GT>> multiple faults GT>> GT>> occur for which SRLGs do not cover the GT>> possibility GT>> GT>> and where it would GT>> GT>> be prohibitively expensive to do so. A GT>> examples GT>> GT>> examples from my GT>> GT>> experience are power outage in Manhattan during GT>> GT>> generator maintenance GT>> GT>> (famous for taking the FAA network down), GT>> Amtrak GT>> GT>> train wreck in NJ GT>> GT>> (famous for nearly taking out NYC due to GT>> damaged GT>> GT>> fiber on both sides GT>> GT>> of the track), hurricane brushing NC and VA GT>> causing GT>> GT>> damage and GT>> GT>> flooding (famous for taking out MAE-E GT>> connectivity GT>> GT>> to Europe during an GT>> GT>> IETF), extensive flooding in US midwest, GT>> earthquake GT>> GT>> in San Diego, GT>> GT>> Raritan River bridge failure in NJ, gas main GT>> leak in GT>> GT>> LA forcing CO to GT>> GT>> cut power, exploding rat in SF power transfer GT>> GT>> switch, and the list GT>> GT>> goes on and on. You can't write SRLGs to cover GT>> GT>> this. The only viable GT>> GT>> solution is to dynamically route. GT>> GT>> GT>> GT>> Some providers talk about using an GT>> explicit-path GT>> GT>> specified at the GT>> GT>> ingress with a dynamically routed backup GT>> (disjoint GT>> GT>> and either GT>> GT>> pre-signaled or just pre-computed, or GT>> dynamically GT>> GT>> rerouted after GT>> GT>> failure). This does not use static insegments GT>> and GT>> GT>> outsegments, it GT>> GT>> uses singaled LSPs with configured paths. Even GT>> talk GT>> GT>> of this approach GT>> GT>> (explicit primary path) is becoming more rare GT>> GT>> because when failure GT>> GT>> occurs and when optimal layout is most needed GT>> it GT>> GT>> often makes sense to GT>> GT>> allow primaries were not broken by the fault to GT>> pick GT>> GT>> alternate less GT>> GT>> congested paths. GT>> GT>> GT>> GT>> second retorical question - Why don't IP GT>> providers GT>> GT>> build their GT>> GT>> backbones out of static routes? I'm hope we GT>> don't GT>> GT>> get any > GT>> don't know why they don't do that IP static GT>> routes GT>> GT>> would seem like a GT>> GT>> really great idea> responses. GT>> GT>> GT>> GT>> Curtis GT>> GT> GT>> GT> GT>> GT>GT>______________________________________________________________________ GT>> GT>Games, Movies, Music & Sports! GT>> http://entertainment.yahoo.ca GT>> GT> GT>> GT>> -- GT>> GT> GT> GT>______________________________________________________________________ GT>Games, Movies, Music & Sports! http://entertainment.yahoo.ca GT> -- From owner-mpls@UU.NET Mon May 6 12:02:15 2002 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 MAA24749 for ; Mon, 6 May 2002 12:02:15 -0400 (EDT) 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 QQmnrr23170; Mon, 6 May 2002 15:57:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnrr07115 for mpls-outgoing; Mon, 6 May 2002 15:56:48 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 QQmnrr07110 for ; Mon, 6 May 2002 15:56:43 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 QQmnrr15067 for ; Mon, 6 May 2002 15:56:08 GMT Received: from web11202.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11202.mail.yahoo.com [216.136.131.184]) id QQmnrr04220 for ; Mon, 6 May 2002 15:56:08 GMT Message-ID: <20020506155605.14542.qmail@web11202.mail.yahoo.com> Received: from [216.191.227.34] by web11202.mail.yahoo.com via HTTP; Mon, 06 May 2002 11:56:05 EDT Date: Mon, 6 May 2002 11:56:05 -0400 (EDT) From: Gary Tam Subject: Re: Static LSP Configuration To: Ajay Simha Cc: curtis@fictitious.org, Ron Bonica , Brijesh Kumar , "'Curtis Villamizar '" , mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Actually in the example I was given previously, there were always four hops in the path: (Access1) P1 - P2 (core) P3 - P4 (Access2) primarly In this case, so you can --- Ajay Simha wrote: > On Mon, 6 May 2002, Gary Tam wrote: > > GT>yes, you can rely on the Physical Optical driver > to > GT>monitor the incoming signal/power level, and/or > GT>synchornization (using PLL/CDR). But without a > fast > GT>propagation mechanism, you cannot archieve sub > 50ms > GT>global protection. I do not see how you can do it > with > GT>RSVP or LDP over 5-10 hop path. > > One could argue that with Global protection the > number of LSPs that you'd have > in the network increases so much so that static LSPs > would no longer be an > option. > > With Local Protection as specified in > draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt draft > you can achieve ~ 50ms > protection. > > Also RSVP hellos are link-local. > > -ajay > GT> > GT>--- Ajay Simha wrote: > GT>> On Mon, 6 May 2002, Gary Tam wrote: > GT>> > GT>> GT>Hi Curtis, > GT>> GT> > GT>> GT>You have some good points. I agree with you > that > GT>> GT>dynamic signaling is good and essential. > GT>> GT> > GT>> GT>But for protection, you do not have to have > GT>> dynamic > GT>> GT>signaling protocol. You need 2 disjointed > LSPs, > GT>> and a > GT>> GT>fast fault detection / propagation mechanism > GT>> (could be > GT>> GT>an OAM control flow or other means for the > GT>> targeted > GT>> GT>DA). In this case, when there is a > link/fiber > GT>> cut, the > GT>> GT>failure can be detected at where the fault > occurs > GT>> and > GT>> GT>be propagated to where the switch takes > place. In > GT>> GT>terms of global/segmented protection, the > GT>> local-node > GT>> GT>detects the failure instantly and propagates > GT>> failure > GT>> GT>condition to the targeted DA of the switch > node. > GT>> The > GT>> GT>switch-node performs the switch-over > activity as > GT>> soon > GT>> GT>as it gets the switch-over message. In the > entire > GT>> GT>proceess, there is no dynamic signaling > here. > GT>> Besides, > GT>> GT>it will be too slow and costly to do > protection > GT>> with > GT>> GT>RSVP-signaling - ie 50ms protection. Even if > you > GT>> scale > GT>> > GT>> Not true. > GT>> GT>the RSVP/LDP Hello intervals to 5ms, there > are > GT>> lots of > GT>> GT>issues such as link flapping, lots of > hellos. > GT>> etc. > GT>> GT> > GT>> > GT>> You could use sonet alarms for detection. Any > how > GT>> would OAM control flow > GT>> solve any lost pkts? > GT>> > GT>> -ajay > GT>> GT>In the Access domain, ie 802.1Q, VLAN/SVLAN > is > GT>> widely > GT>> GT>used for data forwarding and customer data > GT>> separation. > GT>> GT>There is no urgent need for an Ethernet > network > GT>> to > GT>> GT>implement RSVP-TE or CR-LDP. So static > GT>> LSP-Stitching > GT>> GT>will be a cheap and inexpensive solution for > L2 > GT>> VPN. > GT>> GT> > GT>> GT>Gary > GT>> GT> > GT>> GT> > GT>> GT>--- Curtis Villamizar > GT>> GT> wrote: > GT>> GT>> > GT>> GT>> In message > GT>> GT>> > GT>> > GT>GT><20020506135949.87793.qmail@web11208.mail.yahoo.com>, > GT>> GT>> Gary Tam write > GT>> GT>> s: > GT>> GT>> > > GT>> GT>> > In the core network ( between port 2 and > 3), > GT>> it > GT>> GT>> can be > GT>> GT>> > nested LSP trunking setup by > CR-LDP/RSVP-TE. > GT>> This > GT>> GT>> will > GT>> GT>> > not change anything in case of failure > GT>> between 2 > GT>> GT>> and 3 > GT>> GT>> > with the obvious exception of port 2 and > 3. > GT>> GT>> > > GT>> GT>> > The static LSP (1,2,3,4) will likely be > GT>> GT>> > Martini-encapsulated Tunnel for some L2 > GT>> VLAN/MPLS > GT>> GT>> VCs > GT>> GT>> > as well. The L2 FEC can be either MAC > DA, > GT>> VLAN, > GT>> GT>> > Coustomer ID, and ATM VC, etc. > GT>> GT>> > > GT>> GT>> > Gary > GT>> GT>> > GT>> GT>> > GT>> GT>> Gary, > GT>> GT>> > GT>> GT>> I didn't think I was going to have to > answer my > GT>> own > GT>> GT>> retorical question > GT>> GT>> "what happens with static LSPs if a link > goes > GT>> down". > GT>> GT>> If any link > GT>> GT>> fails you're sunk. You could in principle > GT>> create a > GT>> GT>> second static LSP > GT>> GT>> (a static standby) but with no signaling > there > GT>> is no > GT>> GT>> way to tell the > GT>> GT>> ingress to use it. > GT>> GT>> > GT>> GT>> Even with a prmary and standby (regardless > of > GT>> GT>> whether the primary > GT>> GT>> and/or standby are static or dynamic), > GT>> occassionally > GT>> GT>> multiple faults > GT>> GT>> occur for which SRLGs do not cover the > GT>> possibility > GT>> GT>> and where it would > GT>> GT>> be prohibitively expensive to do so. A > GT>> examples > GT>> GT>> examples from my > GT>> GT>> experience are power outage in Manhattan > during > GT>> GT>> generator maintenance > GT>> GT>> (famous for taking the FAA network down), > GT>> Amtrak > GT>> GT>> train wreck in NJ > GT>> GT>> (famous for nearly taking out NYC due to > GT>> damaged > GT>> GT>> fiber on both sides > GT>> GT>> of the track), hurricane brushing NC and > VA > GT>> causing > GT>> GT>> damage and > GT>> GT>> flooding (famous for taking out MAE-E > GT>> connectivity > GT>> GT>> to Europe during an > GT>> GT>> IETF), extensive flooding in US midwest, > GT>> earthquake > GT>> GT>> in San Diego, > GT>> GT>> Raritan River bridge failure in NJ, gas > main > GT>> leak in > GT>> GT>> LA forcing CO to > GT>> GT>> cut power, exploding rat in SF power > transfer > GT>> GT>> switch, and the list > === message truncated === ______________________________________________________________________ Games, Movies, Music & Sports! http://entertainment.yahoo.ca From owner-mpls@UU.NET Mon May 6 12:06:56 2002 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 MAA24912 for ; Mon, 6 May 2002 12:06:56 -0400 (EDT) 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 QQmnrs25159; Mon, 6 May 2002 16:05:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnrs19593 for mpls-outgoing; Mon, 6 May 2002 16:05: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 QQmnrs19476 for ; Mon, 6 May 2002 16:05:09 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 QQmnrs02381 for ; Mon, 6 May 2002 16:05:04 GMT Received: from web11201.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11201.mail.yahoo.com [216.136.131.171]) id QQmnrs03230 for ; Mon, 6 May 2002 16:05:04 GMT Message-ID: <20020506160500.54009.qmail@web11201.mail.yahoo.com> Received: from [216.191.227.34] by web11201.mail.yahoo.com via HTTP; Mon, 06 May 2002 12:05:00 EDT Date: Mon, 6 May 2002 12:05:00 -0400 (EDT) From: Gary Tam Subject: Re: Static LSP Configuration To: Ajay Simha Cc: curtis@fictitious.org, Ron Bonica , Brijesh Kumar , "'Curtis Villamizar '" , mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Actually in the example I was given previously, there were always four hops in the path: (Access1) P1 - P2 (core) P3 - P4 (Access2) primarly (Access1) P1 - P2'(core) P3'- P4 (Access2) backup1 or (Access1) P1'- P2'(core) P3'- P4 (Access2) backup2 In this case, MPLS is just as an aggregation technology and static LSP is not that bad. Note: in the core, it is signaled nested trunk LSP between P2-P3 or P2'-P3'. --- Ajay Simha wrote: > On Mon, 6 May 2002, Gary Tam wrote: > > GT>yes, you can rely on the Physical Optical driver > to > GT>monitor the incoming signal/power level, and/or > GT>synchornization (using PLL/CDR). But without a > fast > GT>propagation mechanism, you cannot archieve sub > 50ms > GT>global protection. I do not see how you can do it > with > GT>RSVP or LDP over 5-10 hop path. > > One could argue that with Global protection the > number of LSPs that you'd have > in the network increases so much so that static LSPs > would no longer be an > option. > > With Local Protection as specified in > draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt draft > you can achieve ~ 50ms > protection. > > Also RSVP hellos are link-local. > > -ajay > GT> > GT>--- Ajay Simha wrote: > GT>> On Mon, 6 May 2002, Gary Tam wrote: > GT>> > GT>> GT>Hi Curtis, > GT>> GT> > GT>> GT>You have some good points. I agree with you > that > GT>> GT>dynamic signaling is good and essential. > GT>> GT> > GT>> GT>But for protection, you do not have to have > GT>> dynamic > GT>> GT>signaling protocol. You need 2 disjointed > LSPs, > GT>> and a > GT>> GT>fast fault detection / propagation mechanism > GT>> (could be > GT>> GT>an OAM control flow or other means for the > GT>> targeted > GT>> GT>DA). In this case, when there is a > link/fiber > GT>> cut, the > GT>> GT>failure can be detected at where the fault > occurs > GT>> and > GT>> GT>be propagated to where the switch takes > place. In > GT>> GT>terms of global/segmented protection, the > GT>> local-node > GT>> GT>detects the failure instantly and propagates > GT>> failure > GT>> GT>condition to the targeted DA of the switch > node. > GT>> The > GT>> GT>switch-node performs the switch-over > activity as > GT>> soon > GT>> GT>as it gets the switch-over message. In the > entire > GT>> GT>proceess, there is no dynamic signaling > here. > GT>> Besides, > GT>> GT>it will be too slow and costly to do > protection > GT>> with > GT>> GT>RSVP-signaling - ie 50ms protection. Even if > you > GT>> scale > GT>> > GT>> Not true. > GT>> GT>the RSVP/LDP Hello intervals to 5ms, there > are > GT>> lots of > GT>> GT>issues such as link flapping, lots of > hellos. > GT>> etc. > GT>> GT> > GT>> > GT>> You could use sonet alarms for detection. Any > how > GT>> would OAM control flow > GT>> solve any lost pkts? > GT>> > GT>> -ajay > GT>> GT>In the Access domain, ie 802.1Q, VLAN/SVLAN > is > GT>> widely > GT>> GT>used for data forwarding and customer data > GT>> separation. > GT>> GT>There is no urgent need for an Ethernet > network > GT>> to > GT>> GT>implement RSVP-TE or CR-LDP. So static > GT>> LSP-Stitching > GT>> GT>will be a cheap and inexpensive solution for > L2 > GT>> VPN. > GT>> GT> > GT>> GT>Gary > GT>> GT> > GT>> GT> > GT>> GT>--- Curtis Villamizar > GT>> GT> wrote: > GT>> GT>> > GT>> GT>> In message > GT>> GT>> > GT>> > GT>GT><20020506135949.87793.qmail@web11208.mail.yahoo.com>, > GT>> GT>> Gary Tam write > GT>> GT>> s: > GT>> GT>> > > GT>> GT>> > In the core network ( between port 2 and > 3), > GT>> it > GT>> GT>> can be > GT>> GT>> > nested LSP trunking setup by > CR-LDP/RSVP-TE. > GT>> This > GT>> GT>> will > GT>> GT>> > not change anything in case of failure > GT>> between 2 > GT>> GT>> and 3 > GT>> GT>> > with the obvious exception of port 2 and > 3. > GT>> GT>> > > GT>> GT>> > The static LSP (1,2,3,4) will likely be > GT>> GT>> > Martini-encapsulated Tunnel for some L2 > GT>> VLAN/MPLS > GT>> GT>> VCs > GT>> GT>> > as well. The L2 FEC can be either MAC > DA, > GT>> VLAN, > GT>> GT>> > Coustomer ID, and ATM VC, etc. > GT>> GT>> > > GT>> GT>> > Gary > GT>> GT>> > GT>> GT>> > GT>> GT>> Gary, > GT>> GT>> > GT>> GT>> I didn't think I was going to have to > answer my > GT>> own > GT>> GT>> retorical question > GT>> GT>> "what happens with static LSPs if a link > goes > GT>> down". > GT>> GT>> If any link > GT>> GT>> fails you're sunk. You could in principle > GT>> create a > GT>> GT>> second static LSP > GT>> GT>> (a static standby) but with no signaling > there > GT>> is no > GT>> GT>> way to tell the > GT>> GT>> ingress to use it. > GT>> GT>> > GT>> GT>> Even with a prmary and standby (regardless > of > GT>> GT>> whether the primary > GT>> GT>> and/or standby are static or dynamic), > GT>> occassionally > GT>> GT>> multiple faults > GT>> GT>> occur for which SRLGs do not cover the > GT>> possibility > GT>> GT>> and where it would > GT>> GT>> be prohibitively expensive to do so. A > GT>> examples > GT>> GT>> examples from my > GT>> GT>> experience are power outage in Manhattan > during > GT>> GT>> generator maintenance > GT>> GT>> (famous for taking the FAA network down), > GT>> Amtrak > GT>> GT>> train wreck in NJ > GT>> GT>> (famous for nearly taking out NYC due to > GT>> damaged > GT>> GT>> fiber on both sides > GT>> GT>> of the track), hurricane brushing NC and > VA > GT>> causing > GT>> GT>> damage and > GT>> GT>> flooding (famous for taking out MAE-E > GT>> connectivity > GT>> GT>> to Europe during an > GT>> GT>> IETF), extensive flooding in US midwest, > GT>> earthquake > GT>> GT>> in San Diego, > GT>> GT>> Raritan River bridge failure in NJ, gas > main > GT>> leak in > GT>> GT>> LA forcing CO to > GT>> GT>> cut power, exploding rat in SF power > transfer > GT>> GT>> switch, and the list > === message truncated === ______________________________________________________________________ Games, Movies, Music & Sports! http://entertainment.yahoo.ca From owner-mpls@UU.NET Mon May 6 12:06:58 2002 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 MAA24925 for ; Mon, 6 May 2002 12:06:58 -0400 (EDT) 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 QQmnrs04484; Mon, 6 May 2002 16:06:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnrs19954 for mpls-outgoing; Mon, 6 May 2002 16:05:39 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 QQmnrs19935 for ; Mon, 6 May 2002 16:05:37 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 QQmnrs28878 for ; Mon, 6 May 2002 16:03:57 GMT Received: from hoemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQmnrs14705 for ; Mon, 6 May 2002 16:03:57 GMT Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g46G3uk23613 for ; Mon, 6 May 2002 12:03:56 -0400 (EDT) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 May 2002 12:03:56 -0400 Message-ID: <4490F7068AC0D111A7120008C72878EC0EB6E278@nj7460exch003u.ho.lucent.com> From: "Nagarajan, Ramesh (Ramesh)" To: curtis@fictitious.org, "'Gary Tam'" Cc: Ron Bonica , Brijesh Kumar , "'Curtis Villamizar '" , "'Ajay Simha '" , curtis@fictitious.org, mpls@UU.NET Subject: RE: Static LSP Configuration Date: Mon, 6 May 2002 12:03:45 -0400 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 Gary, I agree with you about being able to do restoration witthout dynamic signaling. Also, agree with curtis on his points on multiple failures and need for signaling (instead of painful manual reestablishment of static LSPs) there. In particular, see proposal below for restoration which does not require failure detection (and any other signaling including failure notification, LSP switching etc.,) for many L1 and L2 layer failures: http://www.ietf.org/internet-drafts/draft-nagarajan-ccamp-mpls-packet-protec tion-00.txt ramesh. ---------------------------------------------------------------------------- -------------------------------------------------- Room 3M-335, Bell labs Tel: 732-949-2761 101 Crawfords Corner Road Fax: 732-834-5906 Holmdel, NJ 07733. e-mail: rameshn@lucent.com. ---------------------------------------------------------------------------- --------------------------------------------------- > ---------- > From: Gary Tam[SMTP:hukulumu@yahoo.ca] > Sent: Monday, May 06, 2002 11:20 AM > To: curtis@fictitious.org > Cc: Ron Bonica; Brijesh Kumar; 'Curtis Villamizar '; 'Ajay Simha '; > curtis@fictitious.org; mpls@UU.NET > Subject: Re: Static LSP Configuration > > Hi Curtis, > > You have some good points. I agree with you that > dynamic signaling is good and essential. > > But for protection, you do not have to have dynamic > signaling protocol. You need 2 disjointed LSPs, and a > fast fault detection / propagation mechanism (could be > an OAM control flow or other means for the targeted > DA). In this case, when there is a link/fiber cut, the > failure can be detected at where the fault occurs and > be propagated to where the switch takes place. In > terms of global/segmented protection, the local-node > detects the failure instantly and propagates failure > condition to the targeted DA of the switch node. The > switch-node performs the switch-over activity as soon > as it gets the switch-over message. In the entire > proceess, there is no dynamic signaling here. Besides, > it will be too slow and costly to do protection with > RSVP-signaling - ie 50ms protection. Even if you scale > the RSVP/LDP Hello intervals to 5ms, there are lots of > issues such as link flapping, lots of hellos. etc. > > In the Access domain, ie 802.1Q, VLAN/SVLAN is widely > used for data forwarding and customer data separation. > There is no urgent need for an Ethernet network to > implement RSVP-TE or CR-LDP. So static LSP-Stitching > will be a cheap and inexpensive solution for L2 VPN. > > Gary > > > --- Curtis Villamizar > wrote: > > > > In message > > > <20020506135949.87793.qmail@web11208.mail.yahoo.com>, > > Gary Tam write > > s: > > > > > > In the core network ( between port 2 and 3), it > > can be > > > nested LSP trunking setup by CR-LDP/RSVP-TE. This > > will > > > not change anything in case of failure between 2 > > and 3 > > > with the obvious exception of port 2 and 3. > > > > > > The static LSP (1,2,3,4) will likely be > > > Martini-encapsulated Tunnel for some L2 VLAN/MPLS > > VCs > > > as well. The L2 FEC can be either MAC DA, VLAN, > > > Coustomer ID, and ATM VC, etc. > > > > > > Gary > > > > > > Gary, > > > > I didn't think I was going to have to answer my own > > retorical question > > "what happens with static LSPs if a link goes down". > > If any link > > fails you're sunk. You could in principle create a > > second static LSP > > (a static standby) but with no signaling there is no > > way to tell the > > ingress to use it. > > > > Even with a prmary and standby (regardless of > > whether the primary > > and/or standby are static or dynamic), occassionally > > multiple faults > > occur for which SRLGs do not cover the possibility > > and where it would > > be prohibitively expensive to do so. A examples > > examples from my > > experience are power outage in Manhattan during > > generator maintenance > > (famous for taking the FAA network down), Amtrak > > train wreck in NJ > > (famous for nearly taking out NYC due to damaged > > fiber on both sides > > of the track), hurricane brushing NC and VA causing > > damage and > > flooding (famous for taking out MAE-E connectivity > > to Europe during an > > IETF), extensive flooding in US midwest, earthquake > > in San Diego, > > Raritan River bridge failure in NJ, gas main leak in > > LA forcing CO to > > cut power, exploding rat in SF power transfer > > switch, and the list > > goes on and on. You can't write SRLGs to cover > > this. The only viable > > solution is to dynamically route. > > > > Some providers talk about using an explicit-path > > specified at the > > ingress with a dynamically routed backup (disjoint > > and either > > pre-signaled or just pre-computed, or dynamically > > rerouted after > > failure). This does not use static insegments and > > outsegments, it > > uses singaled LSPs with configured paths. Even talk > > of this approach > > (explicit primary path) is becoming more rare > > because when failure > > occurs and when optimal layout is most needed it > > often makes sense to > > allow primaries were not broken by the fault to pick > > alternate less > > congested paths. > > > > second retorical question - Why don't IP providers > > build their > > backbones out of static routes? I'm hope we don't > > get any > don't know why they don't do that IP static routes > > would seem like a > > really great idea> responses. > > > > Curtis > > > ______________________________________________________________________ > Games, Movies, Music & Sports! http://entertainment.yahoo.ca > From owner-mpls@UU.NET Mon May 6 13:42:12 2002 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 NAA29286 for ; Mon, 6 May 2002 13:42:11 -0400 (EDT) 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 QQmnry12095; Mon, 6 May 2002 17:41:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnry29367 for mpls-outgoing; Mon, 6 May 2002 17:40: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 QQmnry29362 for ; Mon, 6 May 2002 17:40:44 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 QQmnry13874 for ; Mon, 6 May 2002 17:40:04 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnry04340 for ; Mon, 6 May 2002 17:40:03 GMT 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 NAA20304 for ; Mon, 6 May 2002 13:40:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA07479 for mpls@uu.net; Mon, 6 May 2002 13:40:02 -0400 (EDT) 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 QQmnry29201 for ; Mon, 6 May 2002 17:38: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 QQmnry06780 for ; Mon, 6 May 2002 17:38:47 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 QQmnry03547 for ; Mon, 6 May 2002 17:38:47 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 g46HdAUX003793; Mon, 6 May 2002 13:39:11 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122]) by bucket.cisco.com (Mirapoint) with ESMTP id AAZ35048; Mon, 6 May 2002 13:38:43 -0400 (EDT) Message-Id: <4.3.2.7.2.20020506131507.024b8d68@bucket> X-Sender: tnadeau@bucket X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 May 2002 13:38:42 -0400 To: mpls@UU.NET From: "Thomas D. Nadeau" Subject: LC-ATM and LC-FR ifType Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, I would like to apply to IANA for an official LC-ATM and LC-FR ifTypes, and have been asked by the AD to send a posting to the MPLS WG to let the WG voice its opinion on this. I would like to apply for these interface type given the reference of section 3 from RFC3035 for LC-ATM, and section 2 from RFC3034. Please post your opinions either way. If I do not hear from anyone in a few days, I will forward my request to IANA. I will also be posting a (very short) informational draft in a few days describing the function of this new ifType and how it plays with the existing MPLS ifStacking picture so that we can be very clear on how these ifTypes are used for management purposes. --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Mon May 6 14:06:28 2002 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 OAA00377 for ; Mon, 6 May 2002 14:06:27 -0400 (EDT) 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 QQmnsa13138; Mon, 6 May 2002 18:05:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnsa09558 for mpls-outgoing; Mon, 6 May 2002 18:04: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 QQmnsa09432 for ; Mon, 6 May 2002 18:04:45 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 QQmnsa02697 for ; Mon, 6 May 2002 18:04:29 GMT Received: from server.nayna.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 67-89-191-66.customer.algx.net [67.89.191.66]) id QQmnsa12019 for ; Mon, 6 May 2002 18:04:28 GMT Received: from relay.nayna.com (relay.nayna.com [10.0.128.11]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA00503; Mon, 6 May 2002 11:04:25 -0700 Received: from nayna.com (dhcp-131-104.nayna.com [10.0.131.104]) by relay.nayna.com (8.9.3/8.9.3) with ESMTP id LAA24981; Mon, 6 May 2002 11:04:22 -0700 Message-ID: <3CD6C43C.94BACCEE@nayna.com> Date: Mon, 06 May 2002 10:58:20 -0700 From: Sudheer Dharanikota X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Gary Tam CC: Ajay Simha , curtis@fictitious.org, Ron Bonica , Brijesh Kumar , "'Curtis Villamizar '" , mpls@UU.NET, CCAMP WG Subject: Re: Static LSP Configuration References: <20020506154218.58140.qmail@web11207.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Gary: Gary Tam wrote: > yes, you can rely on the Physical Optical driver to > monitor the incoming signal/power level, and/or > synchornization (using PLL/CDR). But without a fast > propagation mechanism, you cannot archieve sub 50ms > global protection. I do not see how you can do it with > RSVP or LDP over 5-10 hop path. > > --- Ajay Simha wrote: > > On Mon, 6 May 2002, Gary I thought the discussion was about data networks. This suddenly became transport network discusion :-) As you have noted, there are multiple phases in recovery here. Transport networks are *built* to provide 50 msec recovery times (e.g., rings, span, 1+1 etc). Hence a failures are scoped to be within a domain (typically a ring or a span or in the worst case end-to-end[1+1 case]). Excluding failure detection time in this 50 msec (taking from SONET knowledge), failure reporting and recovery should take 50 msec. Obviously this cannot be done with OSS intervention. One can use SONET's inband signaling mechanisms for failure reporting or use *directed notification* mechanisms such as the ones proposed for signaling protocols. Note that if we assume a ring topology then the messages are only one hop away (with the assumption that only the DCS are the intelligent devices). So your worry of 5-10 hop path is not valid in my opinion. Regards, sudheer > Tam wrote: > > > > GT>Hi Curtis, > > GT> > > GT>You have some good points. I agree with you that > > GT>dynamic signaling is good and essential. > > GT> > > GT>But for protection, you do not have to have > > dynamic > > GT>signaling protocol. You need 2 disjointed LSPs, > > and a > > GT>fast fault detection / propagation mechanism > > (could be > > GT>an OAM control flow or other means for the > > targeted > > GT>DA). In this case, when there is a link/fiber > > cut, the > > GT>failure can be detected at where the fault occurs > > and > > GT>be propagated to where the switch takes place. In > > GT>terms of global/segmented protection, the > > local-node > > GT>detects the failure instantly and propagates > > failure > > GT>condition to the targeted DA of the switch node. > > The > > GT>switch-node performs the switch-over activity as > > soon > > GT>as it gets the switch-over message. In the entire > > GT>proceess, there is no dynamic signaling here. > > Besides, > > GT>it will be too slow and costly to do protection > > with > > GT>RSVP-signaling - ie 50ms protection. Even if you > > scale > > > > Not true. > > GT>the RSVP/LDP Hello intervals to 5ms, there are > > lots of > > GT>issues such as link flapping, lots of hellos. > > etc. > > GT> > > > > You could use sonet alarms for detection. Any how > > would OAM control flow > > solve any lost pkts? > > > > -ajay > > GT>In the Access domain, ie 802.1Q, VLAN/SVLAN is > > widely > > GT>used for data forwarding and customer data > > separation. > > GT>There is no urgent need for an Ethernet network > > to > > GT>implement RSVP-TE or CR-LDP. So static > > LSP-Stitching > > GT>will be a cheap and inexpensive solution for L2 > > VPN. > > GT> > > GT>Gary > > GT> > > GT> > > GT>--- Curtis Villamizar > > GT> wrote: > > GT>> > > GT>> In message > > GT>> > > > GT><20020506135949.87793.qmail@web11208.mail.yahoo.com>, > > GT>> Gary Tam write > > GT>> s: > > GT>> > > > GT>> > In the core network ( between port 2 and 3), > > it > > GT>> can be > > GT>> > nested LSP trunking setup by CR-LDP/RSVP-TE. > > This > > GT>> will > > GT>> > not change anything in case of failure > > between 2 > > GT>> and 3 > > GT>> > with the obvious exception of port 2 and 3. > > GT>> > > > GT>> > The static LSP (1,2,3,4) will likely be > > GT>> > Martini-encapsulated Tunnel for some L2 > > VLAN/MPLS > > GT>> VCs > > GT>> > as well. The L2 FEC can be either MAC DA, > > VLAN, > > GT>> > Coustomer ID, and ATM VC, etc. > > GT>> > > > GT>> > Gary > > GT>> > > GT>> > > GT>> Gary, > > GT>> > > GT>> I didn't think I was going to have to answer my > > own > > GT>> retorical question > > GT>> "what happens with static LSPs if a link goes > > down". > > GT>> If any link > > GT>> fails you're sunk. You could in principle > > create a > > GT>> second static LSP > > GT>> (a static standby) but with no signaling there > > is no > > GT>> way to tell the > > GT>> ingress to use it. > > GT>> > > GT>> Even with a prmary and standby (regardless of > > GT>> whether the primary > > GT>> and/or standby are static or dynamic), > > occassionally > > GT>> multiple faults > > GT>> occur for which SRLGs do not cover the > > possibility > > GT>> and where it would > > GT>> be prohibitively expensive to do so. A > > examples > > GT>> examples from my > > GT>> experience are power outage in Manhattan during > > GT>> generator maintenance > > GT>> (famous for taking the FAA network down), > > Amtrak > > GT>> train wreck in NJ > > GT>> (famous for nearly taking out NYC due to > > damaged > > GT>> fiber on both sides > > GT>> of the track), hurricane brushing NC and VA > > causing > > GT>> damage and > > GT>> flooding (famous for taking out MAE-E > > connectivity > > GT>> to Europe during an > > GT>> IETF), extensive flooding in US midwest, > > earthquake > > GT>> in San Diego, > > GT>> Raritan River bridge failure in NJ, gas main > > leak in > > GT>> LA forcing CO to > > GT>> cut power, exploding rat in SF power transfer > > GT>> switch, and the list > > GT>> goes on and on. You can't write SRLGs to cover > > GT>> this. The only viable > > GT>> solution is to dynamically route. > > GT>> > > GT>> Some providers talk about using an > > explicit-path > > GT>> specified at the > > GT>> ingress with a dynamically routed backup > > (disjoint > > GT>> and either > > GT>> pre-signaled or just pre-computed, or > > dynamically > > GT>> rerouted after > > GT>> failure). This does not use static insegments > > and > > GT>> outsegments, it > > GT>> uses singaled LSPs with configured paths. Even > > talk > > GT>> of this approach > > GT>> (explicit primary path) is becoming more rare > > GT>> because when failure > > GT>> occurs and when optimal layout is most needed > > it > > GT>> often makes sense to > > GT>> allow primaries were not broken by the fault to > > pick > > GT>> alternate less > > GT>> congested paths. > > GT>> > > GT>> second retorical question - Why don't IP > > providers > > GT>> build their > > GT>> backbones out of static routes? I'm hope we > > don't > > GT>> get any > GT>> don't know why they don't do that IP static > > routes > > GT>> would seem like a > > GT>> really great idea> responses. > > GT>> > > GT>> Curtis > > GT> > > GT> > > > GT>______________________________________________________________________ > > GT>Games, Movies, Music & Sports! > > http://entertainment.yahoo.ca > > GT> > > > > -- > > > > ______________________________________________________________________ > Games, Movies, Music & Sports! http://entertainment.yahoo.ca From owner-mpls@UU.NET Mon May 6 16:00:40 2002 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 QAA04691 for ; Mon, 6 May 2002 16:00:40 -0400 (EDT) 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 QQmnsh02524; Mon, 6 May 2002 19:59:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnsh24663 for mpls-outgoing; Mon, 6 May 2002 19:59: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 QQmnsh24658 for ; Mon, 6 May 2002 19:59: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 QQmnsh26427 for ; Mon, 6 May 2002 19:59:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnsh10786 for ; Mon, 6 May 2002 19:59:02 GMT 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 PAA29918 for ; Mon, 6 May 2002 15:59:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA21607 for mpls@uu.net; Mon, 6 May 2002 15:59:02 -0400 (EDT) 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 QQmnsh24614 for ; Mon, 6 May 2002 19:58: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 QQmnsh23582 for ; Mon, 6 May 2002 19:57:25 GMT Received: from hawk.CrescentNetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hawk.crescentnetworks.com [66.105.92.144]) id QQmnsh22140 for ; Mon, 6 May 2002 19:57:25 GMT Received: from crescentnetworks.com (jcucchiara.in.crescentnets.com [192.168.29.132]) by hawk.CrescentNetworks.com (8.9.3/8.9.3) with ESMTP id PAA23903; Mon, 6 May 2002 15:57:18 -0400 (EDT) Message-ID: <3CD6E0B5.69C1D75B@crescentnetworks.com> Date: Mon, 06 May 2002 15:59:50 -0400 From: Joan Cucchiara Organization: Crescent Networks X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Thomas D. Nadeau" CC: mpls@UU.NET Subject: Re: LC-ATM and LC-FR ifType References: <4.3.2.7.2.20020506131507.024b8d68@bucket> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tom, Why are these new ifTypes needed? How they will be used? How they will work in the ifStack? Is your intention that the existing MPLS ifTypes would no longer be needed, or would change in meaning? The answers would be helpful to understanding these new types. Perhaps, this is all described in the doc you will be posting. If so, could you post the doc and then give us a few days to discuss the new ifTypes you are requesting? Currently, we have 2 ifTypes for MPLS (mplsTunnel(150) and and mpls(166)), and we already have the media information because the MPLS interface is usually stacked over an ATM interface, or an FR interface, or a PPP interface, etc. Thanks, -Joan "Thomas D. Nadeau" wrote: > > Hi, > > I would like to apply to IANA for an official > LC-ATM and LC-FR ifTypes, and have been asked by > the AD to send a posting to the MPLS WG to let the WG > voice its opinion on this. I would like to apply for these interface > type given the reference of section 3 from RFC3035 for LC-ATM, > and section 2 from RFC3034. Please post your opinions either > way. If I do not hear from anyone in a few days, I will forward > my request to IANA. > > I will also be posting a (very short) informational draft > in a few days describing the function of this new ifType > and how it plays with the existing MPLS ifStacking picture so that > we can be very clear on how these ifTypes are used for management > purposes. > > --Tom > > ------------------------------------------------------------------------ > Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Mon May 6 16:39:53 2002 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 QAA05560 for ; Mon, 6 May 2002 16:39:53 -0400 (EDT) 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 QQmnsk18804; Mon, 6 May 2002 20:38:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnsk19870 for mpls-outgoing; Mon, 6 May 2002 20:38:27 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 QQmnsk19864 for ; Mon, 6 May 2002 20:38:25 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 QQmnsk25237 for ; Mon, 6 May 2002 20:38:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnsk25280 for ; Mon, 6 May 2002 20:38:02 GMT 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 QAA02447 for ; Mon, 6 May 2002 16:38:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA25721 for mpls@uu.net; Mon, 6 May 2002 16:38:02 -0400 (EDT) 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 QQmnsk19664 for ; Mon, 6 May 2002 20:36: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 QQmnsk18223 for ; Mon, 6 May 2002 20:34:43 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmnsk18916 for ; Mon, 6 May 2002 20:34:42 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 QAA47087; Mon, 6 May 2002 16:31:11 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200205062031.QAA47087@workhorse.fictitious.org> To: Sudheer Dharanikota cc: Gary Tam , Ajay Simha , curtis@fictitious.org, Ron Bonica , Brijesh Kumar , "'Curtis Villamizar '" , mpls@UU.NET, CCAMP WG Reply-To: curtis@fictitious.org Subject: Re: Static LSP Configuration In-reply-to: Your message of "Mon, 06 May 2002 10:58:20 PDT." <3CD6C43C.94BACCEE@nayna.com> Date: Mon, 06 May 2002 16:31:11 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3CD6C43C.94BACCEE@nayna.com>, Sudheer Dharanikota writes: > > Transport networks are *built* to provide 50 msec recovery > times (e.g., rings, span, 1+1 etc). Hence a failures are scoped to be > within a domain (typically a ring or a span or in the worst case > end-to-end[1+1 case]). Excluding failure detection time in this > 50 msec (taking from SONET knowledge), failure reporting > and recovery should take 50 msec. Obviously this cannot > be done with OSS intervention. One can use SONET's > inband signaling mechanisms for failure reporting or use > *directed notification* mechanisms such as the ones proposed > for signaling protocols. Note that if we assume a ring topology then > the messages are only one hop away (with the assumption that > only the DCS are the intelligent devices). So your worry of 5-10 > hop path is not valid in my opinion. > > Regards, > > sudheer The discussion was about MPLS but an underlying assumption seemded to enter into the thread with that last email that either APS was running under MPLS or L2 was the application and APS was running over MPLS provided over multiple end to end L2 tunnels. I don't know of anyone doing SONET APS over the L2 tunnels of an MPLS backbone. I do know of providers who want to eliminate the APS on the sonet links under their MPLS network cutting some costs significantly (but with all things considered, not in half). MPLS restoration needs to work quite well to do this and still meet SLAs and carrying L2 service is even more demanding. Curtis From owner-mpls@UU.NET Mon May 6 16:58:31 2002 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 QAA06415 for ; Mon, 6 May 2002 16:58:30 -0400 (EDT) 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 QQmnsl15798; Mon, 6 May 2002 20:57:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnsl21666 for mpls-outgoing; Mon, 6 May 2002 20:57:26 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 QQmnsl21661 for ; Mon, 6 May 2002 20:57: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 QQmnsl03055 for ; Mon, 6 May 2002 20:57:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnsl17880 for ; Mon, 6 May 2002 20:57:02 GMT 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 QAA03644 for ; Mon, 6 May 2002 16:57:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA28032 for mpls@uu.net; Mon, 6 May 2002 16:57:01 -0400 (EDT) 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 QQmnsl21566 for ; Mon, 6 May 2002 20:56:43 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 QQmnsl28184 for ; Mon, 6 May 2002 20:56:32 GMT Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmnsl17617 for ; Mon, 6 May 2002 20:56:31 GMT Received: (qmail 407 invoked by uid 104); 6 May 2002 20:56:30 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4201. . Clean. Processed in 0.441144 secs); 06 May 2002 20:56:30 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 6 May 2002 20:56:29 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g46KuQp00234; Mon, 6 May 2002 13:56:26 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 6 May 2002 13:56:30 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A795@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" , Sudheer Dharanikota Cc: Gary Tam , Ajay Simha , Ron Bonica , Brijesh Kumar , mpls@UU.NET, CCAMP WG Subject: RE: Static LSP Configuration Date: Mon, 6 May 2002 13:56:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis, > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Sent: Monday, May 06, 2002 4:31 PM > To: Sudheer Dharanikota > Cc: Gary Tam; Ajay Simha; curtis@fictitious.org; Ron Bonica; Brijesh > Kumar; 'Curtis Villamizar '; mpls@UU.NET; CCAMP WG > Subject: Re: Static LSP Configuration > > > > In message <3CD6C43C.94BACCEE@nayna.com>, Sudheer Dharanikota writes: > > > > Transport networks are *built* to provide 50 msec recovery > > times (e.g., rings, span, 1+1 etc). Hence a failures are > scoped to be > > within a domain (typically a ring or a span or in the worst case > > end-to-end[1+1 case]). Excluding failure detection time in this > > 50 msec (taking from SONET knowledge), failure reporting > > and recovery should take 50 msec. Obviously this cannot > > be done with OSS intervention. One can use SONET's > > inband signaling mechanisms for failure reporting or use > > *directed notification* mechanisms such as the ones proposed > > for signaling protocols. Note that if we assume a ring topology then > > the messages are only one hop away (with the assumption that > > only the DCS are the intelligent devices). So your worry of 5-10 > > hop path is not valid in my opinion. > > > > Regards, > > > > sudheer > > > The discussion was about MPLS but an underlying assumption seemded to > enter into the thread with that last email that either APS was running > under MPLS or L2 was the application and APS was running over MPLS > provided over multiple end to end L2 tunnels. > > I don't know of anyone doing SONET APS over the L2 tunnels of an MPLS > backbone. > > I do know of providers who want to eliminate the APS on the sonet > links under their MPLS network cutting some costs significantly (but > with all things considered, not in half). What mechanism will they use to detect the failure then? -Shahram MPLS restoration needs to > work quite well to do this and still meet SLAs and carrying L2 service > is even more demanding. > > Curtis > From owner-mpls@UU.NET Mon May 6 17:28:27 2002 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 RAA07586 for ; Mon, 6 May 2002 17:28:27 -0400 (EDT) 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 QQmnsn27790; Mon, 6 May 2002 21:27:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnsn16411 for mpls-outgoing; Mon, 6 May 2002 21:27:26 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 QQmnsn16406 for ; Mon, 6 May 2002 21:27:15 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 QQmnsn07510 for ; Mon, 6 May 2002 21:27:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnsn22931 for ; Mon, 6 May 2002 21:27:02 GMT 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 RAA05354 for ; Mon, 6 May 2002 17:27:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA01845 for mpls@uu.net; Mon, 6 May 2002 17:27:02 -0400 (EDT) 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 QQmnsn16389 for ; Mon, 6 May 2002 21:26: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 QQmnsn16172 for ; Mon, 6 May 2002 21:26:38 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 QQmnsn22396 for ; Mon, 6 May 2002 21:26: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 g46LQqe4025942; Mon, 6 May 2002 17:26:53 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122]) by bucket.cisco.com (Mirapoint) with ESMTP id AAZ39453; Mon, 6 May 2002 17:26:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20020506160007.024b84e8@bucket> X-Sender: tnadeau@bucket X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 May 2002 17:26:18 -0400 To: Joan Cucchiara From: "Thomas D. Nadeau" Subject: Re: LC-ATM and LC-FR ifType Cc: mpls@UU.NET In-Reply-To: <3CD6E0B5.69C1D75B@crescentnetworks.com> References: <4.3.2.7.2.20020506131507.024b8d68@bucket> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >Why are these new ifTypes needed? >How they will be used? How they will work >in the ifStack? Is your intention that the existing >MPLS ifTypes would no longer be needed, or would change >in meaning? The LC-FR and LC-ATM ifTypes need to be defined as separate types, as they are not MPLS-type interfaces for data, just label control/setup. >The answers would be helpful to understanding these >new types. Perhaps, this is all described in the doc you >will be posting. If so, could you post the doc and then >give us a few days to discuss the new ifTypes you are requesting? I will post the doc shortly. >Currently, we have 2 ifTypes for MPLS (mplsTunnel(150) and >and mpls(166)), and we already have the media information because >the MPLS interface is usually stacked over an ATM interface, or an FR >interface, or a PPP interface, etc. This is for the label switch controlling interfaces, which should only be stacked above the underlying subinterface (non-MPLS): LC-ATM LC-FR atm3/0 fr3/0 --Tom >Thanks, > -Joan > >"Thomas D. Nadeau" wrote: > > > > Hi, > > > > I would like to apply to IANA for an official > > LC-ATM and LC-FR ifTypes, and have been asked by > > the AD to send a posting to the MPLS WG to let the WG > > voice its opinion on this. I would like to apply for these interface > > type given the reference of section 3 from RFC3035 for LC-ATM, > > and section 2 from RFC3034. Please post your opinions either > > way. If I do not hear from anyone in a few days, I will forward > > my request to IANA. > > > > I will also be posting a (very short) informational draft > > in a few days describing the function of this new ifType > > and how it plays with the existing MPLS ifStacking picture so that > > we can be very clear on how these ifTypes are used for management > > purposes. > > > > --Tom > > > > ------------------------------------------------------------------------ > > Mathematics is the supreme nostalgia of our time. ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Mon May 6 17:36:44 2002 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 RAA08004 for ; Mon, 6 May 2002 17:36:44 -0400 (EDT) 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 QQmnso11114; Mon, 6 May 2002 21:35:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnso16813 for mpls-outgoing; Mon, 6 May 2002 21:35: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 QQmnso16807 for ; Mon, 6 May 2002 21:35:25 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 QQmnso04711 for ; Mon, 6 May 2002 21:34:32 GMT Received: from server.nayna.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 67-89-191-66.customer.algx.net [67.89.191.66]) id QQmnso01959 for ; Mon, 6 May 2002 21:34:31 GMT Received: from relay.nayna.com (relay.nayna.com [10.0.128.11]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id OAA31070; Mon, 6 May 2002 14:34:13 -0700 Received: from nayna.com (dhcp-131-104.nayna.com [10.0.131.104]) by relay.nayna.com (8.9.3/8.9.3) with ESMTP id OAA26764; Mon, 6 May 2002 14:33:27 -0700 Message-ID: <3CD6F53E.52779883@nayna.com> Date: Mon, 06 May 2002 14:27:26 -0700 From: Sudheer Dharanikota X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Shahram Davari CC: "'curtis@fictitious.org'" , Gary Tam , Ajay Simha , Ron Bonica , Brijesh Kumar , mpls@UU.NET, CCAMP WG Subject: Re: Static LSP Configuration References: <4B6D09F3B826D411A67300D0B706EFDE84A795@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > Curtis, > > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > > Sent: Monday, May 06, 2002 4:31 PM > > To: Sudheer Dharanikota > > Cc: Gary Tam; Ajay Simha; curtis@fictitious.org; Ron Bonica; Brijesh > > Kumar; 'Curtis Villamizar '; mpls@UU.NET; CCAMP WG > > Subject: Re: Static LSP Configuration > > > > > > > > In message <3CD6C43C.94BACCEE@nayna.com>, Sudheer Dharanikota writes: > > > > > > Transport networks are *built* to provide 50 msec recovery > > > times (e.g., rings, span, 1+1 etc). Hence a failures are > > scoped to be > > > within a domain (typically a ring or a span or in the worst case > > > end-to-end[1+1 case]). Excluding failure detection time in this > > > 50 msec (taking from SONET knowledge), failure reporting > > > and recovery should take 50 msec. Obviously this cannot > > > be done with OSS intervention. One can use SONET's > > > inband signaling mechanisms for failure reporting or use > > > *directed notification* mechanisms such as the ones proposed > > > for signaling protocols. Note that if we assume a ring topology then > > > the messages are only one hop away (with the assumption that > > > only the DCS are the intelligent devices). So your worry of 5-10 > > > hop path is not valid in my opinion. > > > > > > Regards, > > > > > > sudheer > > > > > > The discussion was about MPLS but an underlying assumption seemded to > > enter into the thread with that last email that either APS was running > > under MPLS or L2 was the application and APS was running over MPLS > > provided over multiple end to end L2 tunnels. > > > > I don't know of anyone doing SONET APS over the L2 tunnels of an MPLS > > backbone. > > > > I do know of providers who want to eliminate the APS on the sonet > > links under their MPLS network cutting some costs significantly (but > > with all things considered, not in half). > > What mechanism will they use to detect the failure then? With most of the *recent* L2/L1 technologies, failure dection is not the only problem. Without APS-like mechanisms (sub-second) failure reporting is also a major problem. In my opinion, for the sake of the underlying technologies which does not have APS-like reporting mechanisms, we need to optimize our signaling protocols and propose sensible control plane topologies. Regards, sudheer > > > -Shahram > > MPLS restoration needs to > > work quite well to do this and still meet SLAs and carrying L2 service > > is even more demanding. > > > > Curtis > > From owner-mpls@UU.NET Mon May 6 18:07:19 2002 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 SAA09139 for ; Mon, 6 May 2002 18:07:18 -0400 (EDT) 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 QQmnsq08994; Mon, 6 May 2002 22:06:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnsq09389 for mpls-outgoing; Mon, 6 May 2002 22:06: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 QQmnsq09359 for ; Mon, 6 May 2002 22:06:05 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 QQmnsq09883 for ; Mon, 6 May 2002 22:04:43 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 QQmnsq18487 for ; Mon, 6 May 2002 22:04:43 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 g46M4gL26918 for ; Mon, 6 May 2002 18:04:42 -0400 (EDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id <20N57KF0>; Mon, 6 May 2002 18:04:42 -0400 Message-ID: <4490F7068AC0D111A7120008C72878EC0EB6E27D@nj7460exch003u.ho.lucent.com> From: "Nagarajan, Ramesh (Ramesh)" To: Shahram Davari , "'Sudheer Dharanikota'" Cc: "'curtis@fictitious.org'" , Gary Tam , Ajay Simha , Ron Bonica , Brijesh Kumar , mpls@UU.NET, CCAMP WG Subject: RE: Static LSP Configuration Date: Mon, 6 May 2002 18:04:40 -0400 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 Sudheer, Shahram, I agree. *Fast* failure detection and reporting are challenging issues even when we consider physical layer failures (fiber cut etc.,) only. If you throw in soft failures of many kinds it becomes even more challenging. This was one of the motivations, among many others, in developing a restoration scheme/proposal (link below for convenience) which provides broad coverage for many failures without requiring failure detection and reporting. This will work across the recent L2/L1 technologies that you refer to which lack either proper failure detection and/or reporting. ramesh. http://www.ietf.org/internet-drafts/draft-nagarajan-ccamp-mpls-packet-protec tion-00.txt ---------------------------------------------------------------------------- -------------------------------------------------- Room 3M-335, Bell labs Tel: 732-949-2761 101 Crawfords Corner Road Fax: 732-834-5906 Holmdel, NJ 07733. e-mail: rameshn@lucent.com. ---------------------------------------------------------------------------- --------------------------------------------------- > ---------- > From: Sudheer Dharanikota[SMTP:sudheer@nayna.com] > Sent: Monday, May 06, 2002 5:27 PM > To: Shahram Davari > Cc: 'curtis@fictitious.org'; Gary Tam; Ajay Simha; Ron Bonica; Brijesh > Kumar; mpls@UU.NET; CCAMP WG > Subject: Re: Static LSP Configuration > > > > Shahram Davari wrote: > > > Curtis, > > > > > -----Original Message----- > > > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > > > Sent: Monday, May 06, 2002 4:31 PM > > > To: Sudheer Dharanikota > > > Cc: Gary Tam; Ajay Simha; curtis@fictitious.org; Ron Bonica; Brijesh > > > Kumar; 'Curtis Villamizar '; mpls@UU.NET; CCAMP WG > > > Subject: Re: Static LSP Configuration > > > > > > > > > > > > In message <3CD6C43C.94BACCEE@nayna.com>, Sudheer Dharanikota writes: > > > > > > > > Transport networks are *built* to provide 50 msec recovery > > > > times (e.g., rings, span, 1+1 etc). Hence a failures are > > > scoped to be > > > > within a domain (typically a ring or a span or in the worst case > > > > end-to-end[1+1 case]). Excluding failure detection time in this > > > > 50 msec (taking from SONET knowledge), failure reporting > > > > and recovery should take 50 msec. Obviously this cannot > > > > be done with OSS intervention. One can use SONET's > > > > inband signaling mechanisms for failure reporting or use > > > > *directed notification* mechanisms such as the ones proposed > > > > for signaling protocols. Note that if we assume a ring topology then > > > > the messages are only one hop away (with the assumption that > > > > only the DCS are the intelligent devices). So your worry of 5-10 > > > > hop path is not valid in my opinion. > > > > > > > > Regards, > > > > > > > > sudheer > > > > > > > > > The discussion was about MPLS but an underlying assumption seemded to > > > enter into the thread with that last email that either APS was running > > > under MPLS or L2 was the application and APS was running over MPLS > > > provided over multiple end to end L2 tunnels. > > > > > > I don't know of anyone doing SONET APS over the L2 tunnels of an MPLS > > > backbone. > > > > > > I do know of providers who want to eliminate the APS on the sonet > > > links under their MPLS network cutting some costs significantly (but > > > with all things considered, not in half). > > > > What mechanism will they use to detect the failure then? > > With most of the *recent* L2/L1 technologies, failure dection is not the > only problem. > Without APS-like mechanisms (sub-second) failure reporting is also a major > problem. > In my opinion, for the sake of the underlying technologies which does not > have > APS-like reporting mechanisms, we need to optimize our signaling protocols > and propose sensible control plane topologies. > > Regards, > > sudheer > > > > > > > -Shahram > > > > MPLS restoration needs to > > > work quite well to do this and still meet SLAs and carrying L2 service > > > is even more demanding. > > > > > > Curtis > > > > > From owner-mpls@UU.NET Mon May 6 18:50:01 2002 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 SAA10074 for ; Mon, 6 May 2002 18:50:01 -0400 (EDT) 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 QQmnst20923; Mon, 6 May 2002 22:49:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnst14500 for mpls-outgoing; Mon, 6 May 2002 22:48: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 QQmnst14495 for ; Mon, 6 May 2002 22:48: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 QQmnst24298 for ; Mon, 6 May 2002 22:48:20 GMT Received: from server.nayna.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 67-89-191-66.customer.algx.net [67.89.191.66]) id QQmnst27979 for ; Mon, 6 May 2002 22:48:19 GMT Received: from relay.nayna.com (relay.nayna.com [10.0.128.11]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id PAA09181; Mon, 6 May 2002 15:48:13 -0700 Received: from nayna.com (dhcp-131-104.nayna.com [10.0.131.104]) by relay.nayna.com (8.9.3/8.9.3) with ESMTP id PAA27443; Mon, 6 May 2002 15:47:43 -0700 Message-ID: <3CD706A6.BF752E1C@nayna.com> Date: Mon, 06 May 2002 15:41:42 -0700 From: Sudheer Dharanikota X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Nagarajan, Ramesh (Ramesh)" CC: Shahram Davari , "'curtis@fictitious.org'" , Gary Tam , Ajay Simha , Ron Bonica , Brijesh Kumar , mpls@UU.NET, CCAMP WG Subject: Re: Static LSP Configuration References: <4490F7068AC0D111A7120008C72878EC0EB6E27D@nj7460exch003u.ho.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Ramesh: "Nagarajan, Ramesh (Ramesh)" wrote: > Sudheer, Shahram, > > I agree. *Fast* failure detection and reporting are challenging issues even > when we consider physical layer failures (fiber cut etc.,) only. If you > throw in soft failures of many kinds it becomes even more challenging. > This was one of the motivations, among many others, in developing a > restoration scheme/proposal (link below for convenience) which provides > broad coverage for many failures without requiring failure detection and > reporting. This will work across the recent L2/L1 technologies that you > refer to which lack either proper failure detection and/or reporting. > > ramesh. > > http://www.ietf.org/internet-drafts/draft-nagarajan-ccamp-mpls-packet-protec > tion-00.txt > Although I agree that 1+1 mechanisms may solve (to be precise avoid) such problems, they are very resource intensive. Also most of the data applications do not need the recovery times that you can support by 1+1. In my opinion, the challenge is to support less resource intensive but reasinably faster restoration times for data applications by reusing the under-lying technologies. Regards, sudheer > > ---------------------------------------------------------------------------- > -------------------------------------------------- > Room 3M-335, Bell labs > Tel: 732-949-2761 > 101 Crawfords Corner Road > Fax: 732-834-5906 > Holmdel, NJ 07733. > e-mail: rameshn@lucent.com. > ---------------------------------------------------------------------------- > --------------------------------------------------- > > > ---------- > > From: Sudheer Dharanikota[SMTP:sudheer@nayna.com] > > Sent: Monday, May 06, 2002 5:27 PM > > To: Shahram Davari > > Cc: 'curtis@fictitious.org'; Gary Tam; Ajay Simha; Ron Bonica; Brijesh > > Kumar; mpls@UU.NET; CCAMP WG > > Subject: Re: Static LSP Configuration > > > > > > > > Shahram Davari wrote: > > > > > Curtis, > > > > > > > -----Original Message----- > > > > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > > > > Sent: Monday, May 06, 2002 4:31 PM > > > > To: Sudheer Dharanikota > > > > Cc: Gary Tam; Ajay Simha; curtis@fictitious.org; Ron Bonica; Brijesh > > > > Kumar; 'Curtis Villamizar '; mpls@UU.NET; CCAMP WG > > > > Subject: Re: Static LSP Configuration > > > > > > > > > > > > > > > > In message <3CD6C43C.94BACCEE@nayna.com>, Sudheer Dharanikota writes: > > > > > > > > > > Transport networks are *built* to provide 50 msec recovery > > > > > times (e.g., rings, span, 1+1 etc). Hence a failures are > > > > scoped to be > > > > > within a domain (typically a ring or a span or in the worst case > > > > > end-to-end[1+1 case]). Excluding failure detection time in this > > > > > 50 msec (taking from SONET knowledge), failure reporting > > > > > and recovery should take 50 msec. Obviously this cannot > > > > > be done with OSS intervention. One can use SONET's > > > > > inband signaling mechanisms for failure reporting or use > > > > > *directed notification* mechanisms such as the ones proposed > > > > > for signaling protocols. Note that if we assume a ring topology then > > > > > the messages are only one hop away (with the assumption that > > > > > only the DCS are the intelligent devices). So your worry of 5-10 > > > > > hop path is not valid in my opinion. > > > > > > > > > > Regards, > > > > > > > > > > sudheer > > > > > > > > > > > > The discussion was about MPLS but an underlying assumption seemded to > > > > enter into the thread with that last email that either APS was running > > > > under MPLS or L2 was the application and APS was running over MPLS > > > > provided over multiple end to end L2 tunnels. > > > > > > > > I don't know of anyone doing SONET APS over the L2 tunnels of an MPLS > > > > backbone. > > > > > > > > I do know of providers who want to eliminate the APS on the sonet > > > > links under their MPLS network cutting some costs significantly (but > > > > with all things considered, not in half). > > > > > > What mechanism will they use to detect the failure then? > > > > With most of the *recent* L2/L1 technologies, failure dection is not the > > only problem. > > Without APS-like mechanisms (sub-second) failure reporting is also a major > > problem. > > In my opinion, for the sake of the underlying technologies which does not > > have > > APS-like reporting mechanisms, we need to optimize our signaling protocols > > and propose sensible control plane topologies. > > > > Regards, > > > > sudheer > > > > > > > > > > > -Shahram > > > > > > MPLS restoration needs to > > > > work quite well to do this and still meet SLAs and carrying L2 service > > > > is even more demanding. > > > > > > > > Curtis > > > > > > > > From owner-mpls@UU.NET Mon May 6 19:14:55 2002 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 TAA10782 for ; Mon, 6 May 2002 19:14:55 -0400 (EDT) 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 QQmnsu24296; Mon, 6 May 2002 23:14:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnsu08260 for mpls-outgoing; Mon, 6 May 2002 23:14: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 QQmnsu08255 for ; Mon, 6 May 2002 23:13:52 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 QQmnsu17313 for ; Mon, 6 May 2002 23:13:23 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 QQmnsu23131 for ; Mon, 6 May 2002 23:13:22 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 g46NDLG17623 for ; Mon, 6 May 2002 19:13:21 -0400 (EDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id <20N57LDW>; Mon, 6 May 2002 19:13:21 -0400 Message-ID: <4490F7068AC0D111A7120008C72878EC0EB6E27F@nj7460exch003u.ho.lucent.com> From: "Nagarajan, Ramesh (Ramesh)" To: "'Sudheer Dharanikota'" Cc: Shahram Davari , "'curtis@fictitious.org'" , Gary Tam , Ajay Simha , Ron Bonica , Brijesh Kumar , mpls@UU.NET, CCAMP WG Subject: RE: Static LSP Configuration Date: Mon, 6 May 2002 19:13:20 -0400 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA10782 Sudheer, I am taking the liberty of attaching e-mail (on MPLS WG) from Neil Harrison of BT on the proposal. He has some excellent comments/perspective (among others) on the 2x BW issue (see his point 1). I share these viewpoints. Failure detection/reporting avoidance is only one of the advantages of the proposal (and highlighted in the context of the discussion on this thread). There are many other advantages that we can discuss at length. ramesh. > > From: Harrison,N,Neil,IKO1 R > > Sent: 24 April 2002 13:20 > > To: IETF MPLS WG (E-mail) > > Subject: comments on nagarajan-ccamp-mpls-packet-protection-00.txt > > > > I noted George S asked for comments on > > nagarajan-ccamp-mpls-packet-protection-00.txt to be taken > on the list in his > > notes of the MPLS WG mtg.....so here are some 1st pass comments: > > > > 1 I noted a criticism in the mtg notes that it uses > 2x the BW of one > > LSP....well yes it is 1+1 so I'd say that's obvious. > However, I think we > > have to place any such criticism of BW efficiency in > context. For example, > > if I compare it with LDP as a server layer to (say) rfc2547 > VPNs, then > > because there is no relationship between a pkt's up-state > QoS forwarding > > treatment and a pkt's survivability requirements (vis-à-vis same or > > different DS-coded pkts of *any* VPN), operators are forced > to over-engineer > > such networks and *hope* (because there is no assurance) > that traffic > > survives under failures....a factor of 2x over-engineering > on some DS > > classes is not uncommon. > > > > Hence, the point I want to make here is that using BW wisely to > > reduce/remove a complexity/problem is one thing (which I > support), but > > asking an operator to throw BW at a problem that should not > really exist > > (because the application/problem in question has only been partially > > defined, eg just the connectivity bit of VPNs) is something > else. So any > > criticism of BW efficiency only makes sense against the > context of the > > application/problem it is addressing IMO. > > > > 2 I noted in section 6.2 you address the practical > issue of carrying > > the sequence number (if implemented in such a way), and > suggest that it sits > > directly below the shim header (1st 4 octets of payload). > This is possible. > > 2 things spring to mind here: > > > > - IMO you really need some way to be sure you have correct A-B > > connectivity....and this includes defects where perhaps > another LSP, LSP X > > say, gets merged unintentionally into the LSP Y between > A-B. In this case > > you would get some unexpected results looking for a > sequence number in such > > mismerged pkts. I would therefore recommend you run a > periodic data-plane > > LSP CV OAM flow on each of the LSPs to verify correct > connectivity, since > > these contain unique LSP source identifiers and will detect > all defects, not > > just simple breaks (and if following Y.1711, it will also > invoke the correct > > consequent actions on failure). > > > > - You will need to configure the LSP sink points to > expect LSPs > > containing sequence numbers. This can be done manually of > course, but you > > may want to consider some auto signalling config...and I > later noted that > > you have considered this aspect in section 6.4 wrt RSVP > say. A further way > > to achieve this signalling function could be by the use of > special OAM > > pkts....and its something being considered by those who are > working on MPLS > > OAM in Y.1711 for automatic CV activation/deactivation. > > > > 3 Given that the scheme you are proposing seems to > fit where one has a > > critical LSP connectivity application (like a > control/management-channel > > say), then I think you ought to be running some solid OAM fault > > detection/handling function on it in any case....I gave one > example above > > wrt mismerging and seeing arbitrary sequence number > effects. Moreover, I > > noted later you gave an algorithm for processing the sequence number > > implementation case at the egress that is associated with a > sliding window. > > I would suggest that this needs coupling with defect > detection mechanisms in > > order to make the correct processing decisions.....one > obvious cut-off point > > is when you would consider one of the LSPs to have become > 'unavailable' > > (this is also defined in Y.1711). > > > > 4 Final comment....simple ideas are often the best, > and this idea is > > certainly simple in principle. I think it could find > excellent uses for > > critical applications. > > > > regards, Neil > > > ---------------------------------------------------------------------------- -------------------------------------------------- Room 3M-335, Bell labs Tel: 732-949-2761 101 Crawfords Corner Road Fax: 732-834-5906 Holmdel, NJ 07733. e-mail: rameshn@lucent.com. ---------------------------------------------------------------------------- --------------------------------------------------- > ---------- > From: Sudheer Dharanikota[SMTP:sudheer@nayna.com] > Sent: Monday, May 06, 2002 6:41 PM > To: Nagarajan, Ramesh (Ramesh) > Cc: Shahram Davari; 'curtis@fictitious.org'; Gary Tam; Ajay Simha; Ron > Bonica; Brijesh Kumar; mpls@UU.NET; CCAMP WG > Subject: Re: Static LSP Configuration > > Hi Ramesh: > > > > "Nagarajan, Ramesh (Ramesh)" wrote: > > > Sudheer, Shahram, > > > > I agree. *Fast* failure detection and reporting are challenging issues > even > > when we consider physical layer failures (fiber cut etc.,) only. If you > > throw in soft failures of many kinds it becomes even more challenging. > > This was one of the motivations, among many others, in developing a > > restoration scheme/proposal (link below for convenience) which provides > > broad coverage for many failures without requiring failure detection and > > reporting. This will work across the recent L2/L1 technologies that you > > refer to which lack either proper failure detection and/or reporting. > > > > ramesh. > > > > > http://www.ietf.org/internet-drafts/draft-nagarajan-ccamp-mpls-packet-prot > ec > > tion-00.txt > > > > Although I agree that 1+1 mechanisms may solve (to be precise avoid) > such problems, they are very resource intensive. Also most of the > data applications do not need the recovery times that you can support > by 1+1. In my opinion, the challenge is to support less resource intensive > but reasinably faster restoration times for data applications by reusing > the under-lying technologies. > > Regards, > > sudheer > > > > > > -------------------------------------------------------------------------- > -- > > -------------------------------------------------- > > Room 3M-335, Bell labs > > Tel: 732-949-2761 > > 101 Crawfords Corner Road > > Fax: 732-834-5906 > > Holmdel, NJ 07733. > > e-mail: rameshn@lucent.com. > > > -------------------------------------------------------------------------- > -- > > --------------------------------------------------- > > > > > ---------- > > > From: Sudheer Dharanikota[SMTP:sudheer@nayna.com] > > > Sent: Monday, May 06, 2002 5:27 PM > > > To: Shahram Davari > > > Cc: 'curtis@fictitious.org'; Gary Tam; Ajay Simha; Ron Bonica; > Brijesh > > > Kumar; mpls@UU.NET; CCAMP WG > > > Subject: Re: Static LSP Configuration > > > > > > > > > > > > Shahram Davari wrote: > > > > > > > Curtis, > > > > > > > > > -----Original Message----- > > > > > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > > > > > Sent: Monday, May 06, 2002 4:31 PM > > > > > To: Sudheer Dharanikota > > > > > Cc: Gary Tam; Ajay Simha; curtis@fictitious.org; Ron Bonica; > Brijesh > > > > > Kumar; 'Curtis Villamizar '; mpls@UU.NET; CCAMP WG > > > > > Subject: Re: Static LSP Configuration > > > > > > > > > > > > > > > > > > > > In message <3CD6C43C.94BACCEE@nayna.com>, Sudheer Dharanikota > writes: > > > > > > > > > > > > Transport networks are *built* to provide 50 msec recovery > > > > > > times (e.g., rings, span, 1+1 etc). Hence a failures are > > > > > scoped to be > > > > > > within a domain (typically a ring or a span or in the worst case > > > > > > end-to-end[1+1 case]). Excluding failure detection time in this > > > > > > 50 msec (taking from SONET knowledge), failure reporting > > > > > > and recovery should take 50 msec. Obviously this cannot > > > > > > be done with OSS intervention. One can use SONET's > > > > > > inband signaling mechanisms for failure reporting or use > > > > > > *directed notification* mechanisms such as the ones proposed > > > > > > for signaling protocols. Note that if we assume a ring topology > then > > > > > > the messages are only one hop away (with the assumption that > > > > > > only the DCS are the intelligent devices). So your worry of 5-10 > > > > > > hop path is not valid in my opinion. > > > > > > > > > > > > Regards, > > > > > > > > > > > > sudheer > > > > > > > > > > > > > > > The discussion was about MPLS but an underlying assumption seemded > to > > > > > enter into the thread with that last email that either APS was > running > > > > > under MPLS or L2 was the application and APS was running over MPLS > > > > > provided over multiple end to end L2 tunnels. > > > > > > > > > > I don't know of anyone doing SONET APS over the L2 tunnels of an > MPLS > > > > > backbone. > > > > > > > > > > I do know of providers who want to eliminate the APS on the sonet > > > > > links under their MPLS network cutting some costs significantly > (but > > > > > with all things considered, not in half). > > > > > > > > What mechanism will they use to detect the failure then? > > > > > > With most of the *recent* L2/L1 technologies, failure dection is not > the > > > only problem. > > > Without APS-like mechanisms (sub-second) failure reporting is also a > major > > > problem. > > > In my opinion, for the sake of the underlying technologies which does > not > > > have > > > APS-like reporting mechanisms, we need to optimize our signaling > protocols > > > and propose sensible control plane topologies. > > > > > > Regards, > > > > > > sudheer > > > > > > > > > > > > > > > -Shahram > > > > > > > > MPLS restoration needs to > > > > > work quite well to do this and still meet SLAs and carrying L2 > service > > > > > is even more demanding. > > > > > > > > > > Curtis > > > > > > > > > > > > From owner-mpls@UU.NET Mon May 6 20:50:19 2002 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 UAA12405 for ; Mon, 6 May 2002 20:50:18 -0400 (EDT) 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 QQmntb28407; Tue, 7 May 2002 00:49:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQmntb07672 for mpls-outgoing; Tue, 7 May 2002 00:48:59 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 QQmntb07667 for ; Tue, 7 May 2002 00:48: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 QQmntb19323 for ; Tue, 7 May 2002 00:47:04 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmntb25370 for ; Tue, 7 May 2002 00:47:02 GMT 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 UAA13899 for ; Mon, 6 May 2002 20:47:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id UAA22094 for mpls@uu.net; Mon, 6 May 2002 20:47:01 -0400 (EDT) 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 QQmntb07505 for ; Tue, 7 May 2002 00:46:38 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 QQmntb10862 for ; Tue, 7 May 2002 00:46:11 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmntb24286 for ; Tue, 7 May 2002 00:46: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 UAA47770; Mon, 6 May 2002 20:45:41 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200205070045.UAA47770@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , Sudheer Dharanikota , Gary Tam , Ajay Simha , Ron Bonica , Brijesh Kumar , mpls@UU.NET, CCAMP WG Reply-To: curtis@fictitious.org Subject: Re: Static LSP Configuration In-reply-to: Your message of "Mon, 06 May 2002 13:56:23 PDT." <4B6D09F3B826D411A67300D0B706EFDE84A795@nt-exch-yow.pmc-sierra.bc.ca> Date: Mon, 06 May 2002 20:45:41 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDE84A795@nt-exch-yow.pmc-sierra.bc.ca > > > > I do know of providers who want to eliminate the APS on the sonet > > links under their MPLS network cutting some costs significantly (but > > with all things considered, not in half). > > What mechanism will they use to detect the failure then? SONET framing is still used. What is not used is a SONET protect path. SONET is involved in the detection, but plays no role in the recovery. It seems a few providers did buildouts in recent years costing lots of money, and used SONET protect paths while there was excess capacity. Not the most efficient, but it works great. Then as the capacity filled but revenue had not yet met the demands of incured debt, decided that they don't want the increased debt of a further buildout and are seeking a more cost effective way to meet their SLAs. Curtis From owner-mpls@UU.NET Mon May 6 20:59:04 2002 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 UAA12597 for ; Mon, 6 May 2002 20:59:04 -0400 (EDT) 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 QQmntb25835; Tue, 7 May 2002 00:58:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQmntb08075 for mpls-outgoing; Tue, 7 May 2002 00:57:59 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 QQmntb08070 for ; Tue, 7 May 2002 00:57:54 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 QQmntb07595 for ; Tue, 7 May 2002 00:55:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmntb06526 for ; Tue, 7 May 2002 00:55:03 GMT 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 UAA14119 for ; Mon, 6 May 2002 20:55:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id UAA23267 for mpls@uu.net; Mon, 6 May 2002 20:55:03 -0400 (EDT) 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 QQmntb07950 for ; Tue, 7 May 2002 00:54:40 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 QQmntb05705 for ; Tue, 7 May 2002 00:53:46 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmntb21070 for ; Tue, 7 May 2002 00:53:44 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 UAA47786; Mon, 6 May 2002 20:48:59 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200205070048.UAA47786@workhorse.fictitious.org> To: Sudheer Dharanikota cc: Shahram Davari , "'curtis@fictitious.org'" , Gary Tam , Ajay Simha , Ron Bonica , Brijesh Kumar , mpls@UU.NET, CCAMP WG Reply-To: curtis@fictitious.org Subject: Re: Static LSP Configuration In-reply-to: Your message of "Mon, 06 May 2002 14:27:26 PDT." <3CD6F53E.52779883@nayna.com> Date: Mon, 06 May 2002 20:48:59 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3CD6F53E.52779883@nayna.com>, Sudheer Dharanikota writes: > > > > > > > I do know of providers who want to eliminate the APS on the sonet > > > links under their MPLS network cutting some costs significantly (but > > > with all things considered, not in half). > > > > What mechanism will they use to detect the failure then? > > With most of the *recent* L2/L1 technologies, failure dection is not the > only problem. > Without APS-like mechanisms (sub-second) failure reporting is also a major > problem. > In my opinion, for the sake of the underlying technologies which does not > have > APS-like reporting mechanisms, we need to optimize our signaling protocols > and propose sensible control plane topologies. > > Regards, > > sudheer SONET detection is used. SONET APS protection is not. FRR yields <50msec restroation is needed, and standby LSPs yields a few seconds at worst (consistently sub second is certainly possible with standby, but not yet acheived by today's implementations afaik). Curtis From owner-mpls@UU.NET Tue May 7 08:47:59 2002 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 IAA05464 for ; Tue, 7 May 2002 08:47:59 -0400 (EDT) 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 QQmnux09369; Tue, 7 May 2002 12:47:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnux20405 for mpls-outgoing; Tue, 7 May 2002 12:46: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 QQmnux20394 for ; Tue, 7 May 2002 12:46:33 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 QQmnux03101 for ; Tue, 7 May 2002 12:46:14 GMT From: neil.2.harrison@bt.com Received: from cbibipnt02.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmnux09221 for ; Tue, 7 May 2002 12:46:14 GMT Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Tue, 7 May 2002 13:46:17 +0100 Message-ID: To: asimha@cisco.com Cc: mpls@UU.NET Subject: RE: Static LSP Configuration Date: Tue, 7 May 2002 13:45:57 +0100 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 Ajay Simha wrote 06 May 2002 16:28 > GT> Besides, > GT>it will be too slow and costly to do protection with > GT>RSVP-signaling - ie 50ms protection. Even if you scale > > Not true. > GT>the RSVP/LDP Hello intervals to 5ms, there are lots of > GT>issues such as link flapping, lots of hellos. etc. > GT> NH=> What is not true here? If you set too fast a prot-sw trigger as you go up the network stack and closer to applications you are going to fire this on error events where it should be firing. And which applications actually need a sub-50ms prot-sw action anyway? 50ms is in SDH/Sonet because 'it was as fast as possible on such rings at that time'.....it was not driven by any applications, just the technology/physics. To chase this goal higher up the network stack without understanding *why* you are doing this is sheer folly. > > You could use sonet alarms for detection. Any how would OAM > control flow > solve any lost pkts? NH=> I'm getting a bit worried by this 'let's rely on L1 OAM for everything' statement that seems to occur frequently. SDH/Sonet does detect failures in (and below) these layers because those who designed these protocols thought about these problems in the 1st place. However, there are differences whether we are talking STM, VC4 or VC11/12 signals say, eg a failure of a VC11/12 signal does *not* necessarily assume its parent VC4 (or lower STM) trails are affected. The higher layers get told of lower level defects because the lower layer trail termination points inject a Forward Defect Indicator (FDI) towards those higher layers.....these higher layers do *not* see specific/individual raw L1 defects, eg LOL, LOF, etc....they see a generic FDI. Why? Well, there is very sound practical reason we do this, and that is to stop an explosion of higher layer alarms, ie incoming FDI means *don't* raise alarms here even though your signal has failed because the real failure is lower and elsewhere....possible even in a different country! However, you can, and sometimes must, act on these failures in the higher layer, eg stop QoS counting if you reach a point of unavailability (assuming you have defined this) or trigger prot-sw if the lower layer has not recovered in time T. The reason you need OAM mechanisms in all layer networks is that there can be failures in layer network X that are only relevant to layer network X and are not seen by lower layer network Y say. So if you get a failure in a FR, ATM or MPLS network then SDH/Sonet OAM tools won't help you a bit....you have to detect the failure within the relevent (ie lowest level) trail that is affected and raise an alarms at its trail term point, and you should inject FDI into its clinet layers to suppress alarms being raised at those trail term points as I noted earlier....this behaviour is recursive. Of course, detecting a failure won't 'solve any lost pkts' as you note, but if you don't detect the failure in the 1st place how are you going to invoke prot-sw as a corrective action? BTW the answer is not necessarily to rely on the OAM 'hello' mechanisms built-in to control-plane protocols like RSVP-TE (signalling) or an IGP (routing) because: - in some technologies these use different data-planes (more obvious for cct-sw technologies than pkt-sw technologies, eg OTNs say....but still true in both cases in princple) - in all cases they use different nodal processing components And in respect of the latter point, even when we assume very close coupling of traffic/control-plane data-planes we can still have failures of the traffic data-plane whilst the control-plane protocols think everthing is still fine.....this is why LSP-Ping was drafted as one solution to this problem, and why a more generic solution has been developed in Y.1711. From owner-mpls@UU.NET Tue May 7 11:41:51 2002 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 LAA13229 for ; Tue, 7 May 2002 11:41:51 -0400 (EDT) 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 QQmnvd16064; Tue, 7 May 2002 14:17:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnvd11165 for mpls-outgoing; Tue, 7 May 2002 14:16:42 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 QQmnvd11153 for ; Tue, 7 May 2002 14:16: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 QQmnvd04710 for ; Tue, 7 May 2002 14:16:37 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 QQmnvd17497 for ; Tue, 7 May 2002 14:16:36 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 KAA11285; Tue, 7 May 2002 10:16:31 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA06327; Tue, 7 May 2002 10:16:30 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 May 2002 10:16:29 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55763178@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org Subject: RE: How many can administrative groups assigned? Date: Tue, 7 May 2002 10:16:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ks_c_5601-1987" Sender: owner-mpls@UU.NET Precedence: bulk Kim, -> If so, how many can administrative groups assigned? 32 or 2^32 ? 32. A link can me member of multiple admin groups. -- Venkata. From owner-mpls@UU.NET Tue May 7 12:54:22 2002 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 MAA15480 for ; Tue, 7 May 2002 12:54:21 -0400 (EDT) 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 QQmnvn28787; Tue, 7 May 2002 16:52:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnvn08095 for mpls-outgoing; Tue, 7 May 2002 16:52:01 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 QQmnvn08064 for ; Tue, 7 May 2002 16:51: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 QQmnvn21892 for ; Tue, 7 May 2002 16:50:04 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnvn25460 for ; Tue, 7 May 2002 16:50:03 GMT 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 MAA23363 for ; Tue, 7 May 2002 12:50:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA25336 for mpls@uu.net; Tue, 7 May 2002 12:50:02 -0400 (EDT) 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 QQmnvn07897 for ; Tue, 7 May 2002 16:48:51 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 QQmnvn19223 for ; Tue, 7 May 2002 16:47:34 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQmnvn05019 for ; Tue, 7 May 2002 16:47:33 GMT Received: from FLEFAUCH-W2K.cisco.com (sjc-vpn3-326.cisco.com [10.21.65.70]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA23800; Tue, 7 May 2002 18:47:27 +0200 (MET DST) Message-Id: <4.3.2.7.2.20020507184352.01c69210@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 May 2002 18:47:22 +0200 To: David Charlap From: Francois Le Faucheur Subject: Re: RSVP-TE: DIFFSERV object class Cc: mpls@UU.NET, ZZhang@unispherenetworks.com In-Reply-To: <3CBD8714.4DC4DD1@marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, At 10:30 17/04/2002 -0400, David Charlap wrote: >The diff-ext draft still lists the class number for the DIFFSERV object >as "TBD". > >Is there any particular class number that people are using for their >products while waiting for an IANA-assigned number? > >-- David IANA has completed assigment of RSVP numbers required for "MPLS Support of Diff-Serv". Those can be found at : http://www.iana.org/assignments/rsvp-parameters The DIFF-SERV Class-num is 65. Cheers Francois From owner-mpls@UU.NET Tue May 7 13:58:17 2002 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 NAA18529 for ; Tue, 7 May 2002 13:58:16 -0400 (EDT) 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 QQmnvr05039; Tue, 7 May 2002 17:56:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnvr05258 for mpls-outgoing; Tue, 7 May 2002 17:56:22 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 QQmnvr05253 for ; Tue, 7 May 2002 17:56:19 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 QQmnvr16476 for ; Tue, 7 May 2002 17:56:14 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 QQmnvr03930 for ; Tue, 7 May 2002 17:56:13 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 NAA07059 for ; Tue, 7 May 2002 13:56:11 -0400 (EDT) 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 NAA14075 for ; Tue, 7 May 2002 13:56:11 -0400 (EDT) Message-ID: <3CD81561.9D7D43AE@marconi.com> Date: Tue, 07 May 2002 13:56:49 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: RSVP-TE: DIFFSERV object class References: <4.3.2.7.2.20020507184352.01c69210@europe.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Thanks much. I assume that the number will be in the next rev of the draft, if there is another one before it is released as an RFC, right? -- David Francois Le Faucheur wrote: > > Hi, > > At 10:30 17/04/2002 -0400, David Charlap wrote: > >The diff-ext draft still lists the class number for the DIFFSERV object > >as "TBD". > > > >Is there any particular class number that people are using for their > >products while waiting for an IANA-assigned number? > > > >-- David > > IANA has completed assigment of RSVP numbers required for "MPLS Support of > Diff-Serv". > Those can be found at : > http://www.iana.org/assignments/rsvp-parameters > > The DIFF-SERV Class-num is 65. > > Cheers > > Francois From owner-mpls@UU.NET Tue May 7 14:32:46 2002 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 OAA19591 for ; Tue, 7 May 2002 14:32:46 -0400 (EDT) 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 QQmnvu29388; Tue, 7 May 2002 18:31:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnvu29938 for mpls-outgoing; Tue, 7 May 2002 18:31:36 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 QQmnvu29933 for ; Tue, 7 May 2002 18:31:34 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 QQmnvu03108 for ; Tue, 7 May 2002 18:31:06 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnvu28193 for ; Tue, 7 May 2002 18:31:02 GMT 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 OAA00808 for ; Tue, 7 May 2002 14:31:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA05827 for mpls@uu.net; Tue, 7 May 2002 14:31:02 -0400 (EDT) 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 QQmnvt29710 for ; Tue, 7 May 2002 18:29: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 QQmnvt27130 for ; Tue, 7 May 2002 18:29:10 GMT Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmnvt10621 for ; Tue, 7 May 2002 18:29:10 GMT Received: (qmail 29848 invoked by uid 104); 7 May 2002 18:29:09 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4201. . Clean. Processed in 0.491265 secs); 07 May 2002 18:29:09 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 7 May 2002 18:29:08 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g47ISpp06709; Tue, 7 May 2002 11:28:52 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Tue, 7 May 2002 11:28:49 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A799@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: Sudheer Dharanikota , Gary Tam , Ajay Simha , Ron Bonica , Brijesh Kumar , mpls@UU.NET, CCAMP WG Subject: RE: Static LSP Configuration Date: Tue, 7 May 2002 11:28:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk What is the physical architecture? Is it still a ring? a single ring? -Shahram > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Sent: Monday, May 06, 2002 8:46 PM > To: Shahram Davari > Cc: 'curtis@fictitious.org'; Sudheer Dharanikota; Gary Tam; > Ajay Simha; > Ron Bonica; Brijesh Kumar; mpls@UU.NET; CCAMP WG > Subject: Re: Static LSP Configuration > > > > In message > <4B6D09F3B826D411A67300D0B706EFDE84A795@nt-exch-yow.pmc-sierra.bc.ca > > > > > > I do know of providers who want to eliminate the APS on the sonet > > > links under their MPLS network cutting some costs > significantly (but > > > with all things considered, not in half). > > > > What mechanism will they use to detect the failure then? > > SONET framing is still used. What is not used is a SONET protect > path. SONET is involved in the detection, but plays no role in the > recovery. It seems a few providers did buildouts in recent years > costing lots of money, and used SONET protect paths while there was > excess capacity. Not the most efficient, but it works great. Then as > the capacity filled but revenue had not yet met the demands of incured > debt, decided that they don't want the increased debt of a further > buildout and are seeking a more cost effective way to meet their SLAs. > > Curtis > From owner-mpls@UU.NET Tue May 7 17:45:25 2002 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 RAA24958 for ; Tue, 7 May 2002 17:45:24 -0400 (EDT) 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 QQmnwg02151; Tue, 7 May 2002 21:44:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnwg21098 for mpls-outgoing; Tue, 7 May 2002 21:43: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 QQmnwg21093 for ; Tue, 7 May 2002 21:43: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 QQmnwg18611 for ; Tue, 7 May 2002 21:42:16 GMT From: neil.2.harrison@bt.com Received: from cbibipnt02.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmnwg21080 for ; Tue, 7 May 2002 21:42:16 GMT Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Tue, 7 May 2002 22:39:20 +0100 Message-ID: To: hukulumu@yahoo.ca Cc: mpls@UU.NET Subject: RE: Static LSP Configuration Date: Tue, 7 May 2002 13:45:55 +0100 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 Sounds very reasonable to me Gary. I mean LSPs supporting VPNs should not be changing very often should they?.....they will usually be long-holding and ought to be decoupled from any arbitrary routing changes (or indeed any control-plane misbehaviour) by design. regards, Neil > -----Original Message----- > From: Gary Tam [mailto:hukulumu@yahoo.ca] > Sent: 06 May 2002 15:00 > To: Ron Bonica; Brijesh Kumar; 'Curtis Villamizar '; 'Ajay Simha ' > Cc: curtis@fictitious.org; 'gary tam '; mpls@UU.NET > Subject: RE: Static LSP Configuration > > > Thanks all, > > I think I get my answer that Cisco is not supporting > static LSP configuration. > > Oh well, ... > > Don't you think static LSP will be useful for L2 VPN > in stitching two access domains together. In most > case, the L2 Access network does not have to support > any of the complicated signaling procotocls, but still > enjoy the benifit of utilizing MPLS. See the following > example: > > (Access1) 1 - 2 (Core) 3 - 4 (Access2) > > In this example, the network operator needs only to > setup the L2 FEC at ingress LSP, assign and maintain > labels on 1,2,3,&4 as to setup the static LSP between > the two access doamins and the core network. > > In the core network ( between port 2 and 3), it can be > nested LSP trunking setup by CR-LDP/RSVP-TE. This will > not change anything in case of failure between 2 and 3 > with the obvious exception of port 2 and 3. > > The static LSP (1,2,3,4) will likely be > Martini-encapsulated Tunnel for some L2 VLAN/MPLS VCs > as well. The L2 FEC can be either MAC DA, VLAN, > Coustomer ID, and ATM VC, etc. > > Gary > > > --- Ron Bonica wrote: > > > > > > Also, on your: > > > >>btw- retorical question - with static LSPs, what > > happens when a link > > > goes down? > > > > > > Should the expected behaviour need to be any > > different than when someone > > > routes with static routes? > > > > > > Cheers, > > > > > > --brijesh > > > > > > > > > > Brijesh, > > > > Statically configured LSPs blackhole traffic when a > > link in the middle of > > the LSP fails. > > > > The LSR immediately upstream of the failure discards > > all traffic belonging > > to the LSP. This is because that LSR may not look > > beyond the MPLS label to > > forward the traffic. See RFC 3031 Sections 3.18 and > > 3.22 for details. > > > > > > Ron > > > > > ______________________________________________________________ > ________ > Games, Movies, Music & Sports! http://entertainment.yahoo.ca > From owner-mpls@UU.NET Tue May 7 17:55:08 2002 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 RAA25192 for ; Tue, 7 May 2002 17:55:08 -0400 (EDT) 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 QQmnwh04380; Tue, 7 May 2002 21:54:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnwh22081 for mpls-outgoing; Tue, 7 May 2002 21:54:11 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 QQmnwh22076 for ; Tue, 7 May 2002 21:54:08 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 QQmnwh24113 for ; Tue, 7 May 2002 21:53:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnwh02637 for ; Tue, 7 May 2002 21:53:02 GMT 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 RAA13797 for ; Tue, 7 May 2002 17:53:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA25792 for mpls@uu.net; Tue, 7 May 2002 17:53:02 -0400 (EDT) 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 QQmnwh21953 for ; Tue, 7 May 2002 21:52:04 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 QQmnwh16483 for ; Tue, 7 May 2002 21:51:07 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmnwh11631 for ; Tue, 7 May 2002 21:51:06 GMT Received: (qmail 22085 invoked by uid 104); 7 May 2002 21:51:01 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4201. . Clean. Processed in 0.577657 secs); 07 May 2002 21:51:01 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 7 May 2002 21:51:00 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g47Lovp14131; Tue, 7 May 2002 14:50:57 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Tue, 7 May 2002 14:51:01 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A79D@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'neil.2.harrison@bt.com'" , hukulumu@yahoo.ca Cc: mpls@UU.NET Subject: RE: Static LSP Configuration Date: Tue, 7 May 2002 14:50:57 -0700 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 As another example customers could be assigned a fix label, and be multiplexed to the same access link, The PE could use the label to differentiate between them. No need to run LDP in customer CE. -Shahram > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Tuesday, May 07, 2002 8:46 AM > To: hukulumu@yahoo.ca > Cc: mpls@UU.NET > Subject: RE: Static LSP Configuration > > > Sounds very reasonable to me Gary. I mean LSPs supporting > VPNs should not > be changing very often should they?.....they will usually be > long-holding > and ought to be decoupled from any arbitrary routing changes > (or indeed any > control-plane misbehaviour) by design. > > regards, Neil > > > -----Original Message----- > > From: Gary Tam [mailto:hukulumu@yahoo.ca] > > Sent: 06 May 2002 15:00 > > To: Ron Bonica; Brijesh Kumar; 'Curtis Villamizar '; 'Ajay Simha ' > > Cc: curtis@fictitious.org; 'gary tam '; mpls@UU.NET > > Subject: RE: Static LSP Configuration > > > > > > Thanks all, > > > > I think I get my answer that Cisco is not supporting > > static LSP configuration. > > > > Oh well, ... > > > > Don't you think static LSP will be useful for L2 VPN > > in stitching two access domains together. In most > > case, the L2 Access network does not have to support > > any of the complicated signaling procotocls, but still > > enjoy the benifit of utilizing MPLS. See the following > > example: > > > > (Access1) 1 - 2 (Core) 3 - 4 (Access2) > > > > In this example, the network operator needs only to > > setup the L2 FEC at ingress LSP, assign and maintain > > labels on 1,2,3,&4 as to setup the static LSP between > > the two access doamins and the core network. > > > > In the core network ( between port 2 and 3), it can be > > nested LSP trunking setup by CR-LDP/RSVP-TE. This will > > not change anything in case of failure between 2 and 3 > > with the obvious exception of port 2 and 3. > > > > The static LSP (1,2,3,4) will likely be > > Martini-encapsulated Tunnel for some L2 VLAN/MPLS VCs > > as well. The L2 FEC can be either MAC DA, VLAN, > > Coustomer ID, and ATM VC, etc. > > > > Gary > > > > > > --- Ron Bonica wrote: > > > > > > > > Also, on your: > > > > >>btw- retorical question - with static LSPs, what > > > happens when a link > > > > goes down? > > > > > > > > Should the expected behaviour need to be any > > > different than when someone > > > > routes with static routes? > > > > > > > > Cheers, > > > > > > > > --brijesh > > > > > > > > > > > > > > Brijesh, > > > > > > Statically configured LSPs blackhole traffic when a > > > link in the middle of > > > the LSP fails. > > > > > > The LSR immediately upstream of the failure discards > > > all traffic belonging > > > to the LSP. This is because that LSR may not look > > > beyond the MPLS label to > > > forward the traffic. See RFC 3031 Sections 3.18 and > > > 3.22 for details. > > > > > > > > > Ron > > > > > > > > > ______________________________________________________________ > > ________ > > Games, Movies, Music & Sports! http://entertainment.yahoo.ca > > > From owner-mpls@UU.NET Tue May 7 17:59:15 2002 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 RAA25294 for ; Tue, 7 May 2002 17:59:14 -0400 (EDT) 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 QQmnwh08920; Tue, 7 May 2002 21:57:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnwh22464 for mpls-outgoing; Tue, 7 May 2002 21:57: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 QQmnwh22441 for ; Tue, 7 May 2002 21:57:08 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 QQmnwh13037 for ; Tue, 7 May 2002 21:56:06 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnwh07052 for ; Tue, 7 May 2002 21:56:05 GMT 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 RAA13969 for ; Tue, 7 May 2002 17:56:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA26146 for mpls@uu.net; Tue, 7 May 2002 17:56:05 -0400 (EDT) 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 QQmnwh22121 for ; Tue, 7 May 2002 21:54:59 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 QQmnwh19561 for ; Tue, 7 May 2002 21:54:38 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmnwh06335 for ; Tue, 7 May 2002 21:54:37 GMT Received: (qmail 18945 invoked by uid 104); 7 May 2002 21:54:36 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4201. . Clean. Processed in 0.450494 secs); 07 May 2002 21:54:36 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 7 May 2002 21:54:35 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g47LsWp15189; Tue, 7 May 2002 14:54:32 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Tue, 7 May 2002 14:54:36 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A79E@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'neil.2.harrison@bt.com'" , hukulumu@yahoo.ca Cc: mpls@UU.NET Subject: RE: Static LSP Configuration Date: Tue, 7 May 2002 14:54:34 -0700 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 Some one at Cisco told me that there is a way to do it in Cisco CLI, but it will be officially supported in future. -Shahram > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Tuesday, May 07, 2002 8:46 AM > To: hukulumu@yahoo.ca > Cc: mpls@UU.NET > Subject: RE: Static LSP Configuration > > > Sounds very reasonable to me Gary. I mean LSPs supporting > VPNs should not > be changing very often should they?.....they will usually be > long-holding > and ought to be decoupled from any arbitrary routing changes > (or indeed any > control-plane misbehaviour) by design. > > regards, Neil > > > -----Original Message----- > > From: Gary Tam [mailto:hukulumu@yahoo.ca] > > Sent: 06 May 2002 15:00 > > To: Ron Bonica; Brijesh Kumar; 'Curtis Villamizar '; 'Ajay Simha ' > > Cc: curtis@fictitious.org; 'gary tam '; mpls@UU.NET > > Subject: RE: Static LSP Configuration > > > > > > Thanks all, > > > > I think I get my answer that Cisco is not supporting > > static LSP configuration. > > > > Oh well, ... > > > > Don't you think static LSP will be useful for L2 VPN > > in stitching two access domains together. In most > > case, the L2 Access network does not have to support > > any of the complicated signaling procotocls, but still > > enjoy the benifit of utilizing MPLS. See the following > > example: > > > > (Access1) 1 - 2 (Core) 3 - 4 (Access2) > > > > In this example, the network operator needs only to > > setup the L2 FEC at ingress LSP, assign and maintain > > labels on 1,2,3,&4 as to setup the static LSP between > > the two access doamins and the core network. > > > > In the core network ( between port 2 and 3), it can be > > nested LSP trunking setup by CR-LDP/RSVP-TE. This will > > not change anything in case of failure between 2 and 3 > > with the obvious exception of port 2 and 3. > > > > The static LSP (1,2,3,4) will likely be > > Martini-encapsulated Tunnel for some L2 VLAN/MPLS VCs > > as well. The L2 FEC can be either MAC DA, VLAN, > > Coustomer ID, and ATM VC, etc. > > > > Gary > > > > > > --- Ron Bonica wrote: > > > > > > > > Also, on your: > > > > >>btw- retorical question - with static LSPs, what > > > happens when a link > > > > goes down? > > > > > > > > Should the expected behaviour need to be any > > > different than when someone > > > > routes with static routes? > > > > > > > > Cheers, > > > > > > > > --brijesh > > > > > > > > > > > > > > Brijesh, > > > > > > Statically configured LSPs blackhole traffic when a > > > link in the middle of > > > the LSP fails. > > > > > > The LSR immediately upstream of the failure discards > > > all traffic belonging > > > to the LSP. This is because that LSR may not look > > > beyond the MPLS label to > > > forward the traffic. See RFC 3031 Sections 3.18 and > > > 3.22 for details. > > > > > > > > > Ron > > > > > > > > > ______________________________________________________________ > > ________ > > Games, Movies, Music & Sports! http://entertainment.yahoo.ca > > > From owner-mpls@UU.NET Tue May 7 18:05:48 2002 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 SAA25417 for ; Tue, 7 May 2002 18:05:47 -0400 (EDT) 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 QQmnwi19557; Tue, 7 May 2002 22:04:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnwi04656 for mpls-outgoing; Tue, 7 May 2002 22:04: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 QQmnwi04647 for ; Tue, 7 May 2002 22:04: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 QQmnwi08867 for ; Tue, 7 May 2002 22:03:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnwi17106 for ; Tue, 7 May 2002 22:03:02 GMT 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 SAA14315 for ; Tue, 7 May 2002 18:03:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA28526 for mpls@uu.net; Tue, 7 May 2002 18:03:02 -0400 (EDT) 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 QQmnwi28326 for ; Tue, 7 May 2002 22:02:00 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 QQmnwi18434 for ; Tue, 7 May 2002 22:00:53 GMT Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmnwi25047 for ; Tue, 7 May 2002 22:00:51 GMT Received: (qmail 21583 invoked by uid 104); 7 May 2002 22:00:50 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4201. . Clean. Processed in 0.445052 secs); 07 May 2002 22:00:50 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 7 May 2002 22:00:50 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g47M0fp19530; Tue, 7 May 2002 15:00:41 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Tue, 7 May 2002 15:00:45 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A79F@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau'" Cc: "'Sukanta ganguly'" , Ron Bonica , Brijesh Kumar , "'Curtis Villamizar '" , "'Ajay Simha '" , curtis@fictitious.org, "'gary tam '" , mpls@UU.NET Subject: RE: Static LSP Configuration Date: Tue, 7 May 2002 15:00:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Why not? Imagine this example that I gave in another email: Customers could be assigned a fix label, and be multiplexed to the same access link, The PE could use the label to differentiate between them. No need to run LDP in customer CE. -Shahram > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Monday, May 06, 2002 9:56 AM > To: Shahram Davari > Cc: 'Sukanta ganguly'; Ron Bonica; Brijesh Kumar; 'Curtis > Villamizar '; > 'Ajay Simha '; curtis@fictitious.org; 'gary tam '; mpls@UU.NET > Subject: RE: Static LSP Configuration > > > > > >If one wants to have only 2 LSPs (one working and one backup) in his > >network, why should > >he run LDP? > > Because 2 LSPs is not a realistic example. > > --Tom > > > > >-Shahram > > > > > -----Original Message----- > > > From: Sukanta ganguly [mailto:sganguly@yahoo.com] > > > Sent: Sunday, May 05, 2002 1:43 PM > > > To: Ron Bonica; Brijesh Kumar; 'Curtis Villamizar '; 'Ajay Simha ' > > > Cc: curtis@fictitious.org; 'gary tam '; mpls@UU.NET > > > Subject: RE: Static LSP Configuration > > > > > > > > > In a fairly controlled and static environment it may > > > work, but in other situations it will create > > > unresolved links and packet drops, with no recovery to > > > the failure. > > > > > > SG > > > > > > --- Ron Bonica wrote: > > > > > > > > > > Also, on your: > > > > > >>btw- retorical question - with static LSPs, what > > > > happens when a link > > > > > goes down? > > > > > > > > > > Should the expected behaviour need to be any > > > > different than when someone > > > > > routes with static routes? > > > > > > > > > > Cheers, > > > > > > > > > > --brijesh > > > > > > > > > > > > > > > > > > Brijesh, > > > > > > > > Statically configured LSPs blackhole traffic when a > > > > link in the middle of > > > > the LSP fails. > > > > > > > > The LSR immediately upstream of the failure discards > > > > all traffic belonging > > > > to the LSP. This is because that LSR may not look > > > > beyond the MPLS label to > > > > forward the traffic. See RFC 3031 Sections 3.18 and > > > > 3.22 for details. > > > > > > > > > > > > Ron > > > > > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Yahoo! Health - your guide to health and wellness > > > http://health.yahoo.com > > > > > > > -------------------------------------------------------------- > ---------- > Mathematics is the supreme nostalgia of our time. > From owner-mpls@UU.NET Wed May 8 00:33:07 2002 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 AAA03544 for ; Wed, 8 May 2002 00:33:07 -0400 (EDT) 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 QQmnxi09988; Wed, 8 May 2002 04:31:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnxi25427 for mpls-outgoing; Wed, 8 May 2002 04:31: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 QQmnxi25422 for ; Wed, 8 May 2002 04:31: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 QQmnxi06317 for ; Wed, 8 May 2002 04:30:59 GMT Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQmnxi17214 for ; Wed, 8 May 2002 04:30:57 GMT Received: by BRAHMA01 with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 10:00:53 +0530 Message-ID: <9027F68B07E7D511AE9400B0D0787DC00704A9@BRAHMA01> From: Manoj Agiwal To: "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Subject: Label Set Object Date: Wed, 8 May 2002 10:00: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 Hi , In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on gmpls has described Label Set object usage only for the "optical" domain viz. for carrying wavelengths ( Section 9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . Do we require to send Label set(i.e. time slots) for TDM switching as well . In what way it can be useful . Regards , Manoj From owner-mpls@UU.NET Wed May 8 01:38:04 2002 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 BAA04334 for ; Wed, 8 May 2002 01:38:03 -0400 (EDT) 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 QQmnxm09095; Wed, 8 May 2002 05:37:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnxm22419 for mpls-outgoing; Wed, 8 May 2002 05:36: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 QQmnxm22414 for ; Wed, 8 May 2002 05:36: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 QQmnxm29575 for ; Wed, 8 May 2002 05:36:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnxm07392 for ; Wed, 8 May 2002 05:36:05 GMT 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 BAA02487 for ; Wed, 8 May 2002 01:36:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA11990 for mpls@uu.net; Wed, 8 May 2002 01:36:01 -0400 (EDT) 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 QQmnxm22203 for ; Wed, 8 May 2002 05:35:12 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 QQmnxm00275 for ; Wed, 8 May 2002 05:34:58 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sword.cisco.com [161.44.208.100]) id QQmnxm06252 for ; Wed, 8 May 2002 05:34:58 GMT Received: from ZALI-W2K.cisco.com (che-vpn2-25.cisco.com [10.86.244.25]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id BAA12899; Wed, 8 May 2002 01:34:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20020508013112.04570cc8@sword.cisco.com> X-Sender: zali@sword.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 May 2002 01:34:43 -0400 To: Manoj Agiwal , "'Ccamp (E-mail)" From: Zafar Ali Subject: Re: Label Set Object Cc: "mpls@UU. NET (E-mail)" In-Reply-To: <9027F68B07E7D511AE9400B0D0787DC00704A9@BRAHMA01> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_10629654==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_10629654==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >Hi , > In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on >gmpls has described Label Set object usage > only for the "optical" domain viz. for carrying wavelengths ( Section >9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . > > Do we require to send Label set(i.e. time slots) for TDM switching as >well . In what way it can be useful . Dear Manoj, Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions. The label set object can be used to constrain the downstream label to the same as the upstream label. Thanks Regards... Zafar >Regards , >Manoj =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com --=====================_10629654==_.ALT Content-Type: text/html; charset="us-ascii" At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .

Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar



Regards ,
Manoj

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com --=====================_10629654==_.ALT-- From owner-mpls@UU.NET Wed May 8 01:43:07 2002 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 BAA04424 for ; Wed, 8 May 2002 01:43:07 -0400 (EDT) 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 QQmnxm16167; Wed, 8 May 2002 05:42:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnxm22804 for mpls-outgoing; Wed, 8 May 2002 05:41: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 QQmnxm22799 for ; Wed, 8 May 2002 05:41:53 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 QQmnxm27802 for ; Wed, 8 May 2002 05:41:11 GMT Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQmnxm04058 for ; Wed, 8 May 2002 05:41:09 GMT Received: by BRAHMA01 with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 11:11:01 +0530 Message-ID: <9027F68B07E7D511AE9400B0D0787DC00704AA@BRAHMA01> From: Manoj Agiwal To: "'Zafar Ali'" , Manoj Agiwal , "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Subject: RE: Label Set Object Date: Wed, 8 May 2002 11:11:01 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F652.EFA45500" 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_01C1F652.EFA45500 Content-Type: text/plain; charset="iso-8859-1" Hi , I guess in that case we can use Suggested Label , Label Set still can still be avoided . Regards , Manoj -----Original Message----- From: Zafar Ali [mailto:zali@cisco.com] Sent: Wednesday, May 08, 2002 11:05 AM To: Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: Re: Label Set Object At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: Hi , In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on gmpls has described Label Set object usage only for the "optical" domain viz. for carrying wavelengths ( Section 9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . Do we require to send Label set(i.e. time slots) for TDM switching as well . In what way it can be useful . Dear Manoj, Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions. The label set object can be used to constrain the downstream label to the same as the upstream label. Thanks Regards... Zafar Regards , Manoj =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com ------_=_NextPart_001_01C1F652.EFA45500 Content-Type: text/html; charset="iso-8859-1"
Hi ,
   I guess in that case we can use Suggested Label , Label Set still can still be avoided .
Regards ,
Manoj
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 11:05 AM
To: Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: Re: Label Set Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .

Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar



Regards ,
Manoj

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
------_=_NextPart_001_01C1F652.EFA45500-- From owner-mpls@UU.NET Wed May 8 01:56:49 2002 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 BAA04560 for ; Wed, 8 May 2002 01:56:48 -0400 (EDT) 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 QQmnxn05099; Wed, 8 May 2002 05:56:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnxn23936 for mpls-outgoing; Wed, 8 May 2002 05:55: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 QQmnxn23931 for ; Wed, 8 May 2002 05:55:49 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 QQmnxn15243 for ; Wed, 8 May 2002 05:55:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnxn03659 for ; Wed, 8 May 2002 05:55:02 GMT 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 BAA03669 for ; Wed, 8 May 2002 01:55:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA14366 for mpls@uu.net; Wed, 8 May 2002 01:55:02 -0400 (EDT) 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 QQmnxn23875 for ; Wed, 8 May 2002 05:53:54 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 QQmnxn23240 for ; Wed, 8 May 2002 05:53:25 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sword.cisco.com [161.44.208.100]) id QQmnxn00199 for ; Wed, 8 May 2002 05:53:25 GMT Received: from ZALI-W2K.cisco.com (che-vpn2-25.cisco.com [10.86.244.25]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id BAA13273; Wed, 8 May 2002 01:53:07 -0400 (EDT) Message-Id: <4.3.2.7.2.20020508014732.04577e60@sword.cisco.com> X-Sender: zali@sword.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 May 2002 01:53:05 -0400 To: Manoj Agiwal , Manoj Agiwal , "'Ccamp (E-mail)" From: Zafar Ali Subject: RE: Label Set Object Cc: "mpls@UU. NET (E-mail)" In-Reply-To: <9027F68B07E7D511AE9400B0D0787DC00704AA@BRAHMA01> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_11732159==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_11732159==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:11 AM 5/8/2002 +0530, Manoj Agiwal wrote: >Hi , > I guess in that case we can use Suggested Label , Label Set still can > still be avoided . Hi Manoj, No, the use of suggested label in this case would NOT be correct, as the suggested labels can be ignored/ overridden by the receiving node. Thanks Regards... Zafar >Regards , >Manoj >-----Original Message----- >From: Zafar Ali [mailto:zali@cisco.com] >Sent: Wednesday, May 08, 2002 11:05 AM >To: Manoj Agiwal; 'Ccamp (E-mail) >Cc: mpls@UU. NET (E-mail) >Subject: Re: Label Set Object > >At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>Hi , >> In gmpls signaling extensionsions for RSVP-TE , ccamp >> architecture on >>gmpls has described Label Set object usage >> only for the "optical" domain viz. for carrying wavelengths ( Section >>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . >> >> Do we require to send Label set(i.e. time slots) for TDM >> switching as >>well . In what way it can be useful . >Dear Manoj, > >Yes, label set object is also useful in TDM case. E.g., SONET poses an >additional requirement that the two interfaces of a bidirectional LSP >SHOULD traverse the exact same link with the same SUKLM values for the two >directions. > The label set object can be used to constrain the downstream label to > the same as the upstream label. > >Thanks > >Regards... Zafar > > > > > >>Regards , >>Manoj >=============== >Zafar Ali >Cisco Systems >(734) 276-2459 >100 S Main St. #200 >Ann Arbor, MI 48104. >email: zali@cisco.com =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com --=====================_11732159==_.ALT Content-Type: text/html; charset="us-ascii" At 11:11 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
   I guess in that case we can use Suggested Label , Label Set still can still be avoided .

Hi Manoj,

No, the use of suggested label in this case would NOT be correct, as the suggested labels can be ignored/ overridden by the receiving node.

Thanks

Regards... Zafar

Regards ,
Manoj
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 11:05 AM
To: Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: Re: Label Set Object
At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .
Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar





Regards ,
Manoj
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
 --=====================_11732159==_.ALT-- From owner-mpls@UU.NET Wed May 8 04:17:38 2002 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 EAA28704 for ; Wed, 8 May 2002 04:17:37 -0400 (EDT) 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 QQmnxx28723; Wed, 8 May 2002 08:16:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnxx10979 for mpls-outgoing; Wed, 8 May 2002 08:16: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 QQmnxx10974 for ; Wed, 8 May 2002 08:16:21 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 QQmnxx04811 for ; Wed, 8 May 2002 08:16:13 GMT From: sven.van_den_bosch@alcatel.be Received: from bt0g2p.god.bel.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc250.alcatel.be [195.207.101.250]) id QQmnxx19624 for ; Wed, 8 May 2002 08:16:12 GMT Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id g488E3626082; Wed, 8 May 2002 10:14:03 +0200 Subject: RE: How many can administrative groups assigned? To: "Naidu, Venkata" Cc: "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 8 May 2002 10:15:50 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 05/08/2002 10:15:52 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Naidu, Kim, I think it depends a little bit on the interpretation. In principle the resource classes can be interpreted either as a bit mask (in which case 32 'base' classes can be defined) or as an integer value (in which case 2^32 values can be used). Even with the bit mask interpretation, derived resource classes can be built by combining multiple non-mutually exclusive 'base' classes (you could have 32 generic classes called 1, 2, 3 and so on and then build your resource classes on top of those). The problem lies of course in the processing of the resource class information. If they are not used in a simple bitmask, an AND operation is not sufficient to determine the resource class of a link. Also, if a link would have multiple derived classes, different TLVs would be needed. It would make sense to expand a little bit on these issues in the appropriate documents. In my opinion, this is a general issue with the TE extensions, so it should be explained there. Sven. "Naidu, Venkata" on 07/05/2002 16:16:29 To: "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org cc: (bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject RE: How many can administrative groups : assigned? Kim, -> If so, how many can administrative groups assigned? 32 or 2^32 ? 32. A link can me member of multiple admin groups. -- Venkata. From owner-mpls@UU.NET Wed May 8 04:36:49 2002 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 EAA28960 for ; Wed, 8 May 2002 04:36:49 -0400 (EDT) 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 QQmnxy02811; Wed, 8 May 2002 08:35:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnxy12025 for mpls-outgoing; Wed, 8 May 2002 08:34: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 QQmnxy12018 for ; Wed, 8 May 2002 08:34:48 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 QQmnxy28385 for ; Wed, 8 May 2002 08:33:53 GMT Received: from wiprom2mx1.wipro.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQmnxy01096 for ; Wed, 8 May 2002 08:33:52 GMT Received: from m2vwall2 (m2vwall2.wipro.com [164.164.29.236]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g488XnZ20603 for ; Wed, 8 May 2002 14:03:49 +0530 (IST) Received: from prasanth ([10.117.3.145]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GVSAG600.97M; Wed, 8 May 2002 14:03:42 +0530 From: "Ravi Sankar Mantha" To: , "Naidu Venkata" Cc: "'???'" , , "CCAMP" , Subject: RE: How many can administrative groups assigned? Date: Wed, 8 May 2002 14:06:38 +0530 Message-ID: <001d01c1f66b$7855b160$9103750a@wipro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-c626db9a-4923-4cf1-aec8-fad5a87f276f" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPartTM-000-c626db9a-4923-4cf1-aec8-fad5a87f276f Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit According to RFC 3212 (Constraint-Based LSP Setup using LDP ), the definition of "RsCls " (32bit) field of the Resource Class TLV is, 'The Resource Class bit mask indicating which of the 32 "administrative groupsö or "colorsö of links the CR-LSP can traverse. ' That should mean that the resource classes should be linterpreted as a bit mask. regards, Ravi -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of sven.van_den_bosch@alcatel.be Sent: Wednesday, May 08, 2002 1:46 PM To: Naidu, Venkata Cc: '???'; mpls@UU.NET; CCAMP; te-wg@ops.ietf.org Subject: RE: How many can administrative groups assigned? Naidu, Kim, I think it depends a little bit on the interpretation. In principle the resource classes can be interpreted either as a bit mask (in which case 32 'base' classes can be defined) or as an integer value (in which case 2^32 values can be used). Even with the bit mask interpretation, derived resource classes can be built by combining multiple non-mutually exclusive 'base' classes (you could have 32 generic classes called 1, 2, 3 and so on and then build your resource classes on top of those). The problem lies of course in the processing of the resource class information. If they are not used in a simple bitmask, an AND operation is not sufficient to determine the resource class of a link. Also, if a link would have multiple derived classes, different TLVs would be needed. It would make sense to expand a little bit on these issues in the appropriate documents. In my opinion, this is a general issue with the TE extensions, so it should be explained there. Sven. "Naidu, Venkata" on 07/05/2002 16:16:29 To: "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org cc: (bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject RE: How many can administrative groups : assigned? Kim, -> If so, how many can administrative groups assigned? 32 or 2^32 ? 32. A link can me member of multiple admin groups. -- Venkata. ------=_NextPartTM-000-c626db9a-4923-4cf1-aec8-fad5a87f276f Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer********************************************************* Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ************************************************************************************************ ------=_NextPartTM-000-c626db9a-4923-4cf1-aec8-fad5a87f276f-- From owner-mpls@UU.NET Wed May 8 07:31:53 2002 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 HAA01326 for ; Wed, 8 May 2002 07:31:52 -0400 (EDT) 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 QQmnyk17572; Wed, 8 May 2002 11:30:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnyk01648 for mpls-outgoing; Wed, 8 May 2002 11:30:32 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 QQmnyk01643 for ; Wed, 8 May 2002 11:30:20 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 QQmnyk21941 for ; Wed, 8 May 2002 11:30:07 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnyk02512 for ; Wed, 8 May 2002 11:30:03 GMT 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 HAA11290 for ; Wed, 8 May 2002 07:30:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA16456 for mpls@uu.net; Wed, 8 May 2002 07:30:02 -0400 (EDT) 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 QQmnyj01578 for ; Wed, 8 May 2002 11:29:16 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 QQmnyj17808 for ; Wed, 8 May 2002 11:28:18 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 QQmnyj14217 for ; Wed, 8 May 2002 11:28:18 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00914; Wed, 8 May 2002 07:28:09 -0400 (EDT) Message-Id: <200205081128.HAA00914@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-lsp-query-04.txt Date: Wed, 08 May 2002 07:28:09 -0400 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 : Multi Protocol Label Switching Label Distribution Protocol Query Message Description Author(s) : P. Ashwood-Smih, A. Paraschiv Filename : draft-ietf-mpls-lsp-query-04.txt Pages : 18 Date : 07-May-02 This document describes the encoding and procedures for three new Label Distribution Protocol (LDP) messages: Query Message, Query- Reply Message and Partial Query-Reply Message (the last one is almost identical to the Query-Reply message; therefore all references to the Query-Reply messages imply the Partial Query-Reply messages as well, unless otherwise specified). A Lable Edge Router (LER) sends a Query message when it needs to find out information about a Label Switched Path (LSP). The Query message is sent for an established LSP. The Query message can be used for LDP LSPs as well as for Constraint- Based Label Switched Paths (CR-LSPs). The queried data is encoded into the Query-Reply messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-query-04.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-lsp-query-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsp-query-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020507124322.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-query-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-query-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020507124322.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed May 8 10:30:23 2002 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 KAA09092 for ; Wed, 8 May 2002 10:30:23 -0400 (EDT) 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 QQmnyv16086; Wed, 8 May 2002 14:29:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnyv21456 for mpls-outgoing; Wed, 8 May 2002 14:29:13 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 QQmnyv21451 for ; Wed, 8 May 2002 14:29: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 QQmnyv27265 for ; Wed, 8 May 2002 14:28:38 GMT Received: from wiprom2mx1.wipro.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQmnyv16767 for ; Wed, 8 May 2002 14:28:37 GMT Received: from m2vwall2 (m2vwall2.wipro.com [164.164.29.236]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g48ESPZ19163 for ; Wed, 8 May 2002 19:58:30 +0530 (IST) Received: from Vinayhv ([10.117.3.140]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GVSQV500.676; Wed, 8 May 2002 19:58:17 +0530 Message-ID: <010001c1f69c$5bfe2d40$8c03750a@wipro.com> From: "Vinay Vernekar" To: "Manoj Agiwal" , "'Ccamp (E-mail)" , "Zafar Ali" Cc: "mpls@UU. NET (E-mail)" References: <4.3.2.7.2.20020508013112.04570cc8@sword.cisco.com> Subject: Re: Label Set Object Date: Wed, 8 May 2002 19:56:34 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-4beff982-88c9-4df4-81aa-9782f2259d26" 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. ------=_NextPartTM-000-4beff982-88c9-4df4-81aa-9782f2259d26 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FD_01C1F6CA.74917140" ------=_NextPart_000_00FD_01C1F6CA.74917140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Zafar, The Label Set Object can't be sent to constrain the downstream label = when the LSP encoding type is Sonet/SDH. Consider the example where a = request is sent to downstream with SONET/SDH traffic parameters as = NVC=3Dn and MT=3Dm. The label expected from the downstream would be 'm' = set of labels each set consisting of 'n' labels further that identify = each of the virtual concatenated components. So a Label Set in this = scenario would consist of say 'p' sets each consisting of 'm' sets of = 'n' labels. Such a Label Set cannot be encoded using the object/TLV = structure of Label Set as in "Generalized MPLS - Signalling Functional = Description - draft-ietf-mpls-generalized-signaling-08.txt".=20 Label Set Object can be sent only in WDM scenario where a single = wavelength is requested as a label and the upstream has a restriction on = the usable wavelengths. Correct me if I am going wrong anywhere. Regards Vinay =20 ----- Original Message -----=20 From: Zafar Ali=20 To: Manoj Agiwal ; 'Ccamp (E-mail)=20 Cc: mpls@UU. NET (E-mail)=20 Sent: Wednesday, May 08, 2002 11:04 AM Subject: Re: Label Set Object At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: Hi , In gmpls signaling extensionsions for RSVP-TE , ccamp = architecture on gmpls has described Label Set object usage only for the "optical" domain viz. for carrying wavelengths ( = Section 9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .=20 Do we require to send Label set(i.e. time slots) for TDM = switching as well . In what way it can be useful .=20 Dear Manoj,=20 Yes, label set object is also useful in TDM case. E.g., SONET poses an = additional requirement that the two interfaces of a bidirectional LSP = SHOULD traverse the exact same link with the same SUKLM values for the = two directions. The label set object can be used to constrain the downstream label to = the same as the upstream label.=20 Thanks Regards... Zafar=20 Regards , Manoj =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com=20 ------=_NextPart_000_00FD_01C1F6CA.74917140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Zafar,
The Label Set Object can't be sent to = constrain the=20 downstream label when the LSP encoding type is Sonet/SDH. Consider = the=20 example where a request is sent to downstream with SONET/SDH traffic = parameters=20 as NVC=3Dn and MT=3Dm. The label expected from the downstream would be = 'm' set of=20 labels each set consisting of 'n' labels further that identify each of = the=20 virtual concatenated components. So a Label Set in this scenario would = consist=20 of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label = Set=20 cannot be encoded using the object/TLV structure of Label Set as in = "Generalized MPLS - Signalling Functional Description -=20 draft-ietf-mpls-generalized-signaling-08.txt". 
Label Set Object can be sent only in WDM = scenario where a=20 single wavelength is requested as a label and the upstream has a = restriction on=20 the usable wavelengths.
Correct me if I am going wrong = anywhere.
 
Regards
Vinay   
----- Original Message -----
From:=20 Zafar Ali =
To: Manoj Agiwal ; 'Ccamp = (E-mail)=20
Cc: mpls@UU. NET = (E-mail)
Sent: Wednesday, May 08, 2002 = 11:04=20 AM
Subject: Re: Label Set = Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal = wrote:
Hi = ,
       In=20 gmpls signaling extensionsions for RSVP-TE , ccamp architecture = on
gmpls=20 has described Label Set object usage
    only for = the=20 "optical" domain viz. for carrying wavelengths ( Section
9.9=20 draft-ietf-ccamp-gmpls-architecture-02.txt) .=20

       Do we require to send = Label=20 set(i.e. time slots) for TDM switching as
well . In what way it = can be=20 useful .

Dear Manoj, =

Yes, label=20 set object is also useful in TDM case. E.g., SONET poses an additional = requirement that the two interfaces of a bidirectional LSP SHOULD = traverse the=20 exact same link with the same SUKLM values for the two=20 directions.
 The label set object can be used to constrain the = downstream label to the same as the upstream label.=20

Thanks

Regards... Zafar



Regards=20 = ,
Manoj

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= BR>Zafar Ali
Cisco=20 Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI=20 48104.
email: zali@cisco.com ------=_NextPart_000_00FD_01C1F6CA.74917140-- ------=_NextPartTM-000-4beff982-88c9-4df4-81aa-9782f2259d26 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************************** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. **************************************************************************************** ------=_NextPartTM-000-4beff982-88c9-4df4-81aa-9782f2259d26-- From owner-mpls@UU.NET Wed May 8 12:16:07 2002 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 MAA15137 for ; Wed, 8 May 2002 12:16:07 -0400 (EDT) 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 QQmnzd13049; Wed, 8 May 2002 16:15:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnzc13353 for mpls-outgoing; Wed, 8 May 2002 16:14: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 QQmnzc13348 for ; Wed, 8 May 2002 16:14: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 QQmnzc02206 for ; Wed, 8 May 2002 16:14:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnzc20117 for ; Wed, 8 May 2002 16:14:02 GMT 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 MAA29793 for ; Wed, 8 May 2002 12:14:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA14330 for mpls@uu.net; Wed, 8 May 2002 12:14:02 -0400 (EDT) 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 QQmnzc13303 for ; Wed, 8 May 2002 16:13: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 QQmnzc22017 for ; Wed, 8 May 2002 16:12:50 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmnzc09645 for ; Wed, 8 May 2002 16:12:43 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 MAA53327; Wed, 8 May 2002 12:12:01 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200205081612.MAA53327@workhorse.fictitious.org> To: Shahram Davari cc: "'Sukanta ganguly'" , Ron Bonica , Brijesh Kumar , "'Curtis Villamizar '" , "'Ajay Simha '" , curtis@fictitious.org, "'gary tam '" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Static LSP Configuration In-reply-to: Your message of "Mon, 06 May 2002 06:31:41 PDT." <4B6D09F3B826D411A67300D0B706EFDE84A782@nt-exch-yow.pmc-sierra.bc.ca> Date: Wed, 08 May 2002 12:12:01 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4B6D09F3B826D411A67300D0B706EFDE84A782@nt-exch-yow.pmc-sierra.bc.ca >, Shahram Davari writes: > Hi, > > If one wants to have only 2 LSPs (one working and one backup) in his network, > why should > he run LDP? > > -Shahram The obvious answer is so when the next Amtrak train hits fiber on both sides of the track, [for brevity omit dozens of other examples of multiple failures, some massive, that have occurred in the last 5-10 years], there is still a connection. But this may be to "core" centric. Static IP routes are fine for something that has only one path to "the rest of the world". That is unacceptable to an IP provider but OK for customer circuits in cases where cost outweighs possibility of lengthy outage. In this circumstance, configuration is simple. From the provider, customer network it "that way"; from the customer the rest of the world (IP default route) is "the other way". Unlike static IP, static LSP does not offer the simplification of configuration. If there is a singly connected "last mile" over which a subset of IP traffic is a tunnelled L2 circuit, then it makes sense to advertise LDP and BGP (filtered, just like IP routes to the customer are filtered), and allow the BGP-VPN to establish the E2E LSP needed for the VPN. If the BGP-VPN is moved to the other side of that last mile, then the access router (provider side of customer circuit) has a bit more work to do and the CPE has a static. This is no less work for the provider and is one more thing that can become inconsistent do to slight misconfiguration and fail. Even if the provider were to take this approach, the provider edge would have LDP (optionally over TE) on the core side. In one case there would be filters programmed on the provider edge and limited LDP and BGP exchange. In the other case, a fixed label and interface would be directed into a LDP tunnel. At the other end the mapping would have to be reversed. In the dynamic case, there is configuration only at the ingress (CPE) for each direction. In the static case, for each direction four routers must have static configurations that match and the provider edge router must have a label mapping for each customer VPN and each customer prefix rather than just for each customer prefix. Unlike static IP this does not simplify configuration and reduce load on the provider edge router, it may make matters worse. Regardless, maybe some provider prefers this approach. Some providers consider no exchange of routing information with the CPE to be a goal. I have yet to hear a provider ask for this but we don't come that close to the provider edge (gateway and aggregation is about as close as we get to the edge at this point) so it may be that there are service providers wanting to do something like this. Can we please now take further discussion off list. Curtis From owner-mpls@UU.NET Wed May 8 14:22:15 2002 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 OAA19461 for ; Wed, 8 May 2002 14:22:14 -0400 (EDT) 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 QQmnzl11124; Wed, 8 May 2002 18:20:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnzl07588 for mpls-outgoing; Wed, 8 May 2002 18:19: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 QQmnzl07583 for ; Wed, 8 May 2002 18:19:38 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 QQmnzl16704 for ; Wed, 8 May 2002 18:19:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnzl08473 for ; Wed, 8 May 2002 18:19:02 GMT 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 OAA08345 for ; Wed, 8 May 2002 14:19:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA27181 for mpls@uu.net; Wed, 8 May 2002 14:19:02 -0400 (EDT) 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 QQmnzk06824 for ; Wed, 8 May 2002 18:13:37 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 QQmnzk02697 for ; Wed, 8 May 2002 18:13:20 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmnzk29682 for ; Wed, 8 May 2002 18:13:14 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 OAA53994; Wed, 8 May 2002 14:11:36 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200205081811.OAA53994@workhorse.fictitious.org> To: neil.2.harrison@bt.com cc: hukulumu@yahoo.ca, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Static LSP Configuration In-reply-to: Your message of "Tue, 07 May 2002 13:45:55 BST." Date: Wed, 08 May 2002 14:11:36 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , nei l.2.harrison@bt.com writes: > Sounds very reasonable to me Gary. I mean LSPs supporting VPNs should not > be changing very often should they?.....they will usually be long-holding > and ought to be decoupled from any arbitrary routing changes (or indeed any > control-plane misbehaviour) by design. > > regards, Neil When a fiber gets chopped or a laser goes dead the LSP should affected as little as possible, with the path change as transparent as possible to the end user. That is different from disallowing path change. By decoupled, I'm hoping you mean that path changes due to failure should be expected to occur (and very rapidly) and should be transparent. Curtis From owner-mpls@UU.NET Wed May 8 14:27:30 2002 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 OAA19598 for ; Wed, 8 May 2002 14:27:28 -0400 (EDT) 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 QQmnzl19423; Wed, 8 May 2002 18:26:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnzl08353 for mpls-outgoing; Wed, 8 May 2002 18:26: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 QQmnzl08255 for ; Wed, 8 May 2002 18:26:07 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 QQmnzl07653 for ; Wed, 8 May 2002 18:26:00 GMT Received: from lightwave.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: radiant.calient.net [63.102.55.206]) id QQmnzl21448 for ; Wed, 8 May 2002 18:25:59 GMT Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 11:25:58 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC59F698@nimbus> From: John Drake To: "'Zafar Ali'" , Vinay Vernekar , Manoj Agiwal , "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Subject: RE: Label Set Object Date: Wed, 8 May 2002 11:25:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6BD.CC167440" 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_01C1F6BD.CC167440 Content-Type: text/plain; charset="iso-8859-1" Explicit Label Control is used to handle the SONET/SDH case. Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end Thanks, John -----Original Message----- From: Zafar Ali [mailto:zali@cisco.com] Sent: Wednesday, May 08, 2002 10:31 AM To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: Re: Label Set Object Dear Vinay, Please see comments in-lined. Thanks Regards... Zafar At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: Hi Zafar, The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt". I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above? Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths. IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET? Correct me if I am going wrong anywhere. Regards Vinay ----- Original Message ----- From: Zafar Ali To: Manoj Agiwal ; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Sent: Wednesday, May 08, 2002 11:04 AM Subject: Re: Label Set Object At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: Hi , In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on gmpls has described Label Set object usage only for the "optical" domain viz. for carrying wavelengths ( Section 9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . Do we require to send Label set(i.e. time slots) for TDM switching as well . In what way it can be useful . Dear Manoj, Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions. The label set object can be used to constrain the downstream label to the same as the upstream label. Thanks Regards... Zafar Regards , Manoj =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com ------_=_NextPart_001_01C1F6BD.CC167440 Content-Type: text/html; charset="iso-8859-1"
Explicit Label Control is used to handle the SONET/SDH case.  Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end 
 
Thanks,
 
John
 
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 10:31 AM
To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: Re: Label Set Object

Dear Vinay,

Please see comments in-lined.

Thanks

Regards... Zafar
At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:
Hi Zafar,
The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt".

I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above?

Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths.

IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET?

Correct me if I am going wrong anywhere.
 
Regards
Vinay   
----- Original Message -----
From: Zafar Ali
To: Manoj Agiwal ; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Sent: Wednesday, May 08, 2002 11:04 AM
Subject: Re: Label Set Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .

Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar



Regards ,
Manoj

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
------_=_NextPart_001_01C1F6BD.CC167440-- From owner-mpls@UU.NET Wed May 8 14:48:52 2002 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 OAA20190 for ; Wed, 8 May 2002 14:48:52 -0400 (EDT) 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 QQmnzn22461; Wed, 8 May 2002 18:47:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnzn10279 for mpls-outgoing; Wed, 8 May 2002 18:47:00 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 QQmnzn10274 for ; Wed, 8 May 2002 18:46:57 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 QQmnzn24825 for ; Wed, 8 May 2002 18:45:58 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnzn12739 for ; Wed, 8 May 2002 18:45:58 GMT 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 OAA10036 for ; Wed, 8 May 2002 14:45:58 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA00196 for mpls@uu.net; Wed, 8 May 2002 14:45:58 -0400 (EDT) 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 QQmnzj13904 for ; Wed, 8 May 2002 17:57:52 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 QQmnzj26105 for ; Wed, 8 May 2002 17:57:20 GMT Received: from web13401.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13401.mail.yahoo.com [216.136.175.59]) id QQmnzj17735 for ; Wed, 8 May 2002 17:57:20 GMT Message-ID: <20020508175719.53752.qmail@web13401.mail.yahoo.com> Received: from [12.234.203.226] by web13401.mail.yahoo.com via HTTP; Wed, 08 May 2002 10:57:19 PDT Date: Wed, 8 May 2002 10:57:19 -0700 (PDT) From: Gopalkrishna Panicker Subject: Ptear To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hello, I am sure these questions have been discussed here before. My apologies. I could not find what I was looking for in the archives. I am trying to understand how PathTear works. PathTears can originate at any (ingress or transit) node. These messages travel downstream towards the receivers (egress routers). Every node in this downstream path deletes its path state and in some cases deletes the resv state. I am assuming the above is correct. What happens to the path states upstream to the originator of the Path Tear ? How are they aged out ? Another related question, Is there a concept of graceful shutdown in RSVP? For example if RSVP is disabled in a transit router what should the router do ? I guess this is implementation dependent. Cheers, Gopal __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com From owner-mpls@UU.NET Wed May 8 14:50:02 2002 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 OAA20229 for ; Wed, 8 May 2002 14:50:02 -0400 (EDT) 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 QQmnzn24980; Wed, 8 May 2002 18:49:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnzn10421 for mpls-outgoing; Wed, 8 May 2002 18:48: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 QQmnzn10406 for ; Wed, 8 May 2002 18:48:48 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 QQmnzn02135 for ; Wed, 8 May 2002 18:48:15 GMT Received: from ganymede.or.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: jffdns01.or.intel.com [134.134.248.3]) id QQmnzn15506 for ; Wed, 8 May 2002 18:48:14 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by ganymede.or.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.37 2002/05/03 22:08:52 root Exp $) with SMTP id g48ImDm23656 for ; Wed, 8 May 2002 18:48:14 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002050811555226702 ; Wed, 08 May 2002 11:55:52 -0700 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 11:48:12 -0700 Message-ID: From: "Juneja, Manoj" To: "'John Drake'" , "'Zafar Ali'" , Vinay Vernekar , Manoj Agiwal, "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Subject: RE: Label Set Object Date: Wed, 8 May 2002 11:48:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6C0.E72A7E40" 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_01C1F6C0.E72A7E40 Content-Type: text/plain; charset="iso-8859-1" Hi John, Did u mean Explicit label control is used only for SDH/SONET case and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs. Regards, manoj. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, May 08, 2002 11:26 AM To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Explicit Label Control is used to handle the SONET/SDH case. Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end Thanks, John -----Original Message----- From: Zafar Ali [mailto:zali@cisco.com] Sent: Wednesday, May 08, 2002 10:31 AM To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: Re: Label Set Object Dear Vinay, Please see comments in-lined. Thanks Regards... Zafar At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: Hi Zafar, The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt". I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above? Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths. IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET? Correct me if I am going wrong anywhere. Regards Vinay ----- Original Message ----- From: Zafar Ali To: Manoj Agiwal ; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Sent: Wednesday, May 08, 2002 11:04 AM Subject: Re: Label Set Object At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: Hi , In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on gmpls has described Label Set object usage only for the "optical" domain viz. for carrying wavelengths ( Section 9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . Do we require to send Label set(i.e. time slots) for TDM switching as well . In what way it can be useful . Dear Manoj, Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions. The label set object can be used to constrain the downstream label to the same as the upstream label. Thanks Regards... Zafar Regards , Manoj =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com ------_=_NextPart_001_01C1F6C0.E72A7E40 Content-Type: text/html; charset="iso-8859-1"
Hi John,
               Did u mean Explicit label control is used only for SDH/SONET case  and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs.
 
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:26 AM
To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

Explicit Label Control is used to handle the SONET/SDH case.  Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end 
 
Thanks,
 
John
 
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 10:31 AM
To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: Re: Label Set Object

Dear Vinay,

Please see comments in-lined.

Thanks

Regards... Zafar
At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:
Hi Zafar,
The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt".

I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above?

Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths.

IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET?

Correct me if I am going wrong anywhere.
 
Regards
Vinay   
----- Original Message -----
From: Zafar Ali
To: Manoj Agiwal ; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Sent: Wednesday, May 08, 2002 11:04 AM
Subject: Re: Label Set Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .

Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar



Regards ,
Manoj

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
------_=_NextPart_001_01C1F6C0.E72A7E40-- From owner-mpls@UU.NET Wed May 8 14:50:59 2002 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 OAA20257 for ; Wed, 8 May 2002 14:50:59 -0400 (EDT) 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 QQmnzn22798; Wed, 8 May 2002 18:51:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnzn10634 for mpls-outgoing; Wed, 8 May 2002 18:50:41 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 QQmnzn10579 for ; Wed, 8 May 2002 18:50: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 QQmnzn06678 for ; Wed, 8 May 2002 18:49:39 GMT Received: from radiant.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fwsj.calient.net [63.102.55.194]) id QQmnzn17218 for ; Wed, 8 May 2002 18:49:38 GMT Received: by radiant.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 11:49:37 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC59F699@nimbus> From: John Drake To: "'Juneja, Manoj'" , "'Zafar Ali'" , Vinay Vernekar , Manoj Agiwal , "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Subject: RE: Label Set Object Date: Wed, 8 May 2002 11:49:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6C1.18E89020" 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_01C1F6C1.18E89020 Content-Type: text/plain; charset="iso-8859-1" I didn't say that. -----Original Message----- From: Juneja, Manoj [mailto:m_juneja@trillium.com] Sent: Wednesday, May 08, 2002 11:48 AM To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Hi John, Did u mean Explicit label control is used only for SDH/SONET case and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs. Regards, manoj. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, May 08, 2002 11:26 AM To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Explicit Label Control is used to handle the SONET/SDH case. Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end Thanks, John -----Original Message----- From: Zafar Ali [mailto:zali@cisco.com] Sent: Wednesday, May 08, 2002 10:31 AM To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: Re: Label Set Object Dear Vinay, Please see comments in-lined. Thanks Regards... Zafar At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: Hi Zafar, The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt". I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above? Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths. IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET? Correct me if I am going wrong anywhere. Regards Vinay ----- Original Message ----- From: Zafar Ali To: Manoj Agiwal ; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Sent: Wednesday, May 08, 2002 11:04 AM Subject: Re: Label Set Object At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: Hi , In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on gmpls has described Label Set object usage only for the "optical" domain viz. for carrying wavelengths ( Section 9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . Do we require to send Label set(i.e. time slots) for TDM switching as well . In what way it can be useful . Dear Manoj, Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions. The label set object can be used to constrain the downstream label to the same as the upstream label. Thanks Regards... Zafar Regards , Manoj =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com ------_=_NextPart_001_01C1F6C1.18E89020 Content-Type: text/html; charset="iso-8859-1"
I didn't say that.
-----Original Message-----
From: Juneja, Manoj [mailto:m_juneja@trillium.com]
Sent: Wednesday, May 08, 2002 11:48 AM
To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

Hi John,
               Did u mean Explicit label control is used only for SDH/SONET case  and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs.
 
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:26 AM
To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

Explicit Label Control is used to handle the SONET/SDH case.  Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end 
 
Thanks,
 
John
 
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 10:31 AM
To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: Re: Label Set Object

Dear Vinay,

Please see comments in-lined.

Thanks

Regards... Zafar
At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:
Hi Zafar,
The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt".

I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above?

Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths.

IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET?

Correct me if I am going wrong anywhere.
 
Regards
Vinay   
----- Original Message -----
From: Zafar Ali
To: Manoj Agiwal ; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Sent: Wednesday, May 08, 2002 11:04 AM
Subject: Re: Label Set Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .

Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar



Regards ,
Manoj

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
------_=_NextPart_001_01C1F6C1.18E89020-- From owner-mpls@UU.NET Wed May 8 14:59:53 2002 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 OAA20564 for ; Wed, 8 May 2002 14:59:53 -0400 (EDT) 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 QQmnzn05602; Wed, 8 May 2002 18:59:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnzn11516 for mpls-outgoing; Wed, 8 May 2002 18:59: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 QQmnzn11508 for ; Wed, 8 May 2002 18:59:28 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 QQmnzn18841 for ; Wed, 8 May 2002 18:58:33 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 QQmnzn26871 for ; Wed, 8 May 2002 18:58:32 GMT Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.45 2002/05/03 22:11:31 root Exp $) with ESMTP id g48IvIN14039 for ; Wed, 8 May 2002 18:57:18 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.18 2002/05/02 20:17:19 root Exp $) with SMTP id g48J0v213460 for ; Wed, 8 May 2002 19:00:57 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002050812024403151 ; Wed, 08 May 2002 12:02:45 -0700 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 11:58:14 -0700 Message-ID: From: "Juneja, Manoj" To: "'John Drake'" , "Juneja, Manoj", "'Zafar Ali'" , Vinay Vernekar, Manoj Agiwal , "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Subject: RE: Label Set Object Date: Wed, 8 May 2002 11:57:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6C2.263154A0" 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_01C1F6C2.263154A0 Content-Type: text/plain; charset="iso-8859-1" Hi Jonh, Sorry for creating the confusion. Should the label set be used for establishing the SDH/SONET LSPs ? Regards, manoj. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, May 08, 2002 11:50 AM To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object I didn't say that. -----Original Message----- From: Juneja, Manoj [mailto:m_juneja@trillium.com] Sent: Wednesday, May 08, 2002 11:48 AM To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Hi John, Did u mean Explicit label control is used only for SDH/SONET case and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs. Regards, manoj. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, May 08, 2002 11:26 AM To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Explicit Label Control is used to handle the SONET/SDH case. Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end Thanks, John -----Original Message----- From: Zafar Ali [mailto:zali@cisco.com] Sent: Wednesday, May 08, 2002 10:31 AM To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: Re: Label Set Object Dear Vinay, Please see comments in-lined. Thanks Regards... Zafar At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: Hi Zafar, The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt". I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above? Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths. IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET? Correct me if I am going wrong anywhere. Regards Vinay ----- Original Message ----- From: Zafar Ali To: Manoj Agiwal ; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Sent: Wednesday, May 08, 2002 11:04 AM Subject: Re: Label Set Object At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: Hi , In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on gmpls has described Label Set object usage only for the "optical" domain viz. for carrying wavelengths ( Section 9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . Do we require to send Label set(i.e. time slots) for TDM switching as well . In what way it can be useful . Dear Manoj, Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions. The label set object can be used to constrain the downstream label to the same as the upstream label. Thanks Regards... Zafar Regards , Manoj =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com ------_=_NextPart_001_01C1F6C2.263154A0 Content-Type: text/html; charset="iso-8859-1"
Hi Jonh,
              Sorry for creating the confusion. Should the label set be used for establishing the SDH/SONET LSPs ?
 
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:50 AM
To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

I didn't say that.
-----Original Message-----
From: Juneja, Manoj [mailto:m_juneja@trillium.com]
Sent: Wednesday, May 08, 2002 11:48 AM
To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

Hi John,
               Did u mean Explicit label control is used only for SDH/SONET case  and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs.
 
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:26 AM
To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

Explicit Label Control is used to handle the SONET/SDH case.  Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end 
 
Thanks,
 
John
 
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 10:31 AM
To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: Re: Label Set Object

Dear Vinay,

Please see comments in-lined.

Thanks

Regards... Zafar
At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:
Hi Zafar,
The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt".

I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above?

Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths.

IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET?

Correct me if I am going wrong anywhere.
 
Regards
Vinay   
----- Original Message -----
From: Zafar Ali
To: Manoj Agiwal ; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Sent: Wednesday, May 08, 2002 11:04 AM
Subject: Re: Label Set Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .

Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar



Regards ,
Manoj

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
------_=_NextPart_001_01C1F6C2.263154A0-- From owner-mpls@UU.NET Wed May 8 15:09:52 2002 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 PAA20865 for ; Wed, 8 May 2002 15:09:52 -0400 (EDT) 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 QQmnzo09889; Wed, 8 May 2002 19:09:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnzo03460 for mpls-outgoing; Wed, 8 May 2002 19:09:36 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 QQmnzo03452 for ; Wed, 8 May 2002 19:09:34 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 QQmnzo24243 for ; Wed, 8 May 2002 19:09:30 GMT Received: from mail.san.yahoo.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.san.yahoo.com [209.132.1.30]) id QQmnzo19389 for ; Wed, 8 May 2002 19:09:29 GMT Received: from [65.213.193.52] by mail.san.yahoo.com with HTTP; Wed, 8 May 2002 12:10:07 -0700 Date: Wed, 8 May 2002 15:10:07 -0400 Message-ID: <3CBB5DA900017F08@mta08.san.yahoo.com> From: "Kavita Khanna" Subject: MPLS 2002: topics for presentations To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA20865 The MPLS 2002 International Conference, in addition to the presentations from invited speakers, will also incorporate selected talks from open submitted proposals. The Program Committee cordially invites you to submit proposals for original unpublished presentations. The summaries not exceeding 500 words in the following and related topics may be submitted to TPC@MPLS2002.com for review and possible inclusion in the program, no later than June 7, 2002: - Advances in MPLS and IP Traffic Engineering - Layer 2 Provider Provisioned VPNs - Layer 3 Provider Provisioned VPNs - Service Provider Offerings of New MPLS and IP Based Services - Pseudo-Wire Edge-to-Edge Emulation (PWE3) - Vendor Implementations of Multiservice MPLS and/or IP Based Nodes - Implications and Tradeoffs in MPLS versus IP Tunnneling - Applications of Generalized MPLS - IP over Optical Networking MPLS 2002, the 5th annual International Conference on Multi Protocol Label Switching will take place October 27-29, 2002 at the Omni Shoreham Hotel, Washington, D.C. The event is Co-Hosted by WorldCom and Isocore and Supported by NTT, France Telecom and Cable & Wireless. The 3rd Public Interoperability Demonstration will follow on October 30, 2002. Additional information can be found at: www.mpls2002.com From owner-mpls@UU.NET Wed May 8 15:11:24 2002 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 PAA20911 for ; Wed, 8 May 2002 15:11:23 -0400 (EDT) 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 QQmnzo26936; Wed, 8 May 2002 19:11:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnzo04116 for mpls-outgoing; Wed, 8 May 2002 19:10:55 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 QQmnzo04052 for ; Wed, 8 May 2002 19:10:49 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 QQmnzo26091 for ; Wed, 8 May 2002 19:10:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnzo10071 for ; Wed, 8 May 2002 19:10:02 GMT 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 PAA11911 for ; Wed, 8 May 2002 15:10:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA04159 for mpls@uu.net; Wed, 8 May 2002 15:10:02 -0400 (EDT) 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 QQmnzo02619 for ; Wed, 8 May 2002 19:06:10 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 QQmnzo28219 for ; Wed, 8 May 2002 19:05:36 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQmnzo05262 for ; Wed, 8 May 2002 19:05:35 GMT Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g48J5YcL023000 for ; Wed, 8 May 2002 12:05:34 -0700 (PDT) Received: from cisco.com (dhcp-10-34-44-158.cisco.com [10.34.44.158]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ACF73590; Wed, 8 May 2002 12:06:10 -0700 (PDT) Message-ID: <3CD976FD.85281F5F@cisco.com> Date: Wed, 08 May 2002 12:05:33 -0700 From: Ambal Balakrishnan Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit unsubscribe From owner-mpls@UU.NET Wed May 8 15:22:36 2002 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 PAA21253 for ; Wed, 8 May 2002 15:22:36 -0400 (EDT) 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 QQmnzp12100; Wed, 8 May 2002 19:22:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnzp05691 for mpls-outgoing; Wed, 8 May 2002 19:22:30 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 QQmnzp05674 for ; Wed, 8 May 2002 19:22: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 QQmnzp03871 for ; Wed, 8 May 2002 19:20:42 GMT From: neil.2.harrison@bt.com Received: from mbibipnt08.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmnzp22985 for ; Wed, 8 May 2002 19:20:42 GMT Received: by mbibipnt08.hc.bt.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 20:20:49 +0100 Message-ID: To: curtis@fictitious.org Cc: hukulumu@yahoo.ca, mpls@UU.NET Subject: RE: Static LSP Configuration Date: Wed, 8 May 2002 20:20:29 +0100 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 Curtis Villamizar wrote 08 May 2002 19:12 > In message > , nei > l.2.harrison@bt.com writes: > > Sounds very reasonable to me Gary. I mean LSPs supporting > VPNs should not > > be changing very often should they?.....they will usually > be long-holding > > and ought to be decoupled from any arbitrary routing > changes (or indeed any > > control-plane misbehaviour) by design. > > > > regards, Neil > > > When a fiber gets chopped or a laser goes dead the LSP should affected > as little as possible, with the path change as transparent as possible > to the end user. That is different from disallowing path change. By > decoupled, I'm hoping you mean that path changes due to failure should > be expected to occur (and very rapidly) and should be transparent. > > Curtis NH=> Yes I agree with that Curtis. What we don't want however is for VPN topologies (ie the trails that compose these) to be flapping about just because some routing protocol thinks it has a better way from getting from A to B. Nor do we want the VPN topologies to be affected if there is a control-plane failure/misbehaviour (be it a signalling or routing protocol)......the data-plane in VPNs here needs to be pretty solidly decoupled from any such instances IMO. It therefore follows that the data-plane LSPs of such VPN constructs need to be (i) control-plane agnostic (inc case of none, if need be) and (ii) fault-managed independently of the signalling/routing protocol in force (inc none). There is also the issue of 'performance independence/isolation' per VPN to consider. Now if I extrapolate/extend that requirement into what that means for things like LDP LSPs and rfc2547 VPNs I have some concerns here. In the former case, I can't get survivability and QoS isolation between VPNs (assuming like-DS-class merging across VPN populations) and in the latter case I have a potential common-mode failure mechanism across all VPNs. Neither of these seem like good engineering practices.....even if the solutions are 'elegant' in their own right (purely from connectivity considerations....but this is not enought IMO). regards, Neil From owner-mpls@UU.NET Wed May 8 15:28:58 2002 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 PAA21442 for ; Wed, 8 May 2002 15:28:57 -0400 (EDT) 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 QQmnzp01910; Wed, 8 May 2002 19:29:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnzp06287 for mpls-outgoing; Wed, 8 May 2002 19:28: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 QQmnzp06277 for ; Wed, 8 May 2002 19:28:38 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 QQmnzp17236 for ; Wed, 8 May 2002 19:27:05 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 QQmnzp18458 for ; Wed, 8 May 2002 19:27:05 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 PAA11990; Wed, 8 May 2002 15:26:57 -0400 (EDT) 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 PAA05943; Wed, 8 May 2002 15:26:56 -0400 (EDT) Message-ID: <3CD97C26.9DA9CDF6@marconi.com> Date: Wed, 08 May 2002 15:27:34 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: Gopalkrishna Panicker CC: mpls@UU.NET Subject: Re: Ptear References: <20020508175719.53752.qmail@web13401.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gopalkrishna Panicker wrote: > > I am trying to understand how PathTear works. > > PathTears can originate at any (ingress or transit) node. They should only originate at transit nodes if there is a link failure on the upstream side of that transit node. > These messages travel downstream towards the receivers (egress > routers). Correct. They should follow the same route as the corresponding Path message - using the stored ERO, if applicable. > Every node in this downstream path deletes its path state and in > some cases deletes the resv state. In all cases, the Resv state is deleted. It is meaningless to have an RSVP reservation that does not correspond to any existing Path state. > What happens to the path states upstream to the originator of the > Path Tear ? How are they aged out ? The only time there will be any Path state upstream of the source of the tear will be if the link to the upstream node has failed. The other side of that link failure will generate ResvTear and PathError messages which will flow towards the ingress node. If the ingress node so chooses, it can generate a PathTear in response to the PathError message. If it chooses not to, then the Path state will remain inplace. When the down link comes back up, the router on the upstream side of that link will send a Path message out, and the LSP will be reestablished. > Another related question, Is there a concept of graceful shutdown > in RSVP? For example if RSVP is disabled in a transit router what > should the router do ? I guess this is implementation dependent. I don't know of a specification for this. If the protocol simply stops sending/receiving RSVP messages, the neighbors will detect this and will enerate PathTear, ResvTear and PathErr messages, as appropriate. If Hellos are being exchanged with the neighbor, this will happen within a few seconds. If not, it may take a few minutes - as the soft-states for the different sessions time out individually. If the protocol wants to shut down more gracefully, it may send out PathTead, ResvTear and PathErr messages before shutting down. But due to the soft-state nature of RSVP, messages to establish new state may arrive while this is happening. So the protocol would have to be able to reject new requests while it's sending out the error/tear messaes for the existing state. Overall, the effect is pretty much the same as the abrupt shutdown. Note that this will be different in a GMPLS scenario, where there is a right and a wrong way to tear an LSP. Tearing one the wrong way can set off loss-of-carrier alarms in an optical network. -- David From owner-mpls@UU.NET Wed May 8 16:08:38 2002 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 QAA22319 for ; Wed, 8 May 2002 16:08:37 -0400 (EDT) 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 QQmnzs14160; Wed, 8 May 2002 20:08:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnzs00380 for mpls-outgoing; Wed, 8 May 2002 20:08: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 QQmnzs00352 for ; Wed, 8 May 2002 20:08:20 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 QQmnzs12651 for ; Wed, 8 May 2002 20:07:31 GMT Received: from radiant.chromisys.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fwsj.calient.net [63.102.55.194]) id QQmnzs14533 for ; Wed, 8 May 2002 20:07:30 GMT Received: by radiant.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 13:07:29 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC59F69A@nimbus> From: John Drake To: "'Juneja, Manoj'" , "'Zafar Ali'" , Vinay Vernekar , Manoj Agiwal , "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Subject: RE: Label Set Object Date: Wed, 8 May 2002 13:07:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6CB.F6C16CF0" 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_01C1F6CB.F6C16CF0 Content-Type: text/plain; charset="iso-8859-1" Label Set and Explicit Label Control are used for different purposes, and as I understand it, Explicit Label Control is more natural for establishing SONET/SDH LSPs, while Label Set is more natural for establishing wavelength LSPs. You could, however, use Label Set for SONET/SDH LSPs and Explicit Label Control for wavelength LSPs. -----Original Message----- From: Juneja, Manoj [mailto:m_juneja@trillium.com] Sent: Wednesday, May 08, 2002 11:57 AM To: John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Hi Jonh, Sorry for creating the confusion. Should the label set be used for establishing the SDH/SONET LSPs ? Regards, manoj. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, May 08, 2002 11:50 AM To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object I didn't say that. -----Original Message----- From: Juneja, Manoj [mailto:m_juneja@trillium.com] Sent: Wednesday, May 08, 2002 11:48 AM To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Hi John, Did u mean Explicit label control is used only for SDH/SONET case and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs. Regards, manoj. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, May 08, 2002 11:26 AM To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Explicit Label Control is used to handle the SONET/SDH case. Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end Thanks, John -----Original Message----- From: Zafar Ali [mailto:zali@cisco.com] Sent: Wednesday, May 08, 2002 10:31 AM To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: Re: Label Set Object Dear Vinay, Please see comments in-lined. Thanks Regards... Zafar At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: Hi Zafar, The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt". I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above? Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths. IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET? Correct me if I am going wrong anywhere. Regards Vinay ----- Original Message ----- From: Zafar Ali To: Manoj Agiwal ; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Sent: Wednesday, May 08, 2002 11:04 AM Subject: Re: Label Set Object At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: Hi , In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on gmpls has described Label Set object usage only for the "optical" domain viz. for carrying wavelengths ( Section 9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . Do we require to send Label set(i.e. time slots) for TDM switching as well . In what way it can be useful . Dear Manoj, Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions. The label set object can be used to constrain the downstream label to the same as the upstream label. Thanks Regards... Zafar Regards , Manoj =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com ------_=_NextPart_001_01C1F6CB.F6C16CF0 Content-Type: text/html; charset="iso-8859-1"
Label Set and Explicit Label Control are used for different purposes, and as I understand it, Explicit Label Control is more natural  for establishing SONET/SDH LSPs, while Label Set is more natural for establishing wavelength LSPs.  You could, however, use Label Set for SONET/SDH LSPs and Explicit Label Control for wavelength LSPs.
-----Original Message-----
From: Juneja, Manoj [mailto:m_juneja@trillium.com]
Sent: Wednesday, May 08, 2002 11:57 AM
To: John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

Hi Jonh,
              Sorry for creating the confusion. Should the label set be used for establishing the SDH/SONET LSPs ?
 
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:50 AM
To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

I didn't say that.
-----Original Message-----
From: Juneja, Manoj [mailto:m_juneja@trillium.com]
Sent: Wednesday, May 08, 2002 11:48 AM
To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

Hi John,
               Did u mean Explicit label control is used only for SDH/SONET case  and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs.
 
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:26 AM
To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

Explicit Label Control is used to handle the SONET/SDH case.  Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end 
 
Thanks,
 
John
 
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 10:31 AM
To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: Re: Label Set Object

Dear Vinay,

Please see comments in-lined.

Thanks

Regards... Zafar
At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:
Hi Zafar,
The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt".

I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above?

Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths.

IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET?

Correct me if I am going wrong anywhere.
 
Regards
Vinay   
----- Original Message -----
From: Zafar Ali
To: Manoj Agiwal ; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Sent: Wednesday, May 08, 2002 11:04 AM
Subject: Re: Label Set Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .

Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar



Regards ,
Manoj

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
------_=_NextPart_001_01C1F6CB.F6C16CF0-- From owner-mpls@UU.NET Wed May 8 16:16:12 2002 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 QAA22509 for ; Wed, 8 May 2002 16:16:12 -0400 (EDT) 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 QQmnzt25560; Wed, 8 May 2002 20:16:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnzt02165 for mpls-outgoing; Wed, 8 May 2002 20:15: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 QQmnzt02160 for ; Wed, 8 May 2002 20:15:55 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 QQmnzt06921 for ; Wed, 8 May 2002 20:15:11 GMT Received: from zcars04f.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQmnzt23207 for ; Wed, 8 May 2002 20:15:11 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g48KECx23845; Wed, 8 May 2002 16:14:12 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 16:14:16 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6023F1085@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: Curtis Villamizar , sven.van_den_bosch@alcatel.be Cc: "Naidu, Venkata" , "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org Subject: RE: How many can administrative groups assigned? Date: Wed, 8 May 2002 16:14:40 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Curtis You state the definitions are clear but last time I read a couple of implementations from vendor specification they were different. While I agree we should keep the complexity to a minimum, when I floated a simple request to define the bits the pushback we got was it was too inflexible. So in my opinion administrative bits are purposely under specified by design and hence not so clear. Don > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Subject: Re: How many can administrative groups assigned? > > [ post by non-subscriber. with the massive amount of spam, > it is easy to > miss and therefore delete mis-posts. so fix subscription > addresses! ] > > In message > , sven.van_d > en_bosch@alcatel.be writes: > > Naidu, Kim, > > > > I think it depends a little bit on the interpretation. In principle the > > resource classes can be interpreted either as a bit mask (in which case 32 > > 'base' classes can be defined) or as an integer value (in which case 2^32 > > values can be used). Even with the bit mask interpretation, derived > > resource classes can be built by combining multiple non-mutually exclusive > > 'base' classes (you could have 32 generic classes called 1, 2, 3 and so on > > and then build your resource classes on top of those). The problem lies of > > course in the processing of the resource class information. If they are not > > used in a simple bitmask, an AND operation is not sufficient to determine > > the resource class of a link. Also, if a link would have multiple derived > > classes, different TLVs would be needed. It would make sense to expand a > > little bit on these issues in the appropriate documents. In my opinion, > > this is a general issue with the TE extensions, so it should be explained > > there. > > > > Sven. > > > The definitions are currently very clear. What you have described > differs from the current definitions and therefore would not be a > clarification to the use of admin class but a change in semantics. > > I do not know of anyone using more than a handful of admin class bits > and many who do not use them at all. Lets not take any MPLS > capability and make it any more complicated than it needs to be or > introduce arbitrary change for no good reason. > > Curtis > From owner-mpls@UU.NET Wed May 8 16:16:35 2002 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 QAA22523 for ; Wed, 8 May 2002 16:16:34 -0400 (EDT) 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 QQmnzt25157; Wed, 8 May 2002 20:16:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnzt02355 for mpls-outgoing; Wed, 8 May 2002 20:16:19 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 QQmnzt02302 for ; Wed, 8 May 2002 20:16:13 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 QQmnzt18519 for ; Wed, 8 May 2002 20:15:40 GMT Received: from alpha.tellium.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.119.210.16]) id QQmnzt23738 for ; Wed, 8 May 2002 20:15:40 GMT Received: from mail1.tellium.com (unverified) by alpha.tellium.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 May 2002 16:10:20 -0400 Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id ; Wed, 8 May 2002 16:10:25 -0400 Message-ID: <05707214338CD5119BFF0040A5B170D31816BE@mail3.tellium.com> From: Hang Liu To: "'m_juneja@trillium.com'" Cc: "mpls@UU. NET (E-mail)" Subject: RE: Label Set Object Date: Wed, 8 May 2002 16:10:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi. Explicit label control seems to be used by the ingress node to control the label selection, but Label Set seems more related to the label selection between two adjacent nodes. In the GMPLS RSVP-TE draft, the upstream node needs to copy the value in downstream Label ERO subobject into a Label Set object of the outgoing Path Message (upstream Label ERO goes to Upstream Label object). Please correct me if I am wrong anywhere. Hang Liu Tellium, Inc. -----Original Message----- From: Juneja, Manoj [mailto:m_juneja@trillium.com] Sent: Wednesday, May 08, 2002 2:57 PM To: 'John Drake'; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Hi Jonh, Sorry for creating the confusion. Should the label set be used for establishing the SDH/SONET LSPs ? Regards, manoj. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, May 08, 2002 11:50 AM To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object I didn't say that. -----Original Message----- From: Juneja, Manoj [mailto:m_juneja@trillium.com] Sent: Wednesday, May 08, 2002 11:48 AM To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Hi John, Did u mean Explicit label control is used only for SDH/SONET case and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs. Regards, manoj. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, May 08, 2002 11:26 AM To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Explicit Label Control is used to handle the SONET/SDH case. Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end Thanks, John -----Original Message----- From: Zafar Ali [mailto:zali@cisco.com] Sent: Wednesday, May 08, 2002 10:31 AM To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: Re: Label Set Object Dear Vinay, Please see comments in-lined. Thanks Regards... Zafar At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: Hi Zafar, The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt". I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above? Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths. IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET? Correct me if I am going wrong anywhere. Regards Vinay ----- Original Message ----- From: Zafar Ali To: Manoj Agiwal ; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Sent: Wednesday, May 08, 2002 11:04 AM Subject: Re: Label Set Object At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: Hi , In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on gmpls has described Label Set object usage only for the "optical" domain viz. for carrying wavelengths ( Section 9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . Do we require to send Label set(i.e. time slots) for TDM switching as well . In what way it can be useful . Dear Manoj, Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions. The label set object can be used to constrain the downstream label to the same as the upstream label. Thanks Regards... Zafar Regards , Manoj =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com From owner-mpls@UU.NET Wed May 8 16:32:18 2002 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 QAA23115 for ; Wed, 8 May 2002 16:32:17 -0400 (EDT) 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 QQmnzi23704; Wed, 8 May 2002 17:34:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnzi11919 for mpls-outgoing; Wed, 8 May 2002 17:34: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 QQmnzi11914 for ; Wed, 8 May 2002 17:34:13 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 QQmnzi07819 for ; Wed, 8 May 2002 17:33:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnzi02368 for ; Wed, 8 May 2002 17:33:02 GMT 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 NAA05359 for ; Wed, 8 May 2002 13:33:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA22523 for mpls@uu.net; Wed, 8 May 2002 13:33:02 -0400 (EDT) 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 QQmnzi11867 for ; Wed, 8 May 2002 17:32:21 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 QQmnzi03551 for ; Wed, 8 May 2002 17:31:43 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sword.cisco.com [161.44.208.100]) id QQmnzi00411 for ; Wed, 8 May 2002 17:31:43 GMT Received: from ZALI-W2K.cisco.com (che-vpn1-28.cisco.com [10.86.240.28]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id NAA12265; Wed, 8 May 2002 13:31:15 -0400 (EDT) Message-Id: <4.3.2.7.2.20020508130634.02b77ec0@sword.cisco.com> X-Sender: zali@sword.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 May 2002 13:31:09 -0400 To: "Vinay Vernekar" , "Manoj Agiwal" , "'Ccamp (E-mail)" From: Zafar Ali Subject: Re: Label Set Object Cc: "mpls@UU. NET (E-mail)" In-Reply-To: <010001c1f69c$5bfe2d40$8c03750a@wipro.com> References: <4.3.2.7.2.20020508013112.04570cc8@sword.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_14391804==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_14391804==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear Vinay, Please see comments in-lined. Thanks Regards... Zafar At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: >Hi Zafar, >The Label Set Object can't be sent to constrain the downstream label when >the LSP encoding type is Sonet/SDH. Consider the example where a request >is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. >The label expected from the downstream would be 'm' set of labels each set >consisting of 'n' labels further that identify each of the virtual >concatenated components. So a Label Set in this scenario would consist of >say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set >cannot be encoded using the object/TLV structure of Label Set as in >"Generalized MPLS - Signalling Functional Description - >draft-ietf-mpls-generalized-signaling-08.txt". I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above? >Label Set Object can be sent only in WDM scenario where a single >wavelength is requested as a label and the upstream has a restriction on >the usable wavelengths. IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET? >Correct me if I am going wrong anywhere. > >Regards >Vinay >>----- Original Message ----- >>From: Zafar Ali >>To: Manoj Agiwal ; >>'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Sent: Wednesday, May 08, 2002 11:04 AM >>Subject: Re: Label Set Object >> >>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>>Hi , >>> In gmpls signaling extensionsions for RSVP-TE , ccamp >>> architecture on >>>gmpls has described Label Set object usage >>> only for the "optical" domain viz. for carrying wavelengths ( Section >>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . >>> >>> Do we require to send Label set(i.e. time slots) for TDM >>> switching as >>>well . In what way it can be useful . >> >>Dear Manoj, >> >>Yes, label set object is also useful in TDM case. E.g., SONET poses an >>additional requirement that the two interfaces of a bidirectional LSP >>SHOULD traverse the exact same link with the same SUKLM values for the >>two directions. >> The label set object can be used to constrain the downstream label to >> the same as the upstream label. >> >>Thanks >> >>Regards... Zafar >> >> >> >>>Regards , >>>Manoj >> >>=============== >>Zafar Ali >>Cisco Systems >>(734) 276-2459 >>100 S Main St. #200 >>Ann Arbor, MI 48104. >>email: zali@cisco.com --=====================_14391804==_.ALT Content-Type: text/html; charset="us-ascii" Dear Vinay,

Please see comments in-lined.

Thanks

Regards... Zafar
At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:
Hi Zafar,
The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt".

I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above?

Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths.

IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET?

Correct me if I am going wrong anywhere.
 
Regards
Vinay   
----- Original Message -----
From: Zafar Ali
To: Manoj Agiwal ; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Sent: Wednesday, May 08, 2002 11:04 AM
Subject: Re: Label Set Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .

Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar



Regards ,
Manoj

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
--=====================_14391804==_.ALT-- From owner-mpls@UU.NET Wed May 8 17:10:46 2002 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 RAA24031 for ; Wed, 8 May 2002 17:10:46 -0400 (EDT) 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 QQmnzw11116; Wed, 8 May 2002 21:10:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnzw27736 for mpls-outgoing; Wed, 8 May 2002 21:10: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 QQmnzw27704 for ; Wed, 8 May 2002 21:10:07 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 QQmnzw11159 for ; Wed, 8 May 2002 21:10:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmnzw26796 for ; Wed, 8 May 2002 21:10:02 GMT 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 RAA20747 for ; Wed, 8 May 2002 17:10:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA18836 for mpls@uu.net; Wed, 8 May 2002 17:10:02 -0400 (EDT) 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 QQmnzw27530 for ; Wed, 8 May 2002 21:08: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 QQmnzw23648 for ; Wed, 8 May 2002 21:08:24 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmnzw07103 for ; Wed, 8 May 2002 21:08: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 RAA55207; Wed, 8 May 2002 17:07:10 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200205082107.RAA55207@workhorse.fictitious.org> To: "Don Fedyk" cc: Curtis Villamizar , sven.van_den_bosch@alcatel.be, "Naidu, Venkata" , "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org Reply-To: curtis@fictitious.org Subject: Re: How many can administrative groups assigned? In-reply-to: Your message of "Wed, 08 May 2002 16:14:40 EDT." <0D7FC1D8D861D511AEA70002A52CE5E6023F1085@zcard0ke.ca.nortel.com> Date: Wed, 08 May 2002 17:07:10 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <0D7FC1D8D861D511AEA70002A52CE5E6023F1085@zcard0ke.ca.nortel.com>, " Don Fedyk" writes: > Curtis > > You state the definitions are clear but last time I read a couple of > implementations > from vendor specification they were different. While I agree we should keep > the > complexity to a minimum, when I floated a simple request to define the bits > the > pushback we got was it was too inflexible. So in my opinion administrative > bits > are purposely under specified by design and hence not so clear. > > Don AFAIK the vendors at ISOCORE interoperability testing all interpret these as bitmaps and all support at least the include-any and exclude (which is interpreted as exclude-all). Some do not support the include-all operation but it is easy to add. What meaning is assigned to each bit is something that should not be specified since it is local to the MPLS domain and up to the service provider to choose. No need for any change. Curtis > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > > Subject: Re: How many can administrative groups assigned? > > > > [ post by non-subscriber. with the massive amount of spam, > > it is easy to > > miss and therefore delete mis-posts. so fix subscription > > addresses! ] > > > > In message > > , sven.van_d > > en_bosch@alcatel.be writes: > > > Naidu, Kim, > > > > > > I think it depends a little bit on the interpretation. In principle the > > > resource classes can be interpreted either as a bit mask (in which case > 32 > > > 'base' classes can be defined) or as an integer value (in which case > 2^32 > > > values can be used). Even with the bit mask interpretation, derived > > > resource classes can be built by combining multiple non-mutually > exclusive > > > 'base' classes (you could have 32 generic classes called 1, 2, 3 and so > on > > > and then build your resource classes on top of those). The problem lies > of > > > course in the processing of the resource class information. If they are > not > > > used in a simple bitmask, an AND operation is not sufficient to > determine > > > the resource class of a link. Also, if a link would have multiple > derived > > > classes, different TLVs would be needed. It would make sense to expand a > > > little bit on these issues in the appropriate documents. In my opinion, > > > this is a general issue with the TE extensions, so it should be > explained > > > there. > > > > > > Sven. > > > > > > The definitions are currently very clear. What you have described > > differs from the current definitions and therefore would not be a > > clarification to the use of admin class but a change in semantics. > > > > I do not know of anyone using more than a handful of admin class bits > > and many who do not use them at all. Lets not take any MPLS > > capability and make it any more complicated than it needs to be or > > introduce arbitrary change for no good reason. > > > > Curtis > > > From owner-mpls@UU.NET Wed May 8 18:26:22 2002 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 SAA25324 for ; Wed, 8 May 2002 18:26:22 -0400 (EDT) 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 QQmoab22340; Wed, 8 May 2002 22:26:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoab26677 for mpls-outgoing; Wed, 8 May 2002 22:25: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 QQmoab26669 for ; Wed, 8 May 2002 22:25:53 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 QQmoab03466 for ; Wed, 8 May 2002 22:25:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmoab18215 for ; Wed, 8 May 2002 22:25:02 GMT 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 SAA24508 for ; Wed, 8 May 2002 18:25:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA26917 for mpls@uu.net; Wed, 8 May 2002 18:25:02 -0400 (EDT) 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 QQmoab26540 for ; Wed, 8 May 2002 22:24:35 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 QQmoab27980 for ; Wed, 8 May 2002 22:23:16 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 QQmoab16339 for ; Wed, 8 May 2002 22:23:15 GMT Received: from mira1.cisco.com (IDENT:mirapoint@mira1.cisco.com [64.101.14.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g48MN6YM014927; Wed, 8 May 2002 15:23:06 -0700 (PDT) Received: from SKATUKAM-W2K2.cisco.com (data-pet-w2k.cisco.com [64.101.9.35]) by mira1.cisco.com (Mirapoint) with ESMTP id AAX89018; Wed, 8 May 2002 15:23:25 -0700 (PDT) Message-Id: <4.3.2.7.2.20020508151825.0328c598@mira1.cisco.com> X-Sender: skatukam@mira1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 May 2002 15:23:04 -0700 To: Zafar Ali From: Suresh Katukam Subject: RE: Label Set Object Cc: Manoj Agiwal , Manoj Agiwal , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" In-Reply-To: <4.3.2.7.2.20020508014732.04577e60@sword.cisco.com> References: <9027F68B07E7D511AE9400B0D0787DC00704AA@BRAHMA01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk For TDM, since you have to use same labels in both directions, why do you have to specify anything at all? How can a downstream TDM node pick a label that does not match with Upstream label for a bidirectional LSP? If it picks any other label, LSP is not functional. If there are Uni-directional LSPs in TDM and if you have different types of time slots available in both directions, then one may be able to setup bidirectional LSP on different links or different labels. This is in theory and not in practice. So in practice, one does not need to specify LABEL SET or Suggested label for TDM links. Thanks, Suresh At 01:53 AM 5/8/2002 -0400, Zafar Ali wrote: >At 11:11 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>Hi , >> I guess in that case we can use Suggested Label , Label Set still can >> still be avoided . > >Hi Manoj, > >No, the use of suggested label in this case would NOT be correct, as the >suggested labels can be ignored/ overridden by the receiving node. > >Thanks > >Regards... Zafar > >>Regards , >>Manoj >>-----Original Message----- >>From: Zafar Ali [mailto:zali@cisco.com] >>Sent: Wednesday, May 08, 2002 11:05 AM >>To: Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: Re: Label Set Object >> >>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>>Hi , >>> In gmpls signaling extensionsions for RSVP-TE , ccamp >>> architecture on >>>gmpls has described Label Set object usage >>> only for the "optical" domain viz. for carrying wavelengths ( Section >>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . >>> >>> Do we require to send Label set(i.e. time slots) for TDM >>> switching as >>>well . In what way it can be useful . >>Dear Manoj, >> >>Yes, label set object is also useful in TDM case. E.g., SONET poses an >>additional requirement that the two interfaces of a bidirectional LSP >>SHOULD traverse the exact same link with the same SUKLM values for the >>two directions. >> The label set object can be used to constrain the downstream label to >> the same as the upstream label. >> >>Thanks >> >>Regards... Zafar >> >> >> >> >> >> >> >> >> >>>Regards , >>>Manoj >>=============== >>Zafar Ali >>Cisco Systems >>(734) 276-2459 >>100 S Main St. #200 >>Ann Arbor, MI 48104. >>email: zali@cisco.com > >=============== >Zafar Ali >Cisco Systems >(734) 276-2459 >100 S Main St. #200 >Ann Arbor, MI 48104. >email: zali@cisco.com From owner-mpls@UU.NET Wed May 8 18:38:21 2002 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 SAA25522 for ; Wed, 8 May 2002 18:38:21 -0400 (EDT) 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 QQmoac09505; Wed, 8 May 2002 22:38:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoac27708 for mpls-outgoing; Wed, 8 May 2002 22:37: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 QQmoac27699 for ; Wed, 8 May 2002 22:37: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 QQmoac07689 for ; Wed, 8 May 2002 22:36:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmoac00681 for ; Wed, 8 May 2002 22:36:03 GMT 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 SAA25004 for ; Wed, 8 May 2002 18:36:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA28584 for mpls@uu.net; Wed, 8 May 2002 18:36:02 -0400 (EDT) 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 QQmoac27437 for ; Wed, 8 May 2002 22:34: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 QQmoac29922 for ; Wed, 8 May 2002 22:33:33 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmoac28056 for ; Wed, 8 May 2002 22:33:32 GMT 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 SAA24876; Wed, 8 May 2002 18:33:32 -0400 (EDT) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA14703; Wed, 8 May 2002 18:33:32 -0400 (EDT) Message-Id: <200205082233.SAA14703@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Suresh Katukam cc: Zafar Ali , Manoj Agiwal , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" , swallow@cisco.com Subject: Re: Label Set Object In-reply-to: Your message of "Wed, 08 May 2002 15:23:04 PDT." <4.3.2.7.2.20020508151825.0328c598@mira1.cisco.com> Date: Wed, 08 May 2002 18:33:32 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > So in practice, one does not need to specify LABEL SET or Suggested label > for TDM links. While I agree with your assessment of what is necessary, it might help interoperability by including a label set with one label which is the same label as the upstream label. This covers you if someone else changes their practice (for some stange and/or broken reason). ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed May 8 19:00:43 2002 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 TAA25772 for ; Wed, 8 May 2002 19:00:43 -0400 (EDT) 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 QQmoae12733; Wed, 8 May 2002 23:00:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoae02103 for mpls-outgoing; Wed, 8 May 2002 23:00: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 QQmoae01991 for ; Wed, 8 May 2002 23:00: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 QQmoae11813 for ; Wed, 8 May 2002 23:00:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmoae27853 for ; Wed, 8 May 2002 23:00:02 GMT 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 TAA25883 for ; Wed, 8 May 2002 19:00:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA01519 for mpls@uu.net; Wed, 8 May 2002 19:00:01 -0400 (EDT) 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 QQmnzm08884 for ; Wed, 8 May 2002 18:33:35 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 QQmnzm00362 for ; Wed, 8 May 2002 18:33:18 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmnzm00617 for ; Wed, 8 May 2002 18:33:17 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 OAA54056; Wed, 8 May 2002 14:22:11 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200205081822.OAA54056@workhorse.fictitious.org> To: sven.van_den_bosch@alcatel.be cc: "Naidu, Venkata" , "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org Reply-To: curtis@fictitious.org Subject: Re: How many can administrative groups assigned? In-reply-to: Your message of "Wed, 08 May 2002 10:15:50 +0200." Date: Wed, 08 May 2002 14:22:11 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , sven.van_d en_bosch@alcatel.be writes: > Naidu, Kim, > > I think it depends a little bit on the interpretation. In principle the > resource classes can be interpreted either as a bit mask (in which case 32 > 'base' classes can be defined) or as an integer value (in which case 2^32 > values can be used). Even with the bit mask interpretation, derived > resource classes can be built by combining multiple non-mutually exclusive > 'base' classes (you could have 32 generic classes called 1, 2, 3 and so on > and then build your resource classes on top of those). The problem lies of > course in the processing of the resource class information. If they are not > used in a simple bitmask, an AND operation is not sufficient to determine > the resource class of a link. Also, if a link would have multiple derived > classes, different TLVs would be needed. It would make sense to expand a > little bit on these issues in the appropriate documents. In my opinion, > this is a general issue with the TE extensions, so it should be explained > there. > > Sven. The definitions are currently very clear. What you have described differs from the current definitions and therefore would not be a clarification to the use of admin class but a change in semantics. I do not know of anyone using more than a handful of admin class bits and many who do not use them at all. Lets not take any MPLS capability and make it any more complicated than it needs to be or introduce arbitrary change for no good reason. Curtis From owner-mpls@UU.NET Wed May 8 19:07:43 2002 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 TAA25866 for ; Wed, 8 May 2002 19:07:43 -0400 (EDT) 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 QQmoae21734; Wed, 8 May 2002 23:07:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoae21464 for mpls-outgoing; Wed, 8 May 2002 23:07:24 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 QQmoae21454 for ; Wed, 8 May 2002 23:07: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 QQmoae04426 for ; Wed, 8 May 2002 23:07:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmoae05021 for ; Wed, 8 May 2002 23:07:02 GMT 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 TAA26170 for ; Wed, 8 May 2002 19:07:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA02756 for mpls@uu.net; Wed, 8 May 2002 19:07:02 -0400 (EDT) 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 QQmoae20553 for ; Wed, 8 May 2002 23:06:00 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 QQmoae28773 for ; Wed, 8 May 2002 23:05:31 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sword.cisco.com [161.44.208.100]) id QQmoae18326 for ; Wed, 8 May 2002 23:05:31 GMT Received: from ZALI-W2K.cisco.com (che-vpn1-28.cisco.com [10.86.240.28]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id TAA06542; Wed, 8 May 2002 19:04:59 -0400 (EDT) Message-Id: <4.3.2.7.2.20020508181334.058a4258@sword.cisco.com> X-Sender: zali@sword.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 May 2002 19:04:57 -0400 To: John Drake , "'Juneja, Manoj'" , Vinay Vernekar , Manoj Agiwal , "'Ccamp (E-mail)" , skatukam@cisco.com From: Zafar Ali Subject: RE: Label Set Object Cc: "mpls@UU. NET (E-mail)" In-Reply-To: <9D42C6E086250248810DCADA39CE7EFC59F69A@nimbus> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_34419362==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_34419362==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:07 PM 5/8/2002 -0700, John Drake wrote: >Label Set and Explicit Label Control are used for different purposes, and >as I understand it, Explicit Label Control is more natural for >establishing SONET/SDH LSPs, while Label Set is more natural for >establishing wavelength LSPs. >You could, however, use Label Set for SONET/SDH LSPs and Explicit Label >Control for wavelength LSPs. Hi John, While I agree with the last statement, I didn't understand why you mentioned that explicit label control is more natural for SONET/ SDH. IMHO the label set is a more natural way of constraining labels in all scenarios. Any way, this is a non-debate, in the light of the email sent by Suresh in which he suggested that the constraints are implied by the nature of the TDM circuits. I agree with Suresh that there is no point of copying the same parameters using the other means, if they can be implied. Thanks Regards... Zafar >-----Original Message----- >From: Juneja, Manoj [mailto:m_juneja@trillium.com] >Sent: Wednesday, May 08, 2002 11:57 AM >To: John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; >'Ccamp (E-mail) >Cc: mpls@UU. NET (E-mail) >Subject: RE: Label Set Object > >Hi Jonh, > Sorry for creating the confusion. Should the label set be > used for establishing the SDH/SONET LSPs ? > >Regards, >manoj. >-----Original Message----- >From: John Drake [mailto:jdrake@calient.net] >Sent: Wednesday, May 08, 2002 11:50 AM >To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp >(E-mail) >Cc: mpls@UU. NET (E-mail) >Subject: RE: Label Set Object > >I didn't say that. >-----Original Message----- >From: Juneja, Manoj [mailto:m_juneja@trillium.com] >Sent: Wednesday, May 08, 2002 11:48 AM >To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) >Cc: mpls@UU. NET (E-mail) >Subject: RE: Label Set Object > >Hi John, > Did u mean Explicit label control is used only for > SDH/SONET case and is not used for FSC/LSC LSPs ? If this is the case > then it should be clearly mentioned in the draft. Furthermore, it should > also be mentioned that label set is not used for SDH/SONET LSPs. > >Regards, >manoj. >-----Original Message----- >From: John Drake [mailto:jdrake@calient.net] >Sent: Wednesday, May 08, 2002 11:26 AM >To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) >Cc: mpls@UU. NET (E-mail) >Subject: RE: Label Set Object > >Explicit Label Control is used to handle the SONET/SDH case. Its >semantics are different than Label Set, in the sense that there is one and >only one value, rather than a set that is manipulated end-end > >Thanks, > >John > >-----Original Message----- >From: Zafar Ali [mailto:zali@cisco.com] >Sent: Wednesday, May 08, 2002 10:31 AM >To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) >Cc: mpls@UU. NET (E-mail) >Subject: Re: Label Set Object > >Dear Vinay, > >Please see comments in-lined. > >Thanks > >Regards... Zafar >At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: >>Hi Zafar, >>The Label Set Object can't be sent to constrain the downstream label when >>the LSP encoding type is Sonet/SDH. Consider the example where a request >>is sent to downstream with SONET/SDH traffic parameters as NVC=n and >>MT=m. The label expected from the downstream would be 'm' set of labels >>each set consisting of 'n' labels further that identify each of the >>virtual concatenated components. So a Label Set in this scenario would >>consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a >>Label Set cannot be encoded using the object/TLV structure of Label Set >>as in "Generalized MPLS - Signalling Functional Description - >>draft-ietf-mpls-generalized-signaling-08.txt". >I think, this would be a second level question/ issue. IMO, we should be >able to build on the concept of a label set to incorporate technologies >other than WDM. Can we, in principle, agree on this or you are aware of an >alternative for the case you mentioned above? > >>Label Set Object can be sent only in WDM scenario where a single >>wavelength is requested as a label and the upstream has a restriction on >>the usable wavelengths. >IMHO this would be an undesirable restriction. Why its cannot cover the >single label case in SONET? > >>Correct me if I am going wrong anywhere. >> >>Regards >>Vinay >>>----- Original Message ----- >>>From: Zafar Ali >>>To: Manoj Agiwal ; >>>'Ccamp (E-mail) >>>Cc: mpls@UU. NET (E-mail) >>>Sent: Wednesday, May 08, 2002 11:04 AM >>>Subject: Re: Label Set Object >>> >>>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>>>Hi , >>>> In gmpls signaling extensionsions for RSVP-TE , ccamp >>>> architecture on >>>>gmpls has described Label Set object usage >>>> only for the "optical" domain viz. for carrying wavelengths ( Section >>>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . >>>> >>>> Do we require to send Label set(i.e. time slots) for TDM >>>> switching as >>>>well . In what way it can be useful . >>>Dear Manoj, >>> >>>Yes, label set object is also useful in TDM case. E.g., SONET poses an >>>additional requirement that the two interfaces of a bidirectional LSP >>>SHOULD traverse the exact same link with the same SUKLM values for the >>>two directions. >>> The label set object can be used to constrain the downstream label to >>> the same as the upstream label. >>> >>>Thanks >>> >>>Regards... Zafar >>> >>> >>> >>> >>> >>>>Regards , >>>>Manoj >>>=============== >>>Zafar Ali >>>Cisco Systems >>>(734) 276-2459 >>>100 S Main St. #200 >>>Ann Arbor, MI 48104. >>>email: zali@cisco.com =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com --=====================_34419362==_.ALT Content-Type: text/html; charset="us-ascii" At 01:07 PM 5/8/2002 -0700, John Drake wrote:
Label Set and Explicit Label Control are used for different purposes, and as I understand it, Explicit Label Control is more natural  for establishing SONET/SDH LSPs, while Label Set is more natural for establishing wavelength LSPs. 
You could, however, use Label Set for SONET/SDH LSPs and Explicit Label Control for wavelength LSPs.

Hi John,

While I agree with the last statement, I didn't understand why you mentioned that explicit label control is more natural for SONET/ SDH. IMHO the label set is a more natural way of constraining labels in all scenarios.

Any way, this is a non-debate, in the light of the email sent by Suresh in which he suggested that the constraints are implied by the nature of the TDM circuits. I agree with Suresh that there is no point of copying the same parameters using the other means, if they can be implied.

Thanks

Regards... Zafar
-----Original Message-----
From: Juneja, Manoj [mailto:m_juneja@trillium.com]
Sent: Wednesday, May 08, 2002 11:57 AM
To: John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object
Hi Jonh,
              Sorry for creating the confusion. Should the label set be used for establishing the SDH/SONET LSPs ?
 
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:50 AM
To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object
I didn't say that.
-----Original Message-----
From: Juneja, Manoj [mailto:m_juneja@trillium.com]
Sent: Wednesday, May 08, 2002 11:48 AM
To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object
Hi John,
               Did u mean Explicit label control is used only for SDH/SONET case  and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs.
 
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:26 AM
To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object
Explicit Label Control is used to handle the SONET/SDH case.  Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end
 
Thanks,
 
John
 
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 10:31 AM
To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: Re: Label Set Object
Dear Vinay,

Please see comments in-lined.

Thanks

Regards... Zafar
At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:
Hi Zafar,
The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt".
I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above?

Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths.
IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET?

Correct me if I am going wrong anywhere.
 
Regards
Vinay   
----- Original Message -----
From: Zafar Ali
To: Manoj Agiwal ; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Sent: Wednesday, May 08, 2002 11:04 AM
Subject: Re: Label Set Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .
Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar





Regards ,
Manoj
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
 --=====================_34419362==_.ALT-- From owner-mpls@UU.NET Wed May 8 19:28:22 2002 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 TAA26187 for ; Wed, 8 May 2002 19:28:21 -0400 (EDT) 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 QQmoaf22293; Wed, 8 May 2002 23:28:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoaf24236 for mpls-outgoing; Wed, 8 May 2002 23:28:03 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 QQmoaf24227 for ; Wed, 8 May 2002 23:28: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 QQmoaf01399 for ; Wed, 8 May 2002 23:27:05 GMT Received: from radiant.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fwsj.calient.net [63.102.55.194]) id QQmoaf25995 for ; Wed, 8 May 2002 23:27:03 GMT Received: by radiant.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 16:27:03 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC59F69D@nimbus> From: John Drake To: "'Zafar Ali'" , "'Juneja, Manoj'" , Vinay Vernekar , Manoj Agiwal , "'Ccamp (E-mail)" , skatukam@cisco.com Cc: "mpls@UU. NET (E-mail)" Subject: RE: Label Set Object Date: Wed, 8 May 2002 16:26:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6E7.D93A00E0" 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_01C1F6E7.D93A00E0 Content-Type: text/plain; charset="iso-8859-1" In the SONET/SDH case, there's always one and only one label, so isn't label set overkill? That's what I meant by 'more natural'. As George pointed out, in the downstream direction either explicit label control or a label set with one value is a useful thing in the manner of 'belt and suspenders' -----Original Message----- From: Zafar Ali [mailto:zali@cisco.com] Sent: Wednesday, May 08, 2002 4:05 PM To: John Drake; 'Juneja, Manoj'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail); skatukam@cisco.com Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object At 01:07 PM 5/8/2002 -0700, John Drake wrote: Label Set and Explicit Label Control are used for different purposes, and as I understand it, Explicit Label Control is more natural for establishing SONET/SDH LSPs, while Label Set is more natural for establishing wavelength LSPs. You could, however, use Label Set for SONET/SDH LSPs and Explicit Label Control for wavelength LSPs. Hi John, While I agree with the last statement, I didn't understand why you mentioned that explicit label control is more natural for SONET/ SDH. IMHO the label set is a more natural way of constraining labels in all scenarios. Any way, this is a non-debate, in the light of the email sent by Suresh in which he suggested that the constraints are implied by the nature of the TDM circuits. I agree with Suresh that there is no point of copying the same parameters using the other means, if they can be implied. Thanks Regards... Zafar -----Original Message----- From: Juneja, Manoj [ mailto:m_juneja@trillium.com ] Sent: Wednesday, May 08, 2002 11:57 AM To: John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Hi Jonh, Sorry for creating the confusion. Should the label set be used for establishing the SDH/SONET LSPs ? Regards, manoj. -----Original Message----- From: John Drake [ mailto:jdrake@calient.net ] Sent: Wednesday, May 08, 2002 11:50 AM To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object I didn't say that. -----Original Message----- From: Juneja, Manoj [ mailto:m_juneja@trillium.com ] Sent: Wednesday, May 08, 2002 11:48 AM To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Hi John, Did u mean Explicit label control is used only for SDH/SONET case and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs. Regards, manoj. -----Original Message----- From: John Drake [ mailto:jdrake@calient.net ] Sent: Wednesday, May 08, 2002 11:26 AM To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Explicit Label Control is used to handle the SONET/SDH case. Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end Thanks, John -----Original Message----- From: Zafar Ali [ mailto:zali@cisco.com ] Sent: Wednesday, May 08, 2002 10:31 AM To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: Re: Label Set Object Dear Vinay, Please see comments in-lined. Thanks Regards... Zafar At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: Hi Zafar, The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt". I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above? Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths. IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET? Correct me if I am going wrong anywhere. Regards Vinay ----- Original Message ----- From: Zafar Ali To: Manoj Agiwal ; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Sent: Wednesday, May 08, 2002 11:04 AM Subject: Re: Label Set Object At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: Hi , In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on gmpls has described Label Set object usage only for the "optical" domain viz. for carrying wavelengths ( Section 9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . Do we require to send Label set(i.e. time slots) for TDM switching as well . In what way it can be useful . Dear Manoj, Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions. The label set object can be used to constrain the downstream label to the same as the upstream label. Thanks Regards... Zafar Regards , Manoj =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com ------_=_NextPart_001_01C1F6E7.D93A00E0 Content-Type: text/html; charset="iso-8859-1"
In the SONET/SDH case, there's always one and only one label, so isn't label set overkill?  That's what I meant by 'more natural'.
 
As George pointed out, in the downstream direction either explicit label control or a label set with one value is a useful thing in the manner of 'belt and suspenders'
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 4:05 PM
To: John Drake; 'Juneja, Manoj'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail); skatukam@cisco.com
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

At 01:07 PM 5/8/2002 -0700, John Drake wrote:
Label Set and Explicit Label Control are used for different purposes, and as I understand it, Explicit Label Control is more natural  for establishing SONET/SDH LSPs, while Label Set is more natural for establishing wavelength LSPs. 
You could, however, use Label Set for SONET/SDH LSPs and Explicit Label Control for wavelength LSPs.

Hi John,

While I agree with the last statement, I didn't understand why you mentioned that explicit label control is more natural for SONET/ SDH. IMHO the label set is a more natural way of constraining labels in all scenarios.

Any way, this is a non-debate, in the light of the email sent by Suresh in which he suggested that the constraints are implied by the nature of the TDM circuits. I agree with Suresh that there is no point of copying the same parameters using the other means, if they can be implied.

Thanks

Regards... Zafar
-----Original Message-----
From: Juneja, Manoj [mailto:m_juneja@trillium.com]
Sent: Wednesday, May 08, 2002 11:57 AM
To: John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object
Hi Jonh,
              Sorry for creating the confusion. Should the label set be used for establishing the SDH/SONET LSPs ?
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:50 AM
To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object
I didn't say that.
-----Original Message-----
From: Juneja, Manoj [mailto:m_juneja@trillium.com]
Sent: Wednesday, May 08, 2002 11:48 AM
To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object
Hi John,
               Did u mean Explicit label control is used only for SDH/SONET case  and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs.
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:26 AM
To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object
Explicit Label Control is used to handle the SONET/SDH case.  Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end
Thanks,
John
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 10:31 AM
To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: Re: Label Set Object
Dear Vinay,

Please see comments in-lined.

Thanks

Regards... Zafar
At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:
Hi Zafar,
The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt".
I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above?

Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths.
IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET?

Correct me if I am going wrong anywhere.
Regards
Vinay   
----- Original Message -----
From: Zafar Ali
To: Manoj Agiwal ; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Sent: Wednesday, May 08, 2002 11:04 AM
Subject: Re: Label Set Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .
Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar





Regards ,
Manoj
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
------_=_NextPart_001_01C1F6E7.D93A00E0-- From owner-mpls@UU.NET Wed May 8 19:50:44 2002 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 TAA26351 for ; Wed, 8 May 2002 19:50:44 -0400 (EDT) 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 QQmoah20279; Wed, 8 May 2002 23:50:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoah26009 for mpls-outgoing; Wed, 8 May 2002 23: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 QQmoah26004 for ; Wed, 8 May 2002 23:50:26 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 QQmoah29578 for ; Wed, 8 May 2002 23:50:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmoah24165 for ; Wed, 8 May 2002 23:50:02 GMT 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 TAA27770 for ; Wed, 8 May 2002 19:50:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA08254 for mpls@uu.net; Wed, 8 May 2002 19:50:02 -0400 (EDT) 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 QQmoah25960 for ; Wed, 8 May 2002 23:49:03 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 QQmoah11522 for ; Wed, 8 May 2002 23:48:13 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQmoah21356 for ; Wed, 8 May 2002 23:48:13 GMT Received: from toque.cisco.com (IDENT:mirapoint@toque.cisco.com [161.44.201.11]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g48Nm2YM005185; Wed, 8 May 2002 16:48:03 -0700 (PDT) Received: from ANCAZ-W2K.cisco.com (che-vpn2-8.cisco.com [10.86.244.8]) by toque.cisco.com (Mirapoint) with ESMTP id AAP42777; Wed, 8 May 2002 19:43:46 -0400 (EDT) Message-Id: <4.3.2.7.2.20020508192337.01dd6130@toque.cisco.com> X-Sender: ancaz@toque.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 May 2002 19:47:51 -0400 To: Zafar Ali From: Anca Zamfir Subject: RE: Label Set Object Cc: John Drake , "'Juneja, Manoj'" , Vinay Vernekar , Manoj Agiwal , "'Ccamp (E-mail)" , skatukam@cisco.com, "mpls@UU. NET (E-mail)" In-Reply-To: <4.3.2.7.2.20020508181334.058a4258@sword.cisco.com> References: <9D42C6E086250248810DCADA39CE7EFC59F69A@nimbus> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Trying to find the answer to the original question. If a node wants to use Label Set to make sure the downstream label has the same value as the upstream one, then, I don't see why it cannot fill in the Label Set in the same way it fills in the Upstream Label, as described in draft-ietf-ccamp-gmpls-sonet-sdh-03.txt, section 3, for the case NVC=n and MT=m case. (Theoretically a node could apply this algorithm p times) A node that receives and chooses to interpret LabelSet would know how to interpret its content by looking at the traffic parameters (in particular for this example at the NVC and MT values) which would provide a way to "decode" the ordered set of SUKLM labels present in Label Set. I may be wrong, but I think in theory it is possible to use Label Set for this case. As others pointed out, not sure how practical it is. Anca At 07:04 PM 5/8/2002 -0400, Zafar Ali wrote: >At 01:07 PM 5/8/2002 -0700, John Drake wrote: >>Label Set and Explicit Label Control are used for different purposes, and >>as I understand it, Explicit Label Control is more natural for >>establishing SONET/SDH LSPs, while Label Set is more natural for >>establishing wavelength LSPs. >>You could, however, use Label Set for SONET/SDH LSPs and Explicit Label >>Control for wavelength LSPs. > >Hi John, > >While I agree with the last statement, I didn't understand why you >mentioned that explicit label control is more natural for SONET/ SDH. IMHO >the label set is a more natural way of constraining labels in all scenarios. > >Any way, this is a non-debate, in the light of the email sent by Suresh in >which he suggested that the constraints are implied by the nature of the >TDM circuits. I agree with Suresh that there is no point of copying the >same parameters using the other means, if they can be implied. > >Thanks > >Regards... Zafar >>-----Original Message----- >>From: Juneja, Manoj [mailto:m_juneja@trillium.com] >>Sent: Wednesday, May 08, 2002 11:57 AM >>To: John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; >>'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: RE: Label Set Object >> >>Hi Jonh, >> Sorry for creating the confusion. Should the label set be >> used for establishing the SDH/SONET LSPs ? >> >>Regards, >>manoj. >>-----Original Message----- >>From: John Drake [mailto:jdrake@calient.net] >>Sent: Wednesday, May 08, 2002 11:50 AM >>To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp >>(E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: RE: Label Set Object >> >>I didn't say that. >>-----Original Message----- >>From: Juneja, Manoj [mailto:m_juneja@trillium.com] >>Sent: Wednesday, May 08, 2002 11:48 AM >>To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: RE: Label Set Object >> >>Hi John, >> Did u mean Explicit label control is used only for >> SDH/SONET case and is not used for FSC/LSC LSPs ? If this is the case >> then it should be clearly mentioned in the draft. Furthermore, it should >> also be mentioned that label set is not used for SDH/SONET LSPs. >> >>Regards, >>manoj. >>-----Original Message----- >>From: John Drake [mailto:jdrake@calient.net] >>Sent: Wednesday, May 08, 2002 11:26 AM >>To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: RE: Label Set Object >> >>Explicit Label Control is used to handle the SONET/SDH case. Its >>semantics are different than Label Set, in the sense that there is one >>and only one value, rather than a set that is manipulated end-end >> >>Thanks, >> >>John >> >>-----Original Message----- >>From: Zafar Ali [mailto:zali@cisco.com] >>Sent: Wednesday, May 08, 2002 10:31 AM >>To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: Re: Label Set Object >> >>Dear Vinay, >> >>Please see comments in-lined. >> >>Thanks >> >>Regards... Zafar >>At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: >>>Hi Zafar, >>>The Label Set Object can't be sent to constrain the downstream label >>>when the LSP encoding type is Sonet/SDH. Consider the example where a >>>request is sent to downstream with SONET/SDH traffic parameters as NVC=n >>>and MT=m. The label expected from the downstream would be 'm' set of >>>labels each set consisting of 'n' labels further that identify each of >>>the virtual concatenated components. So a Label Set in this scenario >>>would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. >>>Such a Label Set cannot be encoded using the object/TLV structure of >>>Label Set as in "Generalized MPLS - Signalling Functional Description - >>>draft-ietf-mpls-generalized-signaling-08.txt". >>I think, this would be a second level question/ issue. IMO, we should be >>able to build on the concept of a label set to incorporate technologies >>other than WDM. Can we, in principle, agree on this or you are aware of >>an alternative for the case you mentioned above? >>>Label Set Object can be sent only in WDM scenario where a single >>>wavelength is requested as a label and the upstream has a restriction on >>>the usable wavelengths. >>IMHO this would be an undesirable restriction. Why its cannot cover the >>single label case in SONET? >> >>>Correct me if I am going wrong anywhere. >>> >>>Regards >>>Vinay >>>>----- Original Message ----- >>>>From: Zafar Ali >>>>To: Manoj Agiwal ; >>>>'Ccamp (E-mail) >>>>Cc: mpls@UU. NET (E-mail) >>>>Sent: Wednesday, May 08, 2002 11:04 AM >>>>Subject: Re: Label Set Object >>>> >>>>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>>>>Hi , >>>>> In gmpls signaling extensionsions for RSVP-TE , ccamp >>>>> architecture on >>>>>gmpls has described Label Set object usage >>>>> only for the "optical" domain viz. for carrying wavelengths ( >>>>> Section >>>>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . >>>>> >>>>> Do we require to send Label set(i.e. time slots) for TDM >>>>> switching as >>>>>well . In what way it can be useful . >>>>Dear Manoj, >>>> >>>>Yes, label set object is also useful in TDM case. E.g., SONET poses an >>>>additional requirement that the two interfaces of a bidirectional LSP >>>>SHOULD traverse the exact same link with the same SUKLM values for the >>>>two directions. >>>> The label set object can be used to constrain the downstream label to >>>> the same as the upstream label. >>>> >>>>Thanks >>>> >>>>Regards... Zafar >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Regards , >>>>>Manoj >>>>=============== >>>>Zafar Ali >>>>Cisco Systems >>>>(734) 276-2459 >>>>100 S Main St. #200 >>>>Ann Arbor, MI 48104. >>>>email: zali@cisco.com > > >=============== >Zafar Ali >Cisco Systems >(734) 276-2459 >100 S Main St. #200 >Ann Arbor, MI 48104. >email: zali@cisco.com From owner-mpls@UU.NET Wed May 8 21:38:27 2002 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 VAA29123 for ; Wed, 8 May 2002 21:38:26 -0400 (EDT) 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 QQmoao06308; Thu, 9 May 2002 01:38:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoao18143 for mpls-outgoing; Thu, 9 May 2002 01:38:18 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 QQmoao18136 for ; Thu, 9 May 2002 01:38:09 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 QQmoao28696 for ; Thu, 9 May 2002 01:37:34 GMT Received: from lightwave.chromisys.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: radiant.calient.net [63.102.55.206]) id QQmoao05050 for ; Thu, 9 May 2002 01:37:34 GMT Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 18:37:33 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC59F69F@nimbus> From: John Drake To: "'Suresh Katukam'" , Zafar Ali Cc: Manoj Agiwal , Manoj Agiwal , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: RE: Label Set Object Date: Wed, 8 May 2002 18:37:32 -0700 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 Is it the case that ALL current SONET/SDH equipment has the restriction that the labels (timeslots) must be the same in both directions? If this is the case, then it's really simple; for an SONET/SDH LSP, only the upstream label needs to be specified, and the downstream label MUST be the same. One the other hand, if not all current SONET/SDH equipment has this restriction or the current SONET/SDH standards allow the labels (timeslots) to be different in each direction, then label set with one value or explicit label control would be useful for equipment that does have this restriction. -----Original Message----- From: Suresh Katukam [mailto:skatukam@cisco.com] Sent: Wednesday, May 08, 2002 3:23 PM To: Zafar Ali Cc: Manoj Agiwal; Manoj Agiwal; 'Ccamp (E-mail); mpls@UU. NET (E-mail) Subject: RE: Label Set Object For TDM, since you have to use same labels in both directions, why do you have to specify anything at all? How can a downstream TDM node pick a label that does not match with Upstream label for a bidirectional LSP? If it picks any other label, LSP is not functional. If there are Uni-directional LSPs in TDM and if you have different types of time slots available in both directions, then one may be able to setup bidirectional LSP on different links or different labels. This is in theory and not in practice. So in practice, one does not need to specify LABEL SET or Suggested label for TDM links. Thanks, Suresh At 01:53 AM 5/8/2002 -0400, Zafar Ali wrote: >At 11:11 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>Hi , >> I guess in that case we can use Suggested Label , Label Set still can >> still be avoided . > >Hi Manoj, > >No, the use of suggested label in this case would NOT be correct, as the >suggested labels can be ignored/ overridden by the receiving node. > >Thanks > >Regards... Zafar > >>Regards , >>Manoj >>-----Original Message----- >>From: Zafar Ali [mailto:zali@cisco.com] >>Sent: Wednesday, May 08, 2002 11:05 AM >>To: Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: Re: Label Set Object >> >>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>>Hi , >>> In gmpls signaling extensionsions for RSVP-TE , ccamp >>> architecture on >>>gmpls has described Label Set object usage >>> only for the "optical" domain viz. for carrying wavelengths ( Section >>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . >>> >>> Do we require to send Label set(i.e. time slots) for TDM >>> switching as >>>well . In what way it can be useful . >>Dear Manoj, >> >>Yes, label set object is also useful in TDM case. E.g., SONET poses an >>additional requirement that the two interfaces of a bidirectional LSP >>SHOULD traverse the exact same link with the same SUKLM values for the >>two directions. >> The label set object can be used to constrain the downstream label to >> the same as the upstream label. >> >>Thanks >> >>Regards... Zafar >> >> >> >> >> >> >> >> >> >>>Regards , >>>Manoj >>=============== >>Zafar Ali >>Cisco Systems >>(734) 276-2459 >>100 S Main St. #200 >>Ann Arbor, MI 48104. >>email: zali@cisco.com > >=============== >Zafar Ali >Cisco Systems >(734) 276-2459 >100 S Main St. #200 >Ann Arbor, MI 48104. >email: zali@cisco.com From owner-mpls@UU.NET Wed May 8 22:43:39 2002 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 WAA01361 for ; Wed, 8 May 2002 22:43:39 -0400 (EDT) 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 QQmoas16497; Thu, 9 May 2002 02:43:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoas15270 for mpls-outgoing; Thu, 9 May 2002 02:43: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 QQmoas15265 for ; Thu, 9 May 2002 02:43: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 QQmoas22187 for ; Thu, 9 May 2002 02:42:31 GMT Received: from lightwave.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: radiant.calient.net [63.102.55.206]) id QQmoas21794 for ; Thu, 9 May 2002 02:42:30 GMT Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 19:42:30 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC59F6A2@nimbus> From: John Drake To: "'Anca Zamfir'" , Zafar Ali Cc: "'Juneja, Manoj'" , Vinay Vernekar , Manoj Agiwal , "'Ccamp (E-mail)" , skatukam@cisco.com, "mpls@UU. NET (E-mail)" Subject: RE: Label Set Object Date: Wed, 8 May 2002 19:42:29 -0700 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 Lou and I just reviewed section 5.1.1 of draft-ietf-mpls-generalized-rsvp-te-07.txt (rather than draft-ietf-mpls-generalized-signaling-08.txt, which is what I looked at this morning), and it's pretty clear. The upstream node processing the ERO for the outgoing link checks whether there are explicit label control subobjects for upstream or downstream. An explicit label control for upstream is replaced in the ERO with an upstream label and an explicit label control for downstream is replaced with a label set with the same label. This is so done so that there is only one mechanism for an upstream node to specify the downstream label; explicit label control is only used by a remote node. So the only question is whether for SONET/SDH LSPs, this mechanism is required. -----Original Message----- From: Anca Zamfir [mailto:ancaz@cisco.com] Sent: Wednesday, May 08, 2002 4:48 PM To: Zafar Ali Cc: John Drake; 'Juneja, Manoj'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail); skatukam@cisco.com; mpls@UU. NET (E-mail) Subject: RE: Label Set Object Trying to find the answer to the original question. If a node wants to use Label Set to make sure the downstream label has the same value as the upstream one, then, I don't see why it cannot fill in the Label Set in the same way it fills in the Upstream Label, as described in draft-ietf-ccamp-gmpls-sonet-sdh-03.txt, section 3, for the case NVC=n and MT=m case. (Theoretically a node could apply this algorithm p times) A node that receives and chooses to interpret LabelSet would know how to interpret its content by looking at the traffic parameters (in particular for this example at the NVC and MT values) which would provide a way to "decode" the ordered set of SUKLM labels present in Label Set. I may be wrong, but I think in theory it is possible to use Label Set for this case. As others pointed out, not sure how practical it is. Anca At 07:04 PM 5/8/2002 -0400, Zafar Ali wrote: >At 01:07 PM 5/8/2002 -0700, John Drake wrote: >>Label Set and Explicit Label Control are used for different purposes, and >>as I understand it, Explicit Label Control is more natural for >>establishing SONET/SDH LSPs, while Label Set is more natural for >>establishing wavelength LSPs. >>You could, however, use Label Set for SONET/SDH LSPs and Explicit Label >>Control for wavelength LSPs. > >Hi John, > >While I agree with the last statement, I didn't understand why you >mentioned that explicit label control is more natural for SONET/ SDH. IMHO >the label set is a more natural way of constraining labels in all scenarios. > >Any way, this is a non-debate, in the light of the email sent by Suresh in >which he suggested that the constraints are implied by the nature of the >TDM circuits. I agree with Suresh that there is no point of copying the >same parameters using the other means, if they can be implied. > >Thanks > >Regards... Zafar >>-----Original Message----- >>From: Juneja, Manoj [mailto:m_juneja@trillium.com] >>Sent: Wednesday, May 08, 2002 11:57 AM >>To: John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; >>'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: RE: Label Set Object >> >>Hi Jonh, >> Sorry for creating the confusion. Should the label set be >> used for establishing the SDH/SONET LSPs ? >> >>Regards, >>manoj. >>-----Original Message----- >>From: John Drake [mailto:jdrake@calient.net] >>Sent: Wednesday, May 08, 2002 11:50 AM >>To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp >>(E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: RE: Label Set Object >> >>I didn't say that. >>-----Original Message----- >>From: Juneja, Manoj [mailto:m_juneja@trillium.com] >>Sent: Wednesday, May 08, 2002 11:48 AM >>To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: RE: Label Set Object >> >>Hi John, >> Did u mean Explicit label control is used only for >> SDH/SONET case and is not used for FSC/LSC LSPs ? If this is the case >> then it should be clearly mentioned in the draft. Furthermore, it should >> also be mentioned that label set is not used for SDH/SONET LSPs. >> >>Regards, >>manoj. >>-----Original Message----- >>From: John Drake [mailto:jdrake@calient.net] >>Sent: Wednesday, May 08, 2002 11:26 AM >>To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: RE: Label Set Object >> >>Explicit Label Control is used to handle the SONET/SDH case. Its >>semantics are different than Label Set, in the sense that there is one >>and only one value, rather than a set that is manipulated end-end >> >>Thanks, >> >>John >> >>-----Original Message----- >>From: Zafar Ali [mailto:zali@cisco.com] >>Sent: Wednesday, May 08, 2002 10:31 AM >>To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: Re: Label Set Object >> >>Dear Vinay, >> >>Please see comments in-lined. >> >>Thanks >> >>Regards... Zafar >>At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: >>>Hi Zafar, >>>The Label Set Object can't be sent to constrain the downstream label >>>when the LSP encoding type is Sonet/SDH. Consider the example where a >>>request is sent to downstream with SONET/SDH traffic parameters as NVC=n >>>and MT=m. The label expected from the downstream would be 'm' set of >>>labels each set consisting of 'n' labels further that identify each of >>>the virtual concatenated components. So a Label Set in this scenario >>>would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. >>>Such a Label Set cannot be encoded using the object/TLV structure of >>>Label Set as in "Generalized MPLS - Signalling Functional Description - >>>draft-ietf-mpls-generalized-signaling-08.txt". >>I think, this would be a second level question/ issue. IMO, we should be >>able to build on the concept of a label set to incorporate technologies >>other than WDM. Can we, in principle, agree on this or you are aware of >>an alternative for the case you mentioned above? >>>Label Set Object can be sent only in WDM scenario where a single >>>wavelength is requested as a label and the upstream has a restriction on >>>the usable wavelengths. >>IMHO this would be an undesirable restriction. Why its cannot cover the >>single label case in SONET? >> >>>Correct me if I am going wrong anywhere. >>> >>>Regards >>>Vinay >>>>----- Original Message ----- >>>>From: Zafar Ali >>>>To: Manoj Agiwal ; >>>>'Ccamp (E-mail) >>>>Cc: mpls@UU. NET (E-mail) >>>>Sent: Wednesday, May 08, 2002 11:04 AM >>>>Subject: Re: Label Set Object >>>> >>>>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>>>>Hi , >>>>> In gmpls signaling extensionsions for RSVP-TE , ccamp >>>>> architecture on >>>>>gmpls has described Label Set object usage >>>>> only for the "optical" domain viz. for carrying wavelengths ( >>>>> Section >>>>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . >>>>> >>>>> Do we require to send Label set(i.e. time slots) for TDM >>>>> switching as >>>>>well . In what way it can be useful . >>>>Dear Manoj, >>>> >>>>Yes, label set object is also useful in TDM case. E.g., SONET poses an >>>>additional requirement that the two interfaces of a bidirectional LSP >>>>SHOULD traverse the exact same link with the same SUKLM values for the >>>>two directions. >>>> The label set object can be used to constrain the downstream label to >>>> the same as the upstream label. >>>> >>>>Thanks >>>> >>>>Regards... Zafar >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Regards , >>>>>Manoj >>>>=============== >>>>Zafar Ali >>>>Cisco Systems >>>>(734) 276-2459 >>>>100 S Main St. #200 >>>>Ann Arbor, MI 48104. >>>>email: zali@cisco.com > > >=============== >Zafar Ali >Cisco Systems >(734) 276-2459 >100 S Main St. #200 >Ann Arbor, MI 48104. >email: zali@cisco.com From owner-mpls@UU.NET Thu May 9 01:15:06 2002 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 BAA03377 for ; Thu, 9 May 2002 01:15:06 -0400 (EDT) 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 QQmobd15737; Thu, 9 May 2002 05:15:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmobc02755 for mpls-outgoing; Thu, 9 May 2002 05: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 QQmobc02750 for ; Thu, 9 May 2002 05:14: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 QQmobc07183 for ; Thu, 9 May 2002 05:13:56 GMT Received: from samar.sasken.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQmobc14580 for ; Thu, 9 May 2002 05:13:49 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g495DVU09644; Thu, 9 May 2002 10:43:31 +0530 (IST) Received: from sushanth (pcsva235.sasken.com [10.1.65.235]) by sunsv2.sasken.com (8.11.6/8.11.6) with SMTP id g495DQB22892; Thu, 9 May 2002 10:43:26 +0530 (IST) From: "sushantm" To: "John Drake" Cc: "Manoj Agiwal" , "'Ccamp \(E-mail\)" , "mpls@UU. NET \(E-mail\)" , "'Suresh Katukam'" , "Zafar Ali" Subject: RE: Label Set Object Date: Thu, 9 May 2002 10:45:11 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <9D42C6E086250248810DCADA39CE7EFC59F69F@nimbus> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: High Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi John , I agree to the first case but in the second case, suppose the ERO is not used , why would we have to restrict the Label set to only one label value ? -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of John Drake Sent: Thursday, May 09, 2002 7:08 AM To: 'Suresh Katukam'; Zafar Ali Cc: Manoj Agiwal; Manoj Agiwal; 'Ccamp (E-mail); mpls@UU. NET (E-mail) Subject: RE: Label Set Object Is it the case that ALL current SONET/SDH equipment has the restriction that the labels (timeslots) must be the same in both directions? If this is the case, then it's really simple; for an SONET/SDH LSP, only the upstream label needs to be specified, and the downstream label MUST be the same. One the other hand, if not all current SONET/SDH equipment has this restriction or the current SONET/SDH standards allow the labels (timeslots) to be different in each direction, then label set with one value or explicit label control would be useful for equipment that does have this restriction. -----Original Message----- From: Suresh Katukam [mailto:skatukam@cisco.com] Sent: Wednesday, May 08, 2002 3:23 PM To: Zafar Ali Cc: Manoj Agiwal; Manoj Agiwal; 'Ccamp (E-mail); mpls@UU. NET (E-mail) Subject: RE: Label Set Object For TDM, since you have to use same labels in both directions, why do you have to specify anything at all? How can a downstream TDM node pick a label that does not match with Upstream label for a bidirectional LSP? If it picks any other label, LSP is not functional. If there are Uni-directional LSPs in TDM and if you have different types of time slots available in both directions, then one may be able to setup bidirectional LSP on different links or different labels. This is in theory and not in practice. So in practice, one does not need to specify LABEL SET or Suggested label for TDM links. Thanks, Suresh At 01:53 AM 5/8/2002 -0400, Zafar Ali wrote: >At 11:11 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>Hi , >> I guess in that case we can use Suggested Label , Label Set still can >> still be avoided . > >Hi Manoj, > >No, the use of suggested label in this case would NOT be correct, as the >suggested labels can be ignored/ overridden by the receiving node. > >Thanks > >Regards... Zafar > >>Regards , >>Manoj >>-----Original Message----- >>From: Zafar Ali [mailto:zali@cisco.com] >>Sent: Wednesday, May 08, 2002 11:05 AM >>To: Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: Re: Label Set Object >> >>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>>Hi , >>> In gmpls signaling extensionsions for RSVP-TE , ccamp >>> architecture on >>>gmpls has described Label Set object usage >>> only for the "optical" domain viz. for carrying wavelengths ( Section >>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . >>> >>> Do we require to send Label set(i.e. time slots) for TDM >>> switching as >>>well . In what way it can be useful . >>Dear Manoj, >> >>Yes, label set object is also useful in TDM case. E.g., SONET poses an >>additional requirement that the two interfaces of a bidirectional LSP >>SHOULD traverse the exact same link with the same SUKLM values for the >>two directions. >> The label set object can be used to constrain the downstream label to >> the same as the upstream label. >> >>Thanks >> >>Regards... Zafar >> >> >> >> >> >> >> >> >> >>>Regards , >>>Manoj >>=============== >>Zafar Ali >>Cisco Systems >>(734) 276-2459 >>100 S Main St. #200 >>Ann Arbor, MI 48104. >>email: zali@cisco.com > >=============== >Zafar Ali >Cisco Systems >(734) 276-2459 >100 S Main St. #200 >Ann Arbor, MI 48104. >email: zali@cisco.com From owner-mpls@UU.NET Thu May 9 02:19:47 2002 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 CAA12524 for ; Thu, 9 May 2002 02:19:47 -0400 (EDT) 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 QQmobh21392; Thu, 9 May 2002 06:19:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmobh29933 for mpls-outgoing; Thu, 9 May 2002 06:19: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 QQmobh29926 for ; Thu, 9 May 2002 06:19: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 QQmobh17051 for ; Thu, 9 May 2002 06:18:44 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 QQmobh20238 for ; Thu, 9 May 2002 06:18:43 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 g496IgT26445; Wed, 8 May 2002 23:18:42 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id g496Ifj61993; Wed, 8 May 2002 23:18:42 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 8 May 2002 23:18:41 -0700 (PDT) From: Kireeti Kompella To: Don Fedyk cc: , CCAMP , Subject: RE: How many can administrative groups assigned? In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E6023F1085@zcard0ke.ca.nortel.com> Message-ID: <20020508231129.C61949-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Wed, 8 May 2002, Don Fedyk wrote: > You state the definitions are clear Here's what the OSPF TE doc says: 2.5.9. Resource Class/Color The Resource Class/Color sub-TLV specifies administrative group membership for this link, in terms of a bit mask. The ISIS TE doc has: 4.1 Sub-TLV 3: Administrative group (color, resource class) The administrative group sub-TLV contains a 4-octet bit mask assigned by the network administrator. Each set bit corresponds to one administrative group assigned to the interface. Seems perfectly clear to me that both are talking about *bits*; the OSPF doc uses the term 'bit mask', which makes it crystal clear. > but last time I read a couple of > implementations > from vendor specification they were different. Since when does a vendor's "specification" define a standard? > While I agree we should keep the complexity to a minimum, > when I floated a simple request to define the bits the > pushback we got was it was too inflexible. Different issue altogether. The semantics of *bits* is perfectly clear. The *use* of bits should be left completely up to the user. Kireeti. From owner-mpls@UU.NET Thu May 9 13:20:05 2002 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 NAA01326 for ; Thu, 9 May 2002 13:20:05 -0400 (EDT) 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 QQmocz05930; Thu, 9 May 2002 17:20:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQmocz23032 for mpls-outgoing; Thu, 9 May 2002 17:19: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 QQmocz23027 for ; Thu, 9 May 2002 17:19: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 QQmocz20240 for ; Thu, 9 May 2002 17:19:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmocz25133 for ; Thu, 9 May 2002 17:19:02 GMT 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 NAA14772 for ; Thu, 9 May 2002 13:19:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA22129 for mpls@uu.net; Thu, 9 May 2002 13:19:01 -0400 (EDT) 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 QQmocz22976 for ; Thu, 9 May 2002 17:17:52 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 QQmocz09048 for ; Thu, 9 May 2002 17:16:38 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 QQmocz02271 for ; Thu, 9 May 2002 17:16:38 GMT Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.45 2002/05/03 22:11:31 root Exp $) with ESMTP id g49HFXD08001 for ; Thu, 9 May 2002 17:15:33 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.18 2002/05/02 20:17:19 root Exp $) with SMTP id g49HJKZ15835 for ; Thu, 9 May 2002 17:19:20 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002050910210713003 for ; Thu, 09 May 2002 10:21:08 -0700 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 10:16:36 -0700 Message-ID: <86DB568235A8D511ABAC0002A5072CA506714AAF@orsmsx120.jf.intel.com> From: "Zhong, Haibo" To: mpls@UU.NET Subject: Unsubscribe Date: Thu, 9 May 2002 10:16:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F77D.461CA6A0" 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_01C1F77D.461CA6A0 Content-Type: text/plain; charset="iso-8859-1" unsubscribe unsubscribe unsubscribe unsubscribe unsubscribe unsubscribe unsubscribe unsubscribe unsubscribe unsubscribe unsubscribe unsubscribe unsubscribe unsubscribe unsubscribe unsubscribeHaibo Zhong Trillium Digital Co. Intel Network Software Division 12100 Wilshire Blvd. Suite 1800 Los Angeles, CA 90025 Tel: 310.481.5895 ------_=_NextPart_001_01C1F77D.461CA6A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsubscribe
unsubscribe
unsubscribe
unsubscribe
unsubscribe
unsubscribe
unsubscribe
unsubscribe
unsubscribe
unsubscribe
unsubscribe
unsubscribe
unsubscribe
unsubscribe
unsubscribe
unsubscribe<= /FONT>Haibo=20 Zhong
Trillium = Digital=20 Co.
Intel = Network Software=20 Division
12100 = Wilshire Blvd. Suite=20 1800
Los = Angeles, CA=20 90025
 Tel:=20 310.481.5895
 
------_=_NextPart_001_01C1F77D.461CA6A0-- From owner-mpls@UU.NET Thu May 9 14:19:33 2002 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 OAA03489 for ; Thu, 9 May 2002 14:19:32 -0400 (EDT) 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 QQmodd10522; Thu, 9 May 2002 18:19:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmodd19779 for mpls-outgoing; Thu, 9 May 2002 18:19: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 QQmodd19774 for ; Thu, 9 May 2002 18:19:19 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 QQmodd23259 for ; Thu, 9 May 2002 18:19:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmodd09549 for ; Thu, 9 May 2002 18:19:02 GMT 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 OAA19431 for ; Thu, 9 May 2002 14:19:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA29167 for mpls@uu.net; Thu, 9 May 2002 14:19:02 -0400 (EDT) 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 QQmodd19755 for ; Thu, 9 May 2002 18:18:40 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 QQmodd21046 for ; Thu, 9 May 2002 18:18:01 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 QQmodd07848 for ; Thu, 9 May 2002 18:18:00 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 g49IIO33023132; Thu, 9 May 2002 14:18:24 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (ch2-dhcp134-167.cisco.com [161.44.134.167]) by bucket.cisco.com (Mirapoint) with ESMTP id AAZ84238; Thu, 9 May 2002 14:17:57 -0400 (EDT) Message-Id: <4.3.2.7.2.20020509141732.025a6950@bucket> X-Sender: tnadeau@bucket X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 May 2002 14:17:57 -0400 To: Shahram Davari From: "Thomas D. Nadeau" Subject: Re: LSR MIB question Cc: "'mpls@UU.net'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE84A7B8@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >What is the definition of error in "mplsInSegmentErrors" ? The number of errored packets received on the segment (label). The error condition is determined locally. --Tom >Yours, >Shahram Davari >Senior Product Research Engineer >R&D Research Ottawa >PMC-Sierra, Inc. >Phone: (613) 271-4018 >Fax: (613) 271-6468 ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Thu May 9 14:24:26 2002 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 OAA03878 for ; Thu, 9 May 2002 14:24:26 -0400 (EDT) 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 QQmodd21562; Thu, 9 May 2002 18:24:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQmodd20157 for mpls-outgoing; Thu, 9 May 2002 18:24:19 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 QQmodd20152 for ; Thu, 9 May 2002 18:24:12 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 QQmodd13748 for ; Thu, 9 May 2002 18:24:04 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmodd11980 for ; Thu, 9 May 2002 18:24:04 GMT 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 OAA19794 for ; Thu, 9 May 2002 14:24:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA00129 for mpls@uu.net; Thu, 9 May 2002 14:24:03 -0400 (EDT) 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 QQmodd20111 for ; Thu, 9 May 2002 18:23:38 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 QQmodd03720 for ; Thu, 9 May 2002 18:23:22 GMT Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmodd18994 for ; Thu, 9 May 2002 18:23:22 GMT Received: (qmail 10906 invoked by uid 104); 9 May 2002 18:23:20 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4202. . Clean. Processed in 3.478661 secs); 09 May 2002 18:23:20 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 9 May 2002 18:23:15 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g49INCp01226; Thu, 9 May 2002 11:23:12 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 11:23:16 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A7BA@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau'" Cc: "'mpls@UU.net'" Subject: RE: LSR MIB question Date: Thu, 9 May 2002 11:23:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk So there is no standard definition for error? -Shahram > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Thursday, May 09, 2002 2:18 PM > To: Shahram Davari > Cc: 'mpls@UU.net' > Subject: Re: LSR MIB question > > > > > >What is the definition of error in "mplsInSegmentErrors" ? > > The number of errored packets received on the > segment (label). > The error condition is determined locally. > > --Tom > > > > >Yours, > >Shahram Davari > >Senior Product Research Engineer > >R&D Research Ottawa > >PMC-Sierra, Inc. > >Phone: (613) 271-4018 > >Fax: (613) 271-6468 > > > > -------------------------------------------------------------- > ---------- > Mathematics is the supreme nostalgia of our time. > From owner-mpls@UU.NET Thu May 9 14:37:32 2002 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 OAA04553 for ; Thu, 9 May 2002 14:37:32 -0400 (EDT) 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 QQmode17554; Thu, 9 May 2002 18:37:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmode21428 for mpls-outgoing; Thu, 9 May 2002 18:37: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 QQmode21423 for ; Thu, 9 May 2002 18:37:13 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 QQmode02737 for ; Thu, 9 May 2002 18:37:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmode28430 for ; Thu, 9 May 2002 18:37:03 GMT 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 OAA20795 for ; Thu, 9 May 2002 14:37:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA02586 for mpls@uu.net; Thu, 9 May 2002 14:37:02 -0400 (EDT) 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 QQmode21198 for ; Thu, 9 May 2002 18:35: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 QQmode18252 for ; Thu, 9 May 2002 18:35:01 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 QQmode11769 for ; Thu, 9 May 2002 18:35:00 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 g49IZN0L024809; Thu, 9 May 2002 14:35:24 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (ch2-dhcp134-167.cisco.com [161.44.134.167]) by bucket.cisco.com (Mirapoint) with ESMTP id AAZ84631; Thu, 9 May 2002 14:34:56 -0400 (EDT) Message-Id: <4.3.2.7.2.20020509143009.025f5008@bucket> X-Sender: tnadeau@bucket X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 May 2002 14:34:55 -0400 To: Shahram Davari From: "Thomas D. Nadeau" Subject: RE: LSR MIB question Cc: "'mpls@UU.net'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE84A7BA@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >So there is no standard definition for error? This is defined along the same lines as the packet error counters in RFC2233 (and its newest version). The specific nature of the error is not spelled out, just that the device could not forward the packet. ifInErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol. For character-oriented or fixed-length interfaces, the number of inbound transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifEntry 14 } --Tom >-Shahram > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Thursday, May 09, 2002 2:18 PM > > To: Shahram Davari > > Cc: 'mpls@UU.net' > > Subject: Re: LSR MIB question > > > > > > > > > > >What is the definition of error in "mplsInSegmentErrors" ? > > > > The number of errored packets received on the > > segment (label). > > The error condition is determined locally. > > > > --Tom > > > > > > > > >Yours, > > >Shahram Davari > > >Senior Product Research Engineer > > >R&D Research Ottawa > > >PMC-Sierra, Inc. > > >Phone: (613) 271-4018 > > >Fax: (613) 271-6468 > > > > > > > > -------------------------------------------------------------- > > ---------- > > Mathematics is the supreme nostalgia of our time. > > ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Thu May 9 15:54:04 2002 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 PAA06820 for ; Thu, 9 May 2002 15:54:03 -0400 (EDT) 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 QQmodj00641; Thu, 9 May 2002 19:54:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQmodj19562 for mpls-outgoing; Thu, 9 May 2002 19:53:55 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 QQmodj19557 for ; Thu, 9 May 2002 19:53:54 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 QQmodj22882 for ; Thu, 9 May 2002 19:53:36 GMT Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: exchange.movaz.com [65.205.166.141]) id QQmodj27383 for ; Thu, 9 May 2002 19:53:36 GMT Received: from BLIULAPTOP ([10.18.0.34]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 9 May 2002 15:53:35 -0400 Message-ID: <046601c1f793$34a7a620$2200120a@movaz.com> From: "Adrian Farrel" To: "John Drake" , "'Anca Zamfir'" , "Zafar Ali" Cc: "'Juneja, Manoj'" , "Vinay Vernekar" , "Manoj Agiwal" , "'Ccamp \(E-mail\)" , , "mpls@UU. NET \(E-mail\)" References: <9D42C6E086250248810DCADA39CE7EFC59F6A2@nimbus> Subject: Re: Label Set Object Date: Thu, 9 May 2002 15:53:35 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 09 May 2002 19:53:35.0944 (UTC) FILETIME=[34B25480:01C1F793] Sender: owner-mpls@UU.NET Precedence: bulk Suppose (just suppose) that I want a unidirectional sonet LSP and that I want to constrain the label choice to a specific value. Note that this is distinct from the question of what labels to use in each direction for bidirectional. It is clear how I signal it. No issues. Label Request, Label Set with one member... Now suppose I also want a bidirectional sonet LSP. How do I indicate that it is bidirectional? I believe the only method is to include an Upstream Label. Could we say that bidirectional uses Upstream Label only, and unidirectional uses Label Set only? Yes. Would that be a good idea? I don't see think that having multiple choices of presence of objects is useful. Could an implementation choose to ignore one of the objects and act only on the other? Of course. Adrian ----- Original Message ----- From: "John Drake" To: "'Anca Zamfir'" ; "Zafar Ali" Cc: "'Juneja, Manoj'" ; "Vinay Vernekar" ; "Manoj Agiwal" ; "'Ccamp (E-mail)" ; ; "mpls@UU. NET (E-mail)" Sent: Wednesday, May 08, 2002 10:42 PM Subject: RE: Label Set Object > Lou and I just reviewed section 5.1.1 of > draft-ietf-mpls-generalized-rsvp-te-07.txt (rather than > draft-ietf-mpls-generalized-signaling-08.txt, which is what I looked at this > morning), and it's pretty clear. > > The upstream node processing the ERO for the outgoing link checks whether > there are explicit label control subobjects for upstream or downstream. An > explicit label control for upstream is replaced in the ERO with an upstream > label and an explicit label control for downstream is replaced with a label > set with the same label. This is so done so that there is only one > mechanism for an upstream node to specify the downstream label; explicit > label control is only used by a remote node. > > So the only question is whether for SONET/SDH LSPs, this mechanism is > required. > From owner-mpls@UU.NET Thu May 9 16:12:30 2002 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 QAA07126 for ; Thu, 9 May 2002 16:12:29 -0400 (EDT) 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 QQmocs00963; Thu, 9 May 2002 15:40:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQmocs00828 for mpls-outgoing; Thu, 9 May 2002 15:39: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 QQmocs00823 for ; Thu, 9 May 2002 15:39:42 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 QQmocs06533 for ; Thu, 9 May 2002 15:38:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmocs25008 for ; Thu, 9 May 2002 15:38:02 GMT 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 LAA07626 for ; Thu, 9 May 2002 11:38:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA11563 for mpls@uu.net; Thu, 9 May 2002 11:38:02 -0400 (EDT) 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 QQmocs00730 for ; Thu, 9 May 2002 15:37:07 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 QQmocs25083 for ; Thu, 9 May 2002 15:36:32 GMT Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmocs25888 for ; Thu, 9 May 2002 15:36:31 GMT Received: (qmail 29438 invoked by uid 104); 9 May 2002 15:36:30 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4202. . Clean. Processed in 0.418498 secs); 09 May 2002 15:36:30 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 9 May 2002 15:36:30 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g49FaRp02968 for ; Thu, 9 May 2002 08:36:27 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 08:36:30 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A7B8@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'mpls@UU.net'" Subject: LSR MIB question Date: Thu, 9 May 2002 08:36:28 -0700 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, What is the definition of error in "mplsInSegmentErrors" ? Yours, Shahram Davari Senior Product Research Engineer R&D Research Ottawa PMC-Sierra, Inc. Phone: (613) 271-4018 Fax: (613) 271-6468 From owner-mpls@UU.NET Thu May 9 16:51:39 2002 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 QAA08512 for ; Thu, 9 May 2002 16:51:39 -0400 (EDT) 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 QQmodn12046; Thu, 9 May 2002 20:51:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQmodn16260 for mpls-outgoing; Thu, 9 May 2002 20:51: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 QQmodn16253 for ; Thu, 9 May 2002 20:51:30 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 QQmodn29067 for ; Thu, 9 May 2002 20:51:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmodn14502 for ; Thu, 9 May 2002 20:51:02 GMT 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 QAA00533 for ; Thu, 9 May 2002 16:51:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA16368 for mpls@uu.net; Thu, 9 May 2002 16:51:02 -0400 (EDT) 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 QQmodn16096 for ; Thu, 9 May 2002 20:49:46 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 QQmodn23011 for ; Thu, 9 May 2002 20:48:28 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQmodn07462 for ; Thu, 9 May 2002 20:48:27 GMT Received: from toque.cisco.com (IDENT:mirapoint@toque.cisco.com [161.44.201.11]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g49KiVkc010506; Thu, 9 May 2002 13:44:31 -0700 (PDT) Received: from ANCAZ-W2K.cisco.com (che-vpn2-8.cisco.com [10.86.244.8]) by toque.cisco.com (Mirapoint) with ESMTP id AAP57709; Thu, 9 May 2002 16:40:15 -0400 (EDT) Message-Id: <4.3.2.7.2.20020509161752.01d0a488@toque.cisco.com> X-Sender: ancaz@toque.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 May 2002 16:44:28 -0400 To: "Adrian Farrel" From: Anca Zamfir Subject: Re: Label Set Object Cc: "John Drake" , "Zafar Ali" , "'Juneja, Manoj'" , "Vinay Vernekar" , "Manoj Agiwal" , "'Ccamp \(E-mail\)" , , "mpls@UU. NET \(E-mail\)" In-Reply-To: <046601c1f793$34a7a620$2200120a@movaz.com> References: <9D42C6E086250248810DCADA39CE7EFC59F6A2@nimbus> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 03:53 PM 5/9/2002 -0400, Adrian Farrel wrote: >Suppose (just suppose) that I want a unidirectional sonet LSP and that I >want to >constrain the label choice to a specific value. Note that this is >distinct from >the question of what labels to use in each direction for bidirectional. >It is clear how I signal it. No issues. Label Request, Label Set with one >member... You can also allow the downstream node to pick one (maybe complex) label from a set with more than one member by including multiple labels in the Label Set. >Now suppose I also want a bidirectional sonet LSP. >How do I indicate that it is bidirectional? >I believe the only method is to include an Upstream Label. Correct. >Could we say that bidirectional uses Upstream Label only, and unidirectional >uses Label Set only? >Yes. This is probably true for SONET LSPs. For other types this restriction may be undesirable. >Would that be a good idea? >I don't see think that having multiple choices of presence of objects is >useful. IMO, assuming most GMPLS implementations are meant to cover more than one type of LSP domain, for the reason of maximizing the code re-use, it would be nice to have as few domain specific restrictions as possible. >Could an implementation choose to ignore one of the objects and act only >on the >other? >Of course. > >Adrian > >----- Original Message ----- >From: "John Drake" >To: "'Anca Zamfir'" ; "Zafar Ali" >Cc: "'Juneja, Manoj'" ; "Vinay Vernekar" >; "Manoj Agiwal" ; "'Ccamp >(E-mail)" ; ; "mpls@UU. NET (E-mail)" > >Sent: Wednesday, May 08, 2002 10:42 PM >Subject: RE: Label Set Object > > > > Lou and I just reviewed section 5.1.1 of > > draft-ietf-mpls-generalized-rsvp-te-07.txt (rather than > > draft-ietf-mpls-generalized-signaling-08.txt, which is what I looked at > this > > morning), and it's pretty clear. > > > > The upstream node processing the ERO for the outgoing link checks whether > > there are explicit label control subobjects for upstream or downstream. An > > explicit label control for upstream is replaced in the ERO with an upstream > > label and an explicit label control for downstream is replaced with a label > > set with the same label. This is so done so that there is only one > > mechanism for an upstream node to specify the downstream label; explicit > > label control is only used by a remote node. > > > > So the only question is whether for SONET/SDH LSPs, this mechanism is > > required. > > From owner-mpls@UU.NET Thu May 9 22:53:15 2002 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 WAA23299 for ; Thu, 9 May 2002 22:53:15 -0400 (EDT) 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 QQmoel28487; Fri, 10 May 2002 02:53:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoel26097 for mpls-outgoing; Fri, 10 May 2002 02: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 QQmoel26092 for ; Fri, 10 May 2002 02:53: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 QQmoel05666 for ; Fri, 10 May 2002 02:52:52 GMT Received: from indica.wipsys.stph.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.249.146]) id QQmoel15420 for ; Fri, 10 May 2002 02:52:51 GMT Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.11.6/8.11.6) with SMTP id g4A2pa712148 for ; Fri, 10 May 2002 08:21:36 +0530 (IST) Received: from madpol105151 ([192.168.143.46]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GVVJZW00.PEK; Fri, 10 May 2002 08:22:44 +0530 Reply-To: From: "Ravi, Attili" To: Cc: "Ravi Attili" Subject: LSP setup doubt... Date: Fri, 10 May 2002 08:25:46 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-d83d0564-634a-11d6-84a6-0000e2293f7c" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPartTM-000-d83d0564-634a-11d6-84a6-0000e2293f7c Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Please send some time in answering the following questions. What are all the different configuration/limitation parameters that PEP need to send to PDP as a part of its initial configuration request as far as MPLS is concerned. Is any PIB is talking about this. Please throw some light on this. Thanks in advance Ravi ------=_NextPartTM-000-d83d0564-634a-11d6-84a6-0000e2293f7c Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ***************************************************************************** ------=_NextPartTM-000-d83d0564-634a-11d6-84a6-0000e2293f7c-- From owner-mpls@UU.NET Fri May 10 02:19:31 2002 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 CAA08529 for ; Fri, 10 May 2002 02:19:31 -0400 (EDT) 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 QQmoez29025; Fri, 10 May 2002 06:19:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoez09502 for mpls-outgoing; Fri, 10 May 2002 06:19:16 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 QQmoez09491 for ; Fri, 10 May 2002 06:19:14 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 QQmoez21777 for ; Fri, 10 May 2002 06:15:07 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmoez19313 for ; Fri, 10 May 2002 06:15:03 GMT 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 CAA25634 for ; Fri, 10 May 2002 02:15:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id CAA10420 for mpls@uu.net; Fri, 10 May 2002 02:15:02 -0400 (EDT) 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 QQmoey08905 for ; Fri, 10 May 2002 06:14: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 QQmoey12941 for ; Fri, 10 May 2002 06:13:16 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmoey18028 for ; Fri, 10 May 2002 06:13:15 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 11:54:17 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06099FD9@HARITHA> From: "Vijayanand C - CTD, Chennai." To: David Charlap Cc: mpls@UU.NET Subject: RE: Ptear Date: Fri, 10 May 2002 11:45:03 +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 want to know if there is any specification for graceful restart for RSVP like the one existing for LDP . If not, is any work going on in this area ? Regards, Vijay -----Original Message----- From: David Charlap [mailto:David.Charlap@marconi.com] Sent: Thursday, May 09, 2002 12:58 AM To: Gopalkrishna Panicker Cc: mpls@UU.NET Subject: Re: Ptear Gopalkrishna Panicker wrote: > > I am trying to understand how PathTear works. > > PathTears can originate at any (ingress or transit) node. They should only originate at transit nodes if there is a link failure on the upstream side of that transit node. > These messages travel downstream towards the receivers (egress > routers). Correct. They should follow the same route as the corresponding Path message - using the stored ERO, if applicable. > Every node in this downstream path deletes its path state and in > some cases deletes the resv state. In all cases, the Resv state is deleted. It is meaningless to have an RSVP reservation that does not correspond to any existing Path state. > What happens to the path states upstream to the originator of the > Path Tear ? How are they aged out ? The only time there will be any Path state upstream of the source of the tear will be if the link to the upstream node has failed. The other side of that link failure will generate ResvTear and PathError messages which will flow towards the ingress node. If the ingress node so chooses, it can generate a PathTear in response to the PathError message. If it chooses not to, then the Path state will remain inplace. When the down link comes back up, the router on the upstream side of that link will send a Path message out, and the LSP will be reestablished. > Another related question, Is there a concept of graceful shutdown > in RSVP? For example if RSVP is disabled in a transit router what > should the router do ? I guess this is implementation dependent. I don't know of a specification for this. If the protocol simply stops sending/receiving RSVP messages, the neighbors will detect this and will enerate PathTear, ResvTear and PathErr messages, as appropriate. If Hellos are being exchanged with the neighbor, this will happen within a few seconds. If not, it may take a few minutes - as the soft-states for the different sessions time out individually. If the protocol wants to shut down more gracefully, it may send out PathTead, ResvTear and PathErr messages before shutting down. But due to the soft-state nature of RSVP, messages to establish new state may arrive while this is happening. So the protocol would have to be able to reject new requests while it's sending out the error/tear messaes for the existing state. Overall, the effect is pretty much the same as the abrupt shutdown. Note that this will be different in a GMPLS scenario, where there is a right and a wrong way to tear an LSP. Tearing one the wrong way can set off loss-of-carrier alarms in an optical network. -- David From owner-mpls@UU.NET Fri May 10 04:24:38 2002 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 EAA10620 for ; Fri, 10 May 2002 04:24:38 -0400 (EDT) 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 QQmofh27317; Fri, 10 May 2002 08:24:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmofh02889 for mpls-outgoing; Fri, 10 May 2002 08:24:27 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 QQmofh02884 for ; Fri, 10 May 2002 08:24:24 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 QQmofh20668 for ; Fri, 10 May 2002 08:24:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmofh25748 for ; Fri, 10 May 2002 08:24:02 GMT 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 EAA28680 for ; Fri, 10 May 2002 04:24:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id EAA23445 for mpls@uu.net; Fri, 10 May 2002 04:24:02 -0400 (EDT) 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 QQmofh02847 for ; Fri, 10 May 2002 08:22:58 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 QQmofh16401 for ; Fri, 10 May 2002 08:22:47 GMT Received: from cvis28.marconicomms.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cvis28.marconicomms.com [195.99.244.60]) id QQmofh27172 for ; Fri, 10 May 2002 08:22:47 GMT Received: from cvis05.marconicomms.com (unverified) by cvis28.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 10 May 2002 09:22:45 +0100 Received: from cvdgwy01.uk.marconicomms.com by cvis05.marconicomms.com with ESMTP (8.10.2+Sun/cvms-35) id g4A8Mgq02956; Fri, 10 May 2002 09:22:42 +0100 (BST) Subject: Re: Label Set Object To: "Anca Zamfir Cc: ""Adrian Farrel" , ""John Drake" , ""Zafar Ali" , ""'Juneja@marconi.com, "Manoj'\" , ""Vinay Vernekar" , ""Manoj Agiwal" , "\"\"'Ccamp \(E-mail\)\" , ", ""mpls" "@marconi.com From: "Diego Caviglia" Date: Fri, 10 May 2002 10:21:35 +0200 Message-ID: X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(Release 5.0.8 |June 18, 2001) at 10/05/2002 09:22:35 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Anca, comment in line. Regards, Diego. ---------------------------------------------------------------- Diego Caviglia Optical Network - ASON strategy E-mail: diego.caviglia@marconi.com Tel: +39 0 10 6003 808 Via A. Negrone 1A 16153 Genoa (Italy) http://www.marconi.com Anca Zamfir @ops.ietf.org on 09/05/2002 22.44.28 Sent by: owner-ccamp@ops.ietf.org To: "Adrian Farrel" cc: "John Drake" , "Zafar Ali" , "'Juneja, Manoj'" , "Vinay Vernekar" , "Manoj Agiwal" , "'Ccamp \(E-mail\)" , , "mpls@UU. NET \(E-mail\)" Subject: Re: Label Set Object [CUT] >Could we say that bidirectional uses Upstream Label only, and unidirectional >uses Label Set only? >Yes. This is probably true for SONET LSPs. For other types this restriction may be undesirable. [dc] I'd like to add a comment on the use of Label Set and Upstream Label in case of bidirectional SDH circuit. In bidirectional SDH LSP, both the Upstream and the Downstream label must be the same. Therefore request message must contain an Upstream Label (with say value A) and a Label Set with the single value A to express the specific SDH restriction. [CUT] From owner-mpls@UU.NET Fri May 10 08:29:49 2002 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 IAA17839 for ; Fri, 10 May 2002 08:29:49 -0400 (EDT) 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 QQmofx07917; Fri, 10 May 2002 12:29:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQmofx19695 for mpls-outgoing; Fri, 10 May 2002 12:29: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 QQmofx19686 for ; Fri, 10 May 2002 12:29:33 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 QQmofx09964 for ; Fri, 10 May 2002 12:28:30 GMT Received: from indica.wipsys.stph.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.249.146]) id QQmofx19321 for ; Fri, 10 May 2002 12:28:29 GMT Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.11.6/8.11.6) with SMTP id g4ACRC706263 for ; Fri, 10 May 2002 17:57:12 +0530 (IST) Received: from madpol105151 ([192.168.143.46]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GVWAN800.ITH; Fri, 10 May 2002 17:58:20 +0530 Reply-To: From: "Ravi, Attili" To: "Kireeti Kompella" , "Don Fedyk" , Cc: , "CCAMP" , , "Ravi Attili" Subject: Policy based management for MPLS Date: Fri, 10 May 2002 18:01:23 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-2462bd1a-63fa-11d6-84a6-0000e2293f7c" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20020508231129.C61949-100000@kummer.juniper.net> Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPartTM-000-2462bd1a-63fa-11d6-84a6-0000e2293f7c Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have one query. Assume the case where we have policy based management system that manages the complete network that supports MPLS . my question is, when LER (PEP) sends a request to PDP for LSP setup what are all the different type of capabilities/limitations that LER (PEP) needs to send to PDP. Is there any PIB which is having this information. If there is no PIB, how to send this information to PDP ? Could any body throw light on it ? Thanks in advance Ravi ------=_NextPartTM-000-2462bd1a-63fa-11d6-84a6-0000e2293f7c Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ***************************************************************************** ------=_NextPartTM-000-2462bd1a-63fa-11d6-84a6-0000e2293f7c-- From owner-mpls@UU.NET Fri May 10 08:41:54 2002 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 IAA18586 for ; Fri, 10 May 2002 08:41:53 -0400 (EDT) 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 QQmofy24537; Fri, 10 May 2002 12:42:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmofy20560 for mpls-outgoing; Fri, 10 May 2002 12:41: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 QQmofy20554 for ; Fri, 10 May 2002 12:41:23 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 QQmofy19932 for ; Fri, 10 May 2002 12:41:21 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f52.law15.hotmail.com [64.4.23.52]) id QQmofy03024 for ; Fri, 10 May 2002 12:41:20 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 10 May 2002 05:41:20 -0700 Received: from 155.245.254.253 by lw15fd.law15.hotmail.msn.com with HTTP; Fri, 10 May 2002 12:41:19 GMT X-Originating-IP: [155.245.254.253] From: "Christopher Poh" To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Any Routers? Date: Fri, 10 May 2002 12:41:19 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 May 2002 12:41:20.0121 (UTC) FILETIME=[FC278E90:01C1F81F] Sender: owner-mpls@UU.NET Precedence: bulk Hi, Do Cisco's product lines support tunnel establishment through implicit peering? Thank you. -Chris _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From owner-mpls@UU.NET Fri May 10 09:01:58 2002 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 JAA19775 for ; Fri, 10 May 2002 09:01:58 -0400 (EDT) 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 QQmoga00514; Fri, 10 May 2002 13:02:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoga29356 for mpls-outgoing; Fri, 10 May 2002 13: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 QQmoga29134 for ; Fri, 10 May 2002 13:01:32 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 QQmoga24957 for ; Fri, 10 May 2002 13:01:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmoga07206 for ; Fri, 10 May 2002 13:01:03 GMT 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 JAA06214 for ; Fri, 10 May 2002 09:01:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA20764 for mpls@uu.net; Fri, 10 May 2002 09:01:03 -0400 (EDT) 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 QQmoga24573 for ; Fri, 10 May 2002 13:00:17 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 QQmofz13254 for ; Fri, 10 May 2002 12:59:47 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQmofz05181 for ; Fri, 10 May 2002 12:59:47 GMT Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA22354; Fri, 10 May 2002 08:59:37 -0400 (EDT) Date: Fri, 10 May 2002 08:59:37 -0400 (EDT) From: Ajay Simha To: Christopher Poh cc: mpls-ops@mplsrc.com Subject: Re: Any Routers? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 10 May 2002, Christopher Poh wrote: >CP:Hi, >CP: >CP:Do Cisco's product lines support tunnel establishment through implicit >CP:peering? Removing mpls@uu.net Replying on mpls-ops@mplsrc.com... -ajay >CP: >CP:Thank you. >CP: >CP:-Chris >CP: >CP:_________________________________________________________________ >CP:Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. >CP: -- From owner-mpls@UU.NET Fri May 10 10:40:22 2002 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 KAA25827 for ; Fri, 10 May 2002 10:40:22 -0400 (EDT) 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 QQmogg23852; Fri, 10 May 2002 14:40:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQmogg14374 for mpls-outgoing; Fri, 10 May 2002 14:39: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 QQmogg14361 for ; Fri, 10 May 2002 14:39: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 QQmogg01530 for ; Fri, 10 May 2002 14:39:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmogg23032 for ; Fri, 10 May 2002 14:39:02 GMT 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 KAA13201 for ; Fri, 10 May 2002 10:39:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA00922 for mpls@uu.net; Fri, 10 May 2002 10:39:02 -0400 (EDT) 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 QQmogg14302 for ; Fri, 10 May 2002 14:38:13 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 QQmogg06027 for ; Fri, 10 May 2002 14:38:05 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.10]) id QQmogg19430 for ; Fri, 10 May 2002 14:38:04 GMT Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4AEbs5M009817; Fri, 10 May 2002 07:37:55 -0700 (PDT) Received: from CHMETZ-W2K2.cisco.com (rtp-vpn1-30.cisco.com [10.82.224.30]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA16700; Fri, 10 May 2002 07:37:51 -0700 (PDT) Message-Id: <4.3.2.7.2.20020510103236.01f67438@mail1.cisco.com> X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 May 2002 10:37:50 -0400 To: "Vijayanand C - CTD, Chennai." From: Chris Metz Subject: RE: Ptear Cc: David Charlap , mpls@UU.NET In-Reply-To: <55E277B99171E041ABF5F4B1C6DDCA06099FD9@HARITHA> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi- I recall a graceful restart RSVP-TE draft but it looks like it expired. The defined mechanisms now appear in the GMPLS RSVP-TE signaling draft: http://ietf.org/internet-drafts/draft-ietf-mpls-generalized-rsvp-te-07.txt Thanks ... At 11:45 AM 5/10/2002 +0530, Vijayanand C - CTD, Chennai. wrote: >Hello, >I want to know if there is any specification for graceful restart for RSVP >like the one existing for LDP . If not, is any work going on in this area ? > >Regards, >Vijay > >-----Original Message----- >From: David Charlap [mailto:David.Charlap@marconi.com] >Sent: Thursday, May 09, 2002 12:58 AM >To: Gopalkrishna Panicker >Cc: mpls@UU.NET >Subject: Re: Ptear > > >Gopalkrishna Panicker wrote: > > > > I am trying to understand how PathTear works. > > > > PathTears can originate at any (ingress or transit) node. > >They should only originate at transit nodes if there is a link failure >on the upstream side of that transit node. > > > These messages travel downstream towards the receivers (egress > > routers). > >Correct. They should follow the same route as the corresponding Path >message - using the stored ERO, if applicable. > > > Every node in this downstream path deletes its path state and in > > some cases deletes the resv state. > >In all cases, the Resv state is deleted. It is meaningless to have an >RSVP reservation that does not correspond to any existing Path state. > > > What happens to the path states upstream to the originator of the > > Path Tear ? How are they aged out ? > >The only time there will be any Path state upstream of the source of the >tear will be if the link to the upstream node has failed. > >The other side of that link failure will generate ResvTear and PathError >messages which will flow towards the ingress node. If the ingress node >so chooses, it can generate a PathTear in response to the PathError >message. > >If it chooses not to, then the Path state will remain inplace. When the >down link comes back up, the router on the upstream side of that link >will send a Path message out, and the LSP will be reestablished. > > > Another related question, Is there a concept of graceful shutdown > > in RSVP? For example if RSVP is disabled in a transit router what > > should the router do ? I guess this is implementation dependent. > >I don't know of a specification for this. > >If the protocol simply stops sending/receiving RSVP messages, the >neighbors will detect this and will enerate PathTear, ResvTear and >PathErr messages, as appropriate. If Hellos are being exchanged with >the neighbor, this will happen within a few seconds. If not, it may >take a few minutes - as the soft-states for the different sessions time >out individually. > >If the protocol wants to shut down more gracefully, it may send out >PathTead, ResvTear and PathErr messages before shutting down. But due >to the soft-state nature of RSVP, messages to establish new state may >arrive while this is happening. So the protocol would have to be able >to reject new requests while it's sending out the error/tear messaes for >the existing state. Overall, the effect is pretty much the same as the >abrupt shutdown. > >Note that this will be different in a GMPLS scenario, where there is a >right and a wrong way to tear an LSP. Tearing one the wrong way can set >off loss-of-carrier alarms in an optical network. > >-- David From owner-mpls@UU.NET Sun May 12 09:12:35 2002 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 JAA15358 for ; Sun, 12 May 2002 09:12:31 -0400 (EDT) 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 QQmonk10686; Sun, 12 May 2002 13:12:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmonk28873 for mpls-outgoing; Sun, 12 May 2002 13:12:17 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 QQmonk28868 for ; Sun, 12 May 2002 13:12:14 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 QQmonk13984 for ; Sun, 12 May 2002 13:11:24 GMT Received: from 21cn.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [202.104.32.249]) id QQmonk11137 for ; Sun, 12 May 2002 13:11:23 GMT Received: from 21cn.com([10.2.1.3]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm1b3cdea08f; Sun, 12 May 2002 21:07:32 +0800 Received: from cmr0.ash.ops.us.uu.net([198.5.241.38]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm63cd9ce93; Thr, 09 May 2002 03:08:28 +0800 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 QQmnzo10977; Wed, 8 May 2002 19:10:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQmnzo03460 for mpls-outgoing; Wed, 8 May 2002 19:09:36 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 QQmnzo03452 for ; Wed, 8 May 2002 19:09:34 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 QQmnzo24243 for ; Wed, 8 May 2002 19:09:30 GMT Received: from mail.san.yahoo.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.san.yahoo.com [209.132.1.30]) id QQmnzo19389 for ; Wed, 8 May 2002 19:09:29 GMT Received: from [65.213.193.52] by mail.san.yahoo.com with HTTP; Wed, 8 May 2002 12:10:07 -0700 Date: Wed, 8 May 2002 15:10:07 -0400 Message-ID: <3CBB5DA900017F08@mta08.san.yahoo.com> From: "Kavita Khanna" Subject: MPLS 2002: topics for presentations To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA15358 The MPLS 2002 International Conference, in addition to the presentations from invited speakers, will also incorporate selected talks from open submitted proposals. The Program Committee cordially invites you to submit proposals for original unpublished presentations. The summaries not exceeding 500 words in the following and related topics may be submitted to TPC@MPLS2002.com for review and possible inclusion in the program, no later than June 7, 2002: - Advances in MPLS and IP Traffic Engineering - Layer 2 Provider Provisioned VPNs - Layer 3 Provider Provisioned VPNs - Service Provider Offerings of New MPLS and IP Based Services - Pseudo-Wire Edge-to-Edge Emulation (PWE3) - Vendor Implementations of Multiservice MPLS and/or IP Based Nodes - Implications and Tradeoffs in MPLS versus IP Tunnneling - Applications of Generalized MPLS - IP over Optical Networking MPLS 2002, the 5th annual International Conference on Multi Protocol Label Switching will take place October 27-29, 2002 at the Omni Shoreham Hotel, Washington, D.C. The event is Co-Hosted by WorldCom and Isocore and Supported by NTT, France Telecom and Cable & Wireless. The 3rd Public Interoperability Demonstration will follow on October 30, 2002. Additional information can be found at: www.mpls2002.com From owner-mpls@UU.NET Sun May 12 19:19:22 2002 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 TAA03678 for ; Sun, 12 May 2002 19:19:22 -0400 (EDT) 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 QQmooz23706; Sun, 12 May 2002 23:19:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQmooz24357 for mpls-outgoing; Sun, 12 May 2002 23:19: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 QQmooz24352 for ; Sun, 12 May 2002 23:19:07 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 QQmooz08625 for ; Sun, 12 May 2002 23:18:25 GMT Received: from 21cn.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: [61.140.60.248]) id QQmooz10944 for ; Sun, 12 May 2002 23:18:24 GMT Received: from 21cn.com([10.2.1.4]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm133cdefaeb; Mon, 13 May 2002 07:26:13 +0800 Received: from cmr0.ash.ops.us.uu.net([198.5.241.38]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jmc93cda3528; Thr, 09 May 2002 13:14:22 +0800 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 QQmobd16567; Thu, 9 May 2002 05:15:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQmobc02755 for mpls-outgoing; Thu, 9 May 2002 05: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 QQmobc02750 for ; Thu, 9 May 2002 05:14: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 QQmobc07183 for ; Thu, 9 May 2002 05:13:56 GMT Received: from samar.sasken.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQmobc14580 for ; Thu, 9 May 2002 05:13:49 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g495DVU09644; Thu, 9 May 2002 10:43:31 +0530 (IST) Received: from sushanth (pcsva235.sasken.com [10.1.65.235]) by sunsv2.sasken.com (8.11.6/8.11.6) with SMTP id g495DQB22892; Thu, 9 May 2002 10:43:26 +0530 (IST) From: "sushantm" To: "John Drake" Cc: "Manoj Agiwal" , "'Ccamp \(E-mail\)" , "mpls@UU. NET \(E-mail\)" , "'Suresh Katukam'" , "Zafar Ali" Subject: RE: Label Set Object Date: Thu, 9 May 2002 10:45:11 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <9D42C6E086250248810DCADA39CE7EFC59F69F@nimbus> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: High Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi John , I agree to the first case but in the second case, suppose the ERO is not used , why would we have to restrict the Label set to only one label value ? -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of John Drake Sent: Thursday, May 09, 2002 7:08 AM To: 'Suresh Katukam'; Zafar Ali Cc: Manoj Agiwal; Manoj Agiwal; 'Ccamp (E-mail); mpls@UU. NET (E-mail) Subject: RE: Label Set Object Is it the case that ALL current SONET/SDH equipment has the restriction that the labels (timeslots) must be the same in both directions? If this is the case, then it's really simple; for an SONET/SDH LSP, only the upstream label needs to be specified, and the downstream label MUST be the same. One the other hand, if not all current SONET/SDH equipment has this restriction or the current SONET/SDH standards allow the labels (timeslots) to be different in each direction, then label set with one value or explicit label control would be useful for equipment that does have this restriction. -----Original Message----- From: Suresh Katukam [mailto:skatukam@cisco.com] Sent: Wednesday, May 08, 2002 3:23 PM To: Zafar Ali Cc: Manoj Agiwal; Manoj Agiwal; 'Ccamp (E-mail); mpls@UU. NET (E-mail) Subject: RE: Label Set Object For TDM, since you have to use same labels in both directions, why do you have to specify anything at all? How can a downstream TDM node pick a label that does not match with Upstream label for a bidirectional LSP? If it picks any other label, LSP is not functional. If there are Uni-directional LSPs in TDM and if you have different types of time slots available in both directions, then one may be able to setup bidirectional LSP on different links or different labels. This is in theory and not in practice. So in practice, one does not need to specify LABEL SET or Suggested label for TDM links. Thanks, Suresh At 01:53 AM 5/8/2002 -0400, Zafar Ali wrote: >At 11:11 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>Hi , >> I guess in that case we can use Suggested Label , Label Set still can >> still be avoided . > >Hi Manoj, > >No, the use of suggested label in this case would NOT be correct, as the >suggested labels can be ignored/ overridden by the receiving node. > >Thanks > >Regards... Zafar > >>Regards , >>Manoj >>-----Original Message----- >>From: Zafar Ali [mailto:zali@cisco.com] >>Sent: Wednesday, May 08, 2002 11:05 AM >>To: Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: Re: Label Set Object >> >>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>>Hi , >>> In gmpls signaling extensionsions for RSVP-TE , ccamp >>> architecture on >>>gmpls has described Label Set object usage >>> only for the "optical" domain viz. for carrying wavelengths ( Section >>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . >>> >>> Do we require to send Label set(i.e. time slots) for TDM >>> switching as >>>well . In what way it can be useful . >>Dear Manoj, >> >>Yes, label set object is also useful in TDM case. E.g., SONET poses an >>additional requirement that the two interfaces of a bidirectional LSP >>SHOULD traverse the exact same link with the same SUKLM values for the >>two directions. >> The label set object can be used to constrain the downstream label to >> the same as the upstream label. >> >>Thanks >> >>Regards... Zafar >> >> >> >> >> >> >> >> >> >>>Regards , >>>Manoj >>=============== >>Zafar Ali >>Cisco Systems >>(734) 276-2459 >>100 S Main St. #200 >>Ann Arbor, MI 48104. >>email: zali@cisco.com > >=============== >Zafar Ali >Cisco Systems >(734) 276-2459 >100 S Main St. #200 >Ann Arbor, MI 48104. >email: zali@cisco.com From owner-mpls@UU.NET Mon May 13 02:38:49 2002 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 CAA28729 for ; Mon, 13 May 2002 02:38:49 -0400 (EDT) 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 QQmoqc01465; Mon, 13 May 2002 06:38:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoqc01284 for mpls-outgoing; Mon, 13 May 2002 06:38: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 QQmoqc01279 for ; Mon, 13 May 2002 06:38:28 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 QQmoqc23572 for ; Mon, 13 May 2002 06:37:29 GMT From: sven.van_den_bosch@alcatel.be Received: from bt0g2p.god.bel.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc250.alcatel.be [195.207.101.250]) id QQmoqc29364 for ; Mon, 13 May 2002 06:37:29 GMT Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id g4D6Yv717436; Mon, 13 May 2002 08:34:57 +0200 Subject: Re: How many can administrative groups assigned? To: Curtis Villamizar Cc: "Naidu, Venkata" , "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org, Dimitri.Papadimitriou@alcatel.be X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 13 May 2002 08:36:54 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 05/13/2002 08:36:57 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Curtis, I agree with you that the current interpretation is clear. It brings, however, some difficulties regarding Forwarding Adjacency (FA) LSPs. Suppose you have an LSP that includes gold as a resource class. It goes through links A-B (gold), B-C (gold, north) and C-D (gold, south). Imho, the current FA specification would make this a non-coloured FA-link, or alternatively, it could be coloured gold. In both cases, depending on the interpretation of uncoloured links, it could be used for an LSP that specifies e.g. exclude north, which is not what you want. This problem is due to the bitmask operation. We feel that at least one more TLV would be needed (speciying the OR operation on the bit-mask for the FA-LSP). We will document this in the next version of draft-vandenbosch-mpls-fa-considerations-00.txt. Sven. Curtis Villamizar on 08/05/2002 20:22:11 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: "Naidu, Venkata" , "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org Subject Re: How many can administrative groups : assigned? [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] In message , sven.van_d en_bosch@alcatel.be writes: > Naidu, Kim, > > I think it depends a little bit on the interpretation. In principle the > resource classes can be interpreted either as a bit mask (in which case 32 > 'base' classes can be defined) or as an integer value (in which case 2^32 > values can be used). Even with the bit mask interpretation, derived > resource classes can be built by combining multiple non-mutually exclusive > 'base' classes (you could have 32 generic classes called 1, 2, 3 and so on > and then build your resource classes on top of those). The problem lies of > course in the processing of the resource class information. If they are not > used in a simple bitmask, an AND operation is not sufficient to determine > the resource class of a link. Also, if a link would have multiple derived > classes, different TLVs would be needed. It would make sense to expand a > little bit on these issues in the appropriate documents. In my opinion, > this is a general issue with the TE extensions, so it should be explained > there. > > Sven. The definitions are currently very clear. What you have described differs from the current definitions and therefore would not be a clarification to the use of admin class but a change in semantics. I do not know of anyone using more than a handful of admin class bits and many who do not use them at all. Lets not take any MPLS capability and make it any more complicated than it needs to be or introduce arbitrary change for no good reason. Curtis From owner-mpls@UU.NET Mon May 13 08:10:50 2002 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 IAA05622 for ; Mon, 13 May 2002 08:10:50 -0400 (EDT) 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 QQmoqy19229; Mon, 13 May 2002 12:11:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoqy06996 for mpls-outgoing; Mon, 13 May 2002 12:10: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 QQmoqy06781 for ; Mon, 13 May 2002 12:10:18 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 QQmoqy10135 for ; Mon, 13 May 2002 12:10:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmoqy17658 for ; Mon, 13 May 2002 12:10:02 GMT 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 IAA16565 for ; Mon, 13 May 2002 08:10:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA10472 for mpls@uu.net; Mon, 13 May 2002 08:10:02 -0400 (EDT) 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 QQmoqy06581 for ; Mon, 13 May 2002 12:09:12 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 QQmoqy07450 for ; Mon, 13 May 2002 12:08:20 GMT Received: from auemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail2.lucent.com [192.11.223.163]) id QQmoqy24600 for ; Mon, 13 May 2002 12:08:19 GMT Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4DC8HG26635 for ; Mon, 13 May 2002 08:08:17 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA17553; Mon, 13 May 2002 14:08:11 +0200 (MET DST) Cc: "'Suresh Katukam'" , Zafar Ali , Manoj Agiwal , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA17477; Mon, 13 May 2002 14:07:51 +0200 (MET DST) Message-ID: <3CDFAC96.A6252471@lucent.com> Date: Mon, 13 May 2002 14:07:50 +0200 From: Maarten Vissers Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: John Drake Original-CC: "'Suresh Katukam'" , Zafar Ali , Manoj Agiwal , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: Re: Label Set Object References: <9D42C6E086250248810DCADA39CE7EFC59F69F@nimbus> Content-Type: multipart/mixed; boundary="------------FCE08ED3BE10CF3BA1EB5722" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------FCE08ED3BE10CF3BA1EB5722 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, John Drake wrote: > > Is it the case that ALL current SONET/SDH equipment has the restriction that > the labels (timeslots) must be the same in both directions? Nobody can answer this question, while none of us has a complete overview of equipment in the field and under design :-). SDH/SONET (and OTN) networks are networks optimised for bi-directional connectivity. Uni-directional connections are supported as kind of "exception" on the generic bidirectional rule. SDH standards are assuming bidirectional connectivity. Sometimes a unidirectional connection causes the set up of a bidirectional connection of which only one direction is used (and alarming in the other direction is disabled). People are asking questions with respect to unidirectional connection support in SDH standards. The use of functional modelling method supports so far the specific unidirectional connection issues (e.g. no RDI/REI return) raised; but it is only at this point where you can show how a unidir connection would/should behave. > If this is the > case, then it's really simple; for an SONET/SDH LSP, only the upstream label > needs to be specified, and the downstream label MUST be the same. > > One the other hand, if not all current SONET/SDH equipment has this > restriction or the current SONET/SDH standards allow the labels (timeslots) SDH/SONET networks are build with the requirement that the timeslots in the two directions are the same. (Note - same requirement applies to ATM networks in which VPI/VCI for the two directions must be the same). Regards, Maarten > to be different in each direction, then label set with one value or explicit > label control would be useful for equipment that does have this restriction. > > -----Original Message----- > From: Suresh Katukam [mailto:skatukam@cisco.com] > Sent: Wednesday, May 08, 2002 3:23 PM > To: Zafar Ali > Cc: Manoj Agiwal; Manoj Agiwal; 'Ccamp (E-mail); mpls@UU. NET (E-mail) > Subject: RE: Label Set Object > > For TDM, since you have to use same labels in both directions, why do you > have to specify anything at all? > How can a downstream TDM node pick a label that does not match with > Upstream label for > a bidirectional LSP? If it picks any other label, LSP is not functional. > > If there are Uni-directional LSPs in TDM and if you have different types of > time slots available > in both directions, then one may be able to setup bidirectional LSP on > different links or > different labels. This is in theory and not in practice. > > So in practice, one does not need to specify LABEL SET or Suggested label > for TDM links. > > Thanks, > Suresh > > At 01:53 AM 5/8/2002 -0400, Zafar Ali wrote: > >At 11:11 AM 5/8/2002 +0530, Manoj Agiwal wrote: > >>Hi , > >> I guess in that case we can use Suggested Label , Label Set still can > >> still be avoided . > > > >Hi Manoj, > > > >No, the use of suggested label in this case would NOT be correct, as the > >suggested labels can be ignored/ overridden by the receiving node. > > > >Thanks > > > >Regards... Zafar > > > >>Regards , > >>Manoj > >>-----Original Message----- > >>From: Zafar Ali [mailto:zali@cisco.com] > >>Sent: Wednesday, May 08, 2002 11:05 AM > >>To: Manoj Agiwal; 'Ccamp (E-mail) > >>Cc: mpls@UU. NET (E-mail) > >>Subject: Re: Label Set Object > >> > >>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: > >>>Hi , > >>> In gmpls signaling extensionsions for RSVP-TE , ccamp > >>> architecture on > >>>gmpls has described Label Set object usage > >>> only for the "optical" domain viz. for carrying wavelengths ( > Section > >>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . > >>> > >>> Do we require to send Label set(i.e. time slots) for TDM > >>> switching as > >>>well . In what way it can be useful . > >>Dear Manoj, > >> > >>Yes, label set object is also useful in TDM case. E.g., SONET poses an > >>additional requirement that the two interfaces of a bidirectional LSP > >>SHOULD traverse the exact same link with the same SUKLM values for the > >>two directions. > >> The label set object can be used to constrain the downstream label to > >> the same as the upstream label. > >> > >>Thanks > >> > >>Regards... Zafar > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>>Regards , > >>>Manoj > >>=============== > >>Zafar Ali > >>Cisco Systems > >>(734) 276-2459 > >>100 S Main St. #200 > >>Ann Arbor, MI 48104. > >>email: zali@cisco.com > > > >=============== > >Zafar Ali > >Cisco Systems > >(734) 276-2459 > >100 S Main St. #200 > >Ann Arbor, MI 48104. > >email: zali@cisco.com --------------FCE08ED3BE10CF3BA1EB5722 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------FCE08ED3BE10CF3BA1EB5722-- From owner-mpls@UU.NET Mon May 13 09:44:29 2002 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 JAA09780 for ; Mon, 13 May 2002 09:44:29 -0400 (EDT) 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 QQmore01598; Mon, 13 May 2002 13:44:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQmore07087 for mpls-outgoing; Mon, 13 May 2002 13:44: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 QQmore07072 for ; Mon, 13 May 2002 13:44:15 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 QQmore27802 for ; Mon, 13 May 2002 13:43:47 GMT Received: from mail2.orchestream.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail2.orchestream.com [195.153.64.126]) id QQmore07805 for ; Mon, 13 May 2002 13:43:47 GMT Received: from mx2.mail.uk.psi.net (unverified) by mail2.orchestream.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Fri, 10 May 2002 16:12:47 +0100 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by mx2.mail.uk.psi.net with esmtp (Exim 2.12 #2) id 1769Y1-0001ns-00 for rmorgan@orchestream.com; Fri, 10 May 2002 13:30:57 +0100 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 QQmofy08433; Fri, 10 May 2002 12:30:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmofx19695 for mpls-outgoing; Fri, 10 May 2002 12:29: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 QQmofx19686 for ; Fri, 10 May 2002 12:29:33 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 QQmofx09964 for ; Fri, 10 May 2002 12:28:30 GMT Received: from indica.wipsys.stph.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.249.146]) id QQmofx19321 for ; Fri, 10 May 2002 12:28:29 GMT Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.11.6/8.11.6) with SMTP id g4ACRC706263 for ; Fri, 10 May 2002 17:57:12 +0530 (IST) Received: from madpol105151 ([192.168.143.46]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GVWAN800.ITH; Fri, 10 May 2002 17:58:20 +0530 Reply-To: From: "Ravi, Attili" To: "Kireeti Kompella" , "Don Fedyk" , Cc: , "CCAMP" , , "Ravi Attili" Subject: Policy based management for MPLS Date: Fri, 10 May 2002 18:01:23 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-2462bd1a-63fa-11d6-84a6-0000e2293f7c" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20020508231129.C61949-100000@kummer.juniper.net> Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPartTM-000-2462bd1a-63fa-11d6-84a6-0000e2293f7c Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have one query. Assume the case where we have policy based management system that manages the complete network that supports MPLS . my question is, when LER (PEP) sends a request to PDP for LSP setup what are all the different type of capabilities/limitations that LER (PEP) needs to send to PDP. Is there any PIB which is having this information. If there is no PIB, how to send this information to PDP ? Could any body throw light on it ? Thanks in advance Ravi ------=_NextPartTM-000-2462bd1a-63fa-11d6-84a6-0000e2293f7c Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ***************************************************************************** ------=_NextPartTM-000-2462bd1a-63fa-11d6-84a6-0000e2293f7c-- . From owner-mpls@UU.NET Mon May 13 09:45:29 2002 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 JAA09848 for ; Mon, 13 May 2002 09:45:28 -0400 (EDT) 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 QQmorf07043; Mon, 13 May 2002 13:45:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmorf07392 for mpls-outgoing; Mon, 13 May 2002 13:45: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 QQmorf07377 for ; Mon, 13 May 2002 13:45:14 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 QQmore21782 for ; Mon, 13 May 2002 13:43:47 GMT Received: from mail2.orchestream.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail2.orchestream.com [195.153.64.126]) id QQmore07795 for ; Mon, 13 May 2002 13:43:46 GMT Received: from mx2.mail.uk.psi.net (unverified) by mail2.orchestream.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Fri, 10 May 2002 16:12:41 +0100 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by mx2.mail.uk.psi.net with esmtp (Exim 2.12 #2) id 1769jK-0002N4-00 for mgibson@orchestream.com; Fri, 10 May 2002 13:42:38 +0100 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 QQmofy25190; Fri, 10 May 2002 12:42:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQmofy20560 for mpls-outgoing; Fri, 10 May 2002 12:41: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 QQmofy20554 for ; Fri, 10 May 2002 12:41:23 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 QQmofy19932 for ; Fri, 10 May 2002 12:41:21 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f52.law15.hotmail.com [64.4.23.52]) id QQmofy03024 for ; Fri, 10 May 2002 12:41:20 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 10 May 2002 05:41:20 -0700 Received: from 155.245.254.253 by lw15fd.law15.hotmail.msn.com with HTTP; Fri, 10 May 2002 12:41:19 GMT X-Originating-IP: [155.245.254.253] From: "Christopher Poh" To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Any Routers? Date: Fri, 10 May 2002 12:41:19 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 May 2002 12:41:20.0121 (UTC) FILETIME=[FC278E90:01C1F81F] Sender: owner-mpls@UU.NET Precedence: bulk Hi, Do Cisco's product lines support tunnel establishment through implicit peering? Thank you. -Chris _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. . From owner-mpls@UU.NET Mon May 13 09:45:33 2002 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 JAA09861 for ; Mon, 13 May 2002 09:45:33 -0400 (EDT) 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 QQmorf07243; Mon, 13 May 2002 13:45:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQmorf07405 for mpls-outgoing; Mon, 13 May 2002 13:45:21 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 QQmorf07378 for ; Mon, 13 May 2002 13:45: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 QQmore21727 for ; Mon, 13 May 2002 13:43:46 GMT Received: from mail2.orchestream.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail2.orchestream.com [195.153.64.126]) id QQmore07780 for ; Mon, 13 May 2002 13:43:45 GMT Received: from mx2.mail.uk.psi.net (unverified) by mail2.orchestream.com (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Fri, 10 May 2002 16:12:39 +0100 Received: from psg.com ([147.28.0.62]) by mx2.mail.uk.psi.net with esmtp (Exim 2.12 #2) id 1769vx-0002xY-00; Fri, 10 May 2002 13:55:41 +0100 Received: from lserv by psg.com with local (Exim 3.36 #1) id 1769Vh-000E6E-00 for te-wg-data@psg.com; Fri, 10 May 2002 05:28:33 -0700 Received: from [203.197.249.146] (helo=indica.wipsys.stph.net) by psg.com with esmtp (Exim 3.36 #1) id 1769Ve-000E61-00; Fri, 10 May 2002 05:28:30 -0700 Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.11.6/8.11.6) with SMTP id g4ACRC706262; Fri, 10 May 2002 17:57:12 +0530 (IST) Received: from madpol105151 ([192.168.143.46]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GVWAN800.ITH; Fri, 10 May 2002 17:58:20 +0530 Reply-To: From: "Ravi, Attili" To: "Kireeti Kompella" , "Don Fedyk" , Cc: , "CCAMP" , , "Ravi Attili" Subject: Policy based management for MPLS Date: Fri, 10 May 2002 18:01:23 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-2462bd17-63fa-11d6-84a6-0000e2293f7c" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20020508231129.C61949-100000@kummer.juniper.net> Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPartTM-000-2462bd17-63fa-11d6-84a6-0000e2293f7c Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have one query. Assume the case where we have policy based management system that manages the complete network that supports MPLS . my question is, when LER (PEP) sends a request to PDP for LSP setup what are all the different type of capabilities/limitations that LER (PEP) needs to send to PDP. Is there any PIB which is having this information. If there is no PIB, how to send this information to PDP ? Could any body throw light on it ? Thanks in advance Ravi ------=_NextPartTM-000-2462bd17-63fa-11d6-84a6-0000e2293f7c Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ***************************************************************************** ------=_NextPartTM-000-2462bd17-63fa-11d6-84a6-0000e2293f7c-- . From owner-mpls@UU.NET Mon May 13 14:35:50 2002 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 OAA25225 for ; Mon, 13 May 2002 14:35:45 -0400 (EDT) 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 QQmory29708; Mon, 13 May 2002 18:35:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQmory22590 for mpls-outgoing; Mon, 13 May 2002 18:35: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 QQmory22581 for ; Mon, 13 May 2002 18:35:06 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 QQmory10499 for ; Mon, 13 May 2002 18:35:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmory04962 for ; Mon, 13 May 2002 18:35:02 GMT 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 OAA14564 for ; Mon, 13 May 2002 14:35:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA21614 for mpls@uu.net; Mon, 13 May 2002 14:35:02 -0400 (EDT) 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 QQmory22481 for ; Mon, 13 May 2002 18:34:22 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 QQmory02818 for ; Mon, 13 May 2002 18:32:26 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQmory24904 for ; Mon, 13 May 2002 18:32:25 GMT Received: from mira1.cisco.com (IDENT:mirapoint@mira1.cisco.com [64.101.14.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4DIWJHs007342; Mon, 13 May 2002 11:32:19 -0700 (PDT) Received: from SKATUKAM-W2K2.cisco.com (data-pet-w2k.cisco.com [64.101.9.35]) by mira1.cisco.com (Mirapoint) with ESMTP id AAY31055; Mon, 13 May 2002 11:32:38 -0700 (PDT) Message-Id: <4.3.2.7.2.20020513112029.00bac008@mira1.cisco.com> X-Sender: skatukam@mira1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 May 2002 11:32:17 -0700 To: Maarten Vissers From: Suresh Katukam Subject: Re: Label Set Object Cc: "mpls@UU. NET (E-mail)" In-Reply-To: <3CDFAC96.A6252471@lucent.com> References: <9D42C6E086250248810DCADA39CE7EFC59F69F@nimbus> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >John Drake wrote: > > > > Is it the case that ALL current SONET/SDH equipment has the restriction > that > > the labels (timeslots) must be the same in both directions? > >Nobody can answer this question, while none of us has a complete overview of >equipment in the field and under design :-). Well said. >SDH/SONET (and OTN) networks are networks optimised for bi-directional >connectivity. Uni-directional connections are supported as kind of "exception" >on the generic bidirectional rule. SDH standards are assuming bidirectional >connectivity. >Sometimes a unidirectional connection causes the set up of a bidirectional >connection of which only one direction is used (and alarming in the other >direction is disabled). This is usually correct. A new term is being used in some emails called "pure Unidirectional" when the reverse direction of a unidirectional circuit can be used to setup another unidirectional circuit. >People are asking questions with respect to unidirectional connection >support in >SDH standards. The use of functional modelling method supports so far the >specific unidirectional connection issues (e.g. no RDI/REI return) raised; but >it is only at this point where you can show how a unidir connection >would/should >behave. this requires quite a bit of co-ordination between two end points in a pure unidirectional connections about informing alarms from drop to source etc. As you said, it is not yet known how to do this.. > > If this is the > > case, then it's really simple; for an SONET/SDH LSP, only the upstream > label > > needs to be specified, and the downstream label MUST be the same. > > > > One the other hand, if not all current SONET/SDH equipment has this > > restriction or the current SONET/SDH standards allow the labels (timeslots) > >SDH/SONET networks are build with the requirement that the timeslots in >the two >directions are the same. (Note - same requirement applies to ATM networks in >which VPI/VCI for the two directions must be the same). When you have pure unidirectional connections, it is possible to have different time slots in two directions. Again, this is a theory and a distant possibility. Thanks, Suresh >Regards, > >Maarten > > > to be different in each direction, then label set with one value or > explicit > > label control would be useful for equipment that does have this > restriction. > > > > -----Original Message----- > > From: Suresh Katukam [mailto:skatukam@cisco.com] > > Sent: Wednesday, May 08, 2002 3:23 PM > > To: Zafar Ali > > Cc: Manoj Agiwal; Manoj Agiwal; 'Ccamp (E-mail); mpls@UU. NET (E-mail) > > Subject: RE: Label Set Object > > > > For TDM, since you have to use same labels in both directions, why do you > > have to specify anything at all? > > How can a downstream TDM node pick a label that does not match with > > Upstream label for > > a bidirectional LSP? If it picks any other label, LSP is not functional. > > > > If there are Uni-directional LSPs in TDM and if you have different types of > > time slots available > > in both directions, then one may be able to setup bidirectional LSP on > > different links or > > different labels. This is in theory and not in practice. > > > > So in practice, one does not need to specify LABEL SET or Suggested label > > for TDM links. > > > > Thanks, > > Suresh > > > > At 01:53 AM 5/8/2002 -0400, Zafar Ali wrote: > > >At 11:11 AM 5/8/2002 +0530, Manoj Agiwal wrote: > > >>Hi , > > >> I guess in that case we can use Suggested Label , Label Set still can > > >> still be avoided . > > > > > >Hi Manoj, > > > > > >No, the use of suggested label in this case would NOT be correct, as the > > >suggested labels can be ignored/ overridden by the receiving node. > > > > > >Thanks > > > > > >Regards... Zafar > > > > > >>Regards , > > >>Manoj > > >>-----Original Message----- > > >>From: Zafar Ali [mailto:zali@cisco.com] > > >>Sent: Wednesday, May 08, 2002 11:05 AM > > >>To: Manoj Agiwal; 'Ccamp (E-mail) > > >>Cc: mpls@UU. NET (E-mail) > > >>Subject: Re: Label Set Object > > >> > > >>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: > > >>>Hi , > > >>> In gmpls signaling extensionsions for RSVP-TE , ccamp > > >>> architecture on > > >>>gmpls has described Label Set object usage > > >>> only for the "optical" domain viz. for carrying wavelengths ( > > Section > > >>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . > > >>> > > >>> Do we require to send Label set(i.e. time slots) for TDM > > >>> switching as > > >>>well . In what way it can be useful . > > >>Dear Manoj, > > >> > > >>Yes, label set object is also useful in TDM case. E.g., SONET poses an > > >>additional requirement that the two interfaces of a bidirectional LSP > > >>SHOULD traverse the exact same link with the same SUKLM values for the > > >>two directions. > > >> The label set object can be used to constrain the downstream label to > > >> the same as the upstream label. > > >> > > >>Thanks > > >> > > >>Regards... Zafar > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >>>Regards , > > >>>Manoj > > >>=============== > > >>Zafar Ali > > >>Cisco Systems > > >>(734) 276-2459 > > >>100 S Main St. #200 > > >>Ann Arbor, MI 48104. > > >>email: zali@cisco.com > > > > > >=============== > > >Zafar Ali > > >Cisco Systems > > >(734) 276-2459 > > >100 S Main St. #200 > > >Ann Arbor, MI 48104. > > >email: zali@cisco.com From owner-mpls@UU.NET Mon May 13 17:03:21 2002 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 RAA03136 for ; Mon, 13 May 2002 17:03:21 -0400 (EDT) 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 QQmosi00952; Mon, 13 May 2002 21:03:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQmosi27099 for mpls-outgoing; Mon, 13 May 2002 21:03:01 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 QQmosi25087 for ; Mon, 13 May 2002 21:02:42 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 QQmosi13125 for ; Mon, 13 May 2002 21:01:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmosi01900 for ; Mon, 13 May 2002 21:01:03 GMT 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 RAA25772 for ; Mon, 13 May 2002 17:01:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA06841 for mpls@uu.net; Mon, 13 May 2002 17:01:02 -0400 (EDT) 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 QQmosi18524 for ; Mon, 13 May 2002 21:00:05 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 QQmosh05078 for ; Mon, 13 May 2002 20:58:30 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQmosh28149 for ; Mon, 13 May 2002 20:58:30 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02888; Mon, 13 May 2002 16:58:17 -0400 (EDT) Message-Id: <200205132058.QAA02888@ietf.org> To: IETF-Announce:; Cc: RFC Editor , Internet Architecture Board , mpls@UU.NET From: The IESG Subject: Document Action: Framework for IP Multicast in MPLS to Informational Date: Mon, 13 May 2002 16:58:17 -0400 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved the Internet-Draft 'Framework for IP Multicast in MPLS' as an Informational RFC, but request the title be changed to: Overview of IP Multicast in an MPLS environment This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Bert Wijnen and Scott Bradner. From owner-mpls@UU.NET Mon May 13 17:14:45 2002 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 RAA03801 for ; Mon, 13 May 2002 17:14:45 -0400 (EDT) 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 QQmore25138; Mon, 13 May 2002 13:40:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQmore06640 for mpls-outgoing; Mon, 13 May 2002 13:40:11 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 QQmore06630 for ; Mon, 13 May 2002 13:40: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 QQmore11426 for ; Mon, 13 May 2002 13:39:49 GMT Received: from mail2.orchestream.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail2.orchestream.com [195.153.64.126]) id QQmore28354 for ; Mon, 13 May 2002 13:39:48 GMT Received: from mx2.mail.uk.psi.net (unverified) by mail2.orchestream.com (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Fri, 10 May 2002 16:12:31 +0100 Received: from host.secure4-hosting.net ([209.239.41.31]) by mx2.mail.uk.psi.net with esmtp (Exim 2.12 #2) id 176AM1-0004Xr-00; Fri, 10 May 2002 14:22:37 +0100 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id g4AD9OE23554; Fri, 10 May 2002 09:09:24 -0400 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f X-Originating-IP: [155.245.254.253] From: "Christopher Poh" To: mpls-ops@mplsrc.com, mpls@UU.NET Date: Fri, 10 May 2002 12:41:19 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 May 2002 12:41:20.0121 (UTC) FILETIME=[FC278E90:01C1F81F] Subject: [MPLS-OPS]: Any Routers? X-Mailing-List: archive/latest/4003 X-Loop: mpls-ops@mplsrc.com Sender: owner-mpls@UU.NET Precedence: bulk Hi, Do Cisco's product lines support tunnel establishment through implicit peering? Thank you. -Chris _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml . From owner-mpls@UU.NET Tue May 14 00:36:40 2002 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 AAA21362 for ; Tue, 14 May 2002 00:36:40 -0400 (EDT) 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 QQmotm02383; Tue, 14 May 2002 04:36:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmotm18497 for mpls-outgoing; Tue, 14 May 2002 04:36:23 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 QQmotm18382 for ; Tue, 14 May 2002 04:36:04 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 QQmotm18315 for ; Tue, 14 May 2002 04:35:46 GMT Received: from wiprom2mx1.wipro.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQmotm07081 for ; Tue, 14 May 2002 04:35:44 GMT Received: from m2vwall2 (m2vwall2.wipro.com [164.164.29.236]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g4E4ZXZ20956 for ; Tue, 14 May 2002 10:05:33 +0530 (IST) Received: from prasanth ([10.117.3.145]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GW338R00.3PQ; Tue, 14 May 2002 10:01:39 +0530 From: "Ravi Sankar Mantha" To: , Subject: Regarding Resource Class Attribute in CRLDP Date: Tue, 14 May 2002 10:04:28 +0530 Message-ID: <004501c1fb00$a2979760$9103750a@wipro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-8a1d5e40-e7eb-4efe-97c4-d0a4d4bbc797" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal 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. ------=_NextPartTM-000-8a1d5e40-e7eb-4efe-97c4-d0a4d4bbc797 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi , This is regarding resource class attribute in MPLS; I am facing problem in understanding the conversion from Explicit Inclusion, Explicit Exclusion (as specified in RFC2702, section 5.6.3) to the Resource Class Bit Mask ( RsCls field in the Resource Class Tlv in CRLDP). Take the case of Explicit Inclusion, supposing the Bit Mask is 4 of bits (for simplicity). ( in reality it is of 32 bits) Red - bit '0' (LSB) Blue - bit '1' Green - bit '2' Yellow - bit '4' (MSB). Suppose there is a CRLSP whose resource class affinity is INCLUDE - Blue, this can be encoded in the form of bit map as 0010 ( I assume that the '0's are considered as Don't care ?), now this CRLSP can traverse through links whose Resource Class Attributes can be 0110, 0010, 1111 which include the color- blue) etc. If this is the way, Resource Class Bitmap is interpreted by the CRLDP signaling protocol, I wonder how Explicit Exclusion can be encoded as bit map, and interpreted by the Signaling protocol ? It would be of great help if somebody can through some light on this., Thanks in advance, Ravi ------=_NextPartTM-000-8a1d5e40-e7eb-4efe-97c4-d0a4d4bbc797 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************************** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. **************************************************************************************** ------=_NextPartTM-000-8a1d5e40-e7eb-4efe-97c4-d0a4d4bbc797-- From owner-mpls@UU.NET Tue May 14 00:38:05 2002 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 AAA21425 for ; Tue, 14 May 2002 00:38:05 -0400 (EDT) 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 QQmotm10382; Tue, 14 May 2002 04:38:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQmotm18554 for mpls-outgoing; Tue, 14 May 2002 04:37:43 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 QQmotm18542 for ; Tue, 14 May 2002 04:37: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 QQmotm19078 for ; Tue, 14 May 2002 04:37:17 GMT Received: from wiprom2mx1.wipro.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQmotm03316 for ; Tue, 14 May 2002 04:37:15 GMT Received: from m2vwall2 (m2vwall2.wipro.com [164.164.29.236]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g4E4bDZ21813 for ; Tue, 14 May 2002 10:07:13 +0530 (IST) Received: from wipro.com ([127.0.0.1]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GW33HV00.OQA; Tue, 14 May 2002 10:07:07 +0530 From: "Ravi Sankar Mantha" To: mpls@UU.NET, mpls-ops@mplsrc.com Message-ID: <163827165d61.165d61163827@wipro.com> Date: Tue, 14 May 2002 09:37:07 +0500 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: Regarding Resource Class Attribute in CRLDP X-Accept-Language: en Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-67ff206a-ec1b-49a0-9297-a46518e0f1bb" Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPartTM-000-67ff206a-ec1b-49a0-9297-a46518e0f1bb Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi , This is regarding resource class attribute in MPLS; I am facing problem in understanding the conversion from Explicit Inclusion, Explicit Exclusion (as specified in RFC2702, section 5.6.3) to the Resource Class Bit Mask ( RsCls field in the Resource Class Tlv in CRLDP). Take the case of Explicit Inclusion, supposing the Bit Mask is 4 of bits (for simplicity). ( in reality it is of 32 bits) Red - bit '0' (LSB) Blue - bit '1' Green - bit '2' Yellow - bit '4' (MSB). Suppose there is a CRLSP whose resource class affinity is INCLUDE - Blue, this can be encoded in the form of bit map as 0010 ( I assume that the '0's are considered as Don't care ?), now this CRLSP can traverse through links whose Resource Class Attributes can be 0110, 0010, 1111 which include the color- blue) etc. If this is the way, Resource Class Bitmap is interpreted by the CRLDP signaling protocol, I wonder how Explicit Exclusion can be encoded as bit map, and interpreted by the Signaling protocol ? It would be of great help if somebody can through some light on this., Thanks in advance, Ravi ------=_NextPartTM-000-67ff206a-ec1b-49a0-9297-a46518e0f1bb Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************************** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. **************************************************************************************** ------=_NextPartTM-000-67ff206a-ec1b-49a0-9297-a46518e0f1bb-- From owner-mpls@UU.NET Tue May 14 08:04:56 2002 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 IAA14502 for ; Tue, 14 May 2002 08:04:56 -0400 (EDT) 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 QQmouq25598; Tue, 14 May 2002 12:04:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmouq07802 for mpls-outgoing; Tue, 14 May 2002 12:04: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 QQmouq07705 for ; Tue, 14 May 2002 12:04: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 QQmouq16069 for ; Tue, 14 May 2002 12:04:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmouq20835 for ; Tue, 14 May 2002 12:04:02 GMT 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 IAA27395 for ; Tue, 14 May 2002 08:04:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA03556 for mpls@uu.net; Tue, 14 May 2002 08:04:02 -0400 (EDT) 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 QQmouq07481 for ; Tue, 14 May 2002 12:02:28 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 QQmouq25914 for ; Tue, 14 May 2002 12:02:18 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 QQmouq18581 for ; Tue, 14 May 2002 12:02:12 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14428; Tue, 14 May 2002 08:01:51 -0400 (EDT) Message-Id: <200205141201.IAA14428@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-ttl-01.txt Date: Tue, 14 May 2002 08:01:50 -0400 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 : TTL Processing in MPLS Networks Author(s) : P. Agarwal, B. Akyol Filename : draft-ietf-mpls-ttl-01.txt Pages : 7 Date : 13-May-02 This document describes TTL processing in hierarchical MPLS networks. TTL processing in both pipe and uniform model hierarchical tunnels are specified with examples for both 'push' and 'pop' cases. The document also complements [MPLS-DS] and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ttl-01.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-ttl-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ttl-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020513151318.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ttl-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ttl-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020513151318.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue May 14 15:43:08 2002 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 PAA02800 for ; Tue, 14 May 2002 15:43:08 -0400 (EDT) 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 QQmovu00468; Tue, 14 May 2002 19:43:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQmovu28385 for mpls-outgoing; Tue, 14 May 2002 19:42:47 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 QQmovu28371 for ; Tue, 14 May 2002 19:42: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 QQmovu21126 for ; Tue, 14 May 2002 19:41:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmovu09759 for ; Tue, 14 May 2002 19:41:02 GMT 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 PAA00767 for ; Tue, 14 May 2002 15:41:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA18389 for mpls@uu.net; Tue, 14 May 2002 15:41:01 -0400 (EDT) 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 QQmovu28120 for ; Tue, 14 May 2002 19:39: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 QQmovu14847 for ; Tue, 14 May 2002 19:39:17 GMT Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmovu24637 for ; Tue, 14 May 2002 19:39:12 GMT Received: (qmail 26602 invoked by uid 104); 14 May 2002 19:39:07 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4202. . Clean. Processed in 0.470994 secs); 14 May 2002 19:39:07 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 14 May 2002 19:39:06 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g4EJd3p20117 for ; Tue, 14 May 2002 12:39:03 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 12:39:07 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A7E7@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: mpls@UU.NET Subject: RE: I-D ACTION:draft-ietf-mpls-ttl-01.txt Date: Tue, 14 May 2002 12:39:05 -0700 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 Bora/Puneet, What do you mean by the following sentence? "We also note here that signaling treatment for TTL behavior using either RSVP-TE or LDP is out of the scope of this document." -Shahram > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, May 14, 2002 8:02 AM > Cc: mpls@uu.net > Subject: I-D ACTION:draft-ietf-mpls-ttl-01.txt > > > 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 : TTL Processing in MPLS Networks > Author(s) : P. Agarwal, B. Akyol > Filename : draft-ietf-mpls-ttl-01.txt > Pages : 7 > Date : 13-May-02 > > This document describes TTL processing in hierarchical MPLS > networks. TTL processing in both pipe and uniform model hierarchical > tunnels are specified with examples for both 'push' and 'pop' cases. > The document also complements [MPLS-DS] and ties together the > terminology introduced in that document with TTL processing in > hierarchical MPLS networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-ttl-01.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-ttl-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mpls-ttl-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-mpls@UU.NET Tue May 14 19:37:04 2002 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 TAA12210 for ; Tue, 14 May 2002 19:37:04 -0400 (EDT) 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 QQmowk10746; Tue, 14 May 2002 23:37:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQmowk14655 for mpls-outgoing; Tue, 14 May 2002 23:36:47 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 QQmowk14648 for ; Tue, 14 May 2002 23:36:35 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 QQmowk03284 for ; Tue, 14 May 2002 23:35:28 GMT Received: from zcars04f.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQmowk09108 for ; Tue, 14 May 2002 23:35:28 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4ENZQn17824; Tue, 14 May 2002 19:35:26 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 19:35:35 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6024FA453@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: Ravi Sankar Mantha , mpls@UU.NET, mpls-ops@mplsrc.com Subject: RE: Regarding Resource Class Attribute in CRLDP Date: Tue, 14 May 2002 19:36:13 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Ravi To do include/exclude properly you need 2 vectors or you need semantics associated with the one vector (which we don't put in standards as Kireeti reminded me). But apparently you could have a policy to do it. In a single domain you may get by without signaling the vectors since a route computation can be run on a node doing include and exclude and it is unlikely the attributes will change. In the case of multiple domains without route leaking, where you have to do multiple path selections along the path, you need to carry the a vector which would mean that it has to be consistent between domains. Don > -----Original Message----- > From: Ravi Sankar Mantha [mailto:ravi.mantha@wipro.com] > > > Hi , > This is regarding resource class attribute in MPLS; > I am facing problem in understanding the conversion from Explicit > Inclusion, Explicit Exclusion (as specified in RFC2702, > section 5.6.3) > to > the Resource Class Bit Mask ( RsCls field in the Resource Class Tlv in > CRLDP). > Take the case of Explicit Inclusion, supposing the Bit > Mask is 4 of > bits > (for simplicity). ( in reality it is of 32 bits) > Red - bit '0' (LSB) > Blue - bit '1' > Green - bit '2' > Yellow - bit '4' (MSB). > Suppose there is a CRLSP whose resource class affinity is > INCLUDE - > Blue, this can be encoded in the form of bit map as 0010 ( I assume > that > the '0's are considered as Don't care ?), now this CRLSP can traverse > through links whose Resource Class Attributes can be 0110, 0010, 1111 > which include the color- blue) etc. If this is the way, > Resource Class > Bitmap is interpreted by the CRLDP signaling protocol, I wonder how > Explicit > Exclusion can be encoded as bit map, and interpreted by the Signaling > protocol ? > It would be of great help if somebody can through some light on > this., > Thanks in advance, > Ravi > > > From owner-mpls@UU.NET Wed May 15 00:48:46 2002 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 AAA24230 for ; Wed, 15 May 2002 00:48:46 -0400 (EDT) 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 QQmoxf16858; Wed, 15 May 2002 04:48:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoxf28204 for mpls-outgoing; Wed, 15 May 2002 04:48: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 QQmoxf28194 for ; Wed, 15 May 2002 04:48: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 QQmoxf10104 for ; Wed, 15 May 2002 04:47:51 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 QQmoxf14873 for ; Wed, 15 May 2002 04:47:49 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 g4F4ljZ07548 for ; Wed, 15 May 2002 10:17:46 +0530 (IST) Received: from prasanth ([10.117.3.145]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GW4YNF00.C2O; Wed, 15 May 2002 10:17:39 +0530 From: "Ravi Sankar Mantha" To: "Fedyk Don [BL60:1A00:EXCH]" , , Subject: RE: Regarding Resource Class Attribute in CRLDP Date: Wed, 15 May 2002 10:20:28 +0530 Message-ID: <008201c1fbcc$08e7e580$9103750a@wipro.com> 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 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E6024FA453@zcard0ke.ca.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Don, Thank you for the explanation. In the Resource Class Tlv of CRLDP, the definition of RsCls, "The Resource Class bit mask indicating wihch of the 32 _administrative groups_ or _colors_ of links the CR-LSP can traverse", sounds as though it can carry only the "Include" information in it. Thus it looks like it is out of the scope of CRLDP signaling to carry the "Exclude" vector. Is it not required to signal through CRLDP ? ( I think this is what you mentioned as the 2nd vector). Then, what do you mean by associating semantics with one vector ?, is it something like supporting only one ( either Include/ Exclude) in the entire domain, so that the Bit Mask can be interpreted accordingly ? Thanks and Regards, Ravi -----Original Message----- From: Fedyk, Don [BL60:1A00:EXCH] [mailto:dwfedyk@americasm01.nt.com] Sent: Wednesday, May 15, 2002 5:06 AM To: Ravi Sankar Mantha; mpls@UU.NET; mpls-ops@mplsrc.com Subject: RE: Regarding Resource Class Attribute in CRLDP Ravi To do include/exclude properly you need 2 vectors or you need semantics associated with the one vector (which we don't put in standards as Kireeti reminded me). But apparently you could have a policy to do it. In a single domain you may get by without signaling the vectors since a route computation can be run on a node doing include and exclude and it is unlikely the attributes will change. In the case of multiple domains without route leaking, where you have to do multiple path selections along the path, you need to carry the a vector which would mean that it has to be consistent between domains. Don > -----Original Message----- > From: Ravi Sankar Mantha [mailto:ravi.mantha@wipro.com] > > > Hi , > This is regarding resource class attribute in MPLS; > I am facing problem in understanding the conversion from Explicit > Inclusion, Explicit Exclusion (as specified in RFC2702, > section 5.6.3) > to > the Resource Class Bit Mask ( RsCls field in the Resource Class Tlv in > CRLDP). > Take the case of Explicit Inclusion, supposing the Bit > Mask is 4 of > bits > (for simplicity). ( in reality it is of 32 bits) > Red - bit '0' (LSB) > Blue - bit '1' > Green - bit '2' > Yellow - bit '4' (MSB). > Suppose there is a CRLSP whose resource class affinity is > INCLUDE - > Blue, this can be encoded in the form of bit map as 0010 ( I assume > that > the '0's are considered as Don't care ?), now this CRLSP can traverse > through links whose Resource Class Attributes can be 0110, 0010, 1111 > which include the color- blue) etc. If this is the way, > Resource Class > Bitmap is interpreted by the CRLDP signaling protocol, I wonder how > Explicit > Exclusion can be encoded as bit map, and interpreted by the Signaling > protocol ? > It would be of great help if somebody can through some light on > this., > Thanks in advance, > Ravi > > > From owner-mpls@UU.NET Wed May 15 05:05:38 2002 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 FAA22345 for ; Wed, 15 May 2002 05:05:38 -0400 (EDT) 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 QQmoxw17752; Wed, 15 May 2002 09:05:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoxw29378 for mpls-outgoing; Wed, 15 May 2002 09:05:12 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 QQmoxw28464 for ; Wed, 15 May 2002 09:05:04 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 QQmoxw13611 for ; Wed, 15 May 2002 09:03:21 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQmoxw14472 for ; Wed, 15 May 2002 09:03:19 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 15 May 2002 14:52:23 +0530 Received: from ashokkp (ashokkp.future.futsoft.com [10.6.2.17]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g4FEWv519186 for ; Wed, 15 May 2002 20:02:59 +0530 Reply-To: From: "Ashokkp" To: Subject: FW: Administrative status information Date: Wed, 15 May 2002 14:32:36 +0530 Message-Id: <001101c1fbef$429808a0$1102060a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit - can any one tell me,what is the advantage of the administrative status object when in deletion and testing mode thanx ashok *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Wed May 15 05:11:35 2002 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 FAA22479 for ; Wed, 15 May 2002 05:11:35 -0400 (EDT) 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 QQmoxw10668; Wed, 15 May 2002 09:11:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoxw07293 for mpls-outgoing; Wed, 15 May 2002 09:11: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 QQmoxw07229 for ; Wed, 15 May 2002 09:11:12 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 QQmoxw18144 for ; Wed, 15 May 2002 09:10:24 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQmoxw25720 for ; Wed, 15 May 2002 09:10:21 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 15 May 2002 14:59:35 +0530 Received: from ashokkp (ashokkp.future.futsoft.com [10.6.2.17]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g4FEeB520155 for ; Wed, 15 May 2002 20:10:11 +0530 Reply-To: From: "Ashokkp" To: Subject: gmpls -signaling extn Date: Wed, 15 May 2002 14:39:50 +0530 Message-Id: <001201c1fbf0$45210800$1102060a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit In the GMPLS-RSVP-TE extensions In the Label Set Procedure ?????????????? "specific labels/subchannels can be added to or excluded from a label set via action zero(0)and one (1) objects respectively. Ranges of Labels/subchannels can be added to or excluded from a Label Set via Action two (2) and three (3) object respectively" ---------- the above statement is not clear to me can anybody explain me what the statement says ? thanx in advance ashok *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Wed May 15 08:26:49 2002 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 IAA29318 for ; Wed, 15 May 2002 08:26:44 -0400 (EDT) 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 QQmoyj17238; Wed, 15 May 2002 12:26:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoyj28386 for mpls-outgoing; Wed, 15 May 2002 12:26: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 QQmoyj28381 for ; Wed, 15 May 2002 12:26:29 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 QQmoyj16376 for ; Wed, 15 May 2002 12:25:50 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 QQmoyj23195 for ; Wed, 15 May 2002 12:25:43 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 g4FCPeZ10742 for ; Wed, 15 May 2002 17:55:41 +0530 (IST) Received: from Sonal.wipro.com ([10.117.3.141]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GW5JUL00.AET; Wed, 15 May 2002 17:55:33 +0530 Message-ID: <00e701c1fbe6$496cc700$8d03750a@wipro.com> Reply-To: "venkat" From: "Venkat Dabbara" To: , References: <001201c1fbf0$45210800$1102060a@future.futsoft.com> Subject: Re: gmpls -signaling extn Date: Wed, 15 May 2002 17:58:22 +1000 Organization: wipro technologies X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk hai ashok, Label set is used in the situation where an upstream wants to put some restrictions on the label selection at the downstream node. With the label set object/TLV the upstream guides the downstream to pick up a label for him from the label set or out of the label set which is indicated by the action type. Inwhich case the peer recieving the label set as a part of label request has to restrict its label selection for the upstream from the label set specfied. Again depending on the action flag may even select label out of the label set specified. The applicability of such a restriction is indicated in same draft or u can go through the gmpls signalling draft hope this helps... regards venkat ----- Original Message ----- From: "Ashokkp" To: Sent: Wednesday, May 15, 2002 7:09 PM Subject: gmpls -signaling extn > In the GMPLS-RSVP-TE extensions > In the Label Set Procedure > > ?????????????? > "specific labels/subchannels can be added to or excluded from a label set > via action > zero(0)and one (1) objects respectively. Ranges of Labels/subchannels can > be added to > or excluded from a Label Set via Action two (2) and three (3) object > respectively" > > ---------- the above statement is not clear to me > can anybody explain me what the statement says ? > thanx in advance > ashok > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** From owner-mpls@UU.NET Wed May 15 08:41:06 2002 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 IAA00078 for ; Wed, 15 May 2002 08:41:05 -0400 (EDT) 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 QQmoyk21896; Wed, 15 May 2002 12:41:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoyk29330 for mpls-outgoing; Wed, 15 May 2002 12:40: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 QQmoyk29323 for ; Wed, 15 May 2002 12:40: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 QQmoyk29216 for ; Wed, 15 May 2002 12:40:09 GMT Received: from web21504.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web21504.mail.yahoo.com [66.163.169.15]) id QQmoyk13600 for ; Wed, 15 May 2002 12:40:09 GMT Message-ID: <20020515124008.52135.qmail@web21504.mail.yahoo.com> Received: from [194.204.152.84] by web21504.mail.yahoo.com via HTTP; Wed, 15 May 2002 14:40:08 CEST Date: Wed, 15 May 2002 14:40:08 +0200 (CEST) From: =?iso-8859-1?q?mahmoud=20hebache?= To: mpls@UU.NET MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1814726697-1021466408=:51325" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk --0-1814726697-1021466408=:51325 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Goodafternoon, I am studying the IP MPLS to write a database of recommandations. Neverthless, I have some difficulties to understand the links between MPLS routers and the use of AM or FrameRelay. I would be very pleased if someone could give me a link to understand what is exactely ( I am an engineering stuedent, not an expert). Thank you very much. --------------------------------- Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en français ! --0-1814726697-1021466408=:51325 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Goodafternoon,

I am studying the IP MPLS to write a database of recommandations. Neverthless, I have some difficulties to understand the links between MPLS routers and the use of AM or FrameRelay.

I would be very pleased if someone could give me a link to understand what is exactely ( I am an engineering stuedent, not an expert).

Thank you very much.

 

 


Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en français !
--0-1814726697-1021466408=:51325-- From owner-mpls@UU.NET Wed May 15 09:31:32 2002 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 JAA03372 for ; Wed, 15 May 2002 09:31:32 -0400 (EDT) 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 QQmoyo23937; Wed, 15 May 2002 13:31:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoyo25981 for mpls-outgoing; Wed, 15 May 2002 13:31: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 QQmoyo25976 for ; Wed, 15 May 2002 13:31: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 QQmoyo20439 for ; Wed, 15 May 2002 13:30:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmoyo21068 for ; Wed, 15 May 2002 13:30:03 GMT 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 JAA12531 for ; Wed, 15 May 2002 09:30:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA02107 for mpls@uu.net; Wed, 15 May 2002 09:30:03 -0400 (EDT) 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 QQmoyn25763 for ; Wed, 15 May 2002 13:29:34 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 QQmoyn16817 for ; Wed, 15 May 2002 13:28:17 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQmoyn24607 for ; Wed, 15 May 2002 13:28:16 GMT Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA00751; Wed, 15 May 2002 09:28:15 -0400 (EDT) Date: Wed, 15 May 2002 09:28:15 -0400 (EDT) From: Ajay Simha To: =?iso-8859-1?q?mahmoud=20hebache?= cc: mpls@UU.NET Subject: Re: your mail In-Reply-To: <20020515124008.52135.qmail@web21504.mail.yahoo.com> Message-ID: References: <20020515124008.52135.qmail@web21504.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id JAA03372 On Wed, 15 May 2002, mahmoud hebache wrote: >mh: >mh:Goodafternoon, >mh: >mh:I am studying the IP MPLS to write a database of recommandations. >mh:Neverthless, I have some difficulties to understand the links between MPLS >mh:routers and the use of AM or FrameRelay. ^^ I'm guessing ATM :) ATM and MPLS have a long time relationship. I'd say MPLS has roots in ATM/FR like switching. MPLS was kind-of born to ATM switches fit into an IP world and IP fit into the ATM world. Enough about history. As it stands today ATM/FR is still the most popular methods for access circuits (to bring in a customer's circuit into the provider). Today there are still a lot of ATM switch based cores which can be used as though it is a packet based core because of running MPLS in the network. The other place you'll hear about ATM/FR with MPLS is in L2MPLS where islands of ATM/FR networks can be connected over an MPLS cloud (general purpose packet core). >mh: >mh:I would be very pleased if someone could give me a link to understand what >mh:is exactely ( I am an engineering stuedent, not an expert). I'm an engineer and not an expert either :) Regards, -ajay >mh: >mh:Thank you very much. >mh: >mh: >mh: >mh: >mh: >mh: >mh: >mh:--------------------------------- >mh:Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en français ! >mh: -- From owner-mpls@UU.NET Wed May 15 10:50:36 2002 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 KAA08520 for ; Wed, 15 May 2002 10:50:35 -0400 (EDT) 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 QQmoyt15041; Wed, 15 May 2002 14:50:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoyt24393 for mpls-outgoing; Wed, 15 May 2002 14:50:30 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 QQmoyt24372 for ; Wed, 15 May 2002 14:50: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 QQmoyt02982 for ; Wed, 15 May 2002 14:50:09 GMT Received: from samar.sasken.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQmoyt13987 for ; Wed, 15 May 2002 14:50:05 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g4FEnqG01785; Wed, 15 May 2002 20:19:52 +0530 (IST) Received: from sushanth (pcz-sushantm.sasken.com [10.1.64.104]) by sunsv2.sasken.com (8.11.6/8.11.6) with SMTP id g4FEnlq28418; Wed, 15 May 2002 20:19:47 +0530 (IST) From: "sushantm" To: Cc: Subject: unified control plane Date: Wed, 15 May 2002 20:21:34 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: High X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have following queries. In an unified control plane(RSVP,LMP,OSPF) ----------------------------------------- Does the LMP protocol exchange Label information with the ajacent node.? LMP in the correlation procedure exchange along with TE links,the datalink ID's. Is Datalink Id's are the labels ? RSVP has IF_ID RSVP_HOP object which specifies the data channel in which the LSP is will be established .From Where does RSVP get this data interface information. Does it get it from LMP.? Regards, Sushanth From owner-mpls@UU.NET Wed May 15 11:01:46 2002 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 LAA08956 for ; Wed, 15 May 2002 11:01:46 -0400 (EDT) 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 QQmoyu11833; Wed, 15 May 2002 15:01:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoyu29274 for mpls-outgoing; Wed, 15 May 2002 15:01: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 QQmoyu29208 for ; Wed, 15 May 2002 15:01:29 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 QQmoyu05629 for ; Wed, 15 May 2002 15:00:20 GMT Received: from wiprom2mx1.wipro.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQmoyu29494 for ; Wed, 15 May 2002 15:00:12 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 g4FF02Z12543 for ; Wed, 15 May 2002 20:30:02 +0530 (IST) Received: from Sonal.wipro.com ([10.117.3.141]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GW5QZW00.AID for ; Wed, 15 May 2002 20:29:56 +0530 Message-ID: <018701c1fbfb$da944e00$8d03750a@wipro.com> Reply-To: "venkat" From: "Venkat Dabbara" To: "mpls@UU. NET \(E-mail\)" References: <9D42C6E086250248810DCADA39CE7EFC59F69F@nimbus> <4.3.2.7.2.20020513112029.00bac008@mira1.cisco.com> Subject: Label Set Object Date: Wed, 15 May 2002 20:32:45 +1000 Organization: wipro technologies X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk hai , In draft-ietf-mpls-generalized-cr-ldp-06.txt 2.5.1. Procedures A Label Set is defined via one or more Label Set TLVs. Specific labels/subchannels can be added to or excluded from a Label Set via Action zero (0) and one (1) TLVs respectively. Ranges of labels/subchannels can be added to or excluded from a Label Set via Action two (2) and three (3) TLVs respectively. The first line of the sec 2.5.1 says a label set is defined via one or more LabelSet TLVs. My interpretation about this is that a label request can have multiple Label Set TLVs in it with different action types corresponding to each label set TLV. Am i right ?? If i am wrong please do clarify ... If yes, then assume i get a request with one label set TLV with action type 0 which has a list of labels and other Label set TLV with action type 1 which has a range of Labels. Now in this case i go about picking up a label from the second label set TLV only if i am not able to pick up a label from the first label set TLV....Is that true ?? Now situation may get even worse when i have a Label set TLV with action type to include a label set and other Label Set TLV with action type exclude. I knoe such situations are not practical but sure needs to be handled someway. Please do clarify venkat PS: Please don't bother about the disclaimer which come attached with this mail. From owner-mpls@UU.NET Wed May 15 11:02:53 2002 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 LAA09149 for ; Wed, 15 May 2002 11:02:53 -0400 (EDT) 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 QQmoyu22782; Wed, 15 May 2002 15:03:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoyu00306 for mpls-outgoing; Wed, 15 May 2002 15:02: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 QQmoyu00196 for ; Wed, 15 May 2002 15:02:35 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 QQmoyu07139 for ; Wed, 15 May 2002 15:01:05 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmoyu19408 for ; Wed, 15 May 2002 15:01:03 GMT 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 LAA21308 for ; Wed, 15 May 2002 11:01:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA12221 for mpls@uu.net; Wed, 15 May 2002 11:01:03 -0400 (EDT) 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 QQmoyu25759 for ; Wed, 15 May 2002 15:00:05 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 QQmoyt24261 for ; Wed, 15 May 2002 14:58:54 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmoyt06760 for ; Wed, 15 May 2002 14:58: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 KAA94611; Wed, 15 May 2002 10:54:50 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200205151454.KAA94611@workhorse.fictitious.org> To: "Ravi Sankar Mantha" cc: "Fedyk Don [BL60:1A00:EXCH]" , mpls@UU.NET, mpls-ops@mplsrc.com Reply-To: curtis@fictitious.org Subject: Re: Regarding Resource Class Attribute in CRLDP In-reply-to: Your message of "Wed, 15 May 2002 10:20:28 +0530." <008201c1fbcc$08e7e580$9103750a@wipro.com> Date: Wed, 15 May 2002 10:54:50 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <008201c1fbcc$08e7e580$9103750a@wipro.com>, "Ravi Sankar Mantha" wri tes: > Hi Don, > Thank you for the explanation. > In the Resource Class Tlv of CRLDP, the definition of RsCls, "The > Resource Class bit mask indicating wihch of the 32 _administrative groups_ > or _colors_ of links the CR-LSP can traverse", sounds as though it can carry > only the "Include" information in it. Thus it looks like it is out of the > scope of CRLDP signaling to carry the "Exclude" vector. Is it not required > to signal through CRLDP ? ( I think this is what you mentioned as the 2nd > vector). > Then, what do you mean by associating semantics with one vector ?, is it > something like supporting only one ( either Include/ Exclude) in the entire > domain, so that the Bit Mask can be interpreted accordingly ? > Thanks and Regards, > Ravi The extensions to OSPF and ISIS provide one 32 bit word to be used as a bitmap to describe the attributes (colors) of a link. RFC3209 provides semantics for RSVP/TE which are only needed if local-protect is used or for inter-area LSPs (which are problematic to say the least if attempts are made to enforce color restrictions across IGP areas). 4.7.2. Format with resource affinities SESSION_ATTRIBUTE class = 207, LSP_TUNNEL_RA C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exclude-any | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Include-any | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Include-all | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Setup Prio | Holding Prio | Flags | Name Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Session Name (NULL padded display string) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Exclude-any A 32-bit vector representing a set of attribute filters associated with a tunnel any of which renders a link unacceptable. Include-any A 32-bit vector representing a set of attribute filters associated with a tunnel any of which renders a link acceptable (with respect to this test). A null set (all bits set to zero) automatically passes. Include-all A 32-bit vector representing a set of attribute filters associated with a tunnel all of which must be present for a link to be acceptable (with respect to this test). A null set (all bits set to zero) automatically passes. The FRR draft draft-ping-rsvp-fastreroute-00.txt provides the same semantics with an include-any but does not support an include-all. 3.1.1. FAST_REROUTE Object Class = 205 (use form 11bbbbbb for compatibility) C-Type = 7 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | Setup Prio | Hold Prio | Hop-limit | Reserved | +-------------+-------------+-------------+-------------+ | Bandwidth | +-------------+-------------+-------------+-------------+ | Include colors | +-------------+-------------+-------------+-------------+ | Exclude colors | +-------------+-------------+-------------+-------------+ [ ... snip ... ] Include colors A 32-bit vector representing a set of attribute filters associated with a detour any of which renders a link acceptable (with respect to this test). A null set (all bits set to zero) automatically passes. Exclude colors A 32-bit vector representing a set of attribute filters associated with a detour any of which renders a link unacceptable. AFAIK no one really cares about CRLDP so whether they got it wrong by providing only one word for the LSP may not be important. Curtis From owner-mpls@UU.NET Wed May 15 11:52:37 2002 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 LAA10640 for ; Wed, 15 May 2002 11:52:36 -0400 (EDT) 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 QQmoyx25149; Wed, 15 May 2002 15:52:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoyx21898 for mpls-outgoing; Wed, 15 May 2002 15:52:29 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 QQmoyx21891 for ; Wed, 15 May 2002 15:52:26 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 QQmoyx04252 for ; Wed, 15 May 2002 15:52:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmoyx07380 for ; Wed, 15 May 2002 15:52:02 GMT 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 LAA25463 for ; Wed, 15 May 2002 11:52:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA18296 for mpls@uu.net; Wed, 15 May 2002 11:52:02 -0400 (EDT) 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 QQmoyx21818 for ; Wed, 15 May 2002 15:51:20 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 QQmoyx05141 for ; Wed, 15 May 2002 15:50:05 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sword.cisco.com [161.44.208.100]) id QQmoyx04428 for ; Wed, 15 May 2002 15:50:05 GMT Received: from ZALI-W2K.cisco.com (che-vpn2-23.cisco.com [10.86.244.23]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id LAA07405; Wed, 15 May 2002 11:49:54 -0400 (EDT) Message-Id: <4.3.2.7.2.20020515112853.02d36f98@sword.cisco.com> X-Sender: zali@sword.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 X-Priority: 1 (Highest) Date: Wed, 15 May 2002 11:49:41 -0400 To: "sushantm" , From: Zafar Ali Subject: Re: unified control plane Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_7178872==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_7178872==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear sushantm, Please see comments in-lined. Thanks Regards... Zafar At 08:21 PM 5/15/2002 +0530, sushantm wrote: >Hi, > >I have following queries. > >In an unified control plane(RSVP,LMP,OSPF) >----------------------------------------- >Does the LMP protocol exchange Label information with the ajacent node.? No, >LMP in the correlation procedure exchange along with TE links,the datalink >ID's. >Is Datalink Id's are the labels ? No, A data link may contain multiple labels. LMP does not operate at the label level. >RSVP has IF_ID RSVP_HOP object which specifies the data channel in which the >LSP is will >be established .From Where does RSVP get this data interface information. >Does it get it from LMP.? At the sender LSR, the selection of the component link in a TE Link (the bundled case) is a local decision or the information comes directly from ERO (unbundled case). However, when an LSR receives a Path message containing the IF_ID RSVP_HOP object with the IF_INDEX TLV, it uses an interface ID mapping functions (generated by using LMP or some other means) and the neighbor router ID to identify the unnumbered component link in question. >Regards, >Sushanth =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com --=====================_7178872==_.ALT Content-Type: text/html; charset="us-ascii" Dear sushantm,

Please see comments in-lined.

Thanks

Regards... Zafar

At 08:21 PM 5/15/2002 +0530, sushantm wrote:
Hi,

I have following queries.

In an unified control plane(RSVP,LMP,OSPF)
-----------------------------------------
Does the LMP protocol exchange Label information with the ajacent node.?

No,


LMP in the correlation procedure  exchange along with TE links,the datalink
ID's.
Is Datalink Id's are the labels ?

No, A data link may contain multiple labels. LMP does not operate at the label level.


RSVP has IF_ID RSVP_HOP object which specifies the data channel in which the
LSP is will
be established .From Where does RSVP get this data interface information.
Does it get it from LMP.?

At the sender LSR, the selection of the component link in a TE Link (the bundled case) is a local decision or the information comes directly from ERO (unbundled case). However, when an LSR receives a Path message containing the IF_ID RSVP_HOP object with the IF_INDEX TLV, it uses an interface ID mapping functions (generated by using LMP or some other means) and the neighbor router ID to identify the unnumbered component link in question.


Regards,
Sushanth

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com --=====================_7178872==_.ALT-- From owner-mpls@UU.NET Wed May 15 12:11:55 2002 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 MAA11466 for ; Wed, 15 May 2002 12:11:55 -0400 (EDT) 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 QQmoyy26822; Wed, 15 May 2002 16:12:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQmoyy15210 for mpls-outgoing; Wed, 15 May 2002 16:11:34 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 QQmoyy15205 for ; Wed, 15 May 2002 16:11:32 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 QQmoyy16143 for ; Wed, 15 May 2002 16:11:05 GMT Received: from pulsar.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 200-139.adsl6.netlojix.net [207.71.200.139] (may be forged)) id QQmoyy25281 for ; Wed, 15 May 2002 16:11:05 GMT Received: by pulsar.chromisys.com with Internet Mail Service (5.5.2655.55) id <204C927T>; Wed, 15 May 2002 09:03:26 -0700 Message-ID: From: Jonathan Lang To: "'Zafar Ali'" , sushantm , mpls@UU.NET Cc: gmpls-ops@mplsrc.com Subject: RE: unified control plane Date: Wed, 15 May 2002 09:03:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Zafar, Comments inline. Thanks, Jonathan >-----Original Message----- >From: Zafar Ali [mailto:zali@cisco.com] >Sent: Wednesday, May 15, 2002 8:50 AM >To: sushantm; mpls@UU.NET >Cc: gmpls-ops@mplsrc.com >Subject: Re: unified control plane >Importance: High > > >Dear sushantm, > >Please see comments in-lined. > >Thanks > >Regards... Zafar > >>At 08:21 PM 5/15/2002 +0530, sushantm wrote: >> >>Hi, >> >>I have following queries. >> >>In an unified control plane(RSVP,LMP,OSPF) >>----------------------------------------- >>Does the LMP protocol exchange Label information with the ajacent node.? > >No, In the case where you are doing port or wavelength switching, the data link Interface_Ids are used in the port/wavelength Label. >>LMP in the correlation procedure exchange along with TE links,the datalink ID's. >>Is Datalink Id's are the labels ? >> >No, A data link may contain multiple labels. LMP does not operate at the label level. see comment above. >>RSVP has IF_ID RSVP_HOP object which specifies the data channel in which the LSP is will >>be established .From Where does RSVP get this data interface information. >>Does it get it from LMP.? >> >At the sender LSR, the selection of the component link in a TE Link (the bundled case) is a >local decision or the information comes directly from ERO (unbundled case). However, when >an LSR receives a Path message containing the IF_ID RSVP_HOP object with the IF_INDEX TLV, >it uses an interface ID mapping functions (generated by using LMP or some other means) and >the neighbor router ID to identify the unnumbered component link in question. Correct. The local/remote mapping can be learned using LMP. From owner-mpls@UU.NET Wed May 15 17:16:12 2002 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 RAA22505 for ; Wed, 15 May 2002 17:16:11 -0400 (EDT) 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 QQmozt15589; Wed, 15 May 2002 21:16:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQmozt28836 for mpls-outgoing; Wed, 15 May 2002 21:16:04 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 QQmozt28772 for ; Wed, 15 May 2002 21:15: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 QQmozt25756 for ; Wed, 15 May 2002 21:15:38 GMT Received: from yarilo.pluris.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: yarilo.pluris.com [208.227.9.200]) id QQmozt14608 for ; Wed, 15 May 2002 21:15:37 GMT Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id OAA12968; Wed, 15 May 2002 14:15:34 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id <25G83X5T>; Wed, 15 May 2002 14:15:34 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CA02C6A06E@avalon.pluris.com> From: Puneet Agarwal To: "'Shahram Davari'" , mpls@UU.NET Subject: RE: I-D ACTION:draft-ietf-mpls-ttl-01.txt Date: Wed, 15 May 2002 14:15:33 -0700 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 Shahram, Today there is no way to signal the TTL treatment of each LSP as there is no way to signal the tunnel type (uniform, pipe etc) in RSVP-TE/CR-LDP. We just wanted to reiterate that here. Maybe it should be phrased differently to be more clear: "We also note here that signaling the LSP type (pipe/uniform model) is out of the scope of this document." Other suggestions? -Puneet -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Tuesday, May 14, 2002 12:39 PM To: mpls@UU.NET Subject: RE: I-D ACTION:draft-ietf-mpls-ttl-01.txt Bora/Puneet, What do you mean by the following sentence? "We also note here that signaling treatment for TTL behavior using either RSVP-TE or LDP is out of the scope of this document." -Shahram > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, May 14, 2002 8:02 AM > Cc: mpls@uu.net > Subject: I-D ACTION:draft-ietf-mpls-ttl-01.txt > > > 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 : TTL Processing in MPLS Networks > Author(s) : P. Agarwal, B. Akyol > Filename : draft-ietf-mpls-ttl-01.txt > Pages : 7 > Date : 13-May-02 > > This document describes TTL processing in hierarchical MPLS > networks. TTL processing in both pipe and uniform model hierarchical > tunnels are specified with examples for both 'push' and 'pop' cases. > The document also complements [MPLS-DS] and ties together the > terminology introduced in that document with TTL processing in > hierarchical MPLS networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-ttl-01.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-ttl-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mpls-ttl-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-mpls@UU.NET Wed May 15 17:35:48 2002 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 RAA23010 for ; Wed, 15 May 2002 17:35:48 -0400 (EDT) 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 QQmozu12873; Wed, 15 May 2002 21:35:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQmozu00372 for mpls-outgoing; Wed, 15 May 2002 21:35:19 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 QQmozu00353 for ; Wed, 15 May 2002 21:35:17 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 QQmozu27168 for ; Wed, 15 May 2002 21:35:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmozu12172 for ; Wed, 15 May 2002 21:35:03 GMT 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 RAA21318 for ; Wed, 15 May 2002 17:35:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA23230 for mpls@uu.net; Wed, 15 May 2002 17:35:02 -0400 (EDT) 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 QQmozu00265 for ; Wed, 15 May 2002 21:33:56 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 QQmozu06658 for ; Wed, 15 May 2002 21:33:28 GMT Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmozu09966 for ; Wed, 15 May 2002 21:33:27 GMT Received: (qmail 16454 invoked by uid 104); 15 May 2002 21:33:27 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4202. . Clean. Processed in 0.468432 secs); 15 May 2002 21:33:27 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 15 May 2002 21:33:26 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g4FLXNp17756; Wed, 15 May 2002 14:33:23 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 14:33:27 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A7F6@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Puneet Agarwal'" , mpls@UU.NET Subject: RE: I-D ACTION:draft-ietf-mpls-ttl-01.txt Date: Wed, 15 May 2002 14:33:23 -0700 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 Puneet, Looks better. And I think in general you have made a great draft. -Shahram > -----Original Message----- > From: Puneet Agarwal [mailto:puneet@pluris.com] > Sent: Wednesday, May 15, 2002 5:16 PM > To: Shahram Davari; mpls@UU.NET > Subject: RE: I-D ACTION:draft-ietf-mpls-ttl-01.txt > > > Hi Shahram, > > Today there is no way to signal the TTL treatment of each LSP > as there is no > way to signal the tunnel type (uniform, pipe etc) in > RSVP-TE/CR-LDP. We just > wanted to reiterate that here. > > Maybe it should be phrased differently to be more clear: > > "We also note here that signaling the LSP type (pipe/uniform model) > is out of the scope of this document." > > Other suggestions? > > -Puneet > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Tuesday, May 14, 2002 12:39 PM > To: mpls@UU.NET > Subject: RE: I-D ACTION:draft-ietf-mpls-ttl-01.txt > > > Bora/Puneet, > > What do you mean by the following sentence? > > > "We also note here that signaling treatment for TTL behavior using > either RSVP-TE or LDP is out of the scope of this document." > > -Shahram > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Tuesday, May 14, 2002 8:02 AM > > Cc: mpls@uu.net > > Subject: I-D ACTION:draft-ietf-mpls-ttl-01.txt > > > > > > 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 : TTL Processing in MPLS Networks > > Author(s) : P. Agarwal, B. Akyol > > Filename : draft-ietf-mpls-ttl-01.txt > > Pages : 7 > > Date : 13-May-02 > > > > This document describes TTL processing in hierarchical MPLS > > networks. TTL processing in both pipe and uniform model > hierarchical > > tunnels are specified with examples for both 'push' and > 'pop' cases. > > The document also complements [MPLS-DS] and ties together the > > terminology introduced in that document with TTL processing in > > hierarchical MPLS networks. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-ttl-01.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-ttl-01.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-mpls-ttl-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > From owner-mpls@UU.NET Thu May 16 06:04:17 2002 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 GAA19079 for ; Thu, 16 May 2002 06:04:17 -0400 (EDT) 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 QQmpbs14390; Thu, 16 May 2002 10:04:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpbs01575 for mpls-outgoing; Thu, 16 May 2002 10:03:51 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 QQmpbs01567 for ; Thu, 16 May 2002 10:03: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 QQmpbs27405 for ; Thu, 16 May 2002 10:02:07 GMT Received: from scutsv39.scut.edu.cn by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.38.193.39]) id QQmpbs25541 for ; Thu, 16 May 2002 10:02:05 GMT Received: from letterbox.scut.edu.cn (mail.scut.edu.cn [202.38.193.69]) by scutsv39.scut.edu.cn (8.9.3/8.9.3) with ESMTP id RAA17126 for ; Thu, 16 May 2002 17:58:35 +0800 (CST) Received: from hchang ([202.38.197.20]) by letterbox.scut.edu.cn (8.9.3+Sun/8.9.3) with SMTP id RAA23315 for ; Thu, 16 May 2002 17:49:18 +0800 (CST) Message-Id: <200205160949.RAA23315@letterbox.scut.edu.cn> Date: Thu, 16 May 2002 18:4:27 +0800 From: hchang To: MPLS X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi:) can i ask you a question? i am doubted about the QOS routing. my view is: the object of QOS routing is to meet the strict QOS constrain of per-flow,is it right? it just fit the model of guarantee service in Intserv,but as we know ,the Interv has the Scalability problem, and now we are interesting in the research of Diffserv model.but in the Differv,flows are aggregated in a PHB unit, so how can we guarantee the per-flow QOS in this aggregated model? e.g the end to end delay is a cumulative QOS parameter,when we queue aggregated flows in the same queue in the router,how can we determine the delay bound in this router for each flow packets? so how can we use QOS routing in the Diffserv model? thank you very much:) From owner-mpls@UU.NET Thu May 16 12:12:12 2002 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 MAA00413 for ; Thu, 16 May 2002 12:12:11 -0400 (EDT) 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 QQmpbe03977; Thu, 16 May 2002 06:38:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpbe28683 for mpls-outgoing; Thu, 16 May 2002 06:37: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 QQmpbe28678 for ; Thu, 16 May 2002 06:37:48 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 QQmpbe02474 for ; Thu, 16 May 2002 06:37:29 GMT Received: from web21501.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web21501.mail.yahoo.com [66.163.169.12]) id QQmpbe10488 for ; Thu, 16 May 2002 06:37:28 GMT Message-ID: <20020516063726.78398.qmail@web21501.mail.yahoo.com> Received: from [128.107.253.37] by web21501.mail.yahoo.com via HTTP; Wed, 15 May 2002 23:37:26 PDT Date: Wed, 15 May 2002 23:37:26 -0700 (PDT) From: srinivasa gopinath gadamsetty Subject: crldp er hops To: mpls@UU.NET MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-73450008-1021531046=:78057" Sender: owner-mpls@UU.NET Precedence: bulk --0-73450008-1021531046=:78057 Content-Type: text/plain; charset=us-ascii Hi I have some questions abt cr-ldp configuration.... How crldp knows about its intermediate hops ? / How the ERHOP's are filled in request message ? Does any protocol gives the information about intermediate hops ? Say If it is manually then how the admin sitting at ingress know about the intermediate hop information ? Thanks In Advance regards gopinathg --------------------------------- Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience --0-73450008-1021531046=:78057 Content-Type: text/html; charset=us-ascii

Hi

 I have some questions abt cr-ldp configuration....

How crldp knows about its intermediate hops ? / How the ERHOP's are filled in request message ?

Does any protocol gives the information about intermediate hops ? Say If it is manually then how the admin sitting at ingress know about the intermediate hop information ?

Thanks In Advance

regards

gopinathg

 

 

 

 


Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience --0-73450008-1021531046=:78057-- From owner-mpls@UU.NET Thu May 16 14:52:15 2002 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 OAA06178 for ; Thu, 16 May 2002 14:52:15 -0400 (EDT) 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 QQmpdb27673; Thu, 16 May 2002 18:51:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpdb18369 for mpls-outgoing; Thu, 16 May 2002 18:51: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 QQmpdb18362 for ; Thu, 16 May 2002 18:51:26 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 QQmpdb21220 for ; Thu, 16 May 2002 18:51:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmpdb09384 for ; Thu, 16 May 2002 18:51:02 GMT 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 OAA07606 for ; Thu, 16 May 2002 14:51:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA26683 for mpls@uu.net; Thu, 16 May 2002 14:51:02 -0400 (EDT) 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 QQmpdb18327 for ; Thu, 16 May 2002 18:50:24 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 QQmpdb13293 for ; Thu, 16 May 2002 18:48:05 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQmpdb02646 for ; Thu, 16 May 2002 18:48:04 GMT Received: from FLEFAUCH-W2K.cisco.com (sjc-vpn2-780.cisco.com [10.21.115.12]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA13564; Thu, 16 May 2002 20:47:59 +0200 (MET DST) Message-Id: <4.3.2.7.2.20020516204507.01d47b58@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 16 May 2002 20:46:27 +0200 To: David Charlap From: Francois Le Faucheur Subject: Re: RSVP-TE: DIFFSERV object class Cc: mpls@UU.NET In-Reply-To: <3CD81561.9D7D43AE@marconi.com> References: <4.3.2.7.2.20020507184352.01c69210@europe.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 13:56 07/05/2002 -0400, David Charlap wrote: >Thanks much. I assume that the number will be in the next rev of the >draft, if there is another one before it is released as an RFC, right? It is about to be released as an RFC and it specifies these IANA numbers. Cheers Francois >-- David > > >Francois Le Faucheur wrote: > > > > Hi, > > > > At 10:30 17/04/2002 -0400, David Charlap wrote: > > >The diff-ext draft still lists the class number for the DIFFSERV object > > >as "TBD". > > > > > >Is there any particular class number that people are using for their > > >products while waiting for an IANA-assigned number? > > > > > >-- David > > > > IANA has completed assigment of RSVP numbers required for "MPLS Support of > > Diff-Serv". > > Those can be found at : > > http://www.iana.org/assignments/rsvp-parameters > > > > The DIFF-SERV Class-num is 65. > > > > Cheers > > > > Francois From owner-mpls@UU.NET Thu May 16 16:33:23 2002 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 QAA10039 for ; Thu, 16 May 2002 16:33:23 -0400 (EDT) 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 QQmpdi19014; Thu, 16 May 2002 20:32:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpdi09967 for mpls-outgoing; Thu, 16 May 2002 20:32: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 QQmpdi09962 for ; Thu, 16 May 2002 20:32:00 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 QQmpdi01727 for ; Thu, 16 May 2002 20:31:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmpdi14371 for ; Thu, 16 May 2002 20:31:02 GMT 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 QAA18045 for ; Thu, 16 May 2002 16:31:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA06667 for mpls@uu.net; Thu, 16 May 2002 16:31:02 -0400 (EDT) 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 QQmpdi09730 for ; Thu, 16 May 2002 20:30:04 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 QQmpdh14792 for ; Thu, 16 May 2002 20:29:37 GMT Received: from netreference.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netreference.com [209.246.37.190]) id QQmpdh01277 for ; Thu, 16 May 2002 20:29:37 GMT Received: from ILAZAR.mplsrc.com (209.246.37.179) by netreference.com with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 16 May 2002 04:32:10 -0400 Message-Id: <5.1.0.14.2.20020516162741.00b1fe30@localhost> X-Sender: ilazar/mplsrc.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 16 May 2002 16:29:50 -0400 To: mpls-ops@mplsrc.com, gmpls-ops@mplsrc.com, mpls@UU.NET From: Irwin Lazar Subject: MPLScon Fall 2002, Call for Presentations Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk MPLScon Fall 2002 will be held October 7-10 in Denver, CO. We are actively seeking those able to share their operational experiences with MPLS, as well as those interested in speaking on emerging technologies and trends. A "Call for Presentations" is now available at http://www.mplscon.com/speaker/submit_pres.html Please contact me directly if you have any questions. Irwin ilazar@mplscon.com From owner-mpls@UU.NET Fri May 17 00:27:03 2002 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 AAA23335 for ; Fri, 17 May 2002 00:27:03 -0400 (EDT) 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 QQmpen16865; Fri, 17 May 2002 04:26:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpen11434 for mpls-outgoing; Fri, 17 May 2002 04:26: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 QQmpen11427 for ; Fri, 17 May 2002 04:26:26 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 QQmpen20410 for ; Fri, 17 May 2002 04:26:03 GMT Received: from web21508.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web21508.mail.yahoo.com [66.163.169.19]) id QQmpen12697 for ; Fri, 17 May 2002 04:26:02 GMT Message-ID: <20020517042602.6405.qmail@web21508.mail.yahoo.com> Received: from [128.107.253.37] by web21508.mail.yahoo.com via HTTP; Thu, 16 May 2002 21:26:02 PDT Date: Thu, 16 May 2002 21:26:02 -0700 (PDT) From: srinivasa gopinath gadamsetty Subject: Re:crldp er hops To: mpls@UU.NET MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-911481224-1021609562=:4779" Sender: owner-mpls@UU.NET Precedence: bulk --0-911481224-1021609562=:4779 Content-Type: text/plain; charset=us-ascii Hi I forgot to mention that the following LSP is with TE parameters. >Hi >I have some questions abt cr-ldp configuration.... >How crldp knows about its intermediate hops ? / How the ERHOP's are filled in request message ? >Does any protocol gives the information about intermediate hops ? Say If it is manually then how the admin sitting at ingress know about >the intermediate hop information ? >Thanks In Advance >regards >gopinathg --------------------------------- Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience --0-911481224-1021609562=:4779 Content-Type: text/html; charset=us-ascii

Hi

 I forgot to mention that the following LSP is with TE parameters.

>Hi

 >I have some questions abt cr-ldp configuration....

>How crldp knows about its intermediate hops ? / How the ERHOP's are filled in request message ?

>Does any protocol gives the information about intermediate hops ? Say If it is manually then how the admin sitting at ingress know about >the intermediate hop information ?

>Thanks In Advance

>regards

>gopinathg


Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience --0-911481224-1021609562=:4779-- From owner-mpls@UU.NET Fri May 17 07:28:08 2002 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 HAA08565 for ; Fri, 17 May 2002 07:28:08 -0400 (EDT) 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 QQmpfp28261; Fri, 17 May 2002 11:27:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpfp16630 for mpls-outgoing; Fri, 17 May 2002 11:27:20 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 QQmpfp16617 for ; Fri, 17 May 2002 11:27:14 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 QQmpfp27225 for ; Fri, 17 May 2002 11:27:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmpfp04301 for ; Fri, 17 May 2002 11:27:02 GMT 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 HAA23100 for ; Fri, 17 May 2002 07:27:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA03411 for mpls@uu.net; Fri, 17 May 2002 07:27:01 -0400 (EDT) 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 QQmpfp16571 for ; Fri, 17 May 2002 11:26:13 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 QQmpfp24658 for ; Fri, 17 May 2002 11:25:58 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 QQmpfp02910 for ; Fri, 17 May 2002 11:25:58 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08310; Fri, 17 May 2002 07:25:36 -0400 (EDT) Message-Id: <200205171125.HAA08310@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-bundle-02.txt Date: Fri, 17 May 2002 07:25:36 -0400 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 : Link Bundling in MPLS Traffic Engineering Author(s) : K. Kompella, Y. Rekhter, L. Berger Filename : draft-ietf-mpls-bundle-02.txt Pages : 9 Date : 16-May-02 For the purpose of GMPLS signaling in certain cases a combination of is not sufficient to unambiguously identify the appropriate resource used by an LSP. Such cases are handled by using the link bundling construct which is described in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-02.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-bundle-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-bundle-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020516145517.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-bundle-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-bundle-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020516145517.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri May 17 07:28:18 2002 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 HAA08583 for ; Fri, 17 May 2002 07:28:18 -0400 (EDT) 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 QQmpfp04989; Fri, 17 May 2002 11:27:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpfp16626 for mpls-outgoing; Fri, 17 May 2002 11:27:16 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 QQmpfp16614 for ; Fri, 17 May 2002 11:27: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 QQmpfp10343 for ; Fri, 17 May 2002 11:27:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmpfp04303 for ; Fri, 17 May 2002 11:27:02 GMT 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 HAA23101 for ; Fri, 17 May 2002 07:27:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA03412 for mpls@uu.net; Fri, 17 May 2002 07:27:01 -0400 (EDT) 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 QQmpfp16583 for ; Fri, 17 May 2002 11:26: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 QQmpfp04689 for ; Fri, 17 May 2002 11:26:06 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 QQmpfp03118 for ; Fri, 17 May 2002 11:26:05 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08350; Fri, 17 May 2002 07:25:49 -0400 (EDT) Message-Id: <200205171125.HAA08350@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-rsvp-unnum-06.txt Date: Fri, 17 May 2002 07:25:49 -0400 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 : Signalling Unnumbered Links in RSVP-TE Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-mpls-rsvp-unnum-06.txt Pages : 8 Date : 16-May-02 Current signalling used by MPLS TE doesn't provide support for unnumbered links. This document defines procedures and extensions to RSVP-TE, one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-unnum-06.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-rsvp-unnum-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-rsvp-unnum-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020516145539.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-unnum-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-unnum-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020516145539.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri May 17 07:28:18 2002 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 HAA08587 for ; Fri, 17 May 2002 07:28:18 -0400 (EDT) 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 QQmpfp27861; Fri, 17 May 2002 11:27:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpfp16627 for mpls-outgoing; Fri, 17 May 2002 11:27:16 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 QQmpfp16615 for ; Fri, 17 May 2002 11:27: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 QQmpfp10349 for ; Fri, 17 May 2002 11:27:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmpfp04304 for ; Fri, 17 May 2002 11:27:02 GMT 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 HAA23103 for ; Fri, 17 May 2002 07:27:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA03423 for mpls@uu.net; Fri, 17 May 2002 07:27:02 -0400 (EDT) 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 QQmpfp16584 for ; Fri, 17 May 2002 11:26: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 QQmpfp04384 for ; Fri, 17 May 2002 11:25:59 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 QQmpfp02932 for ; Fri, 17 May 2002 11:25:59 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08330; Fri, 17 May 2002 07:25:43 -0400 (EDT) Message-Id: <200205171125.HAA08330@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-crldp-unnum-06.txt Date: Fri, 17 May 2002 07:25:42 -0400 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 : Signalling Unnumbered Links in CR-LDP Author(s) : K. Kompella, Y. Rekhter, A. Kullberg Filename : draft-ietf-mpls-crldp-unnum-06.txt Pages : 7 Date : 16-May-02 Current signalling used by MPLS TE doesn't provide support for unnumbered links. This document defines procedures and extensions to CR-LDP, one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-crldp-unnum-06.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-crldp-unnum-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-crldp-unnum-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020516145528.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-crldp-unnum-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-crldp-unnum-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020516145528.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri May 17 09:46:31 2002 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 JAA13742 for ; Fri, 17 May 2002 09:46:30 -0400 (EDT) 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 QQmpet03883; Fri, 17 May 2002 05:50:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpet09658 for mpls-outgoing; Fri, 17 May 2002 05:50: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 QQmpet09651 for ; Fri, 17 May 2002 05:50:07 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 QQmpet13999 for ; Fri, 17 May 2002 05:49:29 GMT Received: from tomp.smb.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQmpet02368 for ; Fri, 17 May 2002 05:49:28 GMT Received: from utfors.se ([172.20.0.119]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id GW8R2B00.A6X; Fri, 17 May 2002 07:54:11 +0200 Message-ID: <3CE499E6.8030400@utfors.se> Date: Fri, 17 May 2002 07:49:26 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mpls wg , Scott Bradner , Bert Wijnen , George Swallow Subject: WG Last call - draft-ietf-mpls-bundle-mib-01.txt - ended References: <3CCE5E74.9070207@utfors.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit The WG last call on: Link Bundling Management Information Base has ended! /Loa -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Fri May 17 11:28:07 2002 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 LAA17525 for ; Fri, 17 May 2002 11:28:07 -0400 (EDT) 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 QQmpgf29555; Fri, 17 May 2002 15:27:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpgf03978 for mpls-outgoing; Fri, 17 May 2002 15:27: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 QQmpgf03973 for ; Fri, 17 May 2002 15:27: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 QQmpgf16370 for ; Fri, 17 May 2002 15:27:06 GMT Received: from penguin.wise.edt.ericsson.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: penguin-ext.wise.edt.ericsson.se [193.180.251.47]) id QQmpgf08400 for ; Fri, 17 May 2002 15:27:05 GMT Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4HFR4s7015281 for ; Fri, 17 May 2002 17:27:04 +0200 (MEST) Received: FROM esealnt745.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri May 17 17:23:07 2002 +0200 Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 17:26:40 +0200 Message-ID: <7090FF16C5C81D4FB833E345EC203ABC1B841F@eitrmnt105.tei.ericsson.se> From: "Paola Iovanna (ERI)" To: mpls@UU.NET Subject: RSVP-TE: Bandwidth decrease modify Date: Fri, 17 May 2002 17:26:23 +0200 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 All! I'd like to know more information about how RSVP-TE performs bandwith decrease modify in a MPLS scenario. It is clear the procedure followed in order to perform bandwidth increase while it is not clear how it is released the bandwidth in case of bandwidth decrease. Thank you! Paola From owner-mpls@UU.NET Fri May 17 19:02:53 2002 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 TAA11339 for ; Fri, 17 May 2002 19:02:53 -0400 (EDT) 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 QQmphk02062; Fri, 17 May 2002 23:02:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQmphk23460 for mpls-outgoing; Fri, 17 May 2002 23:02: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 QQmphk23445 for ; Fri, 17 May 2002 23:02:15 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 QQmphk07465 for ; Fri, 17 May 2002 23:02:15 GMT Received: from RS-SC-EXC4.rs.riverstonenet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host60.riverstonenet.com [64.95.122.60] (may be forged)) id QQmphk17498 for ; Fri, 17 May 2002 23:02:14 GMT content-class: urn:content-classes:message Subject: RSVP restart MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Date: Fri, 17 May 2002 16:01:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <10169FC9AB71D940902FE7EBE7109AA909C531@rs-sc-exc4.rs.riverstonenet.com> Thread-Topic: RSVP restart Thread-Index: AcH99pmrWNNU5OqkRBK3OGWwOvJ23w== From: "Ray Qiu" To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA11339 Hi, It seems that the Pan RSVP restart draft expired. Does it mean people should use the state recovery proposal in the GMPLS RSVP-TE draft? Thanks, Ray From owner-mpls@UU.NET Fri May 17 19:12:35 2002 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 TAA11661 for ; Fri, 17 May 2002 19:12:35 -0400 (EDT) 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 QQmphk25300; Fri, 17 May 2002 23:12:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQmphk04632 for mpls-outgoing; Fri, 17 May 2002 23:11: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 QQmphk04627 for ; Fri, 17 May 2002 23:11:55 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 QQmphk09986 for ; Fri, 17 May 2002 23:11:12 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 QQmphk29284 for ; Fri, 17 May 2002 23:11:12 GMT Received: from juniper.net (panther.juniper.net [172.17.12.226]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4HNBBR71066; Fri, 17 May 2002 16:11:11 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3CE58E0F.8070205@juniper.net> Date: Fri, 17 May 2002 16:11:11 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20011222 X-Accept-Language: en-us MIME-Version: 1.0 To: Ray Qiu CC: mpls@UU.NET Subject: Re: RSVP restart References: <10169FC9AB71D940902FE7EBE7109AA909C531@rs-sc-exc4.rs.riverstonenet.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yes. Ray Qiu wrote: > Hi, > > It seems that the Pan RSVP restart draft expired. > Does it mean people should use the state recovery proposal in > the GMPLS RSVP-TE draft? > > Thanks, > Ray > > From owner-mpls@UU.NET Sun May 19 13:34:22 2002 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 NAA14983 for ; Sun, 19 May 2002 13:34:22 -0400 (EDT) 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 QQmpny11686; Sun, 19 May 2002 17:33:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpny04525 for mpls-outgoing; Sun, 19 May 2002 17:33:42 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 QQmpny04520 for ; Sun, 19 May 2002 17:33: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 QQmpny27295 for ; Sun, 19 May 2002 17:33:31 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 QQmpny11135 for ; Sun, 19 May 2002 17:33:30 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4JHXTR60924 for ; Sun, 19 May 2002 10:33:30 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205191733.g4JHXTR60924@merlot.juniper.net> To: mpls@UU.NET Subject: draft-ietf-mpls-bundle-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71211.1021829609.1@juniper.net> Date: Sun, 19 May 2002 10:33:29 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Folks, The revised text has minor editorial changes to improve consistency in terminology, and also split the reference section into normative and non-normative. Yakov. ------- Forwarded Message Date: Fri, 17 May 2002 07:25:36 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce:; cc: mpls@UU.NET Subject: I-D ACTION:draft-ietf-mpls-bundle-02.txt - --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 : Link Bundling in MPLS Traffic Engineering Author(s) : K. Kompella, Y. Rekhter, L. Berger Filename : draft-ietf-mpls-bundle-02.txt Pages : 9 Date : 16-May-02 For the purpose of GMPLS signaling in certain cases a combination of is not sufficient to unambiguously identify the appropriate resource used by an LSP. Such cases are handled by using the link bundling construct which is described in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-02.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-bundle-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-bundle-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020516145517.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-bundle-02.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-bundle-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020516145517.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message From owner-mpls@UU.NET Sun May 19 13:36:11 2002 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 NAA15057 for ; Sun, 19 May 2002 13:36:10 -0400 (EDT) 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 QQmpny19564; Sun, 19 May 2002 17:35:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpny04622 for mpls-outgoing; Sun, 19 May 2002 17:35:26 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 QQmpny04611 for ; Sun, 19 May 2002 17:35:21 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 QQmpny09646 for ; Sun, 19 May 2002 17:34:47 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 QQmpny13188 for ; Sun, 19 May 2002 17:34:46 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4JHYkR60947 for ; Sun, 19 May 2002 10:34:46 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205191734.g4JHYkR60947@merlot.juniper.net> To: mpls@UU.NET Subject: draft-ietf-mpls-crldp-unnum-06.tx MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71443.1021829686.1@juniper.net> Date: Sun, 19 May 2002 10:34:46 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Folks, The revised draft split the reference section into normative and non-normative. Yakov. ------- Forwarded Message Date: Fri, 17 May 2002 07:25:42 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce:; cc: mpls@UU.NET Subject: I-D ACTION:draft-ietf-mpls-crldp-unnum-06.txt - --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 : Signalling Unnumbered Links in CR-LDP Author(s) : K. Kompella, Y. Rekhter, A. Kullberg Filename : draft-ietf-mpls-crldp-unnum-06.txt Pages : 7 Date : 16-May-02 Current signalling used by MPLS TE doesn't provide support for unnumbered links. This document defines procedures and extensions to CR-LDP, one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-crldp-unnum-06.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-crldp-unnum-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-crldp-unnum-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020516145528.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-crldp-unnum-06.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-crldp-unnum-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020516145528.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message From owner-mpls@UU.NET Sun May 19 13:36:53 2002 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 NAA15085 for ; Sun, 19 May 2002 13:36:53 -0400 (EDT) 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 QQmpny29662; Sun, 19 May 2002 17:36:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpny04851 for mpls-outgoing; Sun, 19 May 2002 17:36: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 QQmpny04831 for ; Sun, 19 May 2002 17:36: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 QQmpny02517 for ; Sun, 19 May 2002 17:35:39 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 QQmpny14390 for ; Sun, 19 May 2002 17:35:38 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4JHZcR60972 for ; Sun, 19 May 2002 10:35:38 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205191735.g4JHZcR60972@merlot.juniper.net> To: mpls@UU.NET Subject: draft-ietf-mpls-rsvp-unnum-06.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71563.1021829738.1@juniper.net> Date: Sun, 19 May 2002 10:35:38 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Folks, The revised text split the reference section into normative and non-normative. Yakov. ------- Forwarded Message Date: Fri, 17 May 2002 07:25:49 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce:; cc: mpls@UU.NET Subject: I-D ACTION:draft-ietf-mpls-rsvp-unnum-06.txt - --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 : Signalling Unnumbered Links in RSVP-TE Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-mpls-rsvp-unnum-06.txt Pages : 8 Date : 16-May-02 Current signalling used by MPLS TE doesn't provide support for unnumbered links. This document defines procedures and extensions to RSVP-TE, one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-unnum-06.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-rsvp-unnum-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-rsvp-unnum-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020516145539.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-unnum-06.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-unnum-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020516145539.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message From owner-mpls@UU.NET Mon May 20 16:15:36 2002 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 QAA07035 for ; Mon, 20 May 2002 16:15:36 -0400 (EDT) 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 QQmpsb29914; Mon, 20 May 2002 20:15:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpsa28628 for mpls-outgoing; Mon, 20 May 2002 20:14:47 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 QQmpsa28623 for ; Mon, 20 May 2002 20:14:43 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 QQmpsa01025 for ; Mon, 20 May 2002 20:14:12 GMT Received: from Mail.TRINICOM.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.149.136.4]) id QQmpsa15153 for ; Mon, 20 May 2002 20:14:12 GMT Date: Mon, 20 May 2002 15:12:59 -0500 Message-Id: <200205201512.AA549454088@Mail.TRINICOM.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Sean Crocker" Reply-To: To: , "Paola Iovanna " Subject: Re: RSVP-TE: Bandwidth decrease modify X-Mailer: Sender: owner-mpls@UU.NET Precedence: bulk Paola, >Hi All! >I'd like to know more information about how RSVP-TE performs bandwith decrease modify in a MPLS scenario. It is clear the procedure followed in order to perform bandwidth increase while it is not clear how it is released the bandwidth in case of bandwidth decrease. It should be the same as bandwidth increase as defined in RFC3209 section 4.6.4, except it's asking for less bandwidth in the PATH with the new LSPIP. If the ingress implementation is done right, it should wait either x seconds after the new tunnel is fully established, or x number of RESVs come back for the new tunnel. Then it could either stop sending PATH for the old tunnel, or even better send a PATHTEAR for it. Either way, all nodes from ingress to egress will then have the smaller bandwidth in their state blocks for the session. Sean From owner-mpls@UU.NET Mon May 20 16:29:11 2002 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 QAA08245 for ; Mon, 20 May 2002 16:29:11 -0400 (EDT) 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 QQmpsb13795; Mon, 20 May 2002 20:28:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpsb29891 for mpls-outgoing; Mon, 20 May 2002 20:28: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 QQmpsb29883 for ; Mon, 20 May 2002 20:28:20 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 QQmpsb11520 for ; Mon, 20 May 2002 20:27:09 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 QQmpsb11644 for ; Mon, 20 May 2002 20:27:09 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 QAA22601 for ; Mon, 20 May 2002 16:27:06 -0400 (EDT) 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 QAA06010 for ; Mon, 20 May 2002 16:27:08 -0400 (EDT) Message-ID: <3CE95C35.C8B8196A@marconi.com> Date: Mon, 20 May 2002 16:27:33 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: RSVP-TE: Bandwidth decrease modify Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Paola Iovanna (ERI)" wrote: > > I'd like to know more information about how RSVP-TE performs > bandwith decrease modify in a MPLS scenario. It is clear the > procedure followed in order to perform bandwidth increase while it > is not clear how it is released the bandwidth in case of bandwidth > decrease. Same way as an increase. One of two mechanisms: 1: Have the ingress change the TSPEC it sends. This should propagate through the network and result in an updated FLOWSPEC propagating back in Resv messages. When the bandwidth is decreasing, you'll probably see a quicker response, since RSVP implementations usually clip the FLOWSPEC to the level of the TSPEC. It should work fine, assuming the router allows LSP modification in the first place. 2: Make-before-break. Signal a new LSP with a different LSP ID. Use SE style to share resources with the old one. Once you get the Resv back for the new LSP, cut your traffic over to the new one and tear the old one. -- David From owner-mpls@UU.NET Mon May 20 22:41:33 2002 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 WAA01758 for ; Mon, 20 May 2002 22:41:33 -0400 (EDT) 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 QQmprv01459; Mon, 20 May 2002 18:57:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmprv08888 for mpls-outgoing; Mon, 20 May 2002 18:56:50 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 QQmprv08883 for ; Mon, 20 May 2002 18:56: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 QQmprv05923 for ; Mon, 20 May 2002 18:56:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmprv29609 for ; Mon, 20 May 2002 18:56:02 GMT 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 OAA18708 for ; Mon, 20 May 2002 14:56:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA01105 for mpls@uu.net; Mon, 20 May 2002 14:56:02 -0400 (EDT) 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 QQmprv08508 for ; Mon, 20 May 2002 18:54: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 QQmprv18439 for ; Mon, 20 May 2002 18:53:59 GMT Received: from ihemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQmprv20467 for ; Mon, 20 May 2002 18:53:59 GMT Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4KIrwx01300 for ; Mon, 20 May 2002 14:53:58 -0400 (EDT) Received: from lucent.com (mantegna.ho.lucent.com [135.17.34.61]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA04663; Mon, 20 May 2002 14:53:52 -0400 (EDT) Message-ID: <3CE9464B.ABBA5D76@lucent.com> Date: Mon, 20 May 2002 14:54:03 -0400 From: "Denis A. Khotimsky" Reply-To: dkhotimsky@lucent.com Organization: Bell Labs -- Lucent Technologies, USA X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: CFP: IEEE Communications issue on IP-Oriented QoS [***NEW DEADLINES!***] Content-Type: multipart/mixed; boundary="------------3702B290A991629C7692E0B6" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------3702B290A991629C7692E0B6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Colleagues: The deadline for original paper submission has been extended from May 31 till July 1. Please consider your contribution and/or distribute to the interested parties within your organization. Our apologies if you receive multiple copies of this announcement. Best regards, -dkh --------------3702B290A991629C7692E0B6 Content-Type: text/plain; charset=us-ascii; name="ComMag-Dec02-CFP-ex2.txt" Content-Disposition: inline; filename="ComMag-Dec02-CFP-ex2.txt" Content-Transfer-Encoding: 7bit CALL FOR PAPERS IEEE Communications Magazine Feature Topic on IP-Oriented Quality of Service (QoS) The "best effort" Internet delivery cannot be used for the new multimedia applications. New technologies and new standards are necessary to offer Quality of Service (QoS) for these multimedia applications. Therefore new communication architectures integrate mechanisms allowing to guarantee QoS services as well as high rate for the communications. This special issue of IEEE Communications Magazine seeks to survey and present the research and engineering work in QoS field. The focused tutorial and survey contributions are solicited on (but not restricted to) the following subject categories: * QoS in heterogeneous networks * QoS for wireless and mobile * QoS in WAN * QoS routing * Experiences with QoS * Simulation models for QoS * QoS and metrics * Charging and pricing for QoS * Platform support for QoS * Standardization and QoS Submission Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for clarity and grammatical accuracy, and will be copyedited according to the Magazine's style. Mathematical equations should not be used (in justified cases up to three simple equations could be allowed, provided the consent of the Guest Editor; more than three equations require permission from the Editor-in-Chief). Articles should have no more than 4,500 words, no more than 6 tables+figures, and no more than 15 references. Guidelines for prospective authors can be found on-line at http://www.comsoc.org/pubs/commag/sub_guidelines.html. Please send PDF (preferred), Microsoft Word, or PostScript formatted papers to one of the guest editors no later than July 1, 2002. Accepted papers will also be included in Communications Interactive (CI), the online version of Communications Magazine. Manuscript Due 1 July 2002 Acceptance Notification 15 August 2002 Final Manuscript Due 15 September 2002 Publication Date December 2002 Guest Editors Pascal Lorenz Universite de Haute Alsace IUT de Colmar 34 rue du Grillenbreit - 68008 Colmar - FRANCE Phone: +33 3 89 20 23 66 Fax: +33 3 89 20 23 59 Email: lorenz@ieee.org Abbas Jamalipour School of Electrical and Information Engineering University of Sydney Sydney NSW 2006, Australia Phone: +61 2 9351 2843 Fax: +61 2 9351 3847 Email: a.jamalipour@ieee.org Denis Khotimsky Lucent Bell Labs 101 Crawfords Corner Road Holmdel, New Jersey 07733-3030 USA Phone: +1-732-949-9673 Fax: +1-732-949-5477 Email: dkhotimsky@lucent.com --------------3702B290A991629C7692E0B6-- From owner-mpls@UU.NET Tue May 21 07:49:46 2002 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 HAA05558 for ; Tue, 21 May 2002 07:49:46 -0400 (EDT) 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 QQmpuk03253; Tue, 21 May 2002 11:33:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpuk06814 for mpls-outgoing; Tue, 21 May 2002 11:33:48 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 QQmpuk06806 for ; Tue, 21 May 2002 11:33: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 QQmpuk16119 for ; Tue, 21 May 2002 11:33:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmpuk01860 for ; Tue, 21 May 2002 11:33:02 GMT 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 HAA28774 for ; Tue, 21 May 2002 07:33:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA05295 for mpls@uu.net; Tue, 21 May 2002 07:33:02 -0400 (EDT) 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 QQmpuk06759 for ; Tue, 21 May 2002 11:32:09 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 QQmpuk23770 for ; Tue, 21 May 2002 11:31:45 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 QQmpuk15836 for ; Tue, 21 May 2002 11:31:45 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05056; Tue, 21 May 2002 07:31:27 -0400 (EDT) Message-Id: <200205211131.HAA05056@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-bundle-03.txt Date: Tue, 21 May 2002 07:31:26 -0400 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 : Link Bundling in MPLS Traffic Engineering Author(s) : K. Kompella, Y. Rekhter, L. Berger Filename : draft-ietf-mpls-bundle-03.txt Pages : 9 Date : 20-May-02 For the purpose of GMPLS signaling in certain cases a combination of is not sufficient to unambiguously identify the appropriate resource used by an LSP. Such cases are handled by using the link bundling construct which is described in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-03.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-bundle-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-bundle-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020520143404.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-bundle-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-bundle-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020520143404.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue May 21 09:36:13 2002 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 JAA09978 for ; Tue, 21 May 2002 09:36:13 -0400 (EDT) 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 QQmpus19427; Tue, 21 May 2002 13:35:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpus29875 for mpls-outgoing; Tue, 21 May 2002 13:35:11 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 QQmpus29870 for ; Tue, 21 May 2002 13:35:08 GMT Received: from pmismtp06.wcomnet.com by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pmismtp06.wcomnet.com [166.38.62.54]) id QQmpus18717 for ; Tue, 21 May 2002 13:34:57 GMT Received: from CONVERSION-DAEMON.pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) id <0GWG00A01QZSG2@pmismtp06.wcomnet.com> for mpls@UU.NET; Tue, 21 May 2002 13:34:57 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GWG00A01R13J5@pmismtp06.wcomnet.com> for mpls@UU.NET; Tue, 21 May 2002 13:34:57 +0000 (GMT) Received: from dmcdysan ([166.32.198.25]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GWG00A54R29DJ@pmismtp06.wcomnet.com>; Tue, 21 May 2002 13:34:57 +0000 (GMT) Date: Tue, 21 May 2002 09:36:45 -0400 From: Dave McDysan Subject: MPLS 2002: Oct. 27-29, Washington D.C. To: Ppvpn , Ccamp , Mpls , Pwe3 Cc: TPC@mpls2002.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dear Colleagues, The MPLS 2002 Conference will be held in Washington D.C. from October 27 through October 29. See www.mpls2002.com for more information. A group of industry experts on the Technical Program Committee is soliciting presentation proposals for this conference. If you wish to suggest a particular topic or a contribution please send a brief proposal to the attention of the Technical Program Committee atTPC@mpls2002.com by June 21, 2002. See above web site for more details. The program committee is looking for original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting edge topics. They are solicting presentations from both the vendor and service provider community on new technologies and operational experience. Regards, David E. McDysan WorldCom From owner-mpls@UU.NET Tue May 21 09:41:27 2002 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 JAA10219 for ; Tue, 21 May 2002 09:41:27 -0400 (EDT) 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 QQmpus27395; Tue, 21 May 2002 13:41:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpus00325 for mpls-outgoing; Tue, 21 May 2002 13:40: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 QQmpus00320 for ; Tue, 21 May 2002 13:40: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 QQmpus03062 for ; Tue, 21 May 2002 13:39:32 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmpus06595 for ; Tue, 21 May 2002 13:39:31 GMT 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 JAA05541 for ; Tue, 21 May 2002 09:39:31 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA18426 for mpls@uu.net; Tue, 21 May 2002 09:39:31 -0400 (EDT) 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 QQmpuq27074 for ; Tue, 21 May 2002 13:08:34 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 QQmpuq27582 for ; Tue, 21 May 2002 13:08:29 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 QQmpuq00186 for ; Tue, 21 May 2002 13:08:27 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/01/31/02) with ESMTP id WAA07878; Tue, 21 May 2002 22:07:57 +0900 (JST) (envelope-from ohta.hiroshi@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g4LD7uxV027969; Tue, 21 May 2002 22:07:56 +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.2/8.12.2) with ESMTP id g4LD7uuu019184; Tue, 21 May 2002 22:07:56 +0900 (JST) Received: from imf.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 WAA04161; Tue, 21 May 2002 22:07:55 +0900 (JST) Received: from HIROSHI-TP2 by imf.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id WAA28106; Tue, 21 May 2002 22:07:54 +0900 (JST) Message-Id: <4.2.0.58.J.20020521215209.0335e4f0@imf.m.ecl.ntt.co.jp> X-Sender: ho016@imf.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Tue, 21 May 2002 22:06:22 +0900 To: Scott Bradner , mpls@UU.NET From: Hiroshi Ohta Subject: Re: response to SG 13 Cc: bwijnen@lucent.com In-Reply-To: <200204291852.g3TIqLo08854@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Scott and all, The following text has been prepared by the email discussion group of ITU-T SG13/Q3 in response to IETF's request for explanation of the long-term implications of Y.1711 on IETF protocols. I post it on behalf of the group because I think it is useful to know your views on this response before ITU-T SG13/Q3 drafts an official response. Based on this text, an official response from ITU-T SG13/Question 3 will be prepared at the next Q3 meeting to be held 3-5 July 2002 in Chitose, Japan. Hiroshi *************************************************** Summary: Y.1711 depends on the reserved MPLS label (14) in order to operate, and this was the only method that did not raise any objections when discussed on the MPLS list over a year ago. Any other extension to IETF protocols is purely optional and not essential for the operation of Y.1711 and require further technical study as well as usability assessment. In any case such extensions are not targeted to the current revision of the Y.1711. Details: The MPLS OAM, as defined in Y.1711, has the following requirements: 1) Identification of OAM packets: A reserved MPLS label (suggested label=14) is REQUIRED for the identification of OAM packets. Without this reserved Label, it is not possible to implement Y.1711. Note that this was discussed on the MPLS list over a year ago and the consensus for OAM packet identification was to use a globally reserved label. 2) Activation/Set up of the Connectivity Verification (CV) processing: Running and monitoring the CV flow on any specific LSP is optional in Y.1711. Since the CV processing is done at the egress LSR, it needs to know whether to look for CV packets on a specific LSP or not. On the other hand there are a number of different CV processing options that may be done at an egress LSR (see appendix I of Y.1711). Currently Y.1711 relies on manual configuration of the egress LSR for setting up the CV processing function. Manual configuration of the egress LSR is currently sufficient for the current version of Y.1711. In future it may be desired to use signaling methods to setup the CV processing at an egress LSR for a specific LSP. The key point here is that OAM activation/deactivation needs to be harmonized with any control-plane set-up/tear-down of LSPs, e.g. to stop OAM processing, and hence consequent action such as alarm generation, when an LSP is consciously removed. The methods to achieve this could be: a) OPTIONAL extension to RSVP-TE and CR-LDP. b) Defining new setup OAM packets using the OAM reserved label (14) c) Configuration via NMS. 3) Knowledge of Server-Client relationship: For the purpose of suppressing down-stream alarms, the FDI (Forward Defect Identifier) must be mapped from a lower layer LSP to a higher layer LSP at the egress LSR. Therefore the egress LSR needs to know which LSPs are tunneled inside a specific LSP. Currently Y.1711 relies on two possible methods for setting up the client-server relationship between LSPs: a) Manual configuration of the egress LSR b) Automatic learning process: If during the establishment of the client LSPs, the signaling is tunneled through the server LSP, then the server trail terminating node (egress) could keep the information about the client LSPs in memory as they occur. In future it may be desired to use signaling methods to setup the Server-Client relationship for a specific LSP. The methods to achieve this could be: c) OPTIONAL extension to RSVP-TE and CR-LDP. d) Defining new setup OAM packets using the OAM reserved label (14) e) Configuration via NMS. Other functions such as Performance (P) flows, loop-back, trace-route, variable CV rate, etc are under study and we can't comment on their requirements at this time. It is also far from certain that all these functions would ever be adopted in any case....this will depend on contributions, especially from operators requesting the development of such functions Following are ITU's answers to the specific issues raised in your liaison: A) Section 6.1 issue: The egress LSR needs to know the TTSI for a terminating LSP. According to Y.1711, TTSI = Router_ID + LSP_ID. Both the Router_ID and LSP_ID are already signaled in the existing RSVP-TE and CR-LDP protocols in the form of Session Object and LSPID TLV respectively. Therefore there is no need for further extensions to these protocols to signal the TTSI. B) Impact on IETF protocols: We don't foresee any changes to any other IETF protocol except those noted in this correspondence. Specifically we don't foresee any changes required to BGP and PIM. C) Impact on forwarding plane: There is no requirement in Y.1711 to intercept OAM packets or to inspect subsequent header/label when it should not (such as in PHP case). We feel sure that Y.1711 is fully backward compatible with all MPLS standards. E) Impact on current systems and ASICs: Y.1711 recommendation has been developed based on input from various leading vendors. Whether it is possible to implement Y.1711 in the current systems and ASICs depends on the specific vendor's implementation. If for example a Network processor has been used for the MPLS forwarding plane, Y.1711 could easily be implemented by a firmware/software upgrade. Even in case the MPLS forwarding plane is implemented in ASICs, if the ASIC has the capability to extract/inject MPLS packets with the reserved labels, then the Y.1711 functionality could be supported by upgrade of existing firmware/software. ************************************************* At 14:52 02/04/29 -0400, Scott Bradner wrote: >after reviewing the discussion on the draft response to SG 13 about >draft-ohta-mpls-label-value-01.txt - I simplified the letter and just sent >the following to Brian Moore (SG 13 chair) > >Scott > >------------------ >SOURCE: IETF Sub-IP Area - Scott Bradner, Area co-Director > >TITLE: Response to "Communication on the status of the request on the >assignment of >a reserved label value for MPLS OAM packet identification" > >The MPLS working group discussed SG 13's request for the assignment of a >reserved >label value for MPLS OAM packet identification >(draft-ohta-mpls-label-value-01.txt) >during the MPLS session during the recent IETF meeting in >Minneapolis. There was >some disagreement during the discussion about the long term >implications of the >IETF granting this request. > >During the discussion it was noted that there are a number of references >to what >might be modifications to IETF protocols in Y.1711. For example, Section 6.1 >states, "Ideally this should be done automatically via LSP signaling at >LSP set-up >time (e.g. via a CR-LDP or RSVP control-plane mechanism), but it could >also be >configured manually." > >In order to understand the possible consequences of allocating an MPLS >codepoint in >response to the request in draft-ohta-mpls-label-value-01.txt the MPLS >working group >would like to understand the what modifications that SG13 may be assuming >will be >needed to other IETF protocols. (LDP, CR-LDP, RSVP, PIM and BGP have been >suggested >as IETF protocols that might be impacted.) > >A further concern is the potential impact on the MPLS forwarding plane as >currently >defined. In certain points in a MPLS network, based on an incoming label, >the label >is removed and the packet is forwarded with no further inspection of >subsequent >headers (be it another MPLS label or some other header). Y.1711 seems to >imply that >the above behavior would not satisfy Y.1711. Specifically, there are some >cases >where Y.1711 would expect a network element to intercept an OAM >packet. Thus, the >MPLS working group would like to understand if SG 13 thinks that Y.1711 >assumes >functionally that might raise issues of backward compatibility with >existing MPLS >systems and ASICs. From owner-mpls@UU.NET Tue May 21 13:53:53 2002 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 NAA22109 for ; Tue, 21 May 2002 13:53:53 -0400 (EDT) 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 QQmpvj26003; Tue, 21 May 2002 17:53:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpvj18162 for mpls-outgoing; Tue, 21 May 2002 17:53:00 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 QQmpvj18157 for ; Tue, 21 May 2002 17:52:58 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 QQmpvj27049 for ; Tue, 21 May 2002 17:52:04 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmpvj13812 for ; Tue, 21 May 2002 17:52:03 GMT 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 NAA26330 for ; Tue, 21 May 2002 13:52:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA14225 for mpls@uu.net; Tue, 21 May 2002 13:52:02 -0400 (EDT) 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 QQmpvj18066 for ; Tue, 21 May 2002 17:51: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 QQmpvj23653 for ; Tue, 21 May 2002 17:50:36 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 QQmpvj20174 for ; Tue, 21 May 2002 17:50:35 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 g4LHoWE12918; Tue, 21 May 2002 10:50:32 -0700 (PDT) Message-Id: <200205211750.g4LHoWE12918@gamma.isi.edu> To: IETF-Announce:; Subject: RFC 3270 on Multi-Protocol Label Switching (MPLS) Support of Differentiated Services Cc: rfc-editor@rfc-editor.org, mpls@UU.NET Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 21 May 2002 10:50:32 -0700 From: RFC Editor Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3270 Title: Multi-Protocol Label Switching (MPLS) Support of Differentiated Services Author(s): F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen Status: Standards Track Date: May 2002 Mailbox: flefauch@cisco.com, liwwu@cisco.com, bsd@cisco.com, davari@ieee.org, pasi.vaananen@nokia.com, ram@axiowave.com, pierrick.cheval@space.alcatel.fr, jh@song.fi Pages: 64 Characters: 137960 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-diff-ext-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3270.txt This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. This solution allows the MPLS network administrator to select how Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched Paths (LSPs) so that he/she can best match the Diff-Serv, Traffic Engineering and protection objectives within his/her particular network. For instance, this solution allows the network administrator to decide whether different sets of BAs are to be mapped onto the same LSP or mapped onto separate LSPs. 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: <020521104817.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3270 --OtherAccess Content-Type: Message/External-body; name="rfc3270.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020521104817.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue May 21 15:52:41 2002 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 PAA26752 for ; Tue, 21 May 2002 15:52:40 -0400 (EDT) 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 QQmpvr05915; Tue, 21 May 2002 19:51:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpvr11136 for mpls-outgoing; Tue, 21 May 2002 19:51:36 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 QQmpvr11131 for ; Tue, 21 May 2002 19:51:33 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 QQmpvr26733 for ; Tue, 21 May 2002 19:51:30 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f201.law14.hotmail.com [64.4.21.201]) id QQmpvr21814 for ; Tue, 21 May 2002 19:51:30 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 21 May 2002 12:51:29 -0700 Received: from 198.242.58.71 by lw14fd.law14.hotmail.msn.com with HTTP; Tue, 21 May 2002 19:51:29 GMT X-Originating-IP: [198.242.58.71] From: "Raju Venkatraman" To: mpls@UU.NET Cc: ccamp@ops.ietf.org Subject: IPv6 RSVP Issue Date: Tue, 21 May 2002 19:51:29 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 May 2002 19:51:29.0765 (UTC) FILETIME=[E671F150:01C20100] Sender: owner-mpls@UU.NET Precedence: bulk Hi All, I was wondering whether you are aware of some socket options for IPV6 to intercept RSVP protocol messages with router alert option on Sun-Solaris OS. Any help, pointer would be appreciated. Is there any other way to intercept RSVP IPv6 messages on Sun-Solaris? Thanks in advance. Raju _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-mpls@UU.NET Tue May 21 17:03:24 2002 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 RAA00419 for ; Tue, 21 May 2002 17:03:23 -0400 (EDT) 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 QQmpvw19992; Tue, 21 May 2002 21:02:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpvw16712 for mpls-outgoing; Tue, 21 May 2002 21:02:18 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 QQmpvw16681 for ; Tue, 21 May 2002 21:02:16 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 QQmpvw13463 for ; Tue, 21 May 2002 21:00: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 QQmpvw16723 for ; Tue, 21 May 2002 21:00: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 RAA19844 for ; Tue, 21 May 2002 17:00:14 -0400 (EDT) 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 RAA06076 for ; Tue, 21 May 2002 17:00:10 -0400 (EDT) Message-ID: <3CEAB577.11642A34@marconi.com> Date: Tue, 21 May 2002 17:00:39 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: IPv6 RSVP Issue References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Raju Venkatraman wrote: > > I was wondering whether you are aware of some socket options for > IPV6 to intercept RSVP protocol messages with router alert option > on Sun-Solaris OS. This list's purpose is discussion of the MPLS protocols, not discussions of specific implementations. Your question would be better asked on a list or newsgroup dedicated to Solaris programming, or perhaps general UNIX network programming. The expertise here is mostly in routers, not Solaris. RFC 2711 defines the Router Alert option for IPv6, which is what you need to use if you want to implement RSVP on IPv6, but it's not going to say anything about how a particular operating system may or may not implement it. -- David From owner-mpls@UU.NET Tue May 21 18:58:19 2002 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 SAA04875 for ; Tue, 21 May 2002 18:58:19 -0400 (EDT) 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 QQmpwd29742; Tue, 21 May 2002 22:57:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpwd01535 for mpls-outgoing; Tue, 21 May 2002 22:57: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 QQmpwd01521 for ; Tue, 21 May 2002 22:57:17 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 QQmpwd28892 for ; Tue, 21 May 2002 22:57:05 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmpwd01412 for ; Tue, 21 May 2002 22:57:04 GMT 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 SAA16177 for ; Tue, 21 May 2002 18:57:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA14526 for mpls@uu.net; Tue, 21 May 2002 18:57:04 -0400 (EDT) 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 QQmpwd01457 for ; Tue, 21 May 2002 22:56: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 QQmpwd28062 for ; Tue, 21 May 2002 22:55:04 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 QQmpwd25744 for ; Tue, 21 May 2002 22:55:03 GMT Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.46 2002/05/09 18:12:26 root Exp $) with ESMTP id g4LMta701385 for ; Tue, 21 May 2002 22:55:36 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.20 2002/05/13 20:36:03 root Exp $) with SMTP id g4LMwAr07735 for ; Tue, 21 May 2002 22:58:10 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002052115514221424 ; Tue, 21 May 2002 15:51:43 -0700 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 15:52:26 -0700 Message-ID: From: "Sharma, Prem" To: "'mpls@uu.net'" Cc: "'eric.gray@sandburst.com'" Subject: RFC 3036: Label Mapping Question Date: Tue, 21 May 2002 15:52:26 -0700 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, I've one question on LDP. What should be the behaviour of the LDP module when it receives the label mapping message for a FEC when the label retention mode is liberal and that FEC (e.g. partial IP prefix) is not visible to the local routing module? Should it store the label just received or send out label release message? Here, the routing module just doesn't have any information abt. this IP prefix. On querying, the routing module returns "route not available" or "no information abt. the route". As per the LDP specs., it's implicit/apparent that label distribution entities and routing entities should work in tandem and should remain in synch. So, what should be the behaviour in this special case where LDP sees some FEC but that FEC is not visible to routing entity? The following from RFC 3036, doesn't talk abt. this case explicitly: LMp.12 Is MsgSource the Next Hop for FEC? If so, goto LMp.14. Should the boolean expression in the step mentioned above be considered "FALSE" in this specific scenario? Any response will be greatly appreciated. Thanks. Prem From owner-mpls@UU.NET Wed May 22 09:18:15 2002 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 JAA00436 for ; Wed, 22 May 2002 09:18:15 -0400 (EDT) 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 QQmpyj10996; Wed, 22 May 2002 13:17:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpyj05234 for mpls-outgoing; Wed, 22 May 2002 13:15: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 QQmpyi05139 for ; Wed, 22 May 2002 13:14:58 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 QQmpyi12079 for ; Wed, 22 May 2002 13:14:51 GMT Received: from ariadne.dt.fee.unicamp.br by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dt.fee.unicamp.br [143.106.8.45]) id QQmpyi07784 for ; Wed, 22 May 2002 13:14:50 GMT Received: from calipso.dt.fee.unicamp.br (calipso.dt.fee.unicamp.br [143.106.12.37]) by ariadne.dt.fee.unicamp.br (8.9.3/8.9.3) with ESMTP id KAA09800; Wed, 22 May 2002 10:14:45 -0300 (EST) Date: Wed, 22 May 2002 10:14:45 -0300 (EST) From: Marcos Antonio De Almeida Cora To: mpls@UU.NET, mpls-ops@mplsrc.com Subject: LDP for GMPLS ??? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8BIT Hi all, I'd like to know if anyone have links where I can to find papers and informations about LDP and GMPLS ??? Mainly GMPLS using LDP. I have had difficulties to find these informations. By the way, Which is the protocol of distribution of labels more used in the GMPLS ??? RSVP or LDP ??? It seems me that exist a difficulty in the use of the LDP for GMPLS, Why?? Best Regards, Marcos ______________________________________________________________________ Marcos Antônio de Almeida Corá E-Mail: cora@dt.fee.unicamp.br School of Electrical and Computer Engineering Departament of Telematics State University of Campinas/Brazil - UNICAMP Phone: +55 (19) 3788.3711 - Branch: 73723 Others e-mails: marcoscora@zipmail.com.br , marcos.cora@bol.com.br ______________________________________________________________________ From owner-mpls@UU.NET Wed May 22 09:42:00 2002 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 JAA01551 for ; Wed, 22 May 2002 09:42:00 -0400 (EDT) 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 QQmpyk08442; Wed, 22 May 2002 13:41:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpyk06799 for mpls-outgoing; Wed, 22 May 2002 13:41:18 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 QQmpyk06794 for ; Wed, 22 May 2002 13:41:05 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 QQmpyk16563 for ; Wed, 22 May 2002 13:40:25 GMT Received: from tomp.smb.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQmpyk13237 for ; Wed, 22 May 2002 13:40:24 GMT Received: from tomp.smb.utfors.se ([127.0.0.1]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id GWIM7500.LO1; Wed, 22 May 2002 15:45:05 +0200 From: Loa Andersson To: mpls@UU.NET Cc: , , swallow@cisco.com Message-ID: Date: Wed, 22 May 2002 15:45:05 +0200 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: wg last call on draft-heinanen-inarp-uni-01.txt X-Accept-Language: en Content-Type: multipart/mixed; boundary="--6c96240a2f0a1b59" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ----6c96240a2f0a1b59 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit All, This initiates a two weeks MPLS WG last call on Inverse ARP over Unidirectional Virtual Circuits This draft is not a WG draft, but is being reviewed by the IESG for publication as an Informational RFC. Since the proposal put forward in the draft has applicability in an MPLS context the ADs and chairs has found it appropriate to do a MPLS WG last call on this document. This last call ends on June 5th. Loa and George Disclaimer: This was sent from a webmail system that sometimes do unprerdictable things to mails - excuse me if the mail is "hard to read". /Loa ----6c96240a2f0a1b59 Content-Type: text/x-vcard; name="loa.andersson.vcf"; charset=us-ascii Content-Disposition: attachment; filename="loa.andersson.vc" Content-Description: Card for Loa Andersson Content-Transfer-Encoding: 7bit begin:vcard version:2.1 end:vcard ----6c96240a2f0a1b59-- From owner-mpls@UU.NET Wed May 22 11:00:33 2002 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 LAA06154 for ; Wed, 22 May 2002 11:00:33 -0400 (EDT) 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 QQmpyp02334; Wed, 22 May 2002 14:58:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpyp04739 for mpls-outgoing; Wed, 22 May 2002 14:58: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 QQmpyp04734 for ; Wed, 22 May 2002 14:58:25 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 QQmpyp11702 for ; Wed, 22 May 2002 14:58:18 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmpyp27764 for ; Wed, 22 May 2002 14:58:18 GMT 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 KAA26729 for ; Wed, 22 May 2002 10:58:17 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA15403 for mpls@uu.net; Wed, 22 May 2002 10:58:17 -0400 (EDT) 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 QQmpwn18750 for ; Wed, 22 May 2002 01:28:14 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 QQmpwn06333 for ; Wed, 22 May 2002 01:28:00 GMT Received: from web13402.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13402.mail.yahoo.com [216.136.175.60]) id QQmpwn05742 for ; Wed, 22 May 2002 01:27:59 GMT Message-ID: <20020522012759.34731.qmail@web13402.mail.yahoo.com> Received: from [216.73.180.79] by web13402.mail.yahoo.com via HTTP; Tue, 21 May 2002 18:27:59 PDT Date: Tue, 21 May 2002 18:27:59 -0700 (PDT) From: Gopalkrishna Panicker Subject: MESSAGE_ID in Resv message To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hello, I have a question regarding the use of MESSAGE_ID object in a resv message. Per my understanding of RFC 2209, a Resv state block is created for every {Flowspec, Filterspec(s)}. If a session uses FF style and there are multiple senders, a SINGLE resv message carries a {flowspec,filterspec} set for each sender. This will result in RSB being created for each such set. Now if ROR is used and as only one MESSAGE_ID object is allowed per message, should a separate resv message be sent for each distinct reservation ? Cheers, Gopal __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-mpls@UU.NET Wed May 22 11:11:16 2002 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 LAA07811 for ; Wed, 22 May 2002 11:11:16 -0400 (EDT) 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 QQmpyq06077; Wed, 22 May 2002 15:09:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpyq26714 for mpls-outgoing; Wed, 22 May 2002 15:09:16 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 QQmpyq26699 for ; Wed, 22 May 2002 15:09:03 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 QQmpyq22994 for ; Wed, 22 May 2002 15:07:06 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 QQmpyq01927 for ; Wed, 22 May 2002 15:07:05 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 LAA05596 for ; Wed, 22 May 2002 11:07:02 -0400 (EDT) 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 LAA01542 for ; Wed, 22 May 2002 11:07:03 -0400 (EDT) Message-ID: <3CEBB436.6C766978@marconi.com> Date: Wed, 22 May 2002 11:07:34 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: MESSAGE_ID in Resv message References: <20020522012759.34731.qmail@web13402.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gopalkrishna Panicker wrote: > > Per my understanding of RFC 2209, a Resv state block > is created for every {Flowspec, Filterspec(s)}. If your implementation is based on the architecture that RFC 2209, then you have an RSB for every uniquely received Resv message. Which is keyed on session, sender (filterspec) and next-hop address. Flowspec is not a key, but a value. > If a session uses FF style and there are > multiple senders, a SINGLE resv message carries > a {flowspec,filterspec} set for each sender. > This will result in RSB being created for each such > set. Correct. > Now if ROR is used and as only one MESSAGE_ID object > is allowed per message, should a separate resv message > be sent for each distinct reservation ? No. It just means that the one MESSAGE_ID will refresh multiple RSBs when it appears in an SRefresh message. -- David From owner-mpls@UU.NET Wed May 22 12:03:08 2002 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 MAA14600 for ; Wed, 22 May 2002 12:03:07 -0400 (EDT) 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 QQmpyu24026; Wed, 22 May 2002 16:02:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpyu06725 for mpls-outgoing; Wed, 22 May 2002 16:01: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 QQmpyu06685 for ; Wed, 22 May 2002 16:01:35 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 QQmpyu07188 for ; Wed, 22 May 2002 16:01:04 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmpyu22406 for ; Wed, 22 May 2002 16:01:03 GMT 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 MAA03340 for ; Wed, 22 May 2002 12:01:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA22430 for mpls@uu.net; Wed, 22 May 2002 12:01:03 -0400 (EDT) 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 QQmpyt01495 for ; Wed, 22 May 2002 15:59:25 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 QQmpyt28894 for ; Wed, 22 May 2002 15:58:18 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sword.cisco.com [161.44.208.100]) id QQmpyt25805 for ; Wed, 22 May 2002 15:58:17 GMT Received: from ZALI-W2K.cisco.com (che-vpn1-16.cisco.com [10.86.240.16]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id LAA24090; Wed, 22 May 2002 11:57:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20020522115324.04ff22e0@sword.cisco.com> X-Sender: zali@sword.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 May 2002 11:57:40 -0400 To: Marcos Antonio De Almeida Cora , mpls@UU.NET, mpls-ops@mplsrc.com From: Zafar Ali Subject: Re: LDP for GMPLS ??? In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_4855842==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_4855842==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Dear Marcos, Please see,=20 http://search.ietf.org/internet-drafts/draft-ietf-mpls-generalized-cr-ldp-06= .txt=20 for CR-LDP extensions for G-MPLS, and=20 http://search.ietf.org/internet-drafts/draft-ietf-mpls-generalized-cr-ldp-06= .txt=20 for RSVP-TE extensions for G-MPLS. Common specification can be found in=20 http://search.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling= -08.txt.=20 Thanks Regards... Zafar At 10:14 AM 5/22/2002 -0300, Marcos Antonio De Almeida Cora wrote: >Hi all, > >I'd like to know if anyone have links where I can to find papers and >informations about LDP and GMPLS ??? Mainly GMPLS using LDP. > >I have had difficulties to find these informations. > >By the way, Which is the protocol of distribution of labels more used in >the GMPLS ??? RSVP or LDP ??? > >It seems me that exist a difficulty in the use of the LDP for GMPLS, Why?? > >Best Regards, > > Marcos > >______________________________________________________________________ > > Marcos Ant=F4nio de Almeida Cor=E1 E-Mail: cora@dt.fee.unicamp.br > School of Electrical and Computer Engineering > Departament of Telematics > State University of Campinas/Brazil - UNICAMP > Phone: +55 (19) 3788.3711 - Branch: 73723 > Others e-mails: marcoscora@zipmail.com.br , marcos.cora@bol.com.br >______________________________________________________________________ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zafar Ali Cisco Systems 100 S Main St. #200 Ann Arbor, MI 48104. Mobile: (734) 276-2459, Off: (734) 302-4143, Fax: (734) 302-4190 email: zali@cisco.com --=====================_4855842==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Marcos,

Please see, http://search.ietf.org/internet-drafts/draft-ietf-mpls-g= eneralized-cr-ldp-06.txt for CR-LDP extensions for G-MPLS, and http://search.ietf.org/internet-drafts/draft-ietf-mpls-g= eneralized-cr-ldp-06.txt for RSVP-TE extensions for G-MPLS.= Common specification can be found in http://search.ietf.org/internet-drafts/draft-ietf-mpls-g= eneralized-signaling-08.txt.

Thanks

Regards... Zafar

At 10:14 AM 5/22/2002 -0300, Marcos Antonio De Almeida Cora wrote:

Hi all,

I'd like to know if anyone have links where I can to find papers and
informations about LDP and GMPLS ???  Mainly GMPLS using LDP. =

I have had difficulties to find these informations.

By the way, Which is the protocol of distribution of labels more used in
the GMPLS ???  RSVP or LDP ???

It seems me that exist a difficulty in the use of the LDP for GMPLS,= Why??

Best Regards,
         =        
            = Marcos

______________________________________________________________________

  Marcos Ant=F4nio de Almeida Cor=E1     = E-Mail: cora@dt.fee.unicamp.br   
  School of Electrical and Computer Engineering
  Departament of Telematics
  State University of Campinas/Brazil - UNICAMP
  Phone: +55 (19) 3788.3711 - Branch: 73723  
  Others e-mails: marcoscora@zipmail.com.br ,= marcos.cora@bol.com.br
______________________________________________________________________
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zafar Ali
Cisco Systems
100 S Main St. #200
Ann Arbor, MI 48104.
Mobile: (734) 276-2459, Off: (734) 302-4143, Fax: (734) 302-4190
email: zali@cisco.com<= /html> --=====================_4855842==_.ALT-- From owner-mpls@UU.NET Wed May 22 13:06:29 2002 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 NAA19364 for ; Wed, 22 May 2002 13:06:24 -0400 (EDT) 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 QQmpyy29932; Wed, 22 May 2002 17:05:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmpyy10863 for mpls-outgoing; Wed, 22 May 2002 17:05: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 QQmpyy10836 for ; Wed, 22 May 2002 17:05:19 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 QQmpyy06593 for ; Wed, 22 May 2002 17:04:42 GMT Received: from hoemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQmpyy26991 for ; Wed, 22 May 2002 17:04:42 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 g4MH4ew21613 for ; Wed, 22 May 2002 13:04:40 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 19:04:39 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: Marcos Antonio De Almeida Cora , mpls@UU.NET, mpls-ops@mplsrc.com Subject: RE: LDP for GMPLS ??? Date: Wed, 22 May 2002 19:04:37 +0200 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA19364 You may want to take a look at: http://www.labn.net/gmpls-survey/draft-ietf-ccamp-gmpls-signaling-survey-01.txt Bert > -----Original Message----- > From: Marcos Antonio De Almeida Cora [mailto:cora@dt.fee.unicamp.br] > Sent: Wednesday, May 22, 2002 3:15 PM > To: mpls@UU.NET; mpls-ops@mplsrc.com > Subject: LDP for GMPLS ??? > > > > Hi all, > > I'd like to know if anyone have links where I can to find papers and > informations about LDP and GMPLS ??? Mainly GMPLS using LDP. > > I have had difficulties to find these informations. > > By the way, Which is the protocol of distribution of labels > more used in > the GMPLS ??? RSVP or LDP ??? > > It seems me that exist a difficulty in the use of the LDP for > GMPLS, Why?? > > Best Regards, > > Marcos > > ______________________________________________________________________ > > Marcos Antônio de Almeida Corá E-Mail: > cora@dt.fee.unicamp.br > School of Electrical and Computer Engineering > Departament of Telematics > State University of Campinas/Brazil - UNICAMP > Phone: +55 (19) 3788.3711 - Branch: 73723 > Others e-mails: marcoscora@zipmail.com.br , marcos.cora@bol.com.br > ______________________________________________________________________ > > > From owner-mpls@UU.NET Thu May 23 07:33:52 2002 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 HAA04849 for ; Thu, 23 May 2002 07:33:51 -0400 (EDT) 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 QQmqbu21598; Thu, 23 May 2002 11:32:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqbu19037 for mpls-outgoing; Thu, 23 May 2002 11:32: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 QQmqbu19032 for ; Thu, 23 May 2002 11:32:13 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 QQmqbu23393 for ; Thu, 23 May 2002 11:32:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqbu13035 for ; Thu, 23 May 2002 11:32:02 GMT 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 HAA25921 for ; Thu, 23 May 2002 07:32:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA12320 for mpls@uu.net; Thu, 23 May 2002 07:32:02 -0400 (EDT) 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 QQmqbu18997 for ; Thu, 23 May 2002 11:31:13 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 QQmqbu18467 for ; Thu, 23 May 2002 11:30:06 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 QQmqbu05363 for ; Thu, 23 May 2002 11:30:04 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04693; Thu, 23 May 2002 07:29:43 -0400 (EDT) Message-Id: <200205231129.HAA04693@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-bundle-mib-02.txt Date: Thu, 23 May 2002 07:29:42 -0400 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 : Link Bundling Management Information Base Author(s) : M. Dubuc et al. Filename : draft-ietf-mpls-bundle-mib-02.txt Pages : 55 Date : 22-May-02 This memo defines an experimental portion of the Management Informa- tion Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling link bundling as described in [BUNDLING]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-mib-02.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-bundle-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-bundle-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020522145606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-bundle-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-bundle-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020522145606.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu May 23 08:54:25 2002 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 IAA07687 for ; Thu, 23 May 2002 08:54:25 -0400 (EDT) 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 QQmqbz29930; Thu, 23 May 2002 12:53:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqbz17619 for mpls-outgoing; Thu, 23 May 2002 12:53:05 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 QQmqbz17612 for ; Thu, 23 May 2002 12:53:04 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 QQmqbz05080 for ; Thu, 23 May 2002 12:53:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqbz29272 for ; Thu, 23 May 2002 12:53:02 GMT 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 IAA28757 for ; Thu, 23 May 2002 08:53:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA20696 for mpls@uu.net; Thu, 23 May 2002 08:53:01 -0400 (EDT) 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 QQmqbz17537 for ; Thu, 23 May 2002 12:51:48 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 QQmqbz00656 for ; Thu, 23 May 2002 12:51:19 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqbz27038 for ; Thu, 23 May 2002 12:51:19 GMT 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 IAA28631; Thu, 23 May 2002 08:51:18 -0400 (EDT) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id IAA20825; Thu, 23 May 2002 08:51:18 -0400 (EDT) Message-Id: <200205231251.IAA20825@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: sob@harvard.edu Cc: iesg@ietf.org, mpls@UU.NET Subject: ITU & MPLS Architecture Date: Thu, 23 May 2002 08:51:18 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Scott - It has come to my attention that the ITU is considering/planning a new recommendation, G.mna, "MPLS layer network architecture". As our liaison to the ITU would you please inform them that they are out of order here? Thank you, George >From: "Malcolm Betts" >To: "'Maarten Vissers'" , neil.2.harrison@bt.com >Cc: tsg13q3@itu.int, andy.bd.reid@bt.com, q12/15 >Subject: RE: G.mna >Date: Wed, 22 May 2002 08:11:26 -0400 >X-Mailer: Internet Mail Service (5.5.2653.19) >Sender: owner-tsg15q12@itu.int >Reply-To: "Malcolm Betts" > >I would like to clarify the status of this work in the context of >Q.12/15. The discussion that Maarten refers to was held between a small >group of experts who attend Q.12/15. The results were not formally >discussed within Q.12 and are not captured in the meeting report. > >I support this effort to consolidate the results of the earlier activities >into a single coherent document that could be provided as a contribution >to the next (January 2003) meeting of SG 15 where the group can formally >decide to initiate (or not) work on a new draft Recommendation on MPLS >layer network architecture. > >Malcolm Betts > >Rapporteur Q.12/15 >Nortel Networks >Phone: +1 613 763 7860 >FAX: +1 613 763 6608 >email: betts01@nortelnetworks.com > >-----Original Message----- >From: Maarten Vissers >[mailto:mvissers@lucent.com] >Sent: Wednesday, 22 May, 2002 04:36 >To: neil.2.harrison@bt.com >Cc: tsg13q3@itu.int; andy.bd.reid@bt.com; q12/15 >Subject: G.mna - [was: Re: AAP - Additional Review Comments from >WorldCom on Y.1710 (C o rr . 1) & Y.1711] > >Neil, > >A few months ago MPLS network architecture has been discussed in a smaller >team >of G.805 experts. During the SG15 meeting earlier this month we agreed to >contribute the results so far via correspondence (Q.12/15) as a starter for a >new recommendation (e.g. G.mna "MPLS layer network architecture"). > >The intent is to do as much via correspondence as possible, so we have a >quite >stable draft going in to the next SG15 meeting (in Jan 2003). > >To initiate this work in Q.12/15 I have created a new directory "gmna" and a >subdirectory "cd" for the correspondence documents on G.mna. >http://ties.itu.int/u/tsg15/sg15/wp3/q12/gmna/cd/ > > >I have also uploaded one of the documents that I developed during the mpls >network architecture discussion mentioned above. You find it at: >http://ties.itu.int/u/tsg15/sg15/wp3/q12/gmna/cd/mpls-model3.ppt > >There was other material available as well, so perhaps the authors can upload >that onto this new directory as well. > >Furthermore about 50 emails were exchanged. If we can summarize these >emails we >could have a flying start. Main question in those emails: is there a >single MPLS >layer network with a set of sublayers (for Tandem Connection Monitoring >and for >Multiplexing), or are there multiple MPLS layer networks. The root cause >of the >question is due to the Multiplexing capabilities that the sublayer would >have; >so far we hadn't come across a sublayer with multiplexing capabilities. >Current >thinking is that we have to model it in both ways; i.e. as a sublayer and >as an >additional layer network. > >After we developed the OTN with already 8 levels of "optical channel" >connection >monitoring (1x ODUk path, 6x ODUk tandem connection, 1x OTUk section), MPLS >offers the extreme (theoretical an infinite number of connection monitoring >levels). Despite that 8 levels of connection monitoring in the OTN is more >than >we have ever had before, we could not guarantee that it is sufficient in >every >network scenario (we believe it is). With the infinite number of connection >monitoring levels in MPLS, any network scenario (carrier grade) can be >supported >as soon as MPLS OAM is defined. > >Regards, > >Maarten > >neil.2.harrison@bt.com wrote: > > > > Thanks....some observations. regards Neil > > > > Pathak, Yatendra wrote 21 May 2002 17:15 > > > > > > > > Yatendra, > > > > thanks for your response. Having raised these comments I > > > am sure that we > > > > will see detailed Recommendation text proposals from > > > Worldcom at the next > > > > meeting. > > > > If not, then it can only be assumed that there is no real technical > > > > argument. > > > > > > > > > Yes, as we stated earlier on this list, WorldCom plans to submit > > > contribution(s). > > NH=> Can I just check when...is this to the Chitose mtg? > > > > > > > > > > > I would not expect to see any mention of FR in G.805 as it > > > is technology > > > > independent (see G.803 for SDH, G.872 for OTN, I.326 for ATM). If > > > > you think > > > > it is necessary to have one for FR please write one - this is a > > > > contribution > > > > driven process. The fact that there is not one for a > > > technology does not > > > > mean that the technique is not valid for that technology. > > > > > > > > > We disagree. We were trying to point out a technical issues > > > in that FR does > > > not use a G.805 style OAM model > > NH=> G.805 is not specifically about OAM.....G.805 merely formalises the > > vertical (client/server) and horizonal (within single layer) > relationships. > > However, such a view is an essential pre-cursor for the development of > > appropriate fault-management behaviour. Whether FR has appropriate OAM or > > not is not the issue here, but that does not mean FR does not behave in > > accordance with G.805...and it fact it does. > > > > , and that support for RFC > > > 3034 invalidates > > > the architectural assumption of the G.805 client-server > > > layered OAM model. > > NH=> Would you therefore argue that the SDH and OTN layer networks defined > > under GMPLS invalidate the G.805 model too? Clearly this is not true. I > > believe work will be started to provide a more rigorous functional > model of > > MPLS in ITU based on G.805 very soon (Maarten/Alan....do you know > status of > > this?), so I'd urge Worldcom to get involved if you have anything to > say on > > this before its completed. > > BTW - In fact it is due to a lack of being able to correctly map failure > > behaviour between layers (ie when some layers are insufficiently > specified) > > that will lead to some serious operational problems if we are not careful. > > For example, Jeremey Brayley had a requirement in his ATMoverMPLS draft > that > > was (paraphrased) 'on near-end ATM partition failure generate far-end > > partition SDH AIS'. This is completely unacceptable behaviour, ie asking > > the properly defined SDH OAM mechanism to proxy for missing OAM > > functionality elsewhere. Jeremy has kindly now removed this from his > draft. > > > > > We will note this issue in our contribution as a requirement > > > that support > > > for MPLS using FR encapsulation needs to be supported via the > > > OAM protocol. > > NH=> But that is wholly in the province of the data-plane of the FR layer > > network. If FR is badly/inappropriately specified then you should look > > there to correct it....not fudge it elsewhere, esp in other layer > networks. > > > > > > > > > > One has > > > > also been > > > > recently started for ethernet (G.etna). > > > > > > > > I have to agree with Dave Allan's points in his email. Clearly > > > > proposals to > > > > run X over MPLS are an indication that the model should be > > > independednt of > > > > the client (notwithstanding the requirements of one > > > particular client). > > > > > > > > > See our comments to Shahram. The issue we are raising is not > > > only the client > > > (encapsulation, "user plane," forwarding .... we have too > > > many names for the > > > same thing), but instead the interaction with the control plane. > > NH=> I agree that failures of the data-plane need communicating to the > > control-plane (and just as importantly also to the management plane). The > > route calculation process needs to know of topological validity/resource, > > and if any signalling protocol is involved this needs to know if it > needs to > > clear connections (SVC-like case) or invoke prot-sw/restoration > (S-PVC-like > > case). However, wrt to initial defect detection in the data-plane one > does > > not rely on control-plane protocols alone....these may even be the > cause of > > the defect in the data-plane in the 1st place if they are > > misbehaving/faulty. So if this is what you are suggesting here then > this is > > where I think there is a fundamental disagreement. In a cnls mode relying > > on the control-plane protocol is all you can do....and even here its > > strictly limited to the routing protocol, as there is no signalling > > protocol. These arguments are no longer correct/valid for co pkt-sw > > networks (though perhaps some will bend cnls/IGP model to now allow a > > signalling protocol to proxy for missing data-plane fault-handling?). But > > I'd assume you would concede this is patently not valid for co cct-sw > > networks like SDH and OTNs under GMPLS? > > ====================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu May 23 11:32:12 2002 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 LAA14741 for ; Thu, 23 May 2002 11:32:11 -0400 (EDT) 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 QQmqck03492; Thu, 23 May 2002 15:31:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqck06132 for mpls-outgoing; Thu, 23 May 2002 15:31: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 QQmqck06127 for ; Thu, 23 May 2002 15:31:04 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 QQmqck12699 for ; Thu, 23 May 2002 15:30:10 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandmail.sandburst.com [216.57.132.42]) id QQmqck13228 for ; Thu, 23 May 2002 15:30:09 GMT Message-ID: <3CED0B00.65E95912@sandburst.com> Date: Thu, 23 May 2002 11:30:08 -0400 From: Eric Gray MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: mpls@UU.NET, mpls-ops@mplsrc.com Subject: Re: LDP for GMPLS ??? References: Content-Type: multipart/alternative; boundary="------------B342E292B6004BD3799F50B7" Sender: owner-mpls@UU.NET Precedence: bulk --------------B342E292B6004BD3799F50B7 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Bert, The URL referenced below is not available though these are - http://www.labn.net/gmpls-survey/draft-ietf-ccamp-gmpls-signaling-sur= vey-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-signaling-= survey-00.txt Is there a more recent version in the making somewhere? You wrote: > You may want to take a look at: > http://www.labn.net/gmpls-survey/draft-ietf-ccamp-gmpls-signaling-surv= ey-01.txt > > Bert > > > -----Original Message----- > > From: Marcos Antonio De Almeida Cora [mailto:cora@dt.fee.unicamp.br] > > Sent: Wednesday, May 22, 2002 3:15 PM > > To: mpls@UU.NET; mpls-ops@mplsrc.com > > Subject: LDP for GMPLS ??? > > > > > > > > Hi all, > > > > I'd like to know if anyone have links where I can to find papers and > > informations about LDP and GMPLS ??? Mainly GMPLS using LDP. > > > > I have had difficulties to find these informations. > > > > By the way, Which is the protocol of distribution of labels > > more used in > > the GMPLS ??? RSVP or LDP ??? > > > > It seems me that exist a difficulty in the use of the LDP for > > GMPLS, Why?? > > > > Best Regards, > > > > Marcos > > > > _____________________________________________________________________= _ > > > > Marcos Ant=F4nio de Almeida Cor=E1 E-Mail: > > cora@dt.fee.unicamp.br > > School of Electrical and Computer Engineering > > Departament of Telematics > > State University of Campinas/Brazil - UNICAMP > > Phone: +55 (19) 3788.3711 - Branch: 73723 > > Others e-mails: marcoscora@zipmail.com.br , marcos.cora@bol.com.br > > _____________________________________________________________________= _ > > > > > > -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray --------------B342E292B6004BD3799F50B7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bert,

    The URL referenced below is not available though these are -

    http://www.labn.net/gmpls-survey/draft-ietf-ccamp-gmpls-signaling-survey-00.txt
    http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-signaling-survey-00.txt

Is there a more recent version in the making somewhere?

You wrote:

You may want to take a look at:
 http://www.labn.net/gmpls-survey/draft-ietf-ccamp-gmpls-signaling-survey-01.txt

Bert

> -----Original Message-----
> From: Marcos Antonio De Almeida Cora [mailto:cora@dt.fee.unicamp.br]
> Sent: Wednesday, May 22, 2002 3:15 PM
> To: mpls@UU.NET; mpls-ops@mplsrc.com
> Subject: LDP for GMPLS ???
>
>
>
> Hi all,
>
> I'd like to know if anyone have links where I can to find papers and
> informations about LDP and GMPLS ???  Mainly GMPLS using LDP.
>
> I have had difficulties to find these informations.
>
> By the way, Which is the protocol of distribution of labels
> more used in
> the GMPLS ???  RSVP or LDP ???
>
> It seems me that exist a difficulty in the use of the LDP for
> GMPLS, Why??
>
> Best Regards,
>
>              Marcos
>
> ______________________________________________________________________
>
>   Marcos Antônio de Almeida Corá      E-Mail:
> cora@dt.fee.unicamp.br
>   School of Electrical and Computer Engineering
>   Departament of Telematics
>   State University of Campinas/Brazil - UNICAMP
>   Phone: +55 (19) 3788.3711 - Branch: 73723
>   Others e-mails: marcoscora@zipmail.com.br , marcos.cora@bol.com.br
> ______________________________________________________________________
>
>
>

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray
  --------------B342E292B6004BD3799F50B7-- From owner-mpls@UU.NET Thu May 23 11:50:47 2002 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 LAA15508 for ; Thu, 23 May 2002 11:50:46 -0400 (EDT) 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 QQmqck03854; Thu, 23 May 2002 15:44:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqck07128 for mpls-outgoing; Thu, 23 May 2002 15:44: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 QQmqck07082 for ; Thu, 23 May 2002 15:44:08 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 QQmqck23478 for ; Thu, 23 May 2002 15:41:47 GMT Received: from wiprom2mx1.wipro.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQmqck13226 for ; Thu, 23 May 2002 15:41:42 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 g4NFfbe00606 for ; Thu, 23 May 2002 21:11:37 +0530 (IST) Received: from Sonal.wipro.com ([10.117.3.141]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GWKM9700.DE8; Thu, 23 May 2002 21:11:31 +0530 Message-ID: <01d101c2024b$10fcc940$8d03750a@wipro.com> Reply-To: "venkat" From: "Venkat Dabbara" To: "Eric Gray" , "Wijnen Bert \(Bert\)" Cc: , References: <3CED0B00.65E95912@sandburst.com> Subject: Re: LDP for GMPLS ??? Date: Thu, 23 May 2002 21:14:54 +1000 Organization: wipro technologies MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-d3ac8f4e-68b3-11d6-ba7c-006067005148" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPartTM-000-d3ac8f4e-68b3-11d6-ba7c-006067005148 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CE_01C2029E.E26D56E0" ------=_NextPart_000_01CE_01C2029E.E26D56E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hai , =20 I guess this would meet the requirement .. http://www.labn.net/gmpls-survey/draft-preview.txt regards venkat ----- Original Message -----=20 From: Eric Gray=20 To: Wijnen, Bert (Bert)=20 Cc: mpls@UU.NET ; mpls-ops@mplsrc.com=20 Sent: Friday, May 24, 2002 1:30 AM Subject: Re: LDP for GMPLS ??? Bert,=20 The URL referenced below is not available though these are -=20 = http://www.labn.net/gmpls-survey/draft-ietf-ccamp-gmpls-signaling-survey-= 00.txt=20 = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-signaling-surv= ey-00.txt=20 Is there a more recent version in the making somewhere?=20 You wrote:=20 You may want to take a look at:=20 = http://www.labn.net/gmpls-survey/draft-ietf-ccamp-gmpls-signaling-survey-= 01.txt=20 Bert=20 > -----Original Message-----=20 > From: Marcos Antonio De Almeida Cora = [mailto:cora@dt.fee.unicamp.br]=20 > Sent: Wednesday, May 22, 2002 3:15 PM=20 > To: mpls@UU.NET; mpls-ops@mplsrc.com=20 > Subject: LDP for GMPLS ???=20 >=20 >=20 >=20 > Hi all,=20 >=20 > I'd like to know if anyone have links where I can to find papers = and=20 > informations about LDP and GMPLS ??? Mainly GMPLS using LDP.=20 >=20 > I have had difficulties to find these informations.=20 >=20 > By the way, Which is the protocol of distribution of labels=20 > more used in=20 > the GMPLS ??? RSVP or LDP ???=20 >=20 > It seems me that exist a difficulty in the use of the LDP for=20 > GMPLS, Why??=20 >=20 > Best Regards,=20 >=20 > Marcos=20 >=20 > = ______________________________________________________________________=20 >=20 > Marcos Ant=F4nio de Almeida Cor=E1 E-Mail:=20 > cora@dt.fee.unicamp.br=20 > School of Electrical and Computer Engineering=20 > Departament of Telematics=20 > State University of Campinas/Brazil - UNICAMP=20 > Phone: +55 (19) 3788.3711 - Branch: 73723=20 > Others e-mails: marcoscora@zipmail.com.br , = marcos.cora@bol.com.br=20 > = ______________________________________________________________________=20 >=20 >=20 > -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray =20 ------=_NextPart_000_01CE_01C2029E.E26D56E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hai ,
   
          &nbs= p; I=20 guess this would meet the requirement ..
       =20     http://www.la= bn.net/gmpls-survey/draft-preview.txt
 
regards
venkat
 
----- Original Message -----
From:=20 Eric=20 Gray
Sent: Friday, May 24, 2002 1:30 = AM
Subject: Re: LDP for GMPLS = ???

Bert,=20

    The URL referenced below is not available = though=20 these are -=20

    http://www.labn.net/gmpls-survey/draft-ietf-ccamp-gmpls-s= ignaling-survey-00.txt=20
    http://www.ietf.org/internet-drafts/draft-ietf-ccamp-g= mpls-signaling-survey-00.txt=20

Is there a more recent version in the making somewhere?=20

You wrote:=20

You may want to take a look at:
 http://www.labn.net/gmpls-survey/draft-ietf-ccamp-gmpls-s= ignaling-survey-01.txt=20

Bert=20

> -----Original Message-----
> From: Marcos Antonio De = Almeida=20 Cora [mailto:cora@dt.fee.unicamp.br]= =20
> Sent: Wednesday, May 22, 2002 3:15 PM
> To: = mpls@UU.NET;=20 mpls-ops@mplsrc.com
> Subject: LDP for GMPLS ???
> =
>=20
>
> Hi all,
>
> I'd like to know if = anyone have=20 links where I can to find papers and
> informations about LDP = and=20 GMPLS ???  Mainly GMPLS using LDP.
>
> I have had = difficulties to find these informations.
>
> By the = way, Which=20 is the protocol of distribution of labels
> more used in =
> the=20 GMPLS ???  RSVP or LDP ???
>
> It seems me that = exist a=20 difficulty in the use of the LDP for
> GMPLS, Why??
> =
>=20 Best Regards,
>=20 =
>           = ;  =20 Marcos
>
>=20 = ______________________________________________________________________=20
>
>   Marcos Ant=F4nio de Almeida=20 Cor=E1      E-Mail:
> = cora@dt.fee.unicamp.br=20
>   School of Electrical and Computer Engineering=20
>   Departament of Telematics
>   = State=20 University of Campinas/Brazil - UNICAMP
>   Phone: = +55 (19)=20 3788.3711 - Branch: 73723
>   Others e-mails:=20 marcoscora@zipmail.com.br , marcos.cora@bol.com.br
>=20 = ______________________________________________________________________=20
>
>
>

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewg=
ray
 =20 ------=_NextPart_000_01CE_01C2029E.E26D56E0-- ------=_NextPartTM-000-d3ac8f4e-68b3-11d6-ba7c-006067005148-- From owner-mpls@UU.NET Thu May 23 12:30:37 2002 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 MAA17195 for ; Thu, 23 May 2002 12:30:37 -0400 (EDT) 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 QQmqco09948; Thu, 23 May 2002 16:30:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqco02789 for mpls-outgoing; Thu, 23 May 2002 16:30: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 QQmqcn02707 for ; Thu, 23 May 2002 16:29: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 QQmqcn23675 for ; Thu, 23 May 2002 16:28:04 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqcn29269 for ; Thu, 23 May 2002 16:28:03 GMT 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 MAA15766 for ; Thu, 23 May 2002 12:28:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA11958 for mpls@uu.net; Thu, 23 May 2002 12:28:02 -0400 (EDT) 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 QQmqcn02580 for ; Thu, 23 May 2002 16:27:23 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 QQmqcn13495 for ; Thu, 23 May 2002 16:26:34 GMT Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: exchange.movaz.com [65.205.166.141]) id QQmqcn27057 for ; Thu, 23 May 2002 16:26:33 GMT Received: from LB-LAPTOP.movaz.com ([172.16.8.184]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 23 May 2002 12:26:31 -0400 Message-Id: <4.3.2.7.2.20020523122459.01bb7f00@mail.labn.net> X-Sender: lb@mo-ex1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 May 2002 12:26:21 -0400 To: Eric Gray From: Lou Berger Subject: Re: LDP for GMPLS ??? Cc: "Wijnen, Bert (Bert)" , mpls@UU.NET, mpls-ops@mplsrc.com In-Reply-To: <3CED0B00.65E95912@sandburst.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 23 May 2002 16:26:32.0450 (UTC) FILETIME=[99801620:01C20276] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA17195 link is fixed on labn page. Also a preview of the next version is available: http://www.labn.net/gmpls-survey/draft-preview.txt Lou At 11:30 AM 5/23/2002, Eric Gray wrote: >Bert, > > The URL referenced below is not available though these are - > > >http://www.labn.net/gmpls-survey/draft-ietf-ccamp-gmpls-signaling-survey-00.txt > > >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-signaling-survey-00.txt > > >Is there a more recent version in the making somewhere? > >You wrote: >>You may want to take a look at: >> >>http://www.labn.net/gmpls-survey/draft-ietf-ccamp-gmpls-signaling-survey-01.txt >> >> >>Bert >> >> > -----Original Message----- >> > From: Marcos Antonio De Almeida Cora >> [mailto:cora@dt.fee.unicamp.br] >> > Sent: Wednesday, May 22, 2002 3:15 PM >> > To: mpls@UU.NET; mpls-ops@mplsrc.com >> > Subject: LDP for GMPLS ??? >> > >> > >> > >> > Hi all, >> > >> > I'd like to know if anyone have links where I can to find papers and >> > informations about LDP and GMPLS ??? Mainly GMPLS using LDP. >> > >> > I have had difficulties to find these informations. >> > >> > By the way, Which is the protocol of distribution of labels >> > more used in >> > the GMPLS ??? RSVP or LDP ??? >> > >> > It seems me that exist a difficulty in the use of the LDP for >> > GMPLS, Why?? >> > >> > Best Regards, >> > >> > Marcos >> > >> > ______________________________________________________________________ >> > >> > Marcos Antônio de Almeida Corá E-Mail: >> > cora@dt.fee.unicamp.br >> > School of Electrical and Computer Engineering >> > Departament of Telematics >> > State University of Campinas/Brazil - UNICAMP >> > Phone: +55 (19) 3788.3711 - Branch: 73723 >> > Others e-mails: marcoscora@zipmail.com.br , marcos.cora@bol.com.br >> > ______________________________________________________________________ >> > >> > >> > > >-- >Eric Gray (mailto:eric.gray@sandburst.com) >http://www.mindspring.com/~ewgray > From owner-mpls@UU.NET Thu May 23 14:45:33 2002 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 OAA22662 for ; Thu, 23 May 2002 14:45:32 -0400 (EDT) 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 QQmqcw25714; Thu, 23 May 2002 18:44:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqcw26985 for mpls-outgoing; Thu, 23 May 2002 18:44: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 QQmqcw26972 for ; Thu, 23 May 2002 18:44:04 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 QQmqcw14273 for ; Thu, 23 May 2002 18:42:46 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqcw18063 for ; Thu, 23 May 2002 18:42:46 GMT 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 OAA25499 for ; Thu, 23 May 2002 14:42:45 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA25524 for mpls@uu.net; Thu, 23 May 2002 14:42:45 -0400 (EDT) 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 QQmqcw25968 for ; Thu, 23 May 2002 18:30:45 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 QQmqcv06886 for ; Thu, 23 May 2002 18:28:41 GMT Received: from web13406.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13406.mail.yahoo.com [216.136.175.64]) id QQmqcv28238 for ; Thu, 23 May 2002 18:28:40 GMT Message-ID: <20020523182839.74683.qmail@web13406.mail.yahoo.com> Received: from [216.73.180.79] by web13406.mail.yahoo.com via HTTP; Thu, 23 May 2002 11:28:39 PDT Date: Thu, 23 May 2002 11:28:39 -0700 (PDT) From: Gopalkrishna Panicker Subject: RSVP-TE : bandwidth decrease To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hello, Consider the following topology A-----------B----------C Let us say 1. we are using make-before-break and therefore using SE style. 2. LSP1 with Sender1 has been signalled with a bandwidth of 20 units. A is the ingress and C is the egress. Now A decides to reduce the bandwidth to 10 units. A ceates a new sender template (Sender2) and Tspec. A then sends the path message towards C. After receiving the path message, C computes the bandwidth to be allocated. Since SE style is being used, the merged flowspec sent in the resv message from C to B will continue to say a bandwidth of 20 units. The only reason the resv makes it back to A is because of the new filterspec (Sender2). I assuming this is correct. Now A issues a path tear for sender1. B will delete the path state associated with sender1. B will also delete the corresponding filter spec from the resv state. Now to my question. How does B know that it has to delete the 10 units of bandwidth reservation ? If my understanding is correct, the resv message from C had carried a merged flowspec and set of filterspecs (Sender1, Sender2). How does B determine the orginal flowspec associated with the filterspec (in this case Sender1) ? Should B on rely on the tspec stored in the PSB ? Obviously I am missing something. Thanks Cheers Gopal __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-mpls@UU.NET Thu May 23 15:26:10 2002 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 PAA23721 for ; Thu, 23 May 2002 15:26:10 -0400 (EDT) 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 QQmqcz19591; Thu, 23 May 2002 19:25:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqcz22689 for mpls-outgoing; Thu, 23 May 2002 19:25: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 QQmqcz22684 for ; Thu, 23 May 2002 19:25:20 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 QQmqcz06975 for ; Thu, 23 May 2002 19:24:01 GMT Received: from RS-SC-EXC4.rs.riverstonenet.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host60.riverstonenet.com [64.95.122.60] (may be forged)) id QQmqcz17237 for ; Thu, 23 May 2002 19:24:01 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Subject: Intellectual Property Considerations Date: Thu, 23 May 2002 12:23:59 -0700 Message-ID: <10169FC9AB71D940902FE7EBE7109AA90A6316@rs-sc-exc4.rs.riverstonenet.com> Thread-Topic: Intellectual Property Considerations Thread-Index: AcICjzaGMzfOGBXGQHCKNnpVoknk0g== From: "Ray Qiu" To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA23721 Hi, In the draft-ietf-mpls-lsp-ping-00.txt, there is one paragraph called "Intellectual Property Considerations" where the vendor is seeking patent protection. But this document is a MPLS working group document! Does it mean other people can not comment on the draft or can not contribute to the draft? Then what is the point of making it a working group document? May someone please help me to understand here? Thanks! Ray From owner-mpls@UU.NET Thu May 23 15:41:42 2002 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 PAA24091 for ; Thu, 23 May 2002 15:41:42 -0400 (EDT) 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 QQmqda23393; Thu, 23 May 2002 19:40:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqda24063 for mpls-outgoing; Thu, 23 May 2002 19:40: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 QQmqda24058 for ; Thu, 23 May 2002 19:40: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 QQmqda07115 for ; Thu, 23 May 2002 19:40:08 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqda10551 for ; Thu, 23 May 2002 19:40:03 GMT 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 PAA29963 for ; Thu, 23 May 2002 15:40:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA02099 for mpls@uu.net; Thu, 23 May 2002 15:40:02 -0400 (EDT) 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 QQmqda24020 for ; Thu, 23 May 2002 19:39: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 QQmqda04110 for ; Thu, 23 May 2002 19:39:12 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQmqda09265 for ; Thu, 23 May 2002 19:39:12 GMT Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA12723; Thu, 23 May 2002 15:39:10 -0400 (EDT) Date: Thu, 23 May 2002 15:39:09 -0400 (EDT) From: Ajay Simha To: Ray Qiu cc: mpls@UU.NET Subject: Re: Intellectual Property Considerations In-Reply-To: <10169FC9AB71D940902FE7EBE7109AA90A6316@rs-sc-exc4.rs.riverstonenet.com> Message-ID: References: <10169FC9AB71D940902FE7EBE7109AA90A6316@rs-sc-exc4.rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 23 May 2002, Ray Qiu wrote: >RQ:Hi, >RQ: >RQ:In the draft-ietf-mpls-lsp-ping-00.txt, there is one paragraph called "Intellectual >RQ:Property Considerations" where the vendor is seeking patent protection. But this >RQ:document is a MPLS working group document! Does it mean other people >RQ:can not comment on the draft or can not contribute to the draft? Then what is >RQ:the point of making it a working group document? You can comment/contribute but if the patent is approved it is their idea. It may mean that if a vendor want to use this idea they may have to pay royality to these folks or get some approval of some sort :) -ajay >RQ: >RQ:May someone please help me to understand here? >RQ: >RQ:Thanks! >RQ: >RQ:Ray >RQ: >RQ: -- From owner-mpls@UU.NET Thu May 23 15:51:23 2002 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 PAA24401 for ; Thu, 23 May 2002 15:51:22 -0400 (EDT) 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 QQmqdb08514; Thu, 23 May 2002 19:51:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqdb25121 for mpls-outgoing; Thu, 23 May 2002 19:50: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 QQmqdb25116 for ; Thu, 23 May 2002 19:50:40 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 QQmqdb16737 for ; Thu, 23 May 2002 19:49:52 GMT Received: from RS-SC-EXC4.rs.riverstonenet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host60.riverstonenet.com [64.95.122.60] (may be forged)) id QQmqdb06684 for ; Thu, 23 May 2002 19:49:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Intellectual Property Considerations Date: Thu, 23 May 2002 12:49:27 -0700 Message-ID: <10169FC9AB71D940902FE7EBE7109AA90A6317@rs-sc-exc4.rs.riverstonenet.com> Thread-Topic: Intellectual Property Considerations Thread-Index: AcICkYQkLs2v1FlbSwmK+5BYjcbzyQAABuBw From: "Ray Qiu" To: "Ajay Simha" Cc: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA24401 Ajay, Thanks for the response. What will happen if other people's contributions are pretty big changes to their idea? :-) If people want to apply patent, it seems to make sense for them to take their document out of IETF working group. Thanks. Ray -----Original Message----- From: Ajay Simha [mailto:asimha@cisco.com] Sent: Thursday, May 23, 2002 12:39 PM To: Ray Qiu Cc: mpls@UU.NET Subject: Re: Intellectual Property Considerations On Thu, 23 May 2002, Ray Qiu wrote: >RQ:Hi, >RQ: >RQ:In the draft-ietf-mpls-lsp-ping-00.txt, there is one paragraph called "Intellectual >RQ:Property Considerations" where the vendor is seeking patent protection. But this >RQ:document is a MPLS working group document! Does it mean other people >RQ:can not comment on the draft or can not contribute to the draft? Then what is >RQ:the point of making it a working group document? You can comment/contribute but if the patent is approved it is their idea. It may mean that if a vendor want to use this idea they may have to pay royality to these folks or get some approval of some sort :) -ajay >RQ: >RQ:May someone please help me to understand here? >RQ: >RQ:Thanks! >RQ: >RQ:Ray >RQ: >RQ: -- From owner-mpls@UU.NET Thu May 23 16:08:49 2002 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 QAA24949 for ; Thu, 23 May 2002 16:08:49 -0400 (EDT) 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 QQmqdc05198; Thu, 23 May 2002 20:08:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqdc17665 for mpls-outgoing; Thu, 23 May 2002 20:07: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 QQmqdc17637 for ; Thu, 23 May 2002 20:07: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 QQmqdc02790 for ; Thu, 23 May 2002 20:06:29 GMT Received: from auemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQmqdc02872 for ; Thu, 23 May 2002 20:06:29 GMT Received: from ihmail.ih.lucent.com (h135-185-56-8.lucent.com [135.185.56.8]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4NK6Rh26395; Thu, 23 May 2002 16:06:27 -0400 (EDT) Received: from lucent.com (sjtrowbridge-1.dr.lucent.com [135.4.20.23]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA28230; Thu, 23 May 2002 15:06:25 -0500 (CDT) Message-ID: <3CED4BC0.3F19CB3A@lucent.com> Date: Thu, 23 May 2002 14:06:24 -0600 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: Ray Qiu CC: Ajay Simha , mpls@UU.NET Subject: Re: Intellectual Property Considerations References: <10169FC9AB71D940902FE7EBE7109AA90A6317@rs-sc-exc4.rs.riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ray, Intellectual property is widespread through standards. It is generally not considered necessary that the patent holder grant free license: only that they make license available under reasonable and non-discriminatory terms (RAND) for any material they may have contributed (see RFC 2026, 10.3.2 (C)) The question isn't whether others make big changes to their idea. It is only whether the patent remains necessary to implementation of the standard after the changes. In fact, the big changes due to contributions of others may require that patents be licensed from more than one company to implement the standard. If the changes were significant enough that the original author's patent is no longer necessary to implement the standard, you have no problem. Steve Ray Qiu wrote: > > Ajay, > > Thanks for the response. What will happen if other people's contributions > are pretty big changes to their idea? :-) > > If people want to apply patent, it seems to make sense for them to take > their document out of IETF working group. > > Thanks. > > Ray > > -----Original Message----- > From: Ajay Simha [mailto:asimha@cisco.com] > Sent: Thursday, May 23, 2002 12:39 PM > To: Ray Qiu > Cc: mpls@UU.NET > Subject: Re: Intellectual Property Considerations > > On Thu, 23 May 2002, Ray Qiu wrote: > > >RQ:Hi, > >RQ: > >RQ:In the draft-ietf-mpls-lsp-ping-00.txt, there is one paragraph called "Intellectual > >RQ:Property Considerations" where the vendor is seeking patent protection. But this > >RQ:document is a MPLS working group document! Does it mean other people > >RQ:can not comment on the draft or can not contribute to the draft? Then what is > >RQ:the point of making it a working group document? > > You can comment/contribute but if the patent is approved it is their idea. > It may mean that if a vendor want to use this idea they may have to pay > royality to these folks or get some approval of some sort :) > > -ajay > >RQ: > >RQ:May someone please help me to understand here? > >RQ: > >RQ:Thanks! > >RQ: > >RQ:Ray > >RQ: > >RQ: > > -- From owner-mpls@UU.NET Thu May 23 16:09:00 2002 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 QAA24975 for ; Thu, 23 May 2002 16:08:59 -0400 (EDT) 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 QQmqbu19360; Thu, 23 May 2002 11:36:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqbu19229 for mpls-outgoing; Thu, 23 May 2002 11:35:44 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 QQmqbu19203 for ; Thu, 23 May 2002 11:35:28 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 QQmqbu09556 for ; Thu, 23 May 2002 11:33:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqbu14483 for ; Thu, 23 May 2002 11:33:02 GMT 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 HAA25951 for ; Thu, 23 May 2002 07:33:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA12412 for mpls@uu.net; Thu, 23 May 2002 07:33:01 -0400 (EDT) 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 QQmqbu18998 for ; Thu, 23 May 2002 11:31:14 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 QQmqbu18113 for ; Thu, 23 May 2002 11:30:00 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 QQmqbt05158 for ; Thu, 23 May 2002 11:29:59 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04677; Thu, 23 May 2002 07:29:38 -0400 (EDT) Message-Id: <200205231129.HAA04677@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-recovery-frmwrk-04.txt Date: Thu, 23 May 2002 07:29:38 -0400 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 : Framework for MPLS-based Recovery Author(s) : V. Sharma et al. Filename : draft-ietf-mpls-recovery-frmwrk-04.txt Pages : 31 Date : 22-May-02 Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switched routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling, support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-recovery-frmwrk-04.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-recovery-frmwrk-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-recovery-frmwrk-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020522145554.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-recovery-frmwrk-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-recovery-frmwrk-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020522145554.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu May 23 16:13:56 2002 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 QAA25255 for ; Thu, 23 May 2002 16:13:56 -0400 (EDT) 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 QQmqdc28599; Thu, 23 May 2002 20:13:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqdc18865 for mpls-outgoing; Thu, 23 May 2002 20:12: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 QQmqdc18856 for ; Thu, 23 May 2002 20:12:23 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 QQmqdc01803 for ; Thu, 23 May 2002 20:11:08 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 QQmqdc08871 for ; Thu, 23 May 2002 20:11:08 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 QAA04415 for ; Thu, 23 May 2002 16:11:05 -0400 (EDT) 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 QAA03836 for ; Thu, 23 May 2002 16:11:06 -0400 (EDT) Message-ID: <3CED4CFF.39489D8F@marconi.com> Date: Thu, 23 May 2002 16:11:43 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: RSVP-TE : bandwidth decrease References: <20020523182839.74683.qmail@web13406.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gopalkrishna Panicker wrote: > > Hello, > > Consider the following topology > > A-----------B----------C > > Let us say > 1. we are using make-before-break and therefore using SE style. > 2. LSP1 with Sender1 has been signalled with a bandwidth of 20 > units. A is the ingress and C is the egress. > > Now A decides to reduce the bandwidth to 10 units. A ceates a new > sender template (Sender2) and Tspec. A then sends the path message > towards C. Correct... > After receiving the path message, C computes the bandwidth to be > allocated. Since SE style is being used, the merged flowspec sent > in the resv message from C to B will continue to say a bandwidth > of 20 units. What C actually reserves is a matter of local policy, but to assume that it will choose the least upper bound of the two incoming Path messages is probably a safe assumption. > The only reason the resv makes it back to A is because of the new > filterspec (Sender2). Assuming that the Resv's reservation remains 20, you are correct. > I assuming this is correct. > > Now A issues a path tear for sender1. B will delete the path state > associated with sender1. B will also delete the corresponding > filter spec from the resv state. Correct. > Now to my question. How does B know that it has to delete the 10 > units of bandwidth reservation ? Two different ways. When the PathTear arrives at C, C should re-merge the remaining Path states in the session (which will only be sender2 now), resulting in a bandwidth of 10 units. It should then generate a Resv for the new value, which will propagate back. Also, each router should clip reservations to the level of the TSpec. It is wasteful to reserve more than has been requested. Once sender1 goes away, the merged resources for the session will be 10 - when the Resv from C is clipped to the remaining TSpec, 10 will remain. B should then change its reservation and send a Resv with the new value. See section 2.2 of RFC 2205 for the resv merging rules. In particular note the three steps at the end of this section. Inbound Resv FLOWSPECs are merged into (Re, Resv_Te) - in your example, this is the inbound FLOWSPEC, since there is only one Resv message arriving. Inbound Path TSPECs are merged into the Path_Te variable - in your example, this is from both Path messages, and later from the one remaining Path message. In step 3, the resources actually reserved will be the minimum of Path_Te and Resv_Te. In other words, the FLOWSPEC is clipped to the corresponding TSPEC objects. Section 2.2 is not easy reading, but it does explain exactly what needs to happen. > If my understanding is correct, the resv message from C had > carried a merged flowspec and set of filterspecs (Sender1, > Sender2). How does B determine the orginal flowspec associated > with the filterspec (in this case Sender1) ? It determines this by looking at the stored TSPEC object for the remaining sender(s). > Should B on rely on the tspec stored in the PSB ? Yes. -- David From owner-mpls@UU.NET Thu May 23 16:28:40 2002 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 QAA25980 for ; Thu, 23 May 2002 16:28:40 -0400 (EDT) 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 QQmqdd22027; Thu, 23 May 2002 20:28:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqdd20321 for mpls-outgoing; Thu, 23 May 2002 20:27:36 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 QQmqdd20316 for ; Thu, 23 May 2002 20:27:36 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 QQmqdd01232 for ; Thu, 23 May 2002 20:26:11 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqdd00408 for ; Thu, 23 May 2002 20:26:10 GMT 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 QAA03546 for ; Thu, 23 May 2002 16:26:10 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA08922 for mpls@uu.net; Thu, 23 May 2002 16:26:10 -0400 (EDT) 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 QQmqdd19933 for ; Thu, 23 May 2002 20:23:06 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 QQmqdd22461 for ; Thu, 23 May 2002 20:22:40 GMT Received: from web13409.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13409.mail.yahoo.com [216.136.172.17]) id QQmqdd27937 for ; Thu, 23 May 2002 20:22:39 GMT Message-ID: <20020523202239.23273.qmail@web13409.mail.yahoo.com> Received: from [216.73.180.79] by web13409.mail.yahoo.com via HTTP; Thu, 23 May 2002 13:22:39 PDT Date: Thu, 23 May 2002 13:22:39 -0700 (PDT) From: Gopalkrishna Panicker Subject: RE: RSVP-TE : bandwidth decrease To: "Feng, Mark" Cc: mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Mark, Thanks. That was helpful. I was just browsing the RSVP-TE spec. In light of this discussion I find it interesting that the spec always refers to "bandwidth-increase" instead of say a "bandwidth-modify". I am wondering if make-before-break mechanism should be used when bandwidth is to be decreased. IMO make-before-break was devised to solve the double-counting issues which we don't have here. As mentioned in one of David's earlier emails on the subject, We could simply change the Sender Tspec and wait for a new updated Flowspec from the egress to take effect. Cheers Gopal --- "Feng, Mark" wrote: > IMO, the exact behavior depends on the > implementation, though the end result > should be the same. > > In one behavior, when B receives the PTear, it would > remove the reference to > sender1 in PSB and RSB; but leave the allocation > unchanged (i.e. 20 units). > When C receives the PTear, it would generate a new > Flowspec of 10 units, > since sender1 is removed. When the new Resv message > has been propagated back > to Ingress, the desired allocation is in place. > > B could try to guess what the new allocation is, > based on the Tspec, before > receiving the new Flowspec. IMO, that's entirely up > to the implementation. > > Hope this helps. > > - Mark > > > -----Original Message----- > > From: Gopalkrishna Panicker > [mailto:gopanicker@yahoo.com] > > Sent: Thursday, May 23, 2002 11:29 AM > > To: mpls@UU.NET > > Subject: RSVP-TE : bandwidth decrease > > > > > > Hello, > > > > Consider the following topology > > > > > > A-----------B----------C > > > > Let us say > > 1. we are using make-before-break and therefore > > using SE style. > > 2. LSP1 with Sender1 has been signalled with a > > bandwidth of 20 units. A is the ingress and C > is > > the egress. > > > > Now A decides to reduce the bandwidth to 10 > units. > > A ceates a new sender template (Sender2) and > > Tspec. A then sends the path message towards C. > > > > After receiving the path message, C computes the > > bandwidth to be allocated. Since SE style is > being > > used, the merged flowspec sent in the resv > message > > from C to B will continue to say a bandwidth of > > 20 units. > > The only reason the resv makes it back > > to A is because of the new filterspec (Sender2). > > > > I assuming this is correct. > > > > Now A issues a path tear for sender1. B will > > delete the path state associated with sender1. > > B will also delete the corresponding filter spec > > from the resv state. > > > > Now to my question. How does B know that it has > > to delete the 10 units of bandwidth reservation > ? > > > > If my understanding is correct, the resv message > > from C had carried a merged flowspec and set of > > filterspecs (Sender1, Sender2). How does B > > determine the orginal flowspec associated with > > the filterspec (in this case Sender1) ? > > > > Should B on rely on the tspec stored in the PSB > ? > > > > > > Obviously I am missing something. > > > > Thanks > > > > Cheers > > Gopal > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > LAUNCH - Your Yahoo! Music Experience > > http://launch.yahoo.com > > __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-mpls@UU.NET Thu May 23 16:41:27 2002 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 QAA26479 for ; Thu, 23 May 2002 16:41:27 -0400 (EDT) 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 QQmqde10679; Thu, 23 May 2002 20:40:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqde21129 for mpls-outgoing; Thu, 23 May 2002 20:39: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 QQmqde21118 for ; Thu, 23 May 2002 20:39:22 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 QQmqde14605 for ; Thu, 23 May 2002 20:39:21 GMT Received: from RS-SC-EXC4.rs.riverstonenet.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host60.riverstonenet.com [64.95.122.60] (may be forged)) id QQmqde09565 for ; Thu, 23 May 2002 20:39:21 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Subject: RE: Intellectual Property Considerations Date: Thu, 23 May 2002 13:38:01 -0700 Message-ID: <10169FC9AB71D940902FE7EBE7109AA909C58A@rs-sc-exc4.rs.riverstonenet.com> Thread-Topic: Intellectual Property Considerations Thread-Index: AcIClETekPdklDAtQRqwyCPQsO7rsQABT8/w From: "Ray Qiu" To: "Shahram Davari" , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA26479 Thanks guys. That is helpful. Ray -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Thursday, May 23, 2002 12:59 PM To: Ray Qiu; mpls@UU.NET Subject: RE: Intellectual Property Considerations Ray, Any contribution that has patent claim may seek to become a WG document. The WG members must decide whether the benefits of that contribution outweighs the problems associated with that patent (e.g. Royalty fee) or whether there are other methods that could accomplish the same result which don't have patent claim. If they decide in favor of the document, then probably the basics of that document is sound and won't change by WG comments, and the patent will probably stand. However, In rare cases there could be substantial changes to the basics of the document, which in that case I don't think the original patent would apply to that RFC. Yours, -Shahram > -----Original Message----- > From: Ray Qiu [mailto:rqiu@riverstonenet.com] > Sent: Thursday, May 23, 2002 3:24 PM > To: mpls@UU.NET > Subject: Intellectual Property Considerations > > > Hi, > > In the draft-ietf-mpls-lsp-ping-00.txt, there is one > paragraph called "Intellectual > Property Considerations" where the vendor is seeking patent > protection. But this > document is a MPLS working group document! Does it mean other people > can not comment on the draft or can not contribute to the > draft? Then what is > the point of making it a working group document? > > May someone please help me to understand here? > > Thanks! > > Ray > > From owner-mpls@UU.NET Thu May 23 16:44:51 2002 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 QAA26573 for ; Thu, 23 May 2002 16:44:51 -0400 (EDT) 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 QQmqde00716; Thu, 23 May 2002 20:44:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqde21455 for mpls-outgoing; Thu, 23 May 2002 20:43: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 QQmqde21446 for ; Thu, 23 May 2002 20:43: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 QQmqde26536 for ; Thu, 23 May 2002 20:43:04 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqde24524 for ; Thu, 23 May 2002 20:43:03 GMT 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 QAA04604 for ; Thu, 23 May 2002 16:43:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA11127 for mpls@uu.net; Thu, 23 May 2002 16:43:03 -0400 (EDT) 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 QQmqde21341 for ; Thu, 23 May 2002 20:41: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 QQmqde15574 for ; Thu, 23 May 2002 20:39:40 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmqde09916 for ; Thu, 23 May 2002 20:39: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 QAA69456; Thu, 23 May 2002 16:39:03 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200205232039.QAA69456@workhorse.fictitious.org> To: "Ray Qiu" cc: "Ajay Simha" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Intellectual Property Considerations In-reply-to: Your message of "Thu, 23 May 2002 12:49:27 PDT." <10169FC9AB71D940902FE7EBE7109AA90A6317@rs-sc-exc4.rs.riverstonenet.com> Date: Thu, 23 May 2002 16:39:03 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <10169FC9AB71D940902FE7EBE7109AA90A6317@rs-sc-exc4.rs.riverstonenet. com>, "Ray Qiu" writes: > Ajay, > > Thanks for the response. What will happen if other people's contributions > are pretty big changes to their idea? :-) > > If people want to apply patent, it seems to make sense for them to take > their document out of IETF working group. > > Thanks. > > Ray Ray, I'm not a lawyer but here is my uninformed opinion. For something to be patented an idea must be unique, original, and non-obvious. When something is in the patent application process, the application is not disclosed so we have no idea what is being applied for. Many patents are granted that should not have been granted and would never hold up in court. Of these, some are challenged and the patent is invalidated. For example, if the patent examiner is unaware of prior work when the patent is enforced it may be challenged and invalidated. If a patent is granted, it can only be challenged if there is an attempt to enforce it. The holder of a patent, realizing that the challenge may be invalidated (or in some cases is almost certain to be invalidated), may decide simply to threaten enforcement but not follow through. If so, the patent is never challenged and remains on the books. A good example of the prior situation is the IBM RISC patents in the 1980s. IBM had numerous patents and tried to threaten Sun, MIPS, and anyone else making a RISC chip. Many people publicly commented, pointing to prior work, and IBM simply didn't pursue the enforcement. The patents remain on the books but in this case are ignored. When and if a patent is granted, it is possible to discuss whether it can safely be ignored. If it is denied, then the Intellectual Property message in an internet-draft or RFC should be removed, but there is no way to tell that the rejection has occurred unless the party who applied informs us. During the time (often years) when there is an application but no decision on the part of the patent office, its all a big mystery. The only thing someone in the IETF can do faced with an Intellectual Property statement in an internet-draft is look at the internet-draft and try to figure out what if anything looks unique, original, and non-obvious. If nothing other than the arrangement of bits is really an original idea, then it is unlikely that a patent will be granted, enforced, and upheld. Since judges that rule on patents are non-technical, whether something would be upheld is anyone's guess, regardless of merit. [IMHO - the patent system does the technical community a great disservice, in this field in particular, but also in others.] It is important to point out that I'm not a lawyer so I can't give legal advice. You may want to consult a lawyer for all of your life's major decisions and the minor ones too and perhaps not even speak to us mere mortals. :-) Curtis > -----Original Message----- > From: Ajay Simha [mailto:asimha@cisco.com] > Sent: Thursday, May 23, 2002 12:39 PM > To: Ray Qiu > Cc: mpls@UU.NET > Subject: Re: Intellectual Property Considerations > > > On Thu, 23 May 2002, Ray Qiu wrote: > > >RQ:Hi, > >RQ: > >RQ:In the draft-ietf-mpls-lsp-ping-00.txt, there is one paragraph called "In > tellectual > >RQ:Property Considerations" where the vendor is seeking patent protection. > But this > >RQ:document is a MPLS working group document! Does it mean other people > >RQ:can not comment on the draft or can not contribute to the draft? Then wh > at is > >RQ:the point of making it a working group document? > > You can comment/contribute but if the patent is approved it is their idea. > It may mean that if a vendor want to use this idea they may have to pay > royality to these folks or get some approval of some sort :) > > -ajay > >RQ: > >RQ:May someone please help me to understand here? > >RQ: > >RQ:Thanks! > >RQ: > >RQ:Ray > >RQ: > >RQ: > > -- > > From owner-mpls@UU.NET Thu May 23 16:53:16 2002 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 QAA26911 for ; Thu, 23 May 2002 16:53:16 -0400 (EDT) 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 QQmqdf06278; Thu, 23 May 2002 20:50:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqdf22445 for mpls-outgoing; Thu, 23 May 2002 20:50: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 QQmqdf22432 for ; Thu, 23 May 2002 20:50: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 QQmqdf13711 for ; Thu, 23 May 2002 20:48:23 GMT Received: from RS-SC-EXC4.rs.riverstonenet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host60.riverstonenet.com [64.95.122.60] (may be forged)) id QQmqdf02682 for ; Thu, 23 May 2002 20:48:23 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Intellectual Property Considerations Date: Thu, 23 May 2002 13:48:16 -0700 Message-ID: <10169FC9AB71D940902FE7EBE7109AA909C58B@rs-sc-exc4.rs.riverstonenet.com> Thread-Topic: Intellectual Property Considerations Thread-Index: AcICmeQDcgtTo76xTKqXHY51Fa8ugQAAE1+g From: "Ray Qiu" To: Cc: "Ajay Simha" , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA26911 Curtis, Thanks for the info. I am not worried about any legal. :-) I was just feeling weird that such thing could happen to an IETF working group document. I thought the goal at IETF is providing solutions to public internet communities. Anyway... Will all the drafts/RFCs start putting such a paragraph in the document from now on? :-) Ray -----Original Message----- From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] Sent: Thursday, May 23, 2002 1:39 PM To: Ray Qiu Cc: Ajay Simha; mpls@UU.NET Subject: Re: Intellectual Property Considerations In message <10169FC9AB71D940902FE7EBE7109AA90A6317@rs-sc-exc4.rs.riverstonenet. com>, "Ray Qiu" writes: > Ajay, > > Thanks for the response. What will happen if other people's contributions > are pretty big changes to their idea? :-) > > If people want to apply patent, it seems to make sense for them to take > their document out of IETF working group. > > Thanks. > > Ray Ray, I'm not a lawyer but here is my uninformed opinion. For something to be patented an idea must be unique, original, and non-obvious. When something is in the patent application process, the application is not disclosed so we have no idea what is being applied for. Many patents are granted that should not have been granted and would never hold up in court. Of these, some are challenged and the patent is invalidated. For example, if the patent examiner is unaware of prior work when the patent is enforced it may be challenged and invalidated. If a patent is granted, it can only be challenged if there is an attempt to enforce it. The holder of a patent, realizing that the challenge may be invalidated (or in some cases is almost certain to be invalidated), may decide simply to threaten enforcement but not follow through. If so, the patent is never challenged and remains on the books. A good example of the prior situation is the IBM RISC patents in the 1980s. IBM had numerous patents and tried to threaten Sun, MIPS, and anyone else making a RISC chip. Many people publicly commented, pointing to prior work, and IBM simply didn't pursue the enforcement. The patents remain on the books but in this case are ignored. When and if a patent is granted, it is possible to discuss whether it can safely be ignored. If it is denied, then the Intellectual Property message in an internet-draft or RFC should be removed, but there is no way to tell that the rejection has occurred unless the party who applied informs us. During the time (often years) when there is an application but no decision on the part of the patent office, its all a big mystery. The only thing someone in the IETF can do faced with an Intellectual Property statement in an internet-draft is look at the internet-draft and try to figure out what if anything looks unique, original, and non-obvious. If nothing other than the arrangement of bits is really an original idea, then it is unlikely that a patent will be granted, enforced, and upheld. Since judges that rule on patents are non-technical, whether something would be upheld is anyone's guess, regardless of merit. [IMHO - the patent system does the technical community a great disservice, in this field in particular, but also in others.] It is important to point out that I'm not a lawyer so I can't give legal advice. You may want to consult a lawyer for all of your life's major decisions and the minor ones too and perhaps not even speak to us mere mortals. :-) Curtis > -----Original Message----- > From: Ajay Simha [mailto:asimha@cisco.com] > Sent: Thursday, May 23, 2002 12:39 PM > To: Ray Qiu > Cc: mpls@UU.NET > Subject: Re: Intellectual Property Considerations > > > On Thu, 23 May 2002, Ray Qiu wrote: > > >RQ:Hi, > >RQ: > >RQ:In the draft-ietf-mpls-lsp-ping-00.txt, there is one paragraph called "In > tellectual > >RQ:Property Considerations" where the vendor is seeking patent protection. > But this > >RQ:document is a MPLS working group document! Does it mean other people > >RQ:can not comment on the draft or can not contribute to the draft? Then wh > at is > >RQ:the point of making it a working group document? > > You can comment/contribute but if the patent is approved it is their idea. > It may mean that if a vendor want to use this idea they may have to pay > royality to these folks or get some approval of some sort :) > > -ajay > >RQ: > >RQ:May someone please help me to understand here? > >RQ: > >RQ:Thanks! > >RQ: > >RQ:Ray > >RQ: > >RQ: > > -- > > From owner-mpls@UU.NET Thu May 23 16:58:54 2002 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 QAA27044 for ; Thu, 23 May 2002 16:58:54 -0400 (EDT) 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 QQmqdf07422; Thu, 23 May 2002 20:57:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqdf23101 for mpls-outgoing; Thu, 23 May 2002 20:57:19 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 QQmqdf23096 for ; Thu, 23 May 2002 20:57:08 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 QQmqdf25809 for ; Thu, 23 May 2002 20:56:39 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 QQmqdf15320 for ; Thu, 23 May 2002 20:56:38 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 QAA09128 for ; Thu, 23 May 2002 16:56:35 -0400 (EDT) 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 QAA15048 for ; Thu, 23 May 2002 16:56:35 -0400 (EDT) Message-ID: <3CED57A8.34C3EBE2@marconi.com> Date: Thu, 23 May 2002 16:57:12 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: RSVP-TE : bandwidth decrease References: <20020523202239.23273.qmail@web13409.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gopalkrishna Panicker wrote: > > Thanks. That was helpful. > I was just browsing the RSVP-TE spec. In light of this discussion I > find it interesting that the spec always refers to > "bandwidth-increase" instead of say a "bandwidth-modify". > > I am wondering if make-before-break mechanism should be used when > bandwidth is to be decreased. > > IMO make-before-break was devised to solve the double-counting > issues which we don't have here. The purpose of make-before-break is for situations where the LSP is being rerouted independantly of the routing table - like when the ERO changes. An in-line change of the ERO creates transient instability in the LSP that will result in a temporary loss of connectivity on the data plane. In a service provider network, that is completely unacceptible. I'm not sure what the specific rationale for make-before-break is when the LSP is not rerouting. I think it's in order to prevent a loss of the LSP. In the case of a bandwidth-increase, if you just change the TSPEC, some node may be unable to increase the reservation. The resulting PathErr may cause the LSP to be torn instead of reverted to the smaller reservation. This would be a very bad thing. So instead, we create a new LSP. If the new one fails, the old one is not affected. When doing a bandiwdth decrease, this shouldn't be a concern. If a switch is capable of modifying the bandwidth of an existing LSP in the first place, I would assume that a bandwidth decrease will always succeed. > As mentioned in one of David's earlier emails on the subject, We > could simply change the Sender Tspec and wait for a new updated > Flowspec from the egress to take effect. That would be mu gut feeling, but I wouldn't implement such a feature without further study. I don't trust gut feelings when making a decision that may seriously affect interoperability if I'm wrong. Personally, since make-before-break is required for rerouting and bandwidth-increase, I see no strong reason not to use it for all changes. Once the mechanism is developed, it's simpler to just use it everywhere. -- David From owner-mpls@UU.NET Thu May 23 19:55:43 2002 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 TAA00979 for ; Thu, 23 May 2002 19:55:43 -0400 (EDT) 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 QQmqdr22008; Thu, 23 May 2002 23:54:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqdr12024 for mpls-outgoing; Thu, 23 May 2002 23:54:20 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 QQmqdr12019 for ; Thu, 23 May 2002 23:54:12 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 QQmqdr04242 for ; Thu, 23 May 2002 23:54:04 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqdr20978 for ; Thu, 23 May 2002 23:54:03 GMT 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 TAA14765 for ; Thu, 23 May 2002 19:54:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA00632 for mpls@uu.net; Thu, 23 May 2002 19:54:03 -0400 (EDT) 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 QQmqdr11990 for ; Thu, 23 May 2002 23:53:06 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 QQmqdr00155 for ; Thu, 23 May 2002 23:51:58 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmqdr06539 for ; Thu, 23 May 2002 23:51: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 TAA70471; Thu, 23 May 2002 19:51:38 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200205232351.TAA70471@workhorse.fictitious.org> To: "Ray Qiu" cc: curtis@fictitious.org, "Ajay Simha" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Intellectual Property Considerations In-reply-to: Your message of "Thu, 23 May 2002 13:48:16 PDT." <10169FC9AB71D940902FE7EBE7109AA909C58B@rs-sc-exc4.rs.riverstonenet.com> Date: Thu, 23 May 2002 19:51:38 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <10169FC9AB71D940902FE7EBE7109AA909C58B@rs-sc-exc4.rs.riverstonenet. com>, "Ray Qiu" writes: > Curtis, > > Thanks for the info. I am not worried about any legal. :-) > > I was just feeling weird that such thing could happen to an IETF working gro > up > document. I thought the goal at IETF is providing solutions to public intern > et > communities. Anyway... > > Will all the drafts/RFCs start putting such a paragraph in the document from > now on? :-) > > Ray It might be worth considering writing an independent document based on known prior work and ideas and eliminating any doubt. Its not like ping is a new idea or there is anything new or unique in LSP ping that we can't do without. If I thought there was anything on which a valid Intellectual Property claim could be made, I'd be worried. What could be new - a packet with a timestamp in it? Ping itself? If the patent is narrow enough to stand it is easily avoided, broad enough to not be avoided, easily knocked down due to prior work. Again, I'm not a lawyer so ignore me. I certainly hope the trend toward Intellectual Property notes in internet-drafts reverses. (I also wish Intellectual Property and Internet Protocol didn't both end up with the IP acronym, but there are some things we just have to live with). Curtis From owner-mpls@UU.NET Thu May 23 23:34:12 2002 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 XAA06344 for ; Thu, 23 May 2002 23:34:12 -0400 (EDT) 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 QQmqeg15037; Fri, 24 May 2002 03:33:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqeg26555 for mpls-outgoing; Fri, 24 May 2002 03:33: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 QQmqeg26548 for ; Fri, 24 May 2002 03:33:17 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 QQmqeg07194 for ; Fri, 24 May 2002 03:33:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqeg10623 for ; Fri, 24 May 2002 03:33:03 GMT 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 XAA21341 for ; Thu, 23 May 2002 23:33:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id XAA21350 for mpls@uu.net; Thu, 23 May 2002 23:33:02 -0400 (EDT) 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 QQmqeg26503 for ; Fri, 24 May 2002 03:31:32 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 QQmqeg02062 for ; Fri, 24 May 2002 03:31:26 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQmqeg29066 for ; Fri, 24 May 2002 03:31:26 GMT Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id XAA25675; Thu, 23 May 2002 23:31:24 -0400 (EDT) Date: Thu, 23 May 2002 23:31:24 -0400 (EDT) From: Ajay Simha To: Ray Qiu cc: mpls@UU.NET Subject: RE: Intellectual Property Considerations In-Reply-To: <10169FC9AB71D940902FE7EBE7109AA90A6317@rs-sc-exc4.rs.riverstonenet.com> Message-ID: References: <10169FC9AB71D940902FE7EBE7109AA90A6317@rs-sc-exc4.rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 23 May 2002, Ray Qiu wrote: >RQ:Ajay, >RQ: >RQ:Thanks for the response. What will happen if other people's contributions >RQ:are pretty big changes to their idea? :-) Actually these are orthoganal ideas. Let us say a couple of guys initially cook up a neat idea. What they would do is first file a patent and then create the draft. >RQ: >RQ:If people want to apply patent, it seems to make sense for them to take >RQ:their document out of IETF working group. If the person contributing these ideas has significant contributions there is no reason why this person cannot approach the original folks to add him/her self to the patent or just create a new one. Anyway, think senior folks who have done both should be commenting here not me :) -ajay >RQ: >RQ:Thanks. >RQ: >RQ:Ray >RQ: >RQ: >RQ: >RQ: >RQ:-----Original Message----- >RQ:From: Ajay Simha [mailto:asimha@cisco.com] >RQ:Sent: Thursday, May 23, 2002 12:39 PM >RQ:To: Ray Qiu >RQ:Cc: mpls@UU.NET >RQ:Subject: Re: Intellectual Property Considerations >RQ: >RQ: >RQ:On Thu, 23 May 2002, Ray Qiu wrote: >RQ: >RQ:>RQ:Hi, >RQ:>RQ: >RQ:>RQ:In the draft-ietf-mpls-lsp-ping-00.txt, there is one paragraph called "Intellectual >RQ:>RQ:Property Considerations" where the vendor is seeking patent protection. But this >RQ:>RQ:document is a MPLS working group document! Does it mean other people >RQ:>RQ:can not comment on the draft or can not contribute to the draft? Then what is >RQ:>RQ:the point of making it a working group document? >RQ: >RQ:You can comment/contribute but if the patent is approved it is their idea. >RQ:It may mean that if a vendor want to use this idea they may have to pay >RQ:royality to these folks or get some approval of some sort :) >RQ: >RQ:-ajay >RQ:>RQ: >RQ:>RQ:May someone please help me to understand here? >RQ:>RQ: >RQ:>RQ:Thanks! >RQ:>RQ: >RQ:>RQ:Ray >RQ:>RQ: >RQ:>RQ: >RQ: >RQ: -- From owner-mpls@UU.NET Fri May 24 05:41:09 2002 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 FAA21448 for ; Fri, 24 May 2002 05:41:09 -0400 (EDT) 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 QQmqdc23387; Thu, 23 May 2002 20:00:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqdc28756 for mpls-outgoing; Thu, 23 May 2002 20:00: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 QQmqdc28673 for ; Thu, 23 May 2002 20:00:31 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 QQmqdc12369 for ; Thu, 23 May 2002 20:00:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqdc21895 for ; Thu, 23 May 2002 20:00:03 GMT 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 QAA01606 for ; Thu, 23 May 2002 16:00:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA04889 for mpls@uu.net; Thu, 23 May 2002 16:00:02 -0400 (EDT) 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 QQmqdb25779 for ; Thu, 23 May 2002 19:58: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 QQmqdb08530 for ; Thu, 23 May 2002 19:58:53 GMT Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmqdb07714 for ; Thu, 23 May 2002 19:58:52 GMT Received: (qmail 18633 invoked by uid 104); 23 May 2002 19:58:51 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4204. . Clean. Processed in 0.648302 secs); 23 May 2002 19:58:51 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 23 May 2002 19:58:50 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g4NJwlp23677; Thu, 23 May 2002 12:58:47 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 12:58:50 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03608@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Ray Qiu'" , mpls@UU.NET Subject: RE: Intellectual Property Considerations Date: Thu, 23 May 2002 12:58:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="gb2312" Sender: owner-mpls@UU.NET Precedence: bulk Ray, Any contribution that has patent claim may seek to become a WG document. The WG members must decide whether the benefits of that contribution outweighs the problems associated with that patent (e.g. Royalty fee) or whether there are other methods that could accomplish the same result which don't have patent claim. If they decide in favor of the document, then probably the basics of that document is sound and won't change by WG comments, and the patent will probably stand. However, In rare cases there could be substantial changes to the basics of the document, which in that case I don't think the original patent would apply to that RFC. Yours, -Shahram > -----Original Message----- > From: Ray Qiu [mailto:rqiu@riverstonenet.com] > Sent: Thursday, May 23, 2002 3:24 PM > To: mpls@UU.NET > Subject: Intellectual Property Considerations > > > Hi, > > In the draft-ietf-mpls-lsp-ping-00.txt, there is one > paragraph called "Intellectual > Property Considerations" where the vendor is seeking patent > protection. But this > document is a MPLS working group document! Does it mean other people > can not comment on the draft or can not contribute to the > draft? Then what is > the point of making it a working group document? > > May someone please help me to understand here? > > Thanks! > > Ray > > From owner-mpls@UU.NET Fri May 24 06:33:01 2002 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 GAA22288 for ; Fri, 24 May 2002 06:33:01 -0400 (EDT) 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 QQmqcz05258; Thu, 23 May 2002 19:16:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqcz21829 for mpls-outgoing; Thu, 23 May 2002 19:16:09 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 QQmqcz21783 for ; Thu, 23 May 2002 19:15:58 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 QQmqcz18971 for ; Thu, 23 May 2002 19:15:43 GMT Received: from caduceus.fm.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmr02.intel.com [192.55.52.25]) id QQmqcz16503 for ; Thu, 23 May 2002 19:15:43 GMT Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.46 2002/05/09 18:12:26 root Exp $) with ESMTP id g4NJEJo15476 for ; Thu, 23 May 2002 19:14:19 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.20 2002/05/13 20:36:03 root Exp $) with SMTP id g4NJInS28826 for ; Thu, 23 May 2002 19:18:49 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002052312143221794 ; Thu, 23 May 2002 12:14:32 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 12:15:31 -0700 Message-ID: From: "Feng, Mark" To: "'Gopalkrishna Panicker'" , mpls@UU.NET Subject: RE: RSVP-TE : bandwidth decrease Date: Thu, 23 May 2002 12:15:30 -0700 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 IMO, the exact behavior depends on the implementation, though the end result should be the same. In one behavior, when B receives the PTear, it would remove the reference to sender1 in PSB and RSB; but leave the allocation unchanged (i.e. 20 units). When C receives the PTear, it would generate a new Flowspec of 10 units, since sender1 is removed. When the new Resv message has been propagated back to Ingress, the desired allocation is in place. B could try to guess what the new allocation is, based on the Tspec, before receiving the new Flowspec. IMO, that's entirely up to the implementation. Hope this helps. - Mark > -----Original Message----- > From: Gopalkrishna Panicker [mailto:gopanicker@yahoo.com] > Sent: Thursday, May 23, 2002 11:29 AM > To: mpls@UU.NET > Subject: RSVP-TE : bandwidth decrease > > > Hello, > > Consider the following topology > > > A-----------B----------C > > Let us say > 1. we are using make-before-break and therefore > using SE style. > 2. LSP1 with Sender1 has been signalled with a > bandwidth of 20 units. A is the ingress and C is > the egress. > > Now A decides to reduce the bandwidth to 10 units. > A ceates a new sender template (Sender2) and > Tspec. A then sends the path message towards C. > > After receiving the path message, C computes the > bandwidth to be allocated. Since SE style is being > used, the merged flowspec sent in the resv message > from C to B will continue to say a bandwidth of > 20 units. > The only reason the resv makes it back > to A is because of the new filterspec (Sender2). > > I assuming this is correct. > > Now A issues a path tear for sender1. B will > delete the path state associated with sender1. > B will also delete the corresponding filter spec > from the resv state. > > Now to my question. How does B know that it has > to delete the 10 units of bandwidth reservation ? > > If my understanding is correct, the resv message > from C had carried a merged flowspec and set of > filterspecs (Sender1, Sender2). How does B > determine the orginal flowspec associated with > the filterspec (in this case Sender1) ? > > Should B on rely on the tspec stored in the PSB ? > > > Obviously I am missing something. > > Thanks > > Cheers > Gopal > > > > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > From owner-mpls@UU.NET Fri May 24 07:23:16 2002 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 HAA23516 for ; Fri, 24 May 2002 07:23:16 -0400 (EDT) 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 QQmqfl15420; Fri, 24 May 2002 11:22:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqfl27265 for mpls-outgoing; Fri, 24 May 2002 11:22: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 QQmqfl27260 for ; Fri, 24 May 2002 11:22:07 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 QQmqfl05609 for ; Fri, 24 May 2002 11:21:57 GMT Received: from gorilla.mchh.siemens.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQmqfl09614 for ; Fri, 24 May 2002 11:21:55 GMT Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA07968 for ; Fri, 24 May 2002 13:21:43 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA19515 for ; Fri, 24 May 2002 13:21:44 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 13:21:44 +0200 Message-ID: From: Hummel Heinrich To: mpls@UU.NET Subject: Comments for draft-hummel-mpls-hierarchical-lsp-01.txt appreciate d Date: Fri, 24 May 2002 13:21:42 +0200 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 all, I submitted version 01 of my draft on "Hierarchical LSPs", see draft-hummel-mpls-hierarchical-lsp-01.txt Its goal is to eliminate the N-square problem by building H-LSPs which are concatenations of sub H-LSPs (e.g. of conventional LSPs). Maybe some of you have followed up the thread "PWE3-question" on the pwe3-mailing list which is concerned on this O(n**2) problem as well. Your comments are appreciated. Regards Heinrich Hummel Siemens AG From owner-mpls@UU.NET Mon May 27 06:33:07 2002 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 GAA16005 for ; Mon, 27 May 2002 06:33:07 -0400 (EDT) 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 QQmqqj22427; Mon, 27 May 2002 10:27:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqqj13786 for mpls-outgoing; Mon, 27 May 2002 10:27: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 QQmqqj13777 for ; Mon, 27 May 2002 10:27: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 QQmqqj09737 for ; Mon, 27 May 2002 10:26:53 GMT Received: from tomp.smb.utfors.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQmqqj21717 for ; Mon, 27 May 2002 10:26:52 GMT Received: from utfors.se ([172.20.0.83]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id GWRMKN00.C2Y for ; Mon, 27 May 2002 12:31:35 +0200 Message-ID: <3CF209E6.1070601@utfors.se> Date: Mon, 27 May 2002 12:26:46 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mpls wg Subject: [Fwd: Internet-Draft Cutoff Dates for Yokohama, Japan] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, please note the cut off dates for the Yokhama meeting -00 drafts Monday, June 24th, 2002 at 09:00 US-EST revised drafts Monday, July 1st, 2002 at 09:00 US-EST /Loa -------- Original Message -------- Subject: Internet-Draft Cutoff Dates for Yokohama, Japan Date: Wed, 22 May 2002 15:01:20 -0400 From: Internet-Drafts Administrator To: IETF-Announce: ; NOTE: There are two (2) Internet-Draft Cutoff dates June 24th: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, June 24th, at 09:00 US-EST. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, June 24th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of June 24th will NOT be accepted. July 1st: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, July 1st, 2002 at 09:00 US-EST. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_54.html -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Tue May 28 06:34:40 2002 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 GAA11954 for ; Tue, 28 May 2002 06:34:40 -0400 (EDT) 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 QQmqtu06950; Tue, 28 May 2002 08:39:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqtu26167 for mpls-outgoing; Tue, 28 May 2002 08:39:40 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 QQmqtu26157 for ; Tue, 28 May 2002 08:39:32 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 QQmqtu21441 for ; Tue, 28 May 2002 08:37:58 GMT Received: from smtp2.cluster.oleane.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.cluster.oleane.net [195.25.12.17]) id QQmqtu04114 for ; Tue, 28 May 2002 08:37:57 GMT Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp2.cluster.oleane.net with SMTP id g4S8buJ81380 for ; Tue, 28 May 2002 10:37:56 +0200 (CEST) Message-ID: <007c01c20623$cee177e0$0701a8c0@oleane.com> From: "Peter Lewis" To: Subject: IPoW ' 02 (the IP over WDM international conference), Date: Tue, 28 May 2002 10:43:56 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0075_01C20634.911A9660" 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_0075_01C20634.911A9660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPoW ' 02 (the IP over WDM international conference), will take place in = Paris, France, from June 25 to 28, 2002. All details at: http://www.upperside.fr/ipow01/ipow2001intro.htm =20 ------=_NextPart_000_0075_01C20634.911A9660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
IPoW ' 02 (the IP over WDM = international=20 conference), will take place in Paris, France, from June 25 to 28, = 2002.
All=20 details at:
http://www.uppe= rside.fr/ipow01/ipow2001intro.htm
 
------=_NextPart_000_0075_01C20634.911A9660-- From owner-mpls@UU.NET Tue May 28 06:36:51 2002 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 GAA11973 for ; Tue, 28 May 2002 06:36:51 -0400 (EDT) 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 QQmquc21657; Tue, 28 May 2002 10:36:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQmquc18884 for mpls-outgoing; Tue, 28 May 2002 10:36:00 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 QQmquc18877 for ; Tue, 28 May 2002 10:35:49 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 QQmquc17022 for ; Tue, 28 May 2002 10:35:17 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 QQmquc20295 for ; Tue, 28 May 2002 10:35:15 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 g4SAZDe19575 for ; Tue, 28 May 2002 16:05:14 +0530 (IST) Received: from wipro.com ([10.117.3.140]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GWTHEJ00.9G4; Tue, 28 May 2002 16:05:07 +0530 Message-ID: <3CF35CE1.3307B147@wipro.com> Date: Tue, 28 May 2002 16:03:05 +0530 From: Vinay Vernekar X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: ccamp@ops.ietf.org CC: mpls@UU.NET Subject: Identifying a kind of LSP in GMPLS. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, The draft "draft-ietf-mpls-generalized-signalling-08.txt" specifies the LSP encoding type, switching type and the payload being carried in the Generalized Label Request. It is not clear on how to identify the LSP kind by looking at the values mentioned. Consider the following cases - 1) What are the typical values if a LSP traversing ATM switches is to be established? Is it like - LSP Encoding type - Packet Switching type - L2SC GPID - ATM Mapping. (But the draft specifies ATM mapping for SDH/SONET technologies). 2) What are the values if a LSP traversing FR switches is to be established? There is nothing like GPID - FR?? Please clarify on the above. Regards Vinay From owner-mpls@UU.NET Tue May 28 06:39:33 2002 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 GAA12012 for ; Tue, 28 May 2002 06:39:33 -0400 (EDT) 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 QQmquc25705; Tue, 28 May 2002 10:39:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmquc19178 for mpls-outgoing; Tue, 28 May 2002 10:38: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 QQmquc19169 for ; Tue, 28 May 2002 10:38: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 QQmquc16676 for ; Tue, 28 May 2002 10:38:39 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQmquc14881 for ; Tue, 28 May 2002 10:38:37 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 28 May 2002 16:28:39 +0530 Received: from bharathir (bharathir.future.futsoft.com [10.6.2.6]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g4SAcGA04423; Tue, 28 May 2002 16:08:17 +0530 Reply-To: From: "Bharathi R" To: Cc: Subject: GMPLS - PSC switching capability Date: Tue, 28 May 2002 16:04:09 +0530 Message-Id: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-MS-TNEF-Correlator: Content-Type: multipart/mixed; boundary="----=_NextPart_000_000A_01C20661.4D241580" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C20661.4D241580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Can anyone tell me why GMPLS routing Extension mention 4 different PSC switching capabilities? What is the significance of having 4 different PSC switching capabilities? Thanks & Regards, Bharathi *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** ------=_NextPart_000_000A_01C20661.4D241580 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgkKAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHBQAcABAABAAAAAIAEAEB A5AGAPAKAAAiAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAIQAAAEdNUExTIC0gUFNDIHN3aXRjaGluZyBjYXBhYmlsaXR5AAAAAAIBcQABAAAAFgAAAAHC BjMzF4JW58ZyKBHWi84A0Alv2x8AAAIBHQwBAAAAIgAAAFNNVFA6QkhBUkFUSElSQEZVVFVSRS5G VVRTT0ZULkNPTQAAAAsAAQ4AAAAAQAAGDgAcuS0zBsIBAgEKDgEAAAAYAAAAAAAAAIsAe+9U/tMR myYAgB4DAfHCgAAACwAfDgEAAAACAQkQAQAAACcHAAAjBwAARBEAAExaRnVG7kT0AwAKAHJjcGcx MjVyMgxgYzEDMAEHC2BukQ4QMDMzDxZmZQ+STwH3AqQDYwIAY2gKwHOEZXQC0XBycTIAAJIqCqFu bxJQIDAB0IUB0DYPoDA1MDQUIfMB0BQQNH0HbQKDAFAD1PsR/xMLYhPhFFATshj0FNAbBxMCgzYO UBGdMjM4xRdUIAdtIENFGgQPwE8ajhRAG68ctXlyGgQ1uRGOMTYWMR7/A4JHCdF6axoENiDvGlIi PwOCVOsIcBoENyRPNydxJZ8DgpAoSGViCXB3KRoE/xuRJ64bnym2BxABoA3gKpW6OSsfOCQxLG8D gkIHQPZ0DeACgzcLwhZ7G3gHE70dBjcWPx6oM7UgVTcdke8WbCHoM7QjiDcewTduJWb7M7Qm5jcg 0TdtKJcztCor/jckMTzOMzwtuyiSN20vt68ztDFGApEI5jsJbzBFv/plDjA1RupIAUe/SMlG1P9I 8kdfSy9K7UpvSJ9G7xBg/DI4ULpR0VGPUplG1FLCv1EvVP9UvVQ/Um9WNDkOUB9ZhFrhUwNa4AKC c3R5qmwHkGgJ4HQAAHEDITxsaQFABRABQAPwZGPsdGwKsQBgcwqwXiAW4BFeYm51bQIAYWF1xHRv AGBkanVcUAUQeGdodF2BCgFdUAoBafkBkHAwAzE0kgwBD1IUEH44AFAQGAjQCcBd4GIjbh5wYnlk EA+SAzBzbmV+eBcwB7AFsADAAnMTEGMucw+QAzBf4GRhQGl2nROARAEQX5AxYCBQCsDGYQnAYWBo IEYCIVwTRjEg0F0SZmktD5A4z2DSadNdnCpQZHIJUGtysxaga3J3NFAhFwBwAdD/ZtFej1+fYKZp 02FPYl9jb/1kfmJtMAmAAiBwcWVjaTCzZ/BgoXQtaJADYTowMEJvdjBTdWJqBZB0wXYwRGF0ZTpo 5CQw/2lvan9rj2yfba9uv2/MXKD/fTALgA4ScHEMMHCkDlBxL89yP3NPdF91Z1JlZ1AXAf4gKjB9 MASQaOQncHf/eQ+/eh97L3w+CGBeEAuAZVyAvWdQbAFAfT9+T39UMI9w5QjQYgqwdDh/6HEED5B+ Mh7AEBaRMYHkE1AXcG/8b2aCP4NPhFeQAIVwC1C8eS9ooInQCxGF5XNo5P8sMIbfh++I/4oPfD+N D2/P/3DfgW+TL5Q/lU+WUnZSdfT/dykukF0fXi+cH2BPnmSPs345nq+fv6DPod+ESKrgRNxvY6gg CfAFQE2ecGY295sTZwarB2MAQK6oZrKnYJ+FoQIgM+FcQAWgbXATYnZFAMADEFNcYgHQXBMy/wBQ pf+nD6gfqS+eb6vPrN/vre+EC7XwtNAttPIGALlgdbQAdAhwZUTjExBF0HZBAlEge1VuaxNQd80V 0X0KobOxdzFa0BPg9cI0aCHgOBuAAzC24cHQ97cQmcEBgG52sABgCfBnAJuwAJJheAtgAkBveQnw +lxlgHBcoAAgC5ATUGfBP5nAt5AA4QIwAmAAgGJk9wwwE1EKsGMBEAWwZ8ACAaNl8H8yZVxoBbB6 xRJkZGcAwHJnC4HJ8GjnyCMvoAFBZ3bKuclxuWCfneEx8ABQy0HMNTk4HsD/yoLJcMKQyzPOA3bA xiAAcF8LMMURXGCzsA5QdgiQd/prC4BkHsDP8gTwB0AQYX8BQA4AmZJcsLjw0VUCEG/3uZC3kJXg dMHgjFHEYtLn/7mAAMC4sLeQkmHHkLmAuPH/CTK5IIxwAlAHQAuQ1fECUb/QQbZQ0vDQ4bcQAmB3 1rOfAlEAIAnAtlDEkHJryJF/seIXIRLyd0C0gMWBE4BDqDpcXHWAb2hBbWiQ9wMQB5DaME0N4ANg s+ABgNwgTwEgDeDJUFzb5g+T68YAtPIuhCB0wiAXELcQ/5ZwufJlgAFAxOHU8ASQyVB33fKMQryS MxPw3eRnlGOPwWETAgCABZBsdmwAUP+4MQUAuGDhgQGQACDiAtBB/7BBAcHhcRbgD3AAALgwDND5 AZAgLsC04YYOUOIixtH34o/jn+SvbA/AuDAFgeZf++dv6H9sHsC4MNcg5i/q733r9Cnk7CDQ6b/u n+vUYv8qEAKR77/hs8Lh7X/yP/NP/fRfbCdw9ZLib/b/+A/k7P8sMPWf+x/8L/0/4eAukPof//+v AL8BxAr5tkC2L7c/uE9/uV+6b7t/vI9ki0URslZI8GksDQoGkh0AHOEVwG55aLATgHdAbAdwsDAg CHdoeSNwTVBMU24gIQAJ8H9xIEUCslZF82WQRlBzaWiwEeEGABRiPDQgZxDccN8hsFFQU+xDIDdh 1vBoEwLQ4AiAry3wB6AxcNsAPxCFVzfg/2fgN4ARkFywFhDAIRVQLgDrITDIUCCSwCA34M/wEx1X FS8WPxdKVOuBayzwJtWFYWeWUXMQdkI34XcwLxxAE0oQhUTwACEwAAsAAIAIIAYAAAAAAMAAAAAA AABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAWACCAGAAAA AADAAAAAAAAARgAAAABShQAAP3EBAB4AJYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAA ADkuMAADACaACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsAL4AIIAYAAAAAAMAAAAAAAABG AAAAAA6FAAAAAAAAAwAwgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADADKACCAGAAAAAADA AAAAAAAARgAAAAAYhQAAAAAAAAsA14AIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAACwDegAgg BgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEAAAACAfgPAQAAABAAAACLAHvvVP7TEZsmAIAeAwHxAgH6 DwEAAAAQAAAAiwB771T+0xGbJgCAHgMB8QIB+w8BAAAAUQAAAAAAAAA4obsQBeUQGqG7CAArKlbC AABQU1RQUlguRExMAAAAAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XE1haWxEdGxzXG91dGxvb2su cHN0AAAAAAMA/g8FAAAAAwANNP03AAACAX8AAQAAADwAAAA8TkRCQkpMQ0dJTElBR0ZPTUZGQVBN RURMS0VBQi5iaGFyYXRoaXJAZnV0dXJlLmZ1dHNvZnQuY29tPgADAAYQPELLKQMABxCrAAAAAwAQ EAAAAAADABEQAAAAAB4ACBABAAAAZQAAAEhJLENBTkFOWU9ORVRFTExNRVdIWUdNUExTUk9VVElO R0VYVEVOU0lPTk1FTlRJT040RElGRkVSRU5UUFNDU1dJVENISU5HQ0FQQUJJTElUSUVTP1dIQVRJ U1RIRVNJR05JRkkAAAAAsJE= ------=_NextPart_000_000A_01C20661.4D241580-- From owner-mpls@UU.NET Tue May 28 07:34:59 2002 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 HAA12844 for ; Tue, 28 May 2002 07:34:59 -0400 (EDT) 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 QQmqug01128; Tue, 28 May 2002 11:34:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqug15601 for mpls-outgoing; Tue, 28 May 2002 11:34: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 QQmqug15596 for ; Tue, 28 May 2002 11:34:10 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 QQmqug12112 for ; Tue, 28 May 2002 11:33:45 GMT Received: from xover.netplane.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cnxt10002.conexant.com [198.62.10.2]) id QQmqug29793 for ; Tue, 28 May 2002 11:33:44 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 07:29:53 -0400 Message-ID: From: "Manral, Vishwas" To: "'bharathir@future.futsoft.com'" , mpls@UU.NET Cc: gmpls-ops@mplsrc.com Subject: RE: GMPLS - PSC switching capability Date: Tue, 28 May 2002 07:33:14 -0400 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 Bharathi, Though I do not know much about GMPLS, however the draft http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-04.txt states that "If an interface is of type PSC-1 through PSC-4, it means that the node receiving data over this interface can switch the received data on a packet-by-packet basis, based on the label carried in the "shim" header [RFC3032]. The various levels of PSC establish a hierarchy of LSPs tunneled within LSPs." Hope this is what you were looking for, Thanks, Vishwas > -----Original Message----- > From: Bharathi R [mailto:bharathir@future.futsoft.com] > Sent: Tuesday, May 28, 2002 4:04 PM > To: mpls@UU.NET > Cc: gmpls-ops@mplsrc.com > Subject: GMPLS - PSC switching capability > > Hi, > Can anyone tell me why GMPLS routing Extension mention 4 different PSC > switching capabilities? > What is the significance of having 4 different PSC switching capabilities? > Thanks & Regards, > Bharathi > From owner-mpls@UU.NET Tue May 28 08:50:32 2002 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 IAA16101 for ; Tue, 28 May 2002 08:50:32 -0400 (EDT) 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 QQmqul29982; Tue, 28 May 2002 12:49:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqul14597 for mpls-outgoing; Tue, 28 May 2002 12:49:23 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 QQmqul14590 for ; Tue, 28 May 2002 12:49: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 QQmqul24319 for ; Tue, 28 May 2002 12:48:19 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe35.law9.hotmail.com [64.4.8.92]) id QQmqul14527 for ; Tue, 28 May 2002 12:48:18 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 28 May 2002 05:48:18 -0700 X-Originating-IP: [212.199.233.65] From: "Doug Degan" To: Subject: question Fast-Reroute Resv manipulation Date: Tue, 28 May 2002 15:48:14 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 28 May 2002 12:48:18.0143 (UTC) FILETIME=[F0C026F0:01C20645] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit consider this basic FRR topology - primary protected LSP is configured and bypass is ready for use if needed: [I]---[PLR]----[T]-----[MP]--------[E] \ / \------------------/ BYPASS/DETOUR and the scenario: 1) MP send RESV-MSG to T 2) Link between PLR & T fails 3) T get the RESV-MSG - will it send RESV_ERR downstream cause the link is down? * should every router block RESV_ERR messages for protected LSP? thanks alot. From owner-mpls@UU.NET Tue May 28 09:00:03 2002 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 JAA16553 for ; Tue, 28 May 2002 09:00:03 -0400 (EDT) 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 QQmqul13452; Tue, 28 May 2002 12:59:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqul15333 for mpls-outgoing; Tue, 28 May 2002 12:59: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 QQmqul15324 for ; Tue, 28 May 2002 12:59: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 QQmqul14512 for ; Tue, 28 May 2002 12:59:07 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqul29250 for ; Tue, 28 May 2002 12:59:03 GMT 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 IAA09173 for ; Tue, 28 May 2002 08:59:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA18442 for mpls@uu.net; Tue, 28 May 2002 08:59:02 -0400 (EDT) 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 QQmqme09525 for ; Sun, 26 May 2002 07:03: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 QQmqme14056 for ; Sun, 26 May 2002 07:02:41 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f54.law15.hotmail.com [64.4.23.54]) id QQmqme25260 for ; Sun, 26 May 2002 07:02:40 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 26 May 2002 00:02:40 -0700 Received: from 12.234.67.129 by lw15fd.law15.hotmail.msn.com with HTTP; Sun, 26 May 2002 07:02:39 GMT X-Originating-IP: [12.234.67.129] From: "Chetan Pinto" To: p_sharma@trillium.com Cc: mpls@UU.NET, eric.gray@sandburst.com Subject: Re: RFC 3036: Label Mapping Question Date: Sun, 26 May 2002 00:02:39 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 May 2002 07:02:40.0148 (UTC) FILETIME=[531DBD40:01C20483] Sender: owner-mpls@UU.NET Precedence: bulk >Hi, > >I've one question on LDP. What should be the behaviour of the LDP module >when it receives the label mapping message for a FEC when the label >retention mode is liberal and that FEC (e.g. partial IP prefix) is not >visible to the local routing module? Should it store the label just >received >or send out label release message? "Should" store it >Here, the routing module just doesn't >have any information abt. this IP prefix. On querying, the routing module >returns "route not available" or "no information abt. the route". > >As per the LDP specs., it's implicit/apparent that label distribution >entities and routing entities should work in tandem and should remain in >synch. So, what should be the behaviour in this special case where LDP sees >some FEC but that FEC is not visible to routing entity? Before the Routing information could be propagated, the label mapping may be sent. This may be 'cos of a timing difference between the LDP and Routing entities [due to implementation behaviour]. The Routing entity may be able to send the routing information later [say in a time frame of a few seconds after the label mapping message] > >The following from RFC 3036, doesn't talk abt. this case explicitly: >LMp.12 Is MsgSource the Next Hop for FEC? If so, goto LMp.14. >Should the boolean expression in the step mentioned above be considered >"FALSE" in this specific scenario? >Any response will be greatly appreciated. >Thanks. >Prem > chetan _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-mpls@UU.NET Tue May 28 09:13:53 2002 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 JAA17150 for ; Tue, 28 May 2002 09:13:52 -0400 (EDT) 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 QQmqum02527; Tue, 28 May 2002 13:13:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqum08276 for mpls-outgoing; Tue, 28 May 2002 13:13:11 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 QQmqum08269 for ; Tue, 28 May 2002 13:13:03 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 QQmqum03134 for ; Tue, 28 May 2002 13:12:22 GMT Received: from fsnt.future.futsoft.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQmqum01033 for ; Tue, 28 May 2002 13:12:20 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 28 May 2002 19:02:20 +0530 Received: from bharathir (bharathir.future.futsoft.com [10.6.2.6]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g4SDBvA14645; Tue, 28 May 2002 18:41:57 +0530 Reply-To: From: "Bharathi R" To: "Manral, Vishwas" , Subject: RE: GMPLS - PSC switching capability Date: Tue, 28 May 2002 18:37:51 +0530 Message-Id: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Vishwas, If my understanding is correct, "The Various levels of PSC" means PSC-1, PSC-2..PSC-4? If so then in PSC-2 label stack depth is 2 and PSC-3 means label stack of depth 3 and so on. If so then why it is restricted to 4 levels? Thanks & Regards, Bharathi -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net] On Behalf Of Manral, Vishwas Sent: Tuesday, 28 May 2002 5:03 PM To: 'bharathir@future.futsoft.com'; mpls@uu.net Cc: gmpls-ops@mplsrc.com Subject: RE: GMPLS - PSC switching capability Bharathi, Though I do not know much about GMPLS, however the draft http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-04.txt states that "If an interface is of type PSC-1 through PSC-4, it means that the node receiving data over this interface can switch the received data on a packet-by-packet basis, based on the label carried in the "shim" header [RFC3032]. The various levels of PSC establish a hierarchy of LSPs tunneled within LSPs." Hope this is what you were looking for, Thanks, Vishwas > -----Original Message----- > From: Bharathi R [mailto:bharathir@future.futsoft.com] > Sent: Tuesday, May 28, 2002 4:04 PM > To: mpls@UU.NET > Cc: gmpls-ops@mplsrc.com > Subject: GMPLS - PSC switching capability > > Hi, > Can anyone tell me why GMPLS routing Extension mention 4 different PSC > switching capabilities? > What is the significance of having 4 different PSC switching capabilities? > Thanks & Regards, > Bharathi > *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Tue May 28 09:48:54 2002 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 JAA18651 for ; Tue, 28 May 2002 09:48:54 -0400 (EDT) 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 QQmqup19923; Tue, 28 May 2002 13:48:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqup11315 for mpls-outgoing; Tue, 28 May 2002 13:48:23 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 QQmqup11310 for ; Tue, 28 May 2002 13:48:12 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 QQmqup18257 for ; Tue, 28 May 2002 13:48:04 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqup10090 for ; Tue, 28 May 2002 13:48:02 GMT 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 JAA11533 for ; Tue, 28 May 2002 09:48:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA24202 for mpls@uu.net; Tue, 28 May 2002 09:48:02 -0400 (EDT) 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 QQmqup11268 for ; Tue, 28 May 2002 13:47:04 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 QQmqup01518 for ; Tue, 28 May 2002 13:46:37 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmqup17047 for ; Tue, 28 May 2002 13:46: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 JAA93717; Tue, 28 May 2002 09:46:13 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200205281346.JAA93717@workhorse.fictitious.org> To: bharathir@future.futsoft.com cc: "Manral, Vishwas" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: GMPLS - PSC switching capability In-reply-to: Your message of "Tue, 28 May 2002 18:37:51 +0530." Date: Tue, 28 May 2002 09:46:13 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , "Bharat hi R" writes: > Hi Vishwas, > If my understanding is correct, "The Various levels of PSC" means PSC-1, > PSC-2..PSC-4? > If so then in PSC-2 label stack depth is 2 and PSC-3 means label stack of > depth 3 and so on. > If so then why it is restricted to 4 levels? > Thanks & Regards, > Bharathi PSC-1 would be N+1, where N is the number of labels that already exist. For example, LSPs are already used with VPN label, LDP label, MPLS/TE label with no hierarchy designation. This would add up to 4 levels of hierarchy intended to improve scaling to whatever labels already exist. Also note that a PSC-3 LSP can contain an LSP with no hierarchy designation, a PSC-1, a PSC-2, but not another PSC-3 or anything higher in the hierarchy. So PSC-3 does not mean 3 labels, nor does it mean N+3. Curtis From owner-mpls@UU.NET Tue May 28 10:24:39 2002 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 KAA20028 for ; Tue, 28 May 2002 10:24:39 -0400 (EDT) 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 QQmqur05090; Tue, 28 May 2002 14:22:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqur05826 for mpls-outgoing; Tue, 28 May 2002 14: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 QQmqur05819 for ; Tue, 28 May 2002 14:21:48 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 QQmqur20371 for ; Tue, 28 May 2002 14:21:25 GMT Received: from fsnt.future.futsoft.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQmqur04073 for ; Tue, 28 May 2002 14:21:24 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 28 May 2002 20:11:28 +0530 Received: from suryam (suryam.future.futsoft.com [10.6.2.43]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g4SEL4A18943; Tue, 28 May 2002 19:51:05 +0530 Reply-To: From: "M.N.V.Suryanarayana" To: Cc: Subject: RE: GMPLS - PSC switching capability Date: Tue, 28 May 2002 19:44:50 +0530 Message-Id: <000001c20652$08b72360$2b02060a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Can someone provide an example in which the interface switching capability is set to PSC-2/PSC-3/PSC-4. The examples in section 7 of draft-ietf-ccamp-gmpls-routing-04.txt does not cover the PSC-2/PSC-3/PSC-4 interface switching capability. Thanks & Regards, Surya > -----Original Message----- > From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Manral, > Vishwas > Sent: Tuesday, 28 May 2002 5:03 PM > To: 'bharathir@future.futsoft.com'; mpls@uu.net > Cc: gmpls-ops@mplsrc.com > Subject: RE: GMPLS - PSC switching capability > > > Bharathi, > > Though I do not know much about GMPLS, however the draft > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rou ting-04.txt states that "If an interface is of type PSC-1 through PSC-4, it means that the node receiving data over this interface can switch the received data on a packet-by-packet basis, based on the label carried in the "shim" header [RFC3032]. The various levels of PSC establish a hierarchy of LSPs tunneled within LSPs." Hope this is what you were looking for, Thanks, Vishwas > -----Original Message----- > From: Bharathi R [mailto:bharathir@future.futsoft.com] > Sent: Tuesday, May 28, 2002 4:04 PM > To: mpls@UU.NET > Cc: gmpls-ops@mplsrc.com > Subject: GMPLS - PSC switching capability > > Hi, > Can anyone tell me why GMPLS routing Extension mention 4 different PSC > switching capabilities? > What is the significance of having 4 different PSC switching capabilities? > Thanks & Regards, > Bharathi > *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Tue May 28 15:53:04 2002 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 PAA29225 for ; Tue, 28 May 2002 15:53:04 -0400 (EDT) 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 QQmqvn05584; Tue, 28 May 2002 19:52:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqvn19644 for mpls-outgoing; Tue, 28 May 2002 19:52: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 QQmqvn19632 for ; Tue, 28 May 2002 19:52:25 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 QQmqvn02906 for ; Tue, 28 May 2002 19:51:24 GMT Received: from mailwest3.unispherenetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.194.140.2]) id QQmqvn16719 for ; Tue, 28 May 2002 19:51:24 GMT Received: by uniwest3.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 15:51:22 -0400 Message-ID: <41AC1CD8464BD611BF3C00C04F1FDD3CADDE@uniwest3.it.west.unispherenetworks.com> From: "Chapman, Ken" To: "'mpls@uu.net'" Cc: "Houlik, Patty" , "Scano, John" Subject: draft-ietf-mpls-tc-mib-03.txt Date: Tue, 28 May 2002 15:51:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20681.07420430" 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_01C20681.07420430 Content-Type: text/plain; charset="iso-8859-1" Hi, I'm new to this list so I appologize if this issue has already been addressed. I have a minor issue with the MIB definition in draft-ietf-mpls-tc-mib-03.txt. It "IMPORTS transmission FROM RFC1213-MIB". This MIB is being written as an SMIv2 MIB (SNMPv3). RFC1213-MIB is an SMIv1 MIB (SNMPv1). SMIv2 MIBs should not import from SMIv1 MIBs if it can be avoided. Therefore, "transmission" should be imported from SNMPv2-SMI instead. Thanks. Ken ------_=_NextPart_001_01C20681.07420430 Content-Type: text/html; charset="iso-8859-1" Blue Stationery
Hi,
I'm new to this list so I appologize if this issue has already been addressed.
I have a minor issue with the MIB definition in draft-ietf-mpls-tc-mib-03.txt.
It "IMPORTS transmission FROM RFC1213-MIB". 
This MIB is being written as an SMIv2 MIB (SNMPv3).
RFC1213-MIB is an SMIv1 MIB (SNMPv1).
SMIv2 MIBs should not import from SMIv1 MIBs if it can be avoided.
Therefore, "transmission" should be imported from SNMPv2-SMI instead.
Thanks.
    Ken
------_=_NextPart_001_01C20681.07420430-- From owner-mpls@UU.NET Tue May 28 16:08:57 2002 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 QAA29580 for ; Tue, 28 May 2002 16:08:57 -0400 (EDT) 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 QQmqvo10434; Tue, 28 May 2002 20:08:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqvo11619 for mpls-outgoing; Tue, 28 May 2002 20:08:21 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 QQmqvo11511 for ; Tue, 28 May 2002 20:08:11 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 QQmqvo26657 for ; Tue, 28 May 2002 20:07:52 GMT Received: from mailwest3.unispherenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.194.140.2]) id QQmqvo27428 for ; Tue, 28 May 2002 20:07:52 GMT Received: by uniwest3.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 16:07:52 -0400 Message-ID: <41AC1CD8464BD611BF3C00C04F1FDD3CADDF@uniwest3.it.west.unispherenetworks.com> From: "Chapman, Ken" To: "'mpls@uu.net'" Cc: "Houlik, Patty" , "Scano, John" Subject: draft-ietf-mpls-lsr-mib-08.txt Date: Tue, 28 May 2002 16:07:48 -0400 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, I'm new to this list so I apologize if this issue has already been addressed. In the "MplsOutSegmentEntry ::= SEQUENCE", mplsOutSegmentIfIndex has a syntax of InterfaceIndex, while in the mplsOutSegmentIfIndex OBJECT-TYPE definition, the SYNTAX is InterfaceIndexOrZero. This is an error. Since the DEFVAL is "0", I assume that the correct syntax is InterfaceIndexOrZero. Please note that making this correction eliminates the need to import InterfaceIndex for IF-MIB. Thanks. Ken From owner-mpls@UU.NET Tue May 28 16:20:16 2002 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 QAA29902 for ; Tue, 28 May 2002 16:20:16 -0400 (EDT) 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 QQmqvp15553; Tue, 28 May 2002 20:19:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqvp13712 for mpls-outgoing; Tue, 28 May 2002 20:19: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 QQmqvp13707 for ; Tue, 28 May 2002 20:19:32 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 QQmqvp00789 for ; Tue, 28 May 2002 20:19:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqvp12541 for ; Tue, 28 May 2002 20:19:02 GMT 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 QAA11871 for ; Tue, 28 May 2002 16:19:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA02811 for mpls@uu.net; Tue, 28 May 2002 16:19:02 -0400 (EDT) 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 QQmqvp13628 for ; Tue, 28 May 2002 20:18:03 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 QQmqvp13912 for ; Tue, 28 May 2002 20:15:22 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 QQmqvp08775 for ; Tue, 28 May 2002 20:15:22 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 g4SKFnAR029295; Tue, 28 May 2002 16:15:49 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122]) by bucket.cisco.com (Mirapoint) with ESMTP id ABB88389; Tue, 28 May 2002 16:15:18 -0400 (EDT) Message-Id: <4.3.2.7.2.20020528161023.01ad9318@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 May 2002 16:15:17 -0400 To: "Chapman, Ken" From: "Thomas D. Nadeau" Subject: Re: draft-ietf-mpls-tc-mib-03.txt Cc: "'mpls@uu.net'" , "Houlik, Patty" , "Scano, John" In-Reply-To: <41AC1CD8464BD611BF3C00C04F1FDD3CADDE@uniwest3.it.west.unis pherenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >I'm new to this list so I appologize if this issue has already been addressed. >I have a minor issue with the MIB definition in draft-ietf-mpls-tc-mib-03.txt. >It "IMPORTS transmission FROM RFC1213-MIB". >This MIB is being written as an SMIv2 MIB (SNMPv3). >RFC1213-MIB is an SMIv1 MIB (SNMPv1). >SMIv2 MIBs should not import from SMIv1 MIBs if it can be avoided. >Therefore, "transmission" should be imported from SNMPv2-SMI instead. >Thanks. > Ken Hi Ken, That is correct. The newest version that is in Mib Doctor review has the following IMPORTS clause: MPLS-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, Unsigned32, Integer32, transmission FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; It will soon be published when the other MPLS MIBs have finished MIB doctor review. --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Tue May 28 16:21:03 2002 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 QAA29954 for ; Tue, 28 May 2002 16:21:03 -0400 (EDT) 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 QQmqvp16750; Tue, 28 May 2002 20:20:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqvp13737 for mpls-outgoing; Tue, 28 May 2002 20:20:11 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 QQmqvp13732 for ; Tue, 28 May 2002 20:20:06 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 QQmqvp00810 for ; Tue, 28 May 2002 20:19:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqvp12555 for ; Tue, 28 May 2002 20:19:02 GMT 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 QAA11875 for ; Tue, 28 May 2002 16:19:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA02822 for mpls@uu.net; Tue, 28 May 2002 16:19:02 -0400 (EDT) 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 QQmqvp13636 for ; Tue, 28 May 2002 20:18:10 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 QQmqvp19003 for ; Tue, 28 May 2002 20:17:32 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 QQmqvp12001 for ; Tue, 28 May 2002 20:17:32 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 g4SKHxMi029522; Tue, 28 May 2002 16:17:59 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122]) by bucket.cisco.com (Mirapoint) with ESMTP id ABB88442; Tue, 28 May 2002 16:17:29 -0400 (EDT) Message-Id: <4.3.2.7.2.20020528161543.01c98350@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 May 2002 16:17:28 -0400 To: "Chapman, Ken" From: "Thomas D. Nadeau" Subject: Re: draft-ietf-mpls-lsr-mib-08.txt Cc: "'mpls@uu.net'" , "Houlik, Patty" , "Scano, John" In-Reply-To: <41AC1CD8464BD611BF3C00C04F1FDD3CADDF@uniwest3.it.west.unis pherenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I believe that Bert has commented on this and we are fixing it now. BTW, the MPLS-LSR, LDP, TE, FTN, and TC MIBs are all in MIB doctor review now with Bert Wijnen, A.D. presiding over the review process. --Tom >I'm new to this list so I apologize if this issue has already been >addressed. >In the "MplsOutSegmentEntry ::= SEQUENCE", mplsOutSegmentIfIndex has a >syntax of InterfaceIndex, >while in the mplsOutSegmentIfIndex OBJECT-TYPE definition, the SYNTAX is >InterfaceIndexOrZero. >This is an error. >Since the DEFVAL is "0", I assume that the correct syntax is >InterfaceIndexOrZero. >Please note that making this correction eliminates the need to import >InterfaceIndex for IF-MIB. >Thanks. > Ken ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Tue May 28 19:26:58 2002 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 TAA04001 for ; Tue, 28 May 2002 19:26:58 -0400 (EDT) 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 QQmqwb24613; Tue, 28 May 2002 23:26:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqwb03277 for mpls-outgoing; Tue, 28 May 2002 23:26:15 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 QQmqwb03272 for ; Tue, 28 May 2002 23:26:13 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 QQmqwb14535 for ; Tue, 28 May 2002 23:26:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqwb17161 for ; Tue, 28 May 2002 23:26:02 GMT 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 TAA21911 for ; Tue, 28 May 2002 19:26:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA21835 for mpls@uu.net; Tue, 28 May 2002 19:26:02 -0400 (EDT) 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 QQmqwb02987 for ; Tue, 28 May 2002 23:24: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 QQmqwb21409 for ; Tue, 28 May 2002 23:24:17 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sword.cisco.com [161.44.208.100]) id QQmqwb14877 for ; Tue, 28 May 2002 23:24:16 GMT Received: from ZALI-W2K.cisco.com (che-vpn2-37.cisco.com [10.86.244.37]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id TAA07535; Tue, 28 May 2002 19:24:09 -0400 (EDT) Message-Id: <4.3.2.7.2.20020528191524.0229edf0@sword.cisco.com> X-Sender: zali@sword.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 May 2002 19:24:07 -0400 To: , From: Zafar Ali Subject: RE: GMPLS - PSC switching capability Cc: In-Reply-To: <000001c20652$08b72360$2b02060a@future.futsoft.com> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_34440392==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_34440392==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 07:44 PM 5/28/2002 +0530, M.N.V.Suryanarayana wrote: >Hi, > >Can someone provide an example in which the interface switching capability >is set to PSC-2/PSC-3/PSC-4. The examples in section 7 of >draft-ietf-ccamp-gmpls-routing-04.txt does not cover the >PSC-2/PSC-3/PSC-4 interface switching capability. Hi Suryanarayana, You can construct a deployment scenario by thinking in terms of VP and VC level switching hierarchy in ATM. This way you can aggregate many flows into a single LSP at the higher level in the hierarchy, etc. While ATM hierarchy is limited to the two level, MPLS technology can support such (packet) hierarchy at PSC-1, 2, ..., 4 levels. Thanks Regards... Zafar >Thanks & Regards, >Surya > > > -----Original Message----- > > From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Manral, > > Vishwas > > Sent: Tuesday, 28 May 2002 5:03 PM > > To: 'bharathir@future.futsoft.com'; mpls@uu.net > > Cc: gmpls-ops@mplsrc.com > > Subject: RE: GMPLS - PSC switching capability > > > > > > Bharathi, > > > > Though I do not know much about GMPLS, however the draft > > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rou >ting-04.txt > >states that >"If an interface is of type PSC-1 through PSC-4, it means that the node >receiving data over this interface can switch the received data on a >packet-by-packet basis, based on the label carried in the "shim" header >[RFC3032]. The various levels of PSC establish a hierarchy of LSPs tunneled >within LSPs." >Hope this is what you were looking for, > >Thanks, >Vishwas > > -----Original Message----- > > From: Bharathi R [mailto:bharathir@future.futsoft.com] > > Sent: Tuesday, May 28, 2002 4:04 PM > > To: mpls@UU.NET > > Cc: gmpls-ops@mplsrc.com > > Subject: GMPLS - PSC switching capability > > > > Hi, > > Can anyone tell me why GMPLS routing Extension mention 4 different PSC > > switching capabilities? > > What is the significance of having 4 different PSC switching capabilities? > > Thanks & Regards, > > Bharathi > > > >*************************************************************************** >This message is proprietary to Future Software Limited (FSL) >and is intended solely for the use of the individual to whom it >is addressed. It may contain privileged or confidential information >and should not be circulated or used for any purpose other than for >what it is intended. > >If you have received this message in error, please notify the >originator immediately. If you are not the intended recipient, >you are notified that you are strictly prohibited from using, >copying, altering, or disclosing the contents of this message. >FSL accepts no responsibility for loss or damage arising from >the use of the information transmitted by this email including >damage from virus. >*************************************************************************** =============================================== Zafar Ali Cisco Systems 100 S Main St. #200 Ann Arbor, MI 48104. Mobile: (734) 276-2459, Off: (734) 302-4143, Fax: (734) 302-4190 email: zali@cisco.com --=====================_34440392==_.ALT Content-Type: text/html; charset="us-ascii" At 07:44 PM 5/28/2002 +0530, M.N.V.Suryanarayana wrote:
Hi,

Can someone provide an example in which the interface switching capability
is set to PSC-2/PSC-3/PSC-4. The examples in section 7 of
draft-ietf-ccamp-gmpls-routing-04.txt does not cover the
PSC-2/PSC-3/PSC-4 interface switching capability.

Hi Suryanarayana,

You can construct a deployment scenario by thinking in terms of VP and VC level switching hierarchy in ATM. This way you can aggregate many flows into a single LSP at the higher level in the hierarchy, etc. While ATM hierarchy is limited to the two level, MPLS technology can support such (packet) hierarchy at PSC-1, 2, ..., 4 levels.

Thanks

Regards... Zafar

Thanks & Regards,
Surya

> -----Original Message-----
> From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Manral,
> Vishwas
> Sent: Tuesday, 28 May 2002 5:03 PM
> To: 'bharathir@future.futsoft.com'; mpls@uu.net
> Cc: gmpls-ops@mplsrc.com
> Subject: RE: GMPLS - PSC switching capability
>
>
> Bharathi,
>
> Though I do not know much about GMPLS, however the draft
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rou
ting-04.txt

states that
"If an interface is of type PSC-1 through PSC-4, it means that the node
receiving data over this interface can switch the received data on a
packet-by-packet basis, based on the label carried in the "shim" header
[RFC3032]. The various levels of PSC establish a hierarchy of LSPs tunneled
within LSPs."
Hope this is what you were looking for,

Thanks,
Vishwas
>  -----Original Message-----
> From:         Bharathi R [mailto:bharathir@future.futsoft.com]
> Sent: Tuesday, May 28, 2002 4:04 PM
> To:   mpls@UU.NET
> Cc:   gmpls-ops@mplsrc.com
> Subject:      GMPLS - PSC switching capability
>
> Hi,
> Can anyone tell me why GMPLS routing Extension mention 4 different PSC
> switching capabilities?
> What is the significance of having 4 different PSC switching capabilities?
> Thanks & Regards,
> Bharathi
>

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************
===============================================
Zafar Ali
Cisco Systems
100 S Main St. #200
Ann Arbor, MI 48104.
Mobile: (734) 276-2459, Off: (734) 302-4143, Fax: (734) 302-4190
email: zali@cisco.com --=====================_34440392==_.ALT-- From owner-mpls@UU.NET Tue May 28 19:59:37 2002 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 TAA04488 for ; Tue, 28 May 2002 19:59:37 -0400 (EDT) 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 QQmqwd00694; Tue, 28 May 2002 23:59:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqwd05541 for mpls-outgoing; Tue, 28 May 2002 23:58: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 QQmqwd05534 for ; Tue, 28 May 2002 23:58:49 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 QQmqwd00427 for ; Tue, 28 May 2002 23:58:16 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 QQmqwd29478 for ; Tue, 28 May 2002 23:58:16 GMT Received: from juniper.net (pptp064.static.jnpr.net [172.24.248.64]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4SNwDm86395; Tue, 28 May 2002 16:58:13 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3CF419A3.1010808@juniper.net> Date: Tue, 28 May 2002 16:58:27 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Gopalkrishna Panicker CC: mpls@UU.NET Subject: Re: MESSAGE_ID in Resv message References: <20020522012759.34731.qmail@web13402.mail.yahoo.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 Each RSVP Resv message can be represented via a MESSAGE_ID. This implies the following: 1. Per RSVP, you can combine multiple filters within a single Resv, in which case you need to track the message id for all the filters at both sending and receiving nodes. I know, it can be a pain in the ass to handle this. :-) 2. To simplify the code, when you send refresh messages, you have the option to force one filter per Resv. Hope this will help! - Ping Gopalkrishna Panicker wrote: > Hello, > > I have a question regarding the use of MESSAGE_ID > object in a resv message. > > Per my understanding of RFC 2209, a Resv state block > is created for every {Flowspec, Filterspec(s)}. > > If a session uses FF style and there are > multiple senders, a SINGLE resv message carries > a {flowspec,filterspec} set for each sender. > This will result in RSB being created for each such > set. > > Now if ROR is used and as only one MESSAGE_ID object > is allowed per message, should a separate resv message > be sent for each distinct reservation ? > > > Cheers, > > Gopal > > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > > > From owner-mpls@UU.NET Wed May 29 05:03:48 2002 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 FAA07895 for ; Wed, 29 May 2002 05:03:47 -0400 (EDT) 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 QQmqxo00990; Wed, 29 May 2002 09:03:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqxo12907 for mpls-outgoing; Wed, 29 May 2002 09:03: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 QQmqxo12900 for ; Wed, 29 May 2002 09:03: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 QQmqxo00916 for ; Wed, 29 May 2002 09:02:49 GMT Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQmqxo29200 for ; Wed, 29 May 2002 09:02:33 GMT Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 14:31:29 +0530 Message-ID: <9027F68B07E7D511AE9400B0D0787DC00704C7@mailserver.netbrahma.com> From: Manoj Agiwal To: "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Subject: Sonet Ring provisioning Date: Wed, 29 May 2002 14:31:24 +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 , Do we use GMPLS signaling protocol for configuring Sonet Rings ( UPSR / BLSR ( 2 fiber/4 fiber ) ? I was going through certain white papers where there was a mention that GMPLS is used as a signaling protocol for provisioning mesh topologies only .Traditional Sonet rings will be replaced by mesh topologies in future . But there is a section 12.( LSP protection and restoration) in GMPLS Architecture which says that " Both mesh and ring like topologies are supported " How do we provision nodes in Sonet ring using GMPLS ? Or GMPLS has been designed to provision mesh topologies only. Regards , Manoj From owner-mpls@UU.NET Wed May 29 07:09:05 2002 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 HAA10302 for ; Wed, 29 May 2002 07:09:05 -0400 (EDT) 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 QQmqxw07530; Wed, 29 May 2002 11:08:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqxw15050 for mpls-outgoing; Wed, 29 May 2002 11:08: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 QQmqxw15045 for ; Wed, 29 May 2002 11:08: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 QQmqxw12189 for ; Wed, 29 May 2002 11:07:20 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 QQmqxw10977 for ; Wed, 29 May 2002 11:07:20 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 g4TB7Jm13373; Wed, 29 May 2002 04:07:19 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id g4TB7JL27905; Wed, 29 May 2002 04:07:19 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 29 May 2002 04:07:19 -0700 (PDT) From: Kireeti Kompella To: Bharathi R cc: Subject: RE: GMPLS - PSC switching capability In-Reply-To: Message-ID: <20020529040258.N27567-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Tue, 28 May 2002, Bharathi R wrote: > If so then in PSC-2 label stack depth is 2 and PSC-3 means label stack of > depth 3 and so on. PSC-1...PSC-4 refer to levels of LSP hierarchy in the packet-switched domain. For example, one can full mesh one's core with TE LSPs, and then engineer region-to-region TE LSPs, giving a two-level hierarchy. > If so then why it is restricted to 4 levels? Do you have a preferred magic number? Kireeti. From owner-mpls@UU.NET Wed May 29 07:36:14 2002 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 HAA11344 for ; Wed, 29 May 2002 07:36:14 -0400 (EDT) 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 QQmqxy29153; Wed, 29 May 2002 11:35:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqxy17906 for mpls-outgoing; Wed, 29 May 2002 11:35: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 QQmqxy17901 for ; Wed, 29 May 2002 11:35:26 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 QQmqxy15999 for ; Wed, 29 May 2002 11:35:08 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqxy19365 for ; Wed, 29 May 2002 11:35:02 GMT 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 HAA17040 for ; Wed, 29 May 2002 07:35:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA01768 for mpls@uu.net; Wed, 29 May 2002 07:35:02 -0400 (EDT) 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 QQmqxy17849 for ; Wed, 29 May 2002 11:34:09 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 QQmqxy02004 for ; Wed, 29 May 2002 11:33:41 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQmqxy17488 for ; Wed, 29 May 2002 11:33:41 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10886; Wed, 29 May 2002 07:32:04 -0400 (EDT) Message-Id: <200205291132.HAA10886@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-mantha-resource-class-crldp-00.txt Date: Wed, 29 May 2002 07:32:04 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Resource Class considerations for CRLDP Author(s) : R. Mantha Filename : draft-mantha-resource-class-crldp-00.txt Pages : 8 Date : 28-May-02 This draft extends the CRLDP signaling to include the resource class affinity vectors of an LSP in the label request message. We define resource class attributes for hierarchical LSPs and procedures to admit LSPs into links/tunnels based on the resource class constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mantha-resource-class-crldp-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-mantha-resource-class-crldp-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-mantha-resource-class-crldp-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: <20020528130607.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mantha-resource-class-crldp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mantha-resource-class-crldp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020528130607.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed May 29 07:36:42 2002 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 HAA11367 for ; Wed, 29 May 2002 07:36:41 -0400 (EDT) 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 QQmqxy26864; Wed, 29 May 2002 11:36:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqxy17922 for mpls-outgoing; Wed, 29 May 2002 11:35:56 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 QQmqxy17916 for ; Wed, 29 May 2002 11:35:55 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 QQmqxy06161 for ; Wed, 29 May 2002 11:35:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqxy19366 for ; Wed, 29 May 2002 11:35:02 GMT 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 HAA17042 for ; Wed, 29 May 2002 07:35:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA01769 for mpls@uu.net; Wed, 29 May 2002 07:35:02 -0400 (EDT) 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 QQmqxy17850 for ; Wed, 29 May 2002 11:34:09 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 QQmqxy02007 for ; Wed, 29 May 2002 11:33:41 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQmqxy17489 for ; Wed, 29 May 2002 11:33:41 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11104; Wed, 29 May 2002 07:33:09 -0400 (EDT) Message-Id: <200205291133.HAA11104@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-lsp-hierarchy-06.txt Date: Wed, 29 May 2002 07:33:08 -0400 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 : LSP Hierarchy with Generalized MPLS TE Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-mpls-lsp-hierarchy-06.txt Pages : 12 Date : 28-May-02 To improve scalability of Generalized MPLS (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) an LSR creating a TE LSP, (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a TE link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct). This document describes the mechanisms to accomplish this. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-06.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-lsp-hierarchy-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsp-hierarchy-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020528130812.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-hierarchy-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-hierarchy-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020528130812.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed May 29 07:45:15 2002 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 HAA11685 for ; Wed, 29 May 2002 07:45:15 -0400 (EDT) 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 QQmqxy16072; Wed, 29 May 2002 11:44:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqxy18700 for mpls-outgoing; Wed, 29 May 2002 11:44: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 QQmqxy18688 for ; Wed, 29 May 2002 11:44:22 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 QQmqxy14628 for ; Wed, 29 May 2002 11:44:18 GMT Received: from wiprom2mx1.wipro.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQmqxy07629 for ; Wed, 29 May 2002 11:44:16 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 g4TBiFe13742 for ; Wed, 29 May 2002 17:14:15 +0530 (IST) Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GWVF9L00.14J for ; Wed, 29 May 2002 17:14:09 +0530 Received: from boochi.wipro.com ([10.117.3.144]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id MAA26369 for ; Wed, 29 May 2002 12:21:31 +0530 Date: Wed, 29 May 2002 17:17:52 +0400 (RET) From: "Nagabhushana Ramaswamy Nadig" X-X-Sender: Reply-To: To: Subject: I-D ACTION:draft-mantha-resource-class-crldp-00.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi, We have released a new draft on the resource class considerations for CRLDP and Tunnel Coloring procedures. Please provide your comments on the same over the list. regards Nagabhushana ---------- Forwarded message ---------- Date: Wed, 29 May 2002 07:32:04 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: mpls@UU.NET Subject: I-D ACTION:draft-mantha-resource-class-crldp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Resource Class considerations for CRLDP Author(s) : R. Mantha Filename : draft-mantha-resource-class-crldp-00.txt Pages : 8 Date : 28-May-02 This draft extends the CRLDP signaling to include the resource class affinity vectors of an LSP in the label request message. We define resource class attributes for hierarchical LSPs and procedures to admit LSPs into links/tunnels based on the resource class constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mantha-resource-class-crldp-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-mantha-resource-class-crldp-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-mantha-resource-class-crldp-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 Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-mantha-resource-class-crldp-00.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed May 29 09:49:06 2002 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 JAA17436 for ; Wed, 29 May 2002 09:49:06 -0400 (EDT) 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 QQmqyh07329; Wed, 29 May 2002 13:48:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqyh11809 for mpls-outgoing; Wed, 29 May 2002 13:48:17 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 QQmqyh11804 for ; Wed, 29 May 2002 13:48:16 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 QQmqyh27822 for ; Wed, 29 May 2002 13:48:10 GMT Received: from zcars04f.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQmqyh06482 for ; Wed, 29 May 2002 13:48:10 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4TDm8705276 for ; Wed, 29 May 2002 09:48:08 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 09:48:08 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD34037BED31@zcard0ka.ca.nortel.com> From: "David Allan" To: mpls@UU.NET Subject: draft-allan-mpls-oam-frmwk-02 Date: Wed, 29 May 2002 09:48:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20717.77B16C56" 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_01C20717.77B16C56 Content-Type: text/plain; charset="iso-8859-1" For those interested in MPLS OAM, we've posted a revised version of the framework draft. http://www.ietf.org/internet-drafts/draft-allan-mpls-oam-frmwk-02.txt Comments welcome! cheers Dave ------_=_NextPart_001_01C20717.77B16C56 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-allan-mpls-oam-frmwk-02

For those interested in MPLS OAM, we've posted a = revised version of the framework draft.

http://www.ietf.org/internet-drafts/draft-allan-mpls-o= am-frmwk-02.txt

Comments welcome!

cheers
Dave

------_=_NextPart_001_01C20717.77B16C56-- From owner-mpls@UU.NET Wed May 29 11:58:28 2002 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 LAA22294 for ; Wed, 29 May 2002 11:58:28 -0400 (EDT) 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 QQmqyp03066; Wed, 29 May 2002 15:57:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqyp06139 for mpls-outgoing; Wed, 29 May 2002 15:57:17 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 QQmqyp06130 for ; Wed, 29 May 2002 15:57: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 QQmqyp07676 for ; Wed, 29 May 2002 15:55:49 GMT Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142]) id QQmqyp00061 for ; Wed, 29 May 2002 15:55:48 GMT Received: (qmail 1856 invoked from network); 29 May 2002 15:55:43 -0000 Received: from mailscan1.iitb.ac.in (HELO thisdomain) (144.16.108.201) by mailhost.iitb.ac.in with SMTP; 29 May 2002 15:55:43 -0000 Received: from bhairav.ee.iitb.ac.in by iitb.ac.in ; Wed, 29 May 2002 21:25:47 +0530 Date: Wed, 29 May 2002 21:25:47 +0530 X-Originating-IP: 144.16.100.100 X-Auth-User: gabhijit@ee.iitb.ac.in Received: from brahmi.ee.iitb.ac.in (director.ee.iitb.ac.in [192.168.100.121]) by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id VAA00336; Wed, 29 May 2002 21:23:31 +0530 (IST) Received: from localhost (gabhijit@localhost) by brahmi.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id VAA26586; Wed, 29 May 2002 21:26:07 +0530 X-Authentication-Warning: brahmi.ee.iitb.ac.in: gabhijit owned process doing -bs Date: Wed, 29 May 2002 21:26:07 +0530 (IST) From: Abhijit Gadgil To: cc: IITB MPLS Group Subject: Linux based MPLS Emulator Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi all, MPLS group of IIT Bombay has developed a Linux based MPLS emulator. A reference implementation of this is available at http://www.ee.iitb.ac.in/uma/~mpls/ -abhijit From owner-mpls@UU.NET Wed May 29 13:00:49 2002 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 NAA24787 for ; Wed, 29 May 2002 13:00:49 -0400 (EDT) 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 QQmqyu25623; Wed, 29 May 2002 17:00:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqyt03196 for mpls-outgoing; Wed, 29 May 2002 16:59:39 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 QQmqyt03187 for ; Wed, 29 May 2002 16:59:32 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 QQmqyt15394 for ; Wed, 29 May 2002 16:58:21 GMT Received: from c2.ciena.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.118.32.25]) id QQmqyt22764 for ; Wed, 29 May 2002 16:58:21 GMT Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0) id MAA10816; Wed, 29 May 2002 12:58:19 -0400 (EDT) Received: from wntcsdexg02.csd.ciena.com(10.128.2.168) by c2.ciena.com via smap (V2.0) id xma010704; Wed, 29 May 02 12:58:08 -0400 Received: by wntcsdexg02.csd.ciena.com with Internet Mail Service (5.5.2653.19) id <2NTWVG6H>; Wed, 29 May 2002 09:58:07 -0700 Message-ID: <2135200C183FD5119588009027DE57230151B126@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: "'Manoj Agiwal'" , "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Subject: RE: Sonet Ring provisioning Date: Wed, 29 May 2002 09:58:02 -0700 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 Manoj, the UPSR and BLSR cases are very different. I'm assuming that you are setting up SONET paths such as STS-1, STS-3c, ... STS-192c or their SDH equivalent. Then (1) In the BLSR case the protection is at the SONET line layer, i.e., below the layer of the connection that you are setting up(SONET/SDH are layered networks). In this case no special action needs to be taken unless of course the entity requesting the connection asked for "enhanced" protection in the setup request. (2) A UPSR works at the path layer, i.e., like a path layer 1+1, with the redundant paths taking different routes around the ring. Hence you are actually setting up two connections that have a special relationship with each other. This would have to be indicated somehow (tunnel ID or something). Some UPSRs may put constraints on the timeslots used too. One meta question is why bother signaling around a UPSR versus talking to a UPSR as a separate "protection domain"? There is no way mesh restoration could come close to a UPSR's restoration speed (it just selects the better of two signals). Hence I don't understand the benefit signaling around the ring in this case, all vendors have methods for setting up their UPSRs via EMS's why not just interface to those rather than to the individual ring elements... Greg B. *********************************** Dr. Greg M. Bernstein Senior Technology Director, Ciena Corporation -----Original Message----- From: Manoj Agiwal [mailto:ManojA@netbrahma.com] Sent: Wednesday, May 29, 2002 2:01 AM To: 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: Sonet Ring provisioning Hi , Do we use GMPLS signaling protocol for configuring Sonet Rings ( UPSR / BLSR ( 2 fiber/4 fiber ) ? I was going through certain white papers where there was a mention that GMPLS is used as a signaling protocol for provisioning mesh topologies only .Traditional Sonet rings will be replaced by mesh topologies in future . But there is a section 12.( LSP protection and restoration) in GMPLS Architecture which says that " Both mesh and ring like topologies are supported " How do we provision nodes in Sonet ring using GMPLS ? Or GMPLS has been designed to provision mesh topologies only. Regards , Manoj From owner-mpls@UU.NET Wed May 29 14:20:25 2002 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 OAA27684 for ; Wed, 29 May 2002 14:20:25 -0400 (EDT) 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 QQmqyz15334; Wed, 29 May 2002 18:20:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqyz23455 for mpls-outgoing; Wed, 29 May 2002 18:19: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 QQmqyz23444 for ; Wed, 29 May 2002 18:19: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 QQmqyz12275 for ; Wed, 29 May 2002 18:19:08 GMT Received: from xover.netplane.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cnxt10002.conexant.com [198.62.10.2]) id QQmqyz13534 for ; Wed, 29 May 2002 18:19:07 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 14:14:40 -0400 Message-ID: <076236BAE727D611943F00508BA0F95906E752@XOVER.dedham.mindspeed.com> From: "Kullberg, Alan" To: mpls@UU.NET Subject: comment on FastReroute draft Date: Wed, 29 May 2002 14:14:38 -0400 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 I have a comment on draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt. From section 5, 2nd paragraph: Upon receiving the local protection requests for a protected LSP, the PLRs must try to establish the detour LSPs immediately. But section 7 states that before the CSPF computation can proceed, the PLR should collect the RRO detailing the downstream nodes and links. This RRO is in the RESV. Section 5 and 7 seem to be contradictory when the initial PATH message from the ingress node includes the FASTREROUTE object. Alan From owner-mpls@UU.NET Wed May 29 14:30:55 2002 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 OAA28008 for ; Wed, 29 May 2002 14:30:55 -0400 (EDT) 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 QQmqza03268; Wed, 29 May 2002 18:30:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqza24141 for mpls-outgoing; Wed, 29 May 2002 18:30: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 QQmqyz24135 for ; Wed, 29 May 2002 18:29:58 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 QQmqyz20835 for ; Wed, 29 May 2002 18:28:58 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 QQmqyz28525 for ; Wed, 29 May 2002 18:28:57 GMT Received: from juniper.net (pptp153.static.jnpr.net [172.24.248.153]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4TISPm36935; Wed, 29 May 2002 11:28:25 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3CF5200B.9CC96E22@juniper.net> Date: Wed, 29 May 2002 11:38:03 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Kullberg, Alan" CC: mpls@UU.NET Subject: Re: comment on FastReroute draft References: <076236BAE727D611943F00508BA0F95906E752@XOVER.dedham.mindspeed.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Kullberg, Alan" wrote: > > I have a comment on draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt. > > >From section 5, 2nd paragraph: > > Upon receiving the local > protection requests for a protected LSP, the PLRs must try to > establish the detour LSPs immediately. > > But section 7 states that before the CSPF computation can proceed, > the PLR should collect the RRO detailing the downstream nodes and > links. This RRO is in the RESV. > > Section 5 and 7 seem to be contradictory when the initial PATH > message from the ingress node includes the FASTREROUTE object. > Not really. For one-to-one backup, the PLR will try to setup a detour only AFTER the protected LSP is up and running. When a protected LSP is up and running, the PLR can always get the RRO and all other junk from the protected LSP to setup the detours. - Ping From owner-mpls@UU.NET Wed May 29 14:54:13 2002 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 OAA28709 for ; Wed, 29 May 2002 14:54:12 -0400 (EDT) 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 QQmqzb13926; Wed, 29 May 2002 18:52:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqzb26040 for mpls-outgoing; Wed, 29 May 2002 18:52: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 QQmqzb26009 for ; Wed, 29 May 2002 18:51: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 QQmqzb29535 for ; Wed, 29 May 2002 18:51:08 GMT Received: from xover.netplane.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cnxt10002.conexant.com [198.62.10.2]) id QQmqzb05026 for ; Wed, 29 May 2002 18:51:07 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 14:46:40 -0400 Message-ID: <076236BAE727D611943F00508BA0F95906E753@XOVER.dedham.mindspeed.com> From: "Kullberg, Alan" To: "'Ping Pan'" , "Kullberg, Alan" Cc: mpls@UU.NET Subject: RE: comment on FastReroute draft Date: Wed, 29 May 2002 14:46:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > > I have a comment on draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt. > > > > >From section 5, 2nd paragraph: > > > > Upon receiving the local > > protection requests for a protected LSP, the PLRs must try to > > establish the detour LSPs immediately. > > > > But section 7 states that before the CSPF computation can proceed, > > the PLR should collect the RRO detailing the downstream nodes and > > links. This RRO is in the RESV. > > > > Section 5 and 7 seem to be contradictory when the initial PATH > > message from the ingress node includes the FASTREROUTE object. > > > > Not really. For one-to-one backup, the PLR will try to setup a detour > only AFTER the protected LSP is up and running. When a > protected LSP is > up and running, the PLR can always get the RRO and all other junk from > the protected LSP to setup the detours. I think that the paragraph from section 5 could be interpreted to mean upon reception of a PATH message containing FASTREROUTE object, immediately send out 2 PATH messages, 1 for the protected LSP and another for the detour LSP. Therefore, I think the wording could be changed to clarify this as follows: Upon reception of a RESV corresponding to a PATH message that contains the FASTREROUTE object, the PLR must try to establish the detour LSP immediately. OR, by "protected LSP is up and running", did you mean that the LSP is active all the way from ingress to egress, which implies either the ingress inserts the FASTREROUTE object only AFTER receiving the 1st RESV, or all PLRs wait for a RESV_CONF message to begin detour LSP setup. Alan From owner-mpls@UU.NET Wed May 29 14:55:27 2002 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 OAA28862 for ; Wed, 29 May 2002 14:55:26 -0400 (EDT) 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 QQmqzb11843; Wed, 29 May 2002 18:55:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqzb26251 for mpls-outgoing; Wed, 29 May 2002 18:54:42 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 QQmqzb26213 for ; Wed, 29 May 2002 18:54: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 QQmqzb08479 for ; Wed, 29 May 2002 18:54:04 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmqzb17270 for ; Wed, 29 May 2002 18:54:03 GMT 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 OAA16952 for ; Wed, 29 May 2002 14:54:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA17653 for mpls@uu.net; Wed, 29 May 2002 14:54:02 -0400 (EDT) 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 QQmqzb26079 for ; Wed, 29 May 2002 18:52:52 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 QQmqzb03530 for ; Wed, 29 May 2002 18:52:07 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmqzb06406 for ; Wed, 29 May 2002 18:52:05 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 OAA02918; Wed, 29 May 2002 14:51:54 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200205291851.OAA02918@workhorse.fictitious.org> To: "Kullberg, Alan" cc: mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: comment on FastReroute draft In-reply-to: Your message of "Wed, 29 May 2002 14:14:38 EDT." <076236BAE727D611943F00508BA0F95906E752@XOVER.dedham.mindspeed.com> Date: Wed, 29 May 2002 14:51:54 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <076236BAE727D611943F00508BA0F95906E752@XOVER.dedham.mindspeed.com>, "Kullberg, Alan" writes: > I have a comment on draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt. > > >From section 5, 2nd paragraph: > > Upon receiving the local > protection requests for a protected LSP, the PLRs must try to > establish the detour LSPs immediately. > > But section 7 states that before the CSPF computation can proceed, > the PLR should collect the RRO detailing the downstream nodes and > links. This RRO is in the RESV. > > Section 5 and 7 seem to be contradictory when the initial PATH > message from the ingress node includes the FASTREROUTE object. > > Alan You are right about the document not being clear. If the LSP is strictly routed, the ERO has all the information you need to do the CSPF. If there are some loose hops, you have better information when the RRO arrives. In the worst case, the next hop is loose and there is one more hop that is loose. In that case, based on the ERO alone, the only candidate for merging with the primary path is the egress. When the RRO arrives you can do the equivalent of make-before-break on the detour path if the RRO provides a better merge point. If you create the detour before receiving the RRO, you can confuse some routers by having the detour PATH message arrive before the primary is set up. Some routers can handle this some can't. The advantage of setting up detour as quickly as possible is that local-protect-available can be set sooner (if using those bits, which at least one pre-standard implementation does not use). Curtis From owner-mpls@UU.NET Wed May 29 18:52:53 2002 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 SAA06364 for ; Wed, 29 May 2002 18:52:53 -0400 (EDT) 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 QQmqyt11867; Wed, 29 May 2002 16:51:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqyt02556 for mpls-outgoing; Wed, 29 May 2002 16:50:58 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 QQmqyt02547 for ; Wed, 29 May 2002 16:50: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 QQmqyt20016 for ; Wed, 29 May 2002 16:49:57 GMT Received: from mail.san.yahoo.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.san.yahoo.com [209.132.1.30]) id QQmqyt09122 for ; Wed, 29 May 2002 16:49:56 GMT Received: from [65.213.193.52] by mail.san.yahoo.com with HTTP; Wed, 29 May 2002 09:50:57 -0700 Date: Wed, 29 May 2002 12:50:57 -0400 Message-ID: <3CF41CBE00000B3A@mta08.san.yahoo.com> From: "Kavita Khanna" Subject: RE: question Fast-Reroute Resv manipulation To: "Doug Degan" , mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA06364 Doug, Per FRR spec, LSRs must work under the assumption that any failed LSPs may have been repaired upstream and new Path messages will soon arrive via the bypass tunnel(s). They do not send PathTear and ResvErr messages immediately upon link failure detection. Hope that helps! - Kavita >-- Original Message -- >From: "Doug Degan" >To: >Subject: question Fast-Reroute Resv manipulation >Date: Tue, 28 May 2002 15:48:14 +0300 > > >consider this basic FRR topology - primary protected LSP is configured and >bypass is ready for use if needed: > >[I]---[PLR]----[T]-----[MP]--------[E] > \ / > \------------------/ > BYPASS/DETOUR > > >and the scenario: > >1) MP send RESV-MSG to T > >2) Link between PLR & T fails > >3) T get the RESV-MSG - will it send RESV_ERR downstream cause the link >is >down? > >* should every router block RESV_ERR messages for protected LSP? > > > >thanks alot. > From owner-mpls@UU.NET Wed May 29 19:08:47 2002 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 TAA06806 for ; Wed, 29 May 2002 19:08:47 -0400 (EDT) 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 QQmqyq12632; Wed, 29 May 2002 16:13:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmqyq29095 for mpls-outgoing; Wed, 29 May 2002 16:12: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 QQmqyq29088 for ; Wed, 29 May 2002 16:12:56 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 QQmqyq26350 for ; Wed, 29 May 2002 16:12:27 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 QQmqyq12303 for ; Wed, 29 May 2002 16:12:26 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4TGCPm25882 for ; Wed, 29 May 2002 09:12:26 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205291612.g4TGCPm25882@merlot.juniper.net> To: mpls@UU.NET Subject: draft-ietf-mpls-lsp-hierarchy-06.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11477.1022688745.1@juniper.net> Date: Wed, 29 May 2002 09:12:25 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Hi, The only change with the previous version is splitting references into normative and non-normative. Yakov. ------- Forwarded Message Date: Wed, 29 May 2002 07:33:08 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: mpls@UU.NET Subject: I-D ACTION:draft-ietf-mpls-lsp-hierarchy-06.txt - --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 : LSP Hierarchy with Generalized MPLS TE Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-mpls-lsp-hierarchy-06.txt Pages : 12 Date : 28-May-02 To improve scalability of Generalized MPLS (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) an LSR creating a TE LSP, (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a TE link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct). This document describes the mechanisms to accomplish this. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-06.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-lsp-hierarchy-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsp-hierarchy-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020528130812.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-hierarchy-06.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-hierarchy-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020528130812.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message From owner-mpls@UU.NET Thu May 30 01:29:08 2002 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 BAA14410 for ; Thu, 30 May 2002 01:29:08 -0400 (EDT) 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 QQmrap18339; Thu, 30 May 2002 04:51:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrap19695 for mpls-outgoing; Thu, 30 May 2002 04:51: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 QQmrap19690 for ; Thu, 30 May 2002 04:51: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 QQmrap26907 for ; Thu, 30 May 2002 04:50: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 QQmrap20546 for ; Thu, 30 May 2002 04:50:04 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrap20527 for ; Thu, 30 May 2002 04:50:03 GMT 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 AAA16056 for ; Thu, 30 May 2002 00:50:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id AAA14947 for mpls@uu.net; Thu, 30 May 2002 00:50:03 -0400 (EDT) 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 QQmrap19475 for ; Thu, 30 May 2002 04:48:45 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 QQmrap17756 for ; Thu, 30 May 2002 04:48:05 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 QQmrap15015 for ; Thu, 30 May 2002 04:48:04 GMT Received: from mail.alcatel.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.alcatel.co.uk [195.92.62.199]) id QQmrap14962 for ; Thu, 30 May 2002 04:48:03 GMT Received: from bt0g2p.god.bel.alcatel.be (relay02.net.alcatel.co.uk [127.0.0.1]) by mail.alcatel.co.uk (8.11.0/8.9.3) with ESMTP id g4U4m2J27209 for ; Thu, 30 May 2002 05:48:02 +0100 Received: from Bemail06.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id g4U4jUs15558 for ; Thu, 30 May 2002 06:45:30 +0200 To: mpls@UU.NET Cc: Maria.Coenen@alcatel.be Subject: PHP - draft-ietf-mpls-lsr-mib-08 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 30 May 2002 06:47:58 +0200 X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 05/30/2002 06:47:59, Serialize complete at 05/30/2002 06:47:59 Content-Type: multipart/alternative; boundary="=_alternative 001A5C2CC1256BC9_=" Sender: owner-mpls@UU.NET Precedence: bulk This is a multipart message in MIME format. --=_alternative 001A5C2CC1256BC9_= Content-Type: text/plain; charset="us-ascii" Hello, When reading the , I wonder about the interaction of PHP with the counters in the ifTable/ifXTable. Should the counters for the outgoing direction (ifOutOctets, ifOutPackets etc.) also include * the mpls bytes/packets for out segments using PHP and for which there is **no** other mpls label beneath? * the mpls bytes/packets for out segments using PHP and for which there **is** another mpls label beneath? Thanks for any clarification you can provide. Francis. --=_alternative 001A5C2CC1256BC9_= Content-Type: text/html; charset="us-ascii"
Hello,

When reading the <draft-ietf-mpls-lsr-mib-08>, I wonder about the interaction of PHP with the counters in the ifTable/ifXTable.

Should the counters for the outgoing direction (ifOutOctets, ifOutPackets etc.) also include
* the mpls bytes/packets for out segments using PHP and for which there is **no** other mpls label beneath?
* the mpls bytes/packets for out segments using PHP and for which there **is** another mpls label beneath?

Thanks for any clarification you can provide.

        Francis. --=_alternative 001A5C2CC1256BC9_=-- From owner-mpls@UU.NET Thu May 30 04:49:57 2002 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 EAA26736 for ; Thu, 30 May 2002 04:49:57 -0400 (EDT) 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 QQmrbf17088; Thu, 30 May 2002 08:49:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrbf04630 for mpls-outgoing; Thu, 30 May 2002 08:49: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 QQmrbf04621 for ; Thu, 30 May 2002 08:48:58 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 QQmrbf05054 for ; Thu, 30 May 2002 08:48:10 GMT Received: from mailserver.ossi.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.199.121.176]) id QQmrbf01499 for ; Thu, 30 May 2002 08:48:09 GMT Received: from muralidharan (unknown [192.168.0.16]) by mailserver.ossi.co.in (Postfix) with SMTP id 3BF893C1E3; Thu, 30 May 2002 14:28:34 +0530 (IST) Message-ID: <003601c207b6$cf4bf860$1000a8c0@ossi> Reply-To: "R. Muralidharan" From: "R. Muralidharan" To: "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" References: <2135200C183FD5119588009027DE57230151B126@wntcsdexg02.csd.ciena.com> Subject: Re: Sonet Ring provisioning Date: Thu, 30 May 2002 14:18:46 +0530 Organization: OSS Systems India MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, My understanding is as follows: BLSR or UPSR rings may be already provisioned in the SONET network. The task using GMPLS is to set up an end to end virtual path, may be encompassing multiple SONET rings. This virtual path set up is dynamic in nature and the life of the path may be only for a fixed interval, after which it would be tore down. When one wants to set up a path through a SONET ring, one may have to specify whether one wants a 1+1 protection path or a 1:N protection path or just an unprotected path. Based on this specification the GMPLS can discover and set up an appropriate path in a BLSR or an UPSR ring as the case may be and hence the cost would be optimum. ( assuming that a 1+1 path would cost more than an unprotected path). As Greg pointed out, I also believe that the BLSR and UPSR ring configurations would already have been set up by associated NMS or EMS and advertised. The granularity of the path that can be set up using GMPLS could a VT1.5 or multiples of them ( VT Path) or STS-1s (STS Path). I have used the words "path" and "virtual path" in generic terms and not in the SONET or SDH domain definitions. Does the above make sense ? regards, murali OSS Systems India ----- Original Message ----- From: "Bernstein, Greg" To: "'Manoj Agiwal'" ; "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Sent: Wednesday, May 29, 2002 10:28 PM Subject: RE: Sonet Ring provisioning > Hi Manoj, the UPSR and BLSR cases are very different. I'm assuming that you > are setting up SONET paths such as STS-1, STS-3c, ... STS-192c or their SDH > equivalent. > Then > (1) In the BLSR case the protection is at the SONET line layer, i.e., below > the layer of the connection that you are setting up(SONET/SDH are layered > networks). In this case no special action needs to be taken unless of > course the entity requesting the connection asked for "enhanced" protection > in the setup request. > > (2) A UPSR works at the path layer, i.e., like a path layer 1+1, with the > redundant paths taking different routes around the ring. Hence you are > actually setting up two connections that have a special relationship with > each other. This would have to be indicated somehow (tunnel ID or > something). Some UPSRs may put constraints on the timeslots used too. One > meta question is why bother signaling around a UPSR versus talking to a UPSR > as a separate "protection domain"? There is no way mesh restoration could > come close to a UPSR's restoration speed (it just selects the better of two > signals). Hence I don't understand the benefit signaling around the ring in > this case, all vendors have methods for setting up their UPSRs via EMS's why > not just interface to those rather than to the individual ring elements... > > Greg B. > > *********************************** > Dr. Greg M. Bernstein > Senior Technology Director, Ciena Corporation > > > -----Original Message----- > From: Manoj Agiwal [mailto:ManojA@netbrahma.com] > Sent: Wednesday, May 29, 2002 2:01 AM > To: 'Ccamp (E-mail) > Cc: mpls@UU. NET (E-mail) > Subject: Sonet Ring provisioning > > > Hi , > Do we use GMPLS signaling protocol for configuring Sonet Rings ( UPSR > / BLSR ( 2 fiber/4 > fiber ) ? > > I was going through certain white papers where there was a mention > that GMPLS is used as > a signaling protocol for provisioning mesh topologies only > .Traditional Sonet rings will be > replaced by mesh topologies in future . > > But there is a section 12.( LSP protection and restoration) in GMPLS > Architecture which says > that " Both mesh and ring like topologies are supported " > > How do we provision nodes in Sonet ring using GMPLS ? > Or GMPLS has been designed to provision mesh topologies only. > > Regards , > Manoj > > > > > From owner-mpls@UU.NET Thu May 30 07:04:58 2002 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 HAA28639 for ; Thu, 30 May 2002 07:04:58 -0400 (EDT) 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 QQmrbo27676 for ; Thu, 30 May 2002 11:05:19 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 QQmrbo24803; Thu, 30 May 2002 11:04:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrbo09733 for mpls-outgoing; Thu, 30 May 2002 11:03:55 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 QQmrbo09726 for ; Thu, 30 May 2002 11:03:49 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 QQmrbo07462 for ; Thu, 30 May 2002 11:03:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrbo02370 for ; Thu, 30 May 2002 11:03:02 GMT 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 HAA28198 for ; Thu, 30 May 2002 07:03:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA21304 for mpls@uu.net; Thu, 30 May 2002 07:03:01 -0400 (EDT) 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 QQmrbo09673 for ; Thu, 30 May 2002 11:02: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 QQmrbo01713 for ; Thu, 30 May 2002 11:02:35 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQmrbo24896 for ; Thu, 30 May 2002 11:02:34 GMT Received: from JVASSEUR-W2K.cisco.com (ams-clip-vpn-dhcp21.cisco.com [10.50.0.20]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA10977; Thu, 30 May 2002 13:02:30 +0200 (MET DST) Message-Id: <4.3.2.7.2.20020530130115.01b2aa60@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 30 May 2002 13:02:27 +0200 To: "Doug Degan" From: Jean Philippe Vasseur Subject: Re: question Fast-Reroute Resv manipulation Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, At 15:48 28/05/2002 +0300, Doug Degan wrote: >consider this basic FRR topology - primary protected LSP is configured and >bypass is ready for use if needed: > >[I]---[PLR]----[T]-----[MP]--------[E] > \ / > \------------------/ > BYPASS/DETOUR > > >and the scenario: > >1) MP send RESV-MSG to T > >2) Link between PLR & T fails > >3) T get the RESV-MSG - will it send RESV_ERR downstream cause the link is >down? no. >* should every router block RESV_ERR messages for protected LSP? The MP should silently discard it. JP. >thanks alot. From owner-mpls@UU.NET Thu May 30 07:31:09 2002 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 HAA29605 for ; Thu, 30 May 2002 07:31:09 -0400 (EDT) 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 QQmrbq10011; Thu, 30 May 2002 11:30:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrbq22176 for mpls-outgoing; Thu, 30 May 2002 11:30: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 QQmrbq22171 for ; Thu, 30 May 2002 11:30: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 QQmrbq21158 for ; Thu, 30 May 2002 11:30:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrbq09024 for ; Thu, 30 May 2002 11:30:02 GMT 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 HAA29121 for ; Thu, 30 May 2002 07:30:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA24365 for mpls@uu.net; Thu, 30 May 2002 07:30:01 -0400 (EDT) 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 QQmrbp22110 for ; Thu, 30 May 2002 11:29:13 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 QQmrbp04997 for ; Thu, 30 May 2002 11:28:35 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQmrbp09343 for ; Thu, 30 May 2002 11:28:34 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29480; Thu, 30 May 2002 07:28:08 -0400 (EDT) Message-Id: <200205301128.HAA29480@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-ttl-02.txt Date: Thu, 30 May 2002 07:28:08 -0400 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 : Time to Live (TTL) Processing in MPLS Networks Author(s) : P. Agarwal, B. Akyol Filename : draft-ietf-mpls-ttl-02.txt Pages : 8 Date : 29-May-02 This document describes TTL processing in hierarchical MPLS networks. 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ttl-02.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-ttl-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ttl-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020529145852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ttl-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ttl-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020529145852.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu May 30 07:32:05 2002 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 HAA29645 for ; Thu, 30 May 2002 07:32:05 -0400 (EDT) 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 QQmrbq10571 for ; Thu, 30 May 2002 11:32:27 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 QQmrbp00950; Thu, 30 May 2002 11:29:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrbp22119 for mpls-outgoing; Thu, 30 May 2002 11:29:17 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 QQmrbp22111 for ; Thu, 30 May 2002 11:29:13 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 QQmrbp06174 for ; Thu, 30 May 2002 11:29:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrbp07645 for ; Thu, 30 May 2002 11:29:02 GMT 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 HAA29070 for ; Thu, 30 May 2002 07:29:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA24259 for mpls@uu.net; Thu, 30 May 2002 07:29:02 -0400 (EDT) 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 QQmrbp22083 for ; Thu, 30 May 2002 11:28: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 QQmrbp02970 for ; Thu, 30 May 2002 11:27:44 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQmrbp06772 for ; Thu, 30 May 2002 11:27:43 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29254; Thu, 30 May 2002 07:27:08 -0400 (EDT) Message-Id: <200205301127.HAA29254@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-kishan-lsp-btrace-02.txt Date: Thu, 30 May 2002 07:27:08 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Label Switched Path backtrace using Multi Protocol Label Switching Label Distribution Protocol/Constraint Based Label Distributed Protocol Author(s) : H. Desineni, K. Avasarala Filename : draft-kishan-lsp-btrace-02.txt Pages : 19 Date : 29-May-02 This document describes the encoding and procedures for new Label Distribution Protocol (LDP) messages, the back trace message and back trace reply message. The back trace message is sent for an established Label Switched Path(LSP). The back trace message can be used for Label Distribution Protocol(LDP) Label Switched paths as well as for Constraint Based Label Switched Paths (CR-LSPs). The data requested is encoded into the back trace reply message. Backtrace mechanism described in this draft can be used for obtaining the MPLS topology information for a particular Forwarding Equivalence Class (FEC) in a Multi Protocol Label Switching (MPLS) domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kishan-lsp-btrace-02.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-kishan-lsp-btrace-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kishan-lsp-btrace-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020529140358.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kishan-lsp-btrace-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-kishan-lsp-btrace-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020529140358.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu May 30 08:21:55 2002 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 IAA01070 for ; Thu, 30 May 2002 08:21:55 -0400 (EDT) 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 QQmrbt25751; Thu, 30 May 2002 12:20:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrbt18152 for mpls-outgoing; Thu, 30 May 2002 12:20: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 QQmrbt18147 for ; Thu, 30 May 2002 12:20:20 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 QQmrbt24747 for ; Thu, 30 May 2002 12:20:08 GMT Received: from auemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQmrbt24170 for ; Thu, 30 May 2002 12:20:06 GMT Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with SMTP id g4UCK4Z03132; Thu, 30 May 2002 08:20:04 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id IAA22442; Thu, 30 May 2002 08:20:29 -0400 Message-ID: <3CF61904.40109@lucent.com> Date: Thu, 30 May 2002 08:20:20 -0400 From: Zhi-Wei Lin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "R. Muralidharan" CC: "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: Re: Sonet Ring provisioning References: <2135200C183FD5119588009027DE57230151B126@wntcsdexg02.csd.ciena.com> <003601c207b6$cf4bf860$1000a8c0@ossi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, Seems we have mixed up a "ring topology" from "ring protection mechanism". * In a general ring topology, *any* recovery mechanism may be used. This may be the underlying transport's BLSR/MSSPRING or UPSR/SNCPRING, or it may be using control plane to set up 1+1 or 1:1. * In a BLSR/MSSPRING ring, the type of protection has already been decided (i.e., BLSR *is* the name of the protection mechanism). Similarly for UPSR/SNCPRING. Thus if we're talking about BLSR/UPSR rings, then the question is: how does the control plane protocols interact (do they interact?) with the underlying BLSR/UPSR, e.g., does the control plane simply treat the *entire* ring as a single node and thus interfaces to existing EMSs to ask for a sub-network connection across the "node", or does the control plane actually see all nodes of the ring and ask individual nodes for an STS-1/VC-3 connection (but note it only asks for the normal channel i.e. one connection, since the protection channel comes by default -- the service is either protected or unprotected but one connection in either case)... Zhi R. Muralidharan wrote: >Hi All, > >My understanding is as follows: > > BLSR or UPSR rings may be already provisioned in the SONET network. The >task using GMPLS is to set up an end to end virtual path, may be >encompassing multiple SONET rings. This virtual path set up is dynamic in >nature and the life of the path may be only for a fixed interval, after >which it would be tore down. When one wants to set up a path through a SONET >ring, one may have to specify whether one wants a 1+1 protection path or a >1:N protection path or just an unprotected path. Based on this specification >the GMPLS can discover and set up an appropriate path in a BLSR or an UPSR >ring as the case may be and hence the cost would be optimum. ( assuming that >a 1+1 path would cost more than an unprotected path). As Greg pointed out, I >also believe that the BLSR and UPSR ring configurations would already have >been set up by associated NMS or EMS and advertised. The granularity of the >path that can be set up using GMPLS could a VT1.5 or multiples of them ( VT >Path) or STS-1s (STS Path). > >I have used the words "path" and "virtual path" in generic terms and not in >the SONET or SDH domain definitions. > >Does the above make sense ? >regards, >murali >OSS Systems India > >----- Original Message ----- >From: "Bernstein, Greg" >To: "'Manoj Agiwal'" ; "'Ccamp (E-mail)" > >Cc: "mpls@UU. NET (E-mail)" >Sent: Wednesday, May 29, 2002 10:28 PM >Subject: RE: Sonet Ring provisioning > > > > >>Hi Manoj, the UPSR and BLSR cases are very different. I'm assuming that >> >> >you > > >>are setting up SONET paths such as STS-1, STS-3c, ... STS-192c or their >> >> >SDH > > >>equivalent. >>Then >>(1) In the BLSR case the protection is at the SONET line layer, i.e., >> >> >below > > >>the layer of the connection that you are setting up(SONET/SDH are layered >>networks). In this case no special action needs to be taken unless of >>course the entity requesting the connection asked for "enhanced" >> >> >protection > > >>in the setup request. >> >>(2) A UPSR works at the path layer, i.e., like a path layer 1+1, with the >>redundant paths taking different routes around the ring. Hence you are >>actually setting up two connections that have a special relationship with >>each other. This would have to be indicated somehow (tunnel ID or >>something). Some UPSRs may put constraints on the timeslots used too. One >>meta question is why bother signaling around a UPSR versus talking to a >> >> >UPSR > > >>as a separate "protection domain"? There is no way mesh restoration could >>come close to a UPSR's restoration speed (it just selects the better of >> >> >two > > >>signals). Hence I don't understand the benefit signaling around the ring >> >> >in > > >>this case, all vendors have methods for setting up their UPSRs via EMS's >> >> >why > > >>not just interface to those rather than to the individual ring elements... >> >>Greg B. >> >>*********************************** >>Dr. Greg M. Bernstein >>Senior Technology Director, Ciena Corporation >> >> >>-----Original Message----- >>From: Manoj Agiwal [mailto:ManojA@netbrahma.com] >>Sent: Wednesday, May 29, 2002 2:01 AM >>To: 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: Sonet Ring provisioning >> >> >>Hi , >> Do we use GMPLS signaling protocol for configuring Sonet Rings ( >> >> >UPSR > > >>/ BLSR ( 2 fiber/4 >> fiber ) ? >> >> I was going through certain white papers where there was a mention >>that GMPLS is used as >> a signaling protocol for provisioning mesh topologies only >>.Traditional Sonet rings will be >> replaced by mesh topologies in future . >> >> But there is a section 12.( LSP protection and restoration) in GMPLS >>Architecture which says >> that " Both mesh and ring like topologies are supported " >> >> How do we provision nodes in Sonet ring using GMPLS ? >> Or GMPLS has been designed to provision mesh topologies only. >> >>Regards , >>Manoj >> >> >> >> >> >> >> > > > From owner-mpls@UU.NET Thu May 30 09:40:43 2002 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 JAA04336 for ; Thu, 30 May 2002 09:40:43 -0400 (EDT) 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 QQmrby09720; Thu, 30 May 2002 13:40:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrby16045 for mpls-outgoing; Thu, 30 May 2002 13:39:48 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 QQmrby16040 for ; Thu, 30 May 2002 13:39: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 QQmrby02322 for ; Thu, 30 May 2002 13:38: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 QQmrby17158 for ; Thu, 30 May 2002 13:38:07 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrby17048 for ; Thu, 30 May 2002 13:38:02 GMT 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 JAA04811 for ; Thu, 30 May 2002 09:38:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA07770 for mpls@uu.net; Thu, 30 May 2002 09:38:02 -0400 (EDT) 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 QQmrby15967 for ; Thu, 30 May 2002 13:37:20 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 QQmrby27279 for ; Thu, 30 May 2002 13:36:29 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 QQmrby04917 for ; Thu, 30 May 2002 13:36:29 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 g4UDajph029942; Thu, 30 May 2002 09:36:46 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122]) by bucket.cisco.com (Mirapoint) with ESMTP id ABC11047; Thu, 30 May 2002 09:36:15 -0400 (EDT) Message-Id: <4.3.2.7.2.20020530093335.01f43ef0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 30 May 2002 09:36:14 -0400 To: francis.arts@alcatel.be From: "Thomas D. Nadeau" Subject: Re: PHP - draft-ietf-mpls-lsr-mib-08 Cc: mpls@UU.NET, Maria.Coenen@alcatel.be In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >When reading the , I wonder about the >interaction of PHP with the counters in the ifTable/ifXTable. > >Should the counters for the outgoing direction (ifOutOctets, ifOutPackets >etc.) also include >* the mpls bytes/packets for out segments using PHP and for which there is >**no** other mpls label beneath? >* the mpls bytes/packets for out segments using PHP and for which there >**is** another mpls label beneath? The outgoing counters should only include bytes/packets transmitted with an MPLS shim header. If you are doing PHP, you have stripped the header at that hop and are sending the packet along as IP out that interface (or whatever is underneath the shim header). --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Thu May 30 10:09:15 2002 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 KAA05908 for ; Thu, 30 May 2002 10:09:15 -0400 (EDT) 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 QQmrca19918; Thu, 30 May 2002 14:08:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrca09781 for mpls-outgoing; Thu, 30 May 2002 14:08: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 QQmrca09705 for ; Thu, 30 May 2002 14:08:30 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 QQmrca03612 for ; Thu, 30 May 2002 14:08: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 QQmrca07285 for ; Thu, 30 May 2002 14:08:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrca07273 for ; Thu, 30 May 2002 14:08:03 GMT 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 KAA06899 for ; Thu, 30 May 2002 10:08:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA11347 for mpls@uu.net; Thu, 30 May 2002 10:08:02 -0400 (EDT) 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 QQmrca08876 for ; Thu, 30 May 2002 14:07:38 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 QQmrca28644 for ; Thu, 30 May 2002 14:06:26 GMT Received: from slim.equipecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: equipe-4.equipecom.com [65.163.242.4]) id QQmrca16367 for ; Thu, 30 May 2002 14:06:26 GMT Received: from sherlock.equipecom.com (sherlock.equipecom.com [192.168.1.75]) by slim.equipecom.com (8.11.0/8.11.0) with SMTP id g4UE6Pc23371 for ; Thu, 30 May 2002 10:06:25 -0400 (EDT) Received: from eccexch01.equipecom.com ([192.168.1.11]) by sherlock.equipecom.com (NAVGW 2.5.1.18) with SMTP id M2002053010034321866 ; Thu, 30 May 2002 10:03:43 -0400 Received: by eccexch01.equipecom.com with Internet Mail Service (5.5.2653.19) id <290VB6BJ>; Thu, 30 May 2002 10:05:48 -0400 Message-ID: <666478FCC801D6118E3600D0B781FC16159C00@eccexch01.equipecom.com> From: Nik Langrind To: "'Zhi-Wei Lin'" , "R. Muralidharan" Cc: "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: RE: Sonet Ring provisioning Date: Thu, 30 May 2002 10:05:45 -0400 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, If a path that is set up via GMPLS signaling traverses a SONET ring, and the SONET ring is managed via an EMS as Greg suggests, how do the two protection domains interact? The two protection domains I am thinking of are as follows: 1) The Ring protection domain - failures in the ring itself are protected, by ring-specific mechanisms 2) The end-to-end protection domain - failures anywhere along the path are protected, presumably by failing over to a diversely routed path J------K / \ A ------B------H------I L-------O-------Y--------Z \ \ / / \ N------M F------G \ / C---------------D---------E Endpoints A and Z have an LSP (an end-to-end SONET path) switched across the ring (I-J-K-L-M-N). LSRs B and Y provide a redundant LSP across the path C-D-E. Presumably, the nodes B and Y provide a path monitoring function, similar to UPSR, that they can use to initiate a switch to the protect LSP. If a failure happens in the ring, it will be recovered from, via line-switching or ring-switching inside the ring. But the path monitoring function at nodes B and Y will invoke an LSP protection switch. This is marginally bad, because it extends the outage by some number of milliseconds, and it complicates the revert later. If the path monitoring function has a holddown timer, such that it does not invoke a switch until 50 ms of outage, then failures at H or O will not be reacted to as quickly as possible. Instead of performing path monitoring to trigger an LSP-switch, B and Y could perform line monitoring, and only switch if failures occur on their local segments? But this seems like it opens up a class of failures which would not be recovered from. So it seems to me that the mixing of protection schemes creates a small problem, and I wonder what people think about this? Nik > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Thursday, May 30, 2002 8:20 AM > To: R. Muralidharan > Cc: Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET > (E-mail) > Subject: Re: Sonet Ring provisioning > > > Hi all, > > Seems we have mixed up a "ring topology" from "ring > protection mechanism". > > * In a general ring topology, *any* recovery mechanism > may be used. > This may be the underlying transport's BLSR/MSSPRING or > UPSR/SNCPRING, or it may be using control plane to set > up 1+1 or 1:1. > * In a BLSR/MSSPRING ring, the type of protection has already been > decided (i.e., BLSR *is* the name of the protection mechanism). > Similarly for UPSR/SNCPRING. > > Thus if we're talking about BLSR/UPSR rings, then the > question is: how > does the control plane protocols interact (do they interact?) > with the > underlying BLSR/UPSR, e.g., does the control plane simply treat the > *entire* ring as a single node and thus interfaces to > existing EMSs to > ask for a sub-network connection across the "node", or does > the control > plane actually see all nodes of the ring and ask individual > nodes for an > STS-1/VC-3 connection (but note it only asks for the normal > channel i.e. > one connection, since the protection channel comes by default -- the > service is either protected or unprotected but one connection > in either > case)... > > Zhi > > > R. Muralidharan wrote: > > >Hi All, > > > >My understanding is as follows: > > > > BLSR or UPSR rings may be already provisioned in the > SONET network. The > >task using GMPLS is to set up an end to end virtual path, may be > >encompassing multiple SONET rings. This virtual path set up > is dynamic in > >nature and the life of the path may be only for a fixed > interval, after > >which it would be tore down. When one wants to set up a path > through a SONET > >ring, one may have to specify whether one wants a 1+1 > protection path or a > >1:N protection path or just an unprotected path. Based on > this specification > >the GMPLS can discover and set up an appropriate path in a > BLSR or an UPSR > >ring as the case may be and hence the cost would be optimum. > ( assuming that > >a 1+1 path would cost more than an unprotected path). As > Greg pointed out, I > >also believe that the BLSR and UPSR ring configurations > would already have > >been set up by associated NMS or EMS and advertised. The > granularity of the > >path that can be set up using GMPLS could a VT1.5 or > multiples of them ( VT > >Path) or STS-1s (STS Path). > > > >I have used the words "path" and "virtual path" in generic > terms and not in > >the SONET or SDH domain definitions. > > > >Does the above make sense ? > >regards, > >murali > >OSS Systems India > > > >----- Original Message ----- > >From: "Bernstein, Greg" > >To: "'Manoj Agiwal'" ; "'Ccamp (E-mail)" > > > >Cc: "mpls@UU. NET (E-mail)" > >Sent: Wednesday, May 29, 2002 10:28 PM > >Subject: RE: Sonet Ring provisioning > > > > > > > > > >>Hi Manoj, the UPSR and BLSR cases are very different. I'm > assuming that > >> > >> > >you > > > > > >>are setting up SONET paths such as STS-1, STS-3c, ... > STS-192c or their > >> > >> > >SDH > > > > > >>equivalent. > >>Then > >>(1) In the BLSR case the protection is at the SONET line > layer, i.e., > >> > >> > >below > > > > > >>the layer of the connection that you are setting > up(SONET/SDH are layered > >>networks). In this case no special action needs to be > taken unless of > >>course the entity requesting the connection asked for "enhanced" > >> > >> > >protection > > > > > >>in the setup request. > >> > >>(2) A UPSR works at the path layer, i.e., like a path layer > 1+1, with the > >>redundant paths taking different routes around the ring. > Hence you are > >>actually setting up two connections that have a special > relationship with > >>each other. This would have to be indicated somehow (tunnel ID or > >>something). Some UPSRs may put constraints on the timeslots > used too. One > >>meta question is why bother signaling around a UPSR versus > talking to a > >> > >> > >UPSR > > > > > >>as a separate "protection domain"? There is no way mesh > restoration could > >>come close to a UPSR's restoration speed (it just selects > the better of > >> > >> > >two > > > > > >>signals). Hence I don't understand the benefit signaling > around the ring > >> > >> > >in > > > > > >>this case, all vendors have methods for setting up their > UPSRs via EMS's > >> > >> > >why > > > > > >>not just interface to those rather than to the individual > ring elements... > >> > >>Greg B. > >> > >>*********************************** > >>Dr. Greg M. Bernstein > >>Senior Technology Director, Ciena Corporation > >> > >> > >>-----Original Message----- > >>From: Manoj Agiwal [mailto:ManojA@netbrahma.com] > >>Sent: Wednesday, May 29, 2002 2:01 AM > >>To: 'Ccamp (E-mail) > >>Cc: mpls@UU. NET (E-mail) > >>Subject: Sonet Ring provisioning > >> > >> > >>Hi , > >> Do we use GMPLS signaling protocol for configuring > Sonet Rings ( > >> > >> > >UPSR > > > > > >>/ BLSR ( 2 fiber/4 > >> fiber ) ? > >> > >> I was going through certain white papers where there > was a mention > >>that GMPLS is used as > >> a signaling protocol for provisioning mesh topologies only > >>.Traditional Sonet rings will be > >> replaced by mesh topologies in future . > >> > >> But there is a section 12.( LSP protection and > restoration) in GMPLS > >>Architecture which says > >> that " Both mesh and ring like topologies are supported " > >> > >> How do we provision nodes in Sonet ring using GMPLS ? > >> Or GMPLS has been designed to provision mesh topologies only. > >> > >>Regards , > >>Manoj > >> > >> > >> > >> > >> > >> > >> > > > > > > > > From owner-mpls@UU.NET Thu May 30 12:11:43 2002 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 MAA11099 for ; Thu, 30 May 2002 12:11:42 -0400 (EDT) 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 QQmrci01310; Thu, 30 May 2002 16:11:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrci08824 for mpls-outgoing; Thu, 30 May 2002 16:10:43 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 QQmrci08757 for ; Thu, 30 May 2002 16:10: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 QQmrci14717 for ; Thu, 30 May 2002 16:10: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 QQmrci04949 for ; Thu, 30 May 2002 16:10:15 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 QQmrci04919 for ; Thu, 30 May 2002 16:10:14 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 MAA04906 for ; Thu, 30 May 2002 12:00:29 -0400 (EDT) Subject: how to request the desired bandwidth? RFC3209 section 4.7.3 To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Thu, 30 May 2002 12:00:22 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 05/30/2002 12:00:30 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, RFC3209 Section 4.7.3, it says "When a new path message is considered for admission, the bandwidth requested is compared with the bandwidth available at the priority specified in the set up priority" Here I want to know how to request the desired bandwidth from the path msg. As I know, in the path message, there is one Sender Tspec object, and inside this object, it has traffic parameters like 'token bucket rate', 'token bucket size', 'peak data rate'....... I want to know which parameter can be used to specify the desired bandwidth the node wants. Or desired BW will not be defined from this object at all? Can someone tell me how to request the BW in the Path msg, and if it is not available, a PathErr msg will be sent back? Thanks in an advance. Julia From owner-mpls@UU.NET Thu May 30 12:59:24 2002 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 MAA13019 for ; Thu, 30 May 2002 12:59:24 -0400 (EDT) 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 QQmrcl29510 for ; Thu, 30 May 2002 16:59:45 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 QQmrcl27184; Thu, 30 May 2002 16:58:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrcl13177 for mpls-outgoing; Thu, 30 May 2002 16:58: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 QQmrcl13172 for ; Thu, 30 May 2002 16:58:34 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 QQmrcl02440 for ; Thu, 30 May 2002 16:57:00 GMT Received: from c2.ciena.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.118.32.25]) id QQmrcl04680 for ; Thu, 30 May 2002 16:56:59 GMT Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0) id MAA10636; Thu, 30 May 2002 12:56:57 -0400 (EDT) Received: from wntcsdexg02.csd.ciena.com(10.128.2.168) by c2.ciena.com via smap (V2.0) id xma010545; Thu, 30 May 02 12:56:34 -0400 Received: by wntcsdexg02.csd.ciena.com with Internet Mail Service (5.5.2653.19) id <2NTWVH36>; Thu, 30 May 2002 09:56:32 -0700 Message-ID: <2135200C183FD5119588009027DE57230151B13B@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: "'Nik Langrind'" , "'Zhi-Wei Lin'" , "R. Muralidharan" Cc: "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: RE: Sonet Ring provisioning Date: Thu, 30 May 2002 09:56:28 -0700 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 Nick good points. The interaction of protection types can be tricky. The typical technique is to use "hold off timers" to first give a "faster" protection type a chance to respond. This works well when say source reroute mesh (at say the SONET path layer) is used to back up a connection that traverses say a number of rings (say BLSRs). However, in your example below it would also imply waiting an extra time period before kicking of the mesh. Greg *********************************** Dr. Greg M. Bernstein Senior Technology Director, Ciena Corporation -----Original Message----- From: Nik Langrind [mailto:nik@equipecom.com] Sent: Thursday, May 30, 2002 7:06 AM To: 'Zhi-Wei Lin'; R. Muralidharan Cc: Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET (E-mail) Subject: RE: Sonet Ring provisioning Hi, If a path that is set up via GMPLS signaling traverses a SONET ring, and the SONET ring is managed via an EMS as Greg suggests, how do the two protection domains interact? The two protection domains I am thinking of are as follows: 1) The Ring protection domain - failures in the ring itself are protected, by ring-specific mechanisms 2) The end-to-end protection domain - failures anywhere along the path are protected, presumably by failing over to a diversely routed path J------K / \ A ------B------H------I L-------O-------Y--------Z \ \ / / \ N------M F------G \ / C---------------D---------E Endpoints A and Z have an LSP (an end-to-end SONET path) switched across the ring (I-J-K-L-M-N). LSRs B and Y provide a redundant LSP across the path C-D-E. Presumably, the nodes B and Y provide a path monitoring function, similar to UPSR, that they can use to initiate a switch to the protect LSP. If a failure happens in the ring, it will be recovered from, via line-switching or ring-switching inside the ring. But the path monitoring function at nodes B and Y will invoke an LSP protection switch. This is marginally bad, because it extends the outage by some number of milliseconds, and it complicates the revert later. If the path monitoring function has a holddown timer, such that it does not invoke a switch until 50 ms of outage, then failures at H or O will not be reacted to as quickly as possible. Instead of performing path monitoring to trigger an LSP-switch, B and Y could perform line monitoring, and only switch if failures occur on their local segments? But this seems like it opens up a class of failures which would not be recovered from. So it seems to me that the mixing of protection schemes creates a small problem, and I wonder what people think about this? Nik > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Thursday, May 30, 2002 8:20 AM > To: R. Muralidharan > Cc: Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET > (E-mail) > Subject: Re: Sonet Ring provisioning > > > Hi all, > > Seems we have mixed up a "ring topology" from "ring > protection mechanism". > > * In a general ring topology, *any* recovery mechanism > may be used. > This may be the underlying transport's BLSR/MSSPRING or > UPSR/SNCPRING, or it may be using control plane to set > up 1+1 or 1:1. > * In a BLSR/MSSPRING ring, the type of protection has already been > decided (i.e., BLSR *is* the name of the protection mechanism). > Similarly for UPSR/SNCPRING. > > Thus if we're talking about BLSR/UPSR rings, then the > question is: how > does the control plane protocols interact (do they interact?) > with the > underlying BLSR/UPSR, e.g., does the control plane simply treat the > *entire* ring as a single node and thus interfaces to > existing EMSs to > ask for a sub-network connection across the "node", or does > the control > plane actually see all nodes of the ring and ask individual > nodes for an > STS-1/VC-3 connection (but note it only asks for the normal > channel i.e. > one connection, since the protection channel comes by default -- the > service is either protected or unprotected but one connection > in either > case)... > > Zhi > > > R. Muralidharan wrote: > > >Hi All, > > > >My understanding is as follows: > > > > BLSR or UPSR rings may be already provisioned in the > SONET network. The > >task using GMPLS is to set up an end to end virtual path, may be > >encompassing multiple SONET rings. This virtual path set up > is dynamic in > >nature and the life of the path may be only for a fixed > interval, after > >which it would be tore down. When one wants to set up a path > through a SONET > >ring, one may have to specify whether one wants a 1+1 > protection path or a > >1:N protection path or just an unprotected path. Based on > this specification > >the GMPLS can discover and set up an appropriate path in a > BLSR or an UPSR > >ring as the case may be and hence the cost would be optimum. > ( assuming that > >a 1+1 path would cost more than an unprotected path). As > Greg pointed out, I > >also believe that the BLSR and UPSR ring configurations > would already have > >been set up by associated NMS or EMS and advertised. The > granularity of the > >path that can be set up using GMPLS could a VT1.5 or > multiples of them ( VT > >Path) or STS-1s (STS Path). > > > >I have used the words "path" and "virtual path" in generic > terms and not in > >the SONET or SDH domain definitions. > > > >Does the above make sense ? > >regards, > >murali > >OSS Systems India > > > >----- Original Message ----- > >From: "Bernstein, Greg" > >To: "'Manoj Agiwal'" ; "'Ccamp (E-mail)" > > > >Cc: "mpls@UU. NET (E-mail)" > >Sent: Wednesday, May 29, 2002 10:28 PM > >Subject: RE: Sonet Ring provisioning > > > > > > > > > >>Hi Manoj, the UPSR and BLSR cases are very different. I'm > assuming that > >> > >> > >you > > > > > >>are setting up SONET paths such as STS-1, STS-3c, ... > STS-192c or their > >> > >> > >SDH > > > > > >>equivalent. > >>Then > >>(1) In the BLSR case the protection is at the SONET line > layer, i.e., > >> > >> > >below > > > > > >>the layer of the connection that you are setting > up(SONET/SDH are layered > >>networks). In this case no special action needs to be > taken unless of > >>course the entity requesting the connection asked for "enhanced" > >> > >> > >protection > > > > > >>in the setup request. > >> > >>(2) A UPSR works at the path layer, i.e., like a path layer > 1+1, with the > >>redundant paths taking different routes around the ring. > Hence you are > >>actually setting up two connections that have a special > relationship with > >>each other. This would have to be indicated somehow (tunnel ID or > >>something). Some UPSRs may put constraints on the timeslots > used too. One > >>meta question is why bother signaling around a UPSR versus > talking to a > >> > >> > >UPSR > > > > > >>as a separate "protection domain"? There is no way mesh > restoration could > >>come close to a UPSR's restoration speed (it just selects > the better of > >> > >> > >two > > > > > >>signals). Hence I don't understand the benefit signaling > around the ring > >> > >> > >in > > > > > >>this case, all vendors have methods for setting up their > UPSRs via EMS's > >> > >> > >why > > > > > >>not just interface to those rather than to the individual > ring elements... > >> > >>Greg B. > >> > >>*********************************** > >>Dr. Greg M. Bernstein > >>Senior Technology Director, Ciena Corporation > >> > >> > >>-----Original Message----- > >>From: Manoj Agiwal [mailto:ManojA@netbrahma.com] > >>Sent: Wednesday, May 29, 2002 2:01 AM > >>To: 'Ccamp (E-mail) > >>Cc: mpls@UU. NET (E-mail) > >>Subject: Sonet Ring provisioning > >> > >> > >>Hi , > >> Do we use GMPLS signaling protocol for configuring > Sonet Rings ( > >> > >> > >UPSR > > > > > >>/ BLSR ( 2 fiber/4 > >> fiber ) ? > >> > >> I was going through certain white papers where there > was a mention > >>that GMPLS is used as > >> a signaling protocol for provisioning mesh topologies only > >>.Traditional Sonet rings will be > >> replaced by mesh topologies in future . > >> > >> But there is a section 12.( LSP protection and > restoration) in GMPLS > >>Architecture which says > >> that " Both mesh and ring like topologies are supported " > >> > >> How do we provision nodes in Sonet ring using GMPLS ? > >> Or GMPLS has been designed to provision mesh topologies only. > >> > >>Regards , > >>Manoj > >> > >> > >> > >> > >> > >> > >> > > > > > > > > From owner-mpls@UU.NET Thu May 30 14:26:46 2002 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 OAA16493 for ; Thu, 30 May 2002 14:26:46 -0400 (EDT) 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 QQmrcr06613; Thu, 30 May 2002 18:26:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrcr03575 for mpls-outgoing; Thu, 30 May 2002 18:26: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 QQmrcr03546 for ; Thu, 30 May 2002 18:26:03 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 QQmrcr06004 for ; Thu, 30 May 2002 18:25:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrcr04817 for ; Thu, 30 May 2002 18:25:03 GMT 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 OAA28581 for ; Thu, 30 May 2002 14:25:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA07376 for mpls@uu.net; Thu, 30 May 2002 14:25:02 -0400 (EDT) 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 QQmrcr03349 for ; Thu, 30 May 2002 18:23:51 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 QQmrcr09058 for ; Thu, 30 May 2002 18:23:25 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.69.24.11]) id QQmrcr10048 for ; Thu, 30 May 2002 18:23:24 GMT Received: from mira1.cisco.com (IDENT:mirapoint@mira1.cisco.com [64.101.14.50]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4UINBPI015619; Thu, 30 May 2002 11:23:11 -0700 (PDT) Received: from cisco.com (skatukam-u5.cisco.com [64.101.9.63]) by mira1.cisco.com (Mirapoint) with ESMTP id AAZ95303; Thu, 30 May 2002 11:23:29 -0700 (PDT) Message-ID: <3CF66E05.F5DB0E93@cisco.com> Date: Thu, 30 May 2002 11:23:01 -0700 From: Suresh Katukam Organization: Cisco Systems X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Zhi-Wei Lin CC: "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: Re: Sonet Ring provisioning References: <2135200C183FD5119588009027DE57230151B126@wntcsdexg02.csd.ciena.com> <003601c207b6$cf4bf860$1000a8c0@ossi> <3CF61904.40109@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Let us say that the BLSR ring topology is as follows: A --- B --- C | | H D | | G --- F --- E If one wants to create a LSP from A to D via B, C, then A signals to B, B to C, C to D. Everything is fine. If B -- C link fails, what happens next? 1. Should B and C keep quite and do not tear down LSP (because these know that B - C line is protected)? How about H, G, F, E, D, C nodes? Do these need to know that these are protecting an LSP that goes through A to D? What happens if another link G - F fails? Do these nodes need to inform B or C or A indicating that these cannot protect B - C link anymore so that B can do Fast Reroute? 2. Should B and C setup a backup LSP (when link fails) around the ring? Traffic is not affected during this period. This provides a mechanism for nodes involved in LSP can get information from nodes that are in backup LSPs. I think that there are quite a few issues are not resolved in this area and taking a simple view is not going to be sufficient when Fast Reroute and other things come into play. Thanks, Suresh Zhi-Wei Lin wrote: > > Hi all, > > Seems we have mixed up a "ring topology" from "ring protection mechanism". > > * In a general ring topology, *any* recovery mechanism may be used. > This may be the underlying transport's BLSR/MSSPRING or > UPSR/SNCPRING, or it may be using control plane to set up 1+1 or 1:1. > * In a BLSR/MSSPRING ring, the type of protection has already been > decided (i.e., BLSR *is* the name of the protection mechanism). > Similarly for UPSR/SNCPRING. > > Thus if we're talking about BLSR/UPSR rings, then the question is: how > does the control plane protocols interact (do they interact?) with the > underlying BLSR/UPSR, e.g., does the control plane simply treat the > *entire* ring as a single node and thus interfaces to existing EMSs to > ask for a sub-network connection across the "node", or does the control > plane actually see all nodes of the ring and ask individual nodes for an > STS-1/VC-3 connection (but note it only asks for the normal channel i.e. > one connection, since the protection channel comes by default -- the > service is either protected or unprotected but one connection in either > case)... > > Zhi > > R. Muralidharan wrote: > > >Hi All, > > > >My understanding is as follows: > > > > BLSR or UPSR rings may be already provisioned in the SONET network. The > >task using GMPLS is to set up an end to end virtual path, may be > >encompassing multiple SONET rings. This virtual path set up is dynamic in > >nature and the life of the path may be only for a fixed interval, after > >which it would be tore down. When one wants to set up a path through a SONET > >ring, one may have to specify whether one wants a 1+1 protection path or a > >1:N protection path or just an unprotected path. Based on this specification > >the GMPLS can discover and set up an appropriate path in a BLSR or an UPSR > >ring as the case may be and hence the cost would be optimum. ( assuming that > >a 1+1 path would cost more than an unprotected path). As Greg pointed out, I > >also believe that the BLSR and UPSR ring configurations would already have > >been set up by associated NMS or EMS and advertised. The granularity of the > >path that can be set up using GMPLS could a VT1.5 or multiples of them ( VT > >Path) or STS-1s (STS Path). > > > >I have used the words "path" and "virtual path" in generic terms and not in > >the SONET or SDH domain definitions. > > > >Does the above make sense ? > >regards, > >murali > >OSS Systems India > > > >----- Original Message ----- > >From: "Bernstein, Greg" > >To: "'Manoj Agiwal'" ; "'Ccamp (E-mail)" > > > >Cc: "mpls@UU. NET (E-mail)" > >Sent: Wednesday, May 29, 2002 10:28 PM > >Subject: RE: Sonet Ring provisioning > > > > > > > > > >>Hi Manoj, the UPSR and BLSR cases are very different. I'm assuming that > >> > >> > >you > > > > > >>are setting up SONET paths such as STS-1, STS-3c, ... STS-192c or their > >> > >> > >SDH > > > > > >>equivalent. > >>Then > >>(1) In the BLSR case the protection is at the SONET line layer, i.e., > >> > >> > >below > > > > > >>the layer of the connection that you are setting up(SONET/SDH are layered > >>networks). In this case no special action needs to be taken unless of > >>course the entity requesting the connection asked for "enhanced" > >> > >> > >protection > > > > > >>in the setup request. > >> > >>(2) A UPSR works at the path layer, i.e., like a path layer 1+1, with the > >>redundant paths taking different routes around the ring. Hence you are > >>actually setting up two connections that have a special relationship with > >>each other. This would have to be indicated somehow (tunnel ID or > >>something). Some UPSRs may put constraints on the timeslots used too. One > >>meta question is why bother signaling around a UPSR versus talking to a > >> > >> > >UPSR > > > > > >>as a separate "protection domain"? There is no way mesh restoration could > >>come close to a UPSR's restoration speed (it just selects the better of > >> > >> > >two > > > > > >>signals). Hence I don't understand the benefit signaling around the ring > >> > >> > >in > > > > > >>this case, all vendors have methods for setting up their UPSRs via EMS's > >> > >> > >why > > > > > >>not just interface to those rather than to the individual ring elements... > >> > >>Greg B. > >> > >>*********************************** > >>Dr. Greg M. Bernstein > >>Senior Technology Director, Ciena Corporation > >> > >> > >>-----Original Message----- > >>From: Manoj Agiwal [mailto:ManojA@netbrahma.com] > >>Sent: Wednesday, May 29, 2002 2:01 AM > >>To: 'Ccamp (E-mail) > >>Cc: mpls@UU. NET (E-mail) > >>Subject: Sonet Ring provisioning > >> > >> > >>Hi , > >> Do we use GMPLS signaling protocol for configuring Sonet Rings ( > >> > >> > >UPSR > > > > > >>/ BLSR ( 2 fiber/4 > >> fiber ) ? > >> > >> I was going through certain white papers where there was a mention > >>that GMPLS is used as > >> a signaling protocol for provisioning mesh topologies only > >>.Traditional Sonet rings will be > >> replaced by mesh topologies in future . > >> > >> But there is a section 12.( LSP protection and restoration) in GMPLS > >>Architecture which says > >> that " Both mesh and ring like topologies are supported " > >> > >> How do we provision nodes in Sonet ring using GMPLS ? > >> Or GMPLS has been designed to provision mesh topologies only. > >> > >>Regards , > >>Manoj > >> > >> > >> > >> > >> > >> > >> > > > > > > From owner-mpls@UU.NET Thu May 30 15:01:19 2002 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 PAA17544 for ; Thu, 30 May 2002 15:01:19 -0400 (EDT) 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 QQmrct13114; Thu, 30 May 2002 18:54:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrct05903 for mpls-outgoing; Thu, 30 May 2002 18:54:19 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 QQmrct05896 for ; Thu, 30 May 2002 18:54: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 QQmrct15179 for ; Thu, 30 May 2002 18:54:07 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 QQmrct20972 for ; Thu, 30 May 2002 18:54:07 GMT Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with SMTP id g4UIs5e05745; Thu, 30 May 2002 14:54:06 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA21988; Thu, 30 May 2002 14:54:31 -0400 Message-ID: <3CF6755D.5010508@lucent.com> Date: Thu, 30 May 2002 14:54:21 -0400 From: Zhi-Wei Lin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Suresh Katukam CC: "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: Re: Sonet Ring provisioning References: <2135200C183FD5119588009027DE57230151B126@wntcsdexg02.csd.ciena.com> <003601c207b6$cf4bf860$1000a8c0@ossi> <3CF61904.40109@lucent.com> <3CF66E05.F5DB0E93@cisco.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 Hi Suresh, Yes agree this is very complex if you try to create too much dependencies between control plane and transport plane protection interactions. That is why my simplistic approach: * Control plane sees the entire ring as offering "highly available" connections * Control plane sets up a single connection across this ring "sub-network" (if you think this about this, the entire ring can actually be treated by a control plane controller as a single node where the BLSR ring nodes may be thought of as aggregate ports on the single node) * The ring sub-network, by virtue of providing the protection and knowing *exactly* how protection is provided can set up the protection channel automatically (but control plane need not know this as it is irrelevant to the control plane -- it only needs to know that the single connection is protected) Of course there will be additional constraints placed by the ring, such as a flag to indicate the availability of "highly available" connections, whether or not to enable this highly available connection (if not enabled then you may be using the NUT feature of BLSR e.g.), whether the same timeslot must be used, whether ring switching or span switching is supported (and enabled), whether traffic should be carried as "best effort" (e.g., as extra traffic on the BLSR), etc. etc. Thus in your example, if link B-C fails, so what? the underlying BLSR protects this connection. The control plane sees its A-D connection as been up all the time (the little transport plane interruption probably translates to a packet delay). Also by virtue that this is a BLSR ring, nodes H, G, F, E knows exactly which link it is protecting (it's part of the BLSR protocol operation). If another link G-F fails, then the entire ring has become segmented, and thus *any* traffic going through this ring is shot (except those that are contained within each segment). Then you either declare the connection "dead" or if you're offering an end-to-end restoration on top of the ring, you might try re-routing the LSP. But this is a separate issue from how the rings work (all the ring nodes would know that the ring is segmented from the K1/K2 byte info exchanges in a BLSR -- doesn't need control plane to tell it anything), but more to do with what mechanisms control plane has for restoration. The interactions of course may be the holdoff timer that Greg mentioned. Zhi Suresh Katukam wrote: >Let us say that the BLSR ring topology is as follows: > > A --- B --- C > | | > H D > | | > G --- F --- E > >If one wants to create a LSP from A to D via B, C, then A >signals to B, B to C, C to D. Everything is fine. > >If B -- C link fails, what happens next? > >1. Should B and C keep quite and do not tear down >LSP (because these know that B - C line is protected)? >How about H, G, F, E, D, C nodes? >Do these need to know that these are protecting an LSP that >goes through A to D? What happens if another link G - F fails? >Do these nodes need to inform B or C or A indicating that >these cannot protect B - C link anymore so that B can do >Fast Reroute? > >2. Should B and C setup a backup LSP (when link fails) around the >ring? Traffic is not affected during this period. This provides >a mechanism for nodes involved in LSP can get information >from nodes that are in backup LSPs. > >I think that there are quite a few issues are not resolved in >this area and taking a simple view is not going to be sufficient >when Fast Reroute and other things come into play. > >Thanks, >Suresh > >Zhi-Wei Lin wrote: > > >>Hi all, >> >>Seems we have mixed up a "ring topology" from "ring protection mechanism". >> >> * In a general ring topology, *any* recovery mechanism may be used. >> This may be the underlying transport's BLSR/MSSPRING or >> UPSR/SNCPRING, or it may be using control plane to set up 1+1 or 1:1. >> * In a BLSR/MSSPRING ring, the type of protection has already been >> decided (i.e., BLSR *is* the name of the protection mechanism). >> Similarly for UPSR/SNCPRING. >> >>Thus if we're talking about BLSR/UPSR rings, then the question is: how >>does the control plane protocols interact (do they interact?) with the >>underlying BLSR/UPSR, e.g., does the control plane simply treat the >>*entire* ring as a single node and thus interfaces to existing EMSs to >>ask for a sub-network connection across the "node", or does the control >>plane actually see all nodes of the ring and ask individual nodes for an >>STS-1/VC-3 connection (but note it only asks for the normal channel i.e. >>one connection, since the protection channel comes by default -- the >>service is either protected or unprotected but one connection in either >>case)... >> >>Zhi >> >>R. Muralidharan wrote: >> >> >> >>>Hi All, >>> >>>My understanding is as follows: >>> >>> BLSR or UPSR rings may be already provisioned in the SONET network. The >>>task using GMPLS is to set up an end to end virtual path, may be >>>encompassing multiple SONET rings. This virtual path set up is dynamic in >>>nature and the life of the path may be only for a fixed interval, after >>>which it would be tore down. When one wants to set up a path through a SONET >>>ring, one may have to specify whether one wants a 1+1 protection path or a >>>1:N protection path or just an unprotected path. Based on this specification >>>the GMPLS can discover and set up an appropriate path in a BLSR or an UPSR >>>ring as the case may be and hence the cost would be optimum. ( assuming that >>>a 1+1 path would cost more than an unprotected path). As Greg pointed out, I >>>also believe that the BLSR and UPSR ring configurations would already have >>>been set up by associated NMS or EMS and advertised. The granularity of the >>>path that can be set up using GMPLS could a VT1.5 or multiples of them ( VT >>>Path) or STS-1s (STS Path). >>> >>>I have used the words "path" and "virtual path" in generic terms and not in >>>the SONET or SDH domain definitions. >>> >>>Does the above make sense ? >>>regards, >>>murali >>>OSS Systems India >>> >>>----- Original Message ----- >>>From: "Bernstein, Greg" >>>To: "'Manoj Agiwal'" ; "'Ccamp (E-mail)" >>> >>>Cc: "mpls@UU. NET (E-mail)" >>>Sent: Wednesday, May 29, 2002 10:28 PM >>>Subject: RE: Sonet Ring provisioning >>> >>> >>> >>> >>> >>> >>>>Hi Manoj, the UPSR and BLSR cases are very different. I'm assuming that >>>> >>>> >>>> >>>> >>>you >>> >>> >>> >>> >>>>are setting up SONET paths such as STS-1, STS-3c, ... STS-192c or their >>>> >>>> >>>> >>>> >>>SDH >>> >>> >>> >>> >>>>equivalent. >>>>Then >>>>(1) In the BLSR case the protection is at the SONET line layer, i.e., >>>> >>>> >>>> >>>> >>>below >>> >>> >>> >>> >>>>the layer of the connection that you are setting up(SONET/SDH are layered >>>>networks). In this case no special action needs to be taken unless of >>>>course the entity requesting the connection asked for "enhanced" >>>> >>>> >>>> >>>> >>>protection >>> >>> >>> >>> >>>>in the setup request. >>>> >>>>(2) A UPSR works at the path layer, i.e., like a path layer 1+1, with the >>>>redundant paths taking different routes around the ring. Hence you are >>>>actually setting up two connections that have a special relationship with >>>>each other. This would have to be indicated somehow (tunnel ID or >>>>something). Some UPSRs may put constraints on the timeslots used too. One >>>>meta question is why bother signaling around a UPSR versus talking to a >>>> >>>> >>>> >>>> >>>UPSR >>> >>> >>> >>> >>>>as a separate "protection domain"? There is no way mesh restoration could >>>>come close to a UPSR's restoration speed (it just selects the better of >>>> >>>> >>>> >>>> >>>two >>> >>> >>> >>> >>>>signals). Hence I don't understand the benefit signaling around the ring >>>> >>>> >>>> >>>> >>>in >>> >>> >>> >>> >>>>this case, all vendors have methods for setting up their UPSRs via EMS's >>>> >>>> >>>> >>>> >>>why >>> >>> >>> >>> >>>>not just interface to those rather than to the individual ring elements... >>>> >>>>Greg B. >>>> >>>>*********************************** >>>>Dr. Greg M. Bernstein >>>>Senior Technology Director, Ciena Corporation >>>> >>>> >>>>-----Original Message----- >>>>From: Manoj Agiwal [mailto:ManojA@netbrahma.com] >>>>Sent: Wednesday, May 29, 2002 2:01 AM >>>>To: 'Ccamp (E-mail) >>>>Cc: mpls@UU. NET (E-mail) >>>>Subject: Sonet Ring provisioning >>>> >>>> >>>>Hi , >>>> Do we use GMPLS signaling protocol for configuring Sonet Rings ( >>>> >>>> >>>> >>>> >>>UPSR >>> >>> >>> >>> >>>>/ BLSR ( 2 fiber/4 >>>> fiber ) ? >>>> >>>> I was going through certain white papers where there was a mention >>>>that GMPLS is used as >>>> a signaling protocol for provisioning mesh topologies only >>>>.Traditional Sonet rings will be >>>> replaced by mesh topologies in future . >>>> >>>> But there is a section 12.( LSP protection and restoration) in GMPLS >>>>Architecture which says >>>> that " Both mesh and ring like topologies are supported " >>>> >>>> How do we provision nodes in Sonet ring using GMPLS ? >>>> Or GMPLS has been designed to provision mesh topologies only. >>>> >>>>Regards , >>>>Manoj >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> From owner-mpls@UU.NET Thu May 30 17:43:28 2002 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 RAA20522 for ; Thu, 30 May 2002 17:43:27 -0400 (EDT) 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 QQmrde24626 for ; Thu, 30 May 2002 21:43:46 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 QQmrde22032; Thu, 30 May 2002 21:42:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrde27443 for mpls-outgoing; Thu, 30 May 2002 21:42: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 QQmrde27438 for ; Thu, 30 May 2002 21:42:20 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 QQmrde03162 for ; Thu, 30 May 2002 21:41: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 QQmrde20087 for ; Thu, 30 May 2002 21:41:38 GMT Received: from alpha2.tellium.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.125.55.125]) id QQmrde20081 for ; Thu, 30 May 2002 21:41:38 GMT Received: from mail3.tellium.com (mail3.tellium.com) by alpha2.tellium.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 May 2002 17:41:04 -0400 Received: by mail3.tellium.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 May 2002 17:40:26 -0400 Message-ID: <05707214338CD5119BFF0040A5B170D3016AE810@mail3.tellium.com> From: Vasanthi Thirumalai To: "'Hong Liao'" , mpls@UU.NET Subject: RE: how to request the desired bandwidth? RFC3209 section 4.7.3 Date: Thu, 30 May 2002 17:40:26 -0400 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 The 'peak data rate' is used to specify the desired bandwidth. -Vasanthi -----Original Message----- From: Hong Liao [mailto:hliao@telcordia.com] Sent: Thursday, May 30, 2002 12:00 PM To: mpls@UU.NET Subject: how to request the desired bandwidth? RFC3209 section 4.7.3 Hi, RFC3209 Section 4.7.3, it says "When a new path message is considered for admission, the bandwidth requested is compared with the bandwidth available at the priority specified in the set up priority" Here I want to know how to request the desired bandwidth from the path msg. As I know, in the path message, there is one Sender Tspec object, and inside this object, it has traffic parameters like 'token bucket rate', 'token bucket size', 'peak data rate'....... I want to know which parameter can be used to specify the desired bandwidth the node wants. Or desired BW will not be defined from this object at all? Can someone tell me how to request the BW in the Path msg, and if it is not available, a PathErr msg will be sent back? Thanks in an advance. Julia From owner-mpls@UU.NET Thu May 30 22:16:02 2002 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 WAA24301 for ; Thu, 30 May 2002 22:16:02 -0400 (EDT) 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 QQmrdx26141; Fri, 31 May 2002 02:15:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrdx06499 for mpls-outgoing; Fri, 31 May 2002 02:15: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 QQmrdw06394 for ; Fri, 31 May 2002 02:14:54 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 QQmrdw07657 for ; Fri, 31 May 2002 02:14:16 GMT Received: from scutsv39.scut.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.38.193.39]) id QQmrdw24235 for ; Fri, 31 May 2002 02:14:15 GMT Received: from letterbox.scut.edu.cn (mail.scut.edu.cn [202.38.193.69]) by scutsv39.scut.edu.cn (8.9.3/8.9.3) with ESMTP id KAA15795 for ; Fri, 31 May 2002 10:10:46 +0800 (CST) Received: from hchang ([202.38.197.20]) by letterbox.scut.edu.cn (8.12.2/8.9.3) with SMTP id g4V21KUB024282 for ; Fri, 31 May 2002 10:01:21 +0800 (CST) Message-Id: <200205310201.g4V21KUB024282@letterbox.scut.edu.cn> Date: Fri, 31 May 2002 10:17:20 +0800 From: hchang To: MPLS Subject: Fw: Re: RE: how to request the desired bandwidth? RFC3209 section 4.7.3 X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit in my opinion,it must be the "token buchet rate" to be used to specify the desired bandwidth.is it right? >The 'peak data rate' is used to specify the desired bandwidth. > >-Vasanthi >-----Original Message----- >From: Hong Liao [mailto:hliao@telcordia.com] >Sent: Thursday, May 30, 2002 12:00 PM >To: mpls@UU.NET >Subject: how to request the desired bandwidth? RFC3209 section 4.7.3 > > >Hi, > >RFC3209 Section 4.7.3, it says "When a new path message is considered for >admission, the bandwidth requested is compared with the bandwidth available >at the priority specified in the set up priority" > >Here I want to know how to request the desired bandwidth from the path msg. >As I know, in the path message, there is one Sender Tspec object, and >inside this object, it has traffic parameters like 'token bucket rate', >'token bucket size', 'peak data rate'....... I want to know which >parameter can be used to specify the desired bandwidth the node wants. Or >desired BW will not be defined from this object at all? > >Can someone tell me how to request the BW in the Path msg, and if it is not >available, a PathErr msg will be sent back? > >Thanks in an advance. >Julia From owner-mpls@UU.NET Fri May 31 04:02:38 2002 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 EAA08554 for ; Fri, 31 May 2002 04:02:37 -0400 (EDT) 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 QQmreu24476; Fri, 31 May 2002 08:02:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmreu07157 for mpls-outgoing; Fri, 31 May 2002 08:01: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 QQmreu06201 for ; Fri, 31 May 2002 08:01: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 QQmreu19575 for ; Fri, 31 May 2002 08:01:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmreu16834 for ; Fri, 31 May 2002 08:01:02 GMT 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 EAA08329 for ; Fri, 31 May 2002 04:01:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id EAA24427 for mpls@uu.net; Fri, 31 May 2002 04:01:01 -0400 (EDT) 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 QQmreu01473 for ; Fri, 31 May 2002 08:00:35 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 QQmreu07410 for ; Fri, 31 May 2002 08:00:05 GMT Received: from hoemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQmreu21555 for ; Fri, 31 May 2002 08:00:04 GMT Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4V803l28156 for ; Fri, 31 May 2002 04:00:03 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA06017; Fri, 31 May 2002 10:00:02 +0200 (MET DST) Cc: "'Nik Langrind'" , "'Zhi-Wei Lin'" , "R. Muralidharan" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA05758; Fri, 31 May 2002 09:59:49 +0200 (MET DST) Message-ID: <3CF72D74.AA33B74F@lucent.com> Date: Fri, 31 May 2002 09:59:48 +0200 From: Maarten Vissers Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Bernstein, Greg" Original-CC: "'Nik Langrind'" , "'Zhi-Wei Lin'" , "R. Muralidharan" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: Re: Sonet Ring provisioning References: <2135200C183FD5119588009027DE57230151B13B@wntcsdexg02.csd.ciena.com> Content-Type: multipart/mixed; boundary="------------2019723B2ED73142B4D1A066" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------2019723B2ED73142B4D1A066 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nik, This issue is totally unrelated to GMPLS/ASON. The same situation is already present for years in SDH/SONET networks (with connection management under control of NMS). It has been analysed in great details and the conclusion was that hold off timers provide the only solution. Furthermore, in your example you have overall knowledge of the network architecutre and its protection. In practice a connection often is through more than one network operator's domain. And then you don't have overall knowledge. I.e. the outer operator doesn't know if there is protection (and which type(s)) in the inner domain(s). The implication of nested protection for GMPLS/ASON is that the restoration process in GMPLS/ASON must support hold off timers as well. If an operator will use these and what values it will give is outside the scope of GMPLS/ASON work. Furthermore, when a protected connection is to be set up via GMPLS/ASON, GMPLS/ASON must set up the: - working connection, - protection connection, - appropriate monitoring of working connection - appropriate monitoring of protection connection - bridge and selector at A end - bridge and selector at Z end - provisioning of protection related management information as defined in the equipment standards (e.g. G.705, G.783, G.798, I.732) and protection swithcing recommendations (e.g. G.841, G.gps.1); this includes hold off time, wait to restore time, etc. Regards, Maarten "Bernstein, Greg" wrote: > > Hi Nick good points. The interaction of protection types can be tricky. The > typical technique is to use "hold off timers" to first give a "faster" > protection type a chance to respond. This works well when say source > reroute mesh (at say the SONET path layer) is used to back up a connection > that traverses say a number of rings (say BLSRs). However, in your example > below it would also imply waiting an extra time period before kicking of the > mesh. > > Greg > > *********************************** > Dr. Greg M. Bernstein > Senior Technology Director, Ciena Corporation > > -----Original Message----- > From: Nik Langrind [mailto:nik@equipecom.com] > Sent: Thursday, May 30, 2002 7:06 AM > To: 'Zhi-Wei Lin'; R. Muralidharan > Cc: Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET > (E-mail) > Subject: RE: Sonet Ring provisioning > > Hi, > > If a path that is set up via GMPLS signaling traverses a SONET ring, and the > SONET ring is managed via an EMS as Greg suggests, how do the two protection > domains interact? The two protection domains I am thinking of are as > follows: > > 1) The Ring protection domain - failures in the ring itself are protected, > by ring-specific mechanisms > > 2) The end-to-end protection domain - failures anywhere along the path are > protected, presumably by failing over to a diversely routed path > > J------K > / \ > A ------B------H------I L-------O-------Y--------Z > \ \ / / > \ N------M F------G > \ / > C---------------D---------E > > Endpoints A and Z have an LSP (an end-to-end SONET path) switched across the > ring (I-J-K-L-M-N). LSRs B and Y provide a redundant LSP across the path > C-D-E. Presumably, the nodes B and Y provide a path monitoring function, > similar to UPSR, that they can use to initiate a switch to the protect LSP. > > If a failure happens in the ring, it will be recovered from, via > line-switching or ring-switching inside the ring. But the path monitoring > function at nodes B and Y will invoke an LSP protection switch. This is > marginally bad, because it extends the outage by some number of > milliseconds, and it complicates the revert later. > > If the path monitoring function has a holddown timer, such that it does not > invoke a switch until 50 ms of outage, then failures at H or O will not be > reacted to as quickly as possible. > > Instead of performing path monitoring to trigger an LSP-switch, B and Y > could perform line monitoring, and only switch if failures occur on their > local segments? But this seems like it opens up a class of failures which > would not be recovered from. > > So it seems to me that the mixing of protection schemes creates a small > problem, and I wonder what people think about this? > > Nik > > > -----Original Message----- > > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > > Sent: Thursday, May 30, 2002 8:20 AM > > To: R. Muralidharan > > Cc: Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET > > (E-mail) > > Subject: Re: Sonet Ring provisioning > > > > > > Hi all, > > > > Seems we have mixed up a "ring topology" from "ring > > protection mechanism". > > > > * In a general ring topology, *any* recovery mechanism > > may be used. > > This may be the underlying transport's BLSR/MSSPRING or > > UPSR/SNCPRING, or it may be using control plane to set > > up 1+1 or 1:1. > > * In a BLSR/MSSPRING ring, the type of protection has already been > > decided (i.e., BLSR *is* the name of the protection mechanism). > > Similarly for UPSR/SNCPRING. > > > > Thus if we're talking about BLSR/UPSR rings, then the > > question is: how > > does the control plane protocols interact (do they interact?) > > with the > > underlying BLSR/UPSR, e.g., does the control plane simply treat the > > *entire* ring as a single node and thus interfaces to > > existing EMSs to > > ask for a sub-network connection across the "node", or does > > the control > > plane actually see all nodes of the ring and ask individual > > nodes for an > > STS-1/VC-3 connection (but note it only asks for the normal > > channel i.e. > > one connection, since the protection channel comes by default -- the > > service is either protected or unprotected but one connection > > in either > > case)... > > > > Zhi > > > > > > R. Muralidharan wrote: > > > > >Hi All, > > > > > >My understanding is as follows: > > > > > > BLSR or UPSR rings may be already provisioned in the > > SONET network. The > > >task using GMPLS is to set up an end to end virtual path, may be > > >encompassing multiple SONET rings. This virtual path set up > > is dynamic in > > >nature and the life of the path may be only for a fixed > > interval, after > > >which it would be tore down. When one wants to set up a path > > through a SONET > > >ring, one may have to specify whether one wants a 1+1 > > protection path or a > > >1:N protection path or just an unprotected path. Based on > > this specification > > >the GMPLS can discover and set up an appropriate path in a > > BLSR or an UPSR > > >ring as the case may be and hence the cost would be optimum. > > ( assuming that > > >a 1+1 path would cost more than an unprotected path). As > > Greg pointed out, I > > >also believe that the BLSR and UPSR ring configurations > > would already have > > >been set up by associated NMS or EMS and advertised. The > > granularity of the > > >path that can be set up using GMPLS could a VT1.5 or > > multiples of them ( VT > > >Path) or STS-1s (STS Path). > > > > > >I have used the words "path" and "virtual path" in generic > > terms and not in > > >the SONET or SDH domain definitions. > > > > > >Does the above make sense ? > > >regards, > > >murali > > >OSS Systems India > > > > > >----- Original Message ----- > > >From: "Bernstein, Greg" > > >To: "'Manoj Agiwal'" ; "'Ccamp (E-mail)" > > > > > >Cc: "mpls@UU. NET (E-mail)" > > >Sent: Wednesday, May 29, 2002 10:28 PM > > >Subject: RE: Sonet Ring provisioning > > > > > > > > > > > > > > >>Hi Manoj, the UPSR and BLSR cases are very different. I'm > > assuming that > > >> > > >> > > >you > > > > > > > > >>are setting up SONET paths such as STS-1, STS-3c, ... > > STS-192c or their > > >> > > >> > > >SDH > > > > > > > > >>equivalent. > > >>Then > > >>(1) In the BLSR case the protection is at the SONET line > > layer, i.e., > > >> > > >> > > >below > > > > > > > > >>the layer of the connection that you are setting > > up(SONET/SDH are layered > > >>networks). In this case no special action needs to be > > taken unless of > > >>course the entity requesting the connection asked for "enhanced" > > >> > > >> > > >protection > > > > > > > > >>in the setup request. > > >> > > >>(2) A UPSR works at the path layer, i.e., like a path layer > > 1+1, with the > > >>redundant paths taking different routes around the ring. > > Hence you are > > >>actually setting up two connections that have a special > > relationship with > > >>each other. This would have to be indicated somehow (tunnel ID or > > >>something). Some UPSRs may put constraints on the timeslots > > used too. One > > >>meta question is why bother signaling around a UPSR versus > > talking to a > > >> > > >> > > >UPSR > > > > > > > > >>as a separate "protection domain"? There is no way mesh > > restoration could > > >>come close to a UPSR's restoration speed (it just selects > > the better of > > >> > > >> > > >two > > > > > > > > >>signals). Hence I don't understand the benefit signaling > > around the ring > > >> > > >> > > >in > > > > > > > > >>this case, all vendors have methods for setting up their > > UPSRs via EMS's > > >> > > >> > > >why > > > > > > > > >>not just interface to those rather than to the individual > > ring elements... > > >> > > >>Greg B. > > >> > > >>*********************************** > > >>Dr. Greg M. Bernstein > > >>Senior Technology Director, Ciena Corporation > > >> > > >> > > >>-----Original Message----- > > >>From: Manoj Agiwal [mailto:ManojA@netbrahma.com] > > >>Sent: Wednesday, May 29, 2002 2:01 AM > > >>To: 'Ccamp (E-mail) > > >>Cc: mpls@UU. NET (E-mail) > > >>Subject: Sonet Ring provisioning > > >> > > >> > > >>Hi , > > >> Do we use GMPLS signaling protocol for configuring > > Sonet Rings ( > > >> > > >> > > >UPSR > > > > > > > > >>/ BLSR ( 2 fiber/4 > > >> fiber ) ? > > >> > > >> I was going through certain white papers where there > > was a mention > > >>that GMPLS is used as > > >> a signaling protocol for provisioning mesh topologies only > > >>.Traditional Sonet rings will be > > >> replaced by mesh topologies in future . > > >> > > >> But there is a section 12.( LSP protection and > > restoration) in GMPLS > > >>Architecture which says > > >> that " Both mesh and ring like topologies are supported " > > >> > > >> How do we provision nodes in Sonet ring using GMPLS ? > > >> Or GMPLS has been designed to provision mesh topologies only. > > >> > > >>Regards , > > >>Manoj > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > > > > --------------2019723B2ED73142B4D1A066 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------2019723B2ED73142B4D1A066-- From owner-mpls@UU.NET Fri May 31 08:49:12 2002 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 IAA14264 for ; Fri, 31 May 2002 08:49:07 -0400 (EDT) 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 QQmrfn18642; Fri, 31 May 2002 12:48:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrfn10517 for mpls-outgoing; Fri, 31 May 2002 12:48: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 QQmrfn10511 for ; Fri, 31 May 2002 12:48: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 QQmrfn02291 for ; Fri, 31 May 2002 12:48:07 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrfn07182 for ; Fri, 31 May 2002 12:48:02 GMT 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 IAA15975 for ; Fri, 31 May 2002 08:48:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA21458 for mpls@uu.net; Fri, 31 May 2002 08:48:02 -0400 (EDT) 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 QQmrfn10423 for ; Fri, 31 May 2002 12:46:53 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 QQmrfn26912 for ; Fri, 31 May 2002 12:46: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 QQmrfn23451 for ; Fri, 31 May 2002 12:46:13 GMT Received: from auemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQmrfn23425 for ; Fri, 31 May 2002 12:46:13 GMT Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4VCkBW17202 for ; Fri, 31 May 2002 08:46:11 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA19065; Fri, 31 May 2002 14:46:10 +0200 (MET DST) Cc: Zhi-Wei Lin , "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA18645; Fri, 31 May 2002 14:45:55 +0200 (MET DST) Message-ID: <3CF77082.498B6D7B@lucent.com> Date: Fri, 31 May 2002 14:45:54 +0200 From: Maarten Vissers Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Suresh Katukam Original-CC: Zhi-Wei Lin , "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: Re: Sonet Ring provisioning References: <2135200C183FD5119588009027DE57230151B126@wntcsdexg02.csd.ciena.com> <003601c207b6$cf4bf860$1000a8c0@ossi> <3CF61904.40109@lucent.com> <3CF66E05.F5DB0E93@cisco.com> Content-Type: multipart/mixed; boundary="------------B7651B94689241FB6E15BF5B" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------B7651B94689241FB6E15BF5B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Suresh, >From the HOVC [STS] layer network the ring provides for HOVC unprotected connections. I.e. you set up the connection A-B-C-D and inform the MS SPring [BLSR] ring manager of this connection, and that is it. Some ring managers only need to be given the ingress and egress nodes, and they will set up the connection true the ring at the same time as they configure the necessary MS SPring information in the intermediate switching nodes on the ring. Because the ring is a MS SPring [BLSR] ring, the HOVC connections are protected. This MS SPing configuration is however established before any HOVC connection is routed over it. I.e. it is set up and ready to provide connectivity between its nodes on the ring. Assume that the ring is a sTM-64 ring. In this case the HOVC links between any two nodes will have a 32 VC-4 link connections (or 96 VC-3, or 8 VC-4-4c, or 2 VC-4-16c link connections or a mix). If extra traffic is supported on this ring then there will be another HOVC link between any two nodes with the same number of link connections. In this case, there is a choice to put a connection via the regular HOVC links, or via the extra traffic HOVC links. In the latter case the connection may get interrupted when there is a fault in the ring (extra traffic is dropped). If the ring supports selective MS SPring (NUT feature), then a third HOVC link between the nodes will exist and the size of the HOVC links is not longer fixed (in the example to 32). I.e. for a sTM-N ring with MS SPring protection - HOVC link #1 - protected traffic: 0 .. N/2 VC4 link connections - HOVC link #2 - preemptable traffic: 0 .. N/2 VC4 link connections - HOVC link #3 - unprotected traffic: 0 .. N VC-4 link connections Combinations for e.g. STM-64 ring include [link#1, #2, #3]: [32,32,0], [31,31,2], [30,30,4], etc. See also the functional model of a MS SPring node in G.783. Regards, Maarten Suresh Katukam wrote: > > Let us say that the BLSR ring topology is as follows: > > A --- B --- C > | | > H D > | | > G --- F --- E > > If one wants to create a LSP from A to D via B, C, then A > signals to B, B to C, C to D. Everything is fine. > > If B -- C link fails, what happens next? > > 1. Should B and C keep quite and do not tear down > LSP (because these know that B - C line is protected)? > How about H, G, F, E, D, C nodes? > Do these need to know that these are protecting an LSP that > goes through A to D? What happens if another link G - F fails? > Do these nodes need to inform B or C or A indicating that > these cannot protect B - C link anymore so that B can do > Fast Reroute? > > 2. Should B and C setup a backup LSP (when link fails) around the > ring? Traffic is not affected during this period. This provides > a mechanism for nodes involved in LSP can get information > from nodes that are in backup LSPs. > > I think that there are quite a few issues are not resolved in > this area and taking a simple view is not going to be sufficient > when Fast Reroute and other things come into play. > > Thanks, > Suresh > > Zhi-Wei Lin wrote: > > > > Hi all, > > > > Seems we have mixed up a "ring topology" from "ring protection mechanism". > > > > * In a general ring topology, *any* recovery mechanism may be used. > > This may be the underlying transport's BLSR/MSSPRING or > > UPSR/SNCPRING, or it may be using control plane to set up 1+1 or 1:1. > > * In a BLSR/MSSPRING ring, the type of protection has already been > > decided (i.e., BLSR *is* the name of the protection mechanism). > > Similarly for UPSR/SNCPRING. > > > > Thus if we're talking about BLSR/UPSR rings, then the question is: how > > does the control plane protocols interact (do they interact?) with the > > underlying BLSR/UPSR, e.g., does the control plane simply treat the > > *entire* ring as a single node and thus interfaces to existing EMSs to > > ask for a sub-network connection across the "node", or does the control > > plane actually see all nodes of the ring and ask individual nodes for an > > STS-1/VC-3 connection (but note it only asks for the normal channel i.e. > > one connection, since the protection channel comes by default -- the > > service is either protected or unprotected but one connection in either > > case)... > > > > Zhi > > > > R. Muralidharan wrote: > > > > >Hi All, > > > > > >My understanding is as follows: > > > > > > BLSR or UPSR rings may be already provisioned in the SONET network. The > > >task using GMPLS is to set up an end to end virtual path, may be > > >encompassing multiple SONET rings. This virtual path set up is dynamic in > > >nature and the life of the path may be only for a fixed interval, after > > >which it would be tore down. When one wants to set up a path through a SONET > > >ring, one may have to specify whether one wants a 1+1 protection path or a > > >1:N protection path or just an unprotected path. Based on this specification > > >the GMPLS can discover and set up an appropriate path in a BLSR or an UPSR > > >ring as the case may be and hence the cost would be optimum. ( assuming that > > >a 1+1 path would cost more than an unprotected path). As Greg pointed out, I > > >also believe that the BLSR and UPSR ring configurations would already have > > >been set up by associated NMS or EMS and advertised. The granularity of the > > >path that can be set up using GMPLS could a VT1.5 or multiples of them ( VT > > >Path) or STS-1s (STS Path). > > > > > >I have used the words "path" and "virtual path" in generic terms and not in > > >the SONET or SDH domain definitions. > > > > > >Does the above make sense ? > > >regards, > > >murali > > >OSS Systems India > > > > > >----- Original Message ----- > > >From: "Bernstein, Greg" > > >To: "'Manoj Agiwal'" ; "'Ccamp (E-mail)" > > > > > >Cc: "mpls@UU. NET (E-mail)" > > >Sent: Wednesday, May 29, 2002 10:28 PM > > >Subject: RE: Sonet Ring provisioning > > > > > > > > > > > > > > >>Hi Manoj, the UPSR and BLSR cases are very different. I'm assuming that > > >> > > >> > > >you > > > > > > > > >>are setting up SONET paths such as STS-1, STS-3c, ... STS-192c or their > > >> > > >> > > >SDH > > > > > > > > >>equivalent. > > >>Then > > >>(1) In the BLSR case the protection is at the SONET line layer, i.e., > > >> > > >> > > >below > > > > > > > > >>the layer of the connection that you are setting up(SONET/SDH are layered > > >>networks). In this case no special action needs to be taken unless of > > >>course the entity requesting the connection asked for "enhanced" > > >> > > >> > > >protection > > > > > > > > >>in the setup request. > > >> > > >>(2) A UPSR works at the path layer, i.e., like a path layer 1+1, with the > > >>redundant paths taking different routes around the ring. Hence you are > > >>actually setting up two connections that have a special relationship with > > >>each other. This would have to be indicated somehow (tunnel ID or > > >>something). Some UPSRs may put constraints on the timeslots used too. One > > >>meta question is why bother signaling around a UPSR versus talking to a > > >> > > >> > > >UPSR > > > > > > > > >>as a separate "protection domain"? There is no way mesh restoration could > > >>come close to a UPSR's restoration speed (it just selects the better of > > >> > > >> > > >two > > > > > > > > >>signals). Hence I don't understand the benefit signaling around the ring > > >> > > >> > > >in > > > > > > > > >>this case, all vendors have methods for setting up their UPSRs via EMS's > > >> > > >> > > >why > > > > > > > > >>not just interface to those rather than to the individual ring elements... > > >> > > >>Greg B. > > >> > > >>*********************************** > > >>Dr. Greg M. Bernstein > > >>Senior Technology Director, Ciena Corporation > > >> > > >> > > >>-----Original Message----- > > >>From: Manoj Agiwal [mailto:ManojA@netbrahma.com] > > >>Sent: Wednesday, May 29, 2002 2:01 AM > > >>To: 'Ccamp (E-mail) > > >>Cc: mpls@UU. NET (E-mail) > > >>Subject: Sonet Ring provisioning > > >> > > >> > > >>Hi , > > >> Do we use GMPLS signaling protocol for configuring Sonet Rings ( > > >> > > >> > > >UPSR > > > > > > > > >>/ BLSR ( 2 fiber/4 > > >> fiber ) ? > > >> > > >> I was going through certain white papers where there was a mention > > >>that GMPLS is used as > > >> a signaling protocol for provisioning mesh topologies only > > >>.Traditional Sonet rings will be > > >> replaced by mesh topologies in future . > > >> > > >> But there is a section 12.( LSP protection and restoration) in GMPLS > > >>Architecture which says > > >> that " Both mesh and ring like topologies are supported " > > >> > > >> How do we provision nodes in Sonet ring using GMPLS ? > > >> Or GMPLS has been designed to provision mesh topologies only. > > >> > > >>Regards , > > >>Manoj > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > > > > --------------B7651B94689241FB6E15BF5B Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------B7651B94689241FB6E15BF5B-- From owner-mpls@UU.NET Fri May 31 09:39:01 2002 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 JAA16141 for ; Fri, 31 May 2002 09:39:00 -0400 (EDT) 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 QQmrfq15710; Fri, 31 May 2002 13:38:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrfq07547 for mpls-outgoing; Fri, 31 May 2002 13:38:11 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 QQmrfq07542 for ; Fri, 31 May 2002 13:38:09 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 QQmrfq24782 for ; Fri, 31 May 2002 13:37:12 GMT Received: from atlntex01.movaz.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: exchange.movaz.com [65.205.166.141]) id QQmrfq13789 for ; Fri, 31 May 2002 13:37:12 GMT Received: from BLIULAPTOP ([172.16.24.104]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 31 May 2002 09:37:11 -0400 Message-ID: <015e01c208a8$4452cc00$681810ac@movaz.com> From: "Adrian Farrel" To: "'mpls@uu.net'" Cc: "Cheng-Yin Lee" Subject: Fw: I-D ACTION:draft-lee-ccamp-rsvp-te-exclude-route-00.txt Date: Fri, 31 May 2002 09:37:11 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 31 May 2002 13:37:11.0785 (UTC) FILETIME=[4493A590:01C208A8] Sender: owner-mpls@UU.NET Precedence: bulk Please note that the following draft has been posted. This replaces draft-lee-rsvp-te-exclude-route-00.txt which was discussed at the CCAMP meeting at the last IETF. Discussion should take place on the CCAMP mailing list. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Friday, May 31, 2002 7:20 AM Subject: I-D ACTION:draft-lee-ccamp-rsvp-te-exclude-route-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Exclude Routes - Extension to RSVP-TE > Author(s) : C. Lee, A. Farrel > Filename : draft-lee-ccamp-rsvp-te-exclude-route-00.txt > Pages : 10 > Date : 30-May-02 > > The current RSVP-TE specification [RSVP-TE] and GMPLS extensions > [GMPLS-RSVP-TE] allow abstract nodes and resources to be explicitly > included in a path setup, but not to be explicitly excluded. > In some systems where precise explicit paths are not computed at the > head end it may be useful to specify and signal abstract nodes and > resources that are to be explicitly excluded from routes. These > exclusions may apply to the whole of a path, or to parts of a path > between two abstract nodes specified in an explicit route. > Shared Risk Link Groups (SRLGs) allow the definition of resources or > groups of resources that share the same risk of failure. The > knowledge of SRLGs may be used to compute diverse paths that can be > used for protection. In systems where it is useful to signal > exclusions, it may be useful to signal SRLGs to indicate groups of > resources that should be excluded on the whole of a path or between > two abstract nodes specified in an explicit path. > This draft specifies ways to communicate route exclusions during path > setup using RSVP-TE. > These approaches are equally applicable to other MPLS TE signaling > protocols such as CR-LDP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-00.txt From owner-mpls@UU.NET Fri May 31 12:23:14 2002 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 MAA21389 for ; Fri, 31 May 2002 12:23:13 -0400 (EDT) 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 QQmrgb10686 for ; Fri, 31 May 2002 16:23:36 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 QQmrgb08137; Fri, 31 May 2002 16:22:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgb25496 for mpls-outgoing; Fri, 31 May 2002 16:22: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 QQmrgb25489 for ; Fri, 31 May 2002 16:22:07 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 QQmrgb02983 for ; Fri, 31 May 2002 16:15:31 GMT Received: from dnsmx1pya.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQmrgb23700 for ; Fri, 31 May 2002 16:15:30 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 MAA09293; Fri, 31 May 2002 12:11:03 -0400 (EDT) Subject: RE: how to request the desired bandwidth? RFC3209 section 4.7.3 To: Vasanthi Thirumalai Cc: "'Hong Liao'" , mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Fri, 31 May 2002 12:11:02 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 05/31/2002 12:11:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, I also think it is 'peak date rate'. But if I sent out the peak date rate very high 'FFFFFFFF', the router should not be able to handle it, and send back the path error message, right? Thanks, Hong (Julia) Liao ATM/Broadband Network Integration Telcordia Technologies, Inc Tel: (973) 829-4570 Fax: (973) 829-5962 Vasanthi Thirumalai To: "'Hong Liao'" , mpls@UU.NET Subject: RE: how to request the desired bandwidth? RFC3209 section 4.7.3 05/30/02 05:40 PM The 'peak data rate' is used to specify the desired bandwidth. -Vasanthi -----Original Message----- From: Hong Liao [mailto:hliao@telcordia.com] Sent: Thursday, May 30, 2002 12:00 PM To: mpls@UU.NET Subject: how to request the desired bandwidth? RFC3209 section 4.7.3 Hi, RFC3209 Section 4.7.3, it says "When a new path message is considered for admission, the bandwidth requested is compared with the bandwidth available at the priority specified in the set up priority" Here I want to know how to request the desired bandwidth from the path msg. As I know, in the path message, there is one Sender Tspec object, and inside this object, it has traffic parameters like 'token bucket rate', 'token bucket size', 'peak data rate'....... I want to know which parameter can be used to specify the desired bandwidth the node wants. Or desired BW will not be defined from this object at all? Can someone tell me how to request the BW in the Path msg, and if it is not available, a PathErr msg will be sent back? Thanks in an advance. Julia From owner-mpls@UU.NET Fri May 31 13:32:49 2002 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 NAA23393 for ; Fri, 31 May 2002 13:32:49 -0400 (EDT) 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 QQmrgg04787; Fri, 31 May 2002 17:32:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgg22935 for mpls-outgoing; Fri, 31 May 2002 17:31: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 QQmrgg22930 for ; Fri, 31 May 2002 17:31:45 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 QQmrgg02518 for ; Fri, 31 May 2002 17:30:04 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgg01727 for ; Fri, 31 May 2002 17:30:02 GMT 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 NAA07785 for ; Fri, 31 May 2002 13:30:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA20911 for mpls@uu.net; Fri, 31 May 2002 13:30:02 -0400 (EDT) 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 QQmrgf22812 for ; Fri, 31 May 2002 17:28: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 QQmrgf05101 for ; Fri, 31 May 2002 17:28:39 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmrgf29837 for ; Fri, 31 May 2002 17:28:39 GMT Received: (qmail 28937 invoked by uid 104); 31 May 2002 17:28:38 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4205. . Clean. Processed in 1.365785 secs); 31 May 2002 17:28:38 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 31 May 2002 17:28:36 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g4VHSPp05213; Fri, 31 May 2002 10:28:28 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 10:28:27 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03647@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'mpls@uu.net'" Cc: "'ppvpn@ppvpn.francetelecom.com'" Subject: Basic LDP Question Date: Fri, 31 May 2002 10:28:26 -0700 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, What problem a mp2p LDP-based MPLS network is trying to solve (like the one used in RFC2547) that can't be done with pure IP forwarding? Note: Don't tell me fast forwarding, because we can do fast IP lookup as well. Yours, Shahram From owner-mpls@UU.NET Fri May 31 13:35:52 2002 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 NAA23484 for ; Fri, 31 May 2002 13:35:51 -0400 (EDT) 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 QQmrgg09583; Fri, 31 May 2002 17:35:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgg23265 for mpls-outgoing; Fri, 31 May 2002 17:34: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 QQmrgg23246 for ; Fri, 31 May 2002 17:34:55 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 QQmrgg11102 for ; Fri, 31 May 2002 17:32:56 GMT Received: from server.nayna.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 67-89-191-66.customer.algx.net [67.89.191.66]) id QQmrgg02054 for ; Fri, 31 May 2002 17:32:55 GMT Received: from relay.nayna.com (relay.nayna.com [10.0.128.11]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA15302; Fri, 31 May 2002 10:32:49 -0700 Received: from nayna.com (dhcp-131-104.nayna.com [10.0.131.104]) by relay.nayna.com (8.9.3/8.9.3) with ESMTP id KAA14864; Fri, 31 May 2002 10:32:19 -0700 Message-ID: <3CF7B381.C43BF07E@nayna.com> Date: Fri, 31 May 2002 10:31:45 -0700 From: Sudheer Dharanikota X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: v.sharma@ieee.org CC: Zhi-Wei Lin , Suresh Katukam , "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: Re: Sonet Ring provisioning References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi All: This is very interesting discussion. Some of the people on this discussion list already looked at some of these issues. Please refer to draft-many-ccamp-srg-01.txt for more information. Here is my opinion: Transport networks provide their own protection mechanisms such as the rings under discussion. As others pointed out it makes good sense to use them for faster restoration times. These rings may be created through NMS/EMS - this is not a concern to the control plane. The real problem is how to represent this ring topology in the control plane for the path computation. Well one proposal as mentioned by Zhi was to represent by a logical node with node capability being "highly protected node" (inheriting the property of the ring). Another way to see this, as mentioned in the srg draft is to represent by point-to-multi point links with the exit points to the ring as the terminating points of the links and define the same "highly protected" property on the links (unlike on the node). Now that we have the links and link property we can use it in the path computation. Once path is computed it is the nodes, which are on the ring and participate in the control plane, to make a connection between the end points. Please refer to the above draft or http://www.cs.odu.edu/~sudheer/technical/papers/journal/SRGPaper.pdf - sudheer Vishal Sharma wrote: > Zhi and all, > > Great discussion! I'm glad we're finally discussing some of these > issues, and highlighting that mix inherent ring protection with > the control domain mechanisms is non-trivial. > > Comments in-line. > > -Vishal > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Zhi-Wei Lin > > Sent: Thursday, May 30, 2002 11:54 AM > > To: Suresh Katukam > > Cc: R. Muralidharan; Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); > > mpls@UU. NET (E-mail) > > Subject: Re: Sonet Ring provisioning > > > > > > Hi Suresh, > > > > Yes agree this is very complex if you try to create too much > > dependencies between control plane and transport plane protection > > interactions. That is why my simplistic approach: > > > > * Control plane sees the entire ring as offering "highly available" > > connections > > * Control plane sets up a single connection across this ring > > "sub-network" (if you think this about this, the entire ring can > > actually be treated by a control plane controller as a single node > > where the BLSR ring nodes may be thought of as aggregate ports on > > the single node) > > * The ring sub-network, by virtue of providing the protection and > > knowing *exactly* how protection is provided can set up the > > protection channel automatically (but control plane need not know > > this as it is irrelevant to the control plane -- it only needs to > > know that the single connection is protected) > > What mechanism will the ring use to setup the internal protection channel? > > Will it require EMS/NMS intervention, as proposed on this thread earlier, > or will there be another sequence of control plane messages (initiated > internal to the ring) to set this path up. The latter would be prefereable > if the objective is to have fully-automated path setup (otherwise, we > have EMS/NMS intervention for the ring), but it does complicate the > control plane protocols (since a new sequence of setup steps may > have to be initiated internal to each ring on the path of the end-to-end > circuit/trail that is being setup. > > -Vishal > > > From owner-mpls@UU.NET Fri May 31 13:38:33 2002 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 NAA23617 for ; Fri, 31 May 2002 13:38:33 -0400 (EDT) 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 QQmrgg21893 for ; Fri, 31 May 2002 17:38: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 QQmrgg17675; Fri, 31 May 2002 17:37:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgg23648 for mpls-outgoing; Fri, 31 May 2002 17:36: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 QQmrgg23640 for ; Fri, 31 May 2002 17:36:57 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 QQmrgg22584 for ; Fri, 31 May 2002 17:36: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 QQmrgg16472 for ; Fri, 31 May 2002 17:36:43 GMT Received: from rincewind.office.packetexchange.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmrgg16465 for ; Fri, 31 May 2002 17:36:43 GMT Received: from [80.253.97.111] (helo=[80.253.97.111]) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17DqKE-0004S2-00; Fri, 31 May 2002 18:36:30 +0100 Subject: Re: Basic LDP Question From: Giles Heron To: Shahram Davari Cc: "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03647@nt-exch-yow.pmc-sierra.bc.ca> References: <4B6D09F3B826D411A67300D0B706EFDEB03647@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 31 May 2002 18:36:40 +0000 Message-Id: <1022870200.8186.7.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit 1. Efficient encapsulation of VPN traffic 2. Ability to run VPN on current hardware There are probably other reasons as well... On Fri, 2002-05-31 at 17:28, Shahram Davari wrote: > Hi, > > What problem a mp2p LDP-based MPLS network is trying to solve (like the one used in RFC2547) that can't be done with pure IP forwarding? > > Note: Don't tell me fast forwarding, because we can do fast IP lookup as well. > > Yours, > Shahram > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Fri May 31 13:39:02 2002 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 NAA23651 for ; Fri, 31 May 2002 13:39:02 -0400 (EDT) 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 QQmrgg12246; Fri, 31 May 2002 17:38:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgg23734 for mpls-outgoing; Fri, 31 May 2002 17:38:17 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 QQmrgg23727 for ; Fri, 31 May 2002 17:38:12 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 QQmrgg03972 for ; Fri, 31 May 2002 17:38:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgg13771 for ; Fri, 31 May 2002 17:38:05 GMT 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 NAA08404 for ; Fri, 31 May 2002 13:38:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA22750 for mpls@uu.net; Fri, 31 May 2002 13:38:04 -0400 (EDT) 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 QQmrgg23617 for ; Fri, 31 May 2002 17:36: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 QQmrgg07358 for ; Fri, 31 May 2002 17:34: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 QQmrgg12124 for ; Fri, 31 May 2002 17:34:54 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQmrgg12093 for ; Fri, 31 May 2002 17:34:54 GMT Received: from mira1.cisco.com (IDENT:mirapoint@mira1.cisco.com [64.101.14.50]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4VHYcPK027891; Fri, 31 May 2002 10:34:39 -0700 (PDT) Received: from cisco.com (skatukam-u5.cisco.com [64.101.9.63]) by mira1.cisco.com (Mirapoint) with ESMTP id ABA06617; Fri, 31 May 2002 10:35:00 -0700 (PDT) Message-ID: <3CF7B429.F861B66A@cisco.com> Date: Fri, 31 May 2002 10:34:33 -0700 From: Suresh Katukam Organization: Cisco Systems X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: v.sharma@ieee.org CC: Zhi-Wei Lin , "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: Re: Sonet Ring provisioning References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, Comments in-line.. > > Hi Suresh, > > > > Yes agree this is very complex if you try to create too much > > dependencies between control plane and transport plane protection > > interactions. That is why my simplistic approach: > > > > * Control plane sees the entire ring as offering "highly available" > > connections > > * Control plane sets up a single connection across this ring > > "sub-network" (if you think this about this, the entire ring can > > actually be treated by a control plane controller as a single node > > where the BLSR ring nodes may be thought of as aggregate ports on > > the single node) > > * The ring sub-network, by virtue of providing the protection and > > knowing *exactly* how protection is provided can set up the > > protection channel automatically (but control plane need not know > > this as it is irrelevant to the control plane -- it only needs to > > know that the single connection is protected) > > What mechanism will the ring use to setup the internal protection channel? > > Will it require EMS/NMS intervention, as proposed on this thread earlier, > or will there be another sequence of control plane messages (initiated > internal to the ring) to set this path up. The latter would be prefereable > if the objective is to have fully-automated path setup (otherwise, we > have EMS/NMS intervention for the ring), but it does complicate the > control plane protocols (since a new sequence of setup steps may > have to be initiated internal to each ring on the path of the end-to-end > circuit/trail that is being setup. Yes, this is where the most of the problems are. I was referring to this where GMPLS based messages will be used to setup a path around the ring. I was trying to bring up the issues that may come up during the path setup in the ring. Zhi and Maartin, Please let us know your thoughts on this. Thanks, Suresh > > -Vishal > > > From owner-mpls@UU.NET Fri May 31 13:42:27 2002 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 NAA23805 for ; Fri, 31 May 2002 13:42:27 -0400 (EDT) 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 QQmrgg02871 for ; Fri, 31 May 2002 17:42:50 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 QQmrgg00338; Fri, 31 May 2002 17:41:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgg24130 for mpls-outgoing; Fri, 31 May 2002 17:41: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 QQmrgg24121 for ; Fri, 31 May 2002 17:41: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 QQmrgg21994 for ; Fri, 31 May 2002 17:41:10 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 QQmrgg18345 for ; Fri, 31 May 2002 17:41:09 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4VHf4m81006; Fri, 31 May 2002 10:41:04 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205311741.g4VHf4m81006@merlot.juniper.net> To: Giles Heron cc: Shahram Davari , "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: Re: Basic LDP Question In-Reply-To: Your message of "31 May 2002 18:36:40 -0000." <1022870200.8186.7.camel@gizpad> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <56538.1022866864.1@juniper.net> Date: Fri, 31 May 2002 10:41:04 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Giles, > 1. Efficient encapsulation of VPN traffic > 2. Ability to run VPN on current hardware > > There are probably other reasons as well... One of the "other reasons" is straightforward protection against packet spoofing. Yakov. > > On Fri, 2002-05-31 at 17:28, Shahram Davari wrote: > > Hi, > > > > What problem a mp2p LDP-based MPLS network is trying to solve (like the one used in RFC2547) that can't be done with pure IP forwarding? > > > > Note: Don't tell me fast forwarding, because we can do fast IP lookup as we ll. > > > > Yours, > > Shahram > > > > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > From owner-mpls@UU.NET Fri May 31 13:44:52 2002 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 NAA23914 for ; Fri, 31 May 2002 13:44:52 -0400 (EDT) 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 QQmrgg22841; Fri, 31 May 2002 17:44:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgg24281 for mpls-outgoing; Fri, 31 May 2002 17:43: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 QQmrgg24250 for ; Fri, 31 May 2002 17:43:45 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 QQmrgg10980 for ; Fri, 31 May 2002 17:43:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgg20996 for ; Fri, 31 May 2002 17:43:04 GMT 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 NAA08795 for ; Fri, 31 May 2002 13:43:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA24141 for mpls@uu.net; Fri, 31 May 2002 13:43:03 -0400 (EDT) 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 QQmrgg24143 for ; Fri, 31 May 2002 17:41:43 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 QQmrgg23072 for ; Fri, 31 May 2002 17:41:36 GMT Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmrgg18880 for ; Fri, 31 May 2002 17:41:36 GMT Received: (qmail 18894 invoked by uid 104); 31 May 2002 17:41:35 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4205. . Clean. Processed in 0.440321 secs); 31 May 2002 17:41:35 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 31 May 2002 17:41:34 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g4VHfVp13921; Fri, 31 May 2002 10:41:31 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 10:41:34 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03649@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Giles Heron'" Cc: "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Basic LDP Question Date: Fri, 31 May 2002 10:41:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Giles, > -----Original Message----- > From: Giles Heron [mailto:giles@packetexchange.net] > Sent: Friday, May 31, 2002 2:37 PM > To: Shahram Davari > Cc: 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > Subject: Re: Basic LDP Question > > > 1. Efficient encapsulation of VPN traffic Do you mean the difference between 4 bytes label and 20 bytes IP header? > 2. Ability to run VPN on current hardware But current hardware have IP already, it is much easier to run IP rather than LDP MPLS. isn't it? -Shahram > > There are probably other reasons as well... > > On Fri, 2002-05-31 at 17:28, Shahram Davari wrote: > > Hi, > > > > What problem a mp2p LDP-based MPLS network is trying to > solve (like the one used in RFC2547) that can't be done with > pure IP forwarding? > > > > Note: Don't tell me fast forwarding, because we can do fast > IP lookup as well. > > > > Yours, > > Shahram > > > > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > From owner-mpls@UU.NET Fri May 31 13:46:24 2002 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 NAA23982 for ; Fri, 31 May 2002 13:46:24 -0400 (EDT) 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 QQmrgh25778; Fri, 31 May 2002 17:46:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgg24365 for mpls-outgoing; Fri, 31 May 2002 17:44:40 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 QQmrgg24342 for ; Fri, 31 May 2002 17:44: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 QQmrgg20487 for ; Fri, 31 May 2002 17:43: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 QQmrgg05266 for ; Fri, 31 May 2002 17:43:40 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmrgg04938 for ; Fri, 31 May 2002 17:43:34 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 13:43:27 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B482084@celox-ma1-ems1.celoxnetworks.com> From: "Suryanarayana, Ananth" To: "'Shahram Davari'" , "'mpls@uu.net'" Cc: "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Basic LDP Question Date: Fri, 31 May 2002 13:43:26 -0400 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 traditional IP forwarding is a hopbyhop basis and hence very difficult manage the path taken by a packet (end-too-end)... I think MPLS is like source-routing, but with much more control over the packet flow.. and one of the other uses is for seting up vpns using multiple label header stacks, which is much more simple and efficient then maintaining IP over IP tunnels.. Ananth -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Friday, May 31, 2002 1:28 PM To: 'mpls@uu.net' Cc: 'ppvpn@ppvpn.francetelecom.com' Subject: Basic LDP Question Hi, What problem a mp2p LDP-based MPLS network is trying to solve (like the one used in RFC2547) that can't be done with pure IP forwarding? Note: Don't tell me fast forwarding, because we can do fast IP lookup as well. Yours, Shahram From owner-mpls@UU.NET Fri May 31 13:47:51 2002 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 NAA24068 for ; Fri, 31 May 2002 13:47:51 -0400 (EDT) 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 QQmrgh01282; Fri, 31 May 2002 17:47:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgh25155 for mpls-outgoing; Fri, 31 May 2002 17:47:21 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 QQmrgh25149 for ; Fri, 31 May 2002 17:47: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 QQmrgh00204 for ; Fri, 31 May 2002 17:47:07 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgh27547 for ; Fri, 31 May 2002 17:47:06 GMT 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 NAA09105 for ; Fri, 31 May 2002 13:47:06 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA25223 for mpls@uu.net; Fri, 31 May 2002 13:47:06 -0400 (EDT) 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 QQmrgh24727 for ; Fri, 31 May 2002 17:45:46 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 QQmrgg29404 for ; Fri, 31 May 2002 17:44:12 GMT Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmrgg23893 for ; Fri, 31 May 2002 17:44:10 GMT Received: (qmail 20437 invoked by uid 104); 31 May 2002 17:44:10 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4205. . Clean. Processed in 0.439791 secs); 31 May 2002 17:44:10 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 31 May 2002 17:44:09 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g4VHi6p14659; Fri, 31 May 2002 10:44:06 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 10:44:09 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB0364A@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Yakov Rekhter'" , Giles Heron Cc: "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Basic LDP Question Date: Fri, 31 May 2002 10:44:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Friday, May 31, 2002 1:41 PM > To: Giles Heron > Cc: Shahram Davari; 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > Subject: Re: Basic LDP Question > > > Giles, > > > 1. Efficient encapsulation of VPN traffic > > 2. Ability to run VPN on current hardware > > > > There are probably other reasons as well... > > One of the "other reasons" is straightforward protection > against packet > spoofing. How? in IP also you can do ACL. -Shahram > > Yakov. > > > > > On Fri, 2002-05-31 at 17:28, Shahram Davari wrote: > > > Hi, > > > > > > What problem a mp2p LDP-based MPLS network is trying to > solve (like the one > used in RFC2547) that can't be done with pure IP forwarding? > > > > > > Note: Don't tell me fast forwarding, because we can do > fast IP lookup as we > ll. > > > > > > Yours, > > > Shahram > > > > > > > > -- > > ================================================================= > > Giles Heron Principal Network Architect PacketExchange Ltd. > > ph: +44 7880 506185 "if you build it they will yawn" > > ================================================================= > > > From owner-mpls@UU.NET Fri May 31 13:48:02 2002 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 NAA24081 for ; Fri, 31 May 2002 13:48:01 -0400 (EDT) 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 QQmrgh17945 for ; Fri, 31 May 2002 17:48:26 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 QQmrgh15966; Fri, 31 May 2002 17:47:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgh25180 for mpls-outgoing; Fri, 31 May 2002 17:47: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 QQmrgh25150 for ; Fri, 31 May 2002 17:47:20 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 QQmrgh00244 for ; Fri, 31 May 2002 17:47:08 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgh27551 for ; Fri, 31 May 2002 17:47:07 GMT 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 NAA09109 for ; Fri, 31 May 2002 13:47:07 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA25247 for mpls@uu.net; Fri, 31 May 2002 13:47:07 -0400 (EDT) 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 QQmrgh24732 for ; Fri, 31 May 2002 17:45: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 QQmrgh01581 for ; Fri, 31 May 2002 17:45:06 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 QQmrgh25801 for ; Fri, 31 May 2002 17:45:05 GMT Received: from isi.edu (q06ugy7458hf9vhu@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g4VHite12178; Fri, 31 May 2002 10:44:55 -0700 (PDT) Message-ID: <3CF7B695.8050405@isi.edu> Date: Fri, 31 May 2002 10:44:53 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Yakov Rekhter CC: Giles Heron , Shahram Davari , "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: Re: Basic LDP Question References: <200205311741.g4VHf4m81006@merlot.juniper.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090609080102050009040102" Sender: owner-mpls@UU.NET Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms090609080102050009040102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Yakov Rekhter wrote: >>1. Efficient encapsulation of VPN traffic >>2. Ability to run VPN on current hardware >> >>There are probably other reasons as well... > > One of the "other reasons" is straightforward protection against packet > spoofing. More straightforward than an IP firewall? Lars -- Lars Eggert USC Information Sciences Institute --------------ms090609080102050009040102 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDUzMTE3NDQ1NFowIwYJKoZIhvcNAQkEMRYEFAGuqYZKIjOR 5EmVFLElLkViECITMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYCj+t4ibzQFZ/0KQUQzENdqmTgCPx7k6uIwt24UgIKYo3BH DQ2vMieZ6A3BO8RaBZloxbwV4OO/SqD7o4hnsj8wmo0pWUQspG7l17VqThLcy1i9ScTMpYGV Q79CsPITg7LniSBNCacoe7KnYacIMvCggUZwRSlSW1shc8Z4UyhyMwAAAAAAAA== --------------ms090609080102050009040102-- From owner-mpls@UU.NET Fri May 31 13:49:57 2002 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 NAA24193 for ; Fri, 31 May 2002 13:49:57 -0400 (EDT) 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 QQmrgh05287; Fri, 31 May 2002 17:49:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgh25350 for mpls-outgoing; Fri, 31 May 2002 17:48: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 QQmrgh25308 for ; Fri, 31 May 2002 17:48: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 QQmrgh24951 for ; Fri, 31 May 2002 17:48:05 GMT Received: from rincewind.office.packetexchange.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmrgh02355 for ; Fri, 31 May 2002 17:48:04 GMT Received: from [80.253.97.111] (helo=[80.253.97.111]) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17DqVJ-0004Vb-00; Fri, 31 May 2002 18:47:57 +0100 Subject: RE: Basic LDP Question From: Giles Heron To: Shahram Davari Cc: "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03649@nt-exch-yow.pmc-sierra.bc.ca> References: <4B6D09F3B826D411A67300D0B706EFDEB03649@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 31 May 2002 18:48:07 +0000 Message-Id: <1022870887.8313.1.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2002-05-31 at 17:41, Shahram Davari wrote: > Giles, > > > -----Original Message----- > > From: Giles Heron [mailto:giles@packetexchange.net] > > Sent: Friday, May 31, 2002 2:37 PM > > To: Shahram Davari > > Cc: 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > > Subject: Re: Basic LDP Question > > > > > > 1. Efficient encapsulation of VPN traffic > > Do you mean the difference between 4 bytes label and 20 bytes IP header? yes. > > 2. Ability to run VPN on current hardware > > But current hardware have IP already, it is much easier to run > IP rather than LDP MPLS. isn't it? don't think so. I believe many current routers with MPLS support can push multiple labels when sending a packet, but can't "push" an extra IP header? Giles > -Shahram > > > > > There are probably other reasons as well... > > > > On Fri, 2002-05-31 at 17:28, Shahram Davari wrote: > > > Hi, > > > > > > What problem a mp2p LDP-based MPLS network is trying to > > solve (like the one used in RFC2547) that can't be done with > > pure IP forwarding? > > > > > > Note: Don't tell me fast forwarding, because we can do fast > > IP lookup as well. > > > > > > Yours, > > > Shahram > > > > > > > > -- > > ================================================================= > > Giles Heron Principal Network Architect PacketExchange Ltd. > > ph: +44 7880 506185 "if you build it they will yawn" > > ================================================================= > > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Fri May 31 13:51:46 2002 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 NAA24271 for ; Fri, 31 May 2002 13:51:46 -0400 (EDT) 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 QQmrgh03910; Fri, 31 May 2002 17:51:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgh25644 for mpls-outgoing; Fri, 31 May 2002 17:50:51 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 QQmrgh25623 for ; Fri, 31 May 2002 17:50:48 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 QQmrgh15140 for ; Fri, 31 May 2002 17:50:44 GMT From: ananth.nagarajan@mail.sprint.com Received: from damgwp01.corp.sprint.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker2.sprint.com [199.14.91.106]) id QQmrgh08070 for ; Fri, 31 May 2002 17:50:43 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 g4VHo8t13469; Fri, 31 May 2002 12:50:08 -0500 (CDT) 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 g4VHoYm10524; Fri, 31 May 2002 12:50:34 -0500 (CDT) Received: from localhost (root@localhost) by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id MAA01587; Fri, 31 May 2002 12:50:33 -0500 (CDT) X-OpenMail-Hops: 1 Date: Fri, 31 May 2002 12:50:32 -0500 Message-Id: Subject: RE: Basic LDP Question MIME-Version: 1.0 TO: ananth@celoxnetworks.com, mpls@UU.NET, Shahram_Davari@pmc-sierra.com CC: ppvpn@ppvpn.francetelecom.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 31 May 2002 12:50:32 -0500" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit MPLS is not like source routing. if you use LDP, it is very much like IP routing. Also, source routing is true only if you use "explicit routing". Ananth > -----Original Message----- > From: ananth [mailto:ananth@celoxnetworks.com] > Sent: Friday, May 31, 2002 12:43 PM > To: Shahram.Davari; mpls > Cc: ananth; ppvpn > Subject: RE: Basic LDP Question > > > traditional IP forwarding is a hopbyhop basis and hence very difficult > manage the path taken by a packet (end-too-end)... I think > MPLS is like > source-routing, but with much more control over the packet > flow.. and one of > the other uses is for seting up vpns using multiple label > header stacks, > which is much more simple and efficient then maintaining IP over IP > tunnels.. > > Ananth > > > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Friday, May 31, 2002 1:28 PM > To: 'mpls@uu.net' > Cc: 'ppvpn@ppvpn.francetelecom.com' > Subject: Basic LDP Question > > > Hi, > > What problem a mp2p LDP-based MPLS network is trying to solve > (like the one > used in RFC2547) that can't be done with pure IP forwarding? > > Note: Don't tell me fast forwarding, because we can do fast > IP lookup as > well. > > Yours, > Shahram > > From owner-mpls@UU.NET Fri May 31 13:52:53 2002 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 NAA24339 for ; Fri, 31 May 2002 13:52:53 -0400 (EDT) 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 QQmrgh01908 for ; Fri, 31 May 2002 17:53:12 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 QQmrgh27759; Fri, 31 May 2002 17:51:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgh25651 for mpls-outgoing; Fri, 31 May 2002 17:50:56 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 QQmrgh25629 for ; Fri, 31 May 2002 17:50:50 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 QQmrgh13661 for ; Fri, 31 May 2002 17:50:08 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgh02229 for ; Fri, 31 May 2002 17:50:07 GMT 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 NAA09355 for ; Fri, 31 May 2002 13:50:07 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA26785 for mpls@uu.net; Fri, 31 May 2002 13:50:07 -0400 (EDT) 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 QQmrgh25307 for ; Fri, 31 May 2002 17:48: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 QQmrgh25762 for ; Fri, 31 May 2002 17:48:23 GMT Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmrgh03091 for ; Fri, 31 May 2002 17:48:23 GMT Received: (qmail 8622 invoked by uid 104); 31 May 2002 17:48:22 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4205. . Clean. Processed in 0.474954 secs); 31 May 2002 17:48:22 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 31 May 2002 17:48:21 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g4VHmIp20388; Fri, 31 May 2002 10:48:18 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 10:48:21 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB0364B@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Suryanarayana, Ananth'" , "'mpls@uu.net'" Cc: "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Basic LDP Question Date: Fri, 31 May 2002 10:48:19 -0700 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 1) My question was explicitly related to LDP which can't do source-routing. 2) I was thinking of MPLS over IP not IP over IP. -Shahram > -----Original Message----- > From: Suryanarayana, Ananth [mailto:ananth@celoxnetworks.com] > Sent: Friday, May 31, 2002 1:43 PM > To: Shahram Davari; 'mpls@uu.net' > Cc: 'ppvpn@ppvpn.francetelecom.com' > Subject: RE: Basic LDP Question > > > traditional IP forwarding is a hopbyhop basis and hence very difficult > manage the path taken by a packet (end-too-end)... I think > MPLS is like > source-routing, but with much more control over the packet > flow.. and one of > the other uses is for seting up vpns using multiple label > header stacks, > which is much more simple and efficient then maintaining IP over IP > tunnels.. > > Ananth > > > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Friday, May 31, 2002 1:28 PM > To: 'mpls@uu.net' > Cc: 'ppvpn@ppvpn.francetelecom.com' > Subject: Basic LDP Question > > > Hi, > > What problem a mp2p LDP-based MPLS network is trying to solve > (like the one > used in RFC2547) that can't be done with pure IP forwarding? > > Note: Don't tell me fast forwarding, because we can do fast > IP lookup as > well. > > Yours, > Shahram > From owner-mpls@UU.NET Fri May 31 13:53:36 2002 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 NAA24395 for ; Fri, 31 May 2002 13:53:35 -0400 (EDT) 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 QQmrgh13622; Fri, 31 May 2002 17:53:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgh26006 for mpls-outgoing; Fri, 31 May 2002 17:53: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 QQmrgh25960 for ; Fri, 31 May 2002 17:53:06 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 QQmrgh16832 for ; Fri, 31 May 2002 17:52:32 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmrgh12304 for ; Fri, 31 May 2002 17:52:32 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 13:52:32 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B482085@celox-ma1-ems1.celoxnetworks.com> From: "Suryanarayana, Ananth" To: "'Shahram Davari'" , "Suryanarayana, Ananth" , "'mpls@uu.net'" Cc: "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Basic LDP Question Date: Fri, 31 May 2002 13:52:31 -0400 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 If MPLS over IP is used, how can the overlapping VPN IP address be handled.. In case of multiple labels, the label would distinguish the overlapping address spaced packets correctly , isn't it? Ananth -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Friday, May 31, 2002 1:48 PM To: 'Suryanarayana, Ananth'; 'mpls@uu.net' Cc: 'ppvpn@ppvpn.francetelecom.com' Subject: RE: Basic LDP Question 1) My question was explicitly related to LDP which can't do source-routing. 2) I was thinking of MPLS over IP not IP over IP. -Shahram > -----Original Message----- > From: Suryanarayana, Ananth [mailto:ananth@celoxnetworks.com] > Sent: Friday, May 31, 2002 1:43 PM > To: Shahram Davari; 'mpls@uu.net' > Cc: 'ppvpn@ppvpn.francetelecom.com' > Subject: RE: Basic LDP Question > > > traditional IP forwarding is a hopbyhop basis and hence very difficult > manage the path taken by a packet (end-too-end)... I think > MPLS is like > source-routing, but with much more control over the packet > flow.. and one of > the other uses is for seting up vpns using multiple label > header stacks, > which is much more simple and efficient then maintaining IP over IP > tunnels.. > > Ananth > > > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Friday, May 31, 2002 1:28 PM > To: 'mpls@uu.net' > Cc: 'ppvpn@ppvpn.francetelecom.com' > Subject: Basic LDP Question > > > Hi, > > What problem a mp2p LDP-based MPLS network is trying to solve > (like the one > used in RFC2547) that can't be done with pure IP forwarding? > > Note: Don't tell me fast forwarding, because we can do fast > IP lookup as > well. > > Yours, > Shahram > From owner-mpls@UU.NET Fri May 31 13:59:58 2002 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 NAA24613 for ; Fri, 31 May 2002 13:59:58 -0400 (EDT) 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 QQmrgi17600 for ; Fri, 31 May 2002 18:00:15 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 QQmrgh13660; Fri, 31 May 2002 17:58:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgh26703 for mpls-outgoing; Fri, 31 May 2002 17:58: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 QQmrgh26689 for ; Fri, 31 May 2002 17:58:03 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 QQmrgh21321 for ; Fri, 31 May 2002 17:57:08 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgh18089 for ; Fri, 31 May 2002 17:57:07 GMT 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 NAA09920 for ; Fri, 31 May 2002 13:57:07 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA00339 for mpls@uu.net; Fri, 31 May 2002 13:57:07 -0400 (EDT) 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 QQmrgh26235 for ; Fri, 31 May 2002 17:55:32 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 QQmrgh19419 for ; Fri, 31 May 2002 17:54:51 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmrgh12060 for ; Fri, 31 May 2002 17:54:51 GMT Received: (qmail 12126 invoked by uid 104); 31 May 2002 17:54:50 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4205. . Clean. Processed in 0.47842 secs); 31 May 2002 17:54:50 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 31 May 2002 17:54:49 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g4VHskp23012; Fri, 31 May 2002 10:54:46 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 10:54:49 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB0364C@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Suryanarayana, Ananth'" , "'mpls@uu.net'" Cc: "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Basic LDP Question Date: Fri, 31 May 2002 10:54:48 -0700 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 > > If MPLS over IP is used, how can the overlapping VPN IP > address be handled.. By the MPLS label above IP. > In case of multiple labels, the label would distinguish the > overlapping > address spaced packets correctly , isn't it? No. -Shahram > > Ananth > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Friday, May 31, 2002 1:48 PM > To: 'Suryanarayana, Ananth'; 'mpls@uu.net' > Cc: 'ppvpn@ppvpn.francetelecom.com' > Subject: RE: Basic LDP Question > > > 1) My question was explicitly related to LDP which can't do > source-routing. > 2) I was thinking of MPLS over IP not IP over IP. > > -Shahram > > > -----Original Message----- > > From: Suryanarayana, Ananth [mailto:ananth@celoxnetworks.com] > > Sent: Friday, May 31, 2002 1:43 PM > > To: Shahram Davari; 'mpls@uu.net' > > Cc: 'ppvpn@ppvpn.francetelecom.com' > > Subject: RE: Basic LDP Question > > > > > > traditional IP forwarding is a hopbyhop basis and hence > very difficult > > manage the path taken by a packet (end-too-end)... I think > > MPLS is like > > source-routing, but with much more control over the packet > > flow.. and one of > > the other uses is for seting up vpns using multiple label > > header stacks, > > which is much more simple and efficient then maintaining IP over IP > > tunnels.. > > > > Ananth > > > > > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Friday, May 31, 2002 1:28 PM > > To: 'mpls@uu.net' > > Cc: 'ppvpn@ppvpn.francetelecom.com' > > Subject: Basic LDP Question > > > > > > Hi, > > > > What problem a mp2p LDP-based MPLS network is trying to solve > > (like the one > > used in RFC2547) that can't be done with pure IP forwarding? > > > > Note: Don't tell me fast forwarding, because we can do fast > > IP lookup as > > well. > > > > Yours, > > Shahram > > > From owner-mpls@UU.NET Fri May 31 14:00:35 2002 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 OAA24667 for ; Fri, 31 May 2002 14:00:34 -0400 (EDT) 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 QQmrgi23888; Fri, 31 May 2002 18:00:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgh26797 for mpls-outgoing; Fri, 31 May 2002 17:59: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 QQmrgh26782 for ; Fri, 31 May 2002 17:59: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 QQmrgh06128 for ; Fri, 31 May 2002 17:59: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 QQmrgh15922 for ; Fri, 31 May 2002 17:59:28 GMT Received: from mlsrv1.avici.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged)) id QQmrgh15427 for ; Fri, 31 May 2002 17:59:15 GMT Received: from avici.com (swdev105.avici.com [10.2.21.105]) by mlsrv1.avici.com (8.11.0/8.11.0) with ESMTP id g4VHxAn15654 for ; Fri, 31 May 2002 13:59:10 -0400 (EDT) Message-Id: <200205311759.g4VHxAn15654@mlsrv1.avici.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Markus Jork To: mpls@UU.NET Subject: Re: Fw: Re: RE: how to request the desired bandwidth? RFC3209 section 4.7.3 In-reply-to: Your message of "Fri, 31 May 2002 10:17:20 +0800." <200205310201.g4V21KUB024282@letterbox.scut.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 31 May 2002 13:58:14 -0400 Sender: owner-mpls@UU.NET Precedence: bulk It is in fact the token bucket rate, not the peak rate. Markus > > in my opinion,it must be the "token buchet rate" to be used to specify the desired bandwidth.is it right? > > >The 'peak data rate' is used to specify the desired bandwidth. > > > >-Vasanthi > >-----Original Message----- > >From: Hong Liao [mailto:hliao@telcordia.com] > >Sent: Thursday, May 30, 2002 12:00 PM > >To: mpls@UU.NET > >Subject: how to request the desired bandwidth? RFC3209 section 4.7.3 > > > > > >Hi, > > > >RFC3209 Section 4.7.3, it says "When a new path message is considered for > >admission, the bandwidth requested is compared with the bandwidth available > >at the priority specified in the set up priority" > > > >Here I want to know how to request the desired bandwidth from the path msg. > >As I know, in the path message, there is one Sender Tspec object, and > >inside this object, it has traffic parameters like 'token bucket rate', > >'token bucket size', 'peak data rate'....... I want to know which > >parameter can be used to specify the desired bandwidth the node wants. Or > >desired BW will not be defined from this object at all? > > > >Can someone tell me how to request the BW in the Path msg, and if it is not > >available, a PathErr msg will be sent back? > > > >Thanks in an advance. > >Julia > > > > > From owner-mpls@UU.NET Fri May 31 14:02:54 2002 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 OAA24842 for ; Fri, 31 May 2002 14:02:54 -0400 (EDT) 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 QQmrgi00444; Fri, 31 May 2002 18:02:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgi04739 for mpls-outgoing; Fri, 31 May 2002 18:01: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 QQmrgi03838 for ; Fri, 31 May 2002 18:01:40 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 QQmrgi03053 for ; Fri, 31 May 2002 18:01:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgi27474 for ; Fri, 31 May 2002 18:01:05 GMT 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 OAA10299 for ; Fri, 31 May 2002 14:01:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA01534 for mpls@uu.net; Fri, 31 May 2002 14:01:04 -0400 (EDT) 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 QQmrgi26970 for ; Fri, 31 May 2002 18:00:02 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 QQmrgh28618 for ; Fri, 31 May 2002 17:59:37 GMT Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmrgh22941 for ; Fri, 31 May 2002 17:59:37 GMT Received: (qmail 27061 invoked by uid 104); 31 May 2002 17:59:36 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4205. . Clean. Processed in 0.746598 secs); 31 May 2002 17:59:36 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 31 May 2002 17:59:35 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g4VHxWp25148; Fri, 31 May 2002 10:59:32 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 10:59:35 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB0364D@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Giles Heron'" Cc: "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Basic LDP Question Date: Fri, 31 May 2002 10:59:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Giles, > -----Original Message----- > From: Giles Heron [mailto:giles@packetexchange.net] > Sent: Friday, May 31, 2002 2:48 PM > To: Shahram Davari > Cc: 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > Subject: RE: Basic LDP Question > > > On Fri, 2002-05-31 at 17:41, Shahram Davari wrote: > > Giles, > > > > > -----Original Message----- > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > Sent: Friday, May 31, 2002 2:37 PM > > > To: Shahram Davari > > > Cc: 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > > > Subject: Re: Basic LDP Question > > > > > > > > > 1. Efficient encapsulation of VPN traffic > > > > Do you mean the difference between 4 bytes label and 20 > bytes IP header? > > yes. Although you save 16 bytes per packet (~ 3% BW saving, assuming ~500 bytes average IP packet size), but you create another problem: MPLS is much more prune to failure than IP. If an LSR's MPLS switching table is corrupted, the packet ends up in wrong PE, while if a router's IP routing table is corrupted, the next hops could sent the packet to the right destination PE. > > > > 2. Ability to run VPN on current hardware > > > > But current hardware have IP already, it is much easier to run > > IP rather than LDP MPLS. isn't it? > > don't think so. I believe many current routers with MPLS support can > push multiple labels when sending a packet, but can't "push" > an extra IP > header? May be, but when LDP was created there was no box doing VPN. -Shahram > > Giles > > > -Shahram > > > > > > > > There are probably other reasons as well... > > > > > > On Fri, 2002-05-31 at 17:28, Shahram Davari wrote: > > > > Hi, > > > > > > > > What problem a mp2p LDP-based MPLS network is trying to > > > solve (like the one used in RFC2547) that can't be done with > > > pure IP forwarding? > > > > > > > > Note: Don't tell me fast forwarding, because we can do fast > > > IP lookup as well. > > > > > > > > Yours, > > > > Shahram > > > > > > > > > > > -- > > > ================================================================= > > > Giles Heron Principal Network Architect PacketExchange Ltd. > > > ph: +44 7880 506185 "if you build it they will yawn" > > > ================================================================= > > > > > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > From owner-mpls@UU.NET Fri May 31 14:04:25 2002 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 OAA24891 for ; Fri, 31 May 2002 14:04:25 -0400 (EDT) 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 QQmrgi03128; Fri, 31 May 2002 18:03:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgi08970 for mpls-outgoing; Fri, 31 May 2002 18:03: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 QQmrgi08889 for ; Fri, 31 May 2002 18:03: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 QQmrgi06911 for ; Fri, 31 May 2002 18:02:24 GMT Received: from server.nayna.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 67-89-191-66.customer.algx.net [67.89.191.66]) id QQmrgi00209 for ; Fri, 31 May 2002 18:02:23 GMT Received: from relay.nayna.com (relay.nayna.com [10.0.128.11]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA04358; Fri, 31 May 2002 11:02:22 -0700 Received: from nayna.com (dhcp-131-104.nayna.com [10.0.131.104]) by relay.nayna.com (8.9.3/8.9.3) with ESMTP id LAA15141; Fri, 31 May 2002 11:01:52 -0700 Message-ID: <3CF7BA6E.6FB68E86@nayna.com> Date: Fri, 31 May 2002 11:01:18 -0700 From: Sudheer Dharanikota X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: v.sharma@ieee.org CC: Zhi-Wei Lin , Suresh Katukam , "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: Re: Sonet Ring provisioning References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vishal: I agree that representation, path computation and path setup are three problems that we need to solve here. Please refer to the paper I refered to address the first two problems. In the GMPLS P&R design team we are looking at some of the issues related to the path setup. In the current version we are not looking at rings, which we will do later if there is clear consensus to address them. Extra traffic is one of the subjects we will be addressing (again for linear topologies) in the first release. - sudheer Vishal Sharma wrote: > Sudheer, > > While I agree that representing nodes/domains/rings etc. is an important > problem, I think there are two issues being mixed below. > > One is the problem of the initial configuration of the UPSR/BLSR ring, > which is clearly (today) an NMS/EMS operation. > > The other is of dynamically setting up trails on the ring. It is this > latter problem that falls under the purview of an automated control > plane, and is the one being discussed. This will involve the control plane, > and the issue there, as Suresh pointed out, is how does one deal with > mixed mesh-ring networks, similar, for example, to the topology drawn by > Nik Langrind. > > In that case, I don't think the GMPLS specifications are complete enough > to enable one to accomplish path setup. There are several issues > there, including the difficulty of deciding exactly the process by > which path setup on rings will be handled, and how the various items > that Zhi outlined in an earlier email (ring/span switching supported?, > extra traffic supported? etc.) will be handled. > > I see the issue of representation as somewhat tied to how one does > path setup above. That will dictate how the rings and their nodes/links > should be represented in the routing protocols, and how path computation > will take them into account. > > Some of these issues were discussed by us in a draft a while back > http://search.ietf.org/internet-drafts/draft-mannie-mpls-sdh-ospf-isis-02.tx > t > > -Vishal > > > -----Original Message----- > > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > > Sent: Friday, May 31, 2002 10:32 AM > > To: v.sharma@ieee.org > > Cc: Zhi-Wei Lin; Suresh Katukam; R. Muralidharan; Bernstein, Greg; > > 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET (E-mail) > > Subject: Re: Sonet Ring provisioning > > > > > > Hi All: > > > > This is very interesting discussion. > > > > Some of the people on this discussion list already looked > > at some of these issues. Please refer to draft-many-ccamp-srg-01.txt > > for more information. > > > > Here is my opinion: > > > > Transport networks provide their own protection mechanisms such > > as the rings under discussion. As others pointed out it makes good > > sense to use them for faster restoration times. These rings may > > be created through NMS/EMS - this is not a concern to the control > > plane. > > > > The real problem is how to represent this ring topology in the control > > plane for the path computation. Well one proposal as mentioned by > > Zhi was to represent by a logical node with node capability being > > "highly protected node" (inheriting the property of the ring). Another > > way to see this, as mentioned in the srg draft is to represent by > > point-to-multi point links with the exit points to the ring as the > > terminating points of the links and define the same "highly protected" > > property on the links (unlike on the node). Now that we have the > > links and link property we can use it in the path computation. > > Once path is computed it is the nodes, which are on the ring and > > participate in the control plane, to make a connection between > > the end points. Please refer to the above draft or > > http://www.cs.odu.edu/~sudheer/technical/papers/journal/SRGPaper.pdf > > > > - sudheer > > > > > > > > Vishal Sharma wrote: > > > > > Zhi and all, > > > > > > Great discussion! I'm glad we're finally discussing some of these > > > issues, and highlighting that mix inherent ring protection with > > > the control domain mechanisms is non-trivial. > > > > > > Comments in-line. > > > > > > -Vishal > > > > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > > Behalf Of Zhi-Wei Lin > > > > Sent: Thursday, May 30, 2002 11:54 AM > > > > To: Suresh Katukam > > > > Cc: R. Muralidharan; Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); > > > > mpls@UU. NET (E-mail) > > > > Subject: Re: Sonet Ring provisioning > > > > > > > > > > > > Hi Suresh, > > > > > > > > Yes agree this is very complex if you try to create too much > > > > dependencies between control plane and transport plane protection > > > > interactions. That is why my simplistic approach: > > > > > > > > * Control plane sees the entire ring as offering "highly > > available" > > > > connections > > > > * Control plane sets up a single connection across this ring > > > > "sub-network" (if you think this about this, the entire ring can > > > > actually be treated by a control plane controller as a > > single node > > > > where the BLSR ring nodes may be thought of as > > aggregate ports on > > > > the single node) > > > > * The ring sub-network, by virtue of providing the protection and > > > > knowing *exactly* how protection is provided can set up the > > > > protection channel automatically (but control plane > > need not know > > > > this as it is irrelevant to the control plane -- it > > only needs to > > > > know that the single connection is protected) > > > > > > What mechanism will the ring use to setup the internal > > protection channel? > > > > > > Will it require EMS/NMS intervention, as proposed on this > > thread earlier, > > > or will there be another sequence of control plane messages (initiated > > > internal to the ring) to set this path up. The latter would be > > prefereable > > > if the objective is to have fully-automated path setup (otherwise, we > > > have EMS/NMS intervention for the ring), but it does complicate the > > > control plane protocols (since a new sequence of setup steps may > > > have to be initiated internal to each ring on the path of the end-to-end > > > circuit/trail that is being setup. > > > > > > -Vishal > > > > > > > From owner-mpls@UU.NET Fri May 31 14:05:38 2002 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 OAA25002 for ; Fri, 31 May 2002 14:05:38 -0400 (EDT) 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 QQmrgi01854; Fri, 31 May 2002 18:05:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgi09722 for mpls-outgoing; Fri, 31 May 2002 18:04:56 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 QQmrgi09667 for ; Fri, 31 May 2002 18:04:52 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 QQmrgi17848 for ; Fri, 31 May 2002 18:04:28 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 QQmrgi04008 for ; Fri, 31 May 2002 18:04:27 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4VI4Om82739; Fri, 31 May 2002 11:04:24 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205311804.g4VI4Om82739@merlot.juniper.net> To: Shahram Davari cc: Giles Heron , "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: Re: Basic LDP Question In-Reply-To: Your message of "Fri, 31 May 2002 10:44:07 PDT." <4B6D09F3B826D411A67300D0B706EFDEB0364A@nt-exch-yow.pmc-sierra.bc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <67164.1022868264.1@juniper.net> Date: Fri, 31 May 2002 11:04:24 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk > > -----Original Message----- > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > Sent: Friday, May 31, 2002 1:41 PM > > To: Giles Heron > > Cc: Shahram Davari; 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > > Subject: Re: Basic LDP Question > > > > > > Giles, > > > > > 1. Efficient encapsulation of VPN traffic > > > 2. Ability to run VPN on current hardware > > > > > > There are probably other reasons as well... > > > > One of the "other reasons" is straightforward protection > > against packet > > spoofing. > > How? read draft-behringer-mpls-security-01.txt > in IP also you can do ACL. yes, but it has its own cost/complexity. Yakov. From owner-mpls@UU.NET Fri May 31 14:07:59 2002 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 OAA25087 for ; Fri, 31 May 2002 14:07:59 -0400 (EDT) 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 QQmrgi03915; Fri, 31 May 2002 18:06:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgi12128 for mpls-outgoing; Fri, 31 May 2002 18:06: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 QQmrgi12004 for ; Fri, 31 May 2002 18:06: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 QQmrgi25717 for ; Fri, 31 May 2002 18:05: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 QQmrgi28656 for ; Fri, 31 May 2002 18:05:13 GMT Received: from rincewind.office.packetexchange.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmrgi28633 for ; Fri, 31 May 2002 18:05:13 GMT Received: from [80.253.97.111] (helo=[80.253.97.111]) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17Dqlv-0004Zs-00; Fri, 31 May 2002 19:05:07 +0100 Subject: RE: Basic LDP Question From: Giles Heron To: Shahram Davari Cc: "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB0364D@nt-exch-yow.pmc-sierra.bc.ca> References: <4B6D09F3B826D411A67300D0B706EFDEB0364D@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 31 May 2002 19:05:17 +0000 Message-Id: <1022871917.8388.13.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2002-05-31 at 17:59, Shahram Davari wrote: > Giles, > > > -----Original Message----- > > From: Giles Heron [mailto:giles@packetexchange.net] > > Sent: Friday, May 31, 2002 2:48 PM > > To: Shahram Davari > > Cc: 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > > Subject: RE: Basic LDP Question > > > > > > On Fri, 2002-05-31 at 17:41, Shahram Davari wrote: > > > Giles, > > > > > > > -----Original Message----- > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > Sent: Friday, May 31, 2002 2:37 PM > > > > To: Shahram Davari > > > > Cc: 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > > > > Subject: Re: Basic LDP Question > > > > > > > > > > > > 1. Efficient encapsulation of VPN traffic > > > > > > Do you mean the difference between 4 bytes label and 20 > > bytes IP header? > > > > yes. > > Although you save 16 bytes per packet (~ 3% BW saving, assuming ~500 bytes average IP packet size), but you create another problem: > > MPLS is much more prune to failure than IP. If an LSR's MPLS switching table is > corrupted, the packet ends up in wrong PE, while if a router's IP routing table > is corrupted, the next hops could sent the packet to the right destination PE. agreed. Though of course it always depends on how the IP routing table is corrupted. If it sends packets back the way they came - or into the bit bucket - then you still have a problem :( > > > > > > > 2. Ability to run VPN on current hardware > > > > > > But current hardware have IP already, it is much easier to run > > > IP rather than LDP MPLS. isn't it? > > > > don't think so. I believe many current routers with MPLS support can > > push multiple labels when sending a packet, but can't "push" > > an extra IP > > header? > > May be, but when LDP was created there was no box doing VPN. true. But I think when LDP was created the performance issue which kicked the whole MPLS thing off was still true? Giles > -Shahram > > > > > Giles > > > > > -Shahram > > > > > > > > > > > There are probably other reasons as well... > > > > > > > > On Fri, 2002-05-31 at 17:28, Shahram Davari wrote: > > > > > Hi, > > > > > > > > > > What problem a mp2p LDP-based MPLS network is trying to > > > > solve (like the one used in RFC2547) that can't be done with > > > > pure IP forwarding? > > > > > > > > > > Note: Don't tell me fast forwarding, because we can do fast > > > > IP lookup as well. > > > > > > > > > > Yours, > > > > > Shahram > > > > > > > > > > > > > > -- > > > > ================================================================= > > > > Giles Heron Principal Network Architect PacketExchange Ltd. > > > > ph: +44 7880 506185 "if you build it they will yawn" > > > > ================================================================= > > > > > > > > > -- > > ================================================================= > > Giles Heron Principal Network Architect PacketExchange Ltd. > > ph: +44 7880 506185 "if you build it they will yawn" > > ================================================================= > > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Fri May 31 14:08:01 2002 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 OAA25100 for ; Fri, 31 May 2002 14:08:00 -0400 (EDT) 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 QQmrgi06241; Fri, 31 May 2002 18:07:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgi18578 for mpls-outgoing; Fri, 31 May 2002 18:07: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 QQmrgi18556 for ; Fri, 31 May 2002 18:07: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 QQmrgi01828 for ; Fri, 31 May 2002 18:07:17 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgi09139 for ; Fri, 31 May 2002 18:07:17 GMT 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 OAA10963 for ; Fri, 31 May 2002 14:07:16 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA04723 for mpls@uu.net; Fri, 31 May 2002 14:07:16 -0400 (EDT) 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 QQmrgi12619 for ; Fri, 31 May 2002 18:06:10 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 QQmrgi04660 for ; Fri, 31 May 2002 18:05:40 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mayo.cisco.com [64.102.17.207]) id QQmrgi06639 for ; Fri, 31 May 2002 18:05:39 GMT Received: from VBOLLAPR-W2K2.amer.cisco.com (rtp-vpn1-382.cisco.com [10.82.225.126]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA14522; Fri, 31 May 2002 14:05:36 -0400 (EDT) Date: Fri, 31 May 2002 14:05:36 -0400 (Eastern Daylight Time) From: Vijay Bollapragada To: Shahram Davari cc: "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: Re: Basic LDP Question In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03647@nt-exch-yow.pmc-sierra.bc.ca> Message-ID: X-X-Sender: vbollapr@mayo.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk In the 2547 case, typically u have 2 labels, the vpn_label (bottom label) and the top label is the label to get the packet to the far end PE, Now, LDP is used for this top label. I think u are questioning why use LDP for this bottom_label and why not simply encapsulate the MPLS packet in IP to get the packet to the next_hop PE. If this is your Q, You are absolutely correct and this is what the following draft talks about http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-gre-ip-2547-01.txt IMHO, this is certainly do-able but MPLS in the core give us the ability to do things like Traffic Enginnering which are quite a challenge over pure IP. Thanks, Vijay On Fri, 31 May 2002, Shahram Davari wrote: > Hi, > > What problem a mp2p LDP-based MPLS network is trying to solve (like the one used in RFC2547) that can't be done with pure IP forwarding? > > Note: Don't tell me fast forwarding, because we can do fast IP lookup as well. > > Yours, > Shahram > > From owner-mpls@UU.NET Fri May 31 14:08:11 2002 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 OAA25124 for ; Fri, 31 May 2002 14:08:11 -0400 (EDT) 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 QQmrgi07796 for ; Fri, 31 May 2002 18:08:33 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 QQmrgi05019; Fri, 31 May 2002 18:07:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgi18542 for mpls-outgoing; Fri, 31 May 2002 18:07:16 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 QQmrgi18386 for ; Fri, 31 May 2002 18:07:04 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 QQmrgi15682 for ; Fri, 31 May 2002 18:05:25 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 QQmrgi02121 for ; Fri, 31 May 2002 18:05:25 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4VI5Fm82785; Fri, 31 May 2002 11:05:15 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205311805.g4VI5Fm82785@merlot.juniper.net> To: Lars Eggert cc: Giles Heron , Shahram Davari , "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: Re: Basic LDP Question In-Reply-To: Your message of "Fri, 31 May 2002 10:44:53 PDT." <3CF7B695.8050405@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <67337.1022868315.1@juniper.net> Date: Fri, 31 May 2002 11:05:15 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk > Yakov Rekhter wrote: > >>1. Efficient encapsulation of VPN traffic > >>2. Ability to run VPN on current hardware > >> > >>There are probably other reasons as well... > > > > One of the "other reasons" is straightforward protection against packet > > spoofing. > > More straightforward than an IP firewall? yes. Yakov. From owner-mpls@UU.NET Fri May 31 14:11:41 2002 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 OAA25284 for ; Fri, 31 May 2002 14:11:40 -0400 (EDT) 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 QQmrgi16916; Fri, 31 May 2002 18:11:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgi19962 for mpls-outgoing; Fri, 31 May 2002 18:10: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 QQmrgi19695 for ; Fri, 31 May 2002 18:10:26 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 QQmrgi11011 for ; Fri, 31 May 2002 18:10:04 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgi15067 for ; Fri, 31 May 2002 18:10:03 GMT 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 OAA11288 for ; Fri, 31 May 2002 14:10:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA05825 for mpls@uu.net; Fri, 31 May 2002 14:10:03 -0400 (EDT) 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 QQmrgi19313 for ; Fri, 31 May 2002 18:08:42 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 QQmrgi27853 for ; Fri, 31 May 2002 18:08:39 GMT Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmrgi07984 for ; Fri, 31 May 2002 18:08:38 GMT Received: (qmail 802 invoked by uid 104); 31 May 2002 18:08:38 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4205. . Clean. Processed in 0.441534 secs); 31 May 2002 18:08:38 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 31 May 2002 18:08:37 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g4VI8Yp06041; Fri, 31 May 2002 11:08:34 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 11:08:37 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB0364F@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Vijay Bollapragada'" Cc: "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Basic LDP Question Date: Fri, 31 May 2002 11:08:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Vijay, > -----Original Message----- > From: Vijay Bollapragada [mailto:vbollapr@cisco.com] > Sent: Friday, May 31, 2002 2:06 PM > To: Shahram Davari > Cc: 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > Subject: Re: Basic LDP Question > > > In the 2547 case, typically u have 2 labels, the vpn_label > (bottom label) > and the top label is the label to get the packet to the far > end PE, Now, > LDP is used for this top label. > > I think u are questioning why use LDP for this bottom_label > and why not > simply encapsulate the MPLS packet in IP to get the packet to > the next_hop > PE. If this is your Q, You are absolutely correct and this is what the > following draft talks about > > http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-gre-ip > -2547-01.txt > > IMHO, this is certainly do-able but MPLS in the core give us > the ability > to do things like Traffic Enginnering But LDP does not give you the TE ability. So why use LDP? -Shahram which are quite a challenge over > pure IP. > > Thanks, > Vijay > > > > On Fri, 31 May 2002, Shahram Davari wrote: > > > Hi, > > > > What problem a mp2p LDP-based MPLS network is trying to > solve (like the one used in RFC2547) that can't be done with > pure IP forwarding? > > > > Note: Don't tell me fast forwarding, because we can do fast > IP lookup as well. > > > > Yours, > > Shahram > > > > > From owner-mpls@UU.NET Fri May 31 14:12:46 2002 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 OAA25348 for ; Fri, 31 May 2002 14:12:46 -0400 (EDT) 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 QQmrgi13998; Fri, 31 May 2002 18:12:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgi20536 for mpls-outgoing; Fri, 31 May 2002 18: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 QQmrgi20485 for ; Fri, 31 May 2002 18:12:05 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 QQmrgi05575 for ; Fri, 31 May 2002 18:11: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 QQmrgi16489 for ; Fri, 31 May 2002 18:11:46 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 QQmrgi16426 for ; Fri, 31 May 2002 18:11:45 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4VIBam83288; Fri, 31 May 2002 11:11:36 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205311811.g4VIBam83288@merlot.juniper.net> To: Vijay Bollapragada cc: Shahram Davari , "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: Re: Basic LDP Question In-Reply-To: Your message of "Fri, 31 May 2002 14:05:36 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <69643.1022868696.1@juniper.net> Date: Fri, 31 May 2002 11:11:36 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Vijay, > In the 2547 case, typically u have 2 labels, the vpn_label (bottom label) > and the top label is the label to get the packet to the far end PE, Now, > LDP is used for this top label. > > I think u are questioning why use LDP for this bottom_label and why not > simply encapsulate the MPLS packet in IP to get the packet to the next_hop > PE. If this is your Q, You are absolutely correct and this is what the > following draft talks about > > http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-gre-ip-2547-01.txt Glad you mentioned this draft, as Section 7 in that draft talks about the issue of packet spoofing. Yakov. From owner-mpls@UU.NET Fri May 31 14:18:05 2002 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 OAA25520 for ; Fri, 31 May 2002 14:18:04 -0400 (EDT) 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 QQmrgj21557; Fri, 31 May 2002 18:17:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgj21819 for mpls-outgoing; Fri, 31 May 2002 18:17: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 QQmrgj21803 for ; Fri, 31 May 2002 18:17: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 QQmrgj13617 for ; Fri, 31 May 2002 18:15: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 QQmrgj24976 for ; Fri, 31 May 2002 18:15:04 GMT Received: from granger.mail.mindspring.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: granger.mail.mindspring.net [207.69.200.148]) id QQmrgh19893 for ; Fri, 31 May 2002 17:49:02 GMT Received: from user-1121did.dsl.mindspring.com ([66.32.182.77] helo=METANOIA) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17DqVb-0002Zf-00; Fri, 31 May 2002 13:48:15 -0400 Reply-To: From: "Vishal Sharma" To: "Sudheer Dharanikota" Cc: "Zhi-Wei Lin" , "Suresh Katukam" , "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp \(E-mail\)" , "mpls@UU. NET \(E-mail\)" Subject: RE: Sonet Ring provisioning Date: Fri, 31 May 2002 10:54:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3CF7B381.C43BF07E@nayna.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sudheer, While I agree that representing nodes/domains/rings etc. is an important problem, I think there are two issues being mixed below. One is the problem of the initial configuration of the UPSR/BLSR ring, which is clearly (today) an NMS/EMS operation. The other is of dynamically setting up trails on the ring. It is this latter problem that falls under the purview of an automated control plane, and is the one being discussed. This will involve the control plane, and the issue there, as Suresh pointed out, is how does one deal with mixed mesh-ring networks, similar, for example, to the topology drawn by Nik Langrind. In that case, I don't think the GMPLS specifications are complete enough to enable one to accomplish path setup. There are several issues there, including the difficulty of deciding exactly the process by which path setup on rings will be handled, and how the various items that Zhi outlined in an earlier email (ring/span switching supported?, extra traffic supported? etc.) will be handled. I see the issue of representation as somewhat tied to how one does path setup above. That will dictate how the rings and their nodes/links should be represented in the routing protocols, and how path computation will take them into account. Some of these issues were discussed by us in a draft a while back http://search.ietf.org/internet-drafts/draft-mannie-mpls-sdh-ospf-isis-02.tx t -Vishal > -----Original Message----- > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > Sent: Friday, May 31, 2002 10:32 AM > To: v.sharma@ieee.org > Cc: Zhi-Wei Lin; Suresh Katukam; R. Muralidharan; Bernstein, Greg; > 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET (E-mail) > Subject: Re: Sonet Ring provisioning > > > Hi All: > > This is very interesting discussion. > > Some of the people on this discussion list already looked > at some of these issues. Please refer to draft-many-ccamp-srg-01.txt > for more information. > > Here is my opinion: > > Transport networks provide their own protection mechanisms such > as the rings under discussion. As others pointed out it makes good > sense to use them for faster restoration times. These rings may > be created through NMS/EMS - this is not a concern to the control > plane. > > The real problem is how to represent this ring topology in the control > plane for the path computation. Well one proposal as mentioned by > Zhi was to represent by a logical node with node capability being > "highly protected node" (inheriting the property of the ring). Another > way to see this, as mentioned in the srg draft is to represent by > point-to-multi point links with the exit points to the ring as the > terminating points of the links and define the same "highly protected" > property on the links (unlike on the node). Now that we have the > links and link property we can use it in the path computation. > Once path is computed it is the nodes, which are on the ring and > participate in the control plane, to make a connection between > the end points. Please refer to the above draft or > http://www.cs.odu.edu/~sudheer/technical/papers/journal/SRGPaper.pdf > > - sudheer > > > > Vishal Sharma wrote: > > > Zhi and all, > > > > Great discussion! I'm glad we're finally discussing some of these > > issues, and highlighting that mix inherent ring protection with > > the control domain mechanisms is non-trivial. > > > > Comments in-line. > > > > -Vishal > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > Behalf Of Zhi-Wei Lin > > > Sent: Thursday, May 30, 2002 11:54 AM > > > To: Suresh Katukam > > > Cc: R. Muralidharan; Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); > > > mpls@UU. NET (E-mail) > > > Subject: Re: Sonet Ring provisioning > > > > > > > > > Hi Suresh, > > > > > > Yes agree this is very complex if you try to create too much > > > dependencies between control plane and transport plane protection > > > interactions. That is why my simplistic approach: > > > > > > * Control plane sees the entire ring as offering "highly > available" > > > connections > > > * Control plane sets up a single connection across this ring > > > "sub-network" (if you think this about this, the entire ring can > > > actually be treated by a control plane controller as a > single node > > > where the BLSR ring nodes may be thought of as > aggregate ports on > > > the single node) > > > * The ring sub-network, by virtue of providing the protection and > > > knowing *exactly* how protection is provided can set up the > > > protection channel automatically (but control plane > need not know > > > this as it is irrelevant to the control plane -- it > only needs to > > > know that the single connection is protected) > > > > What mechanism will the ring use to setup the internal > protection channel? > > > > Will it require EMS/NMS intervention, as proposed on this > thread earlier, > > or will there be another sequence of control plane messages (initiated > > internal to the ring) to set this path up. The latter would be > prefereable > > if the objective is to have fully-automated path setup (otherwise, we > > have EMS/NMS intervention for the ring), but it does complicate the > > control plane protocols (since a new sequence of setup steps may > > have to be initiated internal to each ring on the path of the end-to-end > > circuit/trail that is being setup. > > > > -Vishal > > > > > From owner-mpls@UU.NET Fri May 31 14:19:54 2002 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 OAA25551 for ; Fri, 31 May 2002 14:19:54 -0400 (EDT) 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 QQmrgj05798 for ; Fri, 31 May 2002 18:20: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 QQmrgj01651; Fri, 31 May 2002 18:18:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgj21853 for mpls-outgoing; Fri, 31 May 2002 18:18: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 QQmrgj21843 for ; Fri, 31 May 2002 18:17:56 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 QQmrgj19956 for ; Fri, 31 May 2002 18:17:04 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgj01431 for ; Fri, 31 May 2002 18:17:03 GMT 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 OAA12036 for ; Fri, 31 May 2002 14:17:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA08931 for mpls@uu.net; Fri, 31 May 2002 14:17:03 -0400 (EDT) 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 QQmrgj21603 for ; Fri, 31 May 2002 18:16: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 QQmrgi17411 for ; Fri, 31 May 2002 18:14: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 QQmrgi24574 for ; Fri, 31 May 2002 18:14:57 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmrgi24550 for ; Fri, 31 May 2002 18:14:56 GMT Received: (qmail 3238 invoked by uid 104); 31 May 2002 18:14:55 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4205. . Clean. Processed in 0.459429 secs); 31 May 2002 18:14:55 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 31 May 2002 18:14:55 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g4VIEqp08312; Fri, 31 May 2002 11:14:52 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 11:14:54 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03651@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Sukanta ganguly'" , "Suryanarayana, Ananth" , "'mpls@uu.net'" Cc: "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Basic LDP Question Date: Fri, 31 May 2002 11:14:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk LDP path is the same as IP path, and can change over time, therefore is not predictable. -Shahram > -----Original Message----- > From: Sukanta ganguly [mailto:sganguly@yahoo.com] > Sent: Friday, May 31, 2002 2:03 PM > To: Suryanarayana, Ananth; Shahram Davari; 'mpls@uu.net' > Cc: 'ppvpn@ppvpn.francetelecom.com' > Subject: RE: Basic LDP Question > > > Sharam, > LDP helps to lay out the path the packet will travel > from ingress to egress of the MPLS path. It is not > exactly source based routing but a predictive path is > built for the packets with certain colors. > > Ananth, > MPLS itself can be a VPN path when > security/encryption is associated with the packet. So > don't think of it has a IP-VPN enclosed in an MPLS > VPN. They do not overlap. However, I have heard of > talks of MPLS VPN on top of IP VPN. This could be due > to the fact that an IPVPN already exists and MPLS > based paths are new addition. > > SG > > > > --- "Suryanarayana, Ananth" > wrote: > > > > If MPLS over IP is used, how can the overlapping VPN > > IP address be handled.. > > In case of multiple labels, the label would > > distinguish the overlapping > > address spaced packets correctly , isn't it? > > > > Ananth > > > > -----Original Message----- > > From: Shahram Davari > > [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Friday, May 31, 2002 1:48 PM > > To: 'Suryanarayana, Ananth'; 'mpls@uu.net' > > Cc: 'ppvpn@ppvpn.francetelecom.com' > > Subject: RE: Basic LDP Question > > > > > > 1) My question was explicitly related to LDP which > > can't do source-routing. > > 2) I was thinking of MPLS over IP not IP over IP. > > > > -Shahram > > > > > -----Original Message----- > > > From: Suryanarayana, Ananth > > [mailto:ananth@celoxnetworks.com] > > > Sent: Friday, May 31, 2002 1:43 PM > > > To: Shahram Davari; 'mpls@uu.net' > > > Cc: 'ppvpn@ppvpn.francetelecom.com' > > > Subject: RE: Basic LDP Question > > > > > > > > > traditional IP forwarding is a hopbyhop basis and > > hence very difficult > > > manage the path taken by a packet (end-too-end)... > > I think > > > MPLS is like > > > source-routing, but with much more control over > > the packet > > > flow.. and one of > > > the other uses is for seting up vpns using > > multiple label > > > header stacks, > > > which is much more simple and efficient then > > maintaining IP over IP > > > tunnels.. > > > > > > Ananth > > > > > > > > > > > > -----Original Message----- > > > From: Shahram Davari > > [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Friday, May 31, 2002 1:28 PM > > > To: 'mpls@uu.net' > > > Cc: 'ppvpn@ppvpn.francetelecom.com' > > > Subject: Basic LDP Question > > > > > > > > > Hi, > > > > > > What problem a mp2p LDP-based MPLS network is > > trying to solve > > > (like the one > > > used in RFC2547) that can't be done with pure IP > > forwarding? > > > > > > Note: Don't tell me fast forwarding, because we > > can do fast > > > IP lookup as > > > well. > > > > > > Yours, > > > Shahram > > > > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > From owner-mpls@UU.NET Fri May 31 14:34:18 2002 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 OAA26022 for ; Fri, 31 May 2002 14:34:17 -0400 (EDT) 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 QQmrgk01313; Fri, 31 May 2002 18:33:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgk23325 for mpls-outgoing; Fri, 31 May 2002 18:33: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 QQmrgk23320 for ; Fri, 31 May 2002 18:32: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 QQmrgk23476 for ; Fri, 31 May 2002 18:32: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 QQmrgk29338 for ; Fri, 31 May 2002 18:32:33 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgk29332 for ; Fri, 31 May 2002 18:32:32 GMT 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 OAA13169 for ; Fri, 31 May 2002 14:32:32 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA12770 for mpls@uu.net; Fri, 31 May 2002 14:32:32 -0400 (EDT) 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 QQmrgi17203 for ; Fri, 31 May 2002 18:06: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 QQmrgi28782 for ; Fri, 31 May 2002 18:06:15 GMT Received: from web12501.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web12501.mail.yahoo.com [216.136.173.193]) id QQmrgi03653 for ; Fri, 31 May 2002 18:06:14 GMT Message-ID: <20020531180613.51248.qmail@web12501.mail.yahoo.com> Received: from [66.122.195.194] by web12501.mail.yahoo.com via HTTP; Fri, 31 May 2002 11:06:13 PDT Date: Fri, 31 May 2002 11:06:13 -0700 (PDT) From: Sukanta ganguly Subject: Re: Basic LDP Question To: Lars Eggert , Yakov Rekhter Cc: Giles Heron , Shahram Davari , "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" In-Reply-To: <3CF7B695.8050405@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Lars, I am not sure about the more straight forwardness than an IP firewall, but I certainly agree to the layering of labels allowing multiple predictive paths that can be choosen quite dynamically which IP does not allow. As a matter of fact I would actually like to know your reasoning as far as the simplicity of straight forwardness that you see on an MPLS based firewall, which does not exists in the IP firewall. SG --- Lars Eggert wrote: > Yakov Rekhter wrote: > >>1. Efficient encapsulation of VPN traffic > >>2. Ability to run VPN on current hardware > >> > >>There are probably other reasons as well... > > > > One of the "other reasons" is straightforward > protection against packet > > spoofing. > > More straightforward than an IP firewall? > > Lars > -- > Lars Eggert USC > Information Sciences Institute > > ATTACHMENT part 2 application/x-pkcs7-signature name=smime.p7s __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-mpls@UU.NET Fri May 31 14:37:31 2002 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 OAA26250 for ; Fri, 31 May 2002 14:37:31 -0400 (EDT) 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 QQmrgk25634; Fri, 31 May 2002 18:37:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgk23643 for mpls-outgoing; Fri, 31 May 2002 18:36: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 QQmrgk23634 for ; Fri, 31 May 2002 18:36:44 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 QQmrgk16326 for ; Fri, 31 May 2002 18:36:09 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 QQmrgk07458 for ; Fri, 31 May 2002 18:36:07 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgk07425 for ; Fri, 31 May 2002 18:36:07 GMT 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 OAA13474 for ; Fri, 31 May 2002 14:36:06 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA13482 for mpls@uu.net; Fri, 31 May 2002 14:36:06 -0400 (EDT) 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 QQmrgk23446 for ; Fri, 31 May 2002 18:34:54 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 QQmrgk09537 for ; Fri, 31 May 2002 18:34:23 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mayo.cisco.com [64.102.17.207]) id QQmrgk02850 for ; Fri, 31 May 2002 18:34:21 GMT Received: from VBOLLAPR-W2K2.amer.cisco.com (rtp-vpn1-382.cisco.com [10.82.225.126]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA15578; Fri, 31 May 2002 14:34:18 -0400 (EDT) Date: Fri, 31 May 2002 14:34:18 -0400 (Eastern Daylight Time) From: Vijay Bollapragada To: Shahram Davari cc: "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Basic LDP Question In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB0364F@nt-exch-yow.pmc-sierra.bc.ca> Message-ID: X-X-Sender: vbollapr@mayo.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 31 May 2002, Shahram Davari wrote: > Vijay, > But LDP does not give you the TE ability. So why use LDP? Agreed, that LDP does not give the ability to do TE, I only said use MPLS in the core, not necassarily LDP :-) but in any case, Here is what 2547 draft says about using LDP for the top label.. Section 4.3.2 "All that matters for the VPN architecture is that some label switched path between the router and its BGP next hop exists. However, to ensure interoperability among systems which implement this VPN architecture, all such systems must support LDP [MPLS-LDP]." Of course, once could use many other mechanisms to get the vpn_labeled packet from one edge PE to another edge PE, Interoperability is the key here. Thanks, Vijay > > > -----Original Message----- > > From: Vijay Bollapragada [mailto:vbollapr@cisco.com] > > Sent: Friday, May 31, 2002 2:06 PM > > To: Shahram Davari > > Cc: 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > > Subject: Re: Basic LDP Question > > > > > > In the 2547 case, typically u have 2 labels, the vpn_label > > (bottom label) > > and the top label is the label to get the packet to the far > > end PE, Now, > > LDP is used for this top label. > > > > I think u are questioning why use LDP for this bottom_label > > and why not > > simply encapsulate the MPLS packet in IP to get the packet to > > the next_hop > > PE. If this is your Q, You are absolutely correct and this is what the > > following draft talks about > > > > http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-gre-ip > > -2547-01.txt > > > > IMHO, this is certainly do-able but MPLS in the core give us > > the ability > > to do things like Traffic Enginnering > > > -Shahram > > which are quite a challenge over > > pure IP. > > > > Thanks, > > Vijay > > > > > > > > On Fri, 31 May 2002, Shahram Davari wrote: > > > > > Hi, > > > > > > What problem a mp2p LDP-based MPLS network is trying to > > solve (like the one used in RFC2547) that can't be done with > > pure IP forwarding? > > > > > > Note: Don't tell me fast forwarding, because we can do fast > > IP lookup as well. > > > > > > Yours, > > > Shahram > > > > > > > > > From owner-mpls@UU.NET Fri May 31 14:43:50 2002 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 OAA26421 for ; Fri, 31 May 2002 14:43:50 -0400 (EDT) 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 QQmrgk26764 for ; Fri, 31 May 2002 18:44: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 QQmrgk23163; Fri, 31 May 2002 18:42:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgk24011 for mpls-outgoing; Fri, 31 May 2002 18:42: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 QQmrgk24006 for ; Fri, 31 May 2002 18:42:10 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 QQmrgk17094 for ; Fri, 31 May 2002 18:42:03 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 QQmrgk21794 for ; Fri, 31 May 2002 18:42:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgk21789 for ; Fri, 31 May 2002 18:42:02 GMT 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 OAA13882 for ; Fri, 31 May 2002 14:42:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA15042 for mpls@uu.net; Fri, 31 May 2002 14:42:01 -0400 (EDT) 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 QQmrgk23898 for ; Fri, 31 May 2002 18:40:12 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 QQmrgk09884 for ; Fri, 31 May 2002 18:39:45 GMT Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmrgk10324 for ; Fri, 31 May 2002 18:39:45 GMT Received: (qmail 14785 invoked by uid 104); 31 May 2002 18:39:44 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4205. . Clean. Processed in 0.424944 secs); 31 May 2002 18:39:44 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 31 May 2002 18:39:43 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g4VIdep25440; Fri, 31 May 2002 11:39:40 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 11:39:43 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03652@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Yakov Rekhter'" Cc: Giles Heron , "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Basic LDP Question Date: Fri, 31 May 2002 11:39:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > > in IP also you can do ACL. > > yes, but it has its own cost/complexity. Sure, but using LDP you are forced to run some kind of OAM, to detect mis-config of LSRs. So nothing is gained. The cost/complexity of filtering is replaced with cost/complexity of OAM. -Shahram From owner-mpls@UU.NET Fri May 31 14:44:58 2002 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 OAA26444 for ; Fri, 31 May 2002 14:44:58 -0400 (EDT) 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 QQmrgk05929; Fri, 31 May 2002 18:44:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgk24072 for mpls-outgoing; Fri, 31 May 2002 18:44:03 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 QQmrgk24060 for ; Fri, 31 May 2002 18:43:59 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 QQmrgk08087 for ; Fri, 31 May 2002 18:43: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 QQmrgk25149 for ; Fri, 31 May 2002 18:43:26 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgk24482 for ; Fri, 31 May 2002 18:43:08 GMT 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 OAA13968 for ; Fri, 31 May 2002 14:43:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA15176 for mpls@uu.net; Fri, 31 May 2002 14:43:02 -0400 (EDT) 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 QQmrgk23974 for ; Fri, 31 May 2002 18:41: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 QQmrgk15906 for ; Fri, 31 May 2002 18:41:39 GMT Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmrgk02060 for ; Fri, 31 May 2002 18:41:38 GMT Received: (qmail 15719 invoked by uid 104); 31 May 2002 18:41:37 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4205. . Clean. Processed in 0.452576 secs); 31 May 2002 18:41:37 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 31 May 2002 18:41:37 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g4VIfXp26260; Fri, 31 May 2002 11:41:33 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 11:41:36 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03653@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Vijay Bollapragada'" Cc: "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Basic LDP Question Date: Fri, 31 May 2002 11:41:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Vijay, I know all this. The question was: "Why use LDP instead of IP?". If you have an answer please provide. -Shahram > -----Original Message----- > From: Vijay Bollapragada [mailto:vbollapr@cisco.com] > Sent: Friday, May 31, 2002 2:34 PM > To: Shahram Davari > Cc: 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > Subject: RE: Basic LDP Question > > > On Fri, 31 May 2002, Shahram Davari wrote: > > > Vijay, > > > But LDP does not give you the TE ability. So why use LDP? > > Agreed, that LDP does not give the ability to do TE, I only > said use MPLS > in the core, not necassarily LDP :-) but in any case, Here is > what 2547 > draft says about using LDP for the top label.. > > Section 4.3.2 > > "All that matters for the VPN architecture is that some label switched > path between the router and its BGP next hop exists. > However, to ensure > interoperability among systems which implement this VPN architecture, > all such systems must support LDP [MPLS-LDP]." > > Of course, once could use many other mechanisms to get the vpn_labeled > packet from one edge PE to another edge PE, Interoperability > is the key > here. > > Thanks, > Vijay > > > > > > > > -----Original Message----- > > > From: Vijay Bollapragada [mailto:vbollapr@cisco.com] > > > Sent: Friday, May 31, 2002 2:06 PM > > > To: Shahram Davari > > > Cc: 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > > > Subject: Re: Basic LDP Question > > > > > > > > > In the 2547 case, typically u have 2 labels, the vpn_label > > > (bottom label) > > > and the top label is the label to get the packet to the far > > > end PE, Now, > > > LDP is used for this top label. > > > > > > I think u are questioning why use LDP for this bottom_label > > > and why not > > > simply encapsulate the MPLS packet in IP to get the packet to > > > the next_hop > > > PE. If this is your Q, You are absolutely correct and > this is what the > > > following draft talks about > > > > > > http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-gre-ip > > > -2547-01.txt > > > > > > IMHO, this is certainly do-able but MPLS in the core give us > > > the ability > > > to do things like Traffic Enginnering > > > > > > -Shahram > > > > which are quite a challenge over > > > pure IP. > > > > > > Thanks, > > > Vijay > > > > > > > > > > > > On Fri, 31 May 2002, Shahram Davari wrote: > > > > > > > Hi, > > > > > > > > What problem a mp2p LDP-based MPLS network is trying to > > > solve (like the one used in RFC2547) that can't be done with > > > pure IP forwarding? > > > > > > > > Note: Don't tell me fast forwarding, because we can do fast > > > IP lookup as well. > > > > > > > > Yours, > > > > Shahram > > > > > > > > > > > > > > From owner-mpls@UU.NET Fri May 31 14:57:10 2002 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 OAA27331 for ; Fri, 31 May 2002 14:57:09 -0400 (EDT) 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 QQmrgl26873 for ; Fri, 31 May 2002 18:57: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 QQmrgl23293; Fri, 31 May 2002 18:56:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgl25652 for mpls-outgoing; Fri, 31 May 2002 18:55:47 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 QQmrgl25643 for ; Fri, 31 May 2002 18:55:45 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 QQmrgl16852 for ; Fri, 31 May 2002 18:54:09 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 QQmrgl19802 for ; Fri, 31 May 2002 18:54:09 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgl19791 for ; Fri, 31 May 2002 18:54:08 GMT 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 OAA14658 for ; Fri, 31 May 2002 14:54:08 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA18896 for mpls@uu.net; Fri, 31 May 2002 14:54:08 -0400 (EDT) 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 QQmrgl25425 for ; Fri, 31 May 2002 18:53:03 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 QQmrgl05453 for ; Fri, 31 May 2002 18:52:55 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mayo.cisco.com [64.102.17.207]) id QQmrgl04093 for ; Fri, 31 May 2002 18:52:55 GMT Received: from VBOLLAPR-W2K2.amer.cisco.com (rtp-vpn1-382.cisco.com [10.82.225.126]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA16275; Fri, 31 May 2002 14:52:52 -0400 (EDT) Date: Fri, 31 May 2002 14:52:52 -0400 (Eastern Daylight Time) From: Vijay Bollapragada To: Shahram Davari cc: "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Basic LDP Question In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03653@nt-exch-yow.pmc-sierra.bc.ca> Message-ID: X-X-Sender: vbollapr@mayo.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 31 May 2002, Shahram Davari wrote: > Vijay, > > I know all this. The question was: > > "Why use LDP instead of IP?". The argument of not using IP is "spoofing" as yakov pointed out also, section 7 of http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-gre-ip-2547-01.txt Vijay > If you have an answer please provide. > > -Shahram > > > -----Original Message----- > > From: Vijay Bollapragada [mailto:vbollapr@cisco.com] > > Sent: Friday, May 31, 2002 2:34 PM > > To: Shahram Davari > > Cc: 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > > Subject: RE: Basic LDP Question > > > > > > On Fri, 31 May 2002, Shahram Davari wrote: > > > > > Vijay, > > > > > But LDP does not give you the TE ability. So why use LDP? > > > > Agreed, that LDP does not give the ability to do TE, I only > > said use MPLS > > in the core, not necassarily LDP :-) but in any case, Here is > > what 2547 > > draft says about using LDP for the top label.. > > > > Section 4.3.2 > > > > "All that matters for the VPN architecture is that some label switched > > path between the router and its BGP next hop exists. > > However, to ensure > > interoperability among systems which implement this VPN architecture, > > all such systems must support LDP [MPLS-LDP]." > > > > Of course, once could use many other mechanisms to get the vpn_labeled > > packet from one edge PE to another edge PE, Interoperability > > is the key > > here. > > > > Thanks, > > Vijay > > > > > > > > > > > > > -----Original Message----- > > > > From: Vijay Bollapragada [mailto:vbollapr@cisco.com] > > > > Sent: Friday, May 31, 2002 2:06 PM > > > > To: Shahram Davari > > > > Cc: 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > > > > Subject: Re: Basic LDP Question > > > > > > > > > > > > In the 2547 case, typically u have 2 labels, the vpn_label > > > > (bottom label) > > > > and the top label is the label to get the packet to the far > > > > end PE, Now, > > > > LDP is used for this top label. > > > > > > > > I think u are questioning why use LDP for this bottom_label > > > > and why not > > > > simply encapsulate the MPLS packet in IP to get the packet to > > > > the next_hop > > > > PE. If this is your Q, You are absolutely correct and > > this is what the > > > > following draft talks about > > > > > > > > http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-gre-ip > > > > -2547-01.txt > > > > > > > > IMHO, this is certainly do-able but MPLS in the core give us > > > > the ability > > > > to do things like Traffic Enginnering > > > > > > > > > -Shahram > > > > > > which are quite a challenge over > > > > pure IP. > > > > > > > > Thanks, > > > > Vijay > > > > > > > > > > > > > > > > On Fri, 31 May 2002, Shahram Davari wrote: > > > > > > > > > Hi, > > > > > > > > > > What problem a mp2p LDP-based MPLS network is trying to > > > > solve (like the one used in RFC2547) that can't be done with > > > > pure IP forwarding? > > > > > > > > > > Note: Don't tell me fast forwarding, because we can do fast > > > > IP lookup as well. > > > > > > > > > > Yours, > > > > > Shahram > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Fri May 31 15:02:03 2002 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 PAA27529 for ; Fri, 31 May 2002 15:02:03 -0400 (EDT) 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 QQmrgm16578; Fri, 31 May 2002 19:01:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgm29617 for mpls-outgoing; Fri, 31 May 2002 19:01: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 QQmrgm29525 for ; Fri, 31 May 2002 19:01:23 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 QQmrgm15475 for ; Fri, 31 May 2002 19:00: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 QQmrgm04919 for ; Fri, 31 May 2002 19:00:56 GMT Received: from rincewind.office.packetexchange.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmrgm04786 for ; Fri, 31 May 2002 19:00:54 GMT Received: from [80.253.97.111] (helo=[80.253.97.111]) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17DrdP-0004kJ-00; Fri, 31 May 2002 20:00:23 +0100 Subject: RE: Basic LDP Question From: Giles Heron To: Shahram Davari Cc: "'Yakov Rekhter'" , "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03652@nt-exch-yow.pmc-sierra.bc.ca> References: <4B6D09F3B826D411A67300D0B706EFDEB03652@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 31 May 2002 20:00:27 +0000 Message-Id: <1022875232.10736.0.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2002-05-31 at 18:39, Shahram Davari wrote: > > > > in IP also you can do ACL. > > > > yes, but it has its own cost/complexity. > > Sure, but using LDP you are forced to run some kind of OAM, to detect > mis-config of LSRs. So nothing is gained. The cost/complexity of filtering is > replaced with cost/complexity of OAM. please let's not turn this into yet another MPLS OAM debate. Giles > > -Shahram > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Fri May 31 15:06:09 2002 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 PAA27691 for ; Fri, 31 May 2002 15:06:09 -0400 (EDT) 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 QQmrgm23446; Fri, 31 May 2002 19:05:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgm07928 for mpls-outgoing; Fri, 31 May 2002 19:05: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 QQmrgm07920 for ; Fri, 31 May 2002 19:05:18 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 QQmrgm28555 for ; Fri, 31 May 2002 19:05: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 QQmrgm14181 for ; Fri, 31 May 2002 19:05:05 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgm14167 for ; Fri, 31 May 2002 19:05:04 GMT 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 PAA15386 for ; Fri, 31 May 2002 15:05:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA20926 for mpls@uu.net; Fri, 31 May 2002 15:05:03 -0400 (EDT) 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 QQmrgm07764 for ; Fri, 31 May 2002 19:03:52 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 QQmrgm22266 for ; Fri, 31 May 2002 19:00: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 QQmrgm04887 for ; Fri, 31 May 2002 19:00:56 GMT Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmrgm04442 for ; Fri, 31 May 2002 19:00:49 GMT Received: (qmail 12048 invoked by uid 104); 31 May 2002 19:00:04 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4205. . Clean. Processed in 1.232971 secs); 31 May 2002 19:00:04 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 31 May 2002 19:00:01 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g4VIxwp06531; Fri, 31 May 2002 11:59:58 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 12:00:01 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03654@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Vijay Bollapragada'" Cc: "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Basic LDP Question Date: Fri, 31 May 2002 11:59:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk I thought you have found another "good" reason. For spoofing see my email response to Yakov. -Shahram > -----Original Message----- > From: Vijay Bollapragada [mailto:vbollapr@cisco.com] > Sent: Friday, May 31, 2002 2:53 PM > To: Shahram Davari > Cc: 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > Subject: RE: Basic LDP Question > > > On Fri, 31 May 2002, Shahram Davari wrote: > > > Vijay, > > > > I know all this. The question was: > > > > "Why use LDP instead of IP?". > > The argument of not using IP is "spoofing" as yakov pointed out > also, section 7 of > > http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-gre-ip > -2547-01.txt > > Vijay > > > > If you have an answer please provide. > > > > -Shahram > > > > > -----Original Message----- > > > From: Vijay Bollapragada [mailto:vbollapr@cisco.com] > > > Sent: Friday, May 31, 2002 2:34 PM > > > To: Shahram Davari > > > Cc: 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > > > Subject: RE: Basic LDP Question > > > > > > > > > On Fri, 31 May 2002, Shahram Davari wrote: > > > > > > > Vijay, > > > > > > > But LDP does not give you the TE ability. So why use LDP? > > > > > > Agreed, that LDP does not give the ability to do TE, I only > > > said use MPLS > > > in the core, not necassarily LDP :-) but in any case, Here is > > > what 2547 > > > draft says about using LDP for the top label.. > > > > > > Section 4.3.2 > > > > > > "All that matters for the VPN architecture is that some > label switched > > > path between the router and its BGP next hop exists. > > > However, to ensure > > > interoperability among systems which implement this VPN > architecture, > > > all such systems must support LDP [MPLS-LDP]." > > > > > > Of course, once could use many other mechanisms to get > the vpn_labeled > > > packet from one edge PE to another edge PE, Interoperability > > > is the key > > > here. > > > > > > Thanks, > > > Vijay > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Vijay Bollapragada [mailto:vbollapr@cisco.com] > > > > > Sent: Friday, May 31, 2002 2:06 PM > > > > > To: Shahram Davari > > > > > Cc: 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > > > > > Subject: Re: Basic LDP Question > > > > > > > > > > > > > > > In the 2547 case, typically u have 2 labels, the vpn_label > > > > > (bottom label) > > > > > and the top label is the label to get the packet to the far > > > > > end PE, Now, > > > > > LDP is used for this top label. > > > > > > > > > > I think u are questioning why use LDP for this bottom_label > > > > > and why not > > > > > simply encapsulate the MPLS packet in IP to get the packet to > > > > > the next_hop > > > > > PE. If this is your Q, You are absolutely correct and > > > this is what the > > > > > following draft talks about > > > > > > > > > > http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-gre-ip > > > > > -2547-01.txt > > > > > > > > > > IMHO, this is certainly do-able but MPLS in the core give us > > > > > the ability > > > > > to do things like Traffic Enginnering > > > > > > > > > > > > -Shahram > > > > > > > > which are quite a challenge over > > > > > pure IP. > > > > > > > > > > Thanks, > > > > > Vijay > > > > > > > > > > > > > > > > > > > > On Fri, 31 May 2002, Shahram Davari wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > What problem a mp2p LDP-based MPLS network is trying to > > > > > solve (like the one used in RFC2547) that can't be done with > > > > > pure IP forwarding? > > > > > > > > > > > > Note: Don't tell me fast forwarding, because we can do fast > > > > > IP lookup as well. > > > > > > > > > > > > Yours, > > > > > > Shahram > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Fri May 31 15:13:19 2002 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 PAA27938 for ; Fri, 31 May 2002 15:13:19 -0400 (EDT) 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 QQmrgm01996 for ; Fri, 31 May 2002 19:13: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 QQmrgm27842; Fri, 31 May 2002 19:11:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgm18489 for mpls-outgoing; Fri, 31 May 2002 19:11: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 QQmrgm18474 for ; Fri, 31 May 2002 19:11: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 QQmrgm03743 for ; Fri, 31 May 2002 19:09: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 QQmrgm22875 for ; Fri, 31 May 2002 19:09:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgm22857 for ; Fri, 31 May 2002 19:09:05 GMT 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 PAA15666 for ; Fri, 31 May 2002 15:09:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA22227 for mpls@uu.net; Fri, 31 May 2002 15:09:05 -0400 (EDT) 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 QQmrgm17010 for ; Fri, 31 May 2002 19:08:09 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 QQmrgm00743 for ; Fri, 31 May 2002 19:06: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 QQmrgm17769 for ; Fri, 31 May 2002 19:06:37 GMT Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmrgm17751 for ; Fri, 31 May 2002 19:06:36 GMT Received: (qmail 15203 invoked by uid 104); 31 May 2002 19:06:36 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4205. . Clean. Processed in 0.504172 secs); 31 May 2002 19:06:36 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 31 May 2002 19:06:35 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g4VJ6Vp16179; Fri, 31 May 2002 12:06:31 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 12:06:34 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03655@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Giles Heron'" Cc: "'Yakov Rekhter'" , "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Basic LDP Question Date: Fri, 31 May 2002 12:06:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk This is not about OAM debate. It is about security. If you are allergic to this name let's call it "maintenance" or "X" or anything you like. What will you do in your VPN network to make sure that a customer's traffic is not forwarded to wrong destination? You need "X" don't you? -Shahram > -----Original Message----- > From: Giles Heron [mailto:giles@packetexchange.net] > Sent: Friday, May 31, 2002 4:00 PM > To: Shahram Davari > Cc: 'Yakov Rekhter'; 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > Subject: RE: Basic LDP Question > > > On Fri, 2002-05-31 at 18:39, Shahram Davari wrote: > > > > > > in IP also you can do ACL. > > > > > > yes, but it has its own cost/complexity. > > > > Sure, but using LDP you are forced to run some kind of OAM, > to detect > > mis-config of LSRs. So nothing is gained. The > cost/complexity of filtering is > > replaced with cost/complexity of OAM. > > please let's not turn this into yet another MPLS OAM debate. > > Giles > > > > > -Shahram > > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > From owner-mpls@UU.NET Fri May 31 15:22:26 2002 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 PAA28161 for ; Fri, 31 May 2002 15:22:26 -0400 (EDT) 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 QQmrgn23284 for ; Fri, 31 May 2002 19:22: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 QQmrgn21351; Fri, 31 May 2002 19:22:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgn19997 for mpls-outgoing; Fri, 31 May 2002 19:21: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 QQmrgn19966 for ; Fri, 31 May 2002 19:21:13 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 QQmrgn15317 for ; Fri, 31 May 2002 19:20: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 QQmrgn16735 for ; Fri, 31 May 2002 19:20:22 GMT Received: from rincewind.office.packetexchange.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmrgm00063 for ; Fri, 31 May 2002 19:12:44 GMT Received: from [80.253.97.111] (helo=[80.253.97.111]) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17DrpG-0004oJ-00; Fri, 31 May 2002 20:12:38 +0100 Subject: RE: Basic LDP Question From: Giles Heron To: Shahram Davari Cc: "'Yakov Rekhter'" , "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03655@nt-exch-yow.pmc-sierra.bc.ca> References: <4B6D09F3B826D411A67300D0B706EFDEB03655@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 31 May 2002 20:12:48 +0000 Message-Id: <1022875968.10734.8.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit no - I don't need "X". and yes - this is the OAM debate!!! On Fri, 2002-05-31 at 19:06, Shahram Davari wrote: > This is not about OAM debate. It is about security. If you are allergic to this name let's call it "maintenance" or "X" or anything you like. What will you do in your VPN network to make sure that a customer's traffic is not forwarded to wrong destination? You need "X" don't you? > > -Shahram > > > -----Original Message----- > > From: Giles Heron [mailto:giles@packetexchange.net] > > Sent: Friday, May 31, 2002 4:00 PM > > To: Shahram Davari > > Cc: 'Yakov Rekhter'; 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > > Subject: RE: Basic LDP Question > > > > > > On Fri, 2002-05-31 at 18:39, Shahram Davari wrote: > > > > > > > > in IP also you can do ACL. > > > > > > > > yes, but it has its own cost/complexity. > > > > > > Sure, but using LDP you are forced to run some kind of OAM, > > to detect > > > mis-config of LSRs. So nothing is gained. The > > cost/complexity of filtering is > > > replaced with cost/complexity of OAM. > > > > please let's not turn this into yet another MPLS OAM debate. > > > > Giles > > > > > > > > -Shahram > > > > > -- > > ================================================================= > > Giles Heron Principal Network Architect PacketExchange Ltd. > > ph: +44 7880 506185 "if you build it they will yawn" > > ================================================================= > > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Fri May 31 15:25:16 2002 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 PAA28205 for ; Fri, 31 May 2002 15:25:16 -0400 (EDT) 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 QQmrgn23276; Fri, 31 May 2002 19:25:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgn20203 for mpls-outgoing; Fri, 31 May 2002 19:24:48 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 QQmrgn20193 for ; Fri, 31 May 2002 19:24: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 QQmrgn20069 for ; Fri, 31 May 2002 19:22: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 QQmrgn20983 for ; Fri, 31 May 2002 19:22:04 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgn20929 for ; Fri, 31 May 2002 19:22:03 GMT 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 PAA16553 for ; Fri, 31 May 2002 15:22:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA25703 for mpls@uu.net; Fri, 31 May 2002 15:22:02 -0400 (EDT) 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 QQmrgn19946 for ; Fri, 31 May 2002 19:20:54 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 QQmrgn21703 for ; Fri, 31 May 2002 19:20: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 QQmrgn17570 for ; Fri, 31 May 2002 19:20:41 GMT Received: from sj-msg-core-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10]) id QQmrgn17548 for ; Fri, 31 May 2002 19:20:40 GMT Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4VJKZIZ000507; Fri, 31 May 2002 12:20:35 -0700 (PDT) Received: from cisco.com (ams-rraszuk-vpn5.cisco.com [10.61.160.6]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AFA71770; Fri, 31 May 2002 12:21:16 -0700 (PDT) Message-ID: <3CF7CCFE.5B2B506@cisco.com> Date: Fri, 31 May 2002 21:20:30 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: "'Giles Heron'" , "'Yakov Rekhter'" , "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: Re: Basic LDP Question References: <4B6D09F3B826D411A67300D0B706EFDEB03655@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > > This is not about OAM debate. It is about security. If you are allergic to this name let's call it "maintenance" or "X" or anything you like. What will you do in your VPN network to make sure that a customer's traffic is not forwarded to wrong destination? You need "X" don't you? You need this both for LDP LSP as well for any IP tunneling as well to make sure your PE-PE tunnel whatever it can be is up & running and your VPN customers can in fact communicate. Sure we could argue long about that one but I don't think this is really significant issue any more. See lsp-ping draft if you have doubts :). As to the original question from the real deployment point of view there are three main reasons: A) performance and availability of MPLS encapsulation versus IP encapsulation. AFAIK most widely shipping boxes require an extra hardware to do IP encapsulation at an acceptable rate while MPLS encapsulation is supported at line rate much wider. B) Overhead 20 bytes (or more if key is used) versus 4 is from a practical point of view a big difference. Even with extra 4 bytes the headache of MTU problems still exists. C) Loadbalancing in the core ... See when you encapsulate all of your PE-PE traffic in one IP header, the FIB hash will be identical to all VPN customers residing on those PEs hence all the packets will take the same path. This is very bad indeed. In MPLS we can build the hash based on labels or even look higher at the original VPN IP packet so the distribution of VPN flows in the core is much more larger. D) Security or I should rather say protection of data integrity. Rgs, R. From owner-mpls@UU.NET Fri May 31 15:25:56 2002 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 PAA28279 for ; Fri, 31 May 2002 15:25:56 -0400 (EDT) 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 QQmrgn26169; Fri, 31 May 2002 19:25:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgn20285 for mpls-outgoing; Fri, 31 May 2002 19:25: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 QQmrgn20233 for ; Fri, 31 May 2002 19:25:12 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 QQmrgn03975 for ; Fri, 31 May 2002 19:23: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 QQmrgn24647 for ; Fri, 31 May 2002 19:23:17 GMT Received: from auds953.usa.alcatel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auds953.usa.alcatel.com [143.209.238.6]) id QQmrgn24272 for ; Fri, 31 May 2002 19:23:10 GMT Received: from morgoth.pet.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g4VJMSp26110; Fri, 31 May 2002 14:22:28 -0500 (CDT) Received: from alcatel.com (localhost [127.0.0.1]) by morgoth.pet.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g4VJMaW15865; Fri, 31 May 2002 12:22:36 -0700 (PDT) Message-ID: <3CF7CD60.73F9C747@alcatel.com> Date: Fri, 31 May 2002 12:22:08 -0700 From: Mudhafar Hassan-Ali Organization: Alcatel, USA X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hong Liao CC: Vasanthi Thirumalai , mpls@UU.NET, hchang Subject: Re: how to request the desired bandwidth? RFC3209 section 4.7.3 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit This is a classical dual leaky bucket question when it comes to how much bandwidth should be allocated to a connection or an LSP. Basically r (bucket rate) reflects the average bandwidth, whereas the p reflects the maximum bit rate the packet can be emitted, given enough credit in the bucket. Hence, for call admission control (CAC) purposes, the allocate bandwidth is usually between these two values; i.e. r Hi, > > I also think it is 'peak date rate'. But if I sent out the peak date rate > very high 'FFFFFFFF', the router should not be able to handle it, and send > back the path error message, right? > > Thanks, > > Hong (Julia) Liao > ATM/Broadband Network Integration > Telcordia Technologies, Inc > > Tel: (973) 829-4570 > Fax: (973) 829-5962 > > > Vasanthi > Thirumalai To: "'Hong Liao'" , mpls@UU.NET > lium.com> Subject: RE: how to request the desired bandwidth? RFC3209 section > 4.7.3 > 05/30/02 > 05:40 PM > > > > The 'peak data rate' is used to specify the desired bandwidth. > > -Vasanthi > -----Original Message----- > From: Hong Liao [mailto:hliao@telcordia.com] > Sent: Thursday, May 30, 2002 12:00 PM > To: mpls@UU.NET > Subject: how to request the desired bandwidth? RFC3209 section 4.7.3 > > Hi, > > RFC3209 Section 4.7.3, it says "When a new path message is considered for > admission, the bandwidth requested is compared with the bandwidth available > at the priority specified in the set up priority" > > Here I want to know how to request the desired bandwidth from the path msg. > As I know, in the path message, there is one Sender Tspec object, and > inside this object, it has traffic parameters like 'token bucket rate', > 'token bucket size', 'peak data rate'....... I want to know which > parameter can be used to specify the desired bandwidth the node wants. Or > desired BW will not be defined from this object at all? > > Can someone tell me how to request the BW in the Path msg, and if it is not > available, a PathErr msg will be sent back? > > Thanks in an advance. > Julia From owner-mpls@UU.NET Fri May 31 15:39:49 2002 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 PAA00337 for ; Fri, 31 May 2002 15:39:48 -0400 (EDT) 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 QQmrgo21175; Fri, 31 May 2002 19:39:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgo21677 for mpls-outgoing; Fri, 31 May 2002 19:39: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 QQmrgo21669 for ; Fri, 31 May 2002 19:38:52 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 QQmrgo05047 for ; Fri, 31 May 2002 19:37:03 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 QQmrgo23916 for ; Fri, 31 May 2002 19:37:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgo23897 for ; Fri, 31 May 2002 19:37:02 GMT 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 PAA17725 for ; Fri, 31 May 2002 15:37:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA29128 for mpls@uu.net; Fri, 31 May 2002 15:37:02 -0400 (EDT) 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 QQmrgo21360 for ; Fri, 31 May 2002 19:35:51 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 QQmrgo09707 for ; Fri, 31 May 2002 19:35:13 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQmrgo08423 for ; Fri, 31 May 2002 19:35:08 GMT Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4VJYPHs009737; Fri, 31 May 2002 12:34:25 -0700 (PDT) Received: from cisco.com (ams-rraszuk-vpn5.cisco.com [10.61.160.6]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AFA72286; Fri, 31 May 2002 12:35:06 -0700 (PDT) Message-ID: <3CF7D03C.E85EAD36@cisco.com> Date: Fri, 31 May 2002 21:34:20 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: Shahram Davari , "'Giles Heron'" , "'Yakov Rekhter'" , "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: Re: Basic LDP Question References: <4B6D09F3B826D411A67300D0B706EFDEB03655@nt-exch-yow.pmc-sierra.bc.ca> <3CF7CCFE.5B2B506@cisco.com> <15607.53115.949443.940734@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hu Juha, Currently deployed hardware & software. Besides the whole beauty to use pure IP encapsulation is that P boxes just do IP forwarding and don't have to do anything special. Clearly taking into account l2tp session does not meet those conditions. R. > jh@lohi.eng.song.fi wrote: > > Robert Raszuk writes: > > > C) Loadbalancing in the core ... See when you encapsulate all of your > > PE-PE traffic in one IP header, the FIB hash will be identical to all > > VPN customers residing on those PEs hence all the packets will take the > > same path. This is very bad indeed. In MPLS we can build the hash based > > on labels or even look higher at the original VPN IP packet so the > > distribution of VPN flows in the core is much more larger. > > what would prevent you from taking into account l2tp session id when > calculating the hash? > > -- juha From owner-mpls@UU.NET Fri May 31 15:45:08 2002 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 PAA01098 for ; Fri, 31 May 2002 15:45:06 -0400 (EDT) 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 QQmrgo27372; Fri, 31 May 2002 19:44:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgo22181 for mpls-outgoing; Fri, 31 May 2002 19:44:30 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 QQmrgo22159 for ; Fri, 31 May 2002 19:44:20 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 QQmrgo05452 for ; Fri, 31 May 2002 19:44: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 QQmrgo05280 for ; Fri, 31 May 2002 19:44:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgo05267 for ; Fri, 31 May 2002 19:44:02 GMT 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 PAA18181 for ; Fri, 31 May 2002 15:44:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA00497 for mpls@uu.net; Fri, 31 May 2002 15:44:01 -0400 (EDT) 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 QQmrgo22095 for ; Fri, 31 May 2002 19:43:16 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 QQmrgo22031 for ; Fri, 31 May 2002 19:42: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 QQmrgo02709 for ; Fri, 31 May 2002 19:42:27 GMT Received: from sj-msg-core-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10]) id QQmrgo02700 for ; Fri, 31 May 2002 19:42:27 GMT Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4VJfpIZ009333; Fri, 31 May 2002 12:41:51 -0700 (PDT) Received: from cisco.com (ams-rraszuk-vpn5.cisco.com [10.61.160.6]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AFA72556; Fri, 31 May 2002 12:42:32 -0700 (PDT) Message-ID: <3CF7D1FA.9B26B6E9@cisco.com> Date: Fri, 31 May 2002 21:41:46 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: Shahram Davari , "'Giles Heron'" , "'Yakov Rekhter'" , "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: Re: Basic LDP Question References: <4B6D09F3B826D411A67300D0B706EFDEB03655@nt-exch-yow.pmc-sierra.bc.ca> <3CF7CCFE.5B2B506@cisco.com> <15607.53115.949443.940734@harjus.eng.song.fi> <3CF7D03C.E85EAD36@cisco.com> <15607.53639.336830.395925@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Very true statement indeed :) :) ... Thx Juha, Robert > jh@lohi.eng.song.fi wrote: > > Robert Raszuk writes: > > > Currently deployed hardware & software. > > your current router hardware can't do many other things either, like > learning mac addresses. so when you re-spin it, you could also consider > adding real support for ip tunneling for those who don't like the > complexity of mpls control plane. > > -- juha From owner-mpls@UU.NET Fri May 31 15:54:47 2002 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 PAA02247 for ; Fri, 31 May 2002 15:54:45 -0400 (EDT) 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 QQmrgp16935; Fri, 31 May 2002 19:54:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgp23223 for mpls-outgoing; Fri, 31 May 2002 19:54: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 QQmrgp23217 for ; Fri, 31 May 2002 19:53:54 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 QQmrgp25796 for ; Fri, 31 May 2002 19:53:21 GMT Received: from mail.san.yahoo.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.san.yahoo.com [209.132.1.30]) id QQmrgp21548 for ; Fri, 31 May 2002 19:53:21 GMT Received: from [65.213.193.52] by mail.san.yahoo.com with HTTP; Fri, 31 May 2002 12:54:14 -0700 Date: Fri, 31 May 2002 15:54:14 -0400 Message-ID: <3CF535C60000276C@mta08.san.yahoo.com> In-Reply-To: <200205311759.g4VHxAn15654@mlsrv1.avici.com> From: "Kavita Khanna" Subject: Re: how to request the desired bandwidth? RFC3209 section 4.7.3 To: hliao@telcordia.com Cc: mjork@avici.com, mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA02247 The Token Bucket Size, Token Bucket Rate, and Minimum Policed Unit parameters in the RSVP SENDER_TSPEC object are intended to be used to specify the bandwidth requirements for the traffic flow. How these fields are interpreted to actually reserve the bandwidth is a different issue. Regards, Kavita >-- Original Message -- >From: Markus Jork >To: mpls@UU.NET >Subject: Re: Fw: Re: RE: how to request the desired bandwidth? RFC3209 section > > 4.7.3 >Date: Fri, 31 May 2002 13:58:14 -0400 > > >It is in fact the token bucket rate, not the peak rate. > >Markus > >> >> in my opinion,it must be the "token buchet rate" to be used to specify >the desired bandwidth.is it right? >> >> >The 'peak data rate' is used to specify the desired bandwidth. >> > >> >-Vasanthi >> >-----Original Message----- >> >From: Hong Liao [mailto:hliao@telcordia.com] >> >Sent: Thursday, May 30, 2002 12:00 PM >> >To: mpls@UU.NET >> >Subject: how to request the desired bandwidth? RFC3209 section 4.7.3 >> > >> > >> >Hi, >> > >> >RFC3209 Section 4.7.3, it says "When a new path message is considered >for >> >admission, the bandwidth requested is compared with the bandwidth available >> >at the priority specified in the set up priority" >> > >> >Here I want to know how to request the desired bandwidth from the path >msg. >> >As I know, in the path message, there is one Sender Tspec object, and >> >inside this object, it has traffic parameters like 'token bucket rate', >> >'token bucket size', 'peak data rate'....... I want to know which >> >parameter can be used to specify the desired bandwidth the node wants. > Or >> >desired BW will not be defined from this object at all? >> > >> >Can someone tell me how to request the BW in the Path msg, and if it is >not >> >available, a PathErr msg will be sent back? >> > >> >Thanks in an advance. >> >Julia >> >> >> >> >> From owner-mpls@UU.NET Fri May 31 16:20:09 2002 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 QAA03705 for ; Fri, 31 May 2002 16:20:09 -0400 (EDT) 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 QQmrgr08175; Fri, 31 May 2002 20:19:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgr17419 for mpls-outgoing; Fri, 31 May 2002 20:19:29 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 QQmrgr17414 for ; Fri, 31 May 2002 20:19:25 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 QQmrgr12176 for ; Fri, 31 May 2002 20:18: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 QQmrgr05699 for ; Fri, 31 May 2002 20:18:38 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgr05687 for ; Fri, 31 May 2002 20:18:38 GMT 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 QAA21124 for ; Fri, 31 May 2002 16:18:37 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA05067 for mpls@uu.net; Fri, 31 May 2002 16:18:37 -0400 (EDT) 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 QQmrgo20901 for ; Fri, 31 May 2002 19:31:47 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 QQmrgo27015 for ; Fri, 31 May 2002 19:31:13 GMT From: jh@lohi.eng.song.fi Received: from lohi.eng.song.fi by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.song.fi [195.10.149.18]) id QQmrgo06013 for ; Fri, 31 May 2002 19:31:12 GMT Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17Ds7A-0007XM-00; Fri, 31 May 2002 22:31:08 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15607.53115.949443.940734@harjus.eng.song.fi> Date: Fri, 31 May 2002 22:31:07 +0300 To: raszuk@cisco.com Cc: Shahram Davari , "'Giles Heron'" , "'Yakov Rekhter'" , "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: Re: Basic LDP Question In-Reply-To: <3CF7CCFE.5B2B506@cisco.com> References: <4B6D09F3B826D411A67300D0B706EFDEB03655@nt-exch-yow.pmc-sierra.bc.ca> <3CF7CCFE.5B2B506@cisco.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Robert Raszuk writes: > C) Loadbalancing in the core ... See when you encapsulate all of your > PE-PE traffic in one IP header, the FIB hash will be identical to all > VPN customers residing on those PEs hence all the packets will take the > same path. This is very bad indeed. In MPLS we can build the hash based > on labels or even look higher at the original VPN IP packet so the > distribution of VPN flows in the core is much more larger. what would prevent you from taking into account l2tp session id when calculating the hash? -- juha From owner-mpls@UU.NET Fri May 31 16:22:10 2002 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 QAA03744 for ; Fri, 31 May 2002 16:22:10 -0400 (EDT) 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 QQmrgr15138; Fri, 31 May 2002 20:21:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgr17580 for mpls-outgoing; Fri, 31 May 2002 20:20: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 QQmrgr17541 for ; Fri, 31 May 2002 20:20:26 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 QQmrgr15940 for ; Fri, 31 May 2002 20:19: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 QQmrgr06200 for ; Fri, 31 May 2002 20:18:59 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgr06181 for ; Fri, 31 May 2002 20:18:58 GMT 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 QAA21163 for ; Fri, 31 May 2002 16:18:58 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA05071 for mpls@uu.net; Fri, 31 May 2002 16:18:58 -0400 (EDT) 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 QQmrgo21755 for ; Fri, 31 May 2002 19:40:54 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 QQmrgo22724 for ; Fri, 31 May 2002 19:39:53 GMT From: jh@lohi.eng.song.fi Received: from lohi.eng.song.fi by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.song.fi [195.10.149.18]) id QQmrgo22377 for ; Fri, 31 May 2002 19:39:52 GMT Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17DsFb-0007Xv-00; Fri, 31 May 2002 22:39:51 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15607.53639.336830.395925@harjus.eng.song.fi> Date: Fri, 31 May 2002 22:39:51 +0300 To: raszuk@cisco.com Cc: Shahram Davari , "'Giles Heron'" , "'Yakov Rekhter'" , "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: Re: Basic LDP Question In-Reply-To: <3CF7D03C.E85EAD36@cisco.com> References: <4B6D09F3B826D411A67300D0B706EFDEB03655@nt-exch-yow.pmc-sierra.bc.ca> <3CF7CCFE.5B2B506@cisco.com> <15607.53115.949443.940734@harjus.eng.song.fi> <3CF7D03C.E85EAD36@cisco.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Robert Raszuk writes: > Currently deployed hardware & software. your current router hardware can't do many other things either, like learning mac addresses. so when you re-spin it, you could also consider adding real support for ip tunneling for those who don't like the complexity of mpls control plane. -- juha From owner-mpls@UU.NET Fri May 31 16:22:33 2002 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 QAA03763 for ; Fri, 31 May 2002 16:22:19 -0400 (EDT) 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 QQmrgr11619; Fri, 31 May 2002 20:22:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgr17588 for mpls-outgoing; Fri, 31 May 2002 20:20:31 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 QQmrgr17542 for ; Fri, 31 May 2002 20:20:26 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 QQmrgr13909 for ; Fri, 31 May 2002 20:18: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 QQmrgr05196 for ; Fri, 31 May 2002 20:18:21 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrgr05190 for ; Fri, 31 May 2002 20:18:21 GMT 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 QAA21092 for ; Fri, 31 May 2002 16:18:20 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA05061 for mpls@uu.net; Fri, 31 May 2002 16:18:20 -0400 (EDT) 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 QQmrgm18461 for ; Fri, 31 May 2002 19:10:57 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 QQmrgm04172 for ; Fri, 31 May 2002 19:09:25 GMT From: jh@lohi.eng.song.fi Received: from lohi.eng.song.fi by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.song.fi [195.10.149.18]) id QQmrgm03002 for ; Fri, 31 May 2002 19:09:24 GMT Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17Drm1-0007Wy-00; Fri, 31 May 2002 22:09:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15607.51805.590210.478203@harjus.eng.song.fi> Date: Fri, 31 May 2002 22:09:17 +0300 To: Vijay Bollapragada Cc: Shahram Davari , "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Basic LDP Question In-Reply-To: References: <4B6D09F3B826D411A67300D0B706EFDEB03653@nt-exch-yow.pmc-sierra.bc.ca> X-Mailer: VM 7.01 under Emacs 21.1.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit packet spoofing is quite easy to prevent by a single access list at ingress to other providers that drops a packet if its source address belongs to the network that is used for the loopback interfaces that terminate the ip tunnels at the pes. what comes to subscriber links, we, and any reasonable service provider, of course always check that the source addresses belong to the subscribers. -- juha From owner-mpls@UU.NET Fri May 31 19:16:30 2002 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 TAA06647 for ; Fri, 31 May 2002 19:16:30 -0400 (EDT) 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 QQmrhd10992; Fri, 31 May 2002 23:16:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrhd07301 for mpls-outgoing; Fri, 31 May 2002 23:15:03 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 QQmrhd07257 for ; Fri, 31 May 2002 23:15:02 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 QQmrhc18720 for ; Fri, 31 May 2002 23:14:55 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 QQmrhc19444 for ; Fri, 31 May 2002 23:14:55 GMT Received: from cbibipnt03.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmrhc19430 for ; Fri, 31 May 2002 23:14:54 GMT Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Sat, 1 Jun 2002 00:14:57 +0100 Message-ID: To: Shahram_Davari@pmc-sierra.com, yakov@juniper.net Cc: giles@packetexchange.net, mpls@UU.NET, ppvpn@ppvpn.francetelecom.com Subject: RE: Basic LDP Question Date: Sat, 1 Jun 2002 00:14:45 +0100 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 Shahram Davari wrote 31 May 2002 19:40 > To: 'Yakov Rekhter' > Cc: Giles Heron; 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com' > Subject: RE: Basic LDP Question > > > > > > in IP also you can do ACL. > > > > yes, but it has its own cost/complexity. > > Sure, but using LDP you are forced to run some kind of OAM, to detect > mis-config of LSRs. So nothing is gained. The cost/complexity > of filtering is > replaced with cost/complexity of OAM. > > -Shahram NH=> I am not sure you are capturing all the issues here Shahram. Some P LSRs do load-balancing based on IP address hashing as a sort of TE function because LDP just gives SPF and so leads to networks that are traffic/topology sensitive. This gives rise to the additional points: - might this not also be considered a security issue itself from a customer perspective, ie VPN customer IP pkts are looked at for sorting into different streams? - what about the added processing load this creates on the P routers involved? - does it not break the simple 'label forwarding' paradigm that seems to be the raison detre for MPLS? - and don't we effectively get back to IP fowarding now.....albeit with an inability to do IP forwarding because the P routers don't have the IP routes (of the VPNs) To which you can now add your OAM issue because yes we have to fault-manage these entities since they do fail...and this now includes the load-balancing functions. Further: - given we can't give any solid SLAs to such VPNs when based on LDP (because of the VPN population pkt merging issue); - so to compensate we have to over-engineer and hope; - VPN topologies are invariably long-holding....so their LSPs really need decoupling from the IGP in case it flexes routes or misbehaves; In view of all these factors perhaps it might have been wiser to make ER/signalled LSPs the interworking default for VPNs rather than LDP in rfc2547. regards, Neil From owner-mpls@UU.NET Fri May 31 19:17:07 2002 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 TAA06661 for ; Fri, 31 May 2002 19:17:07 -0400 (EDT) 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 QQmrhd25380; Fri, 31 May 2002 23:16:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrhd07527 for mpls-outgoing; Fri, 31 May 2002 23:16:03 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 QQmrhd07464 for ; Fri, 31 May 2002 23:15:54 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 QQmrhc24354 for ; Fri, 31 May 2002 23:14:49 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 QQmrhc19301 for ; Fri, 31 May 2002 23:14:49 GMT Received: from cbibipnt03.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmrhc19292 for ; Fri, 31 May 2002 23:14:48 GMT Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Sat, 1 Jun 2002 00:14:51 +0100 Message-ID: To: vbollapr@cisco.com, Shahram_Davari@pmc-sierra.com Cc: mpls@UU.NET, ppvpn@ppvpn.francetelecom.com Subject: RE: Basic LDP Question Date: Sat, 1 Jun 2002 00:14:38 +0100 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 Vijay, You wrote Vijay Bollapragada 31 May 2002 19:34 > > On Fri, 31 May 2002, Shahram Davari wrote: > > > Vijay, > > > But LDP does not give you the TE ability. So why use LDP? > > Agreed, that LDP does not give the ability to do TE, I only > said use MPLS > in the core, not necassarily LDP :-) but in any case, Here is > what 2547 > draft says about using LDP for the top label.. > > Section 4.3.2 > > "All that matters for the VPN architecture is that some label switched > path between the router and its BGP next hop exists. > However, to ensure > interoperability among systems which implement this VPN architecture, > all such systems must support LDP [MPLS-LDP]." > > Of course, once could use many other mechanisms to get the vpn_labeled > packet from one edge PE to another edge PE, Interoperability > is the key > here. NH=> So are you saying the only reason for LDP is because there is a need to run VPN services composed of (i) multiple vendors and (ii) multiple SPs across a population of P routers? Can you (or anyone else) identify some of these cases please? regards, Neil From owner-mpls@UU.NET Fri May 31 20:58:40 2002 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 UAA07655 for ; Fri, 31 May 2002 20:58:39 -0400 (EDT) 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 QQmrgd03002; Fri, 31 May 2002 16:45:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrgd27357 for mpls-outgoing; Fri, 31 May 2002 16:45: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 QQmrgd27301 for ; Fri, 31 May 2002 16:45:05 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 QQmrgc11335 for ; Fri, 31 May 2002 16:43:51 GMT Received: from granger.mail.mindspring.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: granger.mail.mindspring.net [207.69.200.148]) id QQmrgc25595 for ; Fri, 31 May 2002 16:43:50 GMT Received: from user-1121did.dsl.mindspring.com ([66.32.182.77] helo=METANOIA) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17DpUh-0004aE-00; Fri, 31 May 2002 12:43:15 -0400 Reply-To: From: "Vishal Sharma" To: "Zhi-Wei Lin" , "Suresh Katukam" Cc: "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp \(E-mail\)" , "mpls@UU. NET \(E-mail\)" Subject: RE: Sonet Ring provisioning Date: Fri, 31 May 2002 09:49:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3CF6755D.5010508@lucent.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Zhi and all, Great discussion! I'm glad we're finally discussing some of these issues, and highlighting that mix inherent ring protection with the control domain mechanisms is non-trivial. Comments in-line. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Zhi-Wei Lin > Sent: Thursday, May 30, 2002 11:54 AM > To: Suresh Katukam > Cc: R. Muralidharan; Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); > mpls@UU. NET (E-mail) > Subject: Re: Sonet Ring provisioning > > > Hi Suresh, > > Yes agree this is very complex if you try to create too much > dependencies between control plane and transport plane protection > interactions. That is why my simplistic approach: > > * Control plane sees the entire ring as offering "highly available" > connections > * Control plane sets up a single connection across this ring > "sub-network" (if you think this about this, the entire ring can > actually be treated by a control plane controller as a single node > where the BLSR ring nodes may be thought of as aggregate ports on > the single node) > * The ring sub-network, by virtue of providing the protection and > knowing *exactly* how protection is provided can set up the > protection channel automatically (but control plane need not know > this as it is irrelevant to the control plane -- it only needs to > know that the single connection is protected) What mechanism will the ring use to setup the internal protection channel? Will it require EMS/NMS intervention, as proposed on this thread earlier, or will there be another sequence of control plane messages (initiated internal to the ring) to set this path up. The latter would be prefereable if the objective is to have fully-automated path setup (otherwise, we have EMS/NMS intervention for the ring), but it does complicate the control plane protocols (since a new sequence of setup steps may have to be initiated internal to each ring on the path of the end-to-end circuit/trail that is being setup. -Vishal > From owner-mpls@UU.NET Fri May 31 23:17:40 2002 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 XAA10145 for ; Fri, 31 May 2002 23:17:39 -0400 (EDT) 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 QQmrht27321; Sat, 1 Jun 2002 03:17:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQmrht23833 for mpls-outgoing; Sat, 1 Jun 2002 03:16:44 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 QQmrht23828 for ; Sat, 1 Jun 2002 03:16: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 QQmrht25283 for ; Sat, 1 Jun 2002 03:16:04 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmrht25425 for ; Sat, 1 Jun 2002 03:16:02 GMT 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 XAA06800 for ; Fri, 31 May 2002 23:16:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id XAA17229 for mpls@uu.net; Fri, 31 May 2002 23:16:02 -0400 (EDT) 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 QQmrht23637 for ; Sat, 1 Jun 2002 03:15:41 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 QQmrht27420 for ; Sat, 1 Jun 2002 03:15:39 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQmrht24809 for ; Sat, 1 Jun 2002 03:15:39 GMT Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id XAA02570; Fri, 31 May 2002 23:15:02 -0400 (EDT) Date: Fri, 31 May 2002 23:15:02 -0400 (EDT) From: Ajay Simha To: jh@lohi.eng.song.fi cc: raszuk@cisco.com, Shahram Davari , "'Giles Heron'" , "'Yakov Rekhter'" , "'mpls@uu.net'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: Re: Basic LDP Question In-Reply-To: <15607.53639.336830.395925@harjus.eng.song.fi> Message-ID: References: <4B6D09F3B826D411A67300D0B706EFDEB03655@nt-exch-yow.pmc-sierra.bc.ca> <3CF7CCFE.5B2B506@cisco.com> <15607.53115.949443.940734@harjus.eng.song.fi> <3CF7D03C.E85EAD36@cisco.com> <15607.53639.336830.395925@harjus.eng.song.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 31 May 2002 jh@lohi.eng.song.fi wrote: The point is MPLS effectively decouples the forwarding portion from the routing. This makes MPLS a service enabler. For instance I did not see anyone mention things like QoS transparency that MPLS can achieve. Sure you can monkey around with IP to make IP have everything that MPLS has. May be even a fixed length tag and call it something else :). Why do it when this extension already exists as an IETF based standards where folks like us can debate issues and come up with solutions that are acceptable to most? -ajay >:Robert Raszuk writes: >: >: > Currently deployed hardware & software. >: >:your current router hardware can't do many other things either, like >:learning mac addresses. so when you re-spin it, you could also consider >:adding real support for ip tunneling for those who don't like the >:complexity of mpls control plane. >: >:-- juha >: --