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

From: Randall Atkinson <[email-masked]>
Date: Tue, 19 Feb 2008 09:32:29 -0800

Earlier, Dino Farinacci wrote:
% 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.

This is a fundamental difference in perspective and deserves
further discussion and thought by all.

If (A) is true, then certain proposals are ruled out by definition.
If (B) is true, then all proposals are really open for adoption.

I'm not sure what the RG Chair(s) think, I'm not sure what
host stack implementers think, and I'm not sure what the
IETF Powers-that-Be think while wearing their official hat(s).

As a purely practical matter, at least one host OS implementer
has a de facto veto on this question.  If that host OS is not
going to adopt a proposed host stack modification (or not
adopt it in a timely way), then the percentage of deployed
host OSs with the upgraded stack capabilities is very unlikely
to become commercially interesting/viable.

Yours,

Ran
[email-masked]

--
to unsubscribe send a message to [email-masked] 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

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 19 Feb 2008 20:50:35 +0100

Randall,

> 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

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Tue, 19 Feb 2008 21:37:49 +0100

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: [email-masked] [mailto:[email-masked]] 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,
>

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 19 Feb 2008 21:50:24 +0100

Dimitri,

> the end) as long as fulfilling the incremental deployability design

I would agree. That's already what I said in Prague and after my 
presentation most attendees seemed to agree.
http://inl.info.ucl.ac.be/publications/reconsidering-internet-routing-archit

> which is the open question faced with LISP

I agree. Increamental deployability is not a criteria which is easy to 
quantify...

Olivier

---

From: Tony Li <[email-masked]>
Date: Tue, 19 Feb 2008 13:44:48 -0800

> IETF Powers-that-Be think while wearing their official hat(s).

Well, this co-chair thinks (and my co-chair is free to disagree ;-)  
that host changes are permissible.  They certainly come with some  
concurrent amount of deployment pain that we do want to take into  
account in our considerations, but there are no limitations within  
our charter that forbid us from going that direction if we so choose.

> to become commercially interesting/viable.

If we're thinking of the same OS implementer, the situation is not  
quite so bleak.  In a private meeting, this viewpoint was moderated  
to being one of making no 'unnecessary' host stack changes.

This leaves us with the overriding prerogative to do what we feel is  
best for the long-term architecture of the network, taking into  
account that whatever we deliver must be deployable and should  
minimize any associated pain.  Obviously, this is going to be a  
judgement call that we should reach rough consensus on.

Tony

---

From: "William Herrin" <[email-masked]>
Date: Tue, 19 Feb 2008 18:58:03 -0500

>    today's Internet, a solution is required to be incrementally

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                  [email-masked]  [email-masked]
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 20 Feb 2008 20:06:47 +0800

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: [email-masked] [mailto:[email-masked]] 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 
*<[email-masked]> 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                  [email-masked]  [email-masked]
*3005 Crane Dr.                        Web: <http://bill.herrin.us/>
*Falls Church, VA 22042-3004
*
*--
*to unsubscribe send a message to [email-masked] 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
*

---

From: Robin Whittle <[email-masked]>
Date: Wed, 20 Feb 2008 23:30:35 +1100

In general, I don't see how a solution to the routing scaling
problem is going to be incrementally deployable if it
depends on host changes.  Likewise other solutions to
"architectural" problems such as providing a new way of managing
address space which allows and encourages higher rates of utilization.

Why would an end-user upgrade a host to solve a problem which
doesn't directly affect them?  BGP routers having difficulties with
too many DFZ routes doesn't directly affect ordinary desktop PC
Internet users.

If the benefits only occur when a large proportion of all hosts on
the net have been altered, I can't see how it would ever happen.

I will assume that the upgrade provides some direct benefits for
whoever runs the upgraded host and/or to the people whose
hosts communicate with this upgraded host.  Here are some questions:

1 - Is it an operating system upgrade, or for the operating
    system and applications?

2 - Does the benefit occur when only this end of the communication
    has an upgraded host, or do both ends need to be upgraded.

3 - Does the benefit rely on some other infrastructure, generally
    accessible to all hosts, or which must be installed in the
    networks at one or both ends?

LISP, APT, Ivip and TRRP do not involve host changes, though there
has been discussion of host changes to cope with initial packet
delays which are expected to occur fairly frequently with LISP-ALT.

Ivip's ITR function in hosts is a purely optional arrangement for
when it is easier and cheaper to do this than to use separate ITRs.

  - Robin           http://www.firstpr.com.au

---

From: Randall Atkinson <[email-masked]>
Date: Wed, 20 Feb 2008 06:38:15 -0800

Earlier Bill Herrin wrote:
% 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.

I applaud the notion that folks should consider economic considerations,
incremental deployability, etc.

However, for virtually any IETF proposal in the past 10 years, there
have been at least some folks ("peers") who derided that proposal as
"totally unrealistic".  Despite this, a number of those proposals have
been deployed at significant scale.

So I would narrow your constraint a fair bit.  If a reasonably large
set of folks view a proposal's deployment model as viable, that
is sufficient.

There are very good reasons that the IETF has a "rough consensus" metric,
rather than a "unanimity" metric.  Similarly, experience with the IRTF NSRG
and its "unanimity" metric indicates that is not the right metric for an
IRTF RG either.

If the metric really is that no one disagrees with the viability of a given
deployment model, then we should all go home now, because
there is (virtually) always some dissent within the IETF (or IRTF).

Yours,

Ran
[email-masked]

---

From: Randall Atkinson <[email-masked]>
Date: Wed, 20 Feb 2008 07:16:43 -0800

Earlier, Sheng Jiang wrote:
% It is obvious for everyone, that modifications on both hosts and routers
% are more expensive than modifications on only routers.

Agreed.

However, at least one concept, that of a true ID/Locator split,
requires no router changes at all.

An approach with a stack change to hosts, but no router changes
has different tradeoffs from an approach with router changes
but no host stack changes:

(off the top of my head; no doubt I've missed various things)

A) Host changes

