On Sat, Jan 23, 2010 at 6:26 PM, Noel Chiappa <[email protected]> wrote:
> > From: Patrick Frejborg <[email protected]>
>
> > 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?
>
Don't know where the PA address is coming from but I think an
enterprise should have PI-addresses always, PA-addresses is for
residential users. Portability is an important and critical goal - it
can be achieved, depending where the split is done. If you split the
locator in two parts, one local and one global you can achieve
portability in that way that the local locator doesn't change when you
change ISP, only the global locator is changed. And the global locator
can be changed via DHCP or manually - the global locator has nothing
to do with the local routing architecture, it is just indicating which
ISP is used for incoming/outgoing sessions. Also the MPTCP hosts have
only one NIC and one stack, the global locator is choosen upon which
ISP is preferred for a session or sub-flow.
>
> > 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.)
>
Should I interpret this statement that a CES solution is only aimed
for multi-homed solutions only? Or will it be implemented also in e.g.
B-RASes that are sitting in front of broadband connections?
> But I am still worried about cache sizes with LCPs.
>
Me too
>
> > 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.
>
>
I think that's the approach we need to take, otherwise the LCPs will
not jump on this core-edge bandwagon. And the problem is, when is a
site becoming a LCP site, it is event driven, isn't it?
Anytime there is something happening that passes the news threshold
some servers are starting to get hits, depending upon the nature of
the news.
> 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....
Yes, we are building a rocket that will reach to Mars but we are
telling the astronauts that we really don't know how we are getting
you back to Earth... but we will figure it out once you are there ;-)
-- patte
>
> Noel
>
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
