[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions about GMPLS signaling and routing
> 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
> 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
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 18.104.22.168 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 22.214.171.124 and 126.96.36.199, 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
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.