Too complicated. Send the OPEN at whatever length it is. If it's rejected, then that's it. Nothing more to do.
At this point, manual intervention is required either to remove some configuration or to upgrade the neighbor. Thanks, Jakob. > -----Original Message----- > From: GROW [mailto:[email protected]] On Behalf Of Thomas Mangin > Sent: Thursday, March 09, 2017 6:54 AM > To: [email protected] > Cc: [email protected] > Subject: Re: [GROW] Do you want BGP to extend the message size for all BGP > messages or just UPDATES. > > Hi Randy, > > To never have to revisit this point, I would suggest for a capability > containing a char of value N, for the N extra > MESSAGE to be read before the KA, the extra MESSAGEs being OPENs, which > should have the Version to Identifier data > zero’ed (and ignored) with then the extra capabilities to be considered as if > they were present at the end of the > current OPEN. > > The extra OPEN being themselves up to 65k in size. > > Happy to provide an implementation to test against if we reach consensus. > > Thomas > > > On 9 Mar 2017, at 14:41, Randy Bush <[email protected]> wrote: > > > >> Thank you for sharing this scenario. It would indeed work at the small > >> cost (or perhaps not so small) to require an extra round trip at setup > >> time which is most likely un-avoideable whatever is done. > > > > then a double open. i.e. a 4096 open which has the extended capability > > exchange and then an optional extended open > > > > randy > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
