OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: Two Opaque Timers to Ospf...

From: Acee Lindem (aceeREDBACK.COM)
Date: Wed Apr 16 2003 - 11:00:33 CDT

John,

There have been suggestions in the past to reduce or ignore
MinLSInterval and MinLSArrival. However, there haven't been any
formal proposals addressing (or at least describing) all the issues.
IMHO, adding another timer for TE Opaque LSAs is limited and
shouldn't be pursued.

Thanks,
Acee

john151libero.it wrote:
> Hi all,
> i'd like to do some considerations about the use of Timer
> in RFC2370 Opaque LSA;
>
> i understood this use of Timer for opaque LSA:
> suppose we refer to a simple starting situation in which for a long time there is
> no opaque LSA propagation; in a certain time t0, one router (R1) in the net
> receives a bandwidth update and so an opaque LSA flooding starts;
> if new updates arrive to R1 about bandwidth, color, ecc, these updates
> are stored and NOT flooded through the net until (t0 + MinLSInterval sec) when
> one opaque LSA is flooded with the latest updates.
>
> If it's right, thinking to a MPLS scenario in which bandwidth
> updates come from RSVP and other fields updates in Opaque LSA
> come from a different module in each router (in example an administative
> module), could it be more
> reasonable the use of two timer: for example one timer
> considering all the opaque fields updates excepts administrative group
> field updates and one considering only the administrative field updates?
>
> I see the reason for this complication in the logical
> independence between each entity detecting its own fields variation;
> also condider that an hypothetical admistrative module in the most cases
> will send few updates regarding to RSVP bandwidth updates
> ( i would not wait MinLSInterval seconds to send, for example,
> a color field update, but i would still maintain a time filter for
> rapid changes in link color attributes ).
>
> Do you see stability problems in this change or an
> incompatibility in the standard?
>
> Thanks in advance for your kind answers and observations.
>
> Giovanni
>
> Coritel Rome
>
>

--
Acee