Re: [Idr] 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: 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 AC38C1296E0 for <idr@ietfa.amsl.com>; Tue, 4 Apr 2017 09:44:52 -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=unavailable 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 AMB6ASwAarxh for <idr@ietfa.amsl.com>; Tue, 4 Apr 2017 09:44:51 -0700 (PDT)
Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 D701112422F for <idr@ietf.org>; Tue, 4 Apr 2017 09:44:45 -0700 (PDT)
Received: by mail-wr0-x236.google.com with SMTP id w11so217612153wrc.3 for <idr@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=l1EJg+6ptsz0nQUqcJHqhHLDCM5n33iYIxnUObouLQBpTmwjMMHOW8ZzhmAiBWPAm5 FLRfFu6TGcSgZfcXS4AD6jM6GkYT1eMQ708RR70nljeFW0cWcF8xVhULouH9+RL5v7SK 5snk9ye7ZsWRn4guBMee8aB7Lc2EmXJ+lKBHcH+4cad/bcNZ3TiMOpjn8DkoTgjRAw7c 2IpYz9RipoM98MyxCtC8orNXOIvsrjuq8J+kh4ZivATvDuLWUPU54yamxTHoVi7Jcnat 5ocQj/0mECzNE/XA2hYRjEwKkWdTS+CImaDk2BNpiGbDOvvJ1Q+862IQ3f1qy7TYvNUw J3JQ==
X-Gm-Message-State: AFeK/H3F4VJ9sJc9t7U/nn8KgrqPrYxCMvGpqgT8JhV32n2x+u3y3AdJidT7GL6bM0P80qBFQUUBRM3uIQsH02PW
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/idr/VPFGd77DN_e7TG5bOauE5WFtdAo>
Subject: Re: [Idr] BGPsec without Extended Messages (draft-ietf-sidr-bgpsec-protocol)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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, 04 Apr 2017 16:44:53 -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.
>
>