- The number of hosts is much greater than the number of routers.
- Decision matrix for deployment is potentially larger (more host OSs
  than router OSs, so more implementers need to decide to change things)
+ Feature can be deployed whether or not ISPs decide they want
   to make changes.
+ The Internet potentially scales better because state in the core of
   the network is reduced.
+ Moves the Internet back towards its traditional model ("smart host,
   dumb network")

B) Router changes
+ The number of backbone routers is much smaller than the number of hosts.
+ Decision matrix is potentially much smaller (2 big core router vendors
   plus 3-8 big ISPs)
-  Feature can't deploy unless the big ISPs agree
-  We still have a lot of state in the core of the network; we are just
   handling and using that state a bit differently
-  Continues the current trend towards the new model ("dumb host,
   smart network")

Yours,

Ran Atkinson
[email-masked]

---

From: Scott Brim <[email-masked]>
Date: Wed, 20 Feb 2008 10:46:16 -0500

On 2/20/08 10:16 AM, Randall Atkinson allegedly wrote:
 > + Decision matrix is potentially much smaller (2 big core router
 >   vendors plus 3-8 big ISPs)
 > - We still have a lot of state in the core of the network; we are
 >   just handling and using that state a bit differently

Nice start.  Let see if I can add anything ...

A) Host changes

- The system will need to be robust in the face of incorrect or
   malicious host changes.  There can be incorrect or malicious router
   changes but ISPs understand the risks and the defenses better than
   destination hosts would.

- The business model is difficult, because end system stack providers
   would not see an immediate benefit from implementing and pushing the
   changes.

Mumble ... Scott

---

From: Randall Atkinson <[email-masked]>
Date: Wed, 20 Feb 2008 07:58:40 -0800

Earlier, Scott Brim wrote:
% Nice start.  Let see if I can add anything ...
%
% A) Host changes
%
% - The system will need to be robust in the face of incorrect or
%   malicious host changes.  There can be incorrect or malicious router
%   changes but ISPs understand the risks and the defenses better than
%    destination hosts would.

I disagree that ISPs are inherently more security aware -- some are
and some aren't, just as some end sites are more security aware
than others.

Under IETF rules, any IETF standard needs to be robust from a
security perspective -- whether that involves changes one place
or another.

So I'd rate that as an important evaluation topic, but not
inherently advantageous either way.

% - The business model is difficult, because end system stack providers
%   would not see an immediate benefit from implementing and pushing the
%   changes.

The business model might or might not be difficult, because whether
OS implementers would see an immediate benefit (or a sufficient
benefit which is the real question, IMHO) will vary with the details
of the specific proposal.

So again, I'd rate that as an important topic, but not
inherently advantageous either way.

Both of those said, I do still think it likely that I missed some +/-
items somewhere.  In any event, it is good that you raised
those issues so folks can mull them over. :-)

One of the other things for folks to consider is that with router changes
there actually are more than 2 router vendors who implement BGP and
also have non-trivial deployment.  So having an implementation from
one (or two) router vendors, but not more, is a potential deployment
issue for a router-only approach.

I'm open minded about all of this.  My main goal is to try
to encourage a full evaluation of all of the alternatives,
rather than any form of premature decision.

Cheers,

Ran
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Feb 2008 10:22:22 +1300

> the net have been altered, I can't see how it would ever happen.

However, all hosts are not created equal. If a solution required
a specific type of host to be updated, that might be quite well
linked to economic incentives and therefore deployable. I'm thinking
of a solution that needed host updates only in servers that are
globally visible (typically those in DMZs), but not in client or
generic p2p hosts. Since it is those globally visible servers that
are the main customer base for PI multihoming, they might well be
incented to update their stack to support some form of loc-id solution.

   Brian

---

From: Robin Whittle <[email-masked]>
Date: Thu, 21 Feb 2008 11:59:59 +1100

Hi Brian,

You wrote, in part:

> linked to economic incentives and therefore deployable. I'm
> thinking of a solution that needed host updates only in servers
> that are globally visible (typically those in DMZs), but not in
> client or generic p2p hosts. Since it is those globally visible
> servers that are the main customer base for PI multihoming, they
> might well be incented to update their stack to support some form
> of loc-id solution.

Assuming we are discussing only the goal of multihoming and TE for
hosts which are public servers (and therefore not concerned about
other goals related to routing-addressing, such as improving IPv4
address utilization), then for your suggestion to work, I think:

1 - You would need to show that the multihoming and TE could
    be achieved without changes to the client hosts or the
    networks those are located in.  Therefore you need to achieve
    multihoming and TE purely with new software in the server hosts,
    or together with some routing changes in their network.

    This has to be done in parallel with deploying a map-encap
    scheme, with its ITRs, ETRs and mapping database distribution
    system.

2 - To be incrementally deployable, the benefits would need to
    ensue pretty directly and immediately to the people who run
    these servers and/or the networks they are in.  Or do you mean
    some external incentive scheme to encourage server operators to
    change their operating system (and perhaps application?)
    software?

3 - Also, I think you would need to show that this subset of
    address usage being used in the new way would make a big
    enough impact on the routing scaling problem for it to be worth
    the trouble - ideally sufficient to solve the problem
    indefinitely without having to take other measures.

4 - I also think you would need to get consensus that the
    dichotomy you are implying about networks with public
    server hosts and networks without is valid and will
    remain valid for some decades to come.

Do you have any possible approaches which would pass all of these tests?

LISP-NERD, APT and Ivip don't need any host upgrades at all, since
there is no delay problem or any other difficulty which needs to be
solved at the hosts on either end of the communication.

I think the only reason people are thinking of host upgrades now is
to make hosts somehow cope better with the initial packet delays
which look like they will be inevitable often enough to be a problem
with LISP-ALT or TRRP - the two pure-pull systems currently under
discussion.  You could do this for servers, to help in some way with
the server-client response communication, but your proposal doesn't
allow for upgrading hosts which are clients, so they still suffer
delays and any host stack complications which result.

