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, 09 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 >
- [Idr] Capability Advertisement in draft-ietf-idr-… Alvaro Retana
- Re: [Idr] Capability Advertisement in draft-ietf-… Jeffrey Haas
- Re: [Idr] Capability Advertisement in draft-ietf-… Enke Chen (enkechen)
- Re: [Idr] Capability Advertisement in draft-ietf-… Jeffrey Haas
- Re: [Idr] Capability Advertisement in draft-ietf-… Jakob Heitz (jheitz)
- Re: [Idr] Capability Advertisement in draft-ietf-… Enke Chen (enkechen)
- Re: [Idr] Capability Advertisement in draft-ietf-… Enke Chen (enkechen)
- Re: [Idr] Capability Advertisement in draft-ietf-… Jakob Heitz (jheitz)
- Re: [Idr] Capability Advertisement in draft-ietf-… Randy Bush
- Re: [Idr] Capability Advertisement in draft-ietf-… bruno.decraene
- Re: [Idr] Capability Advertisement in draft-ietf-… Randy Bush
- Re: [Idr] Capability Advertisement in draft-ietf-… Robert Raszuk
- Re: [Idr] Capability Advertisement in draft-ietf-… Keyur Patel
- Re: [Idr] Capability Advertisement in draft-ietf-… Jeffrey Haas
- Re: [Idr] Capability Advertisement in draft-ietf-… Susan Hares
- Re: [Idr] Capability Advertisement in draft-ietf-… Alvaro Retana
- Re: [Idr] Capability Advertisement in draft-ietf-… Robert Raszuk
- Re: [Idr] Capability Advertisement in draft-ietf-… Enke Chen (enkechen)
- Re: [Idr] Capability Advertisement in draft-ietf-… Enke Chen (enkechen)
- Re: [Idr] Capability Advertisement in draft-ietf-… Robert Raszuk