> On Dec 20, 2023, at 17:03, Luke Thompson <[email protected]> wrote: > > The logic on both sides seems valid to me. I think ultimately it's about > supporting the demise of v4 (in that, the rise of efficient smaller > operators). >
I’ll slightly disagree here… The demise of v4 is best resolved by v6, not by ever stranger contortions to try and make things fit in the very limited v4 address space. > There is what seems a valid case to shift this to /26 minimum, and also > bedded-down tradition where the existing baseline is unlikely to > significantly change - especially for what should be a primarily yesteryear > technology. I think there may be a silently resistant subset of operators who > don't want to get into the nitty gritty of smaller assignments at scale, not > that it is necessarily good form. > The level of pain once we run out of v4 for IXPs is zero to push the peering sessions for new exchange points to be v4/v6 NRLI via IPv6 peering. It’s super easy to configure, presents no significant hurdles or additional training requirements vs. dual-stack peering in separate sessions. As such, I see absolutely no reason to change the v4 prefix size for IXPs or worry about running out of them. > From my understanding of the BGP arena, which is lacking, administratively > and in terms of routing table size /24 is already quite small. However at the > same time, small operators shouldn't have to take up "large" (to their scale) > prefixes to establish basic requirements. It does seem unreasonable that you > can't get down into /26 per-site, especially as density increase could > potentially be up to 3x more yield from a /24? > In general, IXP prefixes shouldn’t be carried in the routing table anyway, so this is a questionable issue. > With a view forwards, and v4 becoming more of an > enabling-what-doesn't-do-v6-well technology as it slowly slowly (slowly) > sunsets, I think this proposal will make even more sense. To that end, making > the change sooner than later seems prudent in preserving resources, > especially as this proposal has provision for up to /22 conditionally. > > To Owen's point it is also "just another change" towards prolonging the end > of v4 and one many are tired of. I think the pathway out of v4 has proven to > be remarkably slow and resistant, that it makes sense to aid the sunset > rather than push against it. > Yes, so let’s aid it in part by just letting the prefixes run out instead of aiding the prolonging of it even further. > At the same time, should this gain consensus then where does the line get > drawn? > Excellent question, which is why I hope this does not gain consensus. Owen >>>> Again, members define policy (be it a routing policy or otherwise). If a >>>> community member presents a policy about the routability of prefixes >>>> longer than a /24 at an open policy meeting and it reaches consensus with >>>> the wider community, why should we not accept it? RIRs do so much more >>>> than just administering addresses and if that's all they did, I believe >>>> the internet would not be the way that it is today. Well, there’s a good deal of debate about that, but the simple reality is that people who run routers define the longest prefix they are willing to accept. Sure, the community can apply pressures on that (possibly through RIR policy, though I question that), but at the end of the day, an RIR policy insisting that people carry longer prefixes in their routing tables probably carries about as much weight as a prepend in an as-path. It’s a suggestion at best and often ignored. The RIR can set policy for how it administers the registration database. It cannot set policy for much more than that and have its policies remain meaningful. Certainly the RIR’s ability to enforce policy is limited to how it runs the registry and possibly other aspects of how the RIR is run. Attempting to enforce policy on how people manage their routing tables or other aspects of their business is unlikely to meet with much success, at least in most of the world. >>> Well, at least in the ARIN region, there is a concept of scope of the PDP >>> and policy proposals which are out of scope are rejected out of hand. >> Unfortunately I do not know enough about ARIN's PDP so I'm probably not the >> best person to comment on this specifically. Having spent nearly 15 years on the ARIN advisory council, I am quite well versed in the ARIN PDP. As such, I am happy to answer any questions you may have about it. You can also easily contact any current advisory council member or reach out to any of ARIN’s policy analyst or John Sweeting or John Curran, all of whom are quite accessible. Owen
_______________________________________________ SIG-policy - https://mailman.apnic.net/[email protected]/ To unsubscribe send an email to [email protected]
