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

> 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 <kmajumdar@microsoft.com>
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://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-net2cloud-problem-statement-18#section-3.1>. 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 <idr-bounces@ietf.org> *On Behalf Of * Robert Raszuk
> *Sent:* Monday, January 16, 2023 2:03 PM
> *To:* Linda Dunbar <linda.dunbar@futurewei.com>
> *Cc:* idr@ietf.org; rtgwg@ietf.org
> *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 <linda.dunbar@futurewei.com>
> wrote:
>
> Robert,
>
> Who are the “folks” responsible for making the change?
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* Monday, January 16, 2023 2:32 PM
> *To:* Linda Dunbar <linda.dunbar@futurewei.com>
> *Cc:* Jeffrey Haas <jhaas@pfrc.org>; Gyan Mishra <hayabusagsm@gmail.com>;
> idr@ietf.org; rtgwg@ietf.org
> *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 <linda.dunbar@futurewei.com>
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-net2cloud-problem-statement%2F&data=05%7C01%7Ckmajumdar%40microsoft.com%7C73aed04a767d45111eef08daf80d6f61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638095033847536253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wyUeXwdJn0QxqbLumCoRvOkDqgSKM1URvOmfE8h1H%2Bs%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 <jhaas@pfrc.org>
> Sent: Monday, January 16, 2023 1:45 PM
> To: Robert Raszuk <robert@raszuk.net>
> Cc: Linda Dunbar <linda.dunbar@futurewei.com>; Gyan Mishra <
> hayabusagsm@gmail.com>; idr@ietf.org
> 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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=05%7C01%7Ckmajumdar%40microsoft.com%7C73aed04a767d45111eef08daf80d6f61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638095033847536253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OSAuEnteo1Bs5Q2GLeCw6EPmU%2BPOVcJKMN46fGOyd%2Fo%3D&reserved=0>
>
>