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

[Sheng Jiang <shengjiang@huawei.com>]

It is obvious for everyone, that modifications on both hosts and routers are more
expensive than modifications on only routers. Also the latter is more controllable
and may be transparent for the end users, who may not care the Internet routing
architecture at all. If two methods can both reach exactly same functionality, the
latter should have the priority.

However, the central point here is whether modifications on only routers are
sufficient to reach our goals. If we limit ourselves on routers only, we may
overload the routers and networks, then, get a deployable but unusable network
architecture at the end. Choosing out of two possibilities, even the end users would
like to pay the cost of modify their host-stack in order to access the usable
network services.

In summary, we should open to all kind of proposals. But in order to reach the same
goals, we should keep the modifications minimum.

Best regards,

Sheng JIANG, Ph.D.

IP Research Department, Networking Research Department, Network Product Line, Huawei
Technologies Co. Ltd.
 

*-----Original Message-----
*From: owner-rrg@psg.com [mailto:owner-rrg@psg.com] On Behalf 
*Of William Herrin
*Sent: Wednesday, February 20, 2008 7:58 AM
*To: PAPADIMITRIOU Dimitri
*Cc: Routing Research Group
*Subject: Re: [RRG] Are host-stack modifications allowed or disallowed ?
*
*On Feb 19, 2008 3:37 PM, PAPADIMITRIOU Dimitri 
*<Dimitri.Papadimitriou@alcatel-lucent.be> wrote:
*> 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.
*
*
*After my time on ARIN's PPML list, this statement strikes me 
*as incomplete.
*
*A solution must be incrementally deployable from a technical 
*perspective, true, but if that was the only deployability 
*requirement we could adopt Iljitsch's geo-aggregation and we 
*wouldn't need any new protocols.
*
*Technical deployability isn't good enough. A solution must 
*also be incrementally deployable from economic and public 
*policy perspectives.
*
*In other words:
*
*1. How do I get paid now, right now, for deploying each 
*component of the technology?
*
*2. It shouldn't create a godawful mess for the RIRs trying to 
*manage whatever new number resources the technology requires.
*
*The easy answer to #2 is: don't create any new number 
*resources. Make the LOCs a proper subset of the EID space 
*based on some technical criteria as to how they're being used.
*
*#1 is just plain hard, but if you take your favored solution 
*and produce something like TRRP's implementation timeline
*(http://bill.herrin.us/network/trrp-implementation.html) you 
*can get a pretty good idea whether you're asking for some 
*chicken-or-egg component to exist in a deployed state absent 
*some market advantage for the folks who deployed it.
*
*The point of that is not to figure out "the" way that the 
*solution will be deployed. The point is to verify that there 
*is at least one way the solution could be deployed that 
*doesn't contain steps your peers deride as "totally 
*unrealistic." 'Cause if you've got folks saying, "Nobody in 
*their right minds would behave the way you posit,"
*they're probably close enough to correct that your deployment 
*won't happen.
*
*Coming up with such a timeline doesn't guarantee that your 
*solution is deployable, but failing to pretty well guarantees 
*that it isn't.
*
*Regards,
*Bill Herrin
*
*-- 
*William D. Herrin                  herrin@dirtside.com  bill@herrin.us
*3005 Crane Dr.                        Web: <http://bill.herrin.us/>
*Falls Church, VA 22042-3004
*
*--
*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