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

RE: [RRG] Are host-stack modifications allowed or disallowed ?




 > 
 > A) Some folks on this list (e.g. Dino) believe that the Routing RG
 > cannot select an approach requiring any host stack changes
 > -- because that necessarily precludes deployment.
 > 
 > B) Other folks on this list (e.g. Jari) believe that the Routing RG
 > can select an approach requiring host stack changes because
 > that is done by the IETF in the ordinary course of IETF work.
 > 

IMO, disallowing host stack changes is impossible, or do people feel that the host stacks won't change over the next 20 years?

Isn't the question rather whether a solution requires *all* hosts to be changed to see any benefit?

When I think about "incremental deployability", I assume that there is no single type of network node (neither end-host nor router)
that *must* upgrade at a given time to make it work. 
LISP is a router-based solution and also needs to be "incrementable deployable", meaning not all sites/routers switch at the same
time (or at all).

Incremental deployability means that the involved nodes (hosts and/or routers) can switch one after the other. If you change, you
should have benefit, if you don't change it shouldn't be (much) worse than before.

I would personally prefer a solution that works even if no or only a few hosts are changed, but 

A) can additionally benefit from changed host stacks
B) opens up for host changes that the user/end-host can profit from

Actually, changing an end-host is not terribly hard, if not even easier than changing a router. End-users get their updates to OSes
nearly on a daily or weakly basis using update functionalities. 
The thing that is hard is to get *all* hosts changing within a small timeframe. But over a cycle of say 5+ years, most hosts will
anyway run a new OS. (Though I don't have exact numbers on that, maybe someone has them available?) 

- Simon




NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

Attachment: smime.p7s
Description: S/MIME cryptographic signature