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

Jeffrey Haas <jhaas@pfrc.org> Thu, 01 August 2019 00:27 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 1A374120123; Wed, 31 Jul 2019 17:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KOP0g6hqFiZ; Wed, 31 Jul 2019 17:27:16 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id ED347120043; Wed, 31 Jul 2019 17:27:15 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 1BDCE1E2F5; Wed, 31 Jul 2019 20:29:12 -0400 (EDT)
Date: Wed, 31 Jul 2019 20:29:11 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Enke Chen (enkechen)" <enkechen@cisco.com>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, "idr@ietf. org" <idr@ietf.org>, "draft-ietf-idr-bgp-extended-messages@ietf.org" <draft-ietf-idr-bgp-extended-messages@ietf.org>, Susan Hares <shares@ndzh.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Message-ID: <20190801002911.GB31271@pfrc.org>
References: <CAMMESsyvuU8_dBOeoOXPBt=-HwoF0eHvYgm5d8CgF-4o_oiP=g@mail.gmail.com> <20190731211602.GA31271@pfrc.org> <119404A5-8384-456B-9677-0445899B008F@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <119404A5-8384-456B-9677-0445899B008F@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/7mPrr-nwId3yI62OekK_2_8LlZI>
Subject: Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages
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: Thu, 01 Aug 2019 00:27:17 -0000

Enke,

On Wed, Jul 31, 2019 at 09:50:08PM +0000, Enke Chen (enkechen) wrote:
> >>  Note that RFC 6793 (4-byte ASes) require bi-directional advertisement.
> 
> No, this statement is not correct. It is fundamental (in transition) for a BGP  speaker
> to be able to talk to both NEW speakers (that have advertised the capability), and OLD
> speakers (that have not advertised the capability).  Different encodings are used in the
> UPDATE message depending on whether the 4-byte AS capability is received from a
> neighbor.

I should have known I wasn't pedantic enough in this comment. :-)

The point here is that in order to exercise the procedures between NEW BGP
speakers, (RFC 6793, §4.1), both sides must advertise and use the
capability.  If you have a mix, each speaks 4271 to each other with the new
speaker running the transitional procedures.

With regard to the extended messaging, my preference is that both sides
advertise the capability in order to use the large messages.  A mis-match
falling back to 4271 4k PDUs is fine - symmetrically.  Asymmetrically
sending extended messages leads to a mess of edge cases.

-- Jeff