<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><br></div>Hi John,<div><br></div><div><br id="lineBreakAtBeginningOfMessage"><div><blockquote type="cite"><div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><div><div>Perfectly sensible – and similar to what space agencies would are likely do if they were to receive their own allocation: allocating one prefix per body internally to allow per-body aggregation, and issuing space to projects based on the most expected celestial body of operation. </div></div></div></div></div></div></div></blockquote><div><br></div><div><br></div><div>Unfortunately, that’s not what’s happening. I’m told that agencies are picking random IPv4 prefixes from their normal assignments, without any thought to aggregation, either internally or cross-agency. We need this draft and corresponding RIR policies to take back to them and help them with aggregation.</div><div><br></div><br><blockquote type="cite"><div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">But of course that also means that if providers instead received their own aggregate blocks for all all activities – regardless of celestial location – then under normal circumstances each provider would advertise a single covering aggregate across the deep space Internet. Aggregation would follow provider infrastructure, similar to terrestrial ISP models.</div></div></blockquote><div><br></div><div><br></div><div>That works if and only if the topology is agency exclusive.</div><div><br></div><div>If, on the other hand, the agencies share infrastructure, as is now being proposed, it means that routing will need to carry per-mission prefixes throughout the infrastructure, as the topology no longer aligns with addressing.</div><div><br></div><br><blockquote type="cite"><div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">It does seem like the actual operational aggegation and net routing load would be quite sensitive to number of celestial-body interconnects that end up in routine operation – and that celestial-body-based allocation would in normal circumstances require each provider to carry N routes (N being number of celestial body-assigned allocations it received) on its own network both internally and to shared with others to maintain full connectivity. </div></div></blockquote><div><br></div><div><br></div><div>That is correct. Aggregation is sensitive to topology. If the topology is provider-exclusive, then you would want to aggregate that way. However, if the topology is provider-shared, then you would want to aggregate geographically.</div><div><br></div><div><br></div><blockquote type="cite"><div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><div>The challenge with that is that we end up doing effectively random allocation and completely lose out on the ability to aggregate. The primary purpose of all addressing is to make routing efficient, and it seems like we would be well served to take this opportunity to not repeat previous inefficiencies.</div></div></div></div></blockquote><br></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div>You suggest that a model where each space agency gets its own aggregate block for all its missions is effectively random allocation?? Could you elaborate on that? </div></div></div></blockquote><div><br></div><div><br></div><div>Today, through lack of suitable authoritative direction, each agency is acting independently and allocating per-mission prefixes without any thought to aggregation, internally or externally. One can hardly blame them, as this is well outside of the mission scope and expertise.</div><div><br></div><br><blockquote type="cite"><div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div>Provider-based allocation allows naturally for aggregation across infrastructure – as you are aware, the IPv4 “swamp" referenced in the draft is a result of provider-independent (PI) assignments for terminus networks – many being made pre-CIDR era, and others due to provider-independent allocation policies at the RIRs since… I guess the question is whether we expect a lot of requests for IP address space that not affiliated with any deep space network - do you have an estimate?</div></div></div></blockquote><br></div><div><br></div><div>Provider-based allocation allows for natural aggregation if there is a provider-based topology. Provider-shared topologies break that natural aggregation.</div><div><br></div><div>Another example of where provider-based allocation breaks down is deaggregation for inbound traffic engineering purposes. Content providers deaggregate so that routing will direct traffic to a specific entry point to their network. If providers could get geographic allocations, then some aggregation would be possible across these providers.</div><div><br></div><div>Provider-based allocation is our favorite tool, but it is not optimal in all cases. We should consider all of the abstraction tools that we have available, because scaling is an ongoing problem.</div><div><br></div><div>Tony</div><div><br></div><br></div></body></html>