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

RE: (multi6) requirements draft comments



Brian,

>> Fully agree. All I am suggesting right now is that we don't
>> *assume* PI is the answer for multi6.

Enhanced PI is the SHORT-TERM answer to multi6.

>> If I thought it would scale for tomorrow's Internet, we
>> wouldn't be having this conversation.

It does not scale, and we know it (although there are ways to
scrounge 10 or more years out of it). And, a bad solution is
better than no solution.

>> We agree. So don't build PI into the requirements of multi6.

I am not advocating to build PI into the requirements of multi6.


>>>> This tells me that the road we need to pursue is an
>>>> evolution of the current model as a headstart and continue
>>>> to research other things as incremental changes
>> Please don't build that into the requirements either. Maybe
>> somebody will invent the slam dunk when they see the agreed
>> requirements. (Unlikely, but we mustn't exclude it by
>> construction.)

IMHO, this is not relevant. If somebody invents the improbable
universal solution that everyone here has failed to grasp,
we will all agree to toss the requirements overboard.


What I am advocating for is being realistic:

1. As Randy said, we do have a collective responsability to
bring the IPv6 community more or less what exists today for IPv4
and try to clean it as we go.
*** hint ***
http://search.ietf.org/internet-drafts/draft-py-multi6-mhtp-01.txt

2. This is not enough. No single solution actually answers the
big-picture problem and there are three main areas, or classes, or
spaces or whatever that needs to be addressed: big honkin' setup,
home/soho, and mobile, probably with some overlap.

3. The current requirements draft is blocking solutions from being
developped and, as Christian said, it's time to put it to bed.

Michel.