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

[Pekka Savola <pekkas@netcore.fi>]

Hi,

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.

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