Jakob Heitz wrote (on Fri 31-Aug-2012 at 17:20 +0100): > On Aug 31, 2012, at 12:55 AM, "Chris Hall" wrote: > > 2) or, more directly, by: > > > > * adding an UPDATEv2 message type > > > > * and Capability, > > > > to completely separate NLRI from Attributes. > That does not "completely separate". You can separate with a FIN/SYN > or put them into different packets: use UDP instead of TCP. With > TCP, you are always at the mercy of length fields. Perhaps I got a little over-excited, and overstated the degree of separation. But by moving the NLRI up a level, out of the mish-mash of Attributes (back to the top level of the UPDATE where they were originally), then at least extracting the NLRI from the message is not tangled up with trying to decide how to make sense of a broken set of attributes. Particularly as the whole point of the exercise is to minimise the impact of broken sets of attributes. > I mean, if you are going to require both ends of a connection to > upgrade... The recommendation is that MP_REACH_NLRI and MP_UNREACH_NLRI are moved to the front of the attributes, so that they are less vulnerable to problems in other attributes. That is an upgrade. But, as I said, I don't think that is sufficient. The receiver needs to know that the sender is going to do that -- because otherwise the absence of MP_REACH_NLRI and MP_UNREACH_NLRI is ambiguous. Which requires a capability. That is also an upgrade. To be fully effective, improvements to the error handling will involve an upgrade. In which case, I suggest, one could go back to the future and disentangle NLRI from Attributes. Chris