John,

(I trimmed this to just RRG. My comment isn't specific to LISP/ALT.)

On 2009-02-03 10:09, John Zwiebel wrote:
> 
> On Feb 2, 2009, at 10:31 AM, David Meyer wrote:
> 
>>>>
>>>> cant they? I thought one of the nice things about the loc/id split was
>>>> I could number my internals out of whatever I wanted, spread over
>>>> creation and the attachment points were the only things that required
>>>> aggregation, no?
>>>
>>> Sure, but if one of your sites is in New Zealand, and has a prefix
>>> where the physical ALT hierarchy is optimized for sites in Europe, a
>>> source in New Zealand trying to contact your site would see more delay
>>> during the Map-Request/Reply exchange, even though it they are in the
>>> same town.  However, Map-Request/Reply exchanges don't happen very
>>> often, and the delay will be low (round trip across the Internet).
>>
>>     Or not at all if you're not the first folks communicating
>>     between the sites.
> 
> As dino said, you can.
> 
> Let's say the site was using 10/8
> 
> The xTR in Europe would advertise 10/8 into the ALT.
> The xTR in NZ would advertise 10/8 into the ALT
> 
> If you're in NZ, your map-request would be routed over the ALT to that xTR
> If you're in Europe, your map-request would be routed over the ALT to
> that xTR.
> 
> If it is desired, the EID owner can modify the RLOC advertisements so that
> encapsulated data packets will go to the RLOC he wants them to.
> 
> If you want to move the EID-prefix to a different geographical location,
> (NZ to Timbuctu)
> withdraw the route from NZ and start advertising it from Timbuctu.  Yes
> the RLOC
> will change.  The ALT hierarchy doesn't change.

That sounds like policy-based mapping and would create interesting
commercial side-effects just like BGP policy does. It also suggests that
explicit scoping of map entries would be desirable, filtering rules for
propagation of map entries too, and maybe there would be a risk of
black holes in the map. That all sounds very familiar.

    Brian
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg

Reply via email to