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

[Job Snijders <[e-mail]>]

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).