Re: [Idr] Multi Instance BGP

"UTTARO, JAMES" <ju1738@att.com> Tue, 23 October 2018 14:41 UTC

Return-Path: <ju1738@att.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 0E57F130F4C for <idr@ietfa.amsl.com>; Tue, 23 Oct 2018 07:41:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.389
X-Spam-Level: *
X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 hC9roYRkcywm for <idr@ietfa.amsl.com>; Tue, 23 Oct 2018 07:41:32 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 E1D57128BCC for <idr@ietf.org>; Tue, 23 Oct 2018 07:41:31 -0700 (PDT)
Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w9NEaCLG048571; Tue, 23 Oct 2018 10:41:31 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 2na35emt5s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Oct 2018 10:41:29 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w9NEfQ2g003641; Tue, 23 Oct 2018 10:41:27 -0400
Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [135.66.87.47]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w9NEfNFx003593; Tue, 23 Oct 2018 10:41:24 -0400
Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [127.0.0.1]) by zlp27126.vci.att.com (Service) with ESMTP id A7FBE40F6CEC; Tue, 23 Oct 2018 14:41:23 +0000 (GMT)
Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (unknown [130.9.129.145]) by zlp27126.vci.att.com (Service) with ESMTPS id 826A1400069B; Tue, 23 Oct 2018 14:41:23 +0000 (GMT)
Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.216]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0415.000; Tue, 23 Oct 2018 10:41:23 -0400
From: "UTTARO, JAMES" <ju1738@att.com>
To: Robert Raszuk <robert@raszuk.net>
CC: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] Multi Instance BGP
Thread-Index: AQHUakvpgAW5K/jNnkeXy2XMHm0ieaUs1BLAgABJKAD//8qr8A==
Date: Tue, 23 Oct 2018 14:41:23 +0000
Message-ID: <B17A6910EEDD1F45980687268941550F367CA26D@MISOUT7MSGUSRCD.ITServices.sbc.com>
References: <CAOj+MMHehQrkDDcnd5kAhq4AgdW-DbFErUMxRGffBo1P=1vYeg@mail.gmail.com> <B17A6910EEDD1F45980687268941550F367CA1C2@MISOUT7MSGUSRCD.ITServices.sbc.com> <CAOj+MMFNFhdHixnjxyXs=3MFoN_zDyZZAQEFwk37VaWvqgcQ2w@mail.gmail.com>
In-Reply-To: <CAOj+MMFNFhdHixnjxyXs=3MFoN_zDyZZAQEFwk37VaWvqgcQ2w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.91.76.217]
Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F367CA26DMISOUT7MSGUSRCD_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-23_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810230117
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/NLoz2xBWPIBMbL2X232p7xByF8U>
Subject: Re: [Idr] Multi 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: Tue, 23 Oct 2018 14:41:38 -0000

Robert,

                I would suggest adding a paragraph under Sect 5 that details the separation discussed below and in Sec 6 ( Benefits ) articulate why this benefits providers using BGP across multiple FOUs..

Thanks,
                Jim Uttaro

From: Robert Raszuk [mailto:robert@raszuk.net]
Sent: Tuesday, October 23, 2018 9:51 AM
To: UTTARO, JAMES <ju1738@att.com>
Cc: idr@ietf.org
Subject: Re: [Idr] Multi Instance BGP

Hi Jim,

This goes without saying :) Each BGP instance is 100% independent from each other in all respect. You can assign same or different AS numbers to it.

You can also assign same or different SAFIs to each (case where you trust more your hardware then BGP code and want to run for free N BGP planes for a given SAFI (or rolling new feature first into test plane) .

So the MI-BGP supports your wish day one. If you think that we should add more text to describe this explicitely I am very happy to do that, but was actually trying to trim the text :)

Many thx for your review !
Robert.





