Re: draft-chen-rr-oscillation-reduce-00.txt

> Date: Wed, 5 Jun 2002 15:59:20 -0700 (PDT)
> Message-Id: <200206052259.g55MxJD84331 <at> roque-bsd.juniper.net>
> From: Pedro Roque Marques <roque <at> juniper.net>
> To: Enke Chen <enke <at> redback.com>
> Cc: Gordon Wilfong <gtw <at> research.bell-labs.com>, idr <at> merit.edu
> Subject: Re: draft-chen-rr-oscillation-reduce-00.txt 
> In-Reply-To: <20020605214213.677367E6C1 <at> popserv3.redback.com>
> 
> Enke Chen writes:
> 
> > Hi, Gordon: As you correctly pointed out:
> 
> 
> >   o The code has been deployment for almost 3 years that (by
> > default) avoid the switch between two EBGP paths when the route
> > selection goes to the "random" steps (e.g., router-id
> > comparison). As a result, C1 would converge to AS1 as the best. This
> > is another way to resolve this case.
> 
> >     Now you know the real reason why that step was introduced in the
> > route selection 
> 
> Avoiding the switch between paths doesn't avoid 'random' steps. It is
> itself a 'random' step in which the factor is arrival time of the
> route making it random and non-deterministic.

Let me clarify: I did not mean the step is "random" (sorry). I mean
the result of the step is random. For example, a BGP speaker does not
have any control over what router-id an EBGP peer will use (or change).
In that case, it really does not matter to the speaker which EBGP path
to choose when the route selection goes all the way to comparing
router-id.

> 
> If there are cases where this seems a good idea there is an equal
> number of cases where it makes things worse.

Is there a specific example that avoid EBGP switch (based on router-id)
makes things worse?

> 
> I was under the impression that the "real reason" is much more related
> to certain implementation choices a vendor we used to work for has in
> their implementation that make it really hard for said implementation
> to suppress duplicate updates 

No, it was not the duplicate update. It was a real churn (involving RR)
seen on one of the large ISP networks in the US three years ago. Srihari
was the one that logged into the routers and first identified the churn.

Regards,  -- Enke