It is not clear to me how host changes could make these initial
packet delays much less of a problem, other than to tweak existing
protocols so they didn't make such a mess of themselves when such
delays occurred.  The delays will still add up and the end-users
will still be affected - making this form of address space suck, or
at least be widely regarded as being second-rate and best avoided.

The others tests look pretty challenging too.

 - Robin

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 21 Feb 2008 14:52:20 +0800

>    would not see an immediate benefit from implementing and pushing the
I don't think the business model is a big problem or there is no incentive
for the end user to upgrade their hosts. 
Provided the LISP-CONS/ALT is just looked as a transitional solution to the
routing scalability issue, the non-upgraded host will suffer the initial
packet loss/delay pain, on the contrary, once the host is upgraded to
support EID-RLOC mapping query on behalf of the ITR, the end user will jump
out of the pain. Besides, it will benefit the ISPs eventually since they do
not need to afford the high-cost ITRs which should support full database (
e.g. LISP-NERD), or which should support cache and this mechanism will
become a target of DDoS attack.

Best regards,
Xiaohu XU

---

From: "William Herrin" <[email-masked]>
Date: Thu, 21 Feb 2008 03:50:27 -0500

On Wed, Feb 20, 2008 at 9:38 AM, Randall Atkinson
<[email-masked]> wrote:
>  % way the solution could be deployed
>

Ran,

Derided the proposal or derided a specific step in the proposal's
deployment plan? Recognizing whether a particular small step in a
theoretical deployment process is pure pie-in-the-sky is a whole lot
easier than evaluating the likely impact of a plan's general
weaknesses.

We could, for example, argue forever about whether push or pull makes
a plan too consumptive or too  slow to be viable. On the other hand,
its fairly easy to see that "One ISP deploys one machine which does X"
is a viable step in essentially any deployment plan while "27,000 ISPs
each deploy one machine which does X" is an unweildily large step
that's nearly impossible to justify without first breaking it into
multiple steps.

That's why I say: write it out step by step, verify that you still
have a working system overall at each step and then ask, "Why would
individuals choose to perform step #X at that point in the process?
What would cause step #X not to be performable?"

If your deployment process looks like this:

1. Everybody installs the new software and hardware and turns it on.
2. It works

Then the system has a high probability of deployment failure.

>  set of folks view a proposal's deployment model as viable, that

In other words, get a general consensus after excluding the outliers.
If you're talking about consensus among operators then I can agree.

I have found that folks outside of operations or whose operations
tasks are small-scale tend to take a distressingly simplistic view of
how tasks are sequenced in order to get from one working state to the
next. This routinely leads to a faulty consensus, as the IPv6 debacle
should be making painfully obvious to everyone here.

Regards,
Bill Herrin

---

From: Randall Atkinson <[email-masked]>
Date: Thu, 21 Feb 2008 05:56:43 -0800

Earlier Bill Herrin wrote:
% Derided the proposal or derided a specific step in the proposal's
% deployment plan?

Some derided the whole thing while others at the same time
derided the deployment plan.  There hasn't been an I* proposal
that did not have any objectors since I've been around -- and that
timeframe is just over 20 years now.

>  set of folks view a proposal's deployment model as viable, that

% In other words, get a general consensus after excluding the outliers.
% If you're talking about consensus among operators then I can agree.

Routing system changes are also a user issue, because users are affected
(to varying degrees likely) by any proposal that has been (and also very
likely might be in future) made.

In practice, few network operators (by which I mean, site network operators,
enterprise network operators, IXs, ISPs, and inclusively any other sort of
network operator) tend to show up at I* gatherings.  This is a separate,
but very serious issue for the I*.

% I have found that folks outside of operations or whose operations
% tasks are small-scale tend to take a distressingly simplistic view of
% how tasks are sequenced in order to get from one working state to the
% next. This routinely leads to a faulty consensus, as the IPv6 debacle
% should be making painfully obvious to everyone here.

We disagree all round on the paragraph above.

1) I don't think that is why IPv6 has been called a debacle.
   In fact, different folks seem to have entirely different sets of reasons
   that those folks have called IPv6 a debacle.  Your claim is a new one
   to me.

2) I find that most folks have value to add.  I certainly learn a lot from
   talking with folks who run enterprise networks and various other
   kinds of networks at various scales.  Things which work for one kind
   of deployment often don't work for another, and scale is far from
   being the main reason one deployment works while another doesn't,
   though it is one of the several different unrelated reasons that might
   happen to matter.

Opinions aside, the Routing RG's powers are limited.  This RG might make
a recommendation to the IETF or it might not.  The IETF is not obliged to do
anything with that recommendation (other than listen).  Any standards work
will be done in IETF under IETF process rules (which are rough consensus of
whoever shows up and no special privileges for any group).  The IETF can
undertake standards work which is different from what the RG recommends,
it can undertake standardisation of multiple proposals concurrently, or
whatever else the IETF decides to do -- the RG has no powers over IETF
standardisation efforts that might follow an RG recommendation.
IRTF RGs are purely advisory in the IETF context.

Cheers,

Ran
[email-masked]

---

From: "Simon Schuetz" <[email-masked]>
Date: Thu, 21 Feb 2008 15:18:41 +0100

> that is done by the IETF in the ordinary course of IETF work.

IMO, disallowing host stack changes is impossible, or do people feel that the host stacks won't change over the next 20 years?

Isn't the question rather whether a solution requires *all* hosts to be changed to see any benefit?

When I think about "incremental deployability", I assume that there is no single type of network node (neither end-host nor router)
that *must* upgrade at a given time to make it work. 
LISP is a router-based solution and also needs to be "incrementable deployable", meaning not all sites/routers switch at the same
time (or at all).

Incremental deployability means that the involved nodes (hosts and/or routers) can switch one after the other. If you change, you
should have benefit, if you don't change it shouldn't be (much) worse than before.

I would personally prefer a solution that works even if no or only a few hosts are changed, but 

