Subject: last call comments

From: "tom worster" <[email-masked]>
Date: Fri, 18 Aug 2000 18:38:07 -0400

"and now the votes from the scottish jury. norway -- nul 
points..."

c u
fsb

gsmp spec:

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)

pg6pa7: external -> externally?

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

pg13pa1: TLV abbreviation not explained.

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.

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.

pg16: under Label Length suggest: "A 16 bit field indicating
the length of the Lavel Value field in bytes." ...

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."

pg17: there is an unspecified field to the left of Res under
fr labels. sould also be Res?

pg17: there is an unspecified field to the left of MPLS
label under mpls labels. should be Res?

pg17: fec labels. is it intended to only support one fec
element per connection? if so then the mpls support is
severly limited.

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.

pg19: under Time Slots (and in equivalent places below) the
reference to padding is superfluous if my above suggestion
for "Label Value" is used.

p22sec3.1.3.4: move to (near) the top of chapter 3.

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.

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:"

the word Model in the first row of the table appears to be
in the wrong column.

under B Flag there is a cross reference missing.

p27:

the definiton of O Flag is inadequate: i can't figure it out
from this text.

space before and after the fields picture.

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...)

3rd para: what are "64k call handling applications"?

4th para: "it is an error to use" is not standard
specification language. suggest "the R flag must not be set
if..."

5th para 1st sentence: suggest "the R flag must not be set
if either the M flag or the B flag is set."

p33 4th para: 2nd sentence: "There will..." should this be
"may"? also suggest replacing "any switch" with "certain
switches".

p34 last line: "Number of Branches field"?

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

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

p48 last line: missing period at end.

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

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

p56 under "flow control flags field": the text here (esp.
the 2nd para) is confusing and the structure of the flags
field is unclear.

section 6.2: i can't imagine what min and max labels might
mean for the structured tdm labels.

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?

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.

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.

last sentence of 2nd para after "Range Length": "..would be
able to satisfy." -> "is able..."

what happens to extant connection state when label ranges
are changed? this seems to be rather important.

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.

p87:

port types stm1 and sts3 would seem to be important here.
(already mentioned above)

"Data Fields Length" field seems triply redundant. the
function of checking the length of the fields can be
achieved using the gsmp message length.

p90 last para: "Count" -> "The total number"

p103:

1st para: space after "3.1"

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

last line: "chapter" -> "section"

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"

last two paragraphs: remove "binary"

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.

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

encaps draft:

p2:

first para: "gsmp packets" -> "gsmp messages"

last para 2nd line" "reference source not found"

p4: "Frame check seq" should be defined.

p4 1st para after "Pad": suggest "After adjacency has been
established"

p5:

in the picture the Type value 6068 looks wrong.

under "type" it says the gsmp ether type is 000c, should be
880c?

---

From: "avri" <[email-masked]>
Date: Fri, 18 Aug 2000 19:08:08 -0400

Hi,

Thank you for the detailed comments.  We will work through them in the
next few days.

One question/request:  any chance you can contribute the entry for DiffServ?
It was dropped because no one knowledgeable contributed text.   If you
understand what belongs there that would be a great help.

Thanks again,

a.

----- Original Message -----
From: "tom worster" <[email-masked]>
To: <[email-masked]>
Sent: Friday, August 18, 2000 6:38 PM
Subject: last call comments

[snip]

> hard to fill this gap. you really just need to specify a phb

[snip]