On Tue, 7 Jan 2025 at 17:39, Gert Doering <g...@space.net> wrote: > On Tue, Jan 07, 2025 at 03:55:00PM +0000, Nick Hilliard wrote: > > I'd prefer the section to be dropped completely, and to leave it to > > individual IXPs to make their own minds up about what their routing > policy > > should be for their address space. > > I think the section "do not (never ever) accept more specifics for any > IXP lan you're connected to" is a good one, and should be kept. > > We've seen accidents where peers did... whatever, and announced > more-specifics out of the DECIX FRA peering LAN, leading to interesting > outages at those ISPs who accepted the prefix. Needless waste of time > to debug that.
The existence of a Peering LAN prefix more-specific is one the worst things that can happen to an IX community. So far the only scalable mitigation mechanism seems to be for IX operators to issue ROAs and IX participants to apply ROV filtering. Leveraging the RPKI for this particular case is helpful because it leaves the IX operator in full control whether the peering LAN prefix should be globally visible or not (e.g. the IX operator can set the ROA’s origin AS to 0, or originate the prefix in BGP from a designated ASN). The NIST recommendation seems to somewhat tip-toe around how to actually get things properly done. Kind regards, Job >
_______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
