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

[Greg Bernstein <[e-mail]>]

I think this is more a question to the OSPF WG.
Are you asking when an LSA gets updated? They get updated when a newer 
one is received. By newer one that means one with the same "LSA instance 
number". Another top level TLV wouldn't help here  since updates are not 
based on TLVs, but on LSAs (OSPF folks please chime in).

Note that the the link state database (LSDB) is just a collection of 
LSAs.  Hence the way to get finer granularity in your updates is to use 
more "LSA instances".

Do you have a specific example in mind that can make this discussion 
more concrete?  If an optical node undergoes an in-service update 
(hot-swap) then it will want to send out LSAs reflecting this change. If 
the changes need to replace existing information in the LSDB then the 
same "LSA instance" numbers should be used to force the change. If the 
information is supplemental then new "LSA instance" numbers can be used.

Greg
On 7/20/2011 7:15 AM, PELOSO, PIERRE (PIERRE) wrote:
> 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 : [e-mail] [mailto:[e-mail]] De la part de Greg Bernstein
> Envoyé : mercredi 13 juillet 2011 22:53
> À : [e-mail]
> 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 [phone]