Geoff Huston wrote: > WG Chair hat _OFF_ > > On 07/10/2008, at 10:41 AM, Brian Dickson wrote: > >> >> Rather than having: >> >> IP_address / length le maxLength (length <= maxLength <= >> address-family-max-length) >> >> this would be >> >> IP_address / length ge minLength le maxLength (length <= minLength >> <= maxLength <= address-family-max-length) >> > > Its isomorphic in one sense isn't it? The described representation > lists the prefixes in the maximally permitted aggregate format and by > the optional MaxLength parameter which specifies the finest level of > more specifics that could be originated from this ROA. Your suggested > representation allows a number of aggregatable prefixes to be > aggregated as a described prefix, as long as they share a common > minLength value. > > _personally_ I'm unsure that this alternate representation would offer > any superior flexibility in the representation of ROAs.
I'm not sure if any or all of these kinds of use cases are appropriate, but if any of them are, they may serve to demonstrate the compactness achievable with this representation. Examples: RIR->LIR, RIR has certain specific policies it wishes to enforce regarding LIR assignments to end-users -- anything bigger than /X requires justification (i.e. approval) and registration (i.e. ROA). Either RIR has to create a large swath of ROAs, each of size /X, or it can create one ROA with minLength=X. (In this example, maxLength is irrelevant and presumed identical.) Exceptions are needed, of course, for /Y (Y < X), but each of these can be done with separate ROAs. Even as a worst case scenario, no *more* ROAs are needed than in the original case. In a best case scenario, many orders of magnitude quantity of ROAs need never be created, and RIR's policies are enforced directly via ROAs. LIR->PA customers, LIR wants to aggregate but also wants to ensure no customers are able to punch holes in the PA space. LIR restricts the minLength to something not globally routable (e.g. /25 in IPv4, /49 in IPv6). This ties the customer to the LIR, by preventing PA blocks being announced via third parties (hole punching). One ROA can be assigned, whether the amount of space is small or large. Internal aggregation by the PA customer is limited, of course, but that is the intention of the LIR. There may be other cases that I'm missing, but which others may see, based on the above examples. Things related to IPv6 nibble boundaries (for ip6.arpa reasons) but where the current use is only a portion of the larger (reserved) block; ROAs with differing minLength can be created as the customer grows, providing a viable path with no "flag day" needed. It is certainly no worse than the previous representation, as it is strictly a superset. The main question, IMHO, is, does it add sufficient value to justify making the change? (I think it's the only question, actually.) Brian _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
