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