Re: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.txt

[Lou Berger <[e-mail]>]

On 2/28/2012 6:10 AM, Daniele Ceccarelli wrote:
>...
> Could you please explain what is the rationale
> behind introducing it?
> ...

Daniele,

Now this is a good question!

The ILH field is motivated by the WG goal of identifying and defining
common control plane mechanisms for different data plane technologies.
This draft says it this way:

   Multiple switching technologies support forms of hierarchical
   switching within a particular data plane technology.  As discussed
   above, GMPLS routing originally envisioned support for such cases for
   packet networks using PSC-2, 3, 4.  In other cases, GMPLS defined
   support using technology specific mechanisms, for example Signal Type
   was defined for SONET/SDH, see [RFC4606].  Given that one of the
   objectives of GMPLS is to generalize control plane protocols, it is
   reasonable to define a method for supporting hierarchical switching
   within a particular data plane technology that is not specific to any
   particular technology.

>From the advent of GMPLS, there has been general agreement that there
may be hierarchical switching within a particular data plane technology.
 What hasn't been figured out is the best way to represent this in a
common format.  This draft documents what we think is general agreement;
that the use of the routing Switching Cap field is the wrong place.

So what is the benefit of a generic/common representation of
intra-technology hierarchy?

>From my perspective, i.e. not speaking for Julien, it is that it enables
a function that is common across multiple technologies to be implemented
in a technology agnostic fashion -- which is, of course, on the
fundamental precepts of CCAMP and GMPLS.

Some example benefits include that it enables per-hierarchy level
topologies to be constructed by (routing) implementations *without*
parsing the SCSI.  Additionally, on equipment that doesn't support a
particular technology/hierarchy combination, processing of
advertisements for such non-supported combinations can be minimized.  As
an implementor, I also like the code & testing benefits of having common
mechanisms/implementation for equivalent per-technology functions.  I
also can see some potential operations benefits, but these certainly
will be implementation dependent.

These benefits seem sufficient to warrant looking into the mechanisms in
more detail to determine if the benefit is worth the cost of the
introduction of a new generic mechanism.  We also recognize, as has been
discussed multiple times before in the WG, there is the common tendency
of those focused on a new technology to want to solve generic problems
in a technology-specific fashion and it's the WG's job to identify when
this is happening and when it's appropriate to define new generic
mechanisms.

As we say in the document, we think that the introduction of ILH is an
open-discussion and certainly look for more/WG input.

Lou