[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: requirements draft revision
Joe Abley wrote:
> My point was that it is trivial to affect the routing policy of
> an external organisation by buying transit from them.
Then why couldn't 'popular site' trivially affect the routing policy of 'one
particular provider' to bypass the path? After all they bought transit from
them.
All that a site can hope to affect is the 'internal' routing policy of a
service provider, and then only because that is the service being bought.
> If I made the first paragraph "between its transit providers"
> rather than "between transit providers" would thae make it
> clearer?
It would certainly limit the scope of the statement to what is achievable
today.
> The requirement here is that "popular site" should be able
> to multi-home between ISP4 and ISP5 in order to avoid
> congestion between ISP4 and ISP5.
Basically what you are saying here is that 'any site should be able to
acquire services from an arbitrary set of providers'. But the statement in
the draft goes significantly further:
"The multihoming architecture should allow E to ensure that
in normal operation none of its traffic is carried over the
congested interconnection T1-T2."
This implies that any multi-homed E has realtime control of global routing
policies of all other organizations. The best that E can hope for is that
traffic from direct customers of T1 & T2 not be carried over the congested
path. It may through selective announcements be able to affect some traffic
beyond the direct customers of T1 & T2, but it can't do that reliably on a
global scale.
> I still don't see what is unobtainable about the requirement,
> given that it describes motivations for multi-homing that are
> achievable today with v4/CIDR-abuse.
The words used are overly broad compared to actual practice. I don't have a
problem with requiring that current practice be continued, but make sure the
words are not setting us up to require something beyond reality.
Tony