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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Fri, 13 January 2017 14:48 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 4C53912966C; Fri, 13 Jan 2017 06:48:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 OyneYqhoFf7l; Fri, 13 Jan 2017 06:48:29 -0800 (PST)
Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (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 E18F1129660; Fri, 13 Jan 2017 06:48:28 -0800 (PST)
Received: by mail-yb0-x22e.google.com with SMTP id l23so15667833ybj.2; Fri, 13 Jan 2017 06:48:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WYpB7BibCIrSccRDVUur0Sgo4T6MFKuFn0RswkFYuFc=; b=rfRxLL8rplB3TvhrJTx/GxJ/xbJHuEASFcVK1bHGdNVRwhVKiBaAWsYcKuG7wJMwbs jeA5sZlVnXhcqurAu9W3MB1wyUDnz65VunI7La1b0+hY2SCQAtSi0pDxLjGN7ue2K18Y epA85Y6qnPHeEu36boHWIY/5rKWHAddWidNj6VfG52RhMygCZUiax/gBe1Wv3LWWJQS5 KQwl+oQGZZLf+n3vklHSJD2w1aEiEiY73A6sH9FYdRAY+XNvb+uyKlYIoidBobKVaAti yErGyGd3tSpQgrPsNv5Dcf/7F76sf+fy03T4hxmi6WJNfPIKfYqVj/Pq8qpJG3SD7ROy 3MKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WYpB7BibCIrSccRDVUur0Sgo4T6MFKuFn0RswkFYuFc=; b=MYHUV/jyQx7KnlsRjE7SW4kmCgsIXLqdhycxG57iFfUCwgDnxrKOW76EDviALx6yNx Rv20QU+c3hnEPFN6OVZs1n84FKA0Ru+5dN+cPcaS0/qOxHliX6H7Y6fCVubNv3uJzT4g 6SEgwN9KlMHhUZzvrv0AHooeO8mvhi0jjDomxZOR3KIuBQSaUKVBewcEShd9T/rfbW57 voLa8zpjRvuH0uyfEfI61w2hBuJ5Os1Rx/K8jT3WAFBhffo+bL2fj4zEM1vhpJD71H5K MaZ0AvUldneGIJ4kYzpTHBZkrmNdYXea1yQeZEW7M/Te1BCNBQu60wlr3r9tkUmaBWcL I+cA==
X-Gm-Message-State: AIkVDXK9zSxJyYQqI3HFcmwgS3c4OCl2FN/PXxcqFzgfaeLB1SL3gg/gCidmJ+33E40sm1sy9Gp9EtnrZlGY9g==
X-Received: by 10.37.204.193 with SMTP id l184mr12492766ybf.182.1484318908165; Fri, 13 Jan 2017 06:48:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.221.195 with HTTP; Fri, 13 Jan 2017 06:48:27 -0800 (PST)
In-Reply-To: <m2fuknhjqb.wl-randy@psg.com>
References: <148354658288.13030.6680402717954276501.idtracker@ietfa.amsl.com> <DM2PR09MB04461FA2EC8F5538D6DC03C184780@DM2PR09MB0446.namprd09.prod.outlook.com> <m2fuknhjqb.wl-randy@psg.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Fri, 13 Jan 2017 08:48:27 -0600
Message-ID: <CAKKJt-f3zLoB+dsKr67r++ZdNtneenEYddBLc3AjJxxgX9URtA@mail.gmail.com>
To: Randy Bush <randy@psg.com>
Content-Type: multipart/alternative; boundary="94eb2c083aa641344d0545faedea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/yGs4MwRR72uICDyqm44lwfy29X4>
Cc: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>, The IESG <iesg@ietf.org>, sidr wg list <sidr@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 14:48:30 -0000

You folks are headed in the right direction. I'll be happy wherever you end
up.

Thanks!

Spencer

On Thursday, January 12, 2017, Randy Bush <randy@psg.com> wrote:

> >>    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
>