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

["Ketan Talaulikar (ketant)" <[e-mail]>]

< 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 <[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]<mailto:[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]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>> on behalf of Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Date: Friday, October 19, 2018 at 9:38 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>
Cc: IDR List <[e-mail]<mailto:[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.