Jakob Heitz wrote (on Fri 31-Aug-2012 at 18:38 +0100): > UPDATEv2 is also inadequate. If we are agreed that the current proposals are inadequate, then we are agreed on something. > Either, you have a fix that does not require the other end to > upgrade or you fix it properly. Without an upgrade to improve the ability to extract the NLRI when Attributes are broken, the fix is incomplete. I look forward to a proper fix. Chris > -- > Jakob Heitz. > > > -----Original Message----- > > From: Chris Hall [mailto:chris.hall@xxxxxxxxxxxxxx] > > Sent: Friday, August 31, 2012 10:07 AM > > To: ietf@xxxxxxxx > > Cc: idr@xxxxxxxx; Jakob Heitz > > Subject: RE: [Idr] draft-ietf-grow-ops-reqs-for-bgp-error- > handling-05 > > > > 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