From owner-gsmp@psyton.com Wed Mar 1 22:37:45 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22850 for ; Wed, 1 Mar 2000 22:37:42 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id VAA29862 for gsmp-list; Wed, 1 Mar 2000 21:42:13 -0500 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id VAA29859 for ; Wed, 1 Mar 2000 21:42:03 -0500 Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.19 2000/01/29 00:15:43 dmccart Exp $) with SMTP id CAA26812; Thu, 2 Mar 2000 02:42:08 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 02 Mar 2000 02:41:27 0000 (GMT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 1 Mar 2000 18:41:25 -0800 Message-ID: <65DA3A1DD476D311AC4400A0C98414FC2D56AD@orsmsx54.jf.intel.com> From: "Khosravi, Hormuzd M" To: "'gsmp@psyton.com'" Cc: "'avri.doria@nokia.com'" Subject: RE: GSMP WG Adelaide Date: Wed, 1 Mar 2000 18:41:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Hi, I was looking at the Agenda on the IETF site and trying to find out on which day and time the GSMP WG meeting is going to be held. I could not find this information there, so if someone on the list could send me this info. it would be great. Thanks, Hormuzd. office : 1-503-264-0334 -----Original Message----- From: avri.doria@nokia.com [mailto:avri.doria@nokia.com] Sent: Wednesday, February 23, 2000 4:17 AM To: gsmp@psyton.com Subject: RE: GSMP WG Adelaide Hi, So far, what I have on the agenda is: 1. Review of work done on GSMP spec - including results of the editing meeting and work done since then. 2. Reports on implementations - I know there are a few, and I am hoping that the folk working on them will come forward with short reports. 3. Discussions of future work for GSMP Regards, a. ----------------------------------- avri doria Office: +1 781 993 4645 Mobile: +1 781 308 7680 > -----Original Message----- > From: EXT Kenneth Sundell [mailto:ksundell@nortelnetworks.com] > Sent: 23 February, 2000 2:42 AM > To: gsmp@psyton.com > Subject: Re: GSMP WG adelaide > > > > folks, > we have been assigned one full slot for the adelaide meeting, > so it's time to > create an agenda. Please forward any agenda items you may > have to me and > Avri. It might also be a good idea to cc your requests to the > list as well. > > Regards, > Ken > > > "Khosravi, Hormuzd M" wrote: > > > Hi, > > > > I was wondering if the GSMP WG has an agenda for Adelaide > and is going to > > hold any meetings. > > Please do let me know. > > > > Thanks, > > Hormuzd. > > -- > Kenneth Sundell > Nortel Networks > Routing Architecture Lab > S:t Eriksgatan 115 A, PO Box 6701 > 113 85 Stockholm, Sweden > phone: +46 8 5088-3538, mobile +46 70 665-7838 > e-mail: ksundell@nortelnetworks.com > > From owner-gsmp@psyton.com Wed Mar 1 23:42:09 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24081 for ; Wed, 1 Mar 2000 23:42:09 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id XAA30200 for gsmp-list; Wed, 1 Mar 2000 23:12:50 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id XAA30197 for ; Wed, 1 Mar 2000 23:12:47 -0500 From: avri.doria@nokia.com Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id GAA28631; Thu, 2 Mar 2000 06:12:46 +0200 (EET) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id GAA28381; Thu, 2 Mar 2000 06:12:45 +0200 (EET) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Wed, 1 Mar 2000 22:12:44 -0600 Message-ID: To: hormuzd.m.khosravi@intel.com, gsmp@psyton.com Subject: RE: GSMP WG Adelaide Date: Wed, 1 Mar 2000 22:11:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Hi, While we have been approved for a slot, I don't know when it will be yet. The Agenda isn't due until 17 March, so we are still waiting to find out about contributions. Several items already on the agenda are: -Review of work done on GSMP spec - including results of the editing meeting and work done since then. draft-ietf-gsmp-04.txt (will be released by the deadline 10 Mar) -Discussion of the draft-ietf-gsmp-encaps-00.txt -Discussion of draft-ietf-gsmp-applicability-00.txt (will be released by the deadline 10 Mar) -Reports on implementations - I know there are a few, and I am hoping that the folk working on them will come forward with short reports. -Discussions of future work for GSMP a. ----------------------------------- avri doria Office: +1 781 993 4645 Mobile: +1 781 308 7680 > -----Original Message----- > From: EXT Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com] > Sent: 01 March, 2000 9:41 PM > To: 'gsmp@psyton.com' > Cc: 'avri.doria@nokia.com' > Subject: RE: GSMP WG Adelaide > > > Hi, > > I was looking at the Agenda on the IETF site and trying to > find out on which > day and time > the GSMP WG meeting is going to be held. I could not find > this information > there, so if someone on the list could send me this info. it > would be great. > > Thanks, > Hormuzd. > > office : 1-503-264-0334 > > > -----Original Message----- > From: avri.doria@nokia.com [mailto:avri.doria@nokia.com] > Sent: Wednesday, February 23, 2000 4:17 AM > To: gsmp@psyton.com > Subject: RE: GSMP WG Adelaide > > > Hi, > > So far, what I have on the agenda is: > > 1. Review of work done on GSMP spec - including results of the > editing meeting and work done since then. > > 2. Reports on implementations - I know there are a few, > and I am hoping that the folk working on them will come forward > with short reports. > > 3. Discussions of future work for GSMP > > > Regards, > > a. > ----------------------------------- > avri doria > Office: +1 781 993 4645 > Mobile: +1 781 308 7680 > > > > -----Original Message----- > > From: EXT Kenneth Sundell [mailto:ksundell@nortelnetworks.com] > > Sent: 23 February, 2000 2:42 AM > > To: gsmp@psyton.com > > Subject: Re: GSMP WG adelaide > > > > > > > > folks, > > we have been assigned one full slot for the adelaide meeting, > > so it's time to > > create an agenda. Please forward any agenda items you may > > have to me and > > Avri. It might also be a good idea to cc your requests to the > > list as well. > > > > Regards, > > Ken > > > > > > "Khosravi, Hormuzd M" wrote: > > > > > Hi, > > > > > > I was wondering if the GSMP WG has an agenda for Adelaide > > and is going to > > > hold any meetings. > > > Please do let me know. > > > > > > Thanks, > > > Hormuzd. > > > > -- > > Kenneth Sundell > > Nortel Networks > > Routing Architecture Lab > > S:t Eriksgatan 115 A, PO Box 6701 > > 113 85 Stockholm, Sweden > > phone: +46 8 5088-3538, mobile +46 70 665-7838 > > e-mail: ksundell@nortelnetworks.com > > > > > From owner-gsmp@psyton.com Thu Mar 2 00:36:50 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24712 for ; Thu, 2 Mar 2000 00:36:50 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id AAA30554 for gsmp-list; Thu, 2 Mar 2000 00:09:59 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id AAA30551 for ; Thu, 2 Mar 2000 00:09:57 -0500 From: avri.doria@nokia.com Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id HAA16132 for ; Thu, 2 Mar 2000 07:09:56 +0200 (EET) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id HAA11505 for ; Thu, 2 Mar 2000 07:09:55 +0200 (EET) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <1RM29S6T>; Wed, 1 Mar 2000 23:09:03 -0600 Message-ID: To: gsmp@psyton.com Subject: multipoint label issue Date: Wed, 1 Mar 2000 23:08:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Hi, One of my action items from the editing session was to recommend a mechanism for multipoint label support. That is some support for switches who have a specialized set of labels specialized for multipoint connections. I suggest adding a Multipoint Query flag to the Label request message. The switch would then either respond with the list of specialized multipoint labels or with an error code indicating that there were no multipoint labels. --- M: Multipoint Query If the Multipoint Query flag is set the switch must respond with the current range of valid specialized multipoint labels. The current label range is not changed by a request message with the Multipoint Query flag set. .... If the Multipoint Query flag is set in the request message, and the switch does not support a range of valid multipoint labels then the switch must reply with a failure response message with the Code field se to, "Specialized multipoint labels not supported" The Min Label and Max Label fields are not used in the Multipoint Query request message. regards, a. ----------------------------------- avri doria Office: +1 781 993 4645 Mobile: +1 781 308 7680 From owner-gsmp@psyton.com Thu Mar 2 15:06:51 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24424 for ; Thu, 2 Mar 2000 15:06:49 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id OAA32550 for gsmp-list; Thu, 2 Mar 2000 14:38:00 -0500 Received: from thefsb.org (216-59-34-200.usa.flashcom.net [216.59.34.200]) by nighthawk.psyton.com (8.9.0/8.9.0) with SMTP id OAA32547 for ; Thu, 2 Mar 2000 14:37:59 -0500 Received: (qmail 7771 invoked from network); 2 Mar 2000 19:36:00 -0000 Received: from unknown (HELO tworster) (192.168.65.100) by 216-59-34-200.usa.flashcom.net with SMTP; 2 Mar 2000 19:36:00 -0000 From: "tom worster" To: Subject: managing output label ranges Date: Thu, 2 Mar 2000 14:38:00 -0500 Message-ID: <001301bf847e$d2614900$6441a8c0@thefsb.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit at the editing session in new orleans it was requested that gsmp manage output label ranges. this involves introducing fields or message into the port management messages to report and change output label ranges on each port on each partition, checking that the output labels in connection management messages are within the specified range and issuing error responses if they are not. it may not be necessary to include output label management in the port management messages if we specify in the protocol spec that a port's output label range always matches its input label range. however, this would lead to a loss of generality over the current protocol spec which could be a problem in mpls applications. the desire to include this feature stems from a desire to prevent controllers from establishing connections outside of their partitions' allocated resources. my opinion on the proposal is as follows. the legality of a given value of a label at an output port is a matter for the network layer (i'm using the term network layer rather loosely). gsmp is supposed to be ignorant of network layer issues as far as possible and we have a basic assumption in the design of gsmp that controllers know what they are doing. there are very many ways that an errant controller can cause trouble and establishing connections to output ports that are illegal at the network layer is just one way. we have not in the past attempted to "police" the controller's behaviour by installing state in the switch that prevents control plane errors at the network layer. i therefore argue against the proposal on the grounds that it is neither necessary nor easy to do. an interesting related issue is that gsmp lets the controller manipulate label ranges. this reasonable as far as gsmp is concerned but allows controller behaviour that is very illegal in the msf switch control architecture. any other opinions? c u tom From owner-gsmp@psyton.com Thu Mar 2 16:04:10 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26931 for ; Thu, 2 Mar 2000 16:04:08 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id PAA00321 for gsmp-list; Thu, 2 Mar 2000 15:38:13 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id PAA00318 for ; Thu, 2 Mar 2000 15:38:02 -0500 From: avri.doria@nokia.com Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id WAA03315 for ; Thu, 2 Mar 2000 22:38:01 +0200 (EET) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id WAA00900 for ; Thu, 2 Mar 2000 22:38:01 +0200 (EET) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <1RM29W8R>; Thu, 2 Mar 2000 14:37:08 -0600 Message-ID: To: gsmp@psyton.com Subject: Adelaide Schedule Date: Thu, 2 Mar 2000 14:36:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com For anyone who does not get the agenda mailing, we have been schedules as follows: THURSDAY, March 30, 2000 .... 1130-1300 Break 1300-1500 Afternoon Sessions I APP cnrp Common Name Resolution Protocol WG IRTF aaaarch Authentication Authorisation Accounting Architecture RG OPS rmonmib Remote Network Monitoring WG RTG gsmp General Switch Management Protocol WG SEC saag Open Security Area Directorate Meeting TSV avt Audio/Video Transport WG * a. ----------------------------------- avri doria Office: +1 781 993 4645 Mobile: +1 781 308 7680 From owner-gsmp@psyton.com Thu Mar 2 17:12:30 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29508 for ; Thu, 2 Mar 2000 17:12:29 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id QAA00643 for gsmp-list; Thu, 2 Mar 2000 16:48:12 -0500 Received: from cplane.com (IDENT:qmailr@[63.193.105.226]) by nighthawk.psyton.com (8.9.0/8.9.0) with SMTP id QAA00640 for ; Thu, 2 Mar 2000 16:48:10 -0500 Received: (qmail 3641 invoked from network); 2 Mar 2000 21:33:16 -0000 Received: from unknown (HELO texas.cplane.com) (unknown) by unknown with SMTP; 2 Mar 2000 21:33:16 -0000 Received: (qmail 8821 invoked from network); 2 Mar 2000 21:49:36 -0000 Received: from unknown (HELO cplane.com) (unknown) by unknown with SMTP; 2 Mar 2000 21:49:36 -0000 Message-ID: <38BEE1F0.451B5CA3@cplane.com> Date: Thu, 02 Mar 2000 13:49:36 -0800 From: Jaroslaw Sydir Organization: CPlane Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: Re: managing output label ranges References: <001301bf847e$d2614900$6441a8c0@thefsb.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Tom, Last year, the Partition Id field was added to GSMP messages, in order to allow a GSMP controller to control a partition of a switch, rather then just the complete switch. Just to make sure that we are in sync, our definition of a partion is an arbitrary subset of switch resources, which are either reserved exclusively for the controller that owns the partition or are shared with other partitions according to some policy. The simplest model is to partition resources for the exclusive use of individual controllers, allowing them to operate on their partition, oblivious to the fact that they are controlling only a subset of the switch resources and that other subets of the switch resources are being controlled by other controllers. When switch partitions are created on switches throughout a network, they form a partition of the network (a virtual network). In order for this to work, the resources assigned to adjacent switch partitions (within the same network partition) must match. That is the outgoing bandwidth at one end of a virtual link (a partition of a link) must match the incoming bandwidth of the adjacent switch partition. Similarly the outgoing labels used by a partition must match the incoming labels of the adjacent partition. When such network partitions are set up properly they can be used to host different services over the same network (e.g., MPLS and native ATM) or to host individual VPNs. In order for this model to work, the switches must guarantee that errant/malicious controllers cannot affect the operations of other partitions. Within a virtual network (network partition) the peer controllers are free to make whatever errors they like, and I agree with you that it is not the job of the GSMP slave to try to protect them from themselves. However it is critial that a partitionable switch police the actions of controllers to make certain that they do not interfere with each other and GSMP, as the protocol used to control a partition must carry the messages that enable this. In a partitioned network, the ability to use an outgoing label outside the range of incoming labels assigned to the adjacent partition, gives an errant or malicious controller the ability to send traffic into an unrelated network partition. This is clearly not desirable. To illustrate, here is an example. Switch 1 is connected to switch 2 via link 1. Assume that link 1 plugs into Port 0 on both switches. Partition A on Switch 1 is part of the same virtual network as Partition A on switch 2. Assuming that we assign only incoming label space, partition A on switch 1 will have some label range (which I've omitted in the diagram) and Partition A on switch 2 will have an incoming label range, which I've assigned to be VPI 0 VCI 1-10. Similarly there is a second pair of partitions (B), which are part of a different virtual network. The resources specified in the example are port resources on the ports which are connected by link 1 (ports 0), so the two partitions share resources on the link. Now, if things are to work correctly the controller for Partition A on switch 1 creates a connection accross switch 1 from some incoming port, vpi, vci to say port 0 vpi 0 vci 1. This will cause cells to be routed to Partition A on switch 2 which is within the same virtual network. On the other hand, if the controller of Partition A on switch 1 sends a request to create a connection from some incoming port, vpi,vci to port 0 vpi 0 vci 15, the cells flowing to that connection will flow into Partition B on switch 2 and thus into a different virtual network. There will be no way to prevent the controller of partition A from messing with Partition B. ------------------- --------------------- | Switch 1 | | Switch 2 | | ---------------- | Port 0 Port 0 | ----------------- | ||Partition A | | Link 1 | | Partition A | | || BW: 5 Mbs | |--------------------------| | BW: 5 Mbs | | || | | | | Incoming | | || | | | | Labels: | | || | | | | vpi 0 vci 1- 10 | | | ---------------- |==========================| ----------------- | | | | | | ---------------- | | -----------------| | ||Partition B | | | | Partition B | | || BW: 10 Mbs | | | | BW: 10 Mbs | | || | |-------------------------- | Incoming | | || | | | | Labels: | | || | | | | vpi 0 vci 11-20 | | | ---------------- | | ----------------- | | | | | | | | | | | | | ------------------- --------------------- So to summarize my lengthy note, we believe that it is a fundamental responsiblity of a partitionable switch to disallow a controller of a partition from interferring with the operation of any other partition. Furthermore, we believe that the resources of a partition should explicitly include outgoing labels and that the GSMP connection management requests be policed to disallow connections from using labels outside this range. We therefore restate our proposal that the Port information message response include both incoming and outgoing label ranges and the the GSMP slave police the use of both incoming and outgoing labels. Regards, Jerry Sydir From owner-gsmp@psyton.com Fri Mar 3 12:29:19 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04158 for ; Fri, 3 Mar 2000 12:29:13 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id MAA03730 for gsmp-list; Fri, 3 Mar 2000 12:01:02 -0500 Received: from cplane.com (IDENT:qmailr@[63.193.105.226]) by nighthawk.psyton.com (8.9.0/8.9.0) with SMTP id MAA03727 for ; Fri, 3 Mar 2000 12:01:01 -0500 Received: (qmail 5565 invoked from network); 3 Mar 2000 16:46:13 -0000 Received: from unknown (HELO texas.cplane.com) (unknown) by unknown with SMTP; 3 Mar 2000 16:46:13 -0000 Received: (qmail 13292 invoked from network); 3 Mar 2000 17:02:36 -0000 Received: from unknown (HELO capetown) (unknown) by unknown with SMTP; 3 Mar 2000 17:02:36 -0000 From: "Simon Crosby" To: Subject: RE: managing output label ranges Date: Fri, 3 Mar 2000 08:57:54 -0800 Message-ID: <000f01bf8531$9fdfcfc0$0e02a8c0@capetown.cplane.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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <38BEE1F0.451B5CA3@cplane.com> Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Good reply. S > -----Original Message----- > From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of > Jaroslaw Sydir > Sent: Thursday, March 02, 2000 1:50 PM > To: gsmp@psyton.com > Subject: Re: managing output label ranges > > > Tom, > > Last year, the Partition Id field was added to GSMP messages, in order > to allow a GSMP controller to control a partition of a switch, rather > then just the complete switch. Just to make sure that we are in sync, > our definition of a partion is an arbitrary subset of switch > resources, > which are either reserved exclusively for the controller that owns the > partition or are shared with other partitions according to > some policy. > The simplest model is to partition resources for the exclusive use of > individual controllers, allowing them to operate on their partition, > oblivious to the fact that they are controlling only a subset of the > switch resources and that other subets of the switch > resources are being > controlled by other controllers. > > When switch partitions are created on switches throughout a network, > they form a partition of the network (a virtual network). In order for > this to work, the resources assigned to adjacent switch partitions > (within the same network partition) must match. That is the outgoing > bandwidth at one end of a virtual link (a partition of a link) must > match the incoming bandwidth of the adjacent switch > partition. Similarly > the outgoing labels used by a partition must match the incoming labels > of the adjacent partition. When such network partitions are set up > properly they can be used to host different services over the same > network (e.g., MPLS and native ATM) or to host individual VPNs. > > In order for this model to work, the switches must guarantee that > errant/malicious controllers cannot affect the operations of other > partitions. Within a virtual network (network partition) the peer > controllers are free to make whatever errors they like, and I > agree with > you that it is not the job of the GSMP slave to try to > protect them from > themselves. However it is critial that a partitionable switch > police the > actions of controllers to make certain that they do not interfere with > each other and GSMP, as the protocol used to control a partition must > carry the messages that enable this. > > In a partitioned network, the ability to use an outgoing label outside > the range of incoming labels assigned to the adjacent partition, gives > an errant or malicious controller the ability to send traffic into an > unrelated network partition. This is clearly not desirable. > > To illustrate, here is an example. Switch 1 is connected to > switch 2 via > link 1. Assume that link 1 plugs into Port 0 on both switches. > Partition A on Switch 1 is part of the same virtual network as > Partition A on switch 2. Assuming that we assign only incoming label > space, > partition A on switch 1 will have some label range (which I've omitted > in the diagram) > and Partition A on switch 2 will have an incoming label range, which > I've > assigned to be VPI 0 VCI 1-10. Similarly there is a second pair of > partitions (B), > which are part of a different virtual network. The resources specified > in the example > are port resources on the ports which are connected by link 1 > (ports 0), > so the two > partitions share resources on the link. Now, if things are to work > correctly the > controller for Partition A on switch 1 creates a connection accross > switch 1 from some incoming port, vpi, vci to say port 0 vpi 0 vci 1. > This will cause cells to be routed to Partition A on switch 2 which is > within the same virtual network. > > On the other hand, if the controller of Partition A on switch > 1 sends a > request to > create a connection from some incoming port, vpi,vci to port > 0 vpi 0 vci > 15, the > cells flowing to that connection will flow into Partition B > on switch 2 > and thus > into a different virtual network. There will be no way to prevent the > controller of > partition A from messing with Partition B. > > > > ------------------- > --------------------- > | Switch 1 | | Switch > 2 | > | ---------------- | Port 0 Port 0 | > ----------------- | > ||Partition A | | Link 1 | | > Partition A > | | > || BW: 5 Mbs | |--------------------------| | BW: 5 > Mbs > | | > || | | | | > Incoming > | | > || | | | | > Labels: > | | > || | | | | vpi 0 > vci 1- 10 > | | > | ---------------- |==========================| > ----------------- | > | | > | | > | ---------------- | | > -----------------| | > ||Partition B | | | | > Partition B > | | > || BW: 10 Mbs | | | | BW: > 10 Mbs > | | > || | |-------------------------- | > Incoming > | | > || | | | | > Labels: > | | > || | | | | vpi 0 > vci 11-20 > | | > | ---------------- | | > ----------------- | > | | > | | > | | > | | > | | > | | > ------------------- > --------------------- > > > So to summarize my lengthy note, we believe that it is a fundamental > responsiblity of a partitionable switch to disallow a controller of a > partition from interferring with the operation of any other partition. > Furthermore, we believe that the resources of a partition should > explicitly include outgoing labels and that the GSMP connection > management requests be policed to disallow connections from > using labels > outside this range. We therefore restate our proposal that the Port > information message response include both incoming and outgoing label > ranges and the the GSMP slave police the use of both incoming and > outgoing labels. > > Regards, > Jerry Sydir > From owner-gsmp@psyton.com Sun Mar 5 01:19:26 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14556 for ; Sun, 5 Mar 2000 01:19:25 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id BAA08685 for gsmp-list; Sun, 5 Mar 2000 01:02:00 -0500 Received: from degeer.norrkoping.se (IDENT:root@[194.68.142.27]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id BAA08678; Sun, 5 Mar 2000 01:01:58 -0500 Received: from kllklk (ip22.providence11.ri.pub-ip.psi.net [38.26.242.22]) by degeer.norrkoping.se (8.8.7/8.8.7) with ESMTP id IAA31374; Sun, 5 Mar 2000 08:15:07 +0100 Message-Id: <200003050715.IAA31374@degeer.norrkoping.se> From: "Frank" Subject: For Today... To: first88u@degeer.norrkoping.se X-Mailer: Microsoft Outlook Express 4..72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Sat, 04 Mar 2000 23:14:32 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nighthawk.psyton.com id BAA08679 Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 8bit *Earn $2000 - $5000 weekly-starting within 1-4 weeks *78% Profit Paid Daily *No Selling *No Risk Guarantee *Work from home, No overhead, or employees. *High Tech Training & Support *Not MLM, 100x more profitable *Multibillion Dollar Travel Industry The most incredible part of our business is that ALL MY CLIENTS CALL ME! DO YOU QUALIFY FOR OUR MENTOR PROGRAM? ACCEPTING ONLY 12 NEW ASSOCIATES This is not a hobby! Serious Inquires Only!! Please reply with the following information NAME: EMAIL ADDRESS: PHONE: (Required) BEST TIME TO CALL: TO: mailto:per9@pplmail.com?subject=more_info FOR MORE INFORMATION If you are an entrepreneur or have always wanted to be your own BOSS, read on. We supply state-of-the-art training and a support system that allows you to work your business from your home with just a phone-without cold calling. DO NOT REPLY IF YOU ARE LOOKING FOR A "GET RICH QUICK" SCHEME or some extra cash or if you're lazy. We are only looking for FOCUSED serious entrepreneurs. (Pt/FT) with the DESIRE to improve their lifestyle immediately. /////////////////////////////////////////////////////////// Please remove at mailto:frank4545@yahoo.com?subject=remove /////////////////////////////////////////////////////////// From owner-gsmp@psyton.com Sun Mar 5 01:33:35 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15704 for ; Sun, 5 Mar 2000 01:33:34 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id BAA08806 for gsmp-list; Sun, 5 Mar 2000 01:26:00 -0500 Received: from mail.tidaltech.net (user-24-214-3-66.knology.net [24.214.3.66]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id BAA08803 for ; Sun, 5 Mar 2000 01:25:56 -0500 Received: from lanhost.net ([24.214.3.65]) by mail.tidaltech.net (Netscape Messaging Server 3.62) with ESMTP id 163; Sun, 5 Mar 2000 00:27:27 -0600 Message-ID: <38C1FE32.B248F266@lanhost.net> Date: Sun, 05 Mar 2000 00:26:58 -0600 From: Jackson Lancaster X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com, petr82@bettergolf.net Subject: Re: For Today... References: <200003050715.IAA31374@degeer.norrkoping.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit please dont send advertisements to an ietf list. this is unprofessional Frank wrote: > *Earn $2000 - $5000 weekly-starting within 1-4 weeks > *78% Profit Paid Daily > *No Selling > *No Risk Guarantee > *Work from home, No overhead, or employees. > *High Tech Training & Support > *Not MLM, 100x more profitable > *Multibillion Dollar Travel Industry > > The most incredible part of our business > is that ALL MY CLIENTS CALL ME! > > DO YOU QUALIFY FOR OUR MENTOR PROGRAM? > ACCEPTING ONLY 12 NEW ASSOCIATES > > This is not a hobby! Serious Inquires Only!! > > Please reply with the following information > NAME: > EMAIL ADDRESS: > PHONE: (Required) > BEST TIME TO CALL: > > TO: > > mailto:per9@pplmail.com?subject=more_info > > FOR MORE INFORMATION > > If you are an entrepreneur or have always wanted to be your own BOSS, > read on. We supply state-of-the-art training and a support system > that allows you to work your business from your home with just a > phone-without cold calling. DO NOT REPLY IF YOU ARE LOOKING FOR A > "GET RICH QUICK" SCHEME or some extra cash or if you're lazy. We are > only looking for FOCUSED serious entrepreneurs. (Pt/FT) with the > DESIRE to improve their lifestyle immediately. > > /////////////////////////////////////////////////////////// > Please remove at mailto:frank4545@yahoo.com?subject=remove > /////////////////////////////////////////////////////////// -- Jackson Lancaster, CCNA President/Head Systems Administrator LanHost Internet Services 2224 S. Sutherland Dr. Montgomery, AL 36116 http://www.lanhost.net From owner-gsmp@psyton.com Mon Mar 6 10:25:26 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09577 for ; Mon, 6 Mar 2000 10:25:23 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id KAA14125 for gsmp-list; Mon, 6 Mar 2000 10:03:09 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id KAA14122 for ; Mon, 6 Mar 2000 10:02:11 -0500 From: avri.doria@nokia.com Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id RAA22253 for ; Mon, 6 Mar 2000 17:01:59 +0200 (EET) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id RAA25924 for ; Mon, 6 Mar 2000 17:01:49 +0200 (EET) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <1RM2907D>; Mon, 6 Mar 2000 09:00:55 -0600 Message-ID: To: gsmp@psyton.com Subject: Editorial change Date: Mon, 6 Mar 2000 09:00:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Hi, Tom Worster, the longtime editor of GSMP V3, joined a startup a few months ago, and has been unable to continue his role as the primary editor of the current revision of the specification. To make up for that, the other 3 editor/authors of the spec have split up his work among ourselves, and are making a last minute effort to get the work done before this week's submission deadline. I want to thank Tom publicly for all of his efforts on behalf of the GSMP working group. Regards, a. ----------------------------------- avri doria Office: +1 781 993 4645 Mobile: +1 781 308 7680 From owner-gsmp@psyton.com Mon Mar 6 10:29:43 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09818 for ; Mon, 6 Mar 2000 10:29:41 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id KAA14196 for gsmp-list; Mon, 6 Mar 2000 10:13:53 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id KAA14193 for ; Mon, 6 Mar 2000 10:13:21 -0500 From: avri.doria@nokia.com Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id RAA16502 for ; Mon, 6 Mar 2000 17:13:18 +0200 (EET) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id RAA19305 for ; Mon, 6 Mar 2000 17:13:16 +0200 (EET) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Mon, 6 Mar 2000 09:13:15 -0600 Message-ID: To: gsmp@psyton.com Subject: RE: GSMP/MSF Forum Joint editing session concerning contribution 14 Date: Mon, 6 Mar 2000 09:11:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Hi, I am in the process of trying to fold your changes into the spec before the deadline for the upcoming meeting. by and large I accept all of it, though, due to other changes necessitated by adding TLV type labels to support the CES labels, I may end up shifting some of the bits around. One comment I don't understand was the ability to eliminate the MTYPE. The solution you have proposed works fine for the default/standard service model being offered in GSMP. The purpose of the MTYPE was to allow vendors and carriers to define a completely different service model or resource model if they so desired. In which case they would not append the encap method and traffic block as you have designed, but would instead append one of their own. regards, a. ----------------------------------- avri doria Office: +1 781 993 4645 Mobile: +1 781 308 7680 > -----Original Message----- > From: EXT Clint Bishard [mailto:clint.bishard@wcom.com] > Sent: 15 February, 2000 6:10 PM > To: gsmp@psyton.com > Cc: Bishard, Clint > Subject: GSMP/MSF Forum Joint editing session concerning > contribution 14 > > > All, > > This email concerns one of the significant conclusions > reached (contribution > 14) at the joint GSMP/MSF Switch Control WG meeting on Feb 2. > The three > present GSMP editors agreed to the principle of the requested > change and > suggested that the proposal be sent to the GSMP exploder to provide an > opportunity for input/feedback. > > The contribution recommends that GSMP's connection messages > be changed such > that they specify parameters for each port in a given > connection message > separately - instead of one set of parameters for the > connection. This > change is necessary to be able to build connections across a true > multi-service switch. (see attachment for more details) > > The below PDU format illustrates the changes that would need to be > implemented for the connection messages. Additionally, comments are > requested concerning the semantics of the changes below and > any problems > that anyone can foresee (particularly, the eight listed > changes after the > PDU below). > > The next step will be to initiate a co-authored ID between > Tom Worster and > myself to include these changes into GSMP v3. > > Note: I have not addressed the additional issue that came up > concerning > separate parameters for policing and reservation, since that > simply deals > with a change to the traffic parameters block. > > Thank you in advance for your feedback, > Clint Bishard > > > New Connection Message Format illustrating the possible > needed changes for > this proposal (changes are in bold). (typed in Courier New, size 10) > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version | Message Type | Result | Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Partition ID | Transaction Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input Port Session Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output Port Session Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input Port | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M|B|x|E| Input Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > *~x x x|E| Extended Input Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input Service Selector | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output Port | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x|x|x|E| Output Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > *~x x x|E| Extended Output Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output Service Selector | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |iQMS|oQMS|T|N|x|x| Encapsulation Method | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Under certain conditions (iQMS or oQMS set such that traffic > parameters are > required) the Add Branch message has an additional, variable > length data > block appended to the above message: > *Note: If T above is set, then only one set of Traffic > Parameters Block is > required which pertains to both the input and output ports. > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input TC Flags| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Input Traffic Parameters Block ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Output TC Flags| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Output Traffic Parameters Block ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Described Change: > A Input Port Session Number has been added so allow a > connection to include > the session number for both the input and output ports. > > Added another QMS field - one for the input port (iQMS) and > one for the > output port (oQMS) to define the type of QoS Model Selector > used at both the > input and output port. > > The Service Selector has been changed to reflect one for the > input port and > one for the output port. > > The input and output Traffic Parameter Blocks have been > individualized for > both the input and output ports. > > An additional field has been added to describe what > encapsulation method is > required to adapt the port technologies for each port to each > other. For > example, FRF.8 or FRF.5 for a connection built between and FR > and ATM port. > Tom - you suggested a 32 bit opaque value - would 24 bits be > enough. 24 > bits seemed to fit easily with the additional QMS, T, and N bit. > Furthermore, I first suggested that an encapsulation would be > needed for the > input and the output. However, after further thought, I think one > encapsulation field specifying what encapsulation is needed > between the two > ports should be sufficient. We are not concerned with what > the switch does > in the middle. > > The added field 'T' would be used in the case that one set of Traffic > Parameters Block is used for both the input port and the > output port. For > example, the case when the two port types are the same and > will use the same > traffic parameters. > > The added field 'N' would be used to specify a Null > encapsulation method. > For example, a connection between two ATM ports. > > The MType defined for a switch in the switch configuration > messages would no > longer be required and would be removed from those messages. > > Note: It is assumed that the switch will determine what > characteristics are > needed for the internal connection from the parameters > specified for each > port. For example, if a connection is built across an ATM > switch from a FR > port (with given FR parameters for that port) to an ATM port > (with given > parameters for that port indicating a nrt-VBR service > category) - then the > ATM switch would use the nrt-VBR service category for the internal > connection class, but this would not be directly indicated to > the switch in > the connection message. > > > From owner-gsmp@psyton.com Mon Mar 6 10:35:55 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10136 for ; Mon, 6 Mar 2000 10:35:55 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id KAA14312 for gsmp-list; Mon, 6 Mar 2000 10:25:05 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id KAA14302 for ; Mon, 6 Mar 2000 10:25:00 -0500 From: avri.doria@nokia.com Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id RAA10696 for ; Mon, 6 Mar 2000 17:24:58 +0200 (EET) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id RAA06067 for ; Mon, 6 Mar 2000 17:24:56 +0200 (EET) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <1RM20ADM>; Mon, 6 Mar 2000 09:24:02 -0600 Message-ID: To: gsmp@psyton.com Subject: RE: managing output label ranges Date: Mon, 6 Mar 2000 09:23:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Hi, I accept the reasoning in your note, but have a question. Is there any reason why the assignment of labels cannot be symmetrical? That is, when a range of labels is assigned, the set of labels would be the range assigned for both incoming and outgoing labels. This simplifies the mechanisms yet should give the same protections. Perhaps some text would need to added discussing the principle that a partition can only use the labels in its range; regardless of whether that use be for incoming or outgoing. regards, a. ----------------------------------- avri doria Office: +1 781 993 4645 Mobile: +1 781 308 7680 > -----Original Message----- > From: EXT Jaroslaw Sydir [mailto:sydir@cplane.com] > Sent: 02 March, 2000 4:50 PM > To: gsmp@psyton.com > Subject: Re: managing output label ranges > > ... > > So to summarize my lengthy note, we believe that it is a fundamental > responsiblity of a partitionable switch to disallow a controller of a > partition from interferring with the operation of any other partition. > Furthermore, we believe that the resources of a partition should > explicitly include outgoing labels and that the GSMP connection > management requests be policed to disallow connections from > using labels > outside this range. We therefore restate our proposal that the Port > information message response include both incoming and outgoing label > ranges and the the GSMP slave police the use of both incoming and > outgoing labels. > > Regards, > Jerry Sydir > From owner-gsmp@psyton.com Mon Mar 6 15:09:01 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23404 for ; Mon, 6 Mar 2000 15:09:00 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id OAA15195 for gsmp-list; Mon, 6 Mar 2000 14:54:02 -0500 Received: from PMESMTP02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id OAA15192 for ; Mon, 6 Mar 2000 14:54:01 -0500 Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FR000BAIN8SMZ@firewall.mcit.com> for gsmp@psyton.com; Mon, 6 Mar 2000 19:53:16 +0000 (GMT) Received: from omzmta04.mcit.com (omzmta04.mcit.com [166.37.194.122]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id TAA20379 for ; Mon, 06 Mar 2000 19:53:50 +0000 (GMT) Received: from pc25811 ([165.122.129.149]) by omzmta04.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000306195315.ICML622@pc25811> for ; Mon, 06 Mar 2000 19:53:15 +0000 Date: Mon, 06 Mar 2000 13:53:03 -0600 From: Clint Bishard Subject: RE: GSMP/MSF Forum Joint editing session concerning contribution 14 In-reply-to: To: gsmp@psyton.com Message-id: <000701bf87a5$962935e0$95817aa5@pc25811.wcom.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.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-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Avri, Thanks for the feedback. Does your comment of accepting the changes mean that you are working these into the latest GSMP draft (or I guess actually updating it since the duel Service Selector was already in the last draft). Some of the discussion was that a joint ID may need to be submitted to institute these changes. Is this still necessary? Concerning the TLV labels, is this necessary since the type of label will already be known by the controller and switch given the type of port that was defined? I probably do not fully understand the MTYPE. However, the concept I understood was that an MTYPE was defined for the switch, and then all connections were built given that MTYPE. However, connections are no longer built under this assumption. Each connection message states the connection parameters separately for each port and no parameters regarding the switch type are conveyed in the connection messages. Doesn't this now negate the need for a MTYPE being defined? Thanks for your work Avri, Clint -----Original Message----- From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of avri.doria@nokia.com Sent: Monday, March 06, 2000 9:12 AM To: gsmp@psyton.com Subject: RE: GSMP/MSF Forum Joint editing session concerning contribution 14 Hi, I am in the process of trying to fold your changes into the spec before the deadline for the upcoming meeting. by and large I accept all of it, though, due to other changes necessitated by adding TLV type labels to support the CES labels, I may end up shifting some of the bits around. One comment I don't understand was the ability to eliminate the MTYPE. The solution you have proposed works fine for the default/standard service model being offered in GSMP. The purpose of the MTYPE was to allow vendors and carriers to define a completely different service model or resource model if they so desired. In which case they would not append the encap method and traffic block as you have designed, but would instead append one of their own. regards, a. ----------------------------------- avri doria Office: +1 781 993 4645 Mobile: +1 781 308 7680 > -----Original Message----- > From: EXT Clint Bishard [mailto:clint.bishard@wcom.com] > Sent: 15 February, 2000 6:10 PM > To: gsmp@psyton.com > Cc: Bishard, Clint > Subject: GSMP/MSF Forum Joint editing session concerning > contribution 14 > > > All, > > This email concerns one of the significant conclusions > reached (contribution > 14) at the joint GSMP/MSF Switch Control WG meeting on Feb 2. > The three > present GSMP editors agreed to the principle of the requested > change and > suggested that the proposal be sent to the GSMP exploder to provide an > opportunity for input/feedback. > > The contribution recommends that GSMP's connection messages > be changed such > that they specify parameters for each port in a given > connection message > separately - instead of one set of parameters for the > connection. This > change is necessary to be able to build connections across a true > multi-service switch. (see attachment for more details) > > The below PDU format illustrates the changes that would need to be > implemented for the connection messages. Additionally, comments are > requested concerning the semantics of the changes below and > any problems > that anyone can foresee (particularly, the eight listed > changes after the > PDU below). > > The next step will be to initiate a co-authored ID between > Tom Worster and > myself to include these changes into GSMP v3. > > Note: I have not addressed the additional issue that came up > concerning > separate parameters for policing and reservation, since that > simply deals > with a change to the traffic parameters block. > > Thank you in advance for your feedback, > Clint Bishard > > > New Connection Message Format illustrating the possible > needed changes for > this proposal (changes are in bold). (typed in Courier New, size 10) > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version | Message Type | Result | Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Partition ID | Transaction Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input Port Session Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output Port Session Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input Port | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M|B|x|E| Input Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > *~x x x|E| Extended Input Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input Service Selector | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output Port | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x|x|x|E| Output Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > *~x x x|E| Extended Output Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output Service Selector | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |iQMS|oQMS|T|N|x|x| Encapsulation Method | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Under certain conditions (iQMS or oQMS set such that traffic > parameters are > required) the Add Branch message has an additional, variable > length data > block appended to the above message: > *Note: If T above is set, then only one set of Traffic > Parameters Block is > required which pertains to both the input and output ports. > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input TC Flags| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Input Traffic Parameters Block ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Output TC Flags| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Output Traffic Parameters Block ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Described Change: > A Input Port Session Number has been added so allow a > connection to include > the session number for both the input and output ports. > > Added another QMS field - one for the input port (iQMS) and > one for the > output port (oQMS) to define the type of QoS Model Selector > used at both the > input and output port. > > The Service Selector has been changed to reflect one for the > input port and > one for the output port. > > The input and output Traffic Parameter Blocks have been > individualized for > both the input and output ports. > > An additional field has been added to describe what > encapsulation method is > required to adapt the port technologies for each port to each > other. For > example, FRF.8 or FRF.5 for a connection built between and FR > and ATM port. > Tom - you suggested a 32 bit opaque value - would 24 bits be > enough. 24 > bits seemed to fit easily with the additional QMS, T, and N bit. > Furthermore, I first suggested that an encapsulation would be > needed for the > input and the output. However, after further thought, I think one > encapsulation field specifying what encapsulation is needed > between the two > ports should be sufficient. We are not concerned with what > the switch does > in the middle. > > The added field 'T' would be used in the case that one set of Traffic > Parameters Block is used for both the input port and the > output port. For > example, the case when the two port types are the same and > will use the same > traffic parameters. > > The added field 'N' would be used to specify a Null > encapsulation method. > For example, a connection between two ATM ports. > > The MType defined for a switch in the switch configuration > messages would no > longer be required and would be removed from those messages. > > Note: It is assumed that the switch will determine what > characteristics are > needed for the internal connection from the parameters > specified for each > port. For example, if a connection is built across an ATM > switch from a FR > port (with given FR parameters for that port) to an ATM port > (with given > parameters for that port indicating a nrt-VBR service > category) - then the > ATM switch would use the nrt-VBR service category for the internal > connection class, but this would not be directly indicated to > the switch in > the connection message. > > > From owner-gsmp@psyton.com Mon Mar 6 16:12:17 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01422 for ; Mon, 6 Mar 2000 16:12:16 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id PAA15464 for gsmp-list; Mon, 6 Mar 2000 15:54:18 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id PAA15461 for ; Mon, 6 Mar 2000 15:54:14 -0500 From: avri.doria@nokia.com Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id WAA20007 for ; Mon, 6 Mar 2000 22:54:09 +0200 (EET) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id WAA04599 for ; Mon, 6 Mar 2000 22:54:08 +0200 (EET) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Mon, 6 Mar 2000 14:54:07 -0600 Message-ID: To: gsmp@psyton.com Subject: RE: GSMP/MSF Forum Joint editing session concerning contribution 14 Date: Mon, 6 Mar 2000 14:52:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Hi, Yes, we are currently adding the material in. The original thought had been that an I-D was required, but given the press of time, we decided that your email contribution was sufficiently explicit and substantive that there was no real need to take the extra time involved in creating an I-d at this late date. We can discuss the changes once the are in the next version of the draft - both in Adelaide and on the list. As for the TLV labels, while it might not be necessary to include the type in all cases, some of the labels that are currently being envisioned are variable length and therefore require a length field. Also, since it is possible to use different label encapsulations on a common port type, it seems advantageous to include a label type field. As for the Mtype. It is used to set the model the switch works under - in a sense it defines the context for the parameters being used. Your current proposal affects only one model - the default. If someone where to want to use, for example, an explicit resource model then they would not be using the traffic blocks you have proposed, but would be using some other form and would probably even have a different set of resource commands defined using the commands space reserved for that purpose. Regards, a. ----------------------------------- avri doria Office: +1 781 993 4645 Mobile: +1 781 308 7680 > -----Original Message----- > From: EXT Clint Bishard [mailto:clint.bishard@wcom.com] > Sent: 06 March, 2000 2:53 PM > To: gsmp@psyton.com > Subject: RE: GSMP/MSF Forum Joint editing session concerning > contribution 14 > > > Avri, > > Thanks for the feedback. Does your comment of accepting the > changes mean > that you are working these into the latest GSMP draft (or I > guess actually > updating it since the duel Service Selector was already in > the last draft). > Some of the discussion was that a joint ID may need to be submitted to > institute these changes. Is this still necessary? > > Concerning the TLV labels, is this necessary since the type > of label will > already be known by the controller and switch given the type > of port that > was defined? > > I probably do not fully understand the MTYPE. However, the concept I > understood was that an MTYPE was defined for the switch, and then all > connections were built given that MTYPE. However, > connections are no longer > built under this assumption. Each connection message states > the connection > parameters separately for each port and no parameters > regarding the switch > type are conveyed in the connection messages. Doesn't this > now negate the > need for a MTYPE being defined? > > Thanks for your work Avri, > Clint From owner-gsmp@psyton.com Mon Mar 6 16:43:07 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06119 for ; Mon, 6 Mar 2000 16:43:07 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id QAA15610 for gsmp-list; Mon, 6 Mar 2000 16:26:09 -0500 Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id QAA15607 for ; Mon, 6 Mar 2000 16:26:03 -0500 Received: from omzrelay.mcit.com ([166.37.204.49]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0FR0004DJRID62@firewall.mcit.com> for gsmp@psyton.com; Mon, 6 Mar 2000 21:25:26 +0000 (GMT) Received: from omzmta01.mcit.com (omzmta01.mcit.com [166.37.194.119]) by omzrelay.mcit.com (8.8.7/) with ESMTP id VAA04643 for ; Mon, 06 Mar 2000 21:25:11 +0000 (GMT) Received: from pc25811 ([165.122.129.149]) by omzmta01.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000306212508.JNNS652@pc25811> for ; Mon, 06 Mar 2000 21:25:08 +0000 Date: Mon, 06 Mar 2000 15:24:54 -0600 From: Clint Bishard Subject: RE: GSMP/MSF Forum Joint editing session concerning contribution 14 In-reply-to: To: gsmp@psyton.com Message-id: <000001bf87b2$6b562780$95817aa5@pc25811.wcom.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.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-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Great, I will consider it done. Thanks, Clint -----Original Message----- From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of avri.doria@nokia.com Sent: Monday, March 06, 2000 2:52 PM To: gsmp@psyton.com Subject: RE: GSMP/MSF Forum Joint editing session concerning contribution 14 Hi, Yes, we are currently adding the material in. The original thought had been that an I-D was required, but given the press of time, we decided that your email contribution was sufficiently explicit and substantive that there was no real need to take the extra time involved in creating an I-d at this late date. We can discuss the changes once the are in the next version of the draft - both in Adelaide and on the list. As for the TLV labels, while it might not be necessary to include the type in all cases, some of the labels that are currently being envisioned are variable length and therefore require a length field. Also, since it is possible to use different label encapsulations on a common port type, it seems advantageous to include a label type field. As for the Mtype. It is used to set the model the switch works under - in a sense it defines the context for the parameters being used. Your current proposal affects only one model - the default. If someone where to want to use, for example, an explicit resource model then they would not be using the traffic blocks you have proposed, but would be using some other form and would probably even have a different set of resource commands defined using the commands space reserved for that purpose. Regards, a. ----------------------------------- avri doria Office: +1 781 993 4645 Mobile: +1 781 308 7680 > -----Original Message----- > From: EXT Clint Bishard [mailto:clint.bishard@wcom.com] > Sent: 06 March, 2000 2:53 PM > To: gsmp@psyton.com > Subject: RE: GSMP/MSF Forum Joint editing session concerning > contribution 14 > > > Avri, > > Thanks for the feedback. Does your comment of accepting the > changes mean > that you are working these into the latest GSMP draft (or I > guess actually > updating it since the duel Service Selector was already in > the last draft). > Some of the discussion was that a joint ID may need to be submitted to > institute these changes. Is this still necessary? > > Concerning the TLV labels, is this necessary since the type > of label will > already be known by the controller and switch given the type > of port that > was defined? > > I probably do not fully understand the MTYPE. However, the concept I > understood was that an MTYPE was defined for the switch, and then all > connections were built given that MTYPE. However, > connections are no longer > built under this assumption. Each connection message states > the connection > parameters separately for each port and no parameters > regarding the switch > type are conveyed in the connection messages. Doesn't this > now negate the > need for a MTYPE being defined? > > Thanks for your work Avri, > Clint From owner-gsmp@psyton.com Fri Mar 10 12:37:17 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02688 for ; Fri, 10 Mar 2000 12:37:15 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id MAA29608 for gsmp-list; Fri, 10 Mar 2000 12:18:49 -0500 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id MAA29605 for ; Fri, 10 Mar 2000 12:18:48 -0500 Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id SAA25306 for ; Fri, 10 Mar 2000 18:18:47 +0100 (MET) Received: from etx.ericsson.se (avpc66.etxb.ericsson.se [130.100.27.66]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0FR700AAYURAUS@mbb1.ericsson.se> for gsmp@psyton.com; Fri, 10 Mar 2000 18:18:47 +0100 (MET) Date: Fri, 10 Mar 2000 18:18:42 +0100 From: Hans =?iso-8859-1?Q?Sj=F6strand?= Subject: Re: GSMP WG Adelaide To: gsmp@psyton.com, Avri Doria , Joachim Buerkle , Balaji Srinivasan Message-id: <38C92E72.56CC1243@etx.ericsson.se> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win95; I) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT X-Accept-Language: en References: <38C92D87.A243DE24@etx.ericsson.se> Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 8BIT sorry for that, it's getting late. I mean of course thar you could find the I-D in ftp://www.ericsson.net/pub/ietf/draft-ietf-gsmp-mib-01.txt and the mib in ftp://www.ericsson.net/pub/ietf/draft-ietf-gsmp-mib-01.mib /// Hasse Hans Sjöstrand wrote: > > hi, > > We could also possibly get a item to present the gsmp-mib that > we just submitted. Joachim Büerkle will have the presentation. > > you could find the I-D in > ftp://www.ericsson.net/pub/ietf/draft-ietf-gsmp-mib-01-txt > and the mib in > ftp://www.ericsson.net/pub/ietf/draft-ietf-gsmp-mib-01-txt > > Regards > /// Hasse (Joachim & Balaji) > > avri.doria@nokia.com wrote: > > > > Hi, > > > > While we have been approved for a slot, I don't > > know when it will be yet. > > > > The Agenda isn't due until 17 March, so we are > > still waiting to find out about contributions. > > > > Several items already on the agenda are: > > > > -Review of work done on GSMP spec - including results of the > > editing meeting and work done since then. > > draft-ietf-gsmp-04.txt (will be released by the deadline 10 Mar) > > > > -Discussion of the draft-ietf-gsmp-encaps-00.txt > > > > -Discussion of draft-ietf-gsmp-applicability-00.txt (will be released by the > > deadline 10 Mar) > > > > -Reports on implementations - I know there are a few, > > and I am hoping that the folk working on them will come forward > > with short reports. > > > > -Discussions of future work for GSMP > > > > a. > > ----------------------------------- > > avri doria > > Office: +1 781 993 4645 > > Mobile: +1 781 308 7680 > > > > > > > -----Original Message----- > > > From: EXT Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com] > > > Sent: 01 March, 2000 9:41 PM > > > To: 'gsmp@psyton.com' > > > Cc: 'avri.doria@nokia.com' > > > Subject: RE: GSMP WG Adelaide > > > > > > > > > Hi, > > > > > > I was looking at the Agenda on the IETF site and trying to > > > find out on which > > > day and time > > > the GSMP WG meeting is going to be held. I could not find > > > this information > > > there, so if someone on the list could send me this info. it > > > would be great. > > > > > > Thanks, > > > Hormuzd. > > > > > > office : 1-503-264-0334 > > > > > > > > > -----Original Message----- > > > From: avri.doria@nokia.com [mailto:avri.doria@nokia.com] > > > Sent: Wednesday, February 23, 2000 4:17 AM > > > To: gsmp@psyton.com > > > Subject: RE: GSMP WG Adelaide > > > > > > > > > Hi, > > > > > > So far, what I have on the agenda is: > > > > > > 1. Review of work done on GSMP spec - including results of the > > > editing meeting and work done since then. > > > > > > 2. Reports on implementations - I know there are a few, > > > and I am hoping that the folk working on them will come forward > > > with short reports. > > > > > > 3. Discussions of future work for GSMP > > > > > > > > > Regards, > > > > > > a. > > > ----------------------------------- > > > avri doria > > > Office: +1 781 993 4645 > > > Mobile: +1 781 308 7680 > > > > > > > > > > -----Original Message----- > > > > From: EXT Kenneth Sundell [mailto:ksundell@nortelnetworks.com] > > > > Sent: 23 February, 2000 2:42 AM > > > > To: gsmp@psyton.com > > > > Subject: Re: GSMP WG adelaide > > > > > > > > > > > > > > > > folks, > > > > we have been assigned one full slot for the adelaide meeting, > > > > so it's time to > > > > create an agenda. Please forward any agenda items you may > > > > have to me and > > > > Avri. It might also be a good idea to cc your requests to the > > > > list as well. > > > > > > > > Regards, > > > > Ken > > > > > > > > > > > > "Khosravi, Hormuzd M" wrote: > > > > > > > > > Hi, > > > > > > > > > > I was wondering if the GSMP WG has an agenda for Adelaide > > > > and is going to > > > > > hold any meetings. > > > > > Please do let me know. > > > > > > > > > > Thanks, > > > > > Hormuzd. > > > > > > > > -- > > > > Kenneth Sundell > > > > Nortel Networks > > > > Routing Architecture Lab > > > > S:t Eriksgatan 115 A, PO Box 6701 > > > > 113 85 Stockholm, Sweden > > > > phone: +46 8 5088-3538, mobile +46 70 665-7838 > > > > e-mail: ksundell@nortelnetworks.com > > > > > > > > > > > From owner-gsmp@psyton.com Fri Mar 10 12:37:18 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02702 for ; Fri, 10 Mar 2000 12:37:18 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id MAA29590 for gsmp-list; Fri, 10 Mar 2000 12:15:03 -0500 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id MAA29587 for ; Fri, 10 Mar 2000 12:15:02 -0500 Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id SAA22760 for ; Fri, 10 Mar 2000 18:14:53 +0100 (MET) Received: from etx.ericsson.se (avpc66.etxb.ericsson.se [130.100.27.66]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0FR700BILUKR4D@mbb1.ericsson.se> for gsmp@psyton.com; Fri, 10 Mar 2000 18:14:52 +0100 (MET) Date: Fri, 10 Mar 2000 18:14:47 +0100 From: Hans =?iso-8859-1?Q?Sj=F6strand?= Subject: Re: GSMP WG Adelaide To: gsmp@psyton.com, Avri Doria Cc: Joachim Buerkle , Balaji Srinivasan Message-id: <38C92D87.A243DE24@etx.ericsson.se> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win95; I) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT X-Accept-Language: en References: Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 8BIT hi, We could also possibly get a item to present the gsmp-mib that we just submitted. Joachim Büerkle will have the presentation. you could find the I-D in ftp://www.ericsson.net/pub/ietf/draft-ietf-gsmp-mib-01-txt and the mib in ftp://www.ericsson.net/pub/ietf/draft-ietf-gsmp-mib-01-txt Regards /// Hasse (Joachim & Balaji) avri.doria@nokia.com wrote: > > Hi, > > While we have been approved for a slot, I don't > know when it will be yet. > > The Agenda isn't due until 17 March, so we are > still waiting to find out about contributions. > > Several items already on the agenda are: > > -Review of work done on GSMP spec - including results of the > editing meeting and work done since then. > draft-ietf-gsmp-04.txt (will be released by the deadline 10 Mar) > > -Discussion of the draft-ietf-gsmp-encaps-00.txt > > -Discussion of draft-ietf-gsmp-applicability-00.txt (will be released by the > deadline 10 Mar) > > -Reports on implementations - I know there are a few, > and I am hoping that the folk working on them will come forward > with short reports. > > -Discussions of future work for GSMP > > a. > ----------------------------------- > avri doria > Office: +1 781 993 4645 > Mobile: +1 781 308 7680 > > > > -----Original Message----- > > From: EXT Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com] > > Sent: 01 March, 2000 9:41 PM > > To: 'gsmp@psyton.com' > > Cc: 'avri.doria@nokia.com' > > Subject: RE: GSMP WG Adelaide > > > > > > Hi, > > > > I was looking at the Agenda on the IETF site and trying to > > find out on which > > day and time > > the GSMP WG meeting is going to be held. I could not find > > this information > > there, so if someone on the list could send me this info. it > > would be great. > > > > Thanks, > > Hormuzd. > > > > office : 1-503-264-0334 > > > > > > -----Original Message----- > > From: avri.doria@nokia.com [mailto:avri.doria@nokia.com] > > Sent: Wednesday, February 23, 2000 4:17 AM > > To: gsmp@psyton.com > > Subject: RE: GSMP WG Adelaide > > > > > > Hi, > > > > So far, what I have on the agenda is: > > > > 1. Review of work done on GSMP spec - including results of the > > editing meeting and work done since then. > > > > 2. Reports on implementations - I know there are a few, > > and I am hoping that the folk working on them will come forward > > with short reports. > > > > 3. Discussions of future work for GSMP > > > > > > Regards, > > > > a. > > ----------------------------------- > > avri doria > > Office: +1 781 993 4645 > > Mobile: +1 781 308 7680 > > > > > > > -----Original Message----- > > > From: EXT Kenneth Sundell [mailto:ksundell@nortelnetworks.com] > > > Sent: 23 February, 2000 2:42 AM > > > To: gsmp@psyton.com > > > Subject: Re: GSMP WG adelaide > > > > > > > > > > > > folks, > > > we have been assigned one full slot for the adelaide meeting, > > > so it's time to > > > create an agenda. Please forward any agenda items you may > > > have to me and > > > Avri. It might also be a good idea to cc your requests to the > > > list as well. > > > > > > Regards, > > > Ken > > > > > > > > > "Khosravi, Hormuzd M" wrote: > > > > > > > Hi, > > > > > > > > I was wondering if the GSMP WG has an agenda for Adelaide > > > and is going to > > > > hold any meetings. > > > > Please do let me know. > > > > > > > > Thanks, > > > > Hormuzd. > > > > > > -- > > > Kenneth Sundell > > > Nortel Networks > > > Routing Architecture Lab > > > S:t Eriksgatan 115 A, PO Box 6701 > > > 113 85 Stockholm, Sweden > > > phone: +46 8 5088-3538, mobile +46 70 665-7838 > > > e-mail: ksundell@nortelnetworks.com > > > > > > > > From owner-gsmp@psyton.com Sun Mar 12 00:58:10 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06597 for ; Sun, 12 Mar 2000 00:58:09 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id AAA02712 for gsmp-list; Sun, 12 Mar 2000 00:44:58 -0500 Received: from mail.world.ch ([193.247.200.205]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id AAA02705; Sun, 12 Mar 2000 00:44:56 -0500 Received: from kllklk [208.161.7.182] by mail.world.ch with ESMTP (SMTPD32-6.00) id AE6C21E30116; Sun, 12 Mar 2000 06:43:08 +0100 From: "Andy" Subject: Have You Seen... To: new8j@psyton.com X-Mailer: Mozilla 4.70 [en] (Win95; I) Mime-Version: 1.0 Date: Sat, 11 Mar 2000 23:36:31 -0500 Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200003120643143.SM00176@kllklk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nighthawk.psyton.com id AAA02706 Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 8bit FREE E-COMMERCE WHEN YOU HOST WITH US!! Tired of expensive e-commerce software, set up fees and leasing contracts? Here is the deal: You host your site with us and you get free E -Commerce, including a merchant account, real-time software and shopping cart. NO ONE CAN BEAT OUR PRICE! IF YOU FIND A BETTER DEAL FOR OUR PACKAGE ANYWHERE ELSE, WE WILL MATCH OUR COMPETITOR'S PRICE PLUS GIVE YOU THE FIRST MONTH FOR FREE. While others charge you hundreds of dollars to get a merchant account or put you on a 48 months non-cancelable lease agreement we charge you NOTHING for E-commerce when you sign up for our e-commerce hosting plan. If you wish to stay with your current hosting company you still can get the same deal. Check it out first and make an informed decision. You have never seen a package deal like this before: * Your own merchant account with one of the lowest rates in the industry * Real-Time software to accept VISA, MASTERCARD, AMEX, DISCOVER/NOVUS, DINERSCLUB/CARTE BLANCHE, JCB * Direct deposit within 48 hrs into your checking account * Shopping Cart store front software with an easy to use web based interface * Real-Time Credit Card Processing software * Virtual terminal for phone/fax/mail orders * Automated E-mail receipts to your clients * Recurring billing feature with batch uploads * Password generator for membership sites * Automatic batch closing * Address verification system (AVS) * Back office to 24/7 access account history * 50 MB (megabytes) of disk space * 30 GB (gigabyte) of data transfer per month * 25 POP3 E-mail accounts * Unlimited alias E-mail addresses * Live web site statistics * Unlimited FTP uploads * Anonymous FTP * CGI directory for your own scripts * Site control panel * Installation included * Tech support included All this and more when you sign up for our E-Commerce Hosting plan for ONLY $69.95 per month and a one time set up fee of $199.00. That 's right. NO ADDITIONAL SET UP FEES or application fees for your merchant account real-time software or shopping cart storefront. A one-stop E-Commerce solution. And the best is: NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME. THIS PRICE APPLIES TO U.S. BASED COMPANIES OR INDIVIDUALS ONLY! BUT WE ALSO HAVE A SOLUTION FOR INTERNATIONAL MERCHANTS! Please reply to: mailto:wrkv@pplmail.com?subject=INFO-PLEASE to receive our FREE information package without obligations. ********************************************************* Remove at mailto:kwwk@uymail.com?subject=remove ********************************************************* From owner-gsmp@psyton.com Tue Mar 14 08:45:09 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15459 for ; Tue, 14 Mar 2000 08:45:04 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id IAA10272 for gsmp-list; Tue, 14 Mar 2000 08:24:05 -0500 Received: from apocalypse.org (IDENT:root@apocalypse.org [192.48.232.17]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id IAA10269 for ; Tue, 14 Mar 2000 08:24:05 -0500 Received: from localhost (avri@localhost) by apocalypse.org (8.9.3/8.9.3) with ESMTP id IAA20032 for ; Tue, 14 Mar 2000 08:22:43 -0500 Date: Tue, 14 Mar 2000 08:22:43 -0500 (EST) From: ad To: gsmp@psyton.com Subject: [Internet-Drafts@ietf.org] (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the General Switch Management Protocol Working Group of the IETF. Title : Definitions of Managed Objects for the General Switch Management Protocol (GSMP) Author(s) : H. Sjostrand, J. Burke, B. Srinivasan Filename : draft-ietf-gsmp-mib-01.txt Pages : 21 Date : 13-Mar-00 This memo defines a portion of the Management Information Base (MIB)for use with network management protocols in the Internet community. In particular, it describes managed objects for the General Switch Management Protocol (GSMP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-gsmp-mib-01.txt 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-gsmp-mib-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-gsmp-mib-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: <20000313135304.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-gsmp-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-gsmp-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000313135304.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-gsmp@psyton.com Tue Mar 14 08:45:19 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15543 for ; Tue, 14 Mar 2000 08:45:18 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id IAA10261 for gsmp-list; Tue, 14 Mar 2000 08:22:04 -0500 Received: from apocalypse.org (IDENT:root@apocalypse.org [192.48.232.17]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id IAA10258 for ; Tue, 14 Mar 2000 08:22:03 -0500 Received: from localhost (avri@localhost) by apocalypse.org (8.9.3/8.9.3) with ESMTP id IAA19548 for ; Tue, 14 Mar 2000 08:20:38 -0500 Date: Tue, 14 Mar 2000 08:20:38 -0500 (EST) From: ad To: gsmp@psyton.com Subject: [Internet-Drafts@ietf.org] (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the General Switch Management Protocol Working Group of the IETF. Title : General Switch Management Protocol Author(s) : A. Doria, F. Hellstrand, K. Sundell, T. Worster Filename : draft-ietf-gsmp-04.txt Pages : 149 Date : 13-Mar-00 This memo provides the fourth draft of the standards track specification of GSMP. It is a revision of draft-worster-gsmp-00 which itself was based on GSMP V2 [7]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-gsmp-04.txt 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-gsmp-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-gsmp-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: <20000313135315.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-gsmp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-gsmp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000313135315.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-gsmp@psyton.com Tue Mar 14 13:57:44 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20625 for ; Tue, 14 Mar 2000 13:57:41 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id NAA11223 for gsmp-list; Tue, 14 Mar 2000 13:36:49 -0500 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id NAA11220 for ; Tue, 14 Mar 2000 13:36:44 -0500 From: avri.doria@nokia.com Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id UAB23542 for ; Tue, 14 Mar 2000 20:36:42 +0200 (EET) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id UAA28638 for ; Tue, 14 Mar 2000 20:36:41 +0200 (EET) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <1RMJAF52>; Tue, 14 Mar 2000 12:35:43 -0600 Message-ID: To: gsmp@psyton.com Subject: Proposed Agenda for IETF47 - GSMP WG Date: Tue, 14 Mar 2000 12:34:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Hi Folks, Friday is the deadline for the agenda. This is the proposed agenda. While there is always time to change it before the meeting, I would appreciate any comments folks might have at the moment. 1. Review of draft-ietf-gsmp-04 2. Review of draft-ietf-gsmp-mib-01 3. Review of draft-ietf-gsmp-applicability-00 4. Security issues in draft-ietf-gsmp-encaps-00 5. Implementation Experience 6. Discussion of charter update 7. Requirements for GSMP support of Optical switching 8. Future Requirements for GSMP Regarding Item 5: I know that several teams are working on implementations. What I don't know is who is attending the meeting. What I would like to suggest is that anyone working on an implementation and who is planning to attend do a short, 5 minute max, presentation on their work. For anyone not attending, I encourage you to participate anyway. I am willing to present several slides from anyone who has anything to say about their implementation efforts. Please get in touch with me directly if interested. Regarding Item 8: Although informal, I suggest that anyone who has a concrete proposal on work that needs to be done, prepare a short, 5 minute maximum, presentation on their requirements. Please let me or Kenneth know about your intention to present requirements before the meeting. Regards, a. ----------------------------------- avri doria Office: +1 781 993 4645 Mobile: +1 781 308 7680 From owner-gsmp@psyton.com Wed Mar 15 10:50:33 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17589 for ; Wed, 15 Mar 2000 10:50:26 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id KAA14107 for gsmp-list; Wed, 15 Mar 2000 10:31:00 -0500 Received: from thefsb.org (216-59-34-200.usa.flashcom.net [216.59.34.200]) by nighthawk.psyton.com (8.9.0/8.9.0) with SMTP id KAA14104 for ; Wed, 15 Mar 2000 10:30:46 -0500 Date: Wed, 15 Mar 2000 10:30:46 -0500 From: fsb@thefsb.org Message-Id: <200003151530.KAA14104@nighthawk.psyton.com> Received: (qmail 3309 invoked from network); 15 Mar 2000 15:29:00 -0000 Received: from localhost (HELO thefsb.org) (127.0.0.1) by localhost with SMTP; 15 Mar 2000 15:29:00 -0000 Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: gsmp@psyton.com Subject: adelaide hyatt X-Mailer: acmemail Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com fyi: i just freed up a room. nice one too. http://ietf.org/meetings/hotels_47.html#Hyatt c u fsb From owner-gsmp@psyton.com Thu Mar 16 16:57:54 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07598 for ; Thu, 16 Mar 2000 16:57:49 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id QAA18737 for gsmp-list; Thu, 16 Mar 2000 16:31:56 -0500 Received: from apocalypse.org (IDENT:root@apocalypse.org [192.48.232.17]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id QAA18734 for ; Thu, 16 Mar 2000 16:31:55 -0500 Received: from localhost (avri@localhost) by apocalypse.org (8.9.3/8.9.3) with ESMTP id QAA04765 for ; Thu, 16 Mar 2000 16:30:16 -0500 Date: Thu, 16 Mar 2000 16:30:16 -0500 (EST) From: ad To: gsmp@psyton.com Subject: I-D ACTION:draft-ietf-gsmp-applicability-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the General Switch Management Protocol Working Group of the IETF. Title : General Switch Management Protocol Applicability Author(s) : A. Doria, K. Sundell Filename : draft-ietf-gsmp-applicability-00.txt Pages : 10 Date : 15-Mar-00 This memo provides an overview of the GSMP protocol and includes information relating to its deployment in a MPLS environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-gsmp-applicability-00.txt 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-gsmp-applicability-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-gsmp-applicability-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: <20000315132212.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-gsmp-applicability-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-gsmp-applicability-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000315132212.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-gsmp@psyton.com Tue Mar 21 09:52:26 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09830 for ; Tue, 21 Mar 2000 09:52:22 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id JAA01553 for gsmp-list; Tue, 21 Mar 2000 09:25:16 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id JAA01543 for ; Tue, 21 Mar 2000 09:24:00 -0500 From: avri.doria@nokia.com Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id QAA16574 for ; Tue, 21 Mar 2000 16:23:51 +0200 (EET) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id QAA07911 for ; Tue, 21 Mar 2000 16:23:42 +0200 (EET) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <1RMJBBSG>; Tue, 21 Mar 2000 08:22:40 -0600 Message-ID: To: gsmp@psyton.com Subject: draft-doria-gsmp-req-olsr-00.txt Date: Tue, 21 Mar 2000 08:21:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Hi, This draft was not submitted in time for the I-D publishing deadline: Requirements for adding Optical Switch Support to GSMP I have put it into: http://www.apocalypse.org/pub/~avri/ietf47/draft-doria-gsmp-req-olsr-00.txt While I was at it, I put copies of the other relevant drafts for this session in that same directory. Apologies for being late with this one. a. ----------------------------------- avri doria Office: +1 781 993 4645 Mobile: +1 781 308 7680 From owner-gsmp@psyton.com Tue Mar 21 10:35:53 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26119 for ; Tue, 21 Mar 2000 10:35:51 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id KAA01844 for gsmp-list; Tue, 21 Mar 2000 10:22:34 -0500 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id KAA01841 for ; Tue, 21 Mar 2000 10:22:34 -0500 Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id QAA06069 for ; Tue, 21 Mar 2000 16:22:14 +0100 (MET) Received: from etx.ericsson.se (avpc66.etxb.ericsson.se [130.100.27.66]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0FRS00MCU2OAAY@mbb1.ericsson.se> for gsmp@psyton.com; Tue, 21 Mar 2000 16:21:46 +0100 (MET) Date: Tue, 21 Mar 2000 16:21:30 +0100 From: Hans =?iso-8859-1?Q?Sj=F6strand?= Subject: Re: draft-doria-gsmp-req-olsr-00.txt To: gsmp@psyton.com, avri.doria@nokia.com Message-id: <38D7937A.425D5F5@etx.ericsson.se> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win95; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit hi Avri, It url wasn't working for me, but I found it under http://www.apocalypse.org/pub/u/avri/ietf47/draft-doria-gsmp-req-olsr-00.txt regards /// Hasse avri.doria@nokia.com wrote: > > Hi, > > This draft was not submitted in time for > the I-D publishing deadline: > > Requirements for adding Optical Switch Support to GSMP > > I have put it into: > > http://www.apocalypse.org/pub/~avri/ietf47/draft-doria-gsmp-req-olsr-00.txt > > While I was at it, I put copies of the other relevant drafts for this > session in that same directory. > > Apologies for being late with this one. > > a. > ----------------------------------- > avri doria > Office: +1 781 993 4645 > Mobile: +1 781 308 7680 > From owner-gsmp@psyton.com Tue Mar 21 16:25:54 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07336 for ; Tue, 21 Mar 2000 16:25:53 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id QAA02817 for gsmp-list; Tue, 21 Mar 2000 16:10:47 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id QAA02814 for ; Tue, 21 Mar 2000 16:10:44 -0500 From: avri.doria@nokia.com Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id XAA25658 for ; Tue, 21 Mar 2000 23:10:42 +0200 (EET) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id XAA11327 for ; Tue, 21 Mar 2000 23:10:41 +0200 (EET) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Tue, 21 Mar 2000 15:10:40 -0600 Message-ID: To: gsmp@psyton.com Subject: correct link for missing draft Date: Tue, 21 Mar 2000 15:08:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com hi, i sort of muddled the link to my own site :-( it is either http://www.apocalypse.org/~avri/ietf47/draft-doria-gsmp-req-olsr-00.txt or http://www.apocalypse.org/pub/u/avri/ietf47/draft-doria-gsmp-req-olsr-00.txt & http://www.apocalypse.org/~avri/ietf47/ or http://www.apocalypse.org/pub/u/avri/ietf47/ but not the mixed ones i originally sent. apologies to those i confused or frustrated. regards, a. ----------------------------------- avri doria Office: +1 781 993 4645 Mobile: +1 781 308 7680