Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt

[Jeff Wheeler <[e-mail]>]

On Mon, Dec 10, 2012 at 3:25 PM, Brian Dickson
<[e-mail]> wrote:
> It is unfortunate that UPDATE messages do not have any sort of identifier.

My knee-jerk is that I am not very excited about your idea, but it is
useful to point out that LDP has message identifiers.  LDP needs to
keep more state around about pending LSP setup to support ordered
mode, merge, and downstream on demand, but there are also useful
diagnostic messages that will include the original message ID when
various fault conditions are observed.

> It would be nice to be able to have the receiver send a NOTIFICATION that
> says, in effect, UPDATE #foo was garbled, please send JUST the afi/safi &
> NLRI so I know what to ignore.

If this happens the NOTIFICATION should be responded to not with an
ordinary UPDATE but with one that is either a new Message Type or else
an UPDATE that has a very unambigious field which is sure not to be
confused or corrupted, signaling that this is a re-try of a previous
UPDATE and, if it can't be parsed, don't make that same NOTIFICATION
again.

But if your ultimate attempt is to ask the peer for the information
you need to effect a WITHDRAW, then you could just invent a way to
demand the peer send you that WITHDRAW.  The cool thing about that is,
then the peer can actually have knowledge of what route is broken.  It
could save that information to support investigation of the problem on
both sides of what may be an eBGP session.  At minimum, it could mark
the RIB entry so it knows that route is not advertised to you, and
this could be available on the CLI.

Now, I am not thinking that anyone will jump to implement your idea,
but my knee-jerk was "oh no!" and really, your idea has real serious
technical advantages.  Of course you observe that it has some
disadvantages too (more state on sender side.)  If one were inventing
"BGP 5" surely this ability would be sensible.  Maybe it is even a
sensible Capability for BGP today.  After all, the vendor can always
allow the operator to deactivate the Capability if they wish.

> Maybe this could be handled via another UPDATE Attribute - the
> identification for an UPDATE itself?
> Then refer to this in the appropriate NOTIFICATION, type 3, new subtype,
> with parameter identifying the problem UPDATE?

As long as the sender doesn't respond with another UPDATE that gets
confused and results in another NOTIFICATION in a loop.  But that is
fixable like I describe above.

> Then there is the question of the original UPDATE (generally on-the-fly
> data). If the error happens soon enough, maybe the sender still has the
> UPDATE in his/her outgoing TCP buffer?

The sender won't have the UPDATE in his TCP buffer because it is
basically guaranteed the receiver will already ACK that segment,
either before or when sending the NOTIFICATION, unless some deep TCP
stack tweaking is done to effect this.  Since the segment is ACK'd
then it will be free'd on the sender side, as there is no reason to
keep it around.  Also, extracting the *malformed* UPDATE NLRI out of
the TCP send buffer to then try to re-send it sounds like a good way
for both the sender and receiver to get confused.

But even if your specific notion of reaching into TCP is bad, your
concept is good and fooling around with TCP just isn't a very good way
to implement it.  The vendors can of course choose to implement it
however they please.

> Otherwise, this would mean having to hold onto UPDATEs for possibly longer
> than desired.

I guess there is no free lunch, but what costs does your idea have
other than spending some RAM to be capable of re-sending the NLRI from
a recent UPDATE, and a little bit of CPU to manage the structure
storing these recent UPDATEs?

> And of course, this pushes the "ACK" further up the stack, from TCP to the
> parent application (BGP). Again, maybe not that bad an idea, but definitely
> non-trivial.

Either it provides a fault tolerance mechanism at the cost of some
RAM+CPU and the sender evicts the information needed to re-send NLRI
after some timeout or memory limit has been reached, or else BGP
Advertisements become less of a simple advertisement and a little
closer to a request/response, except the response isn't anything more
than "understood," not like LDP where responses are requests for LSP
setup, etc.

Anyway, I think your idea is clever, but has about zero chance of
being liked by most people, because it is not that easy to implement
and the frequency of need for it to actually mitigate or prevent an
outage is extremely low.  If I were inventing "BGP 5" I would not
include the requirement for a sender to be able to re-transmit
information from an already-transmitted Message because this could
really be difficult on route-reflectors after major events, certainly
on ASBRs at IXPs or with many eBGP customers receiving DFZ, IXP
route-servers, and so on.  Instead I would just invent BGP 5 to have a
more robust Message structure and be done with silly errors that are
difficult to recover from.  By the time you go to the effort to
program your feature, you might as well just program a superior
Message structure and not have any CPU/RAM expense for
already-transmitted data.

Just my $0.02.
-- 
Jeff S Wheeler <[e-mail]>
Sr Network Operator  /  Innovative Network Concepts