Re: Questions about GMPLS signaling and routing

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

Hi Yakov,


>>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).
>>
> 
> Please point to the specific text in the routing documents you'd like 
> to change.
> 


Section 6.4.3


>>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?
>>
> 
> No, we are not limiting the level of tunneling by definining these 4.
> 


Then what is the reason for four PSC levels? Can you explain what the 
last sentence above mean? What type of hierarchy is it referring to? 
thanks for any clarification


>>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?
>>
> 
> Please explain why ODU fits neither in TDM nor in LSC.
> 


The descriptions of TDM talks about SONET/SDH. It doesn't mention OTN. 
Is it your intention then that TDM will also include ODU?


>>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...
>>
> 
> Please look again - the text includes min LSP b/w as well.
> 


OK I see. Thanks for pointing this out.


>>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.
>>
> 
> The example illustrates the case where an interface supports more
> than one branch of the SONET muxing hierarchy.
> 


Right, and again the second part of example talks about arbitrary concat 
which is separated from the main document in GMPLS signaling suite of I-Ds.


>>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)
>>
> 
> In the absence of any objections from the other folks, I'll be glad to
> remove the date.
> 
> 
>>	reservable bandwidth=determined by DWDM
>>doesn't make sense as a combined unit. I think the encoding should be 8
>>(lambda).
>>
> 
> The encoding is "lambda" (as LSC stands for *Lambda* switch capable).
>   


No I'm not referring to "interface switching capability", but "encoding 
type". Right now, it's set to "SONET ANSI T1.105". I think it should be 
"lambda" and you seem to agree with your answer above...?


>>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...
>>
> 
> This has to do with the ability of a given interface to support
> more than one switching capability. At signaling time you may want
> to select a particular one.


So you're saying that a user may request a STS-1 service and wish to 
specify the switching type as LSC (for example), and not the typical TDM?

I'm assuming that once the "switching type" is specified, it remains 
constant for the entire connection? If it is, then I'm assuming that the 
source node will be specifying what "switching type" to use.

What happens when a connection goes over multiple AS, where the first AS 
uses TDM to support the connection but the second AS uses LSC to support 
the connection (for example, for an OC-48 service request)? Does 
specifying the switching type limit service for this case?


Thanks for further clarifications...

Zhi