A) can additionally benefit from changed host stacks
B) opens up for host changes that the user/end-host can profit from

Actually, changing an end-host is not terribly hard, if not even easier than changing a router. End-users get their updates to OSes
nearly on a daily or weakly basis using update functionalities. 
The thing that is hard is to get *all* hosts changing within a small timeframe. But over a cycle of say 5+ years, most hosts will
anyway run a new OS. (Though I don't have exact numbers on that, maybe someone has them available?) 

- Simon

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Randall Atkinson <[email-masked]>
Date: Thu, 21 Feb 2008 06:53:59 -0800

Earlier, Simon Schuetz wrote:
% Actually, changing an end-host is not terribly hard, if not even easier
% than changing a router. End-users get their updates to OSes nearly
% on a daily or weakly basis using update functionalities.

I think that is a really excellent observation.  A decade ago, ordinary
consumers tended to only upgrade/patch their home computers rarely
or when hardware changed.  Now, all the major consumer desktop OS
vendors (including the common consumer-oriented versions of Linux)
seem to push out updates quite regularly -- and most ordinary users
seem to be applying those updates equally regularly.

(Maybe some host OS supplier has approximate numbers on this sort
of thing that could be shared publicly ? :-)

I get several OS patches/upgrades from Apple each month.  My company
gets regular updates/patches from Microsoft for the Windows systems,
and judging from IT announcements those get installed promptly.

So upgrading an interesting percentage of the consumer desktop/laptop
operating systems can be done much much more quickly now than
in the past.

% The thing that is hard is to get *all* hosts changing within a small timeframe.
% But over a cycle of say 5+ years, most hosts will anyway run a new OS.

Right.

Would one needed to have all hosts upgraded or merely some interestingly
large (whatever that means) percentage of them upgraded in a shorter
timeframe ?

Food for thought anyway.  Thanks !

Cheers,

Ran

---

From: David Meyer <[email-masked]>
Date: Thu, 21 Feb 2008 07:15:55 -0800

> out of the pain. 

	Understand the assertion, but do you have any data to
	back it up? If so, that would be interesting. Otherwise,
	both conclusions are conjecture.

> Besides, it will benefit the ISPs eventually since they do

	Again, why should ITRs be "high-cost", and for that
	matter, what constitutes "high-cost"?

	Dave

---

From: "William Herrin" <[email-masked]>
Date: Thu, 21 Feb 2008 18:44:20 -0500

>  but very serious issue for the I*.

Hi Ran,

When we want their input, we don't have to go far to find them:
mailing lists like [email-masked] are readily accessible to us.

>  1) I don't think that is why IPv6 has been called a debacle.

Sorry, I was being snippy. If you care, I'll be happy to share my IPv6
thoughts with you offlist, but its not really on topic here.

>  2) I find that most folks have value to add.

I didn't mean to suggest otherwise. It was just an observation that
folks' estimates of the scope of activities outside their specialties
tend to come in significantly short of the reality.

Regards,
Bill Herrin

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 22 Feb 2008 11:14:29 +0800

> 	both conclusions are conjecture.

yes, we need data to see the impact of initial packet loss/delay firstly.
Then...  

> 	matter, what constitutes "high-cost"?

A lot of ITRs in LISP-NERD need to maintain full EID-RLOC mapping database,
the size of which is hundred times or even more large than that of the
current routing table. Doesn't that mean higher cost?

Best regards,
Xiaohu XU

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Feb 2008 10:24:45 +1300

Robin,

>     scheme, with its ITRs, ETRs and mapping database distribution

I'm thinking that there may be a class of solutions which will
work as far as aggregation and scaling are concerned without
any host modifications, but would allow host modifications to
have substantial impact on traffic engineering for the benefit
of sites hosting major server farms. This type of site cares
about traffic engineering to improve its own performance and
reliability, quite independently of ISP concerns about traffic
engineering. I could imagine a server farm dynamically adjusting
its loc-id mapping as the work load shifts around between
phsyical servers, or as it observes performance changes
from one ISP or another. I would expect this would need tight
interaction between host virtualisation software and the
routing system.

>     indefinitely without having to take other measures.

No, only that it would make a big enough impact on the major
hosting sites that they would pay for it.

>     remain valid for some decades to come.

My personal feeling is that this will persist and even
increase, but of course the technology available and the
business models in use have a circular relationship, so
prediction is quite uncertain.

However, the fact that sites use DNS and BGP4 to attract
traffic to particular prefixes today strongly suggests that
they will use any deployed loc-id mapping system the same
way.

> Do you have any possible approaches which would pass all of these tests?

No, except to suggest that hosts MAY particpate in updating
the loc-id map.

> delays occurred.  

Yes, teaching transport protocols to tolerate a larger initial
delay seems possible if it had to be done.

> The delays will still add up and the end-users

At the risk of repeating an argument already made, I don't think that
users would even notice a few hundred ms in addition to currently
experienced start-up delays, as long as the transport behaves
gracefully.

    Brian

---

From: Robin Whittle <[email-masked]>
Date: Mon, 25 Feb 2008 20:07:49 +1100

Hi Brian,

You wrote:

> work as far as aggregation and scaling are concerned without any
> host modifications, but would allow host modifications to have
> substantial impact on traffic engineering for the benefit of
> sites hosting major server farms. This type of site cares about
> traffic engineering to improve its own performance and 
> phsyical servers, or as it observes performance changes from one
> ISP or another. I would expect this would need tight interaction
> between host virtualisation software and the routing system.

OK - I will try to imagine a scenario such as this.

A site has a bunch of servers, either its own or rented out to
customers.  It has multiple links to ISPs and wants to ensure none
of these links gets congested and/or do some other kind of inbound
traffic engineering.

At some times a particular server or bunch of servers X is very
active, drawing in traffic from some distribution of correspondent
hosts HX.  At other times, another server or bunch of servers Y does
the same, with its distribution of hosts HY.

