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

["Susan Hares" <[e-mail]>]

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:[e-mail]] 
Sent: Saturday, October 20, 2018 7:15 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
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. 

 

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 <[e-mail]> 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) <[e-mail]> 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 <[e-mail]> On Behalf Of Susan Hares
Sent: 19 October 2018 20:06
To: Acee Lindem (acee) <[e-mail]>; 'Robert Raszuk' <[e-mail]>
Cc: [e-mail]
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:[e-mail]] On Behalf Of Susan Hares
Sent: Friday, October 19, 2018 10:11 AM
To: 'Acee Lindem (acee)'; 'Robert Raszuk'
Cc: [e-mail]
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:[e-mail]] 
Sent: Friday, October 19, 2018 10:05 AM
To: Robert Raszuk; [e-mail]
Cc: [e-mail]
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 <[e-mail]> on behalf of Robert Raszuk <[e-mail]>
Date: Friday, October 19, 2018 at 9:38 AM
To: Susan Hares <[e-mail]>
Cc: IDR List <[e-mail]>
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
[e-mail]
https://www.ietf.org/mailman/listinfo/idr