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

[Greg Bernstein <[e-mail]>]

Thanks Tom, hopefully your "chime" helps make it clearer how the LSAs 
get updated and how a WSON system can control that process.
Pierre and co-authors, do you have a specific scenario in mind? The 
existing mechanisms have worked well for previous GMPLS implementations.
Regards
Greg B.
On 8/17/2011 3:14 AM, t.petch wrote:
> ----- Original Message -----
> From: "Greg Bernstein"<[e-mail]>
> To: "PELOSO, PIERRE (PIERRE)"<[e-mail]>
> Cc:<[e-mail]>
> Sent: Wednesday, July 20, 2011 5:04 PM
>
> 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).
>
> <tp>
> I have not seen a chime so here is one.
>
> An LSA is identified by the combination of LS Type, Link State ID and
> Advertising Router, which is unique.  Instances of an LSA are differentiated by
> LS Sequence Number which starts at x'80000001' and is incremented each time a
> router originates a fresh instance of that LSA, which it will do when something
> changes in the contents of the LSA or at regular intervals if everything stays
> the same.
>
> For OSPF TE, the LS Type is 10, and the Link State ID is 1 followed by 24 bits
> of Instance.
>
> When a router receives an LSA, it checks the LS Sequence Number, and if it is
> for a newer instance, then the old one is discarded and the new one flooded.  If
> it is for an older one, then that is discarded.
>
> All in RFC2328, RFC2370 and RFC3630.
>
> Tom Petch
> </tp>
>
> 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]
>
>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>


-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]