On Tue, Sep 17, 2019 at 11:36:18PM +, john heasley wrote:
> Mon, Sep 16, 2019 at 10:36:59PM +0200, Claudio Jeker:
> > > And what if I make it 675 ASes instead and watch sparks fly as a few
> > > hops away routers hit the 4096-byte BGP message size?
> > >
> > > Or I make it 700 ASes with only a 16-bit AS path or a truncated 32-bit
> > > AS path, so the first 32-bit router that tries to create a 700-hop
> > > 32-bit AS path exceeds 4096 bytes?
> >
> > You are applying a band-aid to a broken bone. There is many more ways you
> > can push an UPDATE to over 4096 bytes. Using AS path alone is probably the
> > least successful. There are many more transitive attributes that you can
> > use to bloat an update. So whatever limit you come up with will not
> > protect you from tripping over the message size limit.
> >
> > It would be great if there is a standards document properly describing
> > what to do in such a case because this is one of the underspecified corner
> > cases in the current spec.
>
> isnt this rfc7606
I only see input related checks in rfc7606 and there is nothing describing
what to do when the total lenght of an UPDATE exceeds 4096 bytes. At least
I did not spot it.
draft-ietf-idr-bgp-extended-messages-36 has a paragraph covering how to
handle oversized messages:
A BGP speaker that has advertised the BGP Extended Message capability
to its peers, may receive an UPDATE from one of its peers that
produces an ongoing announcement that is larger than 4,096 octets.
When propagating that UPDATE onward to a neighbor which has not
advertised the BGP Extended Message capability, the speaker SHOULD
try to reduce the outgoing message size by removing attributes
eligible under the "attribute discard" approach of [RFC7606]. If the
message is still too big, then it must not be sent to the neighbor
([RFC4271], Section 9.2). Additionally, if the NLRI was previously
advertised to that peer, it must be withdrawn from service
([RFC4271], Section 9.1.3).
Hopefully implementations will pick up this approach independent from the BGP
Extended Message Capability.
--
:wq Claudio
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