I think you are suggesting some host changes to the servers only,
presumably just their operating systems rather than the server
applications themselves, which would enable the site administrators
to achieve their TE goals, without additional changes in routers
etc.  Also, I am assuming you are not placing further burdens on the
routers in the DFZ with more prefixes or more changes.

I can't imagine what those changes would be, but clearly if you
could upgrade only the server operating systems, leaving everything
alone, and achieve these goals with IPv4, then it would be a
valuable thing to develop.

> hosting sites that they would pay for it.

Yes - if it is only the hosting companies who have to change
something, in a way that doesn't complicate the operations of their
customer's applications - and the hosting company receives direct
benefits which enable or cause it to behave in ways which reduce the
burden on DFZ routers, then any progress at all is worthwhile.

> prediction is quite uncertain.

My point 4 was really only if the "big, supposedly total" solution
to the routing scalability problem relied on distinctions between
different kinds of end-users, such as large and small, server or
client etc.  I think what you are suggesting is some host OS changes
applicable to servers which could be deployed by the hosting company
to acheive TE without burdening anyone else.  I don't see that as a
total solution, but something which would be helpful and should be
pursued.  To the extent that it only works with a subset of end-user
networks, that is fine, because it is not being put in place as a
"total solution".

> they will use any deployed loc-id mapping system the same

I think the "total solution" needs to be about as attractive to
large end-user networks, including server farms, as to small
end-users, new entrants etc.  I feel sure that some kind of
map-encap system will be introduced, but that it will take quite a
few years.  A set of host OS changes such as I think you are
suggesting could work independently of the map-encap scheme, maybe
provide additional benefits with a map-encap scheme compared to the
map-encap scheme on its own or maybe do the same things, without the
need for a map-encap scheme.  I am pretty sure no such set of host
changes could do all the things a good map-encap scheme could do.

> No, except to suggest that hosts MAY particpate in updating

Yes.  The control of mapping information for the one or more
micronets in each User Address Block in Ivip is controlled by the
end-user via a username and password.  Maybe there needs to be a way
that the mapping for a specific micronet can be controlled by a
separate username password pair.  That way, a hosting company A can
rent out a server to customer C and give them one or more micronets
of mapped address space.  They can also give customer C the username
and password for those micronets, so the customer's software and/or
software on the servers which is controlled by company A can
automatically change the mapping, to achieve various things.  Prime
amongst these would be the server monitoring its own incoming
traffic and making changes to the mapping of its micronets to
achieve some kind of load balancing amongst various upstream ISPs.

Since Ivip ITRs don't perform explicit load sharing, one way of
doing this would be to have the server known through the DNS to
clients by four separate, and perhaps contiguous IP addresses.  Eahc
one is its own micronet.  Then, to fit in with the traffic flows of
all other servers at the site, the host can control the mapping of
the micronets to make all of them mapped to an ETR which brings
traffic in through ISP-M, or to map some of the micronets to another
ETR which brings the traffic in through ISP-N.

Maybe the host itself isn't the best place to do this.  Maybe
company A could use some software on the host to monitor its
activity, and report this to some centralised mapping software,
which attempts to balance the load of all servers in real-time by
sending mapping updates, steering traffic through various upstream
links to keep things nicely balanced.

I am not sure if this is what you were suggesting, but it is a good
example of where Ivip's rapid response (I am aiming for 5 seconds or
less) would enable fine, realtime, control over incoming traffic
patterns over multiple upstream links, in ways which could not be
achieved with LISP, APT or TRRP, since they only have slow ways of
controlling the behaviour of ITRs, and because the ITRs themselves,
working in isolation, can't make decisions the way company A wants.
 Only company A knows what traffic is on its upstream links at any
point in time, so it needs fast, specific, control over the mapping
of micronets to be able to steer incoming traffic as it desires.

Company A needs to pay a small fee for each mapping change, so it
would only fire them out at a rate where the benefit it derives
exceeds the cost of each change - and that cost will be set by the
operators of the Ivip system (multiple Root Update Authorisation
Systems) to support the real cost of sending those updatesa and
replicating them out across the Net.

> experienced start-up delays, as long as the transport behaves

A few hundred msec is probably not clearly perceptible to most
people, but if it adds up, with one slowed communication further
delaying the start of others which are also slowed, it would become
more noticable.

Also, delays in sending initial packets in P2P streams could affect
the overall behavior of the P2P application in noticable ways.  For
instance a real-time video streaming application which frequently
depended on one or more packets arriving from hosts it had never had
any packets from so far.

Even if, in general, the slowdown was not clearly noticable to
end-users, and even if the marketing folks didn't use these delays
to turn end-users away from the map-encap space, I still think it is
worth great efforts, including perhaps heroic efforts, to reduce or
eliminate any delays we add to Internet communications in general.
The delay would be repeated trillions of times in the future,
wasting collectively many human lifetimes, just a little at a time
for each individual.

  - Robin

---

From: Jari Arkko <[email-masked]>
Date: Tue, 04 Mar 2008 14:53:56 +0200

Ran,

> that is done by the IETF in the ordinary course of IETF work.
(I only found time to read this thread now. Sorry for the delay.)

For clarification, what I stated earlier was said in the context of the
question "can we change IPv6". I replied that we can, and that its daily
business to change/extend IPv4, IPv6, and various other protocols that
we care for, when backwards compatibility is not too badly hurt.

However, I also added that you have sell the RRG the idea that such
extensions are going to be deployed in the context of a specific
proposal. I do not want to preclude any particular type of a solution,
but I at least want be make very sure that any solution brought forward
can actually be deployed. As we have seen not just with host based
approach but also router based approaches, the deployment/incentive
issues are hard.  Many of the approaches are struggling with this.

Jari

---

From: Scott Brim <[email-masked]>
Date: Tue, 04 Mar 2008 07:24:42 -0800

> interaction between host virtualisation software and the

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.  Would that 
do what you want?  Or do you want to be able to say "Dear edge, I know 
your policy for traffic to prefix X is to bring it in through these two 
points, but I would like it all brought into just this one point"?  If 
so, what's the protocol?

