[rrg] Remote ACLs [Proposals which match rrg architectures.htmlpls check the page]
Dino Farinacci
dino at cisco.com
Mon Jan 5 11:03:24 PST 2009
> On Jan 5, 2009, at 9:36 AM, Dino Farinacci wrote:
>> So don't you think the decoupling is a good thing? I can see
>> benefits.
>
> Decoupling is good, but it can go farther...
>
> As I hinted at (oh so long ago) during my presentation at the AMS
> workshop, one advantage of indirection-based approaches is that EIDs
> do not need to be allocated hierarchically, thus the
To be clear, do you mean according to network topology hierarchy or
you mean in power-of-2 blocks? For the later, you want to allocate in
power-of-2 chunks so your access-lists are kept small. And if the EID
could encode an AS-number of domain-id that the RIR allocates to the
site (read: IPv6 allcoations), then we don't have to have the large
prefix-lists per AS we do today in IPv4.
> existing policy constraints for address allocation no longer apply.
> The RIRs could continue to hand out 'routing slot conservation
> policy'-constrained LOCs since they have the technical
Let's not go this route. Let's have service providers allocate RLOCs
to sites. And just have RIRs allocate EID-prefixes to sites. But RIRs
would allocate PA RLOC prefixes to service providers.
Make sense?
> expertise to know what this means. They could also hand out the
> EIDs, but since the policy regime for EID allocation is
> fundamentally different than LOCs, it might make sense for other
> bodies (e.g., national allocation entities like NANPA in the +1
> telephone region) to handle that task.
By allocating EID-prefixes based solely on address usage, you only
have a one-dimensional variable.
Let me be clear, I am not disagreeing with anything you are saying,
I'm just adding more to it. Hope you agree with my statements.
> Of course, if EIDs aren't handed out hierarchically, the existing
> ACL models that rely on locator semantics would obviously break.
> Some argue this wouldn't necessarily be a bad thing...
I think a non-starter. We shouldn't let this happen.
Dino
>
>
> Regards,
> -drc
>
>
>
More information about the rrg
mailing list