On Fri, Jan 4, 2013 at 7:34 PM, John Leslie <[email protected]> wrote: > Lacking a TLV structure for messages, we should not let go of a > marker which separates messages.
Even if you were inventing "BGP 5" and you cleaned up all the messy extensions and implied field lengths, I think you would be persuaded to keep MARKER around as a good "dummy check" on the message stream. Historically, protocol designers have often conserved octets because it seems like a good way to keep protocol overhead low. For control-plane protocols whose encoding/transmission overhead is insignificant, this has sometimes produced poor results. On Fri, Jan 4, 2013 at 7:49 PM, Jakob Heitz <[email protected]> wrote: > Sorry, that's not what I meant. > I meant a future operational message that says > "this update message caused me a problem and here is > the update message for your reference". It is a copy of > the message, not actually a replay. I liked your idea the first time I read it, and I continue to like it. This would be VERY helpful for troubleshooting. We had some discussion before about what would happen if the original message, being echoed back in a "this was broken" for diagnostic purposes, could not fit into the maximum message length for the session. What if you didn't include the original Message header, the MARKER, Message Type and Length? Your "broken message" echo Message would then be exactly the same Length as the bad one so it would definitely fit in the maximum length, and you don't need to tell the other side what the original Length was because it will know by the Length of your echo Message. As long as it is only for "broken UPDATE" and not for other kinds of messages, then you don't need to encode the Message Type field. The only downside is it wouldn't work for anything except a broken UPDATE, and it would need to be extended in the future if new types of messages are added to BGP. These seem like reasonable limitations though. On Fri, Jan 4, 2013 at 6:44 PM, Chris Hall <[email protected]> wrote: > An option to resync on Marker etc, as a last-ditch, > keep-the-session-up-at-all-costs measure, doesn't seem that difficult > to me -- and wouldn't (key consideration) interfere with code for > normal running. I don't think it's that difficult either, but I do not know if the cost of implementing it is worth the reward. Attribute errors are things that, historically, we've seen propagate through the DFZ (and they might inside a datacenter network too) and the cost of dealing with them is probably going to be worthwhile. A message length error isn't going to cascade through anybody's network right now, let alone cross domain boundaries; so is it worth doing? I only brought up re-sync because it is possible to do and it might have some limited value if we had Jakob's "i got this bad message, here it is" feature. I'm still not necessarily advocating the re-sync idea. -- Jeff S Wheeler <[email protected]> Sr Network Operator / Innovative Network Concepts _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
