Hello,
On 28/06/2024 09:28, Geoff Huston wrote:
Rather than attempt to spoon-feed a reader with a long list of detailed
tasks that is most likely incomplete and will be quickly overtaken by
subsequent changes in the operational environment, it's more useful to
elevate the level of the document and describe what these operational
security measures are trying to achieve and just leave it at that. This
seems like a far more useful approach to me.
I think it could be useful to publish the detailed version somewhere.
The new version is very generic, which makes it hard for operators to
check if they've covered all the specifics. In level of detail I see
similarities with ripe-823 (DNS Resolver Recommendations), so perhaps
the RIPE routing-wg would be a good forum for this.
As a replacement of RFC7454, I agree the new approach is a good way forward.
Some comments on the 02 draft:
3.1
Add: "Ensure that unstable sessions do not threaten the availability of
BGP speakers within the network."
"Ensure that the volume of ingested messages does not threaten the
availability of BGP speakers within the network." - I think this is
point would be better placed under section 4.1 (see below)
4.1
Add: "The number of NLRI received from a neighbor MUST NOT exceed the
resources of the local router."
4.2
Add: "When redistributing NLRI from downstream networks, the local AS
MUST be authorized to be an upstream for the routes."
In general, it may improve readability to have a separate sections for
originating NLRI and re-distributing received NLRI (upstream/downstream).
4.3
"filter that specific attribute." -> "filter that specific attribute or
the NRLI".
Kind regards,
Martin
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
