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

RE: Reqt. 3.1.1 [was Re: (multi6) requirements draft comments]



Brian E Carpenter wrote:
> OK, we don't discuss business models in the IETF, but this is the key
> issue in moving to any kind of *fixed* address alocation
> other than ISP
> based PA.

I agree we are not in the business of proscribing any specific business
model, but we can't define mechanisms that are useful without some
context of the models they might be used in. I do believe it is within
our realm to describe a tool and a potential set of business models that
might apply.

> The reason I've railed against Tony's PI proposal is because I have
> serious doubts whether market forces will lead to the adoption
> of metro (or metro-like) addressing and the consequent creation
> of ISP-neutral metro exchanges.

In the abstract I would agree, but in reality the market has already
created the ISP-neutral exchanges in most of the significant metro
areas. What they are missing is an addressing plan that would leverage
those.

> But in any case, it's something
> totally outside the IETF's control. It's also completely compatible
> with PA addresses, simple by giving PA blocks to the metro exchanges
> if and when they appear.

All we can do is write something like a BCP, and let the market decide
if that is viable. As far as the use of PA blocks vs. the PI ones I
proposed, I really don't think it makes too much difference, the
architectural point is to isolate the end customers from the set of
transit service providers they may subscribe to.

> However, returning to our topic, that would make the metro exchanges
> key failure points in the multihoming system. That breaks
> requirement 3.1.1 in the draft. Do we want to insist that the
> solution MUST accommodate failure of metro exchanges?

Yes there should be no single points of failure. The description of a
distributed exchange in my current draft is admittedly a hand-wave, and
likely inadaquate, but I agree we need to avoid this problem.


Tony