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