Subject: [GROW] Code nannies (Re: Do you want BGP to extend the message size for all BGP messages or just UPDATES.)

From: heasley <[email-masked]>
Date: Thu, 9 Mar 2017 16:56:45 +0000

Thu, Mar 09, 2017 at 12:20:43PM +0000, Nick Hilliard:
> First, it's not guaranteed
> that some badly coded bgp stack wouldn't crash with a 4097 byte OPEN
> message, and secondly, you're not guaranteed that just because the stack
> supports 4097 bytes on open due to e.g. unintentional coding reasons,
> that it actually supports 4097 bytes by design and that it actually
> works properly.

Ignoring support or opposition for the topic of the thread, why should
the ietf concern itself with programming (and testing) incompetency of
this magnitude?  The RFCs should document the procedure to negotiate
the capability, not endeavor to design for every possible programming
error.

> Nick
> 
> Susan Hares wrote:
> > Thomas: 
> > 
> > It is possible to create an option that requires implementation support
> > extended messages upon receiving a notification.  If the sequence is: 
> > Open-(4097 bytes) --> 
> >              <-----notification (with indication message length is too long)
> > 
> > 
> > (sequence allowed RFC4271 current FSM) 
> > The extended messages would know to back down to 4096 and negotiate forward.
> > This would not let your BGP speaker get stuck.  It seems reasonable to make
> > the code take care of this problem rather than have a crisis in an
> > operator's day. 
> > 
> > Open (< 4096) bytes) ---> 
> > 
> > Just let us know what you want. 
> > 
> > Sue 
> > 
> > 
> > -----Original Message-----
> > From: Thomas Mangin [mailto:[email-masked]] 
> > Sent: Tuesday, March 7, 2017 4:39 PM
> > To: [email-masked]
> > Cc: Susan Hares
> > Subject: Re: [GROW] Do you want BGP to extend the message size for all BGP
> > messages or just UPDATES.
> > 
> > Hello Nick,
> > 
> > I can see one reason why it would become undesirable in the future: 
> > 
> > If a then recent speaker, with support with this draft/RFC, and with a
> > yet-to be defined large number of capabilities, happened to generate an OPEN
> > message of 4097 bytes (to match its configuration), this OPEN would most
> > likely be seen as invalid by current implementations not supporting the
> > extension.
> > The excessive/invalid length when checking the OPEN message size will surely
> > caused the session to be terminated.
> > 
> > It would therefore prevent any session to come up (even if otherwise
> > everything is fine). Therefore should this size extension be applied, it
> > should be applied to all message types BUT the OPEN message. I think we are
> > currently not near needing 4096 bytes for OPEN (but the day will/may come).
> > 
> > ExaBGP would suffer from this issue as the check is currently performed on
> > ALL messages as currently specified including the OPEN.
> > 
> > So I would suggest to just change the wording to include all message type
> > but OPEN, and leave it as an exercise to the reader to write another draft
> > allowing to break capabilities over multiple messages.
> > 
> > Sincerely,
> > 
> > Thomas
> > 
> >> On 7 Mar 2017, at 21:08, Nick Hilliard <[email-masked]> wrote:
> >>
> >> Susan Hares wrote:
> >>> This email is to make you aware of the discussion on the Extended
> >>> Messages draft (draft-ietf-idr-bgp-extended-messages-21).   Do you
> >>> want the message size extended for all BGP messages or just UPDATE
> >>> messages?   This probably is more important if you want to have a
> >>> larger size OPEN, ROUTE-REFESH, and UPDATES.    The IDR co-chairs
> >>> value the operational input from GROW WG.
> >> I don't see any reason an extended message size should be limited to 
> >> just UPDATEs. Enke's suggestion for handling the single anomalous case
> >> (OPEN) looks reasonable.  I'd say, go for it!
> >>
> >> Nick

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 09 Mar 2017 17:41:20 +0000

> the capability, not endeavor to design for every possible programming

because bgp is way down there at the bottom of the stack and when it
breaks, it can cause a great deal of trouble.  We all know about the
canonical bgp breakage incidents.

I don't disagree with you, btw, but this is a binary decision based on
fuzzy inputs, and this being an operational WG, expressing operational
concerns is fine.  It would be nice if we had some data on the issue.

Nick