Re: [Idr] [Re: Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-31.txt

Robert Raszuk <robert@raszuk.net> Tue, 02 July 2019 14:52 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 06B8B1200F3 for <idr@ietfa.amsl.com>; Tue, 2 Jul 2019 07:52:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=ham 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 1xmff75O68dI for <idr@ietfa.amsl.com>; Tue, 2 Jul 2019 07:52:08 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 7871C1200EB for <idr@ietf.org>; Tue, 2 Jul 2019 07:52:08 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id x18so14120191qkn.13 for <idr@ietf.org>; Tue, 02 Jul 2019 07:52:08 -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=78veGHgotrAd68AYf0KG1H1R3Z3IOfq/YhyuY5R0ivE=; b=NVxptPcQWel8IxJEZwVJgElLN4N9zTF0eTfWe+Gm9uEKEzIGXgy2CuuKGqgfYu4URq 6XTSoZ4E8yx6Yrr2zOfWkTmC1pi5vsX2CA9G/YPyA/WeulExofvIuYCHARqNj902XwlR jY5v5tYm2UAwDZHx0nhUpUl5mYJYbwG9j8j6eIMQqBaDZ5uCM4ybwu5sNmI2QC6h1zen 1u2bC8T3ajUamE3NigyqU8tgGt5KuhJUyKlSCZHH/INsOxbmvUS6CLzIh9/H1IIUWrd4 lERuyY6qbFNFF2y4jqUN63gRYTzLJnD/73f3NA/0Zeb7t892UA3DcPkphFQf1Zn8muCn DcfA==
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=78veGHgotrAd68AYf0KG1H1R3Z3IOfq/YhyuY5R0ivE=; b=C2evqWG/eqLzA0VnOfzxtJt73+TKO2NuDRW3L8o9GBgdXvfbO3HVlCvsBi+d1gnPQD bWm54+RblTIfRNivW1wBJx0/J/L3HqzPnk8eM9l1yRD5h235XOUEfME/jrqRSWrmnwDb 3QT8P4241N7fx7KqpVtkJ+1iyY4H8M9xXsAArsjBIWQATtMojFPDW2P6dHfPDLwtOeRT ts4LA9PyasRqseLZNwbmO7D7o1o2bmeTifv7TdJ1CcZO7PHzieF2dzIJ1hYBTCERkTaK 6wEg+MB5rUpzz2mdsHnLSu4HUJYRWtM+Qwq9ycQUKaihs1CKlTTWy5MS9rJBXqc6mwPV 97zA==
X-Gm-Message-State: APjAAAUe7VVqXELZVryA1fvOc6ZxzJpBOw4l3wcp2PiDETpd9uxosqIz Kax9XckGvAwdi2lW6qf2+fWyfy7fmnXw+gsPI2+PbA==
X-Google-Smtp-Source: APXvYqxTRmpHpw078u0cwa5/2E4m7pcbiZvZjKvl2SF0sL7mjKV6keTtBrkOKpUVIYJU+olH5PKxmJQCR9HxRKu3oxc=
X-Received: by 2002:a37:e40a:: with SMTP id y10mr8472011qkf.134.1562079127540; Tue, 02 Jul 2019 07:52:07 -0700 (PDT)
MIME-Version: 1.0
References: <FDAC847D-60A2-4571-99CF-50458AC0E159@cisco.com> <m21rz9xn46.wl-randy@psg.com> <F41665B6-DD53-42F5-AD1D-F828C215809B@cisco.com> <CAMMESsxBDJrPMVdHyiJ3rQWyZaMB_4w-9qm+TD_8c0jtB+AOeA@mail.gmail.com> <CAOj+MMFq+zBJ+o=6GrK=YeNCRz+JsXdTj82xggubHq0+wf725Q@mail.gmail.com> <m2o92cwlbv.wl-randy@psg.com>
In-Reply-To: <m2o92cwlbv.wl-randy@psg.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 02 Jul 2019 16:51:55 +0200
Message-ID: <CAOj+MMFsVjRnDyT8YKvHVk4pfvi0xdba_CoHKvOjkYJ7DdCN8g@mail.gmail.com>
To: Randy Bush <randy@psg.com>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, "Enke Chen (enkechen)" <enkechen@cisco.com>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000822e72058cb3e319"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/8vZLiGfAUfkFQHKxz3oK1Oqg05o>
Subject: Re: [Idr] [Re: Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-31.txt
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: Tue, 02 Jul 2019 14:52:12 -0000

> you seem to want two capabilities, sending and receiving.

I was trying to make sure all parties are on the same page here :)

Nope - technically you still negotiate single capability: Extended Msg -
but with TLVs indicating the more granular supported direction.

> but if they negotiate the sending capability, then both are senders.  in
> which case, both must be receivers.

There are not such a thing as "sending capability" ... The capability is
still Ext Msg.

- - -

Anyhow I am not sure I would put that "I want it". I see pros and cons of
both options and very honestly I more biased to leave the current
send/receive combined one for this very extension.

Thx,
R.

On Tue, Jul 2, 2019 at 4:41 PM Randy Bush <randy@psg.com> wrote:

> robert,
>
> >> rfc5492 says this: "Simply put, a given capability can be used on a
> >> peering if that capability has been advertised by both peers.  If
> >> either peer has not advertised it, the capability cannot be used.”
> >
> > Current version of the draft defines one simple capability to indicate
> > support for both sending and receiving.
>
> if they bost must be capable, then both must be able to send and
> receive.
>
> you seem to want two capabilities, sending and receiving.
>
> but if they negotiate the sending capability, then both are senders.  in
> which case, both must be receivers.
>
> randy
>