Also, what do you do about interactions between host requests and 
possible traffic oscillations?  The edge would have to take all requests 
into account and come up with its own synthesis, filtered through 
overall network policy anyway?

It seems to me that anything the server/host could influence at the 
level of loc-id mapping would probably already be taken into account in 
the interconnect's behavior, including whether to have any dynamic 
behavior at all.  For its own purposes, the host can use different 
addresses as needed (and we've been there before).

> they will use any deployed loc-id mapping system the same

Sure.  That's site level policy.

I wish I could say we should talk about it in person.

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Mar 2008 13:15:49 +1300

On 2008-03-05 04:24, Scott Brim wrote:
> 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.

> Would that

I was imagining that the site would just spit out mapping updates;
specific topology isn't generally known to end sites.

> overall network policy anyway?

Yes, I'd expect something of an arms race to develop.

> I wish I could say we should talk about it in person.

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

     Brian

---

From: "William Herrin" <[email-masked]>
Date: Tue, 4 Mar 2008 19:37:05 -0500

>  or c) allow ISPs to defeat any attempt by sites to influence TE.

Brian,

I knew a lot of dialup users who kept accounts with two ISPs. If their
favored one was slow or busy, they'd dial the other.

End users have been doing TE for as long as they've had access to
competitive offerings. It is not a thing to be feared.

Regards,
Bill Herrin

---

From: "Tony Li" <[email-masked]>
Date: Tue, 4 Mar 2008 18:26:57 -0800

|>  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).
|
|End users have been doing TE for as long as they've had access to
|competitive offerings. It is not a thing to be feared.

Agreed, but reality intrudes.  The entity forwarding the traffic is largely
in control of what the next hop should be.  While it's not unreasonable for
everyone on the path to express an opinion, the basic architecture of
hop-by-hop forwarding means that the instantaneous decision made right now
may or may not take those varying opinions into account.  Does that fall
into Brian's definition of choice (a)?  

What if that also subsumes (c)?  If a solution provides an influence
mechanism, but the ISP can choose to disregard it, is that acceptable?  From
a purely pragmatic point of view, I don't see how we can prevent it without
re-architecting the basic contractual obligations that the 'net is built
from.

Tony

---

From: "William Herrin" <[email-masked]>
Date: Tue, 4 Mar 2008 21:57:50 -0500

On Tue, Mar 4, 2008 at 9:26 PM, Tony Li <[email-masked]> wrote:
>  may or may not take those varying opinions into account.

Hi Tony,

Ultimately, the user has the power because he has the off switch. I've
heard a rumor that customer churn is a burning problem for ISPs. It
seems obvious (to me at least) that the more options you can give the
user between "on" and "off," the better chance you have of retaining
him as a paying customer.

How much control should the user have over his routing? Exactly as
much as practical and no more.

>  If a solution provides an influence
>  mechanism, but the ISP can choose to disregard it, is that acceptable?

>From a purely philosophical standpoint, I argue that's backwards. The
ISP should provide the routing nudge which the user can choose to
disregard. Think of it like driving a car: the roads tend to funnel me
towards the Interstate highway and I normally go the direction they
lead but I can choose back roads any time I feel like it and nobody
says, "stop."

Regards,
Bill Herrin

---

From: "Tony Li" <[email-masked]>
Date: Tue, 4 Mar 2008 23:14:41 -0800

|From a purely philosophical standpoint, I argue that's backwards. The
|ISP should provide the routing nudge which the user can choose to
|disregard. Think of it like driving a car: the roads tend to funnel me
|towards the Interstate highway and I normally go the direction they
|lead but I can choose back roads any time I feel like it and nobody
|says, "stop."

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.  ;-)

Tony

---

From: <[email-masked]>
Date: Wed, 5 Mar 2008 16:04:19 -0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
William
> Herrin
> Sent: 05 March 2008 02:58
> To: [email-masked]
> Cc: Routing Research Group
> Subject: Re: [RRG] Are host-stack modifications allowed or disallowed
?
> >  in control of what the next hop should be.  While it's not
unreasonable
> for
> >  hop-by-hop forwarding means that the instantaneous decision made
right
> now

This reminds me of philosophical discussions in mobility community about
network vs terminal controlled handover. The user (terminal) has the
ultimate power because they can always move to another operator.
However, it's a leap to say that therefore mobile-controlled handover is
the correct way of doing things (eg GSM took a different view & did
network controlled - I doubt if many users cared one way or the other!)

Best wishes
phil

---

From: Dow Street <[email-masked]>
Date: Wed, 5 Mar 2008 10:19:32 -0800

On Mar 4, 2008, at 11:14 PM, Tony Li wrote:

> that you want and the way that hop-by-hop forwarding works.

What if the driver could (optionally) select from a set of back roads  
that is limited to those published by the network provider?  If the  
driver doesn't want to and/or cannot do this additional navigation  
work, he could follow the nudge of the underlying hop-by-hop mechanism.

In other words, maybe we can build a basic reachability service of  
global scope, and layer on top of that a more advanced service that  
provides enhanced functionality, but where the costs are localized.

> To give the end

Can you clarify?  What if the intentions stated by the end user are  
only advisory?

R,
Dow

---

From: "Tony Li" <[email-masked]>
Date: Wed, 5 Mar 2008 11:10:51 -0800

|> 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.
|
|What if the driver could (optionally) select from a set of back roads
|that is limited to those published by the network provider?  If the
|driver doesn't want to and/or cannot do this additional navigation
|work, he could follow the nudge of the underlying hop-by-hop mechanism.
|
|In other words, maybe we can build a basic reachability service of
|global scope, and layer on top of that a more advanced service that
|provides enhanced functionality, but where the costs are localized.

That would be a fine thing, but the user has only two ways to express his
desires: one is by injecting routing information, which necessarily can be
overridden.  The only other way is by doing a setup protocol.

