Hello Jeff, thanks for the feedback. This, for some reason, got stuck behind the inbox, addressing now.
> 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 already said "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." I now added: ", or other use-cases when using BGP without globally unique identifiers between networks" at the end. This should clarify that those cases are excluded from the scope of the document to the point of "the document says that you can do this in your own network, but must make sure that it does not leak to the public part." Does that work for you? > 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. That was indeed the consideration here, i.e., making this text a bit more independent from actual implementation, as that may change (faster than we may anticipate). > 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 the following text to prefix limits: "Please note, though, that limiting the number of permissible prefixes a neighbor may send may also introduce stability issues, if that number is set too low for the corresponding neighbor." > 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...) I removed that example. > 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. The text already reads: "In selected cases, if a specific attribute is known to be malicious, an operator <bcp14>MAY</bcp14> either temporarily remove that specific attribute from NLRI when importing them or filter NLRI carrying the attribute.", do you think that this suffices? > 2. Gratuitously filtering attributes can harm incremental deployment > of new features and should be avoided by transit providers. Also re-arranged the text there a bit. I think this works out now without explicitly mentioning the transit-provider aspect. > 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? I added the following text to importing default routes: "Operaters are cautioned to evaluate carefully how accepting a default route affects their network, as this occludes limitations in forwarding coverage by the upstream from which the default route was received." With best regards, Tobias -- My working day may not be your working day. Please do not feel obliged to reply to my email outside of your normal working hours. ----------------------------------------------------------------- Tobias Fiebig, Forschungsgruppe Internet Architecture (INET) Max-Planck-Institut für Informatik, Campus E14, 66123 Saarbrücken E1 4 - Raum 517 mobil: +31 616 80 98 99 _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
