Re: existing proposals

[Ben Black <ben@layer8.net>]

On Thu, Dec 14, 2000 at 06:31:56AM +0859, Masataka Ohta wrote:
> Ben;
> 
> > > I'd like to propose that the charter of multi6 WG tolerate changes
> > > on API or protocol, even though some people think the changes major.
> > > 
> > > 
> > 
> > ohta-san,
> > 	i believe you are actually proposing 2 additions to the charter:
> 
> No.
> 
> > 	1) any multihoming solutions must maintain "end to end
> > 		transparency" (something in desperate need of clear
> > 		definition).
> 
> "end to end transparency"? What is it? No, I don't need your definition.
> 
> If you don't know what the end to end principle means, see RFC1958
> "Architectural Principles of the Internet".
> 
> If you violate it, scalability is lost, as demonstrated by IPv4
> multihoming.
> 

I have no question about the common meaning of end to end, but I
do not understand how you are applying it (to RFC2260 based proposals,
for example).  I also ask that you read RFC1958 carefully, specifically
the following:

   Some current technical triggers for change include the limits to the
   scaling of IPv4, the fact that gigabit/second networks and multimedia
   present fundamentally new challenges, and the need for quality of
   service and security guarantees in the commercial Internet.

   As Lord Kelvin stated in 1895, "Heavier-than-air flying machines are
   impossible." We would be foolish to imagine that the principles
   listed below are more than a snapshot of our current understanding.

It would seem shortsighted to reject any proposal simply because it
violates current belief systems about engineering best practices.
Doing so would almost certainly result in limited improvement.

> The end to end principle is the basic principle that we don't have
> to put it in the charter.
> 
> > 	2) protocol changes (presumably to IPv6 and transport protocols)
> > 		are within scope.
> > 
> > 	i spoke briefly with thomas narten last night about #2, and
> > while i lean towards believing some protocol changes could make our lives
> > a lot easier, such an approach doesn't seem terribly feasible.  worth a
> > shot, perhaps, but i don't hold out much hope.
> 
> With proper modification of the protocol, it is possible to make
> existing implementaion interoperate with the new one, though
> the existing ones are singly homed.
> 
> > development of additional protocols might be a more likely route.
> 
> No.
> 
> If you are talking about new transport/application layer protocols,
> they are completely meaningless for existing applications.
> 
> If you are talking about new intelligent routing protocols, they
> don't scale.
> 

Again, you are rejecting options out of hand without considering all
implications or possible manifestations.


ben