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

[Brian Dickson <[e-mail]>]

On Mon, Dec 10, 2012 at 2:54 PM, Jeff Wheeler <[e-mail]> wrote:

> On Mon, Dec 10, 2012 at 12:52 PM, Chris Hall <[e-mail]>
> wrote:
>
> > Well, that's an interesting idea :-)  If the only important thing to
> > extract from a broken set of attributes is the NLRI, then why not scan
> > for it and assume that there is sufficient redundancy to effectively
> > rule out false positives.  Interesting :-)
>
> I don't know what other way would be sensible.  The other attribute
> information is not needed to effect a withdraw, only the NLRIs
> themselves.
>
>
It is unfortunate that UPDATE messages do not have any sort of identifier.

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.

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?

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?

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

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.

Thoughts?

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

Brian