On Tue, Oct 23, 2018 at 3:33 PM UTTARO, JAMES <ju1738@att.com<mailto:ju1738@att.com>> wrote:
Robert,

                I see no mention of being able to assign different AS numbers to different instances.. At various times over the years I have identified the rationale for assigning different AS numbers based on AFI/SAFI on a given router. As an ex FlowSpec, L3VPN, L2VPNā€¦ on the same box may require a service provider to organize the AS numbering that is optimized for one of these but is problematic for others. This then requires AS manipulation on a per box basis which is undesirable.. Would it make sense to add this separation along with AFI/SAFI in this doc??

Thanks,
                Jim Uttaro

From: Idr [mailto:idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>] On Behalf Of Robert Raszuk
Sent: Monday, October 22, 2018 5:11 PM
To: idr@ietf.org<mailto:idr@ietf.org>
Subject: [Idr] Multi Instance BGP

Hello,

To meet the submission deadline I uploaded a below proposal for Multi Instance BGP.

Please do not hesitate to provide any comments on or off the list.

I consider it as first possible step to separate BGP-LS (or for that matter other non
routing related data) into independent BGP process primarily targeting to run
on the x86 general compute hardware without making any changes to BGP code
therefor making it 100% backwards compatible.

If there is need we could discuss it during the interim meeting, otherwise we could
just keep it for the list based comments.

Kind regards,
Robert

---------- Forwarded message ---------
From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Date: Mon, Oct 22, 2018 at 11:00 PM
Subject: New Version Notification for draft-raszuk-mi-bgp-00.txt

A new version of I-D, draft-raszuk-mi-bgp-00.txt
has been successfully submitted by Robert Raszuk and posted to the
IETF repository.

Name:           draft-raszuk-mi-bgp
Revision:       00
Title:          Multi Instance BGP
Document date:  2018-10-22
Group:          Individual Submission
Pages:          9
URL:            https://www.ietf.org/internet-drafts/draft-raszuk-mi-bgp-00.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Draszuk-2Dmi-2Dbgp-2D00.txt&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=VlD88dkPqw1byyLEghLDS69vtpVXfXnfbzWwstsYYF4&s=CLwiQW2hsMqmZlEIPU6HanNwfpg0lJy5arvVjQirJS0&e=>
Status:         https://datatracker.ietf.org/doc/draft-raszuk-mi-bgp/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Draszuk-2Dmi-2Dbgp_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=VlD88dkPqw1byyLEghLDS69vtpVXfXnfbzWwstsYYF4&s=5koRhnYM1PZJ_SGYUipS3CI0bpIdSOK5XfP7GREPWIY&e=>
Htmlized:       https://tools.ietf.org/html/draft-raszuk-mi-bgp-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Draszuk-2Dmi-2Dbgp-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=VlD88dkPqw1byyLEghLDS69vtpVXfXnfbzWwstsYYF4&s=v11LHxWCrnk__YRhtsfWJphXbfPPjdeEVoAnoqcoQbA&e=>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-raszuk-mi-bgp<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Draszuk-2Dmi-2Dbgp&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=VlD88dkPqw1byyLEghLDS69vtpVXfXnfbzWwstsYYF4&s=Gfttt-yV_QgPoqiqajFASYFBDIpAZHfM7Orctu6M5jU&e=>


Abstract:
   As the number of operational use cases of BGP grows there is demand
   to increase the level of separation and processing independence
   between various address families carried by BGP today.  This document
   augments base BGP specification in allowing local configuration of
   BGP port number by the operator to run parallel fully disjoined BGP
   instances allowing full processing separation between them.

   While local BGP implementation may already assure BGP process or
   thread robustnes the general aim here is to allow similar level of
   groups of BGP address families independence when running BGP code on
   general purpose hardware as well as x86 based route reflectors..

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=VlD88dkPqw1byyLEghLDS69vtpVXfXnfbzWwstsYYF4&s=kCiDrHZDlNSo-Ubre0dWwsF9rmliK94I7xr8BJu2iTg&e=>.

The IETF Secretariat