Hi Pedro,
> I think we have still not learnt from the 2009 incidents,
I think we actually did. The number of IETF documents are trying to
address this both in IDR and GROW WGs.
It is just that it takes 2-3 years to come up with RFC and another 2-3
years to implement such RFC these days .... Not to mention product
marketing/management asking left and right about business case and
frankly speaking operational quality improvements are not on top of
their revenue generating list of enhancements ;(
Best,
R.
OK, then let's state that operational messages (DUMP with malformed
packet) shall be used to notify the neighbor. The ideal scenario for
me is:
1.- Someone sends me a stinking packet and resets my router: I'm able
to notify him back automatically and then, if he doesn't react I can
a) shut the session down and b) ask him why he didn't react.
2.- I'm sending stinking packets: I receive a trap after I sent the
first and I can shut the router/session down and rollback any changes
or investigate where that stinking packet came from, and why it was
rejected.
I think we have still not learnt from the 2009 incidents, where it
took more than 6 hours to bring the situation back to normal and
that's a pity.
/PA
On Thu, Jun 21, 2012 at 7:48 AM, Jakob Heitz <[email protected]> wrote:
http://tools.ietf.org/html/draft-ietf-idr-operational-message-00
On Wednesday, June 20, 2012 10:24 PM, Pedro Andres Aranda Gutierrez <> wrote:
I completely agree with the need to send as much root-cause info as
possible. I think that the user (i.e. admin of the router receiving
wrecked BGP-4 updates) has to be informed. But I also think it would
not do any harm to inform the neighbour causing the crash (à la "you
killed me with this packet!!!"). This information has to be used to
inform (via trap, log, etc.) the admin of the router causing the
damage, so that he takes action ASAP.
My .2 cents,
/Pedro A. Aranda
On Tue, Jun 19, 2012 at 5:05 PM, George, Wes
<[email protected]> wrote:
I've read this draft and I think it is useful and ready to proceed.
Two minor comments:
In section 4, it may be useful to specifically note the need for a
flag, trap, or other notification method (to the user, rather than
to the neighbor) to identify when BGP is in the process of
recovering RIB consistency, including which routes are considered
inconsistent (if this info is available). While section 6 discusses
the need for more information about the state of BGP when it is
recovering from these errors, I saw no reference to this specific
item. Since this is likely to be a transient state, it is also
helpful to log this information to aid in root cause analysis of
transient problems.
--
Jakob Heitz.
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
