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

[John Leslie <[e-mail]>]

Brian Dickson <[e-mail]> wrote:
> 
> It is unfortunate that UPDATE messages do not have any sort of identifier.

   Indeed! One hopes BGP5 won't suffer from this...

> 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.

   The downside, of course, is that the sender needs to agree to do so.

   But IMHO, we're not going to get fully "safe" error recovery without
involving the sender. (There is a sign in my office, which everyone
who has worked here has had to "write 100 times," saying, "Error
correction is the most error-prone operation in computing.")

> 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?

   There are various ways to do this. I, being a bear of small brain,
chose to do it with a new message type, thus entirely removing any
question of pulling it out of an UPDATE message. (In BGP5, it should
be a required field early in the UPDATE!)

> 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?

   Actually, this wouldn't be hard, provided the receiver gives a prompt
enough signal that an UPDATE has been "successfully" received.

> Otherwise, this would mean having to hold onto UPDATEs for possibly longer
> than desired.
> (LRU for buffer management is so very convenient when it is available, of
> course. Pack rat coding rules.)

   But all the sender really needs to save is the NLRI(s) deserving to
be withdrawn. That's a smaller amount of data...

> 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.

   IMHO, the ACK needs to be further up the stack. Sooner or later we'll
run into a case where the error is only apparent in "context", but the
proper correction is to back out the UPDATE and ask the sender to
generate a "safer" version of it.

> (I think this is more reliable, but again requires changes to both ends.
> The net benefit can be substantial, in terms of not having to "just guess"
> when the UPDATE is already known to be busted.)

   Exactly!

--
John Leslie <[e-mail]>