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

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sat, 20 Oct 2018 04:42:01 +0000

< updating the subject line to not confuse with a specific draft under review ☺ >

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 <[email-masked]> On Behalf Of Susan Hares
Sent: 19 October 2018 20:06
To: Acee Lindem (acee) <[email-masked]>; 'Robert Raszuk' <[email-masked]>
Cc: [email-masked]
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:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, October 19, 2018 10:11 AM
To: 'Acee Lindem (acee)'; 'Robert Raszuk'
Cc: [email-masked]<mailto:[email-masked]>
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:[email-masked]]
Sent: Friday, October 19, 2018 10:05 AM
To: Robert Raszuk; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 19, 2018 at 9:38 AM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>
Cc: IDR List <[email-masked]<mailto:[email-masked]>>
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.

---

From: Nikos Triantafillis <[email-masked]>
Date: Fri, 19 Oct 2018 22:30:57 -0700

+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) <[email-masked]>
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 ?
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of * Susan Hares
> *Sent:* 19 October 2018 20:06
> *To:* Acee Lindem (acee) <[email-masked]>; 'Robert Raszuk' <
> [email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Idr] Review of
> draft-ietf-idr-bgpls-segment-routing-epe-16.txt
>
>
>
> Robert:
>
>
>
> 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:[email-masked] <[email-masked]>] *On
> Behalf Of *Susan Hares
> *Sent:* Friday, October 19, 2018 10:11 AM
> *To:* 'Acee Lindem (acee)'; 'Robert Raszuk'
> *Cc:* [email-masked]
> *Subject:* Re: [Idr] Review of
> draft-ietf-idr-bgpls-segment-routing-epe-16.txt
>
>
>
> Acee:
>
>
>
> *From:* Acee Lindem (acee) [mailto:[email-masked] <[email-masked]>]
> *Sent:* Friday, October 19, 2018 10:05 AM
> *To:* Robert Raszuk; [email-masked]
> *Cc:* [email-masked]
> *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 <[email-masked]> on behalf of Robert Raszuk <
> [email-masked]>
> *Date: *Friday, October 19, 2018 at 9:38 AM
> *To: *Susan Hares <[email-masked]>
> *Cc: *IDR List <[email-masked]>
> *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.*
>
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 20 Oct 2018 13:15:13 +0200

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 <
[email-masked]> wrote:

> On Fri, Oct 19, 2018 at 9:42 PM Ketan Talaulikar (ketant) <
> [email-masked]> wrote:
>

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 20 Oct 2018 13:30:13 -0400

Ketan, Robert and all:

I’d like to pick up on one question Robert asked.  If you have an implementation of multisession code, please let the WG chairs know.  I would love to progress this document if there are 2 implementations (John’s an author).  

If there are not implementations, the WG chairs are interested to know if implementation are planned or if there are problems with this draft. 

Cheerily, Susan Hares 

From: Robert Raszuk [mailto:[email-masked]] 
Sent: Saturday, October 20, 2018 7:15 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] BGP session isolation for BGP-LS (and others in general)

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. 

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 <[email-masked]> 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) <[email-masked]> wrote:

< updating the subject line to not confuse with a specific draft under review J >

Thanks,

Ketan

Robert: 

https://tools...ietf.org/html/draft-raszuk-ti-bgp-01 <https://tools.ietf.org/html/draft-raszuk-ti-bgp-01> 

Sue 

Acee:

Sue 

From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Friday, October 19, 2018 10:05 AM
To: Robert Raszuk; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] Review of draft-ietf-idr-bgpls-segment-routing-epe-16.txt

Hi Sue, Robert,

Thanks,

Acee

From: Idr <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Friday, October 19, 2018 at 9:38 AM
To: Susan Hares <[email-masked]>
Cc: IDR List <[email-masked]>
Subject: Re: [Idr] Review of draft-ietf-idr-bgpls-segment-routing-epe-16.txt

Hi Sue,

Ref: https://tools...ietf.org/html/draft-raszuk-ti-bgp-01 <https://tools.ietf.org/html/draft-raszuk-ti-bgp-01> 

Thx,

R.

---

From: Nikos Triantafillis <[email-masked]>
Date: Sun, 21 Oct 2018 13:59:58 -0700

Responses inline.

Best Regards,

Nikos.-

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

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

> multisessions can I allocate 4 core to one bgp process and 2 to the other

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

> cover part of the use case then declared at IETF in Stockholm "Robert - we

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