Subject: Re: [Idr] Question on MinASOrig Timer

From: Yakov Rekhter <[email-masked]>
Date: Sat, 28 Feb 2004 16:34:42 -0800

Curtis,

> > [clipped...]
> >  
> > > Pedro,
> > > 
> > > If you have separate timers for route origination/advertisement and
> > > up/down and the best solution is to set them all the same then it is
> > > possible to set them all the same.
> > > 
> > > If you specify that they must be the same and that doesn't turn out to
> > > be the best way to do things you are stuck.
> > > 
> > > Its clear that there isn't agreement on the best solution, so for the
> > > time being flexibility is needed.
> > 
> > One point to keep in mind is that since we are moving the spec to
> > a Draft Standard, a *necessary* condition for relaxing the spec to 
> > support the flexibility you mentioned above would be more than
> > one implementation that supports such flexibility.
> > 
> > Yakov.
> 
> 
> Maybe not if it is a SHOULD and we are acknoledging the work in
> Signcomm that indicates that slow propogation of withdraw is bad.
> Existing implementations are conforming and there are no
> interoperability problems with a timer that can be set to more than
> one value.

rfc1264 is quite clear on this topic:

   4) There must be evidence that all features of the protocol have
      been tested, running between at least two implementations. 
  
Note that the above quote does not distinguish between SHOULD
and MUST features.

> I understand that you don't want to change the spec.  Again.

I have no problem with changing the spec, as long as the change
reflects what is implemented and deployed. 

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 27 Feb 2004 11:10:09 -0500

In message <[email-masked]>, Robert Raszuk writes:
> Curtis,
> 
> > Where this matters is if there is a cycle:
> > 
> >     AS1  --  AS2  --  AS3  -- AS4  --  AS5  -- ASn  -- back to AS1
> 
> I am glad there seems to be an agreement that providing two timers may 
> matter in the long chain of ASes.
> 
> I also therefor assume that there is an agreement that within single AS 
> or even short chain of 1-3 ASes connected to each other the most 
> practical would be not to introduce two delays one for updates/implicit 
> withdraws and the other for updates with only unreachable routes.
> 
> While maybe in the case you mentioned indeed there could be some 
> benefits but I think correctly setting those timers in an uniform way 
> across all of those ASes is just not possible to be achieved in practice.
> 
> It also seems that different settings in each AS (some of them maybe due 
> to errors) may produce much worse outcome that not using any timer at 
> all. Therefor unless we come up with some auto-tuning way I am not sure 
> if we should treat pure withdraws any different then implicit withdraws 
> or reachability information.
> 
> Rgs,
> R.

Robert,

What I'm saying is we know cases where the impact would be dramatic
and the Craig and Ahba and other Sigcomm papers on BGP performance
show plenty of evidence that these cases quite commonly occur on the
network.

Until the research/standards/operators/vendor community *decides* what
is truly the best way to provide these timers, setting the same for up
and down or different, we should provide the flexibility in the spec
and should provide the flexibility in implementations.

Evidence points to significant benefits to separate timers but that's
not the main issue.  The issue is providing sufficient flexibility
such that if this is beneficial the spec doesn't preclude it.

Curtis