Some folks have proposed a hybrid architecture in the past that allowed
both, but it (rightfully) went over like a lead balloon.

|
|> To give the end
|> user complete control over the path, we need to revert to a fully
|> connection
|> oriented Internet.  No thanks.  ;-)
|
|Can you clarify?  What if the intentions stated by the end user are
|only advisory?

If they are advisory, then the ISP may ignore them.  It was previously
asserted that this would be unacceptable.

Tony

---

From: "William Herrin" <[email-masked]>
Date: Wed, 5 Mar 2008 16:02:29 -0500

>  asserted that this would be unacceptable.

Tony,

If I want to send a package from New York to Chicago, I can hand it to
UPS and they'll get it there. I won't be able to discuss the routes
the drivers take.

I can also hand the package to a courier, in which case I can probably
discuss the general route he'll take.

Finally, I can carry it myself in which case the package will take
exactly the route I choose.

Why should these routing decisions be mutually exclusive? Why must a
protocol require that all packets follow a top-down routing strategy?

Loose and strict source routing existed in IPv4 for a reason. There
were some security issues, some performance issues and the network got
wider than they could support but they weren't fundamentally a bad
idea. Indeed, if loose source routing was still valid, our map-encap
schemes might not need the encap part at all.

Regards,
Bill Herrin

---

From: Dow Street <[email-masked]>
Date: Wed, 5 Mar 2008 15:03:16 -0800

> overridden.  The only other way is by doing a setup protocol.

In the model I'm thinking about, the network (i.e. provider) would  
publish a set of path options (e.g. a map, list of potential  
waypoints, set of deflection bits, etc) for the host to consider.   
The host could then choose from among these options, with the  
expectation that its choice will be honored by the network in the  
general case.  Otherwise, the network should change the set of  
options it is publishing.  The provider retains control by setting  
the bounds of the allowable routing policy.

The publication of path information from network to host might be  
considered a setup protocol, but I'm thinking it would be strictly  
optional.  The host could still send "regular" packets without  
indicating a specific path preference, and get whatever service the  
network gives them.

> both, but it (rightfully) went over like a lead balloon.

Does the model described fit your definition of a hybrid architecture?

R,
Dow

---

From: "Tony Li" <[email-masked]>
Date: Wed, 5 Mar 2008 15:30:42 -0800

|Why should these routing decisions be mutually exclusive? Why must a
|protocol require that all packets follow a top-down routing strategy?

First, it's not a protocol issue, it's an architecture issue.  As I
mentioned previously, hybrid forwarding architectures that support both
hop-by-hop and specialized forwarding schemes have been proposed and have
been widely ignored before.  Please see RFC 1668 as an example.  Please note
the authors.  ;-)

It's definitely not out of the question, but to assert that folks really
want this now implies that there's been some change in conditions that would
make this feasible from a deployment and business model perspective.  I
certainly haven't seen any indication of that.  Why now?  What's changed?

Tony

---

From: "Tony Li" <[email-masked]>
Date: Wed, 5 Mar 2008 15:41:17 -0800

|In the model I'm thinking about, the network (i.e. provider) would
|publish a set of path options (e.g. a map, list of potential
|waypoints, set of deflection bits, etc) for the host to consider.
|The host could then choose from among these options, with the
|expectation that its choice will be honored by the network in the
|general case.  Otherwise, the network should change the set of
|options it is publishing.  The provider retains control by setting
|the bounds of the allowable routing policy.

In particular, that model would allow the provider to only offer a single
route.  Would that be acceptable?  I'm hearing a resounding 'no'.

|The publication of path information from network to host might be
|considered a setup protocol, but I'm thinking it would be strictly
|optional.  The host could still send "regular" packets without
|indicating a specific path preference, and get whatever service the
|network gives them.

The ability to specify the path preference is certainly logically equivalent
to the setup protocol, especially if you want to be able to alter
preferences with any interesting level of granularity.

|Does the model described fit your definition of a hybrid architecture?

It does indeed.  However, the same question still applies: Been there, Done
that, Got the bruises to prove it, Isn't that going to hurt again?

Tony

---

From: "William Herrin" <[email-masked]>
Date: Wed, 5 Mar 2008 18:44:42 -0500

On Wed, Mar 5, 2008 at 6:30 PM, Tony Li <[email-masked]> wrote:
>  [...] Why now?  What's changed?

Hi Tony,

BGP communities
CDNs (e.g. Akamai)
InterNAP-style optimized BGP

Quite an industry has sprung up in the last half decade founded on the
idea of hyper-optimizing the network path between your content and
your customer. Such systems can address factors that traditional
routing schemes can't, like end-to-end packet loss.

Regards,
Bill Herrin

---

From: Scott Brim <[email-masked]>
Date: Wed, 5 Mar 2008 19:41:47 -0500

Excerpts from Brian E Carpenter at 13:15:49 +1300 on Wed  5 Mar 2008:
> 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.

> or c) allow ISPs to defeat any attempt by sites to influence TE.

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

---

From: "Tony Li" <[email-masked]>
Date: Wed, 5 Mar 2008 17:07:45 -0800

|>  [...] Why now?  What's changed?
|
|BGP communities

That's part of the existing architecture, not anything new.

|CDNs (e.g. Akamai)

Interesting, but I'm missing on how that's relevant.  Akamai plays a lot of
DNS (and other) games to redirect you to your nearest server with the
relevant content.  I'd claim that's more of a highly granular anycast result
more than a specific routing result.

|InterNAP-style optimized BGP

And that's proven to be a very small exception, with a relatively small user
base.  Not really a cry for changing the architecture.

Tony

---

From: Dow Street <[email-masked]>
Date: Wed, 5 Mar 2008 18:05:26 -0800

> route.  Would that be acceptable?  I'm hearing a resounding 'no'.

I think it is reasonable that a provider might offer only a single  
explicit route to a given customer, or perhaps not offer the enhanced  
service at all.  The new functionality is partly related to the  
number of options published by the provider, but also related to the  
act of making the route explicit (host becomes path aware).  If the  
customer has two providers, even a single explicit path from each one  
starts to become useful.

