Moin,
> 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.
So far the plan was to move the 'old' parts to two new drafts; I will
submit stubs for that shortly.
> 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)
Added the 'Add:'; For the second part, I moved the established-session-
related parts to 4.1, and added a point to protect BGP speakers from
remote packet/message floods (without a session), i.e., DoS.
> 4.1
>
> Add: "The number of NLRI received from a neighbor MUST NOT exceed the
> resources of the local router."
Added.
> 4.2
>
> Add: "When redistributing NLRI from downstream networks, the local AS
> MUST be authorized to be an upstream for the routes."
I tried to express this with the valley free principle; However, I
reshaped the formulation to be more explicit here (see below).
> In general, it may improve readability to have a separate sections
> for originating NLRI and re-distributing received NLRI
> (upstream/downstream).
That would be two sections with one point each, and additional overlap.
I.e., an AS must ensure that the originator is authorized to originate
a redistributed route, while also ensuring to not originate routes the
AS is not authorized to originate.
By keeping it in one section, i.e., 'ensure what you export conforms'
the text also prevents a diffusion in responsibility ("We check what we
originate, but what others originated is their responsibility.")
Can you take a look if the new text addresses your concerns?
###
4.2. Originating and Redistributing NLRI
When originating NLRI or redistributing NLRI received from a
neighbor, an operator MUST ensure that all NLRI they export conform
to the following properties by implementing technical or
organizational measures:
* The AS_PATH of redistributed NLRI MUST NOT violate the valley-
free principle [RFC4012], i.e., the redistributing AS MUST be
authorized to redistribute NLRI for the specific prefix when
received from the AS directly to its right in the AS_PATH.
Additionally, each AS in the AS_PATH not originating the prefix
MUST be authorized to redistribute the prefix when receiving it
from the next AS to its right.
* The AS originating NLRI for a prefix MUST be globally authorized
to originate that prefix. Operators MAY deviate from this for
default routes (::/0 and 0.0.0.0/0), if they originate the
default route and the specific neighbor granted them permission
to announce default routes towards them.
* The AS_PATH MUST NOT contain AS numbers reserved for private
[RFC6996] or special-use cases excluding their presence in the
global routing table.
###
> 4.3
>
> "filter that specific attribute." -> "filter that specific attribute
> or the NRLI".
Added.
Thanks!
With best regards,
Tobias
--
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M [email protected]
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
