Re: Requirement document last call (let's focus!)

[Brian E Carpenter <brian@hursley.ibm.com>]

What is clear is that no RFC (especially a requirements RFC)
will settle this. It will be settled in the real world as
IPv6 routing and load balancing practices emerge.
I suggest that we either delete the language, or make it so
vague as to avoid the argument. Deleting it seems simpler.

   Brian

Masataka Ohta wrote:
> 
> Michel;
> 
> > Gentlemen,
> 
> I'm not. I'm not a lady, either. :-)
> 
> > I'm afraid I have to disagree with both Tony and Masakata here.
> > Although the goal is not easy to achieve, a good proposal will try to
> > send
> > The traffic over the "best" path. I am not saying that we should
> > prohibit
> > policy routing for egress traffic, but it would be more elegant to let
> > the
> > multihoming solution decide instead of having the site try to control
> > it.
> 
> Assume that a site is connected to ISP A and B.
> 
> If the site negotiate with ISP A and B individually, egress routing
> is fully controlled by the site.
> 
> Otherwise, ISP A and B must cooperate for the welfare of the site
> even if they are hostile competiters.
> 
> > >> Tony Hain wrote:
> > >> The other point is that for inbound load balancing, the receiving
> > site
> > >> only has control as long as it does not conflict with origin site
> > >> policy, or the topology is deep enough that an intermediary abstracts
> > >> out the differences.
> > > Masataka Ohta wrote:
> > > Again, I agree with you.
> >
> > I disagree with both of you here as well. The receiving site does not
> > have
> > much control over the traffic it receives, but let's not forget that a
> > solution includes BOTH the sender and the receiver, which means that
> > indeed
> > inbound load balancing can be controlled, not by the receiver but by the
> > sender.....
> 
> Are you saying "EITHER"?
> 
> > > Masataka Ohta wrote:
> > > The receiver can advertise detailed routes over
> > > each specific link, but if the origin ignores those and defaults to
> > its
> > > prefered low-cost provider, the traffic is not likely to balance the
> > way
> > > the receiver wants.
> >
> > There are ways around that.
> 
> It's not my statement, but, anyway...
> 
> Constructive proof on exsitense of scalable ways is required here.
> 
> > > But, it will make routing/signalling information not to scale,
> > > which destroys the purpose of multi6.
> >
> > I think that Tony's addressing scheme, although not very optimal, can be
> > made very scalable.
> 
> "very" is not a proper wording to discuss scalability.
> 
> "very scalable" = "poorly scalable"
> 
>                                                         Masataka Ohta