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

[Kireeti Kompella <[e-mail]>]

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)

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

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

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

One point of consideration is ODUflex -- where does it fit in the hierarchy?  How does one (if at all) assign an SC value to ODUflex?

> 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