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://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%7C6fc32b560e9342a27bd508daf800bdf7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638094979345574739%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RnQ95WO35tXFp0ZzFkw7J%2B71q8hogfLSoRf1Wft%2FhMY%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
>