Hello Jeff, thanks for the review. > 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 scope states: """ The guidelines defined in this document are intended for BGP when used to exchange generic Internet routing information within the Default- Free Zone (DFZ). It specifically does not cover other uses of BGP, e.g., when using BGP for NLRI exchange in a data-center context. """ Do you think that covers your concern there? > 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. I would also go with "perhaps not", again given the scope of the document; How these can be implemented (IRR, ASPA) will change over time, and are operational environment specific. > 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. I added: When implementing prefix limits, operators <bcp14>SHOULD</bcp14> be aware of the operational implications of exceeding prefix limits, i.e., a loss of an established session. Hence, operators <bcp14>SHOULD</bcp14> appropriately weigh this impact within the specific operational circumstances, and ensure appropriate prefix limits to not cause outages under normal operations. > 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. Thanks; I rephrased se section as follows: """ 4.3 Altering Attributes in Received BGP Updates When processing received BGP updates, an operator <bcp14>SHOULD</bcp14> ensure that attributes which are considered immutable are not altered: - An operator <bcp14>SHOULD NOT</bcp14> change or remove immutable transitive BGP attributes, e.g., ORIGIN as per <xref target="RFC4271" format="default"/>. Furthermore, incremental deployment of new features and technologies relies on the unaltered redistribution of unknown attributes by implementations not yet supporting this feature. Hence, as gratuitously filtering such attributes would harm incremental deployment, filtering unknown attributes <bcp14>SHOULD</bcp14> be avoided by transit providers. - Please note that occasionally unknown or malformed attributes may cause operational problems, e.g., due to implementation bugs. Hence, in selected cases, if a specific attribute is known to be malicious or disruptive, an operator <bcp14>MAY</bcp14> either temporarily remove that specific attribute from received BGP updates when importing them or filter the BGP update carrying the attribute. - BGP updates <bcp14>MUST NOT</bcp14> be enriched with transitive attributes subject to change independent of the underlying NLRI, e.g., encoding RPKI validation state in transitive attributes <xref target="I-D.ietf-sidrops-avoid-rpki-state-in-bgp" format="default"/>. """ > 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? Not a bad idea, imho. I added the following text to the corresponding section; For importing: """ Operators <bcp14>SHOULD</bcp14> be aware that ingesting a default route can have opaque negative operational impact, if the announcing upstream is not able to cover the more specific forwarding in the appropriate service provider context. These limitations do not materialize when receiving a full BGP view. """ And for exporting: """ Operators <bcp14>SHOULD</bcp14> be aware that originating a default route without being able to cover the more specific forwarding in the appropriate service provider context can have opaque negative operational impact for a downstream, while sharing a full BGP view with a downstream does not carry this risk. """ With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M [email protected] Pronouns: he/him/his _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
