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

Alvaro Retana <aretana.ietf@gmail.com> Fri, 09 August 2019 13:27 UTC

Return-Path: <aretana.ietf@gmail.com>
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 2C05B120046; Fri, 9 Aug 2019 06:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 wiKtsq5iaIRw; Fri, 9 Aug 2019 06:27:54 -0700 (PDT)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 B73DE12001A; Fri, 9 Aug 2019 06:27:53 -0700 (PDT)
Received: by mail-ed1-x52d.google.com with SMTP id z51so7510206edz.13; Fri, 09 Aug 2019 06:27:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=1zAyyzpOzjhRGPdvMXRpHiZKnqDGW1FaRQp8JuSleh0=; b=eF8fn+T8wyhAVLX5CO35mkjjMiX+lh8udUZ+erxAc06EWQ1muDLfyi9r+7zzC+7HjB BBM5Yv2hf74SLa0Cvq3cACiQ7B18H5Czr4ofNhDlUohht8L/UqHRQTci6zNu8+MGPt2k LTzlXfiFTanqJVEkPp6uImcNFdc/dkMxguOLaT4Wo6EF+3ZNvek1bikaflWkim1t+v8c ZIFhFFYgbv+7DXfFAg4/aVsoZ1B86cd3C36OhUDOH+y55mbGtB6IpBIaXOsJTyoxM2NH qxku8kC+efuvMbxCy94dY8ShfU7VeCIomoA8OXxje/Y9hQiZ/6GCACRrPOjdS9j+xrG3 dJLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=1zAyyzpOzjhRGPdvMXRpHiZKnqDGW1FaRQp8JuSleh0=; b=SNpskf7dLBLMakFruFiZ6aRm70SbXR1eQNaODSpv1YmFIX6910jNEPDpfvdwEmqR21 MxvFAO5hWrRB/xe4mXYI6QgzKgnDIlbaCHjC/NWo6xTE3PE9Vnb6skRlT23Kp4Fe0vTw cRgoinfFZbxPqeZ/bPd1wp0AaOSkI9FEmmRB5+I6+3OL871cmrdbtBNmf29Ac4R7JcE3 fyz7MT7e7Ru4KDZsBJLtZBAZ2PwN7XHXa7kUKt8lRHKxr43B0aJmRrG1uMLKqrRpQUyW BvB8uXSw/8INKo0n2C5ep3beT4r/40JvYiuuWL0D7SMrVfQc5N0QBY5AsEHxbIj6cgU2 lOaQ==
X-Gm-Message-State: APjAAAVHKr/lCLK3Ak9VnGItlE/TB2yCGkCDorrr/xTdAa0jgwOeyNQA +F7S+BBNwN4ainicWoYRVfC+qDvrv8yIJSSoYFtnwnqF
X-Google-Smtp-Source: APXvYqwokQnq8vP+T7bB4nhp4AD0VVe1CH5kzXaXhO9XgEjtfLvGEX+pqf3XznWhTJBGGR2z0m8n+/7vAKfemS+1iAU=
X-Received: by 2002:a50:86bb:: with SMTP id r56mr11030456eda.217.1565357272189; Fri, 09 Aug 2019 06:27:52 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Aug 2019 06:27:51 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CAMMESsyvuU8_dBOeoOXPBt=-HwoF0eHvYgm5d8CgF-4o_oiP=g@mail.gmail.com>
References: <CAMMESsyvuU8_dBOeoOXPBt=-HwoF0eHvYgm5d8CgF-4o_oiP=g@mail.gmail.com>
MIME-Version: 1.0
Date: Fri, 9 Aug 2019 06:27:51 -0700
Message-ID: <CAMMESszw4PGXdQ+r0xhJaXMWF1J+BFxG_U3FPVrGBgnCTYdHNg@mail.gmail.com>
To: "idr@ietf. org" <idr@ietf.org>
Cc: Susan Hares <shares@ndzh.com>, idr-chairs@ietf.org, Randy Bush <randy@psg.com>, draft-ietf-idr-bgp-extended-messages@ietf.org
Content-Type: multipart/alternative; boundary="00000000000027d18e058faf2421"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/PTNvdx7lJtIkVHsMJmS-qEi9-Ys>
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 13:27:57 -0000

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