[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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



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. 



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

Tony


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