RE: Three GMPLS related IDs: draft-xu-ccamp-gmpls-arch-intra-dom ain-00.txt

[Vishal Sharma <[e-mail]>]

Folks,

I have read quite carefully through the three drafts that you
referred to, and have the following comments them (they'll come
one by one, in three emails).

draft-xu-ccamp-gmpls-arch-intra-domain-00.txt.

This is a v. good document, and provides a good overview of the various
issues that need to be considered while architecting a control plane
for optical networks, using MPLS/IP. 

Comments:

i) On pp. 8, in the sentence "INE maintains LSP ID..." the LSP ID is
introduced in this document for the first time. Where did this come
from? Is it assumed that the document is suddenly referring to the 
LSP ID in RSVP-TE? If so, the connection needs to be made clear.
If not, some introduction is needed before mentioning it.

ii) In the same paragraph the sentences "However, it does not ...
disseminate to other nodes," is unclear. What local information
needn't exist on other NEs?

iii) In Section 5, the phrase "Several physical attributes can be
abstracted into one logical attribute," needs more elaboration, with
examples.

iv) On pp. 10, second last para, "The user traffic _connection service_
performance..." What is "connection service"? Some explanation needed.

v) On pp. 13, under "Service Negotiation," ... "A typical example is...
assignment order." What is this example saying? Seems quite unclear
how it pertains to service negotiation.

vi) On pp. 19, in the paragraph just above Section 5.3.2., you say
"This implies that a time slot map.... routing decisions." Then,
"Alternately, in the logical link ... STS-N signals." This latter
phrase is not clear. What is the "logical link" representation?

vii)In Section 5.4.1, the analogies to apply MPLS control plane
concepts to circuit switched networks are both unclear. The first
one is especially unclear, since it's not clear to the reader
what exactly you seem to be drawing a parallel between?
The second one, though better, is still not well said.

viii) Similarly, on pp. 19, you talk again of a logical link (bundle).
I think the term "logical link" needs to be explained better throughout
the text. It was quite confusing.

ix)In Section 5.4.1.2.2, you introduce "Connection ID" for the first
time. Please define it first.

x) The hierarchical label format, and its use is very _unclear_.
I think if the text intends to make a case for that, the explanation just
above the hierarchical label format needs to be much much better.

xi) In Section 5.4.1.5, pp. 25, first paragraph. The phrase starting
with "If the incoming label... NEs in parallel," is again unclear.
To whom should the label be given at request time? I think what you
mean is that the label should be allocated at request time, and the
cross-connect (that allocated that label, to be passed to its
upstream neighbor during the confirmation phase) 
should start configuring itself accordingly.

xii) Section 5.4.1.6 on LSP tunneling and label stack, should have more
explanation. How is the hierarchical label used exactly?

xiii) Again in the "Delete" operation on pp. 25, you talk of LSP ID.
Not clear where this comes from. RSVP-TE?

xiv) Section 5.4.2, says (at last!) that "LSP ID can be defined
as a source NE address + a source NE ingress label." How does a
source NE have an ingress label?

xv) The phrase immediately following the last one "An LSP has
two sets of information ...." is again unclear. Does it mean an 
LSP has two sets of info. associated with it?


xvi) Section 5.4.1.7 "A new LSP can be concatenated through ..."
What does "concatenated through" mean??

xvii) At the end of the document, I came away with the feeling that
it somehow ended abruptly. I haven't put my finger on it yet, but
that is what I felt. I almost felt that more should have been there.

xviii) A number of references don't seem to be referred to in the text.
[LSP-HIER], [IPO-FRAM], [OSPF-OMPLS], [ISIS-OMPLS].

xix) In addition, a number of documents that probably should be referenced
in this one are not referenced. For example, 

draft-bernstein-gmpls-optical-00.txt, makes many points germane to
the subject of this draft.

draft-ietf-mpls-recovery-frmwrk-02.txt, and
draft-harrison-mpls-oam-00.txt, 
also make many points relevant to the discussions in Section 5.4.3.

There exist drafts on bundling that are not mentioned here.
draft-kompella-mpls-bundle-05.txt, for instance.