IETF Logo Mail Archive

Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

Randy Bush <randy@psg.com> Fri, 13 January 2017 00:44 UTC

Return-Path: <randy@psg.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF61F1295A2; Thu, 12 Jan 2017 16:44:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.1
X-Spam-Level:
X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 YPSXDQNm_NzD; Thu, 12 Jan 2017 16:44:19 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91411295AC; Thu, 12 Jan 2017 16:44:16 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from <randy@psg.com>) id 1cRpyY-0000o2-L4; Fri, 13 Jan 2017 00:44:14 +0000
Date: Fri, 13 Jan 2017 09:44:12 +0900
Message-ID: <m2fuknhjqb.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
In-Reply-To: <DM2PR09MB04461FA2EC8F5538D6DC03C184780@DM2PR09MB0446.namprd09.prod.outlook.com>
References: <148354658288.13030.6680402717954276501.idtracker@ietfa.amsl.com> <DM2PR09MB04461FA2EC8F5538D6DC03C184780@DM2PR09MB0446.namprd09.prod.outlook.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/YmIIJXyh_SikJJQ8_bHkC7712zI>
Cc: sidr wg list <sidr@ietf.org>, Spencer Dawkins <spencerdawkins.ietf@gmail.com>, The IESG <iesg@ietf.org>
Subject: Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jan 2017 00:44:21 -0000

>>    Note that BGPsec update messages can be quite large, therefore any
>>    BGPsec speaker announcing the capability to receive BGPsec messages
>>    SHOULD also announce support for the capability to receive BGP
>>    extended messages [I-D.ietf-idr-bgp-extended-messages].
>> 
>> isn't a MUST, but Section 7 explains this 
>> 
>>    In Section 2.2, is was stated that a BGPsec speaker SHOULD announce
>>    support for the capability to receive BGP extended messages.  Lack of
>>    negotiation of this capability is not expected to pose a problem in
>>    the early years of BGPsec deployment.  However, as BGPsec is deployed
>>    more and more, the BGPsec update messages would grow in size and some
>>    messages may be dropped due to their size exceeding the current 4K
>>    bytes limit.  Therefore, it is strongly RECOMMENDED that all BGPsec
>>    speakers negotiate the extended message capability within a
>>    reasonable period of time after initial deployment of BGPsec.

how about just saying

   A router announcing the capability to send or to receive BGPsec
   updates MUST also announce the capability to send and receive BGP
   extended messages [I-D.ietf-idr-bgp-extended-messages].

and call it a day?

randy

v2.23.0 | Report a Bug | By Email