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

[Enke Chen]

Hi, Folks:

Let me add some specifics:

Case 1: large OPEN only

  If the local speaker is only interested in getting the session established 
using a
  large OPEN, then it SHOULD go ahead with the large OPEN and deal with the 
issue
  administratively upon receiving a NOTIFICATION due to the large OPEN size. In 
this
  case the remote speaker has to be upgraded to support the large message 
capability.

Case 2: Prefer a large OPEN, but can live with a normal size, predefined OPEN

  Option 1: Start with a large OPEN. In case a NOTIFICATION is received due to 
the
large OPEN size, fall back to using the predefined normal size OPEN.

  Option 2: Start with the normal size OPEN. If the OPEN from the remote speaker
does not contains the large message capability, proceed with the 
session
establishment.  Otherwise send a CEASE message (with a new subcode) 
and
terminate the session (before sending the KEEPALIVE), and then 
start a
new session with the large OPEN.

  With either Option, there should be no impact on the GR or LLGR as the session
  did not reach the ESTABLISHED state with the first OPEN.

  Option 1 is more preferred when the local speaker has the knowledge that the
  capability is supported by the remote speaker based on the previous OPEN or 
via
  administrative means. It also does not require any new protocol definitions 
(like
  a new CEASE subcode).

  In addition, I believe that the large OPEN will not be needed any time soon 
and
  by the time it is needed the large message capability should have been widely
  deployed.  Thus I think Option 1 is good and there should be no need to 
specify
  Option 2.

Thanks.  -- Enke

On 3/9/17 6:41 AM, Randy Bush 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
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Thomas Mangin]

+1 - it makes lots of sense.

Thomas

> On 7 Mar 2017, at 21:08, Nick Hilliard  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
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Nick Hilliard]

heasley wrote:
> 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.

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

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[heasley]

Thu, Mar 09, 2017 at 12:20:43PM +, 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:thomas.man...@exa.net.uk] 
> > Sent: Tuesday, March 7, 2017 4:39 PM
> > To: grow@ietf.org
> > 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  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

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Thomas Mangin]

 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 2017-03-09 14:41, Randy Bush 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
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Randy Bush]

> 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
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Thomas Mangin]

 Hi Nick,

Looking at Quagga, Bird, GoBGP (I took a few minutes to read
their code and I am not overly familiar with any of them), they all
seems to perform the 4096 bytes check and send NOTIFICATION, so I would
only expect badly home brewed solution to suffer from the issue (not to
say we should not care).

That said, I would also assume the code path
for this scenario has never been run in production (and perhaps ever) in
the life of any BGP implementation so while it may look good, it may not
do what is expected. I believe some "real" world testing is in order


Thomas

On 2017-03-09 12:20, Nick Hilliard wrote: 

> Sue: I'd be
cautious with your approach. 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.
 ___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Thomas Mangin]

 (Resending as I previously use an email address which is not
registered on grow)

Hello Susan. 

Just thinking out loud here ...


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. 

The issue
which keeps me thinking would be which capabilities/feature should
dropped in order to fulfil the 4096 bytes limit when the NOTIFICATION is
received. 

I would rather see the OPEN stay at 4096 and have an
"extended OPEN capability" than the Notification trick as otherwise
newer drafts/RFCs will otherwise not cover the point. 

If a extended
OPEN feature is added, new drafts can then decide to require the
implementation of this OPEN extension, making the split easy (current
capabilities in OPEN, newer in extension). Modifying the state machine
to include a new MESSAGE (or extra OPEN of 65k) should not be too hard
(I am sure you have heard the before :p) 

In every scenario, some
wording about the Connect(Retry)Timer and DelayOpenTime may also need to
be considered to make sure no large delay is introduced during the BGP
setup - re-sending an OPEN immediately after the NOTIFICATION or extra
OPEN/Message (if doing so does not cause an issue with the state
machine). 

At the moment, with all the current RFC and drafts
implemented, AFAIK we are still far from filling the OPEN, but perhaps
"we" should take the time to see what the sum of of the capabilities for
all the families is, to see what space is definitively left in the OPEN
.. 

It is not unreasonable to consider that a valid capability may need
some large space at some point ..
https://tools.ietf.org/html/draft-walton-bgp-hostname-capability-02 [2]
made me consider the size of the OPEN back in early 2016 - as I
implemented it "for fun" at the time - So in Jan 2016 and ExaBGP still
had 2*255 + 2 = 512 bytes spare in the OPEN but not much more AFAICR.


Sincerely, 

Thomas 

On 2017-03-09 12:20, Nick Hilliard wrote: 

>
Thomas: you have more experience with this and your advice sounds
>
reasonable.
> 
> Sue: I'd be cautious with your approach. 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.
> 
> 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:thomas.man...@exa.net.uk] Sent: Tuesday, March 7, 2017 4:39 PM
To: grow@ietf.orgCc: 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  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 

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

[Nick Hilliard]

Thomas: you have more experience with this and your advice sounds
reasonable.

Sue: I'd be cautious with your approach.  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.

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:thomas.man...@exa.net.uk] 
> Sent: Tuesday, March 7, 2017 4:39 PM
> To: grow@ietf.org
> 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  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
>>
>> ___
>> GROW mailing list
>> GROW@ietf.org
>> https://www.ietf.org/mailman/listinfo/grow
> 
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow