Hi Ran,
On 11-04-17 04:54 PM, RJ Atkinson wrote:
Earlier, Hing-Kam Lam wrote:
I thought we were very close to the WG LC last time and
the new version is addressing all the points raised.
Unfortunately, the new version unfortunately does not address
my comments, or those of others with similar concerns about the
operational impacts of ANY new IPv6 headers on existing IPv6
deployments with routers containing silicon (e.g. ASIC, FPGA)
forwarding engines that parse/parse-past the currently defined
set of IPv6 headers and extensions.
As someone else noted recently on the IPv6 Ops list,
in the IETF words such as "SHOULD" or "SHOULD NOT" are
entirely ignorable. So those don't address my concerns.
As I've said before, I do think that with some specific edits
to tighten up the wording (e.g. using words such as "MUST NOT"
and requiring more specific justification & documentation
than in a normal standards-action if one proposes defining
any new IPv6 header), the draft could be edited into
a form where it would be widely agreeable.
The base IPv6 standard [RFC2460] allows the use of both extension
headers and destination options in order to encode optional
destination information in an IPv6 packet. The use of destination
options to encode this information, provides more flexible handling
characteristics and better backward compatibility than using
extension headers. Because of this, implementations SHOULD use
destination options as the preferred mechanism for encoding optional
destination information, and use a new extension header only if
destination options do not satisfy their needs. The request for
creation of a new IPv6 extension header MUST be accompanied by an
specific explanation of why destination options could not be used to
convey this information.
This was the text I have added in version -02 in response to your
comments. This text discourages creation of new extension headers and
recommends using an existing extension header (dest opts). What do you
think is missing here?
I provided specific suggestions in the past on this,
which I don't see reflected in the latest text. Perhaps
I've overlooked something. I am on travel, which means
that I am both short of time and have VERY limited Internet
access.
I will try to propose some specific edits to this draft,
but I doubt I will be able to post a note to this list
with those proposed edits until end of week (at earliest).
OK. I will look forward to your proposal.
Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
