Hi Pedro, On 21 Jun 2012, at 07:22, Pedro Andres Aranda Gutierrez wrote:
> 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. I think we have learnt from these incidents. During these incidents there were significant problems because sessions were torn down, and hence long-lived outages ensued. As is discussed at some length in the draft, this is not desirable for some operators, and in some operational deployments. The requirements outlined in this document are intended to provide means by which an implementation may balance the risk of inconsistency of routing information against preserving network operation. Primarily, therefore the requirements work out how to minimise the impact to overall network integrity during these cases, and then how to give operators much better visibility into what's happening. It should be noted that where incidents that cause erroneous UPDATE messages occur today, a session MUST be torn down - and therefore a service outage is guaranteed for the subset of routing information carried by this session. Therefore your >6hr period is an outage, rather than a period of degraded service operation. In both the cases that you have described, it seems like the assumption has been made that the advertising speaker is directly responsible for the erroneous nature of the UPDATE message. If we look at the AS4_PATH issue that we had in the DFZ a few years ago, the speaker that sent the UPDATE message was not responsible for the malformed contents of the attribute. In this case, there is little that the advertising speaker can actually do when one lets him know that he's sending "stinking packets". If there are specific requirements that you don't feel are addressed in this document (particularly around the logging mechanisms), it would be great to hear about them. I've been working with a relatively large number of operators (many of whom do not not participate directly in the standards development process) and feel that this document is a good representation of these requirements. Kind regards, r. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
