Am 13.11.2012 15:14, schrieb Ted Lemon:
On Nov 13, 2012, at 2:24 AM, Brian E Carpenter <[email protected]>
wrote:
even if it's the equivalent
of the beeping from a smoke detector whose battery is fading.
To which the typical response is to throw the damned thing through the window
out of rage after it's been beeping for a couple of hours.
No, there are several viable solutions to this problem that don't involve
beeping. Beeping is not the right solution.
I would just like to point out, regarding the bufferbloat problem, that there
are two classes of outcome if we hack around this problem instead of beeping.
The first class of outcome is that something works less well than it otherwise
would have. This is the bufferbloat problem. If you have bufferbloat
because you set up a bridge where ideally you shouldn't have, this is bad, and
the customer will experience less than ideal outcomes. But fundamentally,
their network will function, particularly when loads are light. And so this
becomes a problem that they will either live with, or try to solve, but it is
not an emergency. It is a bad outcome, and the villain is clear: it's the ISP
who gave out a /64. FAQs on the net can cast the blame appropriately, and the
home gateway can provide diagnostics that explain why the situation is
suboptimal.
Contrast this with NAPTv6. In this case, the network is _broken_. End to
end doesn't work. If you are not connected directly to the border gateway,
certain protocols simply will not work. The result of this will be a general
expectation on the part of applications vendors that end-to-end isn't something
that can be counted upon. And so we will have got nothing for all our effort
in deploying IPv6. We'll be back to NAT-inspired walled gardens.
Let's at least set our sights on the better outcome: the one that preserves end
to end. Yes, it's not ideal. But the blame will be cast on the correct
villain, the end-user will at least have a chance of a good outcome, and it
won't needlessly break end-to-end.
I still like the idea of a led which is red if no prefix could be
received, orange if a /64 has been assigned, and a prefix has been
requested from a downstream router (no prefix for the downstream
router), and green if a prefix < /64 has been assigned and a prefix has
been requested from a downstream router and successfully provided.
This is like the leds on the smoke detector, which start blinking once
the battery level is low. They signal a problem, but it's up to the user
whether to ignore it, or to fix it.
Additionally, if there's no prefix request from a downstream router, no
warning will be issued (e.g. green led) as there's no problem.
Dual homed networks with a /64 from one provider and a /56 from the
other might actually behave the same.
As the /64 part gets a prefix request, it switches to orange led, even
though the prefix can be provided by the /56 part, and subnetting works.
But it's a partial bad outcome, and the user should get a hint at that.
Up to him then to leave it or fix it.
I can understand that it would be almost out of scope to put such a
mechanism/idea should into the draft, as it should focus on how to
magically solve issues.
I'm just afraid that even if you put in phrases like "a /64 will
seriously limit the functioning of the homenet" twenty times in the
draft, it might get ignored by ISPs, and thus would love to have the
suggestion of issuing some sort of warning by the gear vendors written
somwhere.
Just my 2c
Mat
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
