Hi Wes,
Thanks for your comments. Please find responses inline.
On 10-10-25 11:01 AM, George, Wes E IV [NTK] wrote:
-----Original Message-----
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Christian Huitema
Subject: RE: I-D Action:draft-krishnan-6man-header-reserved-bits-00.txt
But then, waiting for the traffic to increase and the load
balancing needs to materialize also makes a lot of sense.
[WES] No, actually it doesn't, especially not as a justification for this draft. We as
operators are telling you that we need something now, because we've seen this
load-balancing movie already in IPv4 and we'd like to get ahead of it in IPv6. If you are
proposing waiting to implement a better solution for load-balancing because IPv6 traffic
isn't there yet, you are simply being short-sighted, which is funny given that this draft
is an attempt to future proof the IPv6 header. All it takes is a few key traffic
sources/sinks moving to IPv6 on your average network... People see their IPv6 traffic
increase dramatically *overnight* simply by enabling whitelisting for the Googtubemail
sites. 3 years ago, I might have bought that tired old "wait and see" argument,
but not when we're this close to IPv4 exhaust and starting to see real IPv6 deployments
happening in many major ISPs.
I strongly support the load-balancing use of the flow label. The
question is how many bits are really required. I am not an operator and
hence cannot speak authoritatively, but talking to our customers leads
me to believe that 16 bits is sufficient for this purpose. I would love
to see some more data on this.
I am pretty
sure that 5 or 10 years from now someone will be glad that there are
unused bits in the header...
[WES] Call me crazy, but I'm pretty sure that's why Extension Headers exist.
Someone would be directed to RFC 2460 section 4 and asked to explain why that
wouldn't work for their pet idea. This draft's authors have the same burden of
proof as far as I am concerned.
And no,
"...extension headers are not examined or processed
by any node along a packet's delivery path..."
is not a good enough reason in and of itself, because one would still have to
convince people (specifically router vendors and SPs) that this set of bits is
so important that routers in the middle of the path would need to slow down
their processing or build silicon to look at it (and take some action) at
linerate. Yes, I realize that the same issue exists for any existing use of FL
that is on the table, but at least there's a reasonable justification for that
as being integral to high-scale packet forwarding.
It is hard for me to guess all the future uses, but I will take one
probable use case: re-ECN. This mechanism requires certain characteristics
a) All nodes in the path must be able to see and modify markings
b) The packet needs to go through nodes on the path that do not support
this mechanism (re-ECN), without getting dropped.
c) The presence of the markings should not significantly affect the
processing of the packets containing them.
Extension headers may not be a good choice because they do not fulfil a)
and a new kind of extension header that fulfils a) will not fulfil b).
And as you rightly said it would be difficult to convince all SPs on the
path and hence incremental deployment becomes important, thus
necessitating b).
Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
