Re: Questions about GMPLS signaling and routing

[Yakov Rekhter <yakov@juniper.net>]

Zhi-Wei,

> 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).

Please point to the specific text in the routing documents you'd like 
to change.

> ----------
> 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.

> 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?

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

Please look again - the text includes min LSP b/w as well.

> ----------
> 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.

> 
> ----------
> 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". 

Agreed, and that is exactly what is in the current routing drafts.

> 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).
  
> ----------
> 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.

Yakov.