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

Comments inline

> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of Lou Berger
> Sent: Tuesday, February 28, 2012 5:28 AM
> To: Daniele Ceccarelli
> Cc: CCAMP
> Subject: Re: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-
> 00.txt
> 
> 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.

[JD]  The problem with the above statement is that the term 'hierarchical switching' is not defined. 

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

[JD]  The problem with the above statement is that the term 'a function' is not defined.  

> 
> Some example benefits include that it enables per-hierarchy level
> topologies to be constructed by (routing) implementations *without*
> parsing the SCSI.

[JD]  If you don't parse the SCSI, how do you place it in your TE database?

> Additionally, on equipment that doesn't support a
> particular technology/hierarchy combination, processing of
> advertisements for such non-supported combinations can be minimized.

[JD]  How exactly? 

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

[JD] A common mechanism in support of what exactly?  Also, even though there a single proposed field, the values in it will be technology specific.

> 
> 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
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp