Re: [Idr] AD Review of draft-ietf-idr-ext-opt-param-09

Jeffrey Haas <jhaas@pfrc.org> Fri, 19 March 2021 13:09 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 7FB8D3A1354; Fri, 19 Mar 2021 06:09:48 -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 Z7cckoyhrVOx; Fri, 19 Mar 2021 06:09:46 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 149363A1352; Fri, 19 Mar 2021 06:09:46 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id DF5931E446; Fri, 19 Mar 2021 09:31:16 -0400 (EDT)
Date: Fri, 19 Mar 2021 09:31:16 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: draft-ietf-idr-ext-opt-param@ietf.org, Susan Hares <shares@ndzh.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, IDR List <idr@ietf.org>
Message-ID: <20210319133116.GJ29692@pfrc.org>
References: <CAMMESsw3eVnfiJ8RQ4GSSzp4b1T2n6hm-nSZ6xuyK9XCMb1pAg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMMESsw3eVnfiJ8RQ4GSSzp4b1T2n6hm-nSZ6xuyK9XCMb1pAg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/aKZWZBTyxUIE5sWuQudfLeqX7U8>
Subject: Re: [Idr] AD Review of draft-ietf-idr-ext-opt-param-09
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, 19 Mar 2021 13:09:49 -0000

Alvaro,

On Thu, Mar 18, 2021 at 02:54:46PM -0700, Alvaro Retana wrote:
> 78	2.  Protocol Extensions
> ...
> 83	   In the event that the length of Optional Parameters in the BGP OPEN
> 84	   message does not exceed 255, the encodings of the base BGP
> 85	   specification [RFC4271] MUST be used without alteration.  However, an
> 86	   implementation MUST be prepared to accept an OPEN message that uses
> 87	   the encoding of this specification for Optional Parameters of any
> 88	   length.
> 
> [major] "MUST be prepared to accept an OPEN message...of any length."
> 
> The OPEN message is not covered by rfc8654, so the length is still
> limited to 4k...which means that the full Extended OP length/Parameter
> Length cannot be used.
> 
> Besides clarifying that, I think that new OPEN Message Error subcodes
> are needed for the cases where the length is invalid.  This type of
> error is possible in the non-extended version of the OPEN too -- I
> guess rfc4271 just assumed that this error would never happen.

Speaking as a vendor with an implementation here, we currently send
"Unsupported Optional Parameter".  A new sub-code would be fine to help with
diagnostics, but that's all it would do.  The BGP FSM is still getting a
NOTIFICATION to drop the session.

I think the headache you're highlighting is we have two conditions we can
get to here:

1. The length is unacceptable, but fits in the PDU.
2. There's an overrrun of the optional paramters vs. the encapsulating
   BGP message.


-- Jeff