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

Robert Raszuk <robert@raszuk.net> Tue, 02 July 2019 13:48 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 42812120075 for <idr@ietfa.amsl.com>; Tue, 2 Jul 2019 06:48:28 -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 94UId4qDyD-H for <idr@ietfa.amsl.com>; Tue, 2 Jul 2019 06:48:25 -0700 (PDT)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 3278112009E for <idr@ietf.org>; Tue, 2 Jul 2019 06:48:25 -0700 (PDT)
Received: by mail-qt1-x829.google.com with SMTP id d17so18460154qtj.8 for <idr@ietf.org>; Tue, 02 Jul 2019 06:48:25 -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=OrWXRedfbq9BK+MaKQ/ayDuV+5ck4DwKrabLRg2zAJw=; b=QEsKZt0YVhL2tK08+Uxvw3n5rOiIRtumqeovMwRDNguldHzY/5JG7oGE5xiEo6+s0J rWB8j6fxojkdIQO6jyiySSBoMQFflKVXNMixJkWJfs/JLTQOsnxzTA5JLBC1PIKLXZwd NEHIOWoScCJKFJmbSktwe0JjJ8UobgQnfwqlb3oXS59kZ4C27Tf7gm3ueMNp/FQ3bGg/ jwJJbtrEAbAbw//6vD72Do49wulusSFqHrn/oJh7Lm2jVvX8AaabFuhIxAxJhPiCNxbv ajYvBndHKPTeOMf+hjPGajfRXwdrWtt4C51n//8Z6g19h4B7zC8+w6CocBOm0X2zPct2 jcoA==
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=OrWXRedfbq9BK+MaKQ/ayDuV+5ck4DwKrabLRg2zAJw=; b=DGGE2V0YayTgK2j1BGZWnJp0ta8OwPe0OYR64Y71vfzkJmaZuNvjnZf08u/jc5GpPn GMns/vteGAS/0G1gy5Cqz4uWnLixA3msMMotyeNY/zvWVdKmZHV/jnob1c7sgEGyufMN xS0eg/COLjCGkUFRqOkEDC1KblS1NnwtgavF9g9IYhAJ1qd+AOJqN82IAl4OD7fOun3j x4OA6i2bMNjvtabWzf8N3hqtUXZI0ErQ7Je59N+H2O6zmaF+rvHOe85QOkzUi/lh85wD b9fDtNsb0m1tI5GAOhDEbdqYjaDgg4cfnUhB7XfV2ZIUfoucnuMIlG8dP8q+cC+2OJEq aIxQ==
X-Gm-Message-State: APjAAAWE2Jo/W9rafTtca4/hchi+7OAx1cqXSuyIb7iXzKApUAnVF4Uo 8SdP4S8SkhLBAOy3Gp71HkoPPK4NC3p1Gnlc27zu4g==
X-Google-Smtp-Source: APXvYqzO5A+oHYX8MvWvquqfRZ0SJePICzbolMSnbX0AEfeSSNwOSBUCpGeC5K3zKRtOVx+Ag2RzFCUdeKuZ4t1lPA8=
X-Received: by 2002:ac8:1c2d:: with SMTP id a42mr25043679qtk.311.1562075304248; Tue, 02 Jul 2019 06:48:24 -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>
In-Reply-To: <CAMMESsxBDJrPMVdHyiJ3rQWyZaMB_4w-9qm+TD_8c0jtB+AOeA@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 2 Jul 2019 15:48:12 +0200
Message-ID: <CAOj+MMFq+zBJ+o=6GrK=YeNCRz+JsXdTj82xggubHq0+wf725Q@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: "Enke Chen (enkechen)" <enkechen@cisco.com>, Randy Bush <randy@psg.com>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009f5e53058cb2ffac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/OnpXXXA4JGaoiaQ5ID_Sr2lRzC4>
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 13:48:28 -0000

Alvaro,

> 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.”

I don't think this is the point here.

The issue is this:

Current version of the draft defines one simple capability to indicate
support for both sending and receiving.

Enke brings a valid point that there can be implementations and various use
cases where support for both may be too heavy and that we rather do more
atomic signalling in the protocol just like it has been done for example in
ORF Capability [Ref: RFC5291 Section 5]. Now WG can argue that point.

Cheers,
Robert.


On Tue, Jul 2, 2019 at 3:34 PM Alvaro Retana <aretana.ietf@gmail.com> wrote:

> On July 1, 2019 at 11:39:39 PM, Enke Chen (enkechen) (enkechen@cisco.com)
> wrote:
>
> Enke:
>
> Hi!
>
> Were there any specific issues for the capability to be unidirectional?
> It's not
> clear to me how requiring the capability to be bidirectional would help.
>
>
> 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.”
>
> IOW, it is not so much that the meaning can’t be something else…but that
> this is how it was designed.
>
> Alvaro.
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>