Re: iBGP route oscillation drafts

[Anindya Basu <[e-mail]>]

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