Job, On Sun, Jan 29, 2023 at 02:41:30PM +0100, Job Snijders wrote: > On Sun, Jan 29, 2023 at 08:28:27AM -0500, Jeffrey Haas wrote: > > On Sun, Jan 29, 2023 at 11:26:02AM +0100, Job Snijders wrote: > > > On Wed, Jan 25, 2023 at 05:17:08PM +0000, Sriram, Kotikalapudi (Fed) > > > wrote: > > > > Please let us also know if you would have interest in providing an > > > > implementation. > > > > > > Perhaps it is worthwhile adding a suggestion to the document for BGP > > > stack vendors to make it super easy to reject BGP routes that contain an > > > AS_SET anywhere in the AS_PATH? > > > > That's intended to be covered by the first paragraph of section 3: > > : BGP speakers conforming to this document (i.e., conformant BGP speakers) > > : SHOULD NOT locally generate BGP UPDATE messages containing AS_SETs or > > : AS_CONFED_SETs. Conformant BGP speakers SHOULD NOT send BGP UPDATE > > messages > > : containing AS_SETs or AS_CONFED_SETs. Upon receipt of such messages, > > : conformant BGP speakers SHOULD use the "treat-as-withdraw" error handling > > : behavior as per [RFC7606]. > > Thanks for highlighting that section, that's the gist of it in terms of > desired outcome, (and why I'd be in favor of progressing this document).
Excellent. It's the hope of the authors that this document is largely done and may progress to WGLC soon. > > I know you want to say "add a knob", but we generally try to avoid talking > > about the knobs in IDR specs. > > Understandably. I can see how the suggestion is somewhat superfluous. That said, progression in IDR is also about two interoperable implementations. It sounds like you have a portion of the document implemented. Please review the document further and perhaps see if you have interest in getting the rest of the feature set complete. In particular, I'm interested in hearing implementation analysis for the new brief aggregation procedures. Those are necessary to address a deficiency in generating aggregate routes that are RPKI Origin stable. -- Jeff _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