R,
Dow

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 5 Mar 2008 22:54:10 -0500 (EST)

> From: "Tony Li" <[email-masked]>

    > both, but it (rightfully) went over like a lead balloon.
		    ^^^^^^^^^^

Can you expand on that some? Why did it fail, and why was that failure "right"?

	Noel

---

From: "William Herrin" <[email-masked]>
Date: Thu, 6 Mar 2008 00:33:33 -0500

Tony,

Back in '98 I don't recall my upstreams providing a list of
communities I could assign to my announced routes which would alter
the way in which they advertised them to their upstreams and peers.
That offering seems somewhat common today.

>  |CDNs (e.g. Akamai)
>
>  Interesting, but I'm missing on how that's relevant.

At least one of us is being obtuse. I won't claim it isn't me.

Paraphrasing your question, you asked: What has changed since we
allowed loose source routing to slip away that should cause us now to
be concerned about giving the customer finer grained control over
routing.

The answer is: our customers now pay large amounts of money for
relatively crappy methods of moving packets to their customers in a
"better" way than central servers with generic BGP could. Back when we
allowed loose source routing to die, nobody was spending money on such
a thing.

Regards,
Bill Herrin

---

From: Brian Dickson <[email-masked]>
Date: Thu, 06 Mar 2008 01:24:38 -0500

> the way in which they advertised them to their upstreams and peers.

It might not have been common, but was definitely available among 
several of the big players in 1998.
For sure UUnet, Teleglobe, and two or three others (MCI? AboveNet? ebone?).
More than one of those listed the communities in their RADB entries.

> allowed loose source routing to die, nobody was spending money on such

Probably because LSRR as a "traffic engineering" solution didn't (and 
doesn't) scale, especially from a hardware perspective.

Crappy often scales well. "Never underestimate the bandwidth of a 
station wagon full of mag tapes." (Dates back to uucp days.)

Brian Dickson

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 6 Mar 2008 11:15:09 +0100

> both, but it (rightfully) went over like a lead balloon.

Lead balloons turn out to be more feasible than previously thought.  :-)

> asserted that this would be unacceptable.

Isn't that what contracts, SLAs and the like are for? If you give your  
packets to someone, presumably you think they'll take good care of  
them. If they consistently don't, stop giving them the packets. That's  
the only way you can be absolutely sure they won't be doing the bad  
things to them.

The argument "traffic engineering desires by both ends and/or the  
middle may conflict so it's useless to even try to make this work" has  
never convinced me. Yes, conflicts will happen, but most of the time  
people don't care so they won't mind following the preferences of the  
other end/middle.

---

From: "William Herrin" <[email-masked]>
Date: Thu, 6 Mar 2008 09:15:51 -0500

Brian,

Sure, and you measure it in terms of gigabits per gallon.

I don't propose LSRR as a solution. I do propose that since those
days, customer-driven custom routing has become something customers
are willing to pay significant amounts of money for. Therefore,
enabling that customer behavior should be one of the things we "take
seriously" in our new routing system.

Regards,
Bill Herrin

---

From: Bengt Ahlgren <[email-masked]>
Date: Thu, 06 Mar 2008 19:11:26 +0100

> schemes might not need the encap part at all.

This is IMO an important point.  You can get the same function as a
tunnel, but without requiring the other end to decap.  In NIIA we call
it routing hint, but it has basically the same function.

Regards,

Bengt

---

From: Dow Street <[email-masked]>
Date: Thu, 6 Mar 2008 10:55:07 -0800

> it routing hint, but it has basically the same function.

You can also avoid certain path MTU issues of tunnels, all while  
making the underlying intentions for the packet more visible / explicit.

I think some folks may equate tunnel endpoints with "a small number  
of specifically configured routers", and source routing with "no  
control because any router could be a source routing way-point".   
This is really a question of the usage model, though, not an inherent  
property of tunneling vs. source routing mechanisms.  I think you  
could use source routing in a controlled way as well, where only a  
small number of specifically configured nodes are configured to act  
as way-points.

R,
Dow

---

From: Scott Brim <[email-masked]>
Date: Thu, 6 Mar 2008 17:12:31 -0500

> At least one of us is being obtuse. I won't claim it isn't me.

but CDNs (and I'll toss in DNS tweaks) aren't IP level nor are they
routing.  They distribute content.  Accessing that content is done
using the usual IP layer methods.

So this case probes the rule.  I don't think we should assume that the
way to get what you want is by manipulating routing.

---

From: Bengt Ahlgren <[email-masked]>
Date: Fri, 07 Mar 2008 13:09:05 +0100

> making the underlying intentions for the packet more visible /

Yes, but not necessarily, if a router in the middle needs to insert a
new source route.

> small number of specifically configured nodes are configured to act

Yes, but that is more a configuration issue, not an intrinsic part or
requirement of the mechanism.  And that is exactly why I advocate
source routing before tunneling: the flexibility it gives.

Bengt

---

From: "William Herrin" <[email-masked]>
Date: Fri, 7 Mar 2008 07:59:59 -0500

>  Yes, but not necessarily, if a router in the middle needs to insert a

Bengt,

I think he meant the MTU issue where the ITR has to process and
forward the packet too big message. If you've merely added some IP
options that the source host understands then the source can
understand the ICMP error message directly so the system doesn't have
to do anything special. There was a long set of threads about this a
few months ago.

Regards,
Bill Herrin

---

From: Luigi Iannone <[email-masked]>
Date: Sun, 9 Mar 2008 20:04:00 +0100

> the bounds of the allowable routing policy.

You should ge a look to:
https://datatracker.ietf.org/drafts/draft-bonaventure-informed-path- 
selection/
https://datatracker.ietf.org/drafts/draft-saucez-idips/

they both talk about a way for ISP to suggest path to ned-host.

Luigi

> Does the model described fit your definition of a hybrid architecture?

Luigi Iannone

[email-masked]