Subject: response to last call comments

From: "Kenneth Sundell" <[email-masked]>
Date: Wed, 15 Nov 2000 11:29:16 +0100

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

Last Call Comments
==================

General Switch Management Protocol V3
-------------------------------------  
(draft-ietf-gsmp-06.txt)

[email-masked] - Wed, 16 Aug 2000 11:50:17 +0200

HS1.  
17-bit DLCIs should be removed.

comment: done

HS2.  
ref [5] is outdated by
http://www.isi.edu/in-notes/iana/assignments/address-family-numbers

comment: done. added to the references.

HS3.  
pdftotext sometimes misinterprets - for ¡ Don't ask me why, but
do a search replace on those.

comment: done.

Jaroslaw Sydir <[email-masked]> - Thu, 17 Aug 2000 23:12:05 -0700

JSY1.  
In section 3.1.1 in the description of Result,  the word
"State" is spelled "Sate"

comment: done

JSY2.  
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.  
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.  
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.  
In section 7.3 the line "x: Unused" can probably be deleted.

comment: done

JSY6.  
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.  
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 <[email-masked]> - Fri, 18 Aug 2000 13:24:44 -0700

JSY8.  
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" <[email-masked]> - Fri, 18 Aug
 2000 14:14:27 -0700

HK1.  
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 <[email-masked]> - Fri, 18 Aug 2000 18:38:07 -0400

TW1.  
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.  
pg6pa7: external -> externally?

comment: done

TW3.  
pg12: under "Length" text is a little imprecise. suggest:
"Length of the GSMP message including its header fields."

comment: done

TW4.  
pg13pa1: TLV abbreviation not explained.

comment: done. clarifying text added.

TW5.  
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.  
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.  
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.  
pg17: there is an unspecified field to the left of Res under fr
labels. sould also be Res?   

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.  
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.  
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.  
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.  
p22sec 3.1.3.4: move to (near) the top of chapter 3.

comment: done. the chapter is moved.

TW14.  
p25 last para (and throughout the spec): the "IQS/OQS="
terminology is unclear. does the / mean AND or OR or DIVIDE? if it's
AND then i suggest "IQS=x and OQS=x" etc.

comment: done, should be OR.

TW15.  
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.  
the word Model in the first row of the table appears to be in
the wrong column.

comment: done. the table is reformatted.

TW17.  
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.  
p27: the definiton of O Flag is inadequate: i can't figure it
out from this text.

comment: done, clarification added.

TW19.  
space before and after the fields picture.

comment: done.

TW20.  
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.  
3rd para: what are "64k call handling applications"?

comment: done, example given - emulating 64k voice switches.

TW22.  
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.  
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.  
p33 4th para: 2nd sentence: "There will..." should this be
"may"? also suggest replacing "any switch" with "certain switches".

comment: done.

TW25.  
p34 last line: "Number of Branches field"?

comment: done, text cleaned up.

TW26.  
p35 para before 4.5: "...is not implemented in..." -> "...is
not defined in..."

comment: done.

TW27.  
p46 2nd para last sentence: "...in an Add Branch..." -> "...in
a valid Add Branch..."  *

comment: done.

TW28.  
p48 last line: missing period at end.

comment: done.

TW29.  
p49 sec5.2 first para: "...of the reservation." ->
"...associated with that reservation object."

comment: done.

TW30.  
p51 1st para: first sentence mentions all the functions except
control of the "connection relace" function.

comment: done.

TW31.  
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.  
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.  
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.  
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.  
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.  
last sentence of 2nd para after "Range Length": "..would be
able to satisfy." -> "is able..."

comment: done

TW37.  
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 
remaining connection states for the previous label range.

TW38.  
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.  
p87: port types stm1 and sts3 would seem to be important
here. (already mentioned above)

comment: tdm labels are handled outside this document.

TW40.  
"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.  
p90 last para: "Count" -> "The total number"

comment: done

TW42.  
p103: 1st para: space after "3.1"   comment: done

TW43.  
next para: what is "the Service model Data field"?

comment: done

TW44.  
last line: "chapter" -> "section"

comment: done

TW45.  
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)=-n"

comment: done

TW46.  
last two paragraphs: remove "binary"

comment: done

TW47.  
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 
QoS Profile Model can be used to indicate pre-defined 
diffserv phb's. Definition of QoS profiles is outside of the scope 
of this specification.

TW48.  
i don't understand the traffic and qos parameters for circuit
em.

comment: tdm conserns are removed from the spec.

Jonathan Sadler <[email-masked]> Mon, 21 Aug 2000
10:08:39 -0500

JSA1. 
[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.  
[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.    

comment: a new draft will discuss these matters. i.e. the work is
removed from the gsmp base spec.

tom worster <[email-masked]> - Mon, 21 Aug 2000 13:03:31 -0400

TW51.  
[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.  
[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. 
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=0), request a specific partition identifier (PTYPE=1
and Partition ID != 0) or to allow the switch to chose partition
identifier (PTYPE=1 and Partition ID = 0). Correct ?

The switch entity needs to be configured to either don't allow
partitions (PTYPE=0), only to allow a specific partition identifier
(PTYPE=1 and Partition ID != 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=2 introduced. text inserted to clarify the new behaivor.

---

From: Hans Sjöstrand (ETX)<[email-masked]>
Date: Wed, 15 Nov 2000 17:03:43 +0100

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