Re: [Idr] Multi Instance BGP

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> 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:[e-mail]] *On Behalf Of *Robert Raszuk
> *Sent:* Monday, October 22, 2018 5:11 PM
> *To:* [e-mail]
> *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: <[e-mail]>
> 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
>