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

["Michel Py" <michel@arneill-py.sacramento.ca.us>]

Gentlemen,

I would appreciate if you could be a little more specific in what you
would like to go into the edit doc that in a moment of brain malfunction
I volunteered to maintain.
Please take example in what Ran posted yesterday.

I will add the following as proposed text from Otha-san:
> So, the requirement should be
> A proposal MAY allow site weakly control inbound traffic but it
> MUST NOT increase the amount of global routing/signalling
> information traffic.

>>> Christian Huitema wrote:
>>> 1) Tony Hain sent several detailed comments, one of which
>>> generated a strong debate, i.e. his objection to a part of
>>> section 3.1.2 that stated that "a site MUST be able to
>>> distribute ... outbound traffic between multiple transit
>>> providers," arguing that this was a site policy matter. I
>>> personally don't agree with Tony, and believe the solution
>>> must enable the site to balance traffic, and must also enable
>>> the site to not do so if it chooses.
>> Tony Hain wrote:
>> I was arguing that outbound traffic balancing is a local site policy
>> matter, and nothing we do will change that. The site will send the
bits
>> out whichever interface it chooses, and the only thing this group
could
>> do to influence that would be to define a negotiation protocol (PNI
>> like) to automate changes in site policy.
> Masataka Ohta wrote:
> I agree with you.
> A site CAN NOT be prohibitted to control outbound traffic.
> Any proposal automatically allows sites distribute ... outbound
traffic
> between multiple transit providers.
> So, the requirement is meaningless and should be removed.

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.


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


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

> Yes we can require an approach that allows a
> receiver to balance in the abstract, but there is no way to achieve
> fine-grained absolute control without signalling/negotiation between
the
> endpoint sites, likely to be followed by some form of path
establishment
> protocol.

Yes, and then what?

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

Michel.