ietf
[Top] [All Lists]

RE: [Idr] draft-ietf-grow-ops-reqs-for-bgp-error-handling-05

2012-09-04 10:25:00
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(_dot_)hall(_at_)highwayman(_dot_)com]
Sent: Friday, August 31, 2012 10:07 AM
To: ietf(_at_)ietf(_dot_)org
Cc: idr(_at_)ietf(_dot_)org; 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