Re: [Idr] BGP session isolation for BGP-LS (and others in general)

Responses inline.

Best Regards,

Nikos.-

On Sat, Oct 20, 2018 at 4:15 AM Robert Raszuk <robert@raszuk.net> wrote:

>
> 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.
>

NT: At the time, there was no significant need for it. That was 10+ yrs
ago. Things change. The draft is quite simple and the argument against it
based on whether some code bases had buggy or complex implementations,
lacks merit.

> 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.
>

NT: That's just different optics. You clearly believe process isolation is
the protocol's specification job. Others, don't.

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 ?
>

NT: For such process resource allocation you will need to talk to your
favorite protocol implementor.

> 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".
>

NT: If it was indeed covered, what's the issue? If you think it wasn't, why
not make suggestions for changes?

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
>>>
>>