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

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 27 Jun 2003, Alex Zinin wrote:
> > 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.

And what if the originator of the LSA also has DoNotAge bit set?

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

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings