Re: [Idr] why has 4096 bytes limit on BGP messages size?

In message <0D5A1AAC-03A5-468B-8D56-9FE5818BF5A0@tcb.net>
Danny McPherson writes:
>  
> In RFC 1105 the maximum message size was 1024 octets.  I suspect
> because RFC 1163 added the capability to support multiple prefixes
> (i.e., compression/update packing) they bumped the size to 4096. Note
> that RFC 1163's Appendix 2 states the UPDATE format was changed
> to support multiple "path attributes", when I think they actually meant
> multiple "prefixes".
>  
> As for why it was constrained in the first place, RFC 1164 talks to this
> a bit in section 6.3.  In particular, I suspect the size was constrained
> initially because of this:
>  
>     Due to the stream nature of TCP, all the data for received messages
>     does not necessarily arrive at the same time
>     [...]
>     This can make it difficult to process the data as messages,
>     especially on systems such as BSD Unix where it is not possible to
>     determine how much data has been received but not yet processed.
>  
> One might hypothesize that the selection of the original value of 1024
> had something to the 4.2 BSD-derived systems TCP segment size
> common settings of 1024.
>  
> RFC 1267 incorporated some of the RFC 1164 text directly, in section
> 5.2.
>  
> Of course, I'm just a youngster compared to some of the old folk here,
> especially Yakov, so I'll happily defer  ;-)
>  
> -danny

Danny,

The code back then in rcp_routed and gated, the research reference
implementations (and running code on the NSFNET), was not written by
experts in BSD socket programming.  The code had problems with partial
reads of a BGP update and had even more trouble with a block on the
write (just gave up and reset the BGP session).  It did sort of work
though and implementations have gotten better.

Anyway, we still get lots of prefixes into a BGP update so unless
there is some motivation to increase the 4KB update size limit why
bother?  Maybe it would be more efficient to collect up all the prefix
changes with a common set of attributes and send the whole thing no
matter how big.  If so, lets continue the conversation when someone
has strong evidence that this is the case.  Until then...

Regards,

Curtis

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr