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

[Jie Dong <[e-mail]>]

Hi Robert, 

> Allow me to make an observation that LDP GR is timer driven without any
> LDP EOR marker involved in the restart procedures as described in
> rfc3478. Most likely authors of rfc3478 assumed that the amount of
> binding information as exchanged by LDP allows for such approach.

RFC5919 specifies usage guidelines of LDP End-of-LIB for LDP GR: 

  "Receiving End-of-LIB Notification from a peer in an LDP Graceful
   Restart scenario enables an LDP speaker to stop using stale
   forwarding information learned from that peer and to recover the
   resources it requires without having to wait until the time period
   expiry.  The time period expiry can still be used if the End-of-LIB
   Notification message is not received. "

> However as we all know BGP GR does define EOR as number of BGP routes
> to
> be exchanged during the restart of the session is >> then number of LDP
> bindings therefor IMHO comparison of LDP GR/EOR to BGP GR/EOR is not
> really apple to apple case.

Yes the amount of information to be exchanged may be different, but for LDP it would also be beneficial to reduce the time in GR mode and exit GR ASAP.

Regards,
Jie

> 
> > Hi Robert,
> >
> >> As we have discussed already offline I also do not see a need for new
> >> spec to define EoR capability as a separate document.
> >
> > Got your opinion on this, thanks.
> >
> >> Text clarification of re-spined RFC4724 (with possible addition of new
> >> flag) would be in my opinion sufficient to address any potential doubts
> >> one could have reg explicit helper behaviour signaling when sending GR
> >> capability with null set of AFI/SAFIs.
> >
> > If you choose to re-spin RFC4724, adding new flags would definitely be
> needed, which is more than "text clarification". And remember this would
> be for negotiating features "outside" GR. Not sure if this sounds
> reasonable.
> >
> >> I am of the opinion that it is always much better to focus on one clear
> >> specification rather then define the same functionality in multiple and
> >> independent documents.
> >
> > Correct if they are exactly the same functionality:) Please note that LDP
> End-of-LIB and LDP GR are not the same functionality and are defined in
> separate documents.
> >
> > Best regards,
> > 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.
> >>>
> >>> Many thanks, Jie
> >> _______________________________________________ Idr
> >>> mailing list [e-mail] https://www.ietf.org/mailman/listinfo/idr
> >>>
> >
> >