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