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

hi,all,
	I think my inital question is why the protocol has 4K limit
on messages sizes,that is different from the
implementation,an implementation may chose to use large read
or write buffer(>4K) to handle multiple updates one
time,still my question is if message size limit is a good
pratice in protocol design?
Yours,Fenggen

>Then why not other limit,how is 4096 bytes derived,
thanks.BTW,whether it's a good pratice in protocol devise to
limit message sizes?I see in ripV1 that the maximum PDU
length is 576bytes its reason is to avoid IP
fragmentation,but in ripng the PDU length is determined only
by the link MTU,and in snmp i also doesn't see the message
size limit. 
>Yours,Fenggen
>>
>>On Jun 13, 2007, at 10:01 PM, Fenggen Jia wrote:
>>
>>> hi,all,
>>>       I am wondering why BGP has 4096 bytes
limit on all its  
>>> messages,should we leave it to the
implementator to decide,thanks!
>>
>>
>>Well, the problem with that is that a sender could
then create an  
>>arbitrarily long message, which could be arbitrarily
problematic for  
>>a receiver.
>>
>>Tony
>>
>
>
>
>
>_______________________________________________
>Idr mailing list
>Idrietf.org
>https://ww
w1.ietf.org/mailman/listinfo/idr

= = = = = = = = = = = = = = = = = = = =
			

¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ÖÂ
Àñ£¡
 
				 
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Fenggen Jia
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡fgjiamail.zjgsu.edu.cn  
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2007-06-18

_______________________________________________
Idr mailing list
Idrietf.org
https://ww
w1.ietf.org/mailman/listinfo/idr

On Jun 17, 2007, at 6:12 PM, Fenggen Jia wrote:

> 	I think my inital question is why the protocol has 4K
limit on  
> messages sizes,that is different from the
implementation,an  
> implementation may chose to use large read or write
buffer(>4K) to  
> handle multiple updates one time,still my question is
if message  
> size limit is a good pratice in protocol design?


Hmmm, ok, I guess we haven't been explicit enough.  I'll try
again:

1) First, an implementation should NOT be using a message
size that  
is different than the specified 4k message size limit.  If
an  
implementation sends messages more than 4k, then other  
implementations will not be able to parse them.  If an
implementation  
cannot receive 4k messages, then it will also not be able to
 
interoperate.

1a) Having a fixed size is good because it makes the
protocol  
implementations easy.  There is no point to having
complexity in an  
implementation if it provides no benefit.  Large messages
don't  
provide a wonderful benefit, as they need to be large enough
to carry  
the path attributes and associated prefixes.  For this
purpose 4k is  
probably adequate to date.

1b) Historically, 4k was considered a bit wasteful.  Of
course, it  
was wonderfully simple compared to EGP which used fragmented
 
packets.  Care to parse a 16k jumbo-gram?  Care to debug
that?  Trust  
me, it's not fun.

2) The 4k message size is *completely independent* of the
TCP window  
size.  An implementation is perfectly free to compose any
number of  
messages, each of which is within the 4k limit.  The
implementation  
can then cram any number of messages into its TCP socket, up
to the  
buffering limits of that TCP.

2a) Thus, the message size is *NOT* performance limiting,
except when  
an implementation could actually overfill a message.  Folks 

maintaining current implementations might chime in here as
to whether  
or not they see this.

So, in summary, yes, a 4k message size limit is a fine
situation *for  
BGP*, for the way that it behaves and the job that it does. 
This  
does *NOT* necessarily generalize to other protocols, (e.g.
OSPF)  
where 4k exceeds the most common MTUs.  In those cases,
you'd end up  
with fragmentation, and that's bad.

Regards,
Tony

_______________________________________________
Idr mailing list
Idrietf.org
https://ww
w1.ietf.org/mailman/listinfo/idr