Re: [Idr] [EXTERNAL] Re: draft-ietf-rtgwg-net2cloud-problem-statement description on BGP error valid? (was RE: WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

[Robert Raszuk <[e-mail]>]

Hi Linda,

Nope things are getting mixed here.

Jeff's point was: Use Type 2 as most BGP stacks already support type 2 and
count on what is written in the RFC5492 which is a permit to receive a new
BGP Capability and silently drop it.

IMHO this is a bad idea to receive something and not tell the sender that
we do not understand it.

His point against using any other Type of BGP OPEN Optional Parameter was
that it is not deployed hence will result per current RFC4271 rules to drop
the session when received. Note that other then GR handling such drop is
only at the initial session establishment phase so not harmful too much if
sender can retry without it after receiving NOTIFICATION.

For this very functionality of sending peer's OS, BGP version, perhaps also
other "nice to have" information it may be much easier to simply reuse our
BGP Operational Message draft and do it once for all. Then we can clearly
specify as definition of that new message that signalling unsupported types
within it would not result in BGP sessions going down. Yet peer will know
that the other side did not understood the language.

Kind regards,
R.





On Tue, Jan 17, 2023 at 5:47 PM Linda Dunbar <[e-mail]>
wrote:

> Robert,
>
>
>
> Jeff Haas said in his Jan 16 email (attached)
>
>
>
> *“John Scudder made most of the arguments I'd be supporting.  This is
> optional, and capabilities say you should be ignoring things you don't
> understand anyway.  Why force the implementation to hang up the session?”*
>
>
>
> Do you need BGP profile to achieve continuing the BGP session when
> receiving the unrecognized “optional capability” in BGP Open message?
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Monday, January 16, 2023 6:14 PM
> *To:* Kausik Majumdar <[e-mail]>
> *Cc:* Linda Dunbar <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> *Subject:* Re: [EXTERNAL] Re: [Idr]
> draft-ietf-rtgwg-net2cloud-problem-statement description on BGP error
> valid? (was RE: WG adoption call for
> draft-abraitis-bgp-version-capability-08, to end September 25
>
>
>
>
>
> > Can we use our current Draft to update and describe the best practices
> for the mitigation?
>
>
>
> I don't think that the Informational draft in RTGWG can be used to make
> any modifications to any BGP Message Error Handling.
>
>
>
> > As the scope of the document is to characterize the network-related
> problems that Enterprises
>
> > face today when interconnecting their branch offices with dynamic
> workloads in the Cloud DCs
>
> > and the mitigation practices, it might be useful to recommend /capture
> mitigation practices for the
>
> > Section 3.1 BGP Errors Handling.
>
>
>
> The problem is that we do not have a separate BGP "version/profile" for
> interconnecting branch offices with Cloud DCs.
>
>
>
> That means that we can not customize core BGP protocol operation to be
> optimal to such deployment space.
>
>
>
> - - -
>
>
>
> I think that if we would go and define the notion of "BGP Profiles" -
> lot's of useful customization could be made with
>
> lowering the bar for each.
>
>
>
> I could think of few obvious such profiles already:
>
>
>
> * Internet BGP IPv4/IPv6 Profile
>
> * Intradomain Routing Profile
>
> * Data Center BGP Profile
>
> * Private Overlay Transport BGP Profile
>
>
>
> Now the obvious challenge is to maximize the code reuse while at the same
> time achieve profile isolation/separation.
>
>
>
> Regards,
> Robert
>
>
>
>
>
> On Tue, Jan 17, 2023 at 12:25 AM Kausik Majumdar <[e-mail]>
> wrote:
>
> Hi Robert, Sue, IDR Chairs, et. all,
>
>
>
> Can we use our current Draft to update and describe the best practices for
> the mitigation? As the scope of the document is to characterize the
> network-related problems that Enterprises face today when interconnecting
> their branch offices with dynamic workloads in the Cloud DCs and the
> mitigation practices, it might be useful to recommend /capture mitigation
> practices for the Section 3.1 BGP Errors Handling.
>
>
>
> *3.1 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-rtgwg-net2cloud-problem-statement-18%23section-3.1&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C938968be009a4538691708daf81fc400%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638095112586296054%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JUI%2B2dMjbQKtkZhfXZyYSSmgYVfDuVS5uo7OydiIt8k%3D&reserved=0>. Increased BGP errors and Mitigation Methods*
>
>
> -----------------------------------------------------------------------------------------------------
>
> Abstract
>
>
>
>    This document describes the network-related problems enterprises
>
>    face today when interconnecting their branch offices with dynamic
>
>    workloads in third-party data centers (a.k.a. Cloud DCs) and some
>
>    mitigation practices.
>
>
> ­-----------------------------------------------------------------------------------------------------
>
>
>
>
>
> Regards,
>
> Kausik
>
>
>
>
>
> *From:* Idr <[e-mail]> *On Behalf Of *Robert Raszuk
> *Sent:* Monday, January 16, 2023 2:03 PM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Subject:* [EXTERNAL] Re: [Idr]
> draft-ietf-rtgwg-net2cloud-problem-statement description on BGP error
> valid? (was RE: WG adoption call for
> draft-abraitis-bgp-version-capability-08, to end September 25
>
>
>
>
>
> Any IDR WG member ... :)
>
>
>
> On Mon, Jan 16, 2023 at 10:59 PM Linda Dunbar <[e-mail]>
> wrote:
>
> Robert,
>
> Who are the “folks” responsible for making the change?
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Monday, January 16, 2023 2:32 PM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* Jeffrey Haas <[e-mail]>; Gyan Mishra <[e-mail]>;
> [e-mail]; [e-mail]
> *Subject:* Re: draft-ietf-rtgwg-net2cloud-problem-statement description
> on BGP error valid? (was RE: [Idr] WG adoption call for
> draft-abraitis-bgp-version-capability-08, to end September 25
>
>
>
> Hi Linda,
>
>
>
> I see where you are going with this .. I was expecting so - thank you
> for confirming.
>
>
>
> So RFC7606 talks about BGP UPDATE Message error handling.
>
>
>
> To the best of my knowledge we do not have revised Error Handling for BGP
> OPEN Message. So I would propose you encourage folks to work on it
> before you proceed with the below section 3.1.
>
>
>
> Many thx,
>
> Robert
>
>
>
>
>
> On Mon, Jan 16, 2023 at 9:22 PM Linda Dunbar <[e-mail]>
> wrote:
>
> Robert, Jeffrey, Gyan,
>
>
>
> The reason for my question is to validate the description of the Section
> 3.1 (Increased BGP error) in the
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-net2cloud-problem-statement%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C938968be009a4538691708daf81fc400%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638095112586296054%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cAnaj7s3crPbUCREIDjjd23Zb0cAGmDxF5Sm0Te4Y%2Fw%3D&reserved=0>
>
>
>
> Love to hear your comments to this description
>
> --------------------------------------------------
>
> 3.1. Increased BGP errors and Mitigation Methods
>
> Many network service providers have limited number of BGP peers and
> usually have prior negotiated peering policies with their BGP peers. Cloud
> GWs need to peer with many more parties, via private circuits or IPsec over
> public internet. Many of those peering parties may not be traditional
> network service providers. Their BGP configurations practices might not be
> consistent, and some are done by less experienced personnel. All those can
> contribute to increased BGP peering errors, such as capability mismatch,
> BGP ceasing notification, unwanted route leaks, missing Keepalives, etc.
> Capability mismatch can cause BGP sessions not established properly.
>
> If a BGP speaker receives a BGP OPEN message with the unrecognized
> Optional Parameters, an error message should be generated per RFC 4271,
> although the BGP session can be established. When receiving a BGP UPDATE
> with a malformed attribute, the revised BGP error handling procedure
> [RFC7606] should be followed instead of session resetting.
>
> Many Cloud DCs don’t support multi hop eBGP peering with external devices.
> To get around this limitation, it is necessary for enterprises GWs to
> establish IP tunnels to the Cloud GWs to form IP adjacency.
>
> Some Cloud DC eBGP peering only supports limited number of routes from
> external entities. To get around this limitation, on-premises DCs need to
> set up default routes to be exchanged with the Cloud DC eBGP peers.
>
> -----------
>
>
>
> Thank you very much
>
> Linda Dunbar
>
>
>
> -----Original Message-----
> From: Jeffrey Haas <[e-mail]>
> Sent: Monday, January 16, 2023 1:45 PM
> To: Robert Raszuk <[e-mail]>
> Cc: Linda Dunbar <[e-mail]>; Gyan Mishra <
> [e-mail]>; [e-mail]
> Subject: Re: [Idr] WG adoption call for
> draft-abraitis-bgp-version-capability-08, to end September 25
>
>
>
> Robert,
>
>
>
> On Mon, Jan 16, 2023 at 08:28:27PM +0100, Robert Raszuk wrote:
>
> > I am afraid you are talking about BGP version while Linda is asking
>
> > about the subject draft bgp version ... Both are completely unrelated
> "versions".
>
>
>
> I'm answering Linda's literal question.  In the cited text, she is not
> asking about the new version capability.  If her intent was to ask about
> that, her text wasn't stating what she wanted to ask.
>
>
>
> > While we are here I did reread RFC4271 and I am not sure either if
>
> > there is text to mandate closing the session when new BGP OPEN
>
> > Optional Parameter is not recognized. Neither does FSM. Generating
>
> > NOTIFICATION and continue should be allowed by the spec unless I
>
> > missed some embedded mandate to close it.
>
>
>
> RFC 4271, §6.2:
>
>
>
> :    If one of the Optional Parameters in the OPEN message is not
>
> :    recognized, then the Error Subcode MUST be set to Unsupported
>
> :    Optional Parameters.
>
> :
>
> :    If one of the Optional Parameters in the OPEN message is recognized,
>
> :    but is malformed, then the Error Subcode MUST be set to 0
>
> :    (Unspecific).
>
>
>
> -- Jeff
>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C938968be009a4538691708daf81fc400%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638095112586296054%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RrjOaqOVuegtCj5bkyFKAUrmBfyl2YxQEv3sKn9RcTU%3D&reserved=0>
>
>