Hi Linda, A few more comments.
You added the following: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Please use the correct template as per RFC 8174 under a separate “Requirements Language” section. 196 - When a Cloud DC eBGP session supports a limited number of 197 routes from external entities, the on-premises DCs need to set 198 up default routes and filter as many routes as practical 199 replacing them with a default in the eBGP advertisement to 200 minimize the number of routes to be exchanged with the Cloud DC 201 eBGP peers. Jim> I do not understand the above paragraph. Is a Cloud DC different to an on-premise DC? Who is advertising default to who? The scenario that you are trying to convey above is non-obvious, at least to me, so please clarify. [Linda] The statement is meant to emphasize when a cloud DC GW doesn’t multi-hop eBGP sessions with their peers, a tunnel should be established to achieve IP adjacency. For example, AWS Transit Gateway does not support traditional multi-hop eBGP sessions. AWS recommends establishing eBGP sessions with third-party virtual appliances (like SD-WAN appliances) running in a VPC to exchange routing information between on-premises network and multiple VPCs through a central point. Jim> Okay but in the latest version of the document you do not clarify it or change any text. Reading the above paragraph I still cannot fathom from the text what you are trying to convey. Your explanation is not reflected in the text so again please try to clarify what you want the reader to understand. 202 - When a Cloud GW receives inbound routes exceeding the maximum 203 routes threshold for a peer, the currently common practice is 204 generating out-of-band alerts (e.g., Syslog entries) via the 205 management system or terminating the BGP session (with cease 206 notification messages [RFC4486] being sent). Although out of 207 the scope of this document, more discussion is needed in the 208 IETF Inter-Domain Routing (IDR) Working Group for potential in- 209 band or autonomous notification directly to the peers when the 210 inbound routes exceed the maximum routes threshold. Jim> More explanation is needed here including a reference to section 4 of RFC4486 that describes the procedure for terminating a peering with a NOTIFICATION message and error code providing a reason e.g. “Maximum number of prefixes reached”. [Linda] Azure doesn’t want BGP session to be terminated when max number of prefixes reached. Azure wants a method to notify the peers when the routes received exceeding some threshold. Today’s practice of using Syslog only informs Azure when max routes exceeded. But there is no effective way to notify peers to reduce routes. draft-sas-idr-maxprefix-inbound-05 would be a good solution. But the draft is expired. We are hoping to continue the draft by stating that “more discussion is needed in the IETF Inter-Domain Routing (IDR) Working Group for potential in-band or autonomous notification directly to the peers when the inbound routes exceed the maximum routes threshold.” Jim> Again, my original comment is not addressed in the latest version. At a minimum, a reference to section 4 of RFC4486 is needed. Thanks! Jim
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
