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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



UPDATEv2 is also inadequate.

Either, you have a fix that does not require the other end to upgrade
or you fix it properly.

--
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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]