[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RRG] Upgrading user device software for multihoming or solving ROAP
> I think it is much better and easier to upgrade a few routers than a
> lot of end-user devices, to provide multihoming or to solve any other
> Routing and Addressing Problems (ROAP).
Hi, I agree with you, although "few" can only be understood in contrast to the number of end-user devices. :-) Some hundred thousand routers are hardly "few" :-) There is the additional fact that routers are very expensive.
Anyway, routing scalability is a problem in the DFZ routers, so for me it also seems to be logical to solve it there.
> ...
> Maybe the upgradablity of IPv6 user devices can be assumed, but it
> seems unlikely to me. Once "devices" include consumer devices like
> web-cams, laser printers, ADSL modems, WiFi enabled iPods etc.
> there's no way to upgrade them.
>
> Google finds 10k pages for "IPv6 lightswitch". I don't think we want
> to be downloading operating system upgrades into lightswitches. I
> know many of these devices are likely to be used on local addresses,
> and so wouldn't need global unicast IP addresses, world-facing
> operating systems or multihoming. But if I had an IPv6 lightswitch,
> I would want to be able to SSH to it from any host in the world.
>
> For IPv4, I think the routing and addressing problems are not going
> to be solved by any approach which assumes upgradeable software in
> user devices. There are far too many desktop machines, DSL modems,
> RAQ web servers etc. out there which no-one is ever going to add
> software too. No new architecture can afford to be unreachable from
> those many devices.
Yes, if the solution was not backwards compatible in some sense. I mean, has there been any solution proposal around which assumes host changes but which would render the legacy hosts unreachable? I think no.
Solution requiring host changes should in each case give an alternative for proxy mode, so that host need not be changed after all.
But I think the question is more fundemantal, whether host changes are feasible or not. Is the host the right place to solve all problems? I think no.
Where is the problem?
In case of host multihoming: The problem is in the host with its sockets. The problem should be solved in the host. HIP solves it in the host, but without the deployment of HIP, most applications solve it in higher layer (e.g. re-connect)
In case of routing scalability: it is in the DFZ routers, not in the hosts. Each router taking part in global BGP routing could face the problem. Therefore, it should be solved in the DFZ routers, or in the routing protocol (generally not run by hosts).
And why do we face routing scalability limiations? Now, that was one very intersting topic in the last RRG meeting. Some people do not agree that is only multi-homing or PI addresses.
There were two other interesting reasons:
- advertising more specifics to do ISP inbound traffic engineering
- advertising more specifics to prevent false origination
So, my question is, do we reliably know which one of the above (or which other) cause is responsible for the FIB increase?
What else could bring operators now or in the future to advertise more specifics?
Do the proposed solutions address all causes? The basic philosophy of ENCAPS and it reincarnations today is to separate DFZ (i.e. Internet backbone) routing from the rest. Are we sure that it will solve the problem? If tier-x operators do advertise more specifics, then probably not. Any opinions?
Kind regards,
András
--
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