Re: [Idr] Transport Instance BGP

Zhuangshunwan <zhuangshunwan@huawei.com> Wed, 29 July 2020 10:09 UTC

Return-Path: <zhuangshunwan@huawei.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 5CB5F3A0645 for <idr@ietfa.amsl.com>; Wed, 29 Jul 2020 03:09:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 cje_fTyMup1k for <idr@ietfa.amsl.com>; Wed, 29 Jul 2020 03:09:28 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 6ED923A05A7 for <idr@ietf.org>; Wed, 29 Jul 2020 03:09:28 -0700 (PDT)
Received: from lhreml735-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E9E9F39BB1ED4836CCF9 for <idr@ietf.org>; Wed, 29 Jul 2020 11:09:26 +0100 (IST)
Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml735-chm.china.huawei.com (10.201.108.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 29 Jul 2020 11:09:26 +0100
Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 29 Jul 2020 18:09:23 +0800
Received: from nkgeml708-chm.china.huawei.com ([10.98.57.160]) by nkgeml708-chm.china.huawei.com ([10.98.57.160]) with mapi id 15.01.1913.007; Wed, 29 Jul 2020 18:09:23 +0800
From: Zhuangshunwan <zhuangshunwan@huawei.com>
To: Robert Raszuk <robert@raszuk.net>, Greg Skinner <gregskinner0@icloud.com>
CC: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] Transport Instance BGP
Thread-Index: AQHWZYeUx4OZFvL5M0WBqhlaxXgasakeU8iw
Date: Wed, 29 Jul 2020 10:09:23 +0000
Message-ID: <a411014fb097445a8445d5b1b4953de1@huawei.com>
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> <CAOj+MMF+61OiddMSp_y2Cq+Fb-YVh4R=7azTRiTnfz3tXazfaQ@mail.gmail.com>
In-Reply-To: <CAOj+MMF+61OiddMSp_y2Cq+Fb-YVh4R=7azTRiTnfz3tXazfaQ@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.202.109]
Content-Type: multipart/alternative; boundary="_000_a411014fb097445a8445d5b1b4953de1huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/8jZsOgNGx1qtbmLW5VJkgfVzSVw>
Subject: Re: [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 10:09:31 -0000

Hi Robert,

When you mentioned BGP multi-session, I wondered what the drawbacks of this solution were that it was abandoned?

Thanks,
Shunwan

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, July 29, 2020 5:06 PM
To: Greg Skinner <gregskinner0@icloud.com>
Cc: idr@ietf.org
Subject: [Idr] Transport Instance BGP

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<mailto: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>.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>26>, has been obsoleted by RFC 8126<https://tools.ietf.org/html/rfc8126>26>.
  *   Several of the informative references have expired.
  *   The draft would require numerous editorial changes due to errors in spelling, grammar, etc.

Regards, Greg