I'd consider mentioning again that some of the NRLI components won't work
properly on fragmented traffic and that unexpected fragmentation can cause
DoS. (This is particularly relevant for IPv4, as opposed to IPv6, where
fragmentation can occur anywhere on the path.)
Is it worth saying anything about how the RT-redirect actions can direct
traffic to an entity not expecting it (and, as such, potentially DoS them)?
It also struck me as noteworthy that we're letting DSCP values creep out of
a single administrative scope -- the filtering of inbound DSCP markings
should probably be consistent with the traffic markings advertised to that
peer. (There is perhaps also some "information leakage" as to what
semantics are assigned to given DSCP values within the network in question,
but I find it hard to get too worked up about that, especially since the
inter-AS relationship is inherently pretty trusted.)
Section 12
I'd consider mentioning again that some of the NRLI components won't work properly on fragmented traffic and that unexpected fragmentation can cause DoS. (This is particularly relevant for IPv4, as opposed to IPv6, where fragmentation can occur anywhere on the path.)
Is it worth saying anything about how the RT-redirect actions can direct traffic to an entity not expecting it (and, as such, potentially DoS them)?
It also struck me as noteworthy that we're letting DSCP values creep out of a single administrative scope -- the filtering of inbound DSCP markings should probably be consistent with the traffic markings advertised to that peer. (There is perhaps also some "information leakage" as to what semantics are assigned to given DSCP values within the network in question, but I find it hard to get too worked up about that, especially since the inter-AS relationship is inherently pretty trusted.)