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

Hi Jie,

 > Please note that LDP End-of-LIB and LDP GR are not the same
 > functionality and are defined in separate documents.

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.

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.

Best regards,
R.

> 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 Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
>>>
>
>