IETF Logo Mail Archive

Re: [Idr] New BGP capability to advertise running daemon version

Nick Hilliard <nick@foobar.org> Fri, 02 August 2019 15:22 UTC

Return-Path: <nick@foobar.org>
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 27788120422 for <idr@ietfa.amsl.com>; Fri, 2 Aug 2019 08:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 yIlG9JFC2ynd for <idr@ietfa.amsl.com>; Fri, 2 Aug 2019 08:22:10 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B33B12041E for <idr@ietf.org>; Fri, 2 Aug 2019 08:22:10 -0700 (PDT)
X-Envelope-To: idr@ietf.org
Received: from crumpet.foobar.org (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x72FM8WK047337 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Aug 2019 16:22:08 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.foobar.org
To: Job Snijders <job@ntt.net>
Cc: Robert Raszuk <robert@raszuk.net>, "idr@ietf.org" <idr@ietf.org>
References: <CAPF+HwV3EEUza3FyiXsd_oSkj80OwY-tE2DgFWnynq1FL2tLHg@mail.gmail.com> <015d56c13d01436890da2b8a7179fac9@turkcell.com.tr> <CAPF+HwV2Df6qcRD+GrE_JFv8W5Yh3OACKZrdv1Bw4PXQbjtDyQ@mail.gmail.com> <20190802150251.GA11217@pfrc.org> <CACWOCC_J6-wMWx7KL2dza5A77KFnoabMt7oAY-xhsGb8Vf3O5w@mail.gmail.com> <CAOj+MMFL7FVciSx1NyCp9zCPXZeRtNn4J-O1vS8btg96ZbDRuA@mail.gmail.com> <CACWOCC_+X2bVWa3iFmb6eQ8FVvvn98h_B12HVVundcqCsd+-Lw@mail.gmail.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <dc99fdf4-cb19-34d9-d34b-5ef18f559326@foobar.org>
Date: Fri, 02 Aug 2019 16:22:07 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.18
MIME-Version: 1.0
In-Reply-To: <CACWOCC_+X2bVWa3iFmb6eQ8FVvvn98h_B12HVVundcqCsd+-Lw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/C1WW2x0ywoRPXHRA6TK4ECsbx6g>
Subject: Re: [Idr] New BGP capability to advertise running daemon version
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, 02 Aug 2019 15:22:13 -0000

I'd be very much in favour of seeing draft-ietf-idr-operational-message 
being pushed towards publication.

Nick

Job Snijders wrote on 02/08/2019 16:21:
> Perhaps this work should be picked up again.
> 
> On Sat, Aug 3, 2019 at 00:19 Robert Raszuk <robert@raszuk.net 
> <mailto:robert@raszuk.net>> wrote:
> 
>     Hi,
> 
>     Just to refresh memory there is an active WG document precisely
>     describing how to carry such information between BGP peers. It is
>     called BGP Operational Message
> 
>     https://tools.ietf.org/html/draft-ietf-idr-operational-message-00
> 
>     The ADVISE TLV there section 3.4.1 and 4 are proposed with the very
>     same intention as this discussion is targeting.
> 
>     Due to no customer push vendors have not implemented it yet. So the
>     draft is just hanging waiting for implementations.
> 
>     I think if there is some new interest please consider to review the
>     linked WG doc and possibly augment it with missing elements.
> 
>     Use of BGP capabilities in current state of implementation of bgp
>     dynamic capabilities is really not the right messaging vehicle here.
> 
>     Thx,
>     R.
> 
>     On Fri, Aug 2, 2019 at 11:09 AM Job Snijders <job@ntt.net
>     <mailto:job@ntt.net>> wrote:
> 
>         Right now operators use the peer’s MAC address and certain TCP
>         behaviorism (nmap -O) to attempt to conclude what the remote
>         side might be in case of issues.
> 
>         I see value in having this on by default. Security through
>         obscurity isn’t the best defense anyway. I’m assuming a degree
>         of trust exists anyway, why else set up a BGP session in the
>         first place?
> 
>         I think there are valid use cases, i think it is worthwhile
>         exploring how to implement this concept.
> 
>         Kind regards,
> 
>         Job
>         _______________________________________________
>         Idr mailing list
>         Idr@ietf.org <mailto:Idr@ietf.org>
>         https://www.ietf.org/mailman/listinfo/idr
> 
> 
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

v2.23.0 | Report a Bug | By Email