Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

[Robert Raszuk <[e-mail]>]

Hi Job,

The new proposed text is an improvement, but it still does not describe
what a BGP speaker should do when receiving any existing attribute (say
extended community) packed with RTs exceeding in total 4K and needs to send
it to "old" peer.

IMO we do need to define the recommended behavior before we progress this
to RFC. Just like we did so in migration to 4 octet AS in rfc6793.

Possible options:

1. Drop the update (bit ugly as such drop will be silent .. other then
local syslog/error report)

2. Drop the big attribute and insert defined here standard community or
some other marker indicating MSG_TRUNCATED info.

More ?

Thx,
R.

On Fri, Nov 17, 2017 at 7:55 PM, Job Snijders <[e-mail]> wrote:

> Hi Robert,
>
> On Thu, Nov 16, 2017 at 02:28:51PM +0100, Robert Raszuk wrote:
> > > How is a new BGP message type any different than negotiating through
> > > a capability whether an extended message can be handled by the peer.
> >
> > Because it is not about what your peer can handle. It is about what
> > *all* BGP speakers can handle and what to do when you get to narrow
> > street with this truck.
> >
> > it is mainly about not breaking what works today as discussed already
> > when someone will send 5K of Large Community Attribute.
> >
> > Maybe rather then new message the draft could simply say that none of
> > existing BGP Attributes (defined before this RFC goes out) MUST ever
> > exceed 4K in total and only the new attributes will be allowed to be
> > big if they want - then I am happy to keep all in current UPDATE msg
> > type. And the new fat attributes specs as Bruno suggested must
> > describe on their own how to handle peers with only 4K messages.
> >
> > Peace ?
>
> This is an interesting angle. Your proposal allows for the specification
> (and hopefully more code) to start shipping, and at a later point the
> flood gates can be opened (for 'old world' attributes) if the WG deems
> tjat appropiate.
>
> Proposed text:
>
> ----
> OLD:
>     A BGP announcement will, in the normal case, propagate throughout
>     the BGP speaking Internet; and there will undoubtedly be BGP
>     speakers which do not have the Extended Message capability.
>     Therefore putting an attribute which can not be decomposed to 4096
>     octets or less in an Extended Message is a likely path to routing
>     failure.
>
> NEW:
>     A BGP announcement will, in the normal case, propagate throughout
>     the BGP speaking Internet; and there will undoubtedly be BGP
>     speakers which do not have the Extended Message capability.
>     Therefore putting an attribute which can not be decomposed to 4096
>     octets or less in an Extended Message is a likely path to routing
>     failure.
>
>     It is RECOMMENDED that BGP protocol developers and implementers are
>     conservative in their application and use of Extended Messages.
>     Future protocol specifications will need to describe how to handle
>     peers which can only accomodate 4096 octet messages.
> ----
>
> Kind regards,
>
> Job
>
> ps. Since I don't think we can say "we'll never need larger than 4096",
> I think it is important to get this one shipped. The curious thing is
> that we'll need to have code deployed in the wild, _before_ any
> application can start using it. The WG LC is about a reasonable proposal
> to bump the limit in a way that is incrementally deployable (e.g.
> capability negotated).
>