Re: bgp4-17 Cease subcode

[Russ White <[e-mail]>]

So, then it sounds like the way we should approach this (the
idlehold state in the fsm) is to think about it seperately from
the draft 17 issue (?).

Russ

On Tue, 15 Jan 2002, Susan Hares wrote:

> 
> Alex:
> 
> I know you have been active on the mailing list.
> And you didn't read it before the last call on the FSM.
> And this question was asked on the list because I
> wondered about it.
> 
> ;-)... <giggle on>  --- I guess not even great people are
> perfect.  <giggle off>
> 
> OK, now I've got 2 more against (4 total).  And 15-20 votes
> for it inside the draft.
> 
> I'm sure your vote is a bit more specific.  :-)...
> 
> Is the issue you want to pull exponential out of the draft?
> This is a change to the BGP specification.  This draft
> is about corrections not changes in functionality.
> 
> What do we do?
> 
> Sue Hares
> 
> 
> 
> At 10:30 AM 1/15/2002 -0800, Alex Zinin wrote:
> 
> >Russ, Eric,
> >
> >  I tend to agree here...
> >  I'm currently reviewing the FSM and the impression I'm
> >  getting is that we can go without the IdleHold state
> >  and say that implementations may/should use some local mechanisms
> >  to hold BGP sessions in the *Idle* state to avoid excessive
> >  session flapping. I think this will be simpler and will
> >  match current implementations better...
> >
> >--
> >Alex Zinin
> >
> >Tuesday, January 15, 2002, 7:21:06 AM, Russ White wrote:
> >
> >
> > > Something like: "BGP implementations can/should/must
> > > (?) implement some method to prevent continuous flapping of
> > > peering sessions at a high rate," and then a footbote explaining
> > > that an exponential backoff is one such possible method?
> >
> > > Russ
> >
> > > On Tue, 15 Jan 2002, Eric Gray wrote:
> >
> > >> Russ,
> > >>
> > >>     Very good point.  However, how would you represent "do some
> > >> private magic here" in an FSM?  That may make it the dreaded ISM.
> > >> Perhaps it might be sufficient to remove this from the FSM and
> > >> add a footnote (possibly mentioning an exponential back-off as an
> > >> example?).
> > >>
> > >> You wrote:
> > >>
> > >> > Well, I just took it as 'do people do this?' I agree that it
> > >> > won't cause interop problems either way--it's actually something
> > >> > that's implementation local, so I'm not certain why the
> > >> > exponential backoff would be in the fsm (?). There are, in other
> > >> > words, other ways I could imagine handling this problem that
> > >> > wouldn't effect interoperability as well....
> > >> >
> > >> > :-)
> > >> >
> > >> > Russ
> > >> >
> > >> > On Tue, 15 Jan 2002, Eric Gray wrote:
> > >> >
> > >> > > Russ,
> > >> > >
> > >> > >     I don't think that NAKs are in order on this question - even 
> > from the
> > >> > > 1500 pound dragon.  :-)
> > >> > >
> > >> > >     The fact that anyone's implementation doesn't do X is 
> > important only
> > >> > > if not doing X causes interoperability problems with implementations
> > >> > > that do X.   That is not the case here, I believe...
> > >> > >
> > >> > > You wrote:
> > >> > >
> > >> > > > > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote:
> > >> > > > > > > Please remember that the goal of the draft is to document
> > >> > > > > > > what is *currently* implemented and deployed, *not* what
> > >> > > > > > > *could* be implemented and deployed.
> > >> > > > > >
> > >> > > > > > Is the expoential backoff in the FSM in current implementations?
> > >> > > > >
> > >> > > > > I guess we are going to find this out as part of the
> > >> > > > > implementation report. And if it is not in (at least two)
> > >> > > > > current implementations, we'll take it out of the text.
> > >> > > >
> > >> > > > Cisco doesn't do this....
> > >> > > >
> > >> > > > :-)
> > >> > > >
> > >> > > > Russ
> > >> > > >
> > >> > > > _____________________________
> > >> > > > [e-mail] <>< Grace Alone
> > >> > >
> > >> > > --
> > >> > > Eric Gray (mailto:[e-mail])
> > >> > > http://www.mindspring.com/~ewgray
> > >> > >
> > >> > >
> > >> > >
> > >> >
> > >> > _____________________________
> > >> > [e-mail] <>< Grace Alone
> > >>
> > >> --
> > >> Eric Gray (mailto:[e-mail])
> > >> http://www.mindspring.com/~ewgray
> > >>
> > >>
> > >>
> >
> > > _____________________________
> > > [e-mail] <>< Grace Alone
> 
> 

_____________________________
[e-mail] <>< Grace Alone