Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-34.txt

[Jeffrey Haas <[e-mail]>]

On Tue, Jul 30, 2019 at 06:19:54PM -0700, [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Inter-Domain Routing WG of the IETF.
> 
>         Title           : Extended Message support for BGP
>         Authors         : Randy Bush
>                           Keyur Patel
>                           Dave Ward
> 	Filename        : draft-ietf-idr-bgp-extended-messages-34.txt
> 	Pages           : 7
> 	Date            : 2019-07-30

This revision introduced the following section:

:   During the years of incremental deployment, speakers that are capable
:   of Extended Messages should not simply pack as many NLRI in a message
:   as they can, or otherwise unnecessarily generate UPDATES above the
:   4,096 octet pre- Extended Message limit, so as not to require
:   downstream routers to decompose for peers that do not support
:   Extended Messages.  See Section 8.

I think NLRI packing is incorrectly being placed into the problem space
here.

The general concern with large UPDATE messages is that within the context of
a single BGP route (by RFC 4271 definition - prefix + path attributes)
cannot be fit into an UPDATE.  This generally means that your path
attributes are so huge that a single NLRI for a given address family won't
fit without an extended message, or the NLRI itself may be too large.  An
example of too large NLRI may include flowspec, bgp-ls.

I don't believe that maximally packging the NLRI, when possible, is an
inherently bad thing and should not be called out this way.  BGP speakers
will happily decompose the received large update with many NLRI into several
smaller updates.

-- Jeff