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

["t.petch" <[e-mail]>]

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