Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

"Susan Hares" <> Thu, 09 March 2017 01:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BC701295EE; Wed, 8 Mar 2017 17:34:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.946
X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T0rljMXBPvdy; Wed, 8 Mar 2017 17:34:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 35C9E12953D; Wed, 8 Mar 2017 17:34:10 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: "Susan Hares" <>
To: "'Jeffrey Haas'" <>, "'Enke Chen'" <>
References: <> <> <> <006e01d296db$a7c4c320$f74e4960$> <> <010101d2974a$8520d060$8f627120$> <> <018c01d29756$c8b4f610$5a1ee230$> <> <01b301d29758$180458e0$480d0aa0$> <> <> <> <> <> <> <>
In-Reply-To: <>
Date: Wed, 8 Mar 2017 20:29:37 -0500
Message-ID: <004001d29874$9ed03840$dc70a8c0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQInnAj+Yxa8tap/yfCJFXAjQYwk1wJi0XFfAwzFclUBlnEaYAHWMN+rAr58MhwCyGvcFQMczvZ5Ak2aXIwCIxMNygKhSz2mAkKflqECNogRigHZPoiMAtOA/wsCBpBH+gFPsoV1n7k994A=
Content-Language: en-us
Archived-At: <>
Cc: 'idr wg' <>,, 'Robert Raszuk' <>,
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Mar 2017 01:34:11 -0000


Caveat - I am not commenting on operational issues.  If your brief comment
denotes some operational issues, I would appreciate a longer description
on-list or off-list. 

If you are comment on the functionality within the RFC4271 FSM, I am not
sure why the "wiggle room is reduced when the open message size is changed"?
I have been specific on this list as to the functionality a message header
length error enacts (Event 21) versus an Open Message Header enacts (Event
22).    Please be as specific in your response if it is a FSM issues. 


-----Original Message-----
From: Idr [] On Behalf Of Jeffrey Haas
Sent: Wednesday, March 8, 2017 4:35 PM
To: Enke Chen
Cc: idr wg; Robert Raszuk;;; Susan Hares
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

> On Mar 8, 2017, at 12:13 PM, Enke Chen <> wrote:
> If one has to send a large OPEN, then it is rejected by the remote 
> speaker, then the session needs to be held down (or for slow retry) 
> until the remote speaker is upgraded or the OPEN size reduced locally as
you are saying.
> The details need to be specified in a new revision.

This covers my prior comment: The minute you move to extended BGP Open size,
you change what wiggle room we've left for version negotiation.

And perhaps that's fine.  I've spent my entire networking life in BGP-4.  A
BGP-5 that only has interop with BGP-4 will likely be fine.

That said, you need to say this in the specs.

-- Jeff

Idr mailing list