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

[Jeff Wheeler <[e-mail]>]

On Mon, Dec 10, 2012 at 4:50 AM,  <[e-mail]> wrote:
>>http://mailman.nanog.org/pipermail/nanog/2012-November/053754.html
>
> In that specific case, it was not a BGP protocol error, but a bug in the router receiving the UPDATE. i.e. draft-ietf-idr-error-handling would not change this.
> However, this is an example that error in flags, including in well known attributes, may happen.

It is also an example of when more choices for fault handling would
have significantly reduced the operational impact on networks who had
the buggy routers.  If my customers who had OpenBGPd could simply
configure their router like, "bgp fault-tolerance attribute-malformed
treat-as-withdraw" they could have got themselves back online.

Because this is not allowed by the current BGP protocol, vendors have
disincentive to provide such flexibility, even though it could
sometimes help customers.  I understand why vendors do not want to
give their customers "too much rope" but as the uses for BGP continue
to expand, and more new code and new vendors continue to use it within
the network, vendors are likely to find that customers demand more
choices for handling malfunctions.

> And in general, I agree with Jeff & Rob: BGP is mission critical to networks. Shutting it down for a wrong flag/bit should not be the first option.

I would like to show a detailed example of a mistake that is not in a
TYPE or LENGTH field can make it impossible for the router to know
what prefixes are in an UPDATE.  Chris's post focused on "framing
errors" but these are unfortunately not the only kind of errors that
are serious.

Imagine if a route is originated with MPLS labels in the reachability,
and the bottom-of-stack bit is not set on any of the labels.  Do you
know what happens?  Receiving routers are not only unable to decide
what to do with this update, they can't even figure out what prefixes
the update is for, because the bottom-of-stack bit indicates to the
receiver where the prefixes actually begin.  In effect, the label data
is part of the framing.

I have made notes and illustrations on RFC3107 Pg3:
http://inconcepts.biz/~jsw/img/1120824-rfc3107pg3.jpg
Sorry this is hand-drawn and scanned into the computer but it is legible.

What should your router do if it can't even figure out what prefixes
are being updated?  It can't "treat as withdraw" but some option
better than close the session should be permissible.

I really think a wholesale modification to the BGP protocol will
eventually be necessary because of all the new uses for BGP.  Yes,
MP-BGP is allowing it to do new things, but not with the kind of fault
tolerance that customers should expect.  Improving the choices for
handling faults is clearly a good effort.  However, it is unfortunate
that there are so many kinds of bugs which require the router to make
potentially unsafe guesses.

Until there is a BGPv5 with an improved approach to length encoding
and more resilience against faulty implementation on one device
cascading to others in the network, we will continue to have
questionable solutions to bad problems.  I think it's important to
realize this so myopia about BGPv4's limits does not discourage anyone
from wanting to make it as robust as possible If The Operator decides
to configure his router using vendor-supplied robustness options.

-- 
Jeff S Wheeler <[e-mail]>
Sr Network Operator  /  Innovative Network Concepts