[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

[Linda Dunbar <[e-mail]>]

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/

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