Re: Solicit feedbacks on draft-dong-idr-end-of-rib-use-extension

Hi, Jie:

IMO RFC 4724 is sufficiently clear about the use of EOR, and also 
specifies the use of the GR capability without AFI/SAFI for indicating 
the EOR support without performing GR.  Please see excerpt from RFC 4724 
below.

Granted there are some inconsistencies in RFC 4724.  A re-spin of RFC 
4724 seems in order. Actually a re-spin is already on the IDR WG status 
report presented at the IETF-81.

There is no need for a new capability, though, as there is no backward 
compatibility issue for sending and receiving the GR capability (with or 
without AFI/SAFI).

In short, I do not see a need for draft-dong-idr-end-of-rib-use-extension.

-- Enke

-------------------------------------------------------

RFC 4724 (GR)

2. Marker for End-of-RIB
     .....

    Although the End-of-RIB marker is specified for the purpose of BGP
    graceful restart, it is noted that the generation of such a marker
    upon completion of the initial update would be useful for routing
    convergence in general, and thus the practice is recommended.

    In addition, it would be beneficial for routing convergence if a BGP
    speaker can indicate to its peer up-front that it will generate the
    End-of-RIB marker, regardless of its ability to preserve its
    forwarding state during BGP restart.  This can be accomplished using
    the Graceful Restart Capability described in the next section.

4.  Operation

    A BGP speaker MAY advertise the Graceful Restart Capability for an
    address family to its peer if it has the ability to preserve its
    forwarding state for the address family when BGP restarts.  In
    addition, even if the speaker does not have the ability to preserve
    its forwarding state for any address family during BGP restart, it is
    still recommended that the speaker advertise the Graceful Restart
    Capability to its peer (as mentioned before this is done by not
    including any<AFI, SAFI>  in the advertised capability).  There are
    two reasons for doing this.  The first is to indicate its intention
    of generating the End-of-RIB marker upon the completion of its
    initial routing updates, as doing this would be useful for routing
    convergence in general.  The second is to indicate its support for a
    peer which wishes to perform a graceful restart.

-----------------------------------------------------------------------

On 8/9/11 12:46 AM, Jie Dong wrote:
> Dear all,
>
> Internet-Draft draft-dong-idr-end-of-rib-use-extension was submitted before Quebec IETF. The url
is: http://tools.ietf.org/html/draft-dong-idr-end-of-rib-use-extension-00
>
> Since BGP End-of-Rib (EoR) would be useful for general BGP convergence, this draft proposes to define a
EoR capability to negotiate the use of EoR between BGP peers. This makes EoR an independent feature and
could be used without supporting or enabling GR capability. As according to BGP GR (RFC4724), BGP peers
can only negotiate the combination of EoR and GR capability.
>
> We've received some offline comments, one of which suggested an alternative solution: respin GR
specification and cover this scenario: negotiate only EoR, no GR.
>
> Thus we would have two alternatives here:
> either we define a simple and dedicated capability for EoR,
> or we respin BGP GR with some further capability negotiation functionality to cover this case.
>
> We would like to solicit feedbacks and opinions on this draft and also the alternatives.
>
> Many thanks,
> Jie
> _______________________________________________
> Idr mailing list
> Idr <at> ietf.org
> https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr