> -----Original Message-----
> From: ext Andreas Heiner [mailto:andreas.heinerNOKIA.COM]
> Sent: 03 July, 2002 13:31
> To: OSPFDISCUSS.MICROSOFT.COM
> Subject: Re: Link Flap Damping
>
>
> Hi
>
> comments in-line
>
> > Subject: Re: Link Flap Damping
> >
> >
> > swatirstogi> You are reducing LSA changes at the cost of providing
> > swatirstogi> sub-optimal (and in the worst case incorrect and
> > swatirstogi> false) routing. You still claim reachability to a
> > swatirstogi> router which you are no longer are connected to
> > swatirstogi> (during the period when the link is down)
> >
> [ side issue
> I'm not quite sure what you mean with "optimal routing".
> Intuitively optimality in this context is "getting as much
> traffic through as fast as possible", but with dynamic
> traffic demands optimality is not well defined. Moreover, the
> cost assignment is relatively arbitrary (one administrator
> may say hops, others reliability etc.), so in my opinion
> "optimal routing" is rather arbitrary. I prefer to use "as
> good as possible", or even better, "good enough" routing.
> Gives you way more flexibility. In the end, the only thing
> users are interested in is good (enough) service, not optimal service
> (the STAR protocol by Garcia-Luna-Aceves
> (http://www.soe.ucsc.edu/people/faculty/jj.html) also uses
> this principle)
> ]
>
> > swatirstogi>
> > swatirstogi> The downstream peers will falsely assume that u still
> > swatirstogi> have reachability to some networks and they will in
> > swatirstogi> turn advertise this to their peers. This will create
> > swatirstogi> havoc if one of the OSPF routers is redistributing
> > swatirstogi> routes into BGP
> > swatirstogi>
> > swatirstogi> One of the most fundamental rules of routing which i
> > swatirstogi> learnt long back was that we must advertise the bad
> > swatirstogi> news at the earliest. The same happens in BGP. Certain
> > swatirstogi> implementations maintain a MinAdvertismentInterval
> > swatirstogi> timer which when triggers causes a BGP speaker to
> > swatirstogi> advertise all its UPDATE messages to its peers. This
> > swatirstogi> timer is not honoured in case of sending UPDATE
> > swatirstogi> messages containing withdrawn/non feasible routes.
> > swatirstogi>
> > swatirstogi> The same should hold true for OSPF. Why should one
> > swatirstogi> router keep the link description up when it knows that
> > swatirstogi> it is down?
> > swatirstogi>
> > swatirstogi> Your comments please.
> >
> > I believe IGP has different logic from EGP's.
> >
> > - about "providing sub-optimal" and "why link description up":
> >
> > I'm thinking about link flapping caused by congestion.
> > If a link flaps, your feature will not allow OSPF to route any
> > traffics to the link entirely. We still have a lot of
> links which
> > do not have alternatives. In case no alternatives, I think that
> > we prefer to deactivate the feature and let the traffic thru the
> > link by "best effort" until we upgrade the link or prepare
> > alternatives.
> >
> > [a little bit off topic:
> > I once thought that "we should not worry about congestions,
> > because we have Diffserv technology and link monitor
> packet (such
> > as Hello in OSPF) should go beyond the others priority".
> > But now I wonder if this is true: in Diffserv world,
> some class's
> > packet go through normally and the other class's packet may not.
> > What is that the hello monitors ? Do we really want to keep the
> > reachability in that case ? Hello should monitor each
> class's link
> > path separately ...
> > ]
> >
> ...deleted...
> In my opinion the only service OSPF (or any other IGP)
> provides/should provide is connectivity, i.e. it tells you if
> a link exists and if it can carry traffic, not how much
> traffic there is. Route recalculation based on traffic
> information (congestion gives new cost values) should not be
> done as it will introduce route flaps.
> This also holds for a DiffServ world. In a DiffServ world
> packets are preferentially forwarded, but always such that no
> single class is starved. Even if some class gets so little BW
> that de-facto the link is down for that class, one should not
> declare the link down for that class, as it is equivalent
> with assigning a high cost for that link. Hence link monitor
> packets per class make no sense. (Besides, in long
> simulations with strict priority queueing we never had class
> starvation)
> As for Hello in the highest DiffServ class: we tested this
> idea in simulations for all OSPF packets, and results were
> excellent, i.e. route table convergence in the order of the
> half the minimum round trip time (excl. route table
> recalculations). This idea was also proposed in
> 'draft-ietf-ospf-scalability-01.txt'.
>
> regards,
>
> Andrepeter
>
> > regards.
> > yasu
> >
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]