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

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi Suresh, thanks for your Saturday reply!
small suggestion on your revised wording, below.

From: Suresh Krishnan [mailto:[e-mail]]
Sent: Saturday, June 30, 2018 1:05 PM
To: MORTON, ALFRED C (AL) <[e-mail]>
Cc: Spencer Dawkins at IETF <[e-mail]>; [e-mail]; [e-mail]; The IESG <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-2330-ipv6-05: (with DISCUSS and COMMENT)

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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dgont-2Dv6ops-2Dipv6-2Dehs-2Dpacket-2Ddrops-2D03&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=Czq1H91sahX_Xr5bhh1wFAz_6pHVNOlQBXHGVYJ1TRs&s=oGtdxvB-rRQROdp6QAlrpK1Pf7eak6QhZlZM79X_YB8&e=>
https://tools.ietf.org/html/draft-wkumari-long-headers-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwkumari-2Dlong-2Dheaders-2D03&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=Czq1H91sahX_Xr5bhh1wFAz_6pHVNOlQBXHGVYJ1TRs&s=Ku7IRBA-BcYWZcpyLXeYAPIVgeR4lkPGrJ8I9GgwiRQ&e=>
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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dvoyer-2D6man-2Dextension-2Dheader-2Dinsertion-2D04-23section-2D4&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=Czq1H91sahX_Xr5bhh1wFAz_6pHVNOlQBXHGVYJ1TRs&s=Uk4ArKYJMqSuuPqClTWhyr5KslU6lcnl4DjXoGwoxh8&e=>
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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7872&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=Czq1H91sahX_Xr5bhh1wFAz_6pHVNOlQBXHGVYJ1TRs&s=kLDaw7VEGngq9JbycuGXq3kGShpFRMGDnbkTE4oQ-0U&e=>

We could infer an issue from the RFC 7112 Header Chain limitations:
https://tools.ietf.org/html/rfc7112#section-5<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7112-23section-2D5&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=Czq1H91sahX_Xr5bhh1wFAz_6pHVNOlQBXHGVYJ1TRs&s=HwcTmqzzKyOAtb7cvx0PdyzmGxEyBtABsCoLGIyiCdA&e=>
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.
[acm]
I think it’s fine to remove the RFC 7112 reference
(not necessary to infer the MTU issue).
I have the impression that ICMPv6 error messages
only fail to reach the original Source when certain
routing-related EH are activated (SRH in draft-voyer).
So, I’m inclined to retain one general example of
the insertion issue, as we proposed on Friday:

NewNew:
There are issues with Extension Header insertion and
deletion of course, such as exceeding the path MTU due
to insertion, etc.

I’ll submit the draft as above, with all other changes
implemented, and we can iterate one more time if necessary.

thanks!
Al

** 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