Re: [sidr] BGPsec without Extended Messages (draft-ietf-sidr-bgpsec-protocol)

Matthew Lepinski <mlepinski@ncf.edu> Tue, 04 April 2017 16:44 UTC

Return-Path: <mlepinski@ncf.edu>
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 B7B641296DE for <sidr@ietfa.amsl.com>; Tue, 4 Apr 2017 09:44:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ncf.edu
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 YCiAmj03cmoc for <sidr@ietfa.amsl.com>; Tue, 4 Apr 2017 09:44:46 -0700 (PDT)
Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 D26811296E5 for <sidr@ietf.org>; Tue, 4 Apr 2017 09:44:45 -0700 (PDT)
Received: by mail-wr0-x22e.google.com with SMTP id k6so215348549wre.2 for <sidr@ietf.org>; Tue, 04 Apr 2017 09:44:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncf.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=aafK78B/HKXRqkHHXeWJgW8IWQqGYYjuRzznytyWMW0=; b=XBioahYQy8CSbLe/zUvoN08Sm8iO32GQTGxiX3hsxnZ3z/09WwW40ZQWFwGqg/P4La 3F8CU+RuaVXFy8wQzrbmVEIvRuFsbgWV68sIKzR0JWiV0ia/WmcAiRrIujSzwjxq2X4B GZOUiVhpNijjdW0q11zO9jSTaRimfl9M5onsP6hAiYKfNE9sQJT+omWmHd1SMGHPE+Nz qFR1YUeeUvMliAE5ZtqRNOuhKy/k9D3XI2NZea3uvJzf5piEDTe24lhL2FUaJxx/GFmh vLErLQyMwGkc+2os6zgCFUoGr08gYGmH1bQgjbZHURY4DTTDjftkkWVe7H+G7kDczqWz peJQ==
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:content-transfer-encoding; bh=aafK78B/HKXRqkHHXeWJgW8IWQqGYYjuRzznytyWMW0=; b=oM2T3TgOknb1Ee8UEqeuVbsGo/98B86Td9U39OgJ80PNcM1jvg6n96SVC+E8oe3yHy ZhHGFE9rB1EILbs/qIy4l7/bM/2fHxjYZ6IRQBczGSsMIt7A4ByZPmqPB3feWzquoAFX HzR8tK2iKbYYYgQUFPkz0SLH2dhZOWusxLI9H6NWh14P2ZaqQ7F6ejpuNt5biVFVBtL7 oZE94zLdaX+1RtXiAlcxifjD/FvKT77clPDoqSXvpBdoPfqIcgR66LHDL0wO53WuZl/f Md1QT3YvINrXOr6wLoKWPgnPU/voog9vaeAEaOWIvATw0R6SWlakhHcJ7VU6w51UThFI jP5w==
X-Gm-Message-State: AFeK/H3SV/kL4mfBt6v/lGxd+/0eUcc3lXqrzpoA1AGI7DSbmfdsyTXQCItVN3OjXOiCD1UWbuGqP/MkjkcXyAql
X-Received: by 10.223.173.53 with SMTP id p50mr23163286wrc.116.1491324284248; Tue, 04 Apr 2017 09:44:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.173.232 with HTTP; Tue, 4 Apr 2017 09:44:43 -0700 (PDT)
In-Reply-To: <65677770-43DB-4CE0-8E81-B35B9A82DF6F@cisco.com>
References: <65677770-43DB-4CE0-8E81-B35B9A82DF6F@cisco.com>
From: Matthew Lepinski <mlepinski@ncf.edu>
Date: Tue, 4 Apr 2017 12:44:43 -0400
Message-ID: <CA++NScEB1=TswjnszJm8_kghE2n8MX9gyDPePRsqqNALKyA6=g@mail.gmail.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>
Cc: "sidr@ietf.org" <sidr@ietf.org>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, "draft-ietf-sidr-bgpsec-protocol@ietf.org" <draft-ietf-sidr-bgpsec-protocol@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/crwjOBarz0X37ic3ziRpuPfBgJI>
Subject: Re: [sidr] BGPsec without Extended Messages (draft-ietf-sidr-bgpsec-protocol)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 04 Apr 2017 16:44:49 -0000

Alvaro,

The proposed changes seem reasonable, but I want to make sure that I
understand the path forward clearly.

My understanding is that if we were to reach a future where
draft-ietf-idr-bgp-extended-messages is widely deployed, then the BGP
speaker's maximum message size will just be larger (than it is today)
and as a result we avoid reaching the point where Section 9.2 (of
4271) guidance is needed.

Is my understanding correct? (I want to make sure that future
implementers will find our text clear and we won't need to revise this
spec to add clarity if extended messages ends up in widespread use.)

- Matt Lepinski

On Tue, Apr 4, 2017 at 12:15 PM, Alvaro Retana (aretana)
<aretana@cisco.com> wrote:
> Dear sidr WG:
>
>
>
> As has been discussed in the mailing list and at the sidrops meeting last
> week in Chicago, there is interest to not have the BGPsec document
> (draft-ietf-sidr-bgpsec-protocol) depend normatively on the Extended
> Messages work (draft-ietf-idr-bgp-extended-messages).  Based on that
> discussion, Sriram and I have come up with proposed diffs – please see the
> attachment (-23 has not been posted yet).
>
>
>
> To summarize, the changes are: (1) remove mention/references of/to
> draft-ietf-idr-bgp-extended-messages, and (2) add the following text in
> Section 4.1. (General Guidance):
>
>
>
>     All BGPsec update messages MUST conform to BGP's maximum message
>
>     size.  If the resulting message exceeds the maximum message size,
>
>     then the guidelines in Section 9.2 of RFC 4271 [RFC4271] MUST be
>
>     followed.
>
>
>
> [For easier reference, I put the relevant text from 9.2 below.]
>
>
>
> The result is then that draft-ietf-sidr-bgpsec-protocol doesn’t depend on
> draft-ietf-idr-bgp-extended-messages.  Instead, when referring to the size
> of the messages, it depends on rfc4271.
>
>
>
> Please let me know if you have any concerns.  I will wait a week before
> proceeding.
>
>
>
> Given that this document has already been approved by the IESG, the process
> going forward is:
>
>
>
> - consult the WG (this thread)
>
> - inform the IESG of the intent
>
> - inform the IETF (ietf@ietf.org) of the changes
>
> - publish an updated draft
>
> - continue the publication process
>
>
>
> Each step may, obviously, require additional discussion and could result in
> changes to the current plan.
>
>
>
> Thanks!!
>
>
>
> Alvaro.
>
>
>
>
>
>
>
>
>
> https://tools.ietf.org/html/rfc4271#section-9.2
>
>
>
> 9.2.  Update-Send Process
>
>
>
> …
>
>    If, due to the limits on the maximum size of an UPDATE message (see
>
>    Section 4), a single route doesn't fit into the message, the BGP
>
>    speaker MUST not advertise the route to its peers and MAY choose to
>
>    log an error locally.
>
>