On Sat, Jan 5, 2013 at 6:50 AM, John Leslie <[email protected]> wrote: > Actually, we could invent a message type which reflects the content > of a "bad" update, but it would only be useful for logging at the > sending peer for human perusal; and, to be useful to that human it > would need to classify the problem and indicate what part(s) of the > update have been acted upon.
I don't think the message necessarily has to describe the problem, but BGP already has some mechanisms for this. If a receiver detects a malformed attribute, it will send a Notification with the bad attribute in the Data part of the notice. So the existing Notification will at least tell you about that. Imagine if you are an ISP and your customer's router is complaining of bad messages and resetting the session. His logging is not good so you don't have very much information to go on. Maybe you get a malformed attribute notice but your routers don't have any way for you to search for what paths carry that attribute. You will be debugging for a while! If the customer's router sent you the whole message you could troubleshoot the problem more quickly even if the customer router doesn't tell you why it choked on the message or produce any useful log entries for the customer tech. > Under no circumstances should we do this without making its length > abundantly clear -- both the length we assumed when reading it and the > length of what we are returning (which need not be the same: humans > get the best value out of the first few hundred bytes in most cases). > In particular, if we detect 16-bytes of marker within it, we MUST NOT > return that marker un-escaped. I agree that returning the un-escaped MARKER could have unintended consequences! I think the whole message is useful ESPECIALLY if the NLRI are moved to the beginning of messages at some time in the future. After all, if they are moved, then attributes will be at the end of the message, so you might need them. If the "oh no" message is literally the bad message with a different Message Type, then you will get everything including what the receiver thought the length was. The only things you will not get is the original marker and message type. If you only generate "oh no" if the marker is believed to be legit and the Message Type was UPDATE, then these are implicit whenever you get an "oh no" message. > This would probably be the most helpful when we _don't_ expect to > be able to continue without a NOTIFY. We would need to send this only > to a peer that advertised the capability to log it; and that might > include the ability to recognize it _after_ the NOTIFY if we decide > that sending it before the NOTIFY is too risky... Actually if error-handling introduces the ability to treat-as-withdraw or ignore-bad-message then it seems like it will become useful to have this new diagnostic message even if the BGP session is not reset. That way both sides of the session have some diagnostic information about problems that are potentially being masked by the use of error-handling. -- Jeff S Wheeler <[email protected]> Sr Network Operator / Innovative Network Concepts _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
