Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

Robert Raszuk <robert@raszuk.net> Fri, 09 August 2019 16:23 UTC

Return-Path: <robert@raszuk.net>
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 E17D11201E7 for <idr@ietfa.amsl.com>; Fri, 9 Aug 2019 09:23:22 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 W-KXtGB4EJnT for <idr@ietfa.amsl.com>; Fri, 9 Aug 2019 09:23:21 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 241141201DC for <idr@ietf.org>; Fri, 9 Aug 2019 09:23:16 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id y26so96367941qto.4 for <idr@ietf.org>; Fri, 09 Aug 2019 09:23:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=clGqGvhsyRsse0qBFBv3E0rPAq3809HcX1z3kphoPkc=; b=DVP2dh1qflTRrCWm83O+LibaIShjqj4gMTZDVwtt3/t0I4s6XyZwq93jbTuwDJlezS VzQiGm7JG1IuS3adA9y5/JAHkOWgpNNvLHUzc4s3bMliew0LI7pd1cBzAhuY1rXN7zvN U3lDYMMaAXEL9dorcDi9uSfmkQVVrXMcIdyXeBGZC9FmR+Z8J4GoYyaJfT8WT0tz+NpT gr7ZkGInkDf4CyDETT6orA20z/EwMIT02y4nAz2fgCNtz5M8lb8+Cu3yFnW8pDpNul+e QhI8cKkdw7ytxKNK0Cd7Xd3DTReKiYi6QE4eGM9lB782K4BRrHlJHo4SuKAAx7EK8t7n vr4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=clGqGvhsyRsse0qBFBv3E0rPAq3809HcX1z3kphoPkc=; b=mnMKCXIGC0GeXjNbeHE7BRHka4e8XJnwCwKhq66ExL4CjfBwLm+mHkD0qdp74r+DYb sC67Wm7qs2uj1JycIKD8OqkS/xxEEx/440pUAd3RRNM+oqL1ZoHH3wp4Rh/eQV+my4GP MTyt2Z/nL+iV8fMZHwbWMGN0DiOITQmnG3Ssa27//ESpxOaEi988iZ1zg7uSuYxQghJX 4p7wfPtnRzswjBD3mh3OP2LyiHddwWHN0Tqp9GJAe0laWFXK68emfLW6bqHsRhctVnaV mu0SwLUUW9GsmIK9tYngMJPi+Q94nR1XkMA6sWMv+hZ0sP627C9xUqebGmaNnjckiUQz AJRw==
X-Gm-Message-State: APjAAAVFZlZzLjZ9WqaGl+tiuYQMuBSbzH0FPkH5s6Np8JP6xl2TP+DW Gh0C+5dBAulOFtycY8zPUSlgw1DuYEiRHVR3WaHyxw==
X-Google-Smtp-Source: APXvYqwy03sGDRGaT+GqTWYzwpE5pInZzwch8s7XMk3vi0vRvNVV5DANQm7Dj67WJYT+unhoxNd7Kq5un72BlHkBnFk=
X-Received: by 2002:aed:2667:: with SMTP id z94mr9782497qtc.343.1565367794797; Fri, 09 Aug 2019 09:23:14 -0700 (PDT)
MIME-Version: 1.0
References: <CAMMESsyvuU8_dBOeoOXPBt=-HwoF0eHvYgm5d8CgF-4o_oiP=g@mail.gmail.com> <CAMMESszw4PGXdQ+r0xhJaXMWF1J+BFxG_U3FPVrGBgnCTYdHNg@mail.gmail.com>
In-Reply-To: <CAMMESszw4PGXdQ+r0xhJaXMWF1J+BFxG_U3FPVrGBgnCTYdHNg@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 9 Aug 2019 12:23:04 -0400
Message-ID: <CAOj+MMEJv3K3juuy9FWthMB-Yk7tYuU08D_wQ6h3gdo8q4dtqg@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: "idr@ietf. org" <idr@ietf.org>, idr-chairs@ietf.org, draft-ietf-idr-bgp-extended-messages@ietf.org, Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary="0000000000005a22a3058fb197eb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/qxqEPeu6cGWI8rEJca-zB61-waU>
Subject: Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages
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: Fri, 09 Aug 2019 16:23:23 -0000

Hi Alvaro,

So imagine that BGP Operational Message draft get's standardized and one
TLV will ask to replay back the received message to the sender.

Example: 3.4.3.3
<https://tools.ietf.org/html/draft-ietf-idr-operational-message-00#section-3.4.3.3>;.
Malformed Update Dump (MUD)

How is this going to work in this case when I receive over 4K PDU and can
not mirror it back to sender per his request ?

Aren't we getting ourselves into the trap here and "Oooops" condition by
allowing this asymmetry ?

Thx,
R.


On Fri, Aug 9, 2019 at 9:28 AM Alvaro Retana <aretana.ietf@gmail.com>; wrote:

> Hi!
>
> Thank you for everyone’s opinion and discussion!
>
> The current text in -35 says this:
>
>    A BGP speaker that is capable of receiving BGP Extended Messages
>    SHOULD advertise the BGP Extended Message Capability to its peers
>    using BGP Capabilities Advertisement [RFC5492].  A BGP speaker MAY
>    send Extended Messages to a peer only if the Extended Message
>    Capability was received from that peer.
>
>    An implementation that advertises the BGP Extended Message capability
>    MUST be capable of receiving a message with a Length up to and
>    including 65,535 octets.
>
>
> From the thread, the consensus is to keep the asymmetric capability
> advertisement.  As written, operators have the flexibility to advertise (or
> not) the capability to meet their local policy.
>
>
> Jeff brought up the point that rfc4271 (§6.3 / UPDATE Message Error
> Handling) says that, for some errors, the NOTIFICATION "Data field MUST
> contain the attribute (type, length, and value)."  The problem is that if
> an Extended UPDATE (> 4k) with an erroneous attribute is received from a
> speaker that hasn't advertised the Capability (which is ok because of the
> asymmetry), then that peer may not be able to handle an Extended
> NOTIFICATION (> 4k).
>
> NEW (to be inserted as the 3rd paragraph in §5 (Error Handling))>
>    The UPDATE Message Error Handling, as specified in Section 6.3 of
> [RFC4271],
>    is not changed.  However, if a NOTIFICATION is to be sent to a BGP
> speaker
>    that hasn't advertised the BGP Extended Message Capability, the maximum
> size
>    of the message MUST NOT exceed 4096 octets.
>
>
> Authors: If no word-smithing suggestions are received in the next couple
> of days, please submit a revised draft by the middle of next week.
>
> Thanks!
>
> Alvaro.
>
> On July 31, 2019 at 4:06:04 PM, Alvaro Retana (aretana.ietf@gmail.com)
> wrote:
>
> On July 31, 2019 at 1:31:11 PM, Susan Hares (shares@ndzh.com) wrote:
>
> Dear WG:
>
> As I hope all of you know, the Extended Messages draft is being processed
> by the IESG.
>
> Enke had brought up [1] some confusion in the text in rfc5492 related to
> the need, or not, for both BGP speakers to advertise a Capability before it
> can be used.  I discussed this point with Enke and John Scudder last week
> in Montreal — we looked at the text in the RFC and how recent Capabilities
> had been specified — and concluded that the intent of the RFC was to
> require at least one speaker to advertise the Capability…but that it should
> be the responsibility of any document defining a Capability to explicitly
> specify any changes.
>
> IOW, in some cases it may be enough for one of the peers to advertise a
> Capability, but in other cases it may be required for both to do so.
>  [Enke/John will work on an Update to rfc5492 to clarify.]
>
> Related to Extended Messages, here’s is what Enke proposed on the list [2]:
>
>    As long as Speaker A is able and willing to receive large messages (by
> advertising
>    the capability), its neighbor would be allowed to send such messages to
> Speaker A.
>    Such behavior does not depend on whether Speaker A is able / willing /
> need to
>    send any large messages to its neighbors.
>
>
> We have modified the text in draft-ietf-idr-bgp-extended-messages to
> reflect Enke’s proposal (from -35):
>
>    A BGP speaker that is capable of receiving BGP Extended Messages
>    SHOULD advertise the BGP Extended Message Capability to its peers
>    using BGP Capabilities Advertisement [RFC5492].  A BGP speaker MAY
>    send Extended Messages to a peer only if the Extended Message
>    Capability was received from that peer.
>
>    An implementation that advertises the BGP Extended Message capability
>    MUST be capable of receiving a message with a Length up to and
>    including 65,535 octets.
>
>
> During the IESG Evaluation, Sue pointed out that we removed the piece of
> text below:
>
> Just to let you know that the text below:
>
>
>
> “A peer which does not advertise this capability MUST NOT send BGP
>
>
>    Extended Messages, and BGP Extended Messages MUST NOT be sent to it.”
>
>
>
> was added due to comments on the IDR WG list from reviewers and
> operators.
>
> Given that Extended Messages is a very important extension to BGP, and
> even though I didn’t see objections in the thread mentioned above, I want
> to confirm one more time that the current text is ok with the WG.  The
> effective change is really related to the piece that says "A peer which
> does not advertise this capability MUST NOT send BGP Extended Messages”,
> which would require that both peers advertise the Capability before it can
> be used.
>
> Please reply with any comments by end-of-day on August 8, 2019.  Please
> explain any arguments against what is currently specified in -35.   The
> document is scheduled to be considered by the IESG on Aug/8, but I will
> hold approving publication until there is consensus on this thread.
>
> Thanks!
>
> Alvaro.
>
> [1] https://mailarchive.ietf.org/arch/msg/idr/vaBLOKHQZlRCiJOMTT8VjJrWp7c
> [2] https://mailarchive.ietf.org/arch/msg/idr/K5rA5rVci6VhMv5-UqXXaoRlvXo
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>