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 <[email protected]>
Sent: Monday, January 16, 2023 6:14 PM
To: Kausik Majumdar <[email protected]>
Cc: Linda Dunbar <[email protected]>; [email protected];
[email protected]; [email protected]
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
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> On Behalf Of
Robert Raszuk
Sent: Monday, January 16, 2023 2:03 PM
To: Linda Dunbar <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
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
<[email protected]<mailto:[email protected]>> wrote:
Robert,
Who are the "folks" responsible for making the change?
Linda
From: Robert Raszuk <[email protected]<mailto:[email protected]>>
Sent: Monday, January 16, 2023 2:32 PM
To: Linda Dunbar <[email protected]<mailto:[email protected]>>
Cc: Jeffrey Haas <[email protected]<mailto:[email protected]>>; Gyan Mishra
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
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
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>>
Sent: Monday, January 16, 2023 1:45 PM
To: Robert Raszuk <[email protected]<mailto:[email protected]>>
Cc: Linda Dunbar
<[email protected]<mailto:[email protected]>>; Gyan Mishra
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
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>
--- Begin Message ---
On Sun, Jan 15, 2023 at 07:28:33PM +0000, Jakob Heitz (jheitz) wrote:
> I can agree to using a new BGP OPEN Optional Parameter.
>
> I would add that if after receiving the OPEN message, the BGP neighbor closes
> the session
> with “Unsupported Optional Parameters”, that the sender of that OPEN message
> try
> opening the session again without the version parameter.
>
> Graceful restart is affected. When a restarted session is restarted a second
> time,
> stale markings are removed. To prevent that, when a neighbor has previously
> restarted a session
> due to not supporting the new version parameter, a session that is restarted
> due to GR should not
> include the version parameter.
Whereas for exactly these reasons, I wouldn't want it in the optional
parameter.
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?
-- Jeff
_______________________________________________
Idr mailing list
[email protected]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C525b05620f8d4eeb4b9108daf7f75e14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638094939070062949%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5vzNoGSMtnUYuDNeLkA63CplQ2fzEp%2BG80rwciAvyUU%3D&reserved=0
--- End Message ---
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
