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

[Jie Dong <[e-mail]>]

Hi Jakob, 

That's also what I wanted to describe in my previous mail, thanks for your summarization. 

This is the case to let peers know this speaker "would only send EOR for initial route update and would not behave as GR helper".

Best regards,
Jie

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Jakob Heitz
> Sent: Friday, August 19, 2011 1:41 AM
> To: Cayle Spandon
> Cc: [e-mail]
> Subject: Re: [Idr] Solicit feedbacks on
> draft-dong-idr-end-of-rib-use-extension
> 
> 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
> > >
> >
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr