Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering

From: [email-masked] (Noel Chiappa)
Date: Sat, 30 Dec 2006 17:00:01 -0500 (EST)

> From: Roland Dobbins <[email-masked]>

    > what has been proposed with SHIM6 and related proposals in terms of
    > endpoints making path selection decisions for themselves.

Perhaps I'm confused, but I thought the main goal of SHIM6 was to allow
widespread site muti-homing without overwhelming the existing global routing
system with zillions of PI advertisements.

If anyone's trying to support users/endpoints making path selection decisions
with just SHIM6, they are seriously confused, IMO. You need a lot more than
just multiple routing-names to do user/endpoint path selection in any
reasonable way; for a start, you need information about the network topology
(sorry, JohnD :-), and a way to actually control the path (and no, the source
routing of today isn't it), etc, etc. In other words, it's a major
architectural change, way past anything that's being discussed even here.

    > Is there some other paradigm or architecture in place today which would
    > serve as a useful analogy in terms of extrapolating the need
    > for/desirability of hosts making path selection decisions?

Well, I don't know about you, but a majority of North American individuals
make numerous path-selection choices every day, as a fundamental aspect of
their daily lives.

I'm talking, of course, about driving cars from A to B across the road
network. And while some people are happy to take the default path, and if
there's an outage (read accident) or congestion, they are happy to wait, I
see plenty of people who are interested in availing themselves of the
flexibility the system gives them to make independent decisions, and when
they encounter outages or congestion, use alternative routes they select
themselves.

Too bad the data network doesn't give us all the same opportunity.

	Noel

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Roland Dobbins <[email-masked]>
Date: Sat, 30 Dec 2006 14:16:07 -0800

> system with zillions of PI advertisements.

[Because this is being discussed in the context of IPv6, which still  
utilizes 'IP addresses', I have elected to use that term in this  
particular context, based upon common usage.]

That is what the SHIM6 authors assert they are trying to accomplish,  
and it's what the authors of similar proposals assert they are trying  
to accomplish.  Based upon the way that networks are constructed  
today, it seems to me that by mandating that each endpoint in a  
multihomed network have multiple IP addresses from multiple provider- 
assigned netblocks and that each endpoint then make a determination  
as to which of its multiple IP addresses is utilized as the source IP  
for each packet it emits, that this is in essence giving each  
endpoint a say in the initial path selection for the traffic it  
originates.

By all means, please correct me if I'm mistaken in this  
interpretation.  Perhaps I've read something into these proposals  
which really isn't there?

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // 408.527.6376 voice

		All battles are perpetual.

     		   -- Milton Friedman

---

From: David Conrad <[email-masked]>
Date: Sat, 30 Dec 2006 15:02:51 -0800

Noel,

> system with zillions of PI advertisements.

This was the goal of multi6, which led up to the shim6 proposal.  I  
believe (and I will no doubt be corrected if I'm wrong) that the  
folks developing shim6 felt the definition of "site" was sufficiently  
vague as to imply the only real boundary where multi-homing would  
make sense was the "host" (arguably an equally vague term, but one  
that most folks can get their heads around).

In my opinion, shim6 as it stands is not a _site_ multi-homing  
technology, rather it is a _host_ multi-homing technology.  It also  
doesn't help with "transparent renumbering" and I believe people have  
argued that it makes the traffic engineering problem worse (at least  
from the perspective of ISPs).

Rgds,
-drc

---

From: Roland Dobbins <[email-masked]>
Date: Sat, 30 Dec 2006 15:07:01 -0800

On Dec 30, 2006, at 3:02 PM, David Conrad wrote:

> doesn't help with "transparent renumbering" and I believe people  
> have argued that it makes the traffic engineering problem worse (at  
> least from the perspective of ISPs).

This has been my interpretation of the implications of SHIM6, and so  
the objections I've raised to SHIM6 (or any proposal with similar  
characteristics) have been predicated upon this interpretation.

It makes the traffic engineering problem (along with all the problems  
already discussed) worse for enterprises, too.

     		   -- Milton Friedman

---

From: Tony Li <[email-masked]>
Date: Sat, 30 Dec 2006 16:15:49 -0800

On Dec 30, 2006, at 3:02 PM, David Conrad wrote:

> I believe (and I will no doubt be corrected if I'm wrong) that the  
> folks developing shim6 felt the definition of "site" was  
> sufficiently vague as to imply the only real boundary where multi- 
> homing would make sense was the "host" (arguably an equally vague  
> term, but one that most folks can get their heads around).

Well, I guess you're anticipating this then....

The real reason that shim6 came out the way that it did was the  
intensive pushback that all of the per-site proposals were given.   
All of those options were rejected as being too NATty for those tastes.

Given the constraints that NAT was out, that we need to support  
multiple addresses, and that the stack can't change so that there  
must be only a single address seen by the stack, the only reasonable  
and logical alternative was to move the NAT functionality into the host.

Tony