Almost no one has commented on whether or not a capability code should be used to re-order the contents of BGP Messages, and Attributes, as suggested by error-handling.
This is really important if error-handling is to rely on such re-ordering. Many folks are saying error-handling needs it, the draft says it, yet no mechanism is proposed to do it? The closest thing is a recommendation in RFC4760bis but it is the opposite of what RFC4271 recommends. You can't actually know if your neighbor plans to follow this new recommendation because there's no way to signal that intent. In short, I suggest RFC4760bis should add a second capability that indicates the BGP speaker promises to send the MP attributes before all other attributes, as it recommends. I further suggest any re-ordering of native NLRI information in the Message needs to be addressed .. somewhere. On Fri, Jan 4, 2013 at 12:02 PM, Tony Li <tony...@tony.li> wrote: > That's reasonable for off-by-one, but that's not the only possible mistake. > It's easy to have an inconsistency which is in the tens or hundreds of bytes. > Now what? We could again check both alternatives, but again, the presence > of a Marker, even in one of the possible locations, is no guarantee. You > could easily skip over an entire message, for example, and end up ignoring > two updates, not just one. I'm glad you raise this possibility. Indeed, if you tried to re-sync the message stream by searching for a MARKER, you might skip many messages without realizing it. The potential damage to the RIB is high, so it is a high price to pay to avoid session-reset. > I agree that the Message Length will either be correct or it won't. Now, all > us need is an oracle (the computer science kind ;-), to tell us which is > which. Got any handy? ;-) As you know, when more data arrives from the neighbor, you can make a good guess based on the marker. I don't think divine intervention is necessary. On Fri, Jan 4, 2013 at 1:27 PM, Jakob Heitz <jakob.he...@ericsson.com> wrote: > Or waiting for a very long time for that marker to arrive. > Suppose the length is 40. You think it's 4000. You will sit > there patiently for an eternity waiting for more bytes to > arrive so you can read your next marker. Sure, but this is not different than many other cases where the neighbor fails and you sit there waiting for HoldTime to expire. -- Jeff S Wheeler <j...@inconcepts.biz> Sr Network Operator / Innovative Network Concepts _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
