Re: draft-pillay-esnault-ospf-flooding-05.txt

[Alex Zinin <zinin@psg.com>]

Pekka,

> By the way, we recently got it by a problem in our network which seems to
> be of some relation to this specification.

> Between two major router vendors' OSPF code, there is an interop problem 
> regarding bogus LSA's when the router-id changed (OSPF RFC sections 14.1 
> and 13.4).  Basically this resulted in the MaxAge outage of one hour.

> Oops.  If the spec is implemented, the outage is infinite.  The old 
> entries are never purged.

RFC 1793:

   2.3.  Removing stale DoNotAge LSAs

      Because LSAs with the DoNotAge bit set are never aged, they can
      stay in the link state database even when the originator of the
      LSA no longer exists. To ensure that these LSAs are eventually
      flushed from the routing domain, and that the size of the link
      state database doesn't grow without bound, routers are required to
      flush a DoNotAge LSA if BOTH of the following conditions are met:

        (1) The LSA has been in the router's database for at least
            MaxAge seconds.

        (2) The originator of the LSA has been unreachable (according to
            the routing calculations specified by Section 16 of [1]) for
            at least MaxAge seconds.

Alex


> Granted, this is a bug in the implementation(s), but this IMHO shows that 
> modifications such as proposed may have some interesting side-effects -- 
> and those might not interact well with other (mis)features of the 
> implementations.

> On Tue, 17 Jun 2003, Pekka Savola wrote:
>> On Tue, 17 Jun 2003, Alex Zinin wrote:
>> > >> DoNotAge LSAs, which are the only part of 1793 that this document
>> > >> requires, are already a subset - do you mean a subset of DNA?
>> > 
>> > > No, I meant 1793.  It is not clear enough, IMO, which parts of 1793 are
>> > > required to implment draft-pillay-esnault-ospf-flooding-05.txt.
>> > 
>> > In case you didn't see it, below is my message to Randy and IESG that
>> > should help answer most of your questions.
>> 
>> Yes, this clarifies it.  What I'd like to see is a more explicit 
>> description of what 1793 entails and what's required, like you gave.
>> 
>> > First-hand info (Padma and I were in the same company then): it was
>> > asked by customers: "I see too many refreshes floating throughout the
>> > network, and I can bump my refresh timer in ISIS, but there's nothing
>> > like this in OSPF". As more stuff was put in the IGPs (e.g. TE
>> > attributes) and networks grew bigger, customers asked more and more to
>> > make the OSPF refresh interval configurable, rather than constant. So,
>> > we have this hack now.
>> 
>> "If you use OSPF for TE, this is the price you pay; a loss of 0.01% of 
>> bandwidth."
>> 
>> (Personally, I fail to see why just rigging up the timers wouldn't be the 
>> simplest choice, if the same is done with IS-IS *anyway*.  Of course, you 
>> can always shoot yourself in the foot..)
>>  
>> > >>I'd guess that changes the OSPF protocol assumptions quite a bit.
>> > 
>> > The DNA mechanism does change the assumption, but this not something
>> > new that this draft introduces. DNAs are defined in 1793.
>> 
>> And if 1793 does not adequately discuss the topic?
>> 
>> 
>> > >>  I didn't bother to check how well they were
>> > >>documented in the OSPF DC circuits doc, but I wouldn't count on it.
>> > 
>> > In fact, 1793 does talk about it, and explains decrease in robustness
>> > quite nicely. Please take a look at section 6.
>> 
>> Yes, there is some text, but I would not call that particular half-page 
>> too convincing.
>> 
>>