Questions about GMPLS signaling and routing

[Zhi-Wei Lin <zwlin@lucent.com>]

Hi all,

Below are 7 questions/concerns I have...Looking forward to your replies! 
These questions apply basically to the set of GMPLS routing docs and to 
the GMPLS signaling docs...


----------
1. One thing that came to mind when reading these docs was how these are 
not well aligned with the GMPLS signaling discussions. For example, the 
routing documents still mix "standard" and "non-standard" features 
together (case of concatenation and arbitrary concatenation).

----------
2. The split for the "interface switching capability" doesn't seem to
make sense. For example, why are there four PSC defined? Apparently this
is the text in -ccamp-gmpls-routing-00:

    If an interface is of type PSC-1 through PSC-4, it means that the
    node receiving data over this interface can switch the received data
    on a packet-by-packet basis.  The various levels of PSC establish a
    hierarchy of LSPs tunneled within LSPs.

 From what I understand LSP hierarchy allows any number of LSPs tunneled
within LSPs. Are we limiting the level of tunneling by defining these 4?
Also there should be no difference among these four regardless of
hierarchy. I see hierarchy as layers...

If you were to define PSC as four types, then I can also state that even
for other switching capabilities, you might also have LSPs tunneled
within LSPs of those, and therefore using the same logic should define
four types for TDM, four types for L2TP, etc.

----------
3. Getting back to the switching capability type, the split of TDM
(which currenlty seems to only include SONET/SDH) and LSC does not work
well with OTN. For example, where would ODU switching belong, in TDM or
LSC?

----------
4. The the detailed docs ospf-gmpls-extensions and isis-gmpls-extensions 
and ccamp-gmpls-routing describe min and max LSP bandwidth but when 
looking at the descriptors, they only contain max LSP bandwidth info...

----------
5. Going to the ccamp-gmpls-routing doc again (sorry for jumping
around...), section 6.4.7.4 talks of two type of SONET muxing hierarchy,
one with min of VT1.5 the other with min of VT2. I don't understand this
example at all. I am assuming for both cases that there will be support
for the intermediate muxing structures between VT1.5 and STS-192 (this
is probably STS-192c?). Then for the former case, it includes VT2.
Otherwise, if certain muxing structure are skipped then better specify
each mux hierachy explicitly.

----------
6. For multi-service capable interfaces (by the way, I think switching
capability is not associated with an interface but with the node/fabric
itself. For example, an interface such as a trib card is likely limited
to what signal it supports, but anyway I digress), I think each
switching capability should be advertised as a separate "interface
switching capability descriptor". For example in section 6.4.7.5 and
6.4.7.6, you have
	interface switching capability=LSC
	encoding type=SONET ANSI T1.105 (BTW, please remove the date)
	reservable bandwidth=determined by DWDM
doesn't make sense as a combined unit. I think the encoding should be 8
(lambda).

----------
7. I can understand using the "interface switching capability
descriptor" for routing exchange information. But why has this been
added to the GMPLS signaling? It still escapes me. Can I ask who would
be strongly opposed to removing the "switching type" from GMPLS
signaling and what the impact would be that breaks this? I can think of 
a case where maybe within the network, some subnetwork may want to use a 
different "switching type" as specified by the source, e.g., because 
that's all they support, or it's more efficient to support...

Thanks

Zhi