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

[Scott Brim <swb@employees.org>]

Excerpts from Brian E Carpenter at 13:15:49 +1300 on Wed  5 Mar 2008:
> On 2008-03-05 04:24, Scott Brim wrote:
> > So ...
> > 
> >   - a host or server farm can change its loc-id mapping and control
> >     which site interfaces it receives traffic on.  This can be
> >     per-flow.
> > 
> >   - on a broader level, a site interconnect point can control how
> >     traffic to an including prefix enters the site.
> > 
> > Since loc-id mappings for whole prefixes will be cached all over the
> > Internet, the only way for the host (or server farm) to control this
> > dynamically would be to use an ID from a different prefix.  
> 
> Or, use the loc-id map to punch a hole in a prefix - exactly as they
> might use BGP today. They might also game whatever TTL mechanism the
> mapping system supports (as people game the DNS TTL today). For
> rough-and-ready load balancing, the method doesn't have to be
> watertight.

If I were to do this at all (and I'm still concerned about
rate*state), in LISP I would do it in the data plane.  Don't change
the mapping database -- rather, put something in the data packet
headers to influence which RLOC the return packets take.  As a general
principle I think it's better not to churn the mapping system for
individual flows.

> I think the question is whether The Solution should
> a) recognize that sites may legitimately influence TE policy and
> provide hooks;
> b) turn a blind eye to the issue, which will probably cause sites
> to influence TE by back door methods as today;
> or c) allow ISPs to defeat any attempt by sites to influence TE.
> 
> My preference is for a).

Sure, but the pivotal word is "influence".  A client may make a
request, and a provider should take it into consideration, but shall
choose how it will act on it.

Excerpts from Tony Li at 23:14:41 -0800 on Tue  4 Mar 2008:
> Yes, but there's a very big difference between you driving your car
> the way that you want and the way that hop-by-hop forwarding works.
> To give the end user complete control over the path, we need to
> revert to a fully connection oriented Internet.  No thanks.  ;-)

Nimrod.

Scott



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