RE: Three GMPLS related IDs: draft-xu-ccamp-gmpls-sig-reorg-00.txt

[Vishal Sharma <vishal@JasmineNetworks.com>]

Folks,

This is the second in a series of three emails.

(First, a note to Bert Wijnen. I have cc'd all the three lists, since
the original request was sent on all three, and I wanted to make
people aware that this subject is under active discussion. The 
authors may now reply to only CCAMP, if they wish, since people
on other lists have at least been made aware of the ongoing discussion,
and can always access the CCAMP archives to see what's going on;
BTW, talking of CCAMP archives, unlike MPLS or IPO, 
they appear as one undifferentiated file of emails, which is 
_very difficult_ to wade through.)

-Vishal

Now on to comments:

i) Section 4. The phrase "GMPLS signaling is .... consists of a set
of messages," does not appear to be accurate, since the GMPLS signaling
draft 
draft-ietf-mpls-generalized-signaling-02.txt, does not use this terminology.
In particular, saying that they are "Create/response,
Restoration/response...
... Notification," is likely to throw people off.

ii) The document classified G-label as "optional." Is that correct?
Why would that be so?

iii) Section 5.1, starts out well, but soon meanders...

The first two make sense, even the third and fourth ones (perhaps), but
the fifth is problematic. I think some justification should also be 
given about why it makes sense for GPID to be associated with 
each signal type.

BTW, the current signaling draft (see above) _does not_ associate the
GPID with anything. The GPID, as defined, is a flat, undifferentiated
space. The code points are neither interpreted in the context of
LSP encoding type nor signal type. 
The draft [GMPLS-SIGEN] was the one that proposed dividing GPID by
LSP encoding type, and you are proposing an even finer division.

Note that I am not commenting on the appropriateness or otherwise 
of any of these proposals. I am merely asking that if the draft
proposes reasons for modification, then it should provide them so
that the reader can appreciate the logic.

iv) The example under the sixth point is not clear. The RNC has
to be interpreted together with RGT (as you yourself observe in the
preceding sentence). 
If the RGT was standard contiguous or arbitrary  contiguous
concatenation, the interpretation would be "STS-3c", if RGT was
virtual concatenation, the interpretation would be "STS-3v", if
it was bundle, the interpretation would be "3 co-routed STS-1s."
Where is the problem? 
(Zhi, don't remind me again about 3 STS-3
or 3 STS-7v, etc. :-), since, as I explained in a separate email on this
thread, they cannot be signaled in one shot using
the definitions in the current signaling draft [GMPLS-SIG].)

v) Section 5.2. The Signal Type now incorporates the RNC and RGT of 
GMPLS-SIG. Again, it is not clear why this was necessary or desirable?
No adequate justification seems to have been provided for this choice.

One major problem with doing what you have done is that this leaves no
possibility to accomplish reason one in your "Reasons for Modification."
Namely, you cannot now have a generalized label that spans packet, TDM,
WDM, fiber, etc. (Perhaps you have have one that spans the optical
technologies,
but is that good enough?)

RGT and RNT are general concepts that are probably generalizable in a way
that each layer in a layered network can use them, so why throw away that
possibility by intertwining everything within "signal type"?

**(Note that even GMPLS-SIG does not truly have a generalized label, since
it proposes a "generalized label" and then again an "SDH/SONET label"!
However, I see no good technical or architectural reason for why that
needs to be the case. Indeed, GMPLS-SIGEN
states very eloquently why having a single label format makes a lot of
sense, and, as Yuanggang calls it, "puts the G in GMPLS".) **

vi) Section 5.2, the "Directionality" bits say "Indicates the direction
of the LSP," ... with respect to what? If the intent is to clarify/enhance
things, the explanation needs to be much clearer.

vii) The "Service Type" bits seem to have absorbed what in GMPLS-SIGEN
was the Link Protection Flags, and what in GMPLS-SIG is the Protection
TLV. If that is so, this needs to be explicitly stated somewhere.
This also is problematic. What if a service provider wants to provide
a service that is independent of the underlying protection? Or is protection
deemed to be an integral part of every/any service?
Again, doesn't appear very clear.

viii) The firs sentence in Section 6 should probably be modified to
"Current ER Object/TLV ... Logical Link (bundle) granularity, by
introducing a logical interface ID object."

ix) A confusion with Section 6 is, which ER object are you talking about??
Which draft or drafts are you referring to?? I think it would be much easier
on the reader, if at specific points this draft provides references to the
particular one of the three drafts ([GMPLS-SIGEN], [GMPLS-SIG], or
[GMPLS-ARCH])
that discusses the topic at hand.

x) Section 7.1.2. As in the GMPLS-ARCH draft, this section is very unclear.
It does not adequately explain what is happening, nor does it provide the
reader a view of why a hierarchical label is needed or makes sense?

The last sentence says "The hierarchical label ... at the stack bottom."
Why not show it with an example?

The sentence above that says, "Hierarchical format is a more generic form."
Than what?? Than having a single label? Why? How does it work? What is
the use? The reader is left wondering ...

xii)The last sentence in Section 7.2.1 says
"The Channel ID structure is ... and defined in [GMPLS-SIG] and
[GMPLS-SIGEN]."
Where?? 

This is very^2 confusing, since these two drafts do not use the same
terminology as the current draft. The draft should either clearly point out
where these drafts define something akin to the channel ID, or say what
these drafts call this beast, so that the reader is not left confused
and bewildered!!

(BTW, I hate the practice that we seem to have gotten into recently of
having
a plethora of drafts, with each covering a small morsel of the total
picture,
and then referring to each other, at crucial junctures in the drafts. This
leads the reader/implementer on a wild goose chase, and makes the drafts
quite incomprehensible!)

xiii)I think it has been already pointed out that Suggested Label and
Label Set are not, in fact, mutually exclusive. I may have a label set,
and from _within_ that set suggest a specific label to my neighboring node.
Thus,
both could be simultaneously present.
Hence, the assumption in Section 8.1 and the corresponding reason for
creating the suggested label set, are incorrect.

xiv) Section 8.2, pp. 9, last sentence under "Action: 8 bits" is 
unclear. If the transmit and receive labels are adjacent, how will
they be distinguished. Where and how will their placement have been
negotiated?

xv) Section 8.2, under G-label, "Specifies a label without an 
_object wrapper_" What is that?? Some explanation needed.

xvi)Finally, the reference to [GLABEL-REQ] at the end is wrong
and incomplete. Unless this is a new draft, I think what was meant
here was draft-lin-ccamp-ipo-common-label-request-00.txt. Also,
it is a good practice to give the complete title of the draft
"draft-lin ...." to make it easier for the reader to locate it.
(Especially useful considering that the implementer is running
on a wild goose chase trying to make sense of the myriad drafts across
which useful information tidbits are spread!)