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

[Jakob Heitz <[e-mail]>]

Jie,

When a BGP speaker advertises the GR capability without
including any <AFI,SAFI> it is saying to the peer:
I will send an EOR when my initial update is complete and
I MAY retain your routes when you restart.

When a BGP speaker advertises your extension,
it is saying to the peer:
I will send an EOR when my initial update is complete and
I WILL NOT retain your routes when you restart.

I think. Is that correct?

Can you state a use case where the difference matters?

--
Jakob Heitz.
 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Jie Dong
> Sent: Tuesday, August 09, 2011 6:30 PM
> To: Enke Chen
> Cc: [e-mail]
> Subject: Re: [Idr] Solicit feedbacks on 
> draft-dong-idr-end-of-rib-use-extension
> 
> 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
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>