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

[Jakob Heitz <[e-mail]>]

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