[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Tony;

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

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.

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

Again, I agree with you.

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

But, it will make routing/signalling information not to scale,
which destroys the purpose of multi6.

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.

My feeling is that, in a sense, BGP already is an overkill.

							Masataka Ohta