Hi Tobias,
Thanks for the quick response, those clarifications/changes make sense
to me.
Cheers,
luuk
On Wed 8 Apr 2026, 17:44, Tobias Fiebig wrote:
> Hello Luuk,
>
> > Some nits, notes and questions after going through the -15. This is
> > an interpretation of someone with barely any operational experience,
> > reading the text in isolation (thus, not comparing it to RFC7454 /
> > BCP194).
> >
> > I do think this document is useful, regardless of how much the reader
> > is involved in operations, or for how long. It seems to be a good
> > basis, touching upon all the points at an understandable level
> > without the reader drowning in details. So, I support moving this
> > document forward.
>
> Thanks, really appreciated!
>
> > sec 3.1
> > "exceeding prefix limits, i.e., a loss of an established session"
> > s/a loss/loss/ ?
>
> ack.
>
> > sec 4.
> > "Importing or exporting incorrect or malicious routes is a security
> > risk for receiving networks"
> >
> > What is a "receiving network" here, one receiving route information
> > via BGP? Or receiving traffic based on exchanged ("incorrect or
> > malicious") routing information?
>
> Reworded to "networks that receive these routes".
>
> > 4.1
> > "Operators 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."
> >
> > This is hard to parse for me. Reading 'occludes' as 'to block off
> > something', followed by 'limitations' makes me think this is some
> > kind of double negative, but I'm really not sure what this is
> > supposed to tell me.
>
> Reworded:
>
> Operators are cautioned to evaluate how accepting a default route
> affects their network. A defaultroute may hide that an upstream is
> unable to forward traffic to a destination, i.e., if there is no route
> known to that destination by the upstream.
>
> > 4.1
> > bullet point 2, "For received BGP routes with AS_PATH = AS1, AS2,
> > ..."
> >
> > I interpret this as 'you should do ASPA' without the text explicitly
> > mentioning ASPA. If that is indeed the message, I suppose this bullet
> > point is there to future-proof this document while we see ASPA
> > adoption steadily grow?
> > Because at this very point in time I feel this is quite a tricky
> > requirement to fulfil in reality, unless I'm missing something.
> >
> > Not saying this bullet point should go, as the other requirements in
> > that list seem to be trivial to tick off, this one stood out.
>
> Technically, even if tricky, one could also try to do this without
> ASPA. But yes, that is exactly the intent behind this point.
>
>
> Thanks for the review!
>
> With best regards,
> Tobias
>
> --
> Univ.Prof. 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]
