The draft uses RFC1918 address space as there are only three(3) IPv4 blocks made available by RFC 5737 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24 (TEST-NET-3). Given that the key part of the use cases really revolves around the prefix length and MaxLen - the bits that make up the address part are meaningless.
So if we were to construct the use cases around /24s, and then sub-allocate/assign /25's and /26's in the document, I posit the document would be less meaningful to a reader. (I don't see too many cases of /26's in BGP, yes from time to time, but not in numbers and not routinely) I feel more comfortable saying that using 10/8 provides deeper and more meaningful examples. As for the ASNs, I originally started writing the draft using ASNs from RFC5398, however a few ASNs from outside the range 64496 - 64511 crept in. They can be cleaned up easily enough without having to rejig the document. There are no use cases using IPv6 and its documentation prefix from RFC3849. A quick discussion between authors wayback suggested a KISS principle. Cheers Terry On 22/12/11 1:32 PM, "Randy Bush" <[email protected]> wrote: >> And why not use the documentation prefix(es) and documentation AS(es) >> in this draft. rather than 10/8 etc. That's what they are there for. > > the draft in $subject uses 10/8. i think sandy was pointing out that > the ips and asns in rfc 5737 might be more appropriate. is the latter > what you mean by "documentation xxx?" > > so what is it you are suggesting? i suspect you are agreeing with sandy > but can not parse. my error, likely, too much good theater and food. > > randy > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
