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

Jeffrey Haas <jhaas@pfrc.org> Fri, 23 August 2019 15:40 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6B6120118 for <idr@ietfa.amsl.com>; Fri, 23 Aug 2019 08:40:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umbBIF_gttSf for <idr@ietfa.amsl.com>; Fri, 23 Aug 2019 08:40:42 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B85561200E6 for <idr@ietf.org>; Fri, 23 Aug 2019 08:40:42 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 31A3D1E2F6; Fri, 23 Aug 2019 11:43:03 -0400 (EDT)
Date: Fri, 23 Aug 2019 11:43:02 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: idr@ietf.org
Message-ID: <20190823154302.GR367@pfrc.org>
References: <156453599438.14213.11074089613507937754@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <156453599438.14213.11074089613507937754@ietfa.amsl.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/XhByklnrHVSaaldGWN5ukzF_kUA>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-34.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Aug 2019 15:40:44 -0000

On Tue, Jul 30, 2019 at 06:19:54PM -0700, internet-drafts@ietf.org 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