> From: Patrick Frejborg <pfrejb...@gmail.com>
> Yes, and I believe that the Trojan Horse is called MPTCP :-)
Support for multiple PA addresses does certainly help with the multi-homing
aspects, but does it help with number (address) portability at all? I mean,
you just did say (above):
> the subscriber owns the number and can choose which ever service
> provider [they] prefer[]. So we should keep this model in the Internet
> as well.
So is portability an important (critical?) goal or not? If so, how would
portability be done, if multi-homing is handled with multiple PA addresses?
> If the CES solution becomes popular and gets widely deployed, e.g. if
> broadband routers will include an ITR stack it will increase cache
> sizes on the ETRs in front of popular sites.
Cache sizes in front of large content providers are the thing that concern me
the most, but I don't think you're likely to see the _average_ residential
customer getting their own mapping entry.
That's because most residential customers don't have any need for the things
you need a mapping entry for - multi-homing, address portability, etc. (Heck,
my ISP seems to change my address on a regular basis, but because I'm not
running any servers, I don't notice.)
But I am still worried about cache sizes with LCPs.
> Can you get a better story if you combine a CES with CEE from day one,
As I pointed out, most any CES can also be a CEE without much work.
Maybe that's the solution to the LCP problem - move the mapping stuff into
their servers, so they don't have the ETR caching issue? They generally all
have customized gear anyway, so that's probably actually feasible, now that I
think about it.
Of course, in a _rational_ design we wouldn't have this
caching/identifier-lookup issue, because the system would have been designed
from day one for the DNS lookup to return an {EID, RLOC} tuple, which would
be kept together thereafter.
Blasted 'changing engines while the plane is flying' - sure produces some
ugly configurations....
Noel
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
