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

[Jie Dong <[e-mail]>]

Hi Enke,

Thanks for your replies.

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

It's good that we agree on this scenario. IMO now GR capability with null AFI/SAFI is for signaling "GR helper and EoR". If we want to use it to signal EoR only, we may need another way to signal the GR helper capability.

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

IMO the two scenarios mentioned in sec 4 cannot be signaled separately through one single capability format. Thus some additional flag needs be defined if you choose to re-spin GR RFC, and such extension would be for scenarios NOT enabling GR. That's why the draft proposes a dedicate capability for EoR only scenario.

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

IMO whether a speaker would retain stale routes SHOULD be signaled to its peer, then the peer (and peer's operator) could know whether GR is deployed and would take effect between the two BGP speakers. Otherwise the operator cannot tell where in the network GR is deployed and where only EoR is used.

Best regards,
Jie

> -----------------------------------------
> 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:[e-mail]]
> >> Sent: Wednesday, August 10, 2011 3:14 AM
> >> To: Jie Dong
> >> Cc: [e-mail]; 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/idr