> From: Patrick Frejborg <pfrejb...@gmail.com> > Believe we need both CEE and CES so that the end users can decide which > way to go, either by upgrading the hosts or add a network device in > front of their hosts - both approaches should be promoted
Umm, CES approaches can also often be deployed in the host (as LISP does for mobile devices), whereas it seems (to me at least) to be not really feasible to deploy CEE in the network. > you could design the architecture in a such way that it is backwards > compatible and only part of [the hosts] need[] to be upgraded. That was kind of _my_ hope for LISP (although I'm not sure it's not the rest of the LISP group shares, so please, this is only my personal opinion). I've always viewed the LISP devices (ITRs and ETRs) as the boundary between the 'old' part of the network (one namespace, etc) and the 'new' part (separate location/identity, etc, etc). My further hope was that in that segregated 'new' part of the network, we could move forward and actually deploy _new_ stuff (e.g. a new locator syntax, or a new routing architecture). Hosts which didn't need/want direct access to any of new capabilities would not need to upgrade. Of course, for that strategy to succeed, it requires _minimization_ of the number of devices on the boundary (because deploying something new inside the 'new' part means changing them, and the less of them there are, the easier to change things). Moving the boundary to the hosts means more devices on the boundary... so in a way I would prefer to _delay_ updating hosts! Of course, if there are lots of hosts, there is always nested LISP (to which my personal reaction is 'blech', but I guess when you're changing engines in flight, some stages of the process are ugly... :-) > From: Robin Whittle <r...@firstpr.com.au> > The "simple network, sophisticated hosts" paradigm works well in many > respects In pure architectural terms, it is superior. Alas, we aren't working with a clean sheet of paper... > An increasing number of hosts have computational constraints due to > being hand-held devices with very limited battery power. ... if > cryptographic work is required in the CEE protocols, then I think it is > more of a problem. I'm not sure this is a real problem - but it is the perfect hook for another of my architectural observations: In a system which is designed for a very long lifetime, design for the outer envelope of technology today - because tomorrow's will be a lot more capable. Yes, it has to be possible, and vaguely economic with today's technology, but over the entire life-cycle of the technology, you'll be happier overall if you 'push' the design, even though it may cause a little heart-burn in the very earliest stages. Noel _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg