On Thu, Jan 3, 2013 at 2:35 PM, Michael Long <ml...@us.ntt.net> wrote:
> Either upgrade to fixed code or policy out the offending announcement.

You actually can't policy out the announcement on the receiving side.

This is why I continue to state that you need help from external
parties to solve these problems.  Vendor, BGP neighbor, etc.

When I got called because some of my transit customers were having
their sessions flap endlessly and their routers were logging errors
they did not understand, it took be about an hour to figure out what
prefixes were causing it.  That's because my router had equally poor
logging.  Then I asked the customers if they wanted me to filter out
the 5 bad prefixes from going to them.  That is what they needed until
they could upgrade their software.

On Thu, Jan 3, 2013 at 2:36 PM, Enke Chen <enkec...@cisco.com> wrote:
> A good argument (IMO) has been made in the error handling draft:
>
> ---------
> http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/
>
> 4. Operational Considerations
>
>    Note that "treat-as-withdraw" is different from discarding an UPDATE
>    message.  The latter violates the basic BGP principle of incremental
>    update, and could cause invalid routes to be kept.  (See also
>    Appendix A.)

I hope we all understand that treat-as-withdraw violates exactly the
same principle.  It just throws away routes which may be valid,
instead of keeping them.

I don't understand the perspective from which you are looking at this
problem.  From mine, there could be a buggy router in my AS, and it
could be withdrawing routes from its RIB.  Then other routers could be
trying to transit traffic across that router, which is then mis-routed
(could be looped) or discarded.

The error-handling draft does not keep the RIB in a good state.
Anyone who thinks otherwise is simply incorrect.

So treat-as-withdraw puts the RIB in a bad state.  Ignore-bad-message
puts the RIB in a bad state.  Exactly how it is bad differs, but
treat-as-withdraw in the current draft is very complicated and does
not provide a band-aid for "all" problems.  Ignore-bad-message is very
simple and provides a band-aid for more problems, including unforeseen
problems.

-- 
Jeff S Wheeler <j...@inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Reply via email to