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

[Jakob Heitz <[e-mail]>]

I think I can see a use case.
A BGP speaker wants to tell its neighbors:

If the BGP session to me goes down, you MUST immediately
remove the routes that I advertised to you,
AND
when I have completed my initial update to you,
I will send you an EOR.

--
Jakob Heitz.
 

> -----Original Message-----
> From: Cayle Spandon [mailto:[e-mail]] 
> Sent: Thursday, August 18, 2011 4:44 AM
> To: Jakob Heitz
> Cc: [e-mail]
> Subject: Re: [Idr] Solicit feedbacks on 
> draft-dong-idr-end-of-rib-use-extension
> 
> Jakob Heitz> When a BGP speaker advertises the GR capability without
> Jakob Heitz> including any <AFI,SAFI> it is saying to the peer:
> Jakob Heitz> I will send an EOR when my initial update is complete and
> Jakob Heitz> I MAY retain your routes when you restart.
> 
> Jakob Heitz> When a BGP speaker advertises your extension,
> Jakob Heitz> it is saying to the peer:
> Jakob Heitz> I will send an EOR when my initial update is complete and
> Jakob Heitz> I WILL NOT retain your routes when you restart.
> 
> One nitpick (not relevant to the discussion at hand): if we have a new
> separate EoR capability, sending it would not make any statement about
> whether or not router are retained after a restart. That would be an
> orthogonal issue handled by the GR capability.
> 
> Jakob Heitz> Can you state a use case where the difference matters?
> 
> I see your point, which is (I think) that we can use the existing GR
> capability without an <AFI,SAFI> to advertise "I will (a MUST) send an
> EoR after initial convergence".
> 
> I believe there is a problem with this approach.
> 
> Let's say that a BGP speaker wants to announce the following:
> 
> (a) I am able to preserve forwarding state for <AFI,SAFI> during a
> restart. This requires sending a GR capability with <AFI,SAFI>.
> 
> (b) I will (a MUST) send an EoR after initial convergence. This
> requires sending a GR capability without an <AFI,SAFI>.
> 
> Since a single GR capability cannot have and not have an <AFI,SAFI> at
> the same time, this would require sending two separate GR capabilities
> in a single OPEN message (one GR cap with one or more <AFI,SAFI> and
> one GR cap without).
> 
> This is explicitly forbidden in the 2nd to last paragraph of section 3
> of RFC 4724.
> 
> On Tue, Aug 16, 2011 at 10:23 AM, Jakob Heitz 
> <[e-mail]> wrote:
> > Again:
> >
> > 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.
> >
> > Can you state a use case where the difference matters?
> >
> > --
> > Jakob Heitz.
> >
> >
> > On Aug 16, 2011, at 4:32 AM, "Cayle Spandon" 
> <[e-mail]<mailto:[e-mail]>> wrote:
> >
> > I think it is fair to say that everyone agrees that EoR makes sense
> > without GR.
> >
> > With 20/20 hindsight, it would probably have been "cleaner" 
> to define
> > a separate capability for EoR and GR.
> >
> > But we have to play the cards we have been dealt, and at 
> this point I
> > can sympathize with the position that clarifying/tweaking 
> the existing
> > specs would minimize churn and confusion.
> >
> > (That said, I would not object to "doing the right thing from an
> > architecture point of view" and creating a new EoR capability even
> > though doing so would create a new set of confusions on how the new
> > EoR capability would interact with the existing GR capability.)
> >
> > Regardless of what we decide to do (tweak GR capability or add EoR
> > capability) I think that the following 3 problems need to fixed:
> >
> > 1. There must be a way of negotiating EoR in such a way that the
> > receiver can be 100% certain that it will receive an EoR at 
> the end of
> > initial convergence. As pointed out by earlier posters, 
> there are some
> > inconsistencies in the current GR spec which cause it to be unclear
> > (for certain scenarios, notably when <AFI,SAFI> is included) whether
> > an EOR should be sent after initial convergence.
> >
> > 2. It is not sufficient to simply clarify the language in a 
> respin of
> > the GR spec without any protocol changes. If we did that, 
> the receiver
> > of a GR capability would have no way to know 100% sure that 
> the remote
> > side intends to send an EoR after initial convergence (because it
> > doesn't know whether the remote side was implemented before or after
> > the "clarifications"). Thus, we need to add "something" 
> (either a new
> > flag in the existing GR capability to a new EoR capability) which
> > conveys to the other side: "I guarantee that I will send EoR after
> > initial convergence".
> >
> > 3. We also need to clarify the behavior for router-refresh. In my
> > opinion it would be good to also indicate 
> end-of-route-refresh with an
> > EoR (or similar) message.
> >
> > -- Bruno
> >
> > PS to muddle the waters some more: If we do end up going 
> down the path
> > of a new EoR capability, then I would suggest that the authors of
> > draft-ietf-idr-bgp-enhanced-route-refresh join the effort; EoR could
> > be enhanced to include SoR (Start-of-RIB) as well which would cover
> > the need for start-of-route-refresh and end-of-route-refresh.
> >
> > On Thu, Aug 11, 2011 at 9:15 AM, Robert Raszuk 
> <[e-mail]<mailto:[e-mail]>> wrote:
> > Hi Jie,
> >
> > It's good that we agree on this scenario. IMO now GR capability with
> > null AFI/SAFI is for signaling "GR helper and EoR".
> >
> > I would not agree with that. It is in fact just the opposite.
> >
> > If we want to use it to signal EoR only, we may need another way to
> >
> > signal the GR helper capability.
> >
> > +
> >
> > IMO the two scenarios mentioned in sec 4 cannot be signaled
> > separately through one single capability format. Thus some 
> additional
> > flag needs be defined
> >
> > While I did suggested the addition of flag after rethinking 
> this a bit more
> > I do not think it is necessary.
> >
> > Here is my idea:
> >
> > --
> >
> > * When you signal GR capability with null AFI/SAFI list - 
> it just means use
> > of EOR - it does not mean you support helper mode.
> >
> > * When you signal GR capability with non-null AFI/SAFI (at least one
> > AFI/SAFI included) - it will mean use of EOR, helper mode 
> support + GR
> > support for this/those AFI/SAFIs.
> >
> > --
> >
> > If the GR RFC will clarify that to reflect such semantics I 
> think all
> > confusions are addressed and all cases covered without any 
> need for protocol
> > extension.
> >
> > Thoughts ?
> >
> > Thx,
> > R.
> >
> >
> > _______________________________________________
> > Idr mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/idr
> >
> > _______________________________________________
> > Idr mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/idr
> >
>