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

[Cayle Spandon <[e-mail]>]

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
>