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

<> Thu, 01 August 2019 07:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EFC0E120047; Thu, 1 Aug 2019 00:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qJayAjUUTX3R; Thu, 1 Aug 2019 00:35:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC3C212000F; Thu, 1 Aug 2019 00:35:41 -0700 (PDT)
Received: from (unknown [xx.xx.xx.66]) by (ESMTP service) with ESMTP id 45zhsm2mKxzyt9; Thu, 1 Aug 2019 09:35:40 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.95]) by (ESMTP service) with ESMTP id 45zhsm1qMPz8sZK; Thu, 1 Aug 2019 09:35:40 +0200 (CEST)
Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM24.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Thu, 1 Aug 2019 09:35:40 +0200
To: Alvaro Retana <>, "idr@ietf. org" <>
CC: "" <>, "" <>, Susan Hares <>
Thread-Topic: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages
Thread-Index: AQHVR9uJswf557uQl0+4n83nuxT6Cabl4KeQ
Date: Thu, 01 Aug 2019 07:35:38 +0000
Message-ID: <11371_1564644940_5D42964C_11371_208_1_53C29892C857584299CBF5D05346208A48BCBA9E@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A48BCBA9EOPEXCAUBM43corp_"
MIME-Version: 1.0
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 07:35:45 -0000

From: Idr [] On Behalf Of Alvaro Retana
Sent: Wednesday, July 31, 2019 10:06 PM
To: idr@ietf. org
Cc:;; Susan Hares
Subject: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

On July 31, 2019 at 1:31:11 PM, Susan Hares (<>) wrote:

Dear WG:

As I hope all of you know, the Extended Messages draft is being processed by the IESG.

Enke had brought up [1] some confusion in the text in rfc5492 related to the need, or not, for both BGP speakers to advertise a Capability before it can be used.  I discussed this point with Enke and John Scudder last week in Montreal — we looked at the text in the RFC and how recent Capabilities had been specified — and concluded that the intent of the RFC was to require at least one speaker to advertise the Capability…but that it should be the responsibility of any document defining a Capability to explicitly specify any changes.

IOW, in some cases it may be enough for one of the peers to advertise a Capability, but in other cases it may be required for both to do so.  [Enke/John will work on an Update to rfc5492 to clarify.]

Related to Extended Messages, here’s is what Enke proposed on the list [2]:

   As long as Speaker A is able and willing to receive large messages (by advertising
   the capability), its neighbor would be allowed to send such messages to Speaker A.
   Such behavior does not depend on whether Speaker A is able / willing / need to
   send any large messages to its neighbors.

In general, I support this asymmetric behavior with capability advertisement  as it brings flexibility and reflects what looks to be the natural meaning: Sending capability A, means I support A. It should mean that my neighbor can use A with me.

However, I’m less in favor of such asymmetry for bgp-extended-messages as in general, for consistent routing, we would likely want the opposite asymmetry: everyone willing to accept receiving extended messages, before someone sends one. So I’d rather say that if you want to send extended-messages, you need to send the capability to be ready to also receive extended messages. Although this brings additional constraints (and nobody like constraints), I don’t really see a case where an BGP speaker could send an extended message and could not implemented the receiving side. While I can see that some implementers may be tempted to support the minimal for their use case and be happy to send large messages but not ready to do the work on the receiving side.

That been said, I can live with both options. We can leave this to operators to only configure the feature when both speakers support it. (Note that if your concerned with deployment speed of this feature, I’m not sure that in general this will be the speediest path)


We have modified the text in draft-ietf-idr-bgp-extended-messages to reflect Enke’s proposal (from -35):

   A BGP speaker that is capable of receiving BGP Extended Messages
   SHOULD advertise the BGP Extended Message Capability to its peers
   using BGP Capabilities Advertisement [RFC5492].  A BGP speaker MAY
   send Extended Messages to a peer only if the Extended Message
   Capability was received from that peer.

   An implementation that advertises the BGP Extended Message capability
   MUST be capable of receiving a message with a Length up to and
   including 65,535 octets.

During the IESG Evaluation, Sue pointed out that we removed the piece of text below:

Just to let you know that the text below:

“A peer which does not advertise this capability MUST NOT send BGP
   Extended Messages, and BGP Extended Messages MUST NOT be sent to it.”

was added due to comments on the IDR WG list from reviewers and operators.

Given that Extended Messages is a very important extension to BGP, and even though I didn’t see objections in the thread mentioned above, I want to confirm one more time that the current text is ok with the WG.  The effective change is really related to the piece that says "A peer which does not advertise this capability MUST NOT send BGP Extended Messages”, which would require that both peers advertise the Capability before it can be used.

Please reply with any comments by end-of-day on August 8, 2019.  Please explain any arguments against what is currently specified in -35.   The document is scheduled to be considered by the IESG on Aug/8, but I will hold approving publication until there is consensus on this thread.





Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.