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

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

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