RE: Three GMPLS related IDs: draft-lin-ccamp-ipo-common-label-req uest-00.txt

[Vishal Sharma <[e-mail]>]

Folks,

This is the last in the sequel.

-Vishal


Now on to the comments:

i) First, a nit. The draft should be named "Common Label Request
and Label Specification ...," since that is precisely the order in which
it discusses things.

ii) Also, (unless the plan was to make the wild goose chase of the
implementer
interesting!) at various points "Signaling Type" needs to be
replaced with "Signal Type." The two don't mean the same thing. :-)

iii) Section 2, Abstract. The statement describing the very first change
needs to be expanded on somewhere in the rest of the text!
It is not just a new _set_ of Signal Type structures, it is a completely
new organization of what is there in GMPLS-SIG or in GMPLS-SIGEN, and
that needs to be made very clear to the reader. The text should say
that RGT, RNT, etc. have been all absorbed into the signal type.
(Of course, it is an entirely different matter to say "why" that makes
sense,
but we'll come to that shortly.)

iv) The final "signal type" discussed in Section 3.2.3 again breaks
things into a signal type and a concatenation type. So it seems such a
break-up is needed. What would be use then of eliminating RNC in 
GMPLS-SIG?
If there is a valid technical reason for doing things this way, it should
be clearly, succintly, and unambiguously articulated. I am afraid,
in this trilogy of drafts that does not seem to have been done adequately.

v) My major problem with this and its companion draft is that it proposes
changes (some of which could even be good ones), BUT it does not provide
a detailed enough justification for all of its changes. Nor does it provide
the reader with any insight about why the encoding proposed in this draft
is a good one, a better one, an easier one, or a sensible one.

(Note: I am not implying that the remaining GMPLS drafts do a good job
of this. I am here merely pointing to the _need_ to do so, in all drafts;
in particular, in drafts that propose changing things (pl. see, for example,
draft-mack-crane-gmpls-signaling-enhancements-00.txt and 
draft-bernstein-gmpls-optical-00.txt, which at least make an attempt to do
so). This is 
especially useful to enable the community to appreciate the _technical
merits_ of each proposal and is very^2 helpful to pick the right
ones.)

A lot of the community may not instantly know all of the technicalities of
SONET/SDH or optical technologies,
so it is all the more important to make a crystal clear _technical case_,
that
anyone can appreciate.

vi) So why does it make sense to combine RGT and RNT and transparency,
and signal type all into "signal type"?
Why is that more helpful/better/cleaner than a form of encoding that treats
these 
as separate entities?

-- If we resort to one big coding space for signal types, it would be
difficult
to add more as more signal types come in, since all combinations of those
signal types with RGT and RNC will have to be added. 

-- Further, what if an RNC or RGT option changes tomorrow? Now, we'd have 
to expand all existing signal types! If things were broken up, only the RGT 
or RNT codepoints would change.

vii) The encoding of signal types in Section 3.2.4 allows for two
ways to specify an STS-1, using value 5,  X=0 or value 7, X=1. 
Was this intended?

viii) Section 3.2.4, in the values for virtual concatenation (10-15), why
does
the draft stop at STS-3c-Xv? What about STS-12c-Xv, or higher?

ix)Similarly, in the values for co-routed groups (23-27), why stop at
STS-3c-X? What about STS-12c-X or higher?

x) Page 8, para 3, the number of vendor specific codepoints is 12
it seems, not 13.

xi) Section 4.2, the document spends many paragraphs trying to make
a case apparently for why HOVC and LOVC labels are independent, and 
should have dedicated channel IDs. However, I cannot see how this
follows from any of the preceding explanations. After a lot
of words, the reader is suddenly confronted with the blanket
statement " Therefore, HOVC.... labels. Each one will have a 
dedicated channel ID."

xii) Again, in Section 4.2, the notation for the sub-STM-0/STM-1 
signals is never introduced, even briefly. It is just thrown at
the reader. Where does that come from? What is the background?
The reader has no clue...

xiii) In the same section, para 6, the last sentence says "At any
moment, the complete aggregation bandwidth's multiplex structure
must be defined to prevent alarms to be raised." Uh?! Say what?

xiv) Section 4.2.3, please ... at least give an explanation of the
notation used in the title, in plain English, somewhere. (Not everyone
is an SDH/SONET expert, for crying out loud!)

xv) Again, maybe I am missing something, but how does the current
encoding allow to encode a signal like
3 STS-3? or 7 STS-3c-Xv?
Or doesn't it?

xvi) Also, it would be useful for the document to give references
to all the G.707, G.708, etc. documents that it refers to throughout,
together with pointers to how they may be obtained.
(Let's make people's life a little bit easier, let's at least help them
read, understand, and look at our drafts critically, instead of having
them put the drafts aside in a huge pile, never to be read.)