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

Randy Bush <randy@psg.com> Tue, 02 July 2019 14:41 UTC

Return-Path: <randy@psg.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 F39881200EB for <idr@ietfa.amsl.com>; Tue, 2 Jul 2019 07:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 IoVjlPi2IjhP for <idr@ietfa.amsl.com>; Tue, 2 Jul 2019 07:41:13 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B902212008C for <idr@ietf.org>; Tue, 2 Jul 2019 07:41:13 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from <randy@psg.com>) id 1hiJy0-0000k6-NO; Tue, 02 Jul 2019 14:41:08 +0000
Date: Tue, 02 Jul 2019 07:41:08 -0700
Message-ID: <m2o92cwlbv.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, "Enke Chen (enkechen)" <enkechen@cisco.com>, "idr@ietf.org" <idr@ietf.org>
In-Reply-To: <CAOj+MMFq+zBJ+o=6GrK=YeNCRz+JsXdTj82xggubHq0+wf725Q@mail.gmail.com>
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>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="ISO-2022-JP"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/TLCafMI-kdKPiBSA1YiUxRWeeBI>
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:41:15 -0000

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