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

[Yakov Rekhter <[e-mail]>]

Curtis,

> Here are some suggested changes to the BGP4 draft.  Briefly, there are
> a few separable issues:
> 
>   1.  Some wording changes (ie: hunk 1, 6, 7, 8, 14)
> 
>   2.  Proposing "BGP resynchronization".  See below.
> 
>   3.  Replace descriptions of route selection with something more
>       clear and accurate.
> 
>   4.  Replace some text about route overlap that is wrong and reflects
>       earlier indecision on the part of the WG.

I think that we need to decouple the editorial changes from
the technical changes, especially at the point where the WG
is in the process of advancing the document to a Full Standard.

With this in mind here is my response:


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.

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.
  
>   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. 
  
>   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.
  
>   4.  Reduces the exposure to TCP RST attacks.

Please elaborate.

Yakov.