Re: iBGP route oscillation drafts

[Gordon Wilfong <[e-mail]>]

Anindya,

I apologize, but I think I might have 
mislead you somewhat.  The example we have is of 
a system that suffers from persistent route
oscillations when MEDs are compared, but that converges
when MEDs are ignored.  Thus in my terminology, this system
has a MED induced oscillation problem.  I'm not sure however
if this is what others mean by the MED induced
oscillation problem.

- Gordon

Anindya Basu wrote:
> 
> John, in addition to Bruce's comments, here are my $0.02.
> -Anindya
> 
> "John G. Scudder" wrote:
> > The MED problem is real enough.  However, as we've been discussing in
> > a different thread, your proposal is more far-reaching than just
> > addressing [3].  Specifically:
> >
> > At 1:26 PM -0400 5/29/02, Anindya Basu wrote:
> > >However, our aim was to address the elimination of any possible kind
> > >of oscillation in I-BGP, MED-induced or not, persistent or not.
> >
> > That's laudable in the abstract but inevitably leads to the
> > requirement that you advertise more additional routes than required
> > to fix specifically [3].
> 
> The comment you refer to here was made in the context of Alvaro's
> comment that their solution was designed only to eliminate MED-induced
> oscillations. We now have an example where the oscillations are
> MED-induced, which our solution fixes but the solution proposed by
> Alvaro
> et. al. does not. In that sense, sending around the extra routes is
> *necessary* to eliminate even MED-induced oscillations alone.
> 
> > My take on the subject is that while theoretical protocol correctness
> > is an admirable goal, it's not more important than scalability.
> > Protocol scalability plus _practical_ protocol correctness is more
> > important, IMO.
> >
> > As you yourself point out in draft-wilfong-ibgp-oscillations-00.txt:
> > >Admittedly, the configuration in Figure 1 is not likely in a
> > >reasonable network.
> >
> > I think the IDR working group should be primarily concerned with
> > reasonable networks.  Fixing problems for unreasonable (or
> > hypothetical) networks seems fine as long as it doesn't conflict with
> > the operation and scaling of reasonable ones.
> >
> > Do you disagree?
> 
> In principle, I do agree with what you say. However, the question is
> what we mean by _practical_ protocol correctness, as you call it.
> Moreover, I think we pointed out in an earlier mail (and I quote):
> 
> "We feel that our example is no less real than the one outlined in the
> McPherson I-D since that example also critically relies on a route
> reflector preferring a route through the client of a different route
> reflector (due to IGP metrics)."
> 
> Also, there may be some danger in equating "real" configurations with
> configurations that are "safe" (i.e., that do not produce oscillations).
> We cannot say for sure that a "real" configuration (produced by using
> heuristics or rules of thumb) will never produce MED-induced (or any
> other kinds of) oscillations. Finally, detecting configurations that are
> safe is NP-hard, as we have shown in the SIGCOMM paper (reference [5],
> soon to be available from the ACM SIGCOMM website).