Re: [Idr] [Re: Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-31.txt

Randy Bush <randy@psg.com> Tue, 02 July 2019 01:05 UTC

Return-Path: <randy@psg.com>
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 7829312018A for <idr@ietfa.amsl.com>; Mon, 1 Jul 2019 18:05:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 wtW7oYHEktuT for <idr@ietfa.amsl.com>; Mon, 1 Jul 2019 18:05:00 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9654012009C for <idr@ietf.org>; Mon, 1 Jul 2019 18:05:00 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from <randy@psg.com>) id 1hi7EA-0007Yb-8m; Tue, 02 Jul 2019 01:04:58 +0000
Date: Mon, 01 Jul 2019 18:04:57 -0700
Message-ID: <m21rz9xn46.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: "Enke Chen (enkechen)" <enkechen@cisco.com>
Cc: "idr@ietf.org" <idr@ietf.org>
In-Reply-To: <FDAC847D-60A2-4571-99CF-50458AC0E159@cisco.com>
References: <FDAC847D-60A2-4571-99CF-50458AC0E159@cisco.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-2022-JP
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/6IBvKWALr7aK0_7OKgu5NOnT3GU>
Subject: Re: [Idr] [Re: Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-31.txt
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: Tue, 02 Jul 2019 01:05:03 -0000

> Apologies for being late in the review cycle of this document.  But I
> have a basic question about the BGP capability defined in Sect 3:
> 
> --
>    By advertising the BGP Extended Message Capability to a peer, a BGP
>    speaker conveys that it is able to send, receive, and properly
>    handle, see Section 4, BGP Extended Messages.
> --
> 
> The text “… to send” does not seem to be necessary, and the spec would
> be simpler and cleaner without it.
> 
> IMO the capability should be about “receiving” only. As long as a BGP
> speaker is able and willing to receive large messages (by advertising
> the capability), its neighbor would be allowed to send such messages
> to the speaker. It really does not matter whether the speaker is able
> / willing / need to send any large messages to its neighbors.  (Of
> course certain “Operational” considerations still apply, especially
> for IBGP, as discussed in the document.)
> 
> What do folks think?

we weny around this at least twice during the wg process.  there was a
dislike of the possibility of extended messages being unidirectional,
error reporting, etc.

but i have no dog in this fight

randy