Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

Jeffrey Haas <> Thu, 01 August 2019 21:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5ACEC12022E; Thu, 1 Aug 2019 14:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E-Qj549IBAJ2; Thu, 1 Aug 2019 14:03:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DC6381201BB; Thu, 1 Aug 2019 14:03:22 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 16C2D1E2F2; Thu, 1 Aug 2019 17:05:20 -0400 (EDT)
Date: Thu, 01 Aug 2019 17:05:19 -0400
From: Jeffrey Haas <>
To: "Enke Chen (enkechen)" <>
Cc: Alvaro Retana <>, "idr@ietf. org" <>, "" <>, Susan Hares <>, "" <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Aug 2019 21:03:25 -0000


On Thu, Aug 01, 2019 at 05:29:41AM +0000, Enke Chen (enkechen) wrote:
> Hi, Jeff:
> 1) It is a new capability, and it will take time for it to be deployed or enabled. A BGP speaker has to deal
> with the case that some neighbors have advertised the capability, and some have not. That is already
> covered in "Section 4 Operation" of the draft. 

I've made no argument against this.

> 2) In terms of deployment, as this feature is likely to be controlled by config (and likely "off" by default),
> requiring both sides to advertise the capability simultaneously would make it difficult for the feature to
> be deployed or used.

Then the normative text needs to be adjusted for notifications and future
messages.  A minor thing, but roughly: If you say you're willing to receive
extended messages, but protocol demands you respond (i.e. notification) with
information that may overflow 4k, you truncate or silently die.

(c.f. RFC 4271, §6.3, "Data field)

> 3) I do not see a reason for this capability to be different from other capabilities that do not require
> bi-directional advertisement of the capability.

I don't have Jakob's general issue.  I do think it simplifies a lot of cases
in code if a given pair of speakers symmetrically have the same limits.  So,
this is primarily a preference for cleaner code.

I am personally fine living with this being asymmetric (delete the
additional sentence in Alvaro's message), but would suggest the comment
above is handled.

-- Jeff