Authora and WG, Section 4.1 - importing NLRI:
The restrictions vs. private AS numbers make good sense if this document is solely operational considerations for Internet purposes and non-customers. Private ASes are used for internal use along with related (and under-specified [filing a Issue in 4271-bis now...]) remove-private. Should this document exclude such cases? The AS relationship check is best practice. However, it's not actionable in the current text. Should something actionable be recommended? The answer may be perhaps not, because that's subject to a number of documents. A similar consideration applies on export in 4.2. Somewhat of a sore point due to escalations, the nod toward prefix-limits could be made a bit more clear. It's covered in the RFC 4271 text. However, dropping a session due to exceeding a prefix limit causes outages. This perhaps deserves a few comments. Section 4.3 is less about altering "NLRI" and more commentary on BGP path attributes. For example, the origin attribute has at most a SHOULD NOT alter. We know for certain that providers do so. (And yes, there's a draft out there that says 'let's get rid of this thing...) This section is also possibly good to discuss attribute and related route filtering. John and I try to talk about the landscape and the operational headaches in a solution draft in IDR[2]. Also, I discuss the general problem of when we have path attributes that have gotten outside of their expected use case as escaped attributes.[3] In the context of the opsec draft, what we probably want to discuss is two of the overlapping points from these: 1. Unwanted attributes may cause operational problems. This may be addressed by filtering routes containing these attributes, or sometimes filtering the attribute itself. 2. Gratuitously filtering attributes can harm incremental deployment of new features and should be avoided by transit providers. --- A general comment on default routes: Originating default when you're unable to cover the more specific forwarding in the appropriate service provider context can be a problem. When default isn't used, coverage is generally visible to the receiving provider. Should we offer a cautionary word here as an operational consideration? -- Jeff [1] https://github.com/ietf-wg-idr/RFC4271bis/issues/69 [2] https://datatracker.ietf.org/doc/draft-haas-idr-path-attribute-filtering/ [3] https://datatracker.ietf.org/doc/draft-haas-idr-bgp-attribute-escape/ _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
