Brian Dickson wrote:
Oversight on my part - this would need *two* /4's, X and Y. X for RLOCs, Y for EIDs...Tony Li wrote:Again, the real question here is about whether we need host granularity or not.It may be that rather than having one problem/solution match-up to consider, that there are two:dual-homed multi-homed (N>2)I'd argue that the requirements of each differ, and there can be significant scaling benefits from splitting them out, and handling each separately.For that reason, I think further exploring how to provide "host-like" granularity without going to full host granularity, would be wise.However, if we do need host granularity, then I think you need about 3 orders of magnitude more scale, and pure push approaches simply won't get you there.So, toward that end, here I go with thoughts about 2-homed and N-homed... N-homed (N>2)The presumptions are that a site with >2 homes, will have the following characteristics:1. EID prefixes assigned from central authority/authorities (e.g. RIRs) 2. has a network administrator assigning (directly, or via automated mechanism) EIDs 3. handles its own TE issues 4. handles its own EID->RLOC mapping policies 5. has delegated PA space from upstreams for RLOCs, with PA blocks hierarchically aggregated by upstreams (e.g. by POP) 6. quantities X of such sites: (current number of ASNs)<< X << (number of 2-homed sites) This can scale well enough by itself for things like NERD. Similarly, the presumptions and requirements on 2-homed sites could be: 1. no network administrator - just normal users with minimal networking knowledge 2. prefer not to have "centrally assigned" EID prefixes3. want lightweight mechanism for EID->RLOC mapping, preferably automagic4. want scalable aggregation of EID->RLOC mappings, if possible 5. want site EID prefixes, with EID assignment within the site via something like DHCP 6. don't want actual host granularity on EIDs 7. has delegated PA space from upsteams for RLOCs, with PA blocks hierarchically aggregated by upstreams (e.g. by POP) 8. ability to "authenticate" EID->RLOC mappings to prevent spoofing 9. needs to scale to arbitrary pairings of upstream ISP, presumably based on 32-bit ASNsPutting these requirements together puts the need for addressing schemes, and enough bits in the address fields, into perspective.For instance, combining requirements #2 and #3, means there would be a preference for a deterministic mapping scheme for (2 x RLOCs)->EID. Similarly, adding #9 into this, means that EID prefixes must be >>64 bits long - meaning this address space must diverge from the standard IPv6 use of 64-bit Interface Identifiers.I'll take a stab at how this might look. Let's assume first, that we are using new prefix space from IPv6.The prefix space itself would be, for instance, the first 4 bits, such as 4200::/4.Call this prefix "X:4" (meaning value X, 4 bits long).
(I'll use :N rather than /N, since /N is anchored and absolute in length; :N means "the next N bits", and is relative.)The ASN-specific RLOC blocks would be constructed as:X:4 + A:32, forming RLOC-block-A/36, and similarly RLOC-block-B/36, for ASNs A and B.The actual RLOC values would be prefixes assigned from sub-blocks under this, constructed like: RLOC-block-A:36 + a:28 to form RLOC-A-a/64. RLOC-B-b/64 is created similarly with sub-block b:28. The assignments would presumably be done by ISP A and B, however they choose, probably hierarchically.Now for the tricky part -- Constructing EID prefixes. This is done as follows: X:4 + A:32 + B:32 + a:28 + b:28 to form EID-AB-ab/124.
Y:4 instead of X:4... my bad.
Another EID prefix (for reasons of symmetry) is also created, EID-BA-ba/124.The "knob" for TE purposes, is the choice of which upstream is preferred: EID-AB-ab prefers A over B.Note that this allows for *lots* of RLOC assignments (and thus end sites), but does so at the expense of the available EIDs per site (absolute max of 16, max usable under normal circustances is 13.)Global reachability of RLOC blocks is aggregated. How more-specific information on unreachability may be carried somehow, e.g. as opaque BGP data used only at the edge (ITR), is unspecified. EID->RLOC mappings are deterministic, by parsing the prefix portion, and appending the host portion:X:4 + A:32 + B:32 + a:28 + b:28 + host:4 maps onto two RLOCs:
Y:4...
* X:4 + A:32 + a:28 + 0:60 + host:4 (preferred) * X:4 + B:32 + b:28 + 0:60 + host:4 (backup) The alternate EID has the *same* RLOCs, but in reverse preference.Note that this means that the mappings themselves are completely deterministic, and as such, the requirement for push/pull of mapping database goes away. It scales to 2^28 sites per ISP (268M), with arbitrary ISP/ISP pairings for upstreams. It still allows for non-EID use of RLOC prefixes as individual /64's, with the requirement that a few fixed values be set aside (::0/4 specifically).Presumably prefix filtering on ingress by ISPs A and B, would permit only things that match (X:4 + A:32 + *:32 + a:28 + *:28)/124 as the encapsulated EID value, or the alternate encapsulated EID value (X:4 + *:32 + A:32 + *:28 + a:28)/124.
Y:4...
I know it's not what was necessarily envisioned by the current strategies, but hey, it scales pretty well, IMHO.What do folks think? Brian Dickson -- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
-- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg