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

[Pradosh Mohapatra <[e-mail]>]

Hi Jie,

> 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.

I don't think any new capability negotiation is required. The procedures defined in the GR spec (RFC4724) sufficiently cover what you are trying to achieve here. E.g. the following paragraph:

   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.

Moreover, many implementations do this already. The -bis for RFC4760 clearly says that an UPDATE message with empty MP_UNREACH (essentially the EOR) MUST not be treated as an error.

IMO, this is an implementation detail and let's focus on fixing those that do not do today.

Thanks,
- Pradosh