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]
