...
In this
configuration participants may route these prefixes inside their
networks (e. g. using BGP no-export communities or routing the IXP
LANs within the participants' IGP) to perform fault management.
...
I recommend for AS to use next-hop-self on iBGP sessions, by doing
that there will be no need to redistribute IXP prefix into their IGP.
The routing of the IXPs LANs inside the participants has to do with the use of uRPF and being able to perform traceroutes. Using next-hop-self to your iBGP sessions does not solve this problem.
6. Route Server
...
The use of MD5 [RFC2385] or IPSEC [RFC4301] to
authenticate the BGP sessions and the use of GTSM (The Generalized
TTL Security Mechanism) [RFC3682] should be considered.
...
For sure that these mechanisms are important to help securing the BGP
session, but as they are related to the BGP session itself and not to
IPv6 address families they do not seem to fit well on this document.
I disagree, this items were requested several times in the list and remember this is an Informational RFC.
...
Route Server
Router-Server
...
These terms may be confusing for the reader to identify from the ones
used for MLPA and for others tasks.
I recommend to highlight the idea that MLPA route servers should not
have external (Internet) access to them for security matters.
done.
+++++++++++++++++++++++++++++++++++++
8. IXP Policies and IPv6
I strongly recommend to include IPv6 prefixes number
control/limitation (maximum-prefix) between neighbours.
I understand that this feature may be useful for some IPv4 BGP
sessions, but it is mandatory for IPv6 sessions, because of the huge
amount of prefixes that may be advertised per netblock (e.g. /32 le
/64).
I added this info in the Route-Server section. Why this should be an IXP policy issue?
Thanks,