From owner-gsmp@psyton.com Wed Nov 1 05:01:42 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA11285 for ; Wed, 1 Nov 2000 05:01:42 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id eA19pNW08425 for gsmp-list; Wed, 1 Nov 2000 04:51:23 -0500 Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id eA19pMk08422 for ; Wed, 1 Nov 2000 04:51:22 -0500 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Wed, 1 Nov 2000 09:49:54 +0000 Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) by zhard00m.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VWD1W6KV; Wed, 1 Nov 2000 09:49:50 -0000 Received: from europem01.nt.com (KSUNDELL [141.251.192.238]) by zvb1c002.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VGPW21S0; Wed, 1 Nov 2000 10:49:51 +0100 Message-ID: <39FFE77D.11E06F99@europem01.nt.com> Date: Wed, 01 Nov 2000 10:50:53 +0100 X-Sybari-Space: 00000000 00000000 00000000 From: "Kenneth Sundell" X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: gsmp-list CC: "Avri Doria" Subject: GSMP WG meeting in San Diego 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 folks, we have got a two hour slot assigned for the upcoming ietf meeting (thursday, dec 14, 1300-1500) so please forward any agenda items to me and Avri. regards, ken From owner-gsmp@psyton.com Sat Nov 11 11:23:06 2000 Received: from nighthawk.psyton.com (IDENT:root@[24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20796 for ; Sat, 11 Nov 2000 11:23:06 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id eABGAP921846 for gsmp-list; Sat, 11 Nov 2000 11:10:25 -0500 Received: from apocalypse.org (IDENT:root@apocalypse.org [192.48.232.17]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id eABGANT21843 for ; Sat, 11 Nov 2000 11:10:23 -0500 Received: from localhost (avri@localhost) by apocalypse.org (8.9.3/8.9.3) with ESMTP id LAA20809 for ; Sat, 11 Nov 2000 11:10:17 -0500 Date: Sat, 11 Nov 2000 11:10:16 -0500 (EST) From: ad To: gsmp@psyton.com Subject: I-D ACTION:draft-ietf-gsmp-encaps-03.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 : GSMP Packet Encapsulations for ATM, Ethernet and TCP > Author(s) : T. Worster, A. Doria, J. Buerkle > Filename : draft-ietf-gsmp-encaps-03.txt > Pages : 8 > Date : 08-Nov-00 > > This memo specifies the encapsulation of GSMP packets in ATM, > Ethernet and TCP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-gsmp-encaps-03.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-encaps-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-gsmp-encaps-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > --NextPart > Content-Type: Multipart/Alternative; Boundary="OtherAccess" > > --OtherAccess > Content-Type: Message/External-body; > access-type="mail-server"; > server="mailserv@ietf.org" > > Content-Type: text/plain > Content-ID: <20001108122024.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-gsmp-encaps-03.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-ietf-gsmp-encaps-03.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <20001108122024.I-D@ietf.org> > > --OtherAccess-- > > --NextPart-- > > From owner-gsmp@psyton.com Mon Nov 13 11:06:43 2000 Received: from nighthawk.psyton.com (psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07902 for ; Mon, 13 Nov 2000 11:06:33 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id eADFVHh02033 for gsmp-list; Mon, 13 Nov 2000 10:31:17 -0500 Received: from apocalypse.org (IDENT:root@apocalypse.org [192.48.232.17]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id eADFVGa02030 for ; Mon, 13 Nov 2000 10:31:16 -0500 Received: from localhost (avri@localhost) by apocalypse.org (8.9.3/8.9.3) with ESMTP id KAA01009 for ; Mon, 13 Nov 2000 10:31:13 -0500 Date: Mon, 13 Nov 2000 10:31:13 -0500 (EST) From: ad To: gsmp@psyton.com Subject: I-D ACTION:draft-ietf-gsmp-07.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 V3 Author(s) : A. Doria, F. Hellstrand, K. Sundell, T. Worster Filename : draft-ietf-gsmp-07.txt Pages : 141 Date : 10-Nov-00 The General Switch Management Protocol (GSMP), is a general purpose protocol to control a label switch. GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a multicast connection; manage switch ports; request configuration information; request and delete reservation of switch resources; and request statistics. It also allows the switch to inform the controller of asynchronous events such as a link going down. The GSMP protocol is asymmetric, the controller being the master and the switch being the slave. Multiple switches may be controlled by a single controller using multiple instantiations of the protocol over separate control connections. Also a switch may be controlled by more than one controller by using the technique of partitioning. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-gsmp-07.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-07.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-07.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: <20001110102702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-gsmp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-gsmp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001110102702.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-gsmp@psyton.com Tue Nov 14 08:00:29 2000 Received: from nighthawk.psyton.com (psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06792 for ; Tue, 14 Nov 2000 08:00:28 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id eAECZF705057 for gsmp-list; Tue, 14 Nov 2000 07:35:15 -0500 Received: from apocalypse.org (IDENT:root@apocalypse.org [192.48.232.17]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id eAECZEa05054 for ; Tue, 14 Nov 2000 07:35:14 -0500 Received: from localhost (avri@localhost) by apocalypse.org (8.9.3/8.9.3) with ESMTP id HAA12175 for ; Tue, 14 Nov 2000 07:35:06 -0500 Date: Tue, 14 Nov 2000 07:35:05 -0500 (EST) From: ad To: gsmp@psyton.com Subject: I-D ACTION:draft-ietf-gsmp-mib-03.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 : Definitions of Managed Objects for the General Switch Management Protocol (GSMP) Author(s) : H. Sjostrand, J. Buerkle, B. Srinivasan Filename : draft-ietf-gsmp-mib-03.txt Pages : 44 Date : 13-Nov-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-03.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-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-gsmp-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001113134550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-gsmp-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-gsmp-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001113134550.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-gsmp@psyton.com Wed Nov 15 06:03:54 2000 Received: from nighthawk.psyton.com (psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15297 for ; Wed, 15 Nov 2000 06:03:54 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id eAFATCG08260 for gsmp-list; Wed, 15 Nov 2000 05:29:12 -0500 Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id eAFAT9a08257 for ; Wed, 15 Nov 2000 05:29:09 -0500 Received: from znsgd00t.europe.nortel.com (actually znsgd00t) by qhars002.nortel.com; Wed, 15 Nov 2000 10:27:42 +0000 Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) by znsgd00t.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id WS4L2X79; Wed, 15 Nov 2000 10:27:41 -0000 Received: from europem01.nt.com (KSUNDELL [141.251.192.231]) by zvb1c002.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id WMR6FPF6; Wed, 15 Nov 2000 11:27:39 +0100 Message-ID: <3A12657C.B87577E8@europem01.nt.com> Date: Wed, 15 Nov 2000 11:29:16 +0100 X-Sybari-Space: 00000000 00000000 00000000 From: "Kenneth Sundell" X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: gsmp-list Subject: response to last call comments Content-Type: multipart/mixed; boundary="------------7EFD11208077836EAB936EA7" Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com This is a multi-part message in MIME format. --------------7EFD11208077836EAB936EA7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi, we have gone through all the last call comments (on draft-ietf-gsmp-06.txt) received on the gsmp mailing list. the responses to these last call comments are attached below. the updated version draft-ietf-gsmp-07.txt is already distributed but we found a comment (tw37) that was not solved in the -07 version, so a new version (draft-ietf-gsmp-08.txt) was submitted yesterday and will show up shortly. cheers, ken and avri --------------7EFD11208077836EAB936EA7 Content-Type: text/plain; charset=iso-8859-1; name="gsmp_spec_lc_comments.txt" Content-Disposition: inline; filename="gsmp_spec_lc_comments.txt" X-MIME-Autoconverted: from 8bit to quoted-printable by nighthawk.psyton.com id eAFATCG08260 Content-Transfer-Encoding: quoted-printable Last Call Comments =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D General Switch Management Protocol V3 ------------------------------------- =20 (draft-ietf-gsmp-06.txt) Hans.Sjostrand@etx.ericsson.se - Wed, 16 Aug 2000 11:50:17 +0200 HS1. =20 17-bit DLCIs should be removed. comment: done HS2. =20 ref [5] is outdated by http://www.isi.edu/in-notes/iana/assignments/address-family-numbers comment: done. added to the references. HS3. =20 pdftotext sometimes misinterprets - for =A1 Don't ask me why, but do a search replace on those. comment: done. Jaroslaw Sydir - Thu, 17 Aug 2000 23:12:05 -0700 JSY1. =20 In section 3.1.1 in the description of Result, the word "State" is spelled "Sate" comment: done JSY2. =20 In section 4.1 in the description of the O flag, the description should read "The opaque flag indicates whether the adaptation FIELD is opaque..." comment: done JSY3. =20 In section 6.1 in the description of the Reset Input Port field, the statement "All connections that arrive at the specified input port" is misleading in that "arrive" implies dynamic behavior that is not intended. It would read better if the word "arrive" is replaced with "originate". comment: done. arrive replaced with originate. JSY4. =20 In section 7.1 in the description of the TC Block Length the word "field" is mistyped (it is "filed" in the text). comment: done JSY5. =20 In section 7.3 the line "x: Unused" can probably be deleted. comment: done JSY6. =20 In section 8.1 in the description of MType in the list of mtypes, the first two line have funky characters instead of dashes. comment: done (in -08 version) JSY7. =20 The response to the Statistics Messages include cell count fields which are specific to ATM. This breaks with the rest of the document where technology specific field are identified as such. Is it the case that for a non ATM port these fields are not used? If so this should be stated in the document. comment: Text is added in order to clarify. Jaroslaw Sydir - Fri, 18 Aug 2000 13:24:44 -0700 JSY8. =20 I have a comment concerning document organization of the GSMP spec. The GSMP document combines the definitions of the generic and technology-dependent parts of the protocol. Besides making the spec very large, this means that either, the spec gets revised every time that GSMP is applied to a new technology, or that some technologies are dealt with in the main spec and some are dealt with in addendums. This would probably be more manageable if the spec dealt only with the generic parts and there were separate documents for each of the technologies. This is basically an editorial change, albeit a big one. comment: judging by the responses to this on the gsmp list, we have decided not to do this in the current version of gsmp. "Khosravi, Hormuzd M" - Fri, 18 Aug 2000 14:14:27 -0700 HK1. =20 I had a very similar comment on the GSMP spec. I was wondering if the Service Model Definition could be part of a separate draft instead of the GSMP spec. This would help reducing the size of the GSMP spec and make it easy to extend the Service Model at a later time. comment: judging by the responses to this on the gsmp list, we have decided not to do this in the current version of gsmp. tom worster - Fri, 18 Aug 2000 18:38:07 -0400 TW1. =20 general: the "specification langue" is incosistent. e.g. sometimes "must" is upper case, sometimes not and sometimes "shall" is used. i suggest including the standard paragraph defining the meanings of must and should etc. and using these terms consistently. (m$ w0rd's "search and replace" should make this job fairly easy) comment: done. text together with reference to rfc2119 added. TW2. =20 pg6pa7: external -> externally? comment: done TW3. =20 pg12: under "Length" text is a little imprecise. suggest: "Length of the GSMP message including its header fields." comment: done TW4. =20 pg13pa1: TLV abbreviation not explained. comment: done. clarifying text added. TW5. =20 pg14: under "frame relay labels," fields "Res" and "x" are not explained. suggest moving 3.1.3.4 to the top of this section. also in the spec both "unused" and "reserved" are used. what is the difference. perhaps its better to use only one version. and since "x" and "reserved" are defined here we can remove the subsequent definitions of fields marked thus throught the spec. comment: done. 3.1.3.4 moved. res replaced with x where appropriate. TW6. =20 pg15: tlv labels for atm, fr and mpls. i don't think it makes sense to support two different encodings for these labels. this poses a complexity burden on the spec and on implementations and doesn't seem to have any associated benefit. if there is a need for two different encodings then it is not apparent. as far as i can see, none of the label types supported have variable length value (i.e. the v in tlv) fields so is seems unnecessary to distinguish between short and tlv labels. and since the length field is redundant, a uniform label encoding using type discriminators would appear to suffice. so i think we should go for: 1) only tlv labels, or 2) a uniform encoding without a length field, or 3) drop the tlv versions of atm, fr and mpls. comment: done, suggestion 1) used. comment: done, suggstion 1) used, all labels are now tlv encoded. TW7. =20 pg16: under Label Length suggest: "A 16 bit field indicating the length of the Lavel Value field in bytes." ... comment: done after that the Label Value field should be described, e.g. " Label Value (new para) A variable length field that is an integer number of 32 bit words long. The value field is interpreted according to the Label Type as described in the following sections." comment: done. TW8. =20 pg17: there is an unspecified field to the left of Res under fr labels. sould also be Res? =20 comment: done, the res field is part of the fr label field (as defined in the mpls/fr draft). x's are added to indicate that the bits in front of the fr label are unused. TW9. =20 pg17: there is an unspecified field to the left of MPLS label under mpls labels. should be Res? comment: x's are added to indicate that the bits left of the mpls label is unused. TW10. pg17: fec labels. is it intended to only support one fec element per connection? if so then the mpls support is severly limited. comment: done. added support for multiple fec elements. TW11. =20 pg18 and throughout the spec: the ds3/e3/... labels are inadequately defined. it is completely unclear to me what a channel id is and i cannot understand how the time slots field is encoded. it seems that reference must be made to the sandards that specify the multiplex structure of these signals and the semantics of the fields specified in the gsmp be related unambiguously to those standards. also, since we are doing channelised ds1, ds3 etc it seems only reasonable to also do channelised sts3 and stm1. the deployment of channelised sts3 and stm1 in access networks is very is widespread and increasing rapidly. comment: tdm labels are removed from the spec, these will be handled in separate document. TW12. =20 pg19: under Time Slots (and in equivalent places below) the reference to padding is superfluous if my above suggestion for "Label Value" is used. comment: tdm removed from the spec. TW13. =20 p22sec 3.1.3.4: move to (near) the top of chapter 3. comment: done. the chapter is moved. TW14. =20 p25 last para (and throughout the spec): the "IQS/OQS=3D" terminology is unclear. does the / mean AND or OR or DIVIDE? if it's AND then i suggest "IQS=3Dx and OQS=3Dx" etc. comment: done, should be OR. TW15. =20 p26: under IQS, OQS, 1st para, last sentence: suggest "The values of IQS and OQS determine respectively the interpretation of the Input Service Selector and Output Service Selector fields as shown:" comment: done. TW16. =20 the word Model in the first row of the table appears to be in the wrong column. comment: done. the table is reformatted. TW17. =20 under B Flag there is a cross reference missing. comment: the function of b-flag was removed in an earlier version of the spec so the reference was dangling. it is now removed. TW18. =20 p27: the definiton of O Flag is inadequate: i can't figure it out from this text. comment: done, clarification added. TW19. =20 space before and after the fields picture. comment: done. TW20. =20 p32: 2nd para: "clashing output branch"? elsewhere we use different text for what i think this is intended to mean. (if the label is alread...) comment: done. TW21. =20 3rd para: what are "64k call handling applications"? comment: done, example given - emulating 64k voice switches. TW22. =20 4th para: "it is an error to use" is not standard specification language. suggest "the R flag must not be set if..." comment: done. TW23. =20 5th para 1st sentence: suggest "the R flag must not be set if either the M flag or the B flag is set." comment: done. TW24. =20 p33 4th para: 2nd sentence: "There will..." should this be "may"? also suggest replacing "any switch" with "certain switches". comment: done. TW25. =20 p34 last line: "Number of Branches field"? comment: done, text cleaned up. TW26. =20 p35 para before 4.5: "...is not implemented in..." -> "...is not defined in..." comment: done. TW27. =20 p46 2nd para last sentence: "...in an Add Branch..." -> "...in a valid Add Branch..." * comment: done. TW28. =20 p48 last line: missing period at end. comment: done. TW29. =20 p49 sec5.2 first para: "...of the reservation." -> "...associated with that reservation object." comment: done. TW30. =20 p51 1st para: first sentence mentions all the functions except control of the "connection relace" function. comment: done. TW31. =20 p56 under "flow control flags field": the text here (esp. the 2nd para) is confusing and the structure of the flags field is unclear. comment: done, text cleaned up. TW32. =20 section 6.2: i can't imagine what min and max labels might mean for the structured tdm labels. comment: tdm labels are removed from the spec, these will be handled in separate document. TW33. =20 p58: D flag: the word "disjoint" means that two sets have no elements in common. isn't it more important here that the label ranges are not contiguous? comment: done. TW34. =20 what about overlapping label ranges for mpls unicast and multicast? how are these handled? the label ranges of two label spaces on one port are not disjoint in this case. comment: we believe this is implementation specific, gsmp only gives a hint that a mcast marked label range *could* be used for mcast. TW35. =20 after "Range Length" field the Min and Max Labels fields and Remaining Labels field should be defined, if only to say that they are defined below. comment: done. TW36. =20 last sentence of 2nd para after "Range Length": "..would be able to satisfy." -> "is able..." comment: done TW37. =20 what happens to extant connection state when label ranges are changed? this seems to be rather important. comment: done. a warning is added to indicate that there are=20 remaining connection states for the previous label range. TW38. =20 p84: a reference to the iee qgsmp specification must eb given. if that spec is not ready for referencing then the code point should be removed and given over to iana. comment: the qgsmp work is ongoing. new reference added to a valid working document. TW39. =20 p87: port types stm1 and sts3 would seem to be important here. (already mentioned above) comment: tdm labels are handled outside this document. TW40. =20 "Data Fields Length" field seems triply redundant. the function of checking the length of the fields can be achieved using the gsmp message length. comment: we think that the field is useful for making the parsing easier. TW41. =20 p90 last para: "Count" -> "The total number" comment: done TW42. =20 p103: 1st para: space after "3.1" comment: done TW43. =20 next para: what is "the Service model Data field"? comment: done TW44. =20 last line: "chapter" -> "section" comment: done TW45. =20 p106: under CLR: the 10exp(-n) notation could be confusing to many readers. (exp(x) is often used for e^x in physics.) suggest instead "CLR takes the value of ten raised to the power of -n, i.e. log(CLR)=3D-n" comment: done TW46. =20 last two paragraphs: remove "binary" comment: done TW47. =20 p121: i think its a serious limitation that diff-serv isn't supported. diff-serv is seeing a lot of deployment in conjunction with mpls and now with atm. it wouldn't be too hard to fill this gap. you really just need to specify a phb group for a conenction. comment: diffserv is not supported in the service model, however the=20 QoS Profile Model can be used to indicate pre-defined=20 diffserv phb's. Definition of QoS profiles is outside of the scope=20 of this specification. TW48. =20 i don't understand the traffic and qos parameters for circuit em. comment: tdm conserns are removed from the spec. Jonathan Sadler Mon, 21 Aug 2000 10:08:39 -0500 JSA1.=20 [referring to TW6.] The Generalized MPLS draft being worked on in the MPLS wg includes definition of a variable label size, as well as labels that are 32-bits in length (ie. SDH, SONET, and Optical labels -- see Sec 3.2.1) While the TLV formats for ATM and FR could be dropped, the TLV format for MPLS will be required if Generalized MPLS is to be supported. comment: all label types will use the tlv format. JSA2. =20 [referring to TW6.] It seems that some of these label formats defined in the GSMPv3 spec intersect with the label formats being defined as a part of the Generalized MPLS work. It seems the best would be to take the SONET/SDH definitions and merge them with the sub-DS1 formats proposed in GSMP v3. =20 comment: a new draft will discuss these matters. i.e. the work is removed from the gsmp base spec. tom worster - Mon, 21 Aug 2000 13:03:31 -0400 TW51. =20 [referring to JSA1.] if variable length labels are required then tlvs make sense. but with that decided we need to make up our minds if atm, fr and basic mpls labels should be encoded in tlvs or in the short format. i don't much care which but it doesn't make any sense to specify both encodings. comment: solved. tlv only TW52. =20 [referring to JSA2.] in principle that would be the best approach. but i think the timing is bad. gsmp closed last call on friday and generalised mpls signalling is new and not exactly stable. a workable compromise might be to remove the tdm labels from gsmp v3 into a separate draft, put out gsmpv3 as is and then handle the tdm-label draft according to what goes down in generalised mpls. since the label type will be ianaised there shouldn't be much difficulty. any thoughts on that approach? comment: tdm/gmpls will be handled in a separate document Hans Sjostrand wrote: HS12.=20 Even though the last call ended friday, I don't think that just having a partiton ID on the entiry is enough. The controller entity needs to be configured to either don't handle partitions (PTYPE=3D0), request a specific partition identifier (PTYPE=3D= 1 and Partition ID !=3D 0) or to allow the switch to chose partition identifier (PTYPE=3D1 and Partition ID =3D 0). Correct ? The switch entity needs to be configured to either don't allow partitions (PTYPE=3D0), only to allow a specific partition identifier (PTYPE=3D1 and Partition ID !=3D 0) and to assign partition identifier in case it's not assigned by the controller. Correct ? To configure this per entity we need to add a PTYPE to both the controller adn the switch sides. Its not possible to define this with only the gsmpVscePartitionId and gsmpVsePartitionId objects. If you agree that this is needed PTYPE objects gets added to the mib as a (last) last call comment. comment: PType=3D2 introduced. text inserted to clarify the new behaivor. =20 --------------7EFD11208077836EAB936EA7-- From owner-gsmp@psyton.com Wed Nov 15 08:01:15 2000 Received: from nighthawk.psyton.com (psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10660 for ; Wed, 15 Nov 2000 08:01:14 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id eAFCZg808513 for gsmp-list; Wed, 15 Nov 2000 07:35:42 -0500 Received: from apocalypse.org (IDENT:root@apocalypse.org [192.48.232.17]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id eAFCZga08510 for ; Wed, 15 Nov 2000 07:35:42 -0500 Received: from localhost (avri@localhost) by apocalypse.org (8.9.3/8.9.3) with ESMTP id HAA10591 for ; Wed, 15 Nov 2000 07:35:25 -0500 Date: Wed, 15 Nov 2000 07:35:25 -0500 (EST) From: ad To: gsmp@psyton.com Subject: I-D ACTION:draft-ietf-gsmp-08.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 V3 Author(s) : A. Doria, F. Hellstrand, K. Sundell, T. Worster Filename : draft-ietf-gsmp-08.txt Pages : 141 Date : 14-Nov-00 The General Switch Management Protocol (GSMP), is a general purpose protocol to control a label switch. GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a multicast connection; manage switch ports; request configuration information; request and delete reservation of switch resources; and request statistics. It also allows the switch to inform the controller of asynchronous events such as a link going down. The GSMP protocol is asymmetric, the controller being the master and the switch being the slave. Multiple switches may be controlled by a single controller using multiple instantiations of the protocol over separate control connections. Also a switch may be controlled by more than one controller by using the technique of partitioning. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-gsmp-08.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-08.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-08.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: <20001114131039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-gsmp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-gsmp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001114131039.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-gsmp@psyton.com Wed Nov 15 11:35:48 2000 Received: from nighthawk.psyton.com (psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06359 for ; Wed, 15 Nov 2000 11:35:47 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id eAFG5J208980 for gsmp-list; Wed, 15 Nov 2000 11:05:19 -0500 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id eAFG5Fa08977 for ; Wed, 15 Nov 2000 11:05:16 -0500 Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id eAFG4sZ25706 for ; Wed, 15 Nov 2000 17:04:54 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Nov 15 17:04:53 2000 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Wed, 15 Nov 2000 17:02:54 +0100 Message-ID: <21A2BDF7A29CD3118B000008C75D087302703F5C@esealnt127> From: =?ISO-8859-1?Q?Hans_Sj=F6strand_=28ETX=29?= To: "'gsmp@psyton.com'" Subject: RE: response to last call comments Date: Wed, 15 Nov 2000 17:03:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Hi, Unfortunately you won't get such a thorough list on the mib as with the base spec over the last call comments and the changes due to them. But, besides from editorial changes the following updates was made from < draft-ietf-gsmp-mib-02.txt > - Added gsmpThisSideId and gsmpFarSideId helper objects. - Replaced Ipv4 address type with TC for Internet Network Addresses - Added textual conventions for reader convenience. - Removed gsmpVsceName object and added default behaviour of gsmpVseName - Added row status objects for the encap tables. - Added DEFVAL and ranges to objects. - Persistent storage clarified - "Virtual" removed from names and concepts. gsmpVsceTable now gsmpControllerTable and gsmpVseTable is gsmpSwitchTable. - Partition Type object added. - Session state moved from Session table to Controller and Switch tables. - Removed gsmpSwitchAllowMultContr object, it's redundant. - BITS import removed. - Partition ID object added to session table. - gsmpSessionStat table merged into the gmspSessionTable. most of the comments hasn't been on the list but has been forwarded privately. I think all of them has been answered and taken care of. If you think that yuo had a coments that was treated unfare or forgotten, please let me know. Happy reading /// Hasse From owner-gsmp@psyton.com Wed Nov 15 13:47:36 2000 Received: from nighthawk.psyton.com (psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25228 for ; Wed, 15 Nov 2000 13:47:35 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id eAFI82c09314 for gsmp-list; Wed, 15 Nov 2000 13:08:02 -0500 Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id eAFI81a09311 for ; Wed, 15 Nov 2000 13:08:02 -0500 Received: from zbl6c016.corpeast.baynetworks.com (actually zbl6c016) by ertpg14e1.nortelnetworks.com; Wed, 15 Nov 2000 07:43:44 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id W8KS3ZR1; Wed, 15 Nov 2000 07:43:42 -0500 Received: from nortelnetworks.com (AVRI-1 [141.251.192.162]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VDZZF4TZ; Wed, 15 Nov 2000 07:43:41 -0500 Message-ID: <3A1284F3.A9C0826B@nortelnetworks.com> Date: Wed, 15 Nov 2000 07:43:31 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Avri Doria" Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: GSMP WG Last Call - Take 2 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 Hi, Now that all of the documents have been updated in response to the last call comments received, it is time to do another WG last call on the following documents: http://www.ietf.org/internet-drafts/draft-ietf-gsmp-08.txt http://www.ietf.org/internet-drafts/draft-ietf-gsmp-mib-03.txt http://www.ietf.org/internet-drafts/draft-ietf-gsmp-encaps-03.txt This last call should focus on the issues raised during the last WG last call. This last call is scheduled to end on: 29 November 2000 (any timezone) BTW, the draft-ietf-gsmp-appicability-01.txt is not included in this last call, since there were no substantive comments received during the 1st WG last call. Thanks avri and ken GSMP co-chairs -- Avri Doria +1 401 663 5024 From owner-gsmp@psyton.com Tue Nov 21 01:05:19 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12044 for ; Tue, 21 Nov 2000 01:05:19 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id eAL5ulE17213 for gsmp-list; Tue, 21 Nov 2000 00:56:47 -0500 Received: from zrtps06s.us.nortel.com ([47.140.48.50]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id eAL5uk617210 for ; Tue, 21 Nov 2000 00:56:47 -0500 Received: from zbl6c016.corpeast.baynetworks.com by zrtps06s.us.nortel.com; Tue, 21 Nov 2000 00:54:03 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id W8KSPDFJ; Tue, 21 Nov 2000 00:53:53 -0500 Received: from nortelnetworks.com (AVRI-1 [141.251.192.171]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id XFWJFPL4; Tue, 21 Nov 2000 00:53:57 -0500 Message-ID: <3A1A0DF0.83C834AB@nortelnetworks.com> Date: Tue, 21 Nov 2000 00:53:52 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Avri Doria" Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: WG ast call - draft-ietf-gsmp-mib-03.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Hi, We were informed by our AD that each of the documents needed an individual last call. We are therefore restarting the last call. The following document is currently in WG last call. http://www.ietf.org/internet-drafts/draft-ietf-gsmp-mib-03.txt This last call should focus on the issues raised during the last WG last call. Please send comments to the GSMP list. This last call is scheduled to end on: 5 December 2000 (any timezone) Thanks avri and ken GSMP co-chairs -- Avri Doria +1 401 663 5024 From owner-gsmp@psyton.com Tue Nov 21 01:05:29 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12099 for ; Tue, 21 Nov 2000 01:05:29 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id eAL5uin17209 for gsmp-list; Tue, 21 Nov 2000 00:56:44 -0500 Received: from zrtps06s.us.nortel.com ([47.140.48.50]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id eAL5uh617206 for ; Tue, 21 Nov 2000 00:56:43 -0500 Received: from zbl6c016.corpeast.baynetworks.com by zrtps06s.us.nortel.com; Tue, 21 Nov 2000 00:53:57 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id W8KSPDFH; Tue, 21 Nov 2000 00:52:58 -0500 Received: from nortelnetworks.com (AVRI-1 [141.251.192.171]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id XFWJFPLQ; Tue, 21 Nov 2000 00:53:02 -0500 Message-ID: <3A1A0DB8.95DBC1FD@nortelnetworks.com> Date: Tue, 21 Nov 2000 00:52:56 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Avri Doria" Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: Last Call - draft-ietf-gsmp-08.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Hi, We were informed by our AD that each of the documents needed an individual last call. We are therefore restarting the last call. The following document is currently in WG last call. http://www.ietf.org/internet-drafts/draft-ietf-gsmp-08.txt This last call should focus on the issues raised during the last WG last call. Please send comments to the GSMP list. This last call is scheduled to end on: 5 December 2000 (any timezone) Thanks avri and ken GSMP co-chairs -- Avri Doria +1 401 663 5024 From owner-gsmp@psyton.com Tue Nov 21 01:11:29 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14270 for ; Tue, 21 Nov 2000 01:11:29 -0500 (EST) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id eAL5skV17198 for gsmp-list; Tue, 21 Nov 2000 00:54:46 -0500 Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id eAL5sj617195 for ; Tue, 21 Nov 2000 00:54:45 -0500 Received: from zcard00m.ca.nortel.com by smtprch1.nortel.com; Mon, 20 Nov 2000 23:53:27 -0600 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id XDMRMYAD; Tue, 21 Nov 2000 00:53:24 -0500 Received: from nortelnetworks.com (AVRI-1 [141.251.192.171]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id XFWJFPLS; Tue, 21 Nov 2000 00:53:26 -0500 Message-ID: <3A1A0DD0.992D5DB2@nortelnetworks.com> Date: Tue, 21 Nov 2000 00:53:20 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Avri Doria" Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: WG Last Call - draft-ietf-gsmp-encaps-03.txt 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 Hi, We were informed by our AD that each of the documents needed an individual last call. We are therefore restarting the last call. The following document is currently in WG last call. http://www.ietf.org/internet-drafts/draft-ietf-gsmp-encaps-03.txt This last call should focus on the issues raised during the last WG last call. Please send comments to the GSMP list. This last call is scheduled to end on: 5 December 2000 (any timezone) Thanks avri and ken GSMP co-chairs -- Avri Doria +1 401 663 5024