Re: diffs to draft-ietf-idr-bgp4-03.txt

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>om>, Yakov Rekhter writes:
> 
> 1. I looked at your editorial comments, and they seems to be fine
>    (except for comment 3). I would suggest that we'll give folks
>    on the list 3 weeks for comments, and in the absence of objections
>    I'll incorporate your editorial comments.

OK

> 2. Wrt BGP resyncronization, I'd like to see some stong justifications for
>    introducing this message.
>    
> > The "BGP resynchronization" warents further mention.  The idea was to
> > make something 100% compatible with current BGP4 implementations that
> > addresses the following:
> > 
> >   1.  Allows a better recovery if running a hosed implementation.  No
> >       more clearing the BGP conection.
> 
> How is that going to be better ? Seems that that best way to
> recover against a hosed implementation is to terminate peering
> with this implementation and get the "hosed implementation" fixed.

What typically happens is routes that are supposed to have been added
or removed aren't, often due to the order in which routes arrived or
were withdrawn.  This would provide an non-disruptive way of clearing
the condition while people look for the bugs.

We had been seeing this sort of problem with the Bay routers.  I can
think of numerous times that we've had to do a clear ip bgp <peer> to
fix a small number of prefixes in the Cisco that were not right so it
does happen with Cisco routers too.

At this point we could do without this.  Until the next bug.

This would also help in cases where Cisco routers need a clear
connection to get next hop right after it changed or to update a MED
derived from IGP cost.  These are still outstanding bugs.

> >   2.  Allows a cheap policy reconfig (maybe less desirable than a true
> >       dynamic reconfig) that doesn't involve clearing the BGP conection.
> 
> The problem of policy reconfig is already solved (in multiple independent 
> implementations) without BGP resyncronization. 

OK.

> >   3.  Reduces the impact of occasional loss of BGP connections.  Might
> >       even allow you to squeeze in a reload if it was real fast.
> 
> Please elaborate.

I should have put a smilely on the reload part.  A while back there
was loss on MaeWest and we think this contributed to one EBGP going
down a few times a day (though we are not sure why only this
connection lost EBGP).  The flap could be avoided if this was the only
peering (if not maybe better to take the peering down).

> >   4.  Reduces the exposure to TCP RST attacks.
> 
> Please elaborate.

well known but offline anyway.

> Yakov.

Curtis