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

From: "Michel Py" <[email-masked]>
Date: Mon, 7 Jan 2002 23:22:33 -0800

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.

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 8 Jan 2002 10:14:53 -0800

Michel Py wrote:
> The traffic over the "best" path.
This approach is doomed to fail. "Best" is a function of where you are
looking from, what your goals are, and how many distinct policies get
applied along each path.

> I am not saying that we should
> prohibit
I am sorry, but there is no way I am going to allow a destination site
to dictate that I send my traffic over my highest cost path. It is
unfortunate that BGP has fostered the complete fantasy that a site can
control the traffic towards itself. The holder of the packet is always
in control of where it gets sent, and that is true for each hop along
the path.

> inbound load balancing can be controlled, not by the receiver
This makes no sense.

Tony

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 9 Jan 2002 04:07:05 +0859 ()

Michel;

> Gentlemen,

I'm not. I'm not a lady, either. :-)

> multihoming solution decide instead of having the site try to control

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.

> inbound load balancing can be controlled, not by the receiver but by the

Are you saying "EITHER"?

> There are ways around that.

It's not my statement, but, anyway...

Constructive proof on exsitense of scalable ways is required here.

> I think that Tony's addressing scheme, although not very optimal, can be

"very" is not a proper wording to discuss scalability.

"very scalable" = "poorly scalable"

							Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Jan 2002 14:37:55 +0100

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