Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

On 2008-01-11 10:23, Tony Li wrote:
> 
>> Correct. And that is a significantly harder problem than multihoming
>> for an enterprise network that only has one point of interconnection
>> to the outside.
> 
> 
> Our job is to solve the hard problems, not just the easy ones.

Yes, of course - I was attempting to agree with you that we must
not ignore this case.

> 
> 
>>> Optimal  routing implies that there will be different locator
>>> preferences for different hosts.   Mobility within the
>>> organization itself implies that creating and maintaining meaningful
>>> identifier prefixes is going to prove challenging.
>>
>> Indeed it is challenging, so why bother?
> 
> 
> Because our job is to fix the routing and addressing architecture.

OK, I was too telegraphic. I don't believe that mobility that preserves
a global routing prefix is a requirement. [Discussion of the value of
Mobile IP elided.] I do mean global - there are certainly scenarios where
mobile prefixes are a requirement, but those won't be prefixes that ever
need to be in the public Internet, so they aren't part of what I thought
we were discussing here.

> 
> 
>> Having roamed around that
>> organization pretty widely over ten years, and roamed around it
>> virtually by remote VPN on a daily basis, I never had or needed
>> a meaningful prefix beyond 9/8. Internal servers, otoh, don't roam.
>> Externally visible servers aren't even in Net 9, because of various
>> techniques for security, load balancing, and traffic management.
> 
> 
> I'd say that's an admission (ok, Yet Another Admission) that the routing
> & addressing architecture isn't working.  When a site needs multiple
> prefixes for whatever reason, that's a problem that we should solve.

Actually I suspect that when you analyze *why* IBM's public web servers
aren't in Net 9, it will turn out to be because they need RLOCs but
Net 9 addresses behave like EIDs. So yes, I didn't mean to imply that
everything is hunky-dory.

> 
>> Certainly I'd expect EID space for large enterprises to be sliced
>> and diced down to the geographical-site or even server-farm level.
>> I don't think it's necessary down to host level.
> 
> 
> Why not?  That seems like a fairly arbitrary architectural decision.

Well, it's not so much a decision as a prediction of likely
operational practice... YMMV.

> 
> 
>>> In other words, I think that we need host level granularity in the
>>> mapping function.
>>
>> I'd prefer to say: we need to support arbitrary granularity, but the
>> normal level will remain as a site (for some definition of site).
> 
> 
> The distinction here escapes me (unless you're already thinking
> mechanisms).

See previous comment - I think we need an architecturally general
solution but the scaling target is a matter of prediction.
> 
> 
>>> I *don't* think that we need per-interface granularity, as the
>>> semantics of an identifier should be host-specific, not identifier
>>> specific.
> 
> 
> Oops.  s/identifier specific/interface specific/
> 
> 
>> I hope that's right, but since you can't tell by looking at two IP
>> addresses if they refer to two interfaces on the same host, it's
>> unenforcable.
> 
> 
> Fair, but we needn't architect to assume interface specificity either.

We agree on that.

   Brian

--
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