[Idr] Transport Instance BGP

Robert Raszuk <robert@raszuk.net> Wed, 29 July 2020 09:06 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 1CEBA3A0878 for <idr@ietfa.amsl.com>; Wed, 29 Jul 2020 02:06:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 VY32PKSZj3lP for <idr@ietfa.amsl.com>; Wed, 29 Jul 2020 02:06:05 -0700 (PDT)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 776073A085A for <idr@ietf.org>; Wed, 29 Jul 2020 02:06:05 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id v22so6077918edy.0 for <idr@ietf.org>; Wed, 29 Jul 2020 02:06:05 -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=wjZpukrLSImr1iVkbN4YfbJq5gkivgsZC8z7PkiIIB4=; b=Q/s92fBGgcocQ+tYfhRx1lgmfjrKv75nJ7UVURYLG61FSVf29cjtE9CHDbtntde0qh Izv4q/BJFi18Kn5INZkJcicuhPE5ztJYQ8Nm+OuZPvL8F0z7TxMAudxSS+OXRFcGnORb Sq462UEqEgI1Jegs8m/JhiezyFGP0QAJBhzzzOH65jNNajAAhcjShPdU7/oBaH/xEclt uBqlRIsXBsP21DN15X7ZUqyepD0lXGp/PiXgxEJwV876NO1/JN191104AwaIAZg8Pe9H rlpoClBEhUNI8wWAGHp5uG2ksCara2KHUNek9vZRxK/gphOcCmAUL112dKY0JHf+xwGe wPeQ==
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=wjZpukrLSImr1iVkbN4YfbJq5gkivgsZC8z7PkiIIB4=; b=jRKk7IWWBG4XZZ3KPVAcdydgSZ14K2caEAvGFwBVizwvRbGedcFEzg632Nuy4hu1iM zv3XDQfugPLP4AgS8RczmHzZcnlJunP3MlFP8leagl9JcgMbmrOmWDEWrLxz+zNFrado Rk9SJX9HoNV/LniDRsRIgoB82vTNcQHE9naaqlNJNXHLewjRQgZBjZM2HBTy7VX/p2Ij 7e+jaafUS0CfBY10EI9hM8weBWXiCPBz7Uj+QJog/f/P/XR7UWIIl7MihaMAeFdylb5d q+/NPzJCRsvk7WdDf5e3AZ/dGniQVnuEGqm2Gu6oWAGCVO5PmRE5X0B9jdO59Kyb2bWN SY9w==
X-Gm-Message-State: AOAM531wxCYlIiieWjlqnFcd3GpluphmP8MK3Kt816S/F2Yw6QpATtuc 1Q3qZhYLz2xkHD/8VgjlbEbjZrJrkA1b7IRp/6EYMA==
X-Google-Smtp-Source: ABdhPJx/34e3qy8iEV5/cIE8023m4zGuK4GM4ghEueQOENF7n5YiKbgT8tP64m6gkxvVoHyitrM9ymFxIzrHzCu3PzI=
X-Received: by 2002:aa7:db06:: with SMTP id t6mr30294053eds.369.1596013563790; Wed, 29 Jul 2020 02:06:03 -0700 (PDT)
MIME-Version: 1.0
References: <SN6PR13MB23347FC0BC5212B52E62591385750@SN6PR13MB2334.namprd13.prod.outlook.com> <CAOj+MMFqFaQ3e6voR-4LyZaAwY2VVX12h_z8tTtJMV+y9KJjyw@mail.gmail.com> <SN6PR13MB2334CCDC36A49DC07F05946485720@SN6PR13MB2334.namprd13.prod.outlook.com> <CAOj+MMHOt+7-suB9Y3cRbC0osM5i+-ueNaGUjfVO3iShUF276Q@mail.gmail.com> <214FC810-D50E-4F48-96AB-0DAB894FBB8A@icloud.com>
In-Reply-To: <214FC810-D50E-4F48-96AB-0DAB894FBB8A@icloud.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 29 Jul 2020 11:05:53 +0200
Message-ID: <CAOj+MMF+61OiddMSp_y2Cq+Fb-YVh4R=7azTRiTnfz3tXazfaQ@mail.gmail.com>
To: Greg Skinner <gregskinner0@icloud.com>
Cc: "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000086e6f305ab90ddaa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/dB9Gz64sbAsAIN_tSqX7UN6jF_c>
Subject: [Idr] Transport Instance BGP
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: Wed, 29 Jul 2020 09:06:08 -0000

Hi Greg,

Many thx for your comments. I do agree with all of them and if there is
interest in IDR to proceed all of your points will be addressed.

Just a note on the first point you made ...

The proposal was shelved due to claims being made at and around Stockholm
IETF that all we need is working BGP multi sessions to demux specific
AFI/SAFI to a different session or different process within the box.

Well 10 years after I have not seen this to happen in *any* implementation.

Moreover in the mean time I see the proposals like BGP-LS which were
promised during WG processing and LC to be deployed separately from Routing
BGP (ex: dedicated RRs) in real deployments running on the same session and
on the same platforms (RRs) where LSDB is fighting for processing resources
with IP routes.

So here when we are discussing just using BGP as a transport because:

a) it is there
b) it takes everything (well used to till today :)
c) it is loop free distribution

my point of mentioning use of ti-bgp proposal (btw second choice if you go
back to the note - first being JSON format and CURL for this type of
distributions) was to at least decouple it hard from IP routing.

Many thx,
Robert.


On Wed, Jul 29, 2020 at 3:06 AM Greg Skinner <gregskinner0@icloud.com>
wrote:

> (I limited the recipients in my response in order to (hopefully) focus on
> the IDR-specific topics covered in the quoted text.)
>
> Regarding draft-raszuk-ti-bgp-01, if IDR has an interest in pursuing it
> again, I have some concerns:
>
>
>    - There were several issues raised
>    <https://www.ietf.org/proceedings/75/minutes/idr.txt> during the IDR
>    WG meeting during IETF 75 that should be addressed, IMO.
>    - I found some other issues in the draft that weren’t brought up
>    during that meeting.  For example, in Section 5.5
>    <https://tools.ietf.org/html/draft-raszuk-ti-bgp-01#section-5.5>, it
>    is stated that "On the network side all today's BGP messages are send with
>    IP precedence value of Internetwork Control of 110000, which is used for
>    high-priority routing traffic.”  Is this true, even for open-source BGP
>    implementations?  I looked at the source code for three implementations
>    (Bird, FRR, and OpenBGPD), and was only able to confirm this for IPv4
>    OpenBGPD messages.
>    - One of the normative references, RFC 5226
>    <https://tools.ietf.org/html/rfc5226>, has been obsoleted by RFC 8126
>    <https://tools.ietf.org/html/rfc8126>.
>    - Several of the informative references have expired.
>    - The draft would require numerous editorial changes due to errors in
>    spelling, grammar, etc.
>
>
> Regards, Greg
>