Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)

[Robert Raszuk <[e-mail]>]

Hi Bruno/all,

“A protocol designer or network operator needing to advertise, outside of
> its AS, a BGP route which size would require a BGP message larger than 4096
> octets should take into account that it has no guarantee that its route
> will be propagated as expected as a downstream BGP speaker might not be
> compliant or might not has enabled BGP extended messages and hence will not
> propagate the route. This is especially the case if one expect Internet
> wide propagation of its route, which seems highly improbable until a few
> years/decades”.
>


​The above text which very true triggered few more observations:

​- As this is WG last call implementation report (even on the wiki should
be available) Can we get a pointer to it ? I do not see it on the IETF page:
https://www.ietf.org/iesg/implementation-report.html

- Did implementation report (if even completed) included the set of test
cases say with large AS_PATH or long Extended Community (stuffing a lot of
RTs as described in RTC backwards compatibility work) to make sure that
most popular BGP implementation can handle such large attributes without
crashing ? Otherwise enabling this would be an excellent attack vector in
the Internet.

- Do we have an agreement that this will not be "ON" by default, but will
be enabled only with a knob ?

- How do we detect if this is supported across the private AS/public
Internet zoo of routers ? Should we have a protocol tool which would allow
to detect support of extended messages at each BGP speaker and if not
report this as an error to the originator of the large message ? Sending
large BGP message if not supported by any remote peer by any BGP speaker
along the propagation would trigger reporting it back with new ICMP error
could be one approach. I am sure there would be others ...

Thx,
r.