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
