Re: [Idr] BGP session isolation for BGP-LS (and others in general)
Robert Raszuk <robert@raszuk.net> Sat, 20 October 2018 11:15 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 85F7C12D4EF for <idr@ietfa.amsl.com>; Sat, 20 Oct 2018 04:15:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_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 d9ZYCc0137s0 for <idr@ietfa.amsl.com>; Sat, 20 Oct 2018 04:15:24 -0700 (PDT)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 AAF9B1294D0 for <idr@ietf.org>; Sat, 20 Oct 2018 04:15:23 -0700 (PDT)
Received: by mail-qk1-x735.google.com with SMTP id q184-v6so4550454qkd.3 for <idr@ietf.org>; Sat, 20 Oct 2018 04:15:23 -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=rzrG/1nmgyNe62I+gfVN1xc72tG5bG3qIj/3VO1QjLY=; b=R/cZqSsgE/uLsF1czBhEekIXav55E3Z/9kfgA7LMAq4sBc4Sq2GrW4qds5hY1IQpdC +U9IiUu9Qgo4t/TYIDEkhGnNNT/wvT+Zfn/DwE6ju5khCwbIzhN8Yitca942y7P6NrWj GJkwMN88DAuAsesG5iDhmEDUc34UXNXdFDtcCekgO+M3cnahRTOsV24IvXBRpZgqti47 z8qH37OCw7mXJrLVJtlqP5VabJ0Zt16zDp0AZio/ry5tiSQB18M/zzGPrGwlgXVYTOHL ppUWDkqrvCMh1M7U/w6Uhuo4ECFeeRjxdXuRU9AJxlum92XkVSUJmNpg+JtvWXP9L3PN uT2A==
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=rzrG/1nmgyNe62I+gfVN1xc72tG5bG3qIj/3VO1QjLY=; b=EkRM4EErZIHGx/w78n+oQPEBUzzcQ3q9xJ6KDR1jhVXsqMVejvIBBb4TtTcmF/fjqK iACphVrh9vJmJjnkNg2PuloTm4RgVKgUupaotgfrZ7zPPcRBXkWIEnGP/mcysaF1F24W 34+7ew1IFqOzi/0Y2E9fz3OiZ0jMugM7lbl58ozTDeuwfeoA7vzMvZykh1LCVVGxi+kc yLr0K9gVJHRCtBY5Y45sM1vqkBbIIIgRbTPW/YCKQKtqzLwTXOk1Ju6kdYxNP53Osolh Nzcy8ibb8FBuznH8Jg9H0CGFTOvq3hk+TKRppM4nJc2Y4DytxjVd2w+7DmYaK9QUklIK 7V9w==
X-Gm-Message-State: ABuFfojjseV53fzWIPA0detB9AOH9hAXB5iQzxTfyfPsP4GYoQ39683u hzVlGkv+54yqgFGWwLHcOJRXhtdfhsuc0KqNapd8yQ==
X-Google-Smtp-Source: ACcGV61H4BxtCe453nN3AmK72e8rCB/FKsud3hVOco0js0pA2ymK0rM16i6cw2it43CMyXdQ2uqysiWwtgT8Qrl9X2s=
X-Received: by 2002:a37:9dd5:: with SMTP id g204-v6mr36177702qke.41.1540034122714; Sat, 20 Oct 2018 04:15:22 -0700 (PDT)
MIME-Version: 1.0
References: <9d7207cbd2d84aa784689fbf4d747833@XCH-ALN-008.cisco.com> <CA+R4MGeqVAmh9E=CMKDD2xN+zAbg2vdbvAvZH8QBcE3fNo+stw@mail.gmail.com>
In-Reply-To: <CA+R4MGeqVAmh9E=CMKDD2xN+zAbg2vdbvAvZH8QBcE3fNo+stw@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 20 Oct 2018 13:15:13 +0200
Message-ID: <CAOj+MMHjNb62OsZb2GgSZtbDfk4uM2PhXJFjoXQuBDXdnjw9hQ@mail.gmail.com>
To: ntriantafillis@gmail.com
Cc: ketant@cisco.com, shares@ndzh.com, acee@cisco.com, idr@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d3a5780578a722c8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/nBWT6He3G4ad4cRcfzBpeV1bEog>
Subject: Re: [Idr] BGP session isolation for BGP-LS (and others in general)
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: Sat, 20 Oct 2018 11:15:26 -0000
Multisessions has been proposed long time back and since then there is hardly any significant support of it in the shipping bgp code. I recall there was a wave of it during times of MTR excitements, but then it apparently faded away. From some of the popular code basis last time I heard that it was even removed as too complex and too buggy. Is there anywhere a valid IETF implementation report of it ? Besides multisessions may if available address only a fraction of the problem - being session isolation from error handling point of view. It gives zero control on the actual process isolation which I am mainly after. I am deploying route reflection on x86 servers and I would like to run on the same hardware and same linux OS two BGP processes IOS for routing and Junos for BGP-LS. How can I do that today without going to VMs, LXCs or injecting additional routes (last assuming that BGP code goes deep to kernel and can lock itself to single IP address on the box) ? How using multisessions can I allocate 4 core to one bgp process and 2 to the other one - cli examples ? Multisessions has been written with one BGP code base in mind - even if multi threaded. That is not a sufficient control of the execution. Yes soon after I wrote TI proposal John updated the multisessions draft to cover part of the use case then declared at IETF in Stockholm "Robert - we got it covered". If there is no interest then it is perfectly fine ... you all can still wait for the day multisessions ships and actually works yet I can refocus on how to run various BGP code code basis with platform virtualization. Well as a matter of fact some newest BGP implementations already support a lot of resource control so defining a new TCP port is really not needed there.It is just a low hanging fruit for the legacy BGP world. Kindest regards, RR. On Sat, Oct 20, 2018 at 7:31 AM Nikos Triantafillis < ntriantafillis@gmail.com> wrote: > +1 on https://tools.ietf.org/html/draft-ietf-idr-bgp-multisession-07 for > session isolation. > > Nikos.- > > On Fri, Oct 19, 2018 at 9:42 PM Ketan Talaulikar (ketant) < > ketant@cisco.com> wrote: > >> < updating the subject line to not confuse with a specific draft under >> review J > >> >> >> >> While we are doing this analysis for best way to achieve session >> isolation, how about >> https://tools.ietf.org/html/draft-ietf-idr-bgp-multisession-07 ? >> >> >> >> Any feedback/inputs on this mechanism? >> >> >> >> Thanks, >> >> Ketan >> >> >> >> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of * Susan Hares >> *Sent:* 19 October 2018 20:06 >> *To:* Acee Lindem (acee) <acee@cisco.com>; 'Robert Raszuk' < >> robert@raszuk.net> >> *Cc:* idr@ietf.org >> *Subject:* Re: [Idr] Review of >> draft-ietf-idr-bgpls-segment-routing-epe-16.txt >> >> >> >> Robert: >> >> >> >> My understanding is that you wish me to do a WG adoption call for the >> following draft: >> >> >> >> https://tools...ietf.org/html/draft-raszuk-ti-bgp-01 >> <https://tools.ietf.org/html/draft-raszuk-ti-bgp-01> >> >> >> >> I will review the draft for an adoption call later today. You will need >> to present at the IDR interim so that the IDR WG can ask questions. >> >> >> >> Sue >> >> >> >> *From:* Idr [mailto:idr-bounces@ietf.org <idr-bounces@ietf.org>] *On >> Behalf Of *Susan Hares >> *Sent:* Friday, October 19, 2018 10:11 AM >> *To:* 'Acee Lindem (acee)'; 'Robert Raszuk' >> *Cc:* idr@ietf.org >> *Subject:* Re: [Idr] Review of >> draft-ietf-idr-bgpls-segment-routing-epe-16.txt >> >> >> >> Acee: >> >> >> >> Thank you for your feedback on the bis and the ordering of the drafts. >> >> >> >> Sue >> >> >> >> *From:* Acee Lindem (acee) [mailto:acee@cisco.com <acee@cisco.com>] >> *Sent:* Friday, October 19, 2018 10:05 AM >> *To:* Robert Raszuk; shares@ndzh.com >> *Cc:* idr@ietf.org >> *Subject:* Re: [Idr] Review of >> draft-ietf-idr-bgpls-segment-routing-epe-16.txt >> >> >> >> Hi Sue, Robert, >> >> I don’t think we need to gate all the extant BGP-LS drafts on the >> completion of this new work improving the RFC 7752 considerations. I agree >> that it would be useful. >> >> Thanks, >> >> Acee >> >> >> >> *From: *Idr <idr-bounces@ietf.org> on behalf of Robert Raszuk < >> robert@raszuk.net> >> *Date: *Friday, October 19, 2018 at 9:38 AM >> *To: *Susan Hares <shares@ndzh.com> >> *Cc: *IDR List <idr@ietf.org> >> *Subject: *Re: [Idr] Review of >> draft-ietf-idr-bgpls-segment-routing-epe-16.txt >> >> >> >> Hi Sue, >> >> >> >> *[KT] When isolation is not followed then the BGP-LS AFI/SAFI share fate >> with the other MP BGP signaling. This can result in update churn or errors >> hit on one would affect the other. The concern would be that BGP-LS >> topology churn should not come in the way of the (MP) BGP routing updates >> and slow down convergence. The session bring down due to an error >> notification due to some error in BGP-LS encoding is also a likelihood. >> However, all of these are not really specific to this BGP-LS extension and >> should be documented in general for BGP-LS. I volunteer to help with that >> as a separate draft and putting some text like this hear does not seem like >> a good idea.* >> >> >> >> [Sue] An additional draft is a fine way to handle this point as >> >> this problem does impact all BGP-LS. I like this approach. >> >> >> >> However, if you take this approach we will need to have this draft >> >> at a WG draft status before we can forward the other drafts to the >> >> IESG. Can you spin this draft quickly? I will be glad to review it >> >> and do a WG adoption call. Can you get it done over the weekend? >> >> We can talk about it on the 26th. >> >> >> >> Is your intention to "document" the fate sharing issue or solve it ? >> >> >> >> If this is about documenting obvious then sure new draft can be spinned >> over weekend. >> >> >> >> If this is however about solving the issue I recommend we adopt BGP >> Transport Instance draft to WG status and move BGP-LS to simply use new TCP >> port making it at least at the TCP session level fully independent from >> other SAFIs. >> >> >> >> Ref: https://tools...ietf.org/html/draft-raszuk-ti-bgp-01 >> <https://tools.ietf.org/html/draft-raszuk-ti-bgp-01> >> >> >> >> Thx, >> >> R. >> >> >> >> >> >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >
- [Idr] BGP session isolation for BGP-LS (and other… Ketan Talaulikar (ketant)
- Re: [Idr] BGP session isolation for BGP-LS (and o… Nikos Triantafillis
- Re: [Idr] BGP session isolation for BGP-LS (and o… Robert Raszuk
- Re: [Idr] BGP session isolation for BGP-LS (and o… Susan Hares
- Re: [Idr] BGP session isolation for BGP-LS (and o… Nikos Triantafillis