Subject: Proxy: comments on section 3

From: Alex Zinin <[email-masked]>
Date: Fri, 6 Sep 2002 15:02:40 +0200

Proxy-fwd'ing a set of comments on the spec.
Please discuss.
Alex

Reading draft-ietf-idr-bgp4-17.txt from a "first time implementer" point of
view ...

Something at the beginning of Section 3 of  is not clear.  

> The initial data flow is the portion of the BGP routing table that is
> allowed by the export policy, called the Adj-Ribs-Out (see 3.2).
> Incremental updates are sent as the routing tables change. BGP does
> not require periodic refresh of the routing table. Therefore, a BGP
> speaker __must__ retain the current version of the routes advertised by
> all of its peers for the duration of the connection. 

Shouldn't "must retain" be "SHOULD retain"?  The text that comes next
(below) contradicts "must".
 
> If the
> implementation decides to not store the routes that have been
> received from a peer, but have been filtered out according to
> configured local policy, the BGP Route Refresh extension [12] may be
> used to request the full set of routes from a peer without resetting
> the BGP session when the local policy configuration changes.

Regarding Route Refresh, this is clear.  When I change local policy, I would
need to trigger a "Route Refresh" (e.g. clear ip bgp).

However, what about if route refresh isn't supported (locally or by the
remote peer, or both)?  I'm aware of the current practice of "soft reset".
Should it be mentioned?  If not "soft reset" because its IOS specific,
perhaps text pointing out that the routes retained from a peer should/could
be used (via manual intervention) when local policy changes.   For
completness, call out that routes filtered and not retained can never be
used after local policy changes without a real reset (or route refresh).

---

From: Mathew Richardson <[email-masked]>
Date: Fri, 6 Sep 2002 09:23:21 -0400

> Alex Zinin <[email-masked]> [Fri, Sep 06, 2002 at 03:02:40PM +0200]:
>remote peer, or both)?

This is why you must retain them.  I, personally, was against adding
the Route Refresh text to the base spec, and would still like to see
it removed.  Given that I'm in the minority on this, how about something
like:

  ... Therefore, a BGP speaker must either retain the current version of
  the routes advertised by all of its peers for the duration of the
  connection, or make use of the Route Refresh extension [12].  This
  is necessary to allow local policy changes to have the correct effect
  without requiring the reset of any peering sessions.

  If the implementation decides not to retain the current version of
  the routes that have been received from a peer, then Route Refresh
  messages should be sent whenever there is a change to local policy.

>I'm aware of the current practice of "soft reset".

Is the above text sufficient?

mrr

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 23 Sep 2002 13:04:08 -0700

Matt,

>   messages should be sent whenever there is a change to local policy.

How about the slight rewording, as follows:

    To allow local policy changes to have the correct effect without
    resetting  any BGP connections, a BGP speaker SHOULD either
    (a) retain the current version of the routes advertised to it
    by all of its peers for the duration of the connection, or (b)
    make use of the Route Refresh extension [12].

Yakov.

---

From: Mathew Richardson <[email-masked]>
Date: Mon, 23 Sep 2002 16:27:39 -0400

> Yakov Rekhter <[email-masked]> [Mon, Sep 23, 2002 at 01:04:08PM -0700]:
>Matt,

<snip>

>    make use of the Route Refresh extension [12].

<snip>

That sounds good.

mrr