Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt

[Brian Dickson <[e-mail]>]

>> On Oct 28, 2011, at 4:51 PM, John Scudder wrote:
>>
>>> Folks,
>>>
>>> Please send comments to the list prior to the IDR meeting on November 15.

I have some questions, and some concerns.

First, the questions:

Was consideration given to implementing this as an optional,
non-transitive attribute, instead of as a separate message? Or have
the sending party use an attribute with the responder using a message
type to acknowledge?

Also, have you considered using a "marker" message not associated with
a specific NLRI, to simply indicate the latest "window" of messages
which has been processed (rather than merely queued up)? One that is
sent periodically (and possibly also after N messages). This would
behave similar to the "red card" in a casino multi-deck card "shoe",
although instead of "shuffle the cards", the semantics would be
"everything before this has been received". It would be analogous to
TCP sequence numbers, just covering a much larger range of transmitted
data, or analogous to DNS serial numbers (kind of). This would work,
because each BGP peering session is serialized over a single TCP
session. The "marker" is in effect, meta-data used to inform the GR
machinery what NLRIs have/have-not been processed, and thus where GR
can pick up if GR occurs. IMHO, not only is the overhead less (my
orders of magnitude), I think the implementation would be a lot
easier, especially when considering interoperability.

And, here are the concerns:

First, this puts a burden on implementations as far as linking new
state to out-RIB. This in turn could, depending on previous
implementation choices, have impact on performance tied to things like
locking semantics to ensure reliable updates to data structures.

Second, this creates a fixed per-NLRI set of additional performance
overhead. Consider the "marker" message alternative - how do the two
behave during very high demand periods, when significant route updates
occur due to major outages (and not only does a significant percentage
of the NLRI base get affected, but due to path-hunting, each NLRI is
likely to be revisited several or even several dozen times, in a short
interval.) Not tying the GR state to individual updates, is likely to
minimize the risk of GR degrading performance, at exactly the time
where degraded performance becomes a potential causative factor in
routing instability and further collapse of the routing
infrastructure.

Perhaps these questions could be addressed now, prior to adoption?

I'm in favor in principal of having GR enhanced, just not with the
specific manner embodied in the current draft, with all due respect.

(Currently: not in favor.)

Brian