On Jan 4, 2013, at 9:54 AM, "Smith, Donald" <[email protected]> wrote:
>> In short, treat-as-withdraw is a fail safe approach. Ignoring updates >> is not. > But in a peering world you have potentially just withdrawn all of your routes > to a peer from that peer. > > You will now prefer some other peer for all of that peers traffic (or another > connection to that peer in another location). > > If you can ignore a single update error from a peer while you troubleshoot > the issue with that peer it would allow a better path for the rest of that > peers announcements. Again anything with a overrun or under run issue sort of > implies the rest of the updates from that point forward are > corrupted/untrustworthy. > Can you detect overrun and under runs without FPs or FNs? Probably not in all > cases. > Donald, As I would implement treat-as-withdraw, the scope of the withdrawal would ONLY be for the message in question, and again it would only apply to semantic errors where the NLRI could be cleanly extracted. So only the prefixes in error would be affected, not necessarily everything from that peer. Detecting overrun and under run is not too hard. Again, the most common cases are when the Message Length and TLV lengths are inconsistent. The presence of the marker for the next message and a sane length field for the next message are also helpful checks for detection. Again, some kind of redundancy for framing would have been a better long-term design. I'll note that if folks are sufficiently motivated, this COULD be retro-fit. Add an attribute that is a CRC-16 of the entire message. Tony _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
