Re: Questions about GMPLS signaling and routing

[Yakov Rekhter <yakov@juniper.net>]

Zhi-Wei,

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

The text in 6.4.3 uses arbitrary concatenation *as an example*. Are
you saying that we can't refer to arbitrary concatenation even for the
purpose of an example ?

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

The last sentence above means that if one wants to have more than 4 levels
of nested (PSC) LSPs, one could certainly do this.

> What type of hierarchy is it referring to? 

The hierarchy of LSP regions, as described in draf-ietf-mpls-lsp-hierarchy.

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

My intention is first to get comments on this issue from other folks
in the WG.

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

Ok.

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

Right, and again it uses arbitrary concatenation just as *an example*,
and not as a normative text.

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

Small miscommunication - the encoding I was referring to was the encoding 
of the interface switching capability. The encoding you are referring to 
is the "encoding type".  The reason why the encoding type is set to
SONET is because in that particular example the DWDM constraints
the signal to SONET.
  
Yakov.