Re: [CCAMP] Change 1: Introduction of resource pool entity (was Re: Moving the WSON discussion forward)

Hi Greg,

The reason we are proposing a change, is that with current WG solution the updating process is not detailed, and leaves this in an implementation dependant interpretation, as is also the composition of each instance of the LSA. I would rather have a solution that specifies that as I see this as a facilitator for interoperability and commonality. Otherwise the WG believes that having a specified process of updates is not required.
My opinion on that is that in case the cost is low, let it be specified.
Using multiple type of top-level TLV is a way to formalize that, there can be alternative approachs, but if there is no constraint in using those, why not exploring this path, as long as nothing else is proposed?

Regards,

- pierre 

-----Message d'origine-----
De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De la part de Greg Bernstein
Envoyé : mercredi 13 juillet 2011 22:53
À : ccamp@ietf.org
Objet : Re: [CCAMP] Change 1: Introduction of resource pool entity (was Re: Moving the WSON discussion forward)

Pierre, as previously stated multiple instances in OSPF-TE (RFC3630) allow one to decrease the flooding size for dynamic information. As RFC3630 indicates: "The Instance field is an arbitrary value used to maintain multiple Traffic Engineering LSAs.  A maximum of 16777216 Traffic Engineering LSAs may be sourced by a single system.". This number of instances should be more than enough by far for all WSON applications.  Hence the proposed change is not needed.

Best Regards
Greg

On 7/13/2011 8:44 AM, PELOSO, PIERRE (PIERRE) wrote:
> Hi Greg and CCAMPer's,
>
> As in the preceding mail which summarized the 3 main changes proposed 
> by draft-peloso-ccamp-wson-ospf-oeo, become too big to be easily read through, I've been splitting the 3 points in 3 different threads, this one deals with change 1:
> Introduction of the Resource Pool entity inside the model, which allows the definition of several resource entites per node independantly floodable.
> MOTIVATION: to decrease the size of flooding upon LSP changes (setup or tear down). (Resource Pool = group of resource blocks with same connectivity constraints).
>
> Best Regards,
>
> Pierre
>
> [SNIP]
>
> ==snip==

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp