[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