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

Robert Raszuk <robert@raszuk.net> Fri, 02 August 2019 15:29 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 AFBB7120451 for <idr@ietfa.amsl.com>; Fri, 2 Aug 2019 08:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 ZPrkLkFv4vbX for <idr@ietfa.amsl.com>; Fri, 2 Aug 2019 08:29:54 -0700 (PDT)
Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (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 69F0912044F for <idr@ietf.org>; Fri, 2 Aug 2019 08:29:54 -0700 (PDT)
Received: by mail-qk1-x743.google.com with SMTP id d15so55068345qkl.4 for <idr@ietf.org>; Fri, 02 Aug 2019 08:29:54 -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=OQyqxkq9sWovRJYPE0TTjrtSuK8owOKUejDU9GLZ0h4=; b=VBuaeA8LdE1tI00fjOpi9Yxj73/Q7ObYT5JaPnpbpRygQnYQocN4nzDlFEIAs0+jmN xH3jDF6VHIkXMEP9eSPuOU/bqZO8V4ZJP/HrTDoyabkXJFoG5xK0ij240fPiXrKh/ybT xijR0I/2bHhOqaqEIqKTSYWfDLCefRqbI5h7joETi+fXsKS8ZK9L91QxoeFF6+suzkYX tV1ebkeVb/qaadF64QmC++1FiYjYvDKRv/uOFsoY+aXzZRNhlsfKYhwM+WWALeK06swX VCXprcK4uytsIbiITxCBHH1EqODEEwnoz6bUGEbM1hvtlUTOrkgqbrxG8ueo9QMIe05b nLMw==
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=OQyqxkq9sWovRJYPE0TTjrtSuK8owOKUejDU9GLZ0h4=; b=ISBhJ/WT9IxZxea0WDTrRPdH2A5F5ThnJ/Tnu34pFq5I4k++BkVRyytOdtBo387LWH YCm4eO2dcosuchnRZs5WPS1j2wSFVkQuKH/Dy5AA04Yd4lFMOwbJgKBMNHXs0R4armj1 6A73UZcIbYgC7F6/yVyNVkZnyBfCQTEmBlkenKlshJAy49smHFsuVyVLSvFxgoOazUTu +xYgX1RpO48tLlN1A+PGgn8y4gzBaOJrVfFk5RqDulM9z2GRFlzsYfIzMC12S8yKqXR9 QZ6KuKlaVEZzDJx17HWwFLRj6nCtoiyn4UkgGCVqtziMODKuASxCbjZEl8zTcsAtQFS1 aiOw==
X-Gm-Message-State: APjAAAUS/6fJyQwMy6FRcw9Lf2mOG/wTJOqPr3qq5y0ni0f0FStwtNP8 OTQBkal9FZ1nB7SEE2y3rfCa677T0m/Cd80+fdcY6Q==
X-Google-Smtp-Source: APXvYqyODBBXoUfpXlnM9MEN0Kl7THXH6lgdYxqVN85Z+MOzzRWQTYvmWo+ILZG5XFPYkBQ1LiOctTbOQ5UVZzigZBc=
X-Received: by 2002:a05:620a:1286:: with SMTP id w6mr88568257qki.219.1564759793492; Fri, 02 Aug 2019 08:29:53 -0700 (PDT)
MIME-Version: 1.0
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> <dc99fdf4-cb19-34d9-d34b-5ef18f559326@foobar.org>
In-Reply-To: <dc99fdf4-cb19-34d9-d34b-5ef18f559326@foobar.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 2 Aug 2019 11:29:44 -0400
Message-ID: <CAOj+MMHEmQmPeYjWr-v3B1HXL3wYkku57e0SnZaT5dBpYrLAJw@mail.gmail.com>
To: Nick Hilliard <nick@foobar.org>
Cc: Job Snijders <job@ntt.net>, "idr@ietf.org" <idr@ietf.org>, Rob Shakir <robjs@google.com>, david.freedman@uk.clara.net
Content-Type: multipart/alternative; boundary="000000000000a67947058f2407e4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/oor21FyjqGBw4U9ouzhcdsFQuGM>
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:29:57 -0000

Hey Nick & Job,

Extremely happy to see your support here.

Draft wise I think we still have sources :) But what really got this work
stuck is implementations.

Perhaps if we could make FRR and BIRD to implement it we could test it and
ask for WGLC.

Of course if there is seriou sinterest we should also ask for IANA
allocations too. I think both Rob & David would be happy to see this moving
forward too :)

Thx a lot,
R.


On Fri, Aug 2, 2019 at 11:22 AM Nick Hilliard <nick@foobar.org> wrote:

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