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

Hi, Jie:

There is no dispute about using EOR without performing the GR procedures 
(i.e., retaining stale routes).  That had always been the intention 
during the GR design.  The semantics of the GR capability without any 
AFI/SAFI was designed specifically for that purpose.

Unfortunately there are some inconsistencies in this area between Sect 3 
and 4 of RFC 4724.  The first two paragraphs in Section 4 talks about 
the general rules of advertising the GR cap and sending EOR.   But the 
reference in Section 3 jumps directly to Section 4.2.  The inconsistency 
needs to be fixed in a re-spin.

It a local decision whether a speaker retains stale routes from a remote 
speaker, and the decision has no impact on how the remote speaker would 
behave.  Thus no backward compatibility issue would arise from the local 
decision. That is something that should be clarified in a re-spin.

Regards,   -- Enke

-----------------------------------------
3.  Graceful Restart Capability

     ...

    When a sender of this capability does not include any<AFI, SAFI>  in
    the capability, it means that the sender is not capable of preserving
    its forwarding state during BGP restart, but supports procedures for
    the Receiving Speaker (as defined in Section 4.2 of this document).
    In that case, the value of the "Restart Time" field advertised by the
    sender is irrelevant.

---

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.

    The End-of-RIB marker MUST be sent by a BGP speaker to its peer once
    it completes the initial routing update (including the case when
    there is no update to send) for an address family after the BGP
    session is established.

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

On 8/9/11 6:30 PM, Jie Dong wrote:
> Hi Enke,
>
> Thanks for your comments.
>
> I think we agree that RFC4724 cannot cover this case well (otherwise any respin would not be needed). With RFC4724, BGP speaker can signal:
> a. capability as GR restarting speaker and use of EoR, or
> b. capability as GR receiving speaker and use of EoR.
> Thus there is no means of negotiating only EoR.
>
> Clearly EoR is not something tightly bound with GR, people could use EoR without GR. Thus if people want to signal only EoR and no GR, is it appropriate to signal it using GR capability?
>
> Our basic idea is to make EoR an independent feature, which could be used in more general cases. Thus an independent capability sounds reasonable IMO.
>
> Best regards,
> Jie
>
>> -----Original Message-----
>> From: Enke Chen [mailto:enkechen@cisco.com]
>> Sent: Wednesday, August 10, 2011 3:14 AM
>> To: Jie Dong
>> Cc: idr@ietf.org; Enke Chen
>> Subject: Re: [Idr] 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@ietf.org
>>> https://www.ietf.org/mailman/listinfo/idr