Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)

[Julien Meuric <[e-mail]>]

Hi Kireeti,

See below.

Cheers,

Julien


Le 12/12/2011 22:37, Kireeti Kompella a écrit :
>  Hi Julien,
>
>  On Dec 6, 2011, at 7:31 , Julien Meuric wrote:
>
> > Hi John, hi Lou.
> >
> > On the one hand, SONET/SDH and OTN are close: it is highly tempting
> > to prolong control of the former to the latter. Nevertheless, the
> > GMPLS deployments on SONET/SDH I am aware of only control high
> > order containers (i.e. SDH VC-4/VC-4-nc or SONET STS-1/STS-1-nc).
> > In that context, I do not think we can easily generalized protocol
> > extensions from an almost single-stage control to a highly
> > multi-stage control.
>
>  Are you saying that OTN can be considered "highly multi-stage"?
>  (asking, for my edification)

[JM] This is what I said/wrote (but you may also work on my English 
language edification).
[JM] SDH core network planing teams are currently used to working on a 
single switching granularity: VC-4. When they look at the switching 
granularities in OTN cross-connects, their eyes start to glaze (think of 
SUKLM). They rather hope that smaller containers will be aggregated 
before entering the core (like in SDH), or that TDM services will evolve 
into a simplified sub-part of the hierarchy (e.g. ODUflex and ODU4)...

>
> > On the other hand, it seems that PSC-1 to PSC-4 have not been
> > implemented much. Reasons behind are only guesses. Mine is that
> > upgrading implementations and deployments of MPLS-TE was not worth
> > the pain with respect to the added value of moving to the GMPLS
> > flavor of IGPs and RSVP-TE (especially for packet-only operations).
> > Whatever the actual reason for having so few implementations, PSC-n
> > are part of the original GMPLS specification.
>
>  I believe the primary reason is that in packet networks, hierarchy is
>  primarily used for control plane scale. In practice, this hierarchy
>  was achieved as LDP over RSVP (not RSVP over RSVP, where one might
>  have considered PSC levels); the current trend is LDP or RSVP over
>  BGP. (Perhaps we should signal "labeled BGP" as PSC-n (n>1) using
>  the BGP TE attribute!

[JM] My last experience in mixing BGP and GMPLS was in L1VPN WG. I've 
realized since that I should rather have worked on a GUI...

>
> > Let me quote the section about PSC in RFC 4202: "The various levels
> > of PSC establish a hierarchy of LSPs tunneled within LSPs." This
> > really looks like what we are doing in OTN. Yes, the discrete
> > nature of the technology will introduce one more information into
> > the SC field, but doing otherwise would depreciate existing GMPLS
> > specification.
>
>  Agree completely with you. If the thinking behind the PSC levels
>  from one of the original authors is of any interest, here it is:
>
>  For packet networks, there is clearly no pre-assigned bandwidth for
>  PSC levels. The intent was purely to control hierarchy; one was
>  allowed to tunnel PSC-1 over PSC-2 ... over TDM over lambda over
>  fiber. One could (should, would) not tunnel fiber over lambda, or
>  lambda over TDM (or TDM over packet, but then, MPLS is rife with
>  layer violations.) Likewise, an attempt to tunnel PSC 2 over PSC 1
>  was to be disallowed (or flagged for management intervention).
>
>  One could have considering defining levels of TDM as well, but (a)
>  SDH was beyond me; (b) the standardization atmosphere around SDH was
>  extremely charged; (c) my eyes would glaze over whenever SUKLM was
>  mentioned. Could one really assign SC TDM levels to PDH/SDH that
>  captured the allowed hierarchy?
>
>  With ODU, I believe that one can simply assign numbers to levels such
>  that the tunneling hierarchy is adequately captured. I believe (but
>  am not completely sure, as people here are amazingly innovative) that
>  one cannot tunnel ODU5 over ODU0. If that is of value, then there
>  should be multiple TDM levels (or perhaps, ODU levels, between TDM
>  and lambda). BTW, these levels have nothing to do with actual
>  bandwidth.
>
[JM] Thank you for the bit of history. At that time, what a foolish idea 
to control transmission circuits using RSVP-TE! Have you ever considered 
MPLS label configuration using TL1 over CLNP?... ;-)

> > Furthermore, RFC 4203 says: "When the Switching Capability field is
> > TDM, the Switching Capability specific information field includes
> > Minimum LSP Bandwidth..." In other words, even if not included in
> > the SC field so far, one cannot really say that a value per ODUk
> > layer would overload the ISCD definition.
> >
> > Thus, we have legacy vs. depreciation:
>
>  Rather, I would say, think utility -- if it is useful to have
>  multiple SC levels to capture the ODUk hierarchy, please do so. You
>  will not escape putting bandwidth somewhere (as I understand, there
>  are multiple bandwidths for ODU2, and one has to be careful with
>  suffixes and decimal places), probably in the ISCD.

[JM] I guess we all agree the information will be in {ISCD, IACD}.

>
>  One point of consideration is ODUflex -- where does it fit in the
>  hierarchy?

[JM] That is an open discussion if that path is taken. I believe its 
definition can be reflected in several ways in the IGP (e.g. L2SC over 
ODUflex in IACD).

>  How does one (if at all) assign an SC value to ODUflex?

[JM] Ask IANA? ;-)

>
> > my understanding of IETF work is to put emphasis on consistency and
> > avoid defining new solutions when they already exist, even if not
> > absolutely optimized (we are not building G.709 control from
> > scratch).
>
>  Clearly, one can solve the problem in multiple ways and in multiple
>  TLVs, including rolling an entirely new one.
>
> > My 2 cents,
>
>  ditto
>
>  Kireeti.
>
> > Julien
>
>