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

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



olivier

section 3.10 of
<http://tools.ietf.org/html/draft-irtf-rrg-design-goals-01>

3.10. Deployability


   Since solutions that are not deployable are simply academic
   exercises, solutions are required to be deployable from a technical
   perspective.  Furthermore, given the extensive deployed base of
   today's Internet, a solution is required to be incrementally
   deployable. 


--> i would state that the solution should not be constrained by which
system (host vs network) will require changes/updates (it may be both at
the end) as long as fulfilling the incremental deployability design
goal.

the real question is: incremental does not necessarily mean impact free
even if a solution initially targets only host or network updates -
which is the open question faced with LISP

thanks,
-dimitri.


> -----Original Message-----
> From: owner-rrg@psg.com [mailto:owner-rrg@psg.com] On Behalf 
> Of Olivier Bonaventure
> Sent: Tuesday, February 19, 2008 8:51 PM
> To: Randall Atkinson
> Cc: 'Routing Research Group'
> Subject: Re: [RRG] Are host-stack modifications allowed or 
> disallowed ?
> 
> Randall,
> 
> > % 1) If you put Loc/ID functionality in hosts, then they
> > % will have to change. Don't want to do this because
> > % it kills deployability.
> > 
> > This question, for which Dino's view is expressed above,
> > is actually pretty central to the discussions here.
> > 
> > 
> > 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.
> 
> I personally think that the architecture should not preclude on which 
> kind of systems it will be deployed. Some environments will want 
> router-based solutions (e.g. corporate networks), others will prefer 
> host based solutions (e.g. home environments). The 
> architecture that RRG 
> will develop should be deployable on both hosts and routers.
> 
> Concerning the ease of deployment of new features, ten years 
> ago routers 
> were easier to upgrade than hosts, but nowadays most hosts 
> are patched 
> every month or so and thus deploying a new feature on a large 
> number of 
> hosts is not difficult. I'm not aware of any router vendor providing 
> automatic upgrades of its OS.
> 
> 
> Olivier
> 
> 
> -- 
> http://inl.info.ucl.ac.be , Universite catholique de Louvain, Belgium
> 
> --
> 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
> 

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