Re: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-2330-ipv6-05: (with DISCUSS and COMMENT)

[Suresh Krishnan <[e-mail]>]

Hi Al,

On Jun 29, 2018, at 4:35 PM, MORTON, ALFRED C (AL) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Suresh,

As this week draws to a close, let me provide the current status
on your DISCUSS.

Rather than wait for a text suggestion**, the co-authors exchanged
many messages as we researched the topic from your DISCUSS:
“...describe potential issues that may occur due to header insertion/deletion.”
We proposed that a few concise references and a sentence to introduce
them might be sufficient.

Since this is a topic where consensus is evolving,
the co-authors agreed that we should not propose any
text or references that others might see as controversial
(and move us further from everyone’s goal of approval).

Instead, we sought sources/lists of issues that have been vetted,
such as those published as an RFC or a peer-reviewed conference paper
by someone with a prominent reputation in this field.

We found many Internet Drafts that identify general issues related to EH:
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03
https://tools.ietf.org/html/draft-wkumari-long-headers-03
Also, this draft that presents issues specific to the SRH proposal:
https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-04#section-4
But Individual drafts that raise issues aren’t agreed at any level.
We looked at many e-mails and other items, too.

OTOH, there is some of evidence of strained EH-compliance
found through measurements:
https://tools.ietf.org/html/rfc7872

We could infer an issue from the RFC 7112 Header Chain limitations:
https://tools.ietf.org/html/rfc7112#section-5
where inserting any new EH at an intermediate node could exceed the PMTU.
But the EH insertion/deletion issue is not discussed in the RFC text.

The current Bullet item reads:

   o  Extension Header insertion or deletion: Although such behavior is
      not endorsed by current standards, it is possible that Extension
      Headers could be added to, or removed from the header chain.  The
      resulting packet may be standard-formed, with a corresponding
      Type-P.

We propose to append:

This point simply encourages measurement system designers to be prepared
for the unexpected, and to notify users when such events occur.
There are issues with Extension Header insertion and deletion,
such as exceeding header chain size limitations, like those
described in [RFC7112], of course.

Let us know what you think,
Al, for the co-authors

I was working on text that was along similar lines (expect the unexpected) and I believe your text proposal strikes the right balance in this regard. Thanks! I will clear right away when this new text is added. I would prefer removing the reference to 7112 as it is not directly related to insertion at intermediate points and make the following minor change (but I will leave it to your discretion whether to take this suggestion or not)

OLD:
There are issues with Extension Header insertion and deletion,
such as exceeding header chain size limitations, like those
described in [RFC7112], of course.

NEW:
There are issues with Extension Header insertion and deletion,
such as exceeding path MTUs due to insertion, inability of the
original packet initiator to react to ICMPv6 error messages etc.,
of course.


** We saw Mike Heard’s suggestion, but we felt it didn’t address your
DISCUSS directly, and didn’t meet our criteria to avoid more controversy.

Yep. That I figured it was probably too controversial for you as well.

Regards
Suresh