Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RFC 1771, further thoughts

  • From: lucifer
  • Date: Tue Jun 26 23:02:01 2001

In an attempt to return to an argument, rather than simple contradiction
(ok, ok, it's far more polite and reasonable so far than that would imply,
but I couldn't miss the cheap shot; apologies hereby tendered), perhaps we
should consider *what* the RFC should say, if it should be changed? Going
to the WG with a proposal in hand and a rationale to support it would seem
to be the best path.

So, a summary of my view on it at the moment:

Assumption #1) Resetting a BGP session is 'costly'. Both in terms of the
time it takes, the stability it removes, and the fact that it flaps all
of your *outgoing* announcements as well as incoming ones.

Assumption #2) A router that sends a malformed route is clearly doing
something which it Should Not Be Doing (tm) (ok, this might be axiomatic,
but should still be laid out)

Assumption #3) The current practice has been shown to demonstrably
increase the brittleness of the Internet, by causing severe flapping when
someone only partially follows the RFC (in particular, propagating bad
route data, whether or not the origional source session is reset).

Assumption #4) Routing errors which are bad data, but *not* malformed
routes, will not generally be caught by normal means in normal operation,
until a case of human intervention to cross-check the data.

Assumption #5) Any router which breaks so badly as to start spewing large
amounts of validly formed but errorneous data, and is *also* spewing badly
formed data, will spew noticeable amounts of said badly formed data. (This
one is key, and is only a conjecture; field evidence would be of great use
in validating it).

Conclusion: changing the RFC from saying you MUST do a NOTIFY and ditch the
session could be adjusted to stating that you MUST handle the error in one
of two ways: do a NOTIFY and ditch the session (traditional), or send an
ALERT and discard the badly formed route. Additionally, this alternative
handling MUST NOT be enabled by default, and SHOULD have a threshhold
parameter at which the session will undergo a NOTIFY/reset, under the
assumption that the host sending an appreciable amount of badly formed
routes is, in fact, in danger of sending correctly formed but erroneous
data as well.

Suitable threshold values are left as an excercise to local admins and BCP
documents; I would think this could be negotiated as a capability extension
to BGP4, with the fallback, of course, being to follow the traditional RFC
practice.

Thoughts?
-- 
***************************************************************************
Joel Baker                           System Administrator - lightbearer.com
lucifer@lightbearer.com              http://www.lightbearer.com/~lucifer




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.