Bill,
On 2008-12-30 13:13, William Herrin wrote:
> On Mon, Dec 29, 2008 at 5:57 PM, Brian E Carpenter
> <[email protected]> wrote:
>>> http://bill.herrin.us/network/rrgarchitectures.html
>> Grossly oversimplifying, strategy B is unworkable for IPv4
>> and very close to the plan of record for IPv6.
>
> Hi Brian,
>
> I hate to be a pest, but does this mean you favor eliminating strategy
> B from consideration? Or oppose?
Quoting Joel:
"So I would hate to see either A or B declared out of bounds for this
community."
But it is my opinion that B is a lost cause for IPv4. If someone can write
a proposal that proves that wrong, I'd be delighted.
Below...
>
> I respect that your views on the subject are complex and that you
> would choose to ask and answer a more subtle question. But I didn't
> ask a subtle question.
>
>
>> The other point about this approach to strategy B is that it doesn't
>> break strategy A, if a little care is taken.
>
> There are also forms of strategy A that can evolve into strategy B
> over the long term. Architect your ITR so that the pushed data load
> doesn't render it unreasonable to place the ITR on the end-user's PC
> and then build the ETR dumb. With the session knowledge not available
> to the network ITR, the host ITR can make a better decision. Over time
> it becomes a standard part of the stack.
>
>
>> But people don't seem to have really absorbed that IPv6 stacks,
>> and applications updated to use them, already work with multiprefix
>> PA address assignments.
>
> Name three such applications. No points for layer-7 multihoming or
> applications which are obscure even within the IPv6 community.
Huh? No credit for stuff that works?
Look, IPv6 stacks all, or almost all, support RFC3484 address
selection. That means that *any* application upgraded to use the
IPv6 socket API works with multiple PA-prefix based addresses.
So I think you can make your own list. How many of them have
impeccable retry logic when an address fails I don't know,
however. That takes a lot of testing.
>
> I'm not the IPv6 expert that you are Brian, but your statement does
> not reflect operations-level reality.
What are you referring to there? (Off list if you prefer.)
Brian
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
