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

[Suresh Krishnan <[e-mail]>]

Hi Al,
  Thanks for the quick reply. Please find comments inline.

On Jun 21, 2018, at 10:23 AM, MORTON, ALFRED C (AL) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Suresh,
Thanks for your review.
Please see the discussion below.
We have things to talk about.

Al

...
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

* Section 4

Since this behavior is clearly forbidden in RFC8200
[acm]
Although much of the IETF community shares your view,
"forbidden" is much too strong a word to describe this
sentence/statement in RFC8200

  Extension headers (except for the Hop-by-Hop Options header) are not
  processed, inserted, or deleted by any node along a packet's delivery
  path, until the packet reaches the node (or each of the set of nodes,
  in the case of multicast) identified in the Destination Address field
  of the IPv6 header.

"are not" would not translate to "forbidden" in any SDO I know.
I understand that some folks proposed to update the wording to 2119
terms, and were found to be in the rough.

Actually, the lack of 2119 language in RFC8200 is completely unrelated to this issue. We, in the IETF, do not require standards track documents to use 2119 language (IMHO, I think this is unfortunate and that we should!). The reason header insertion was not allowed in RFC8200 was because the proponents of header insertion could not describe how to do header insertion safely on the internet and were not willing to scope the header insertion to private networks. I do not have a religious position on this and I summarized my position in a mail to the 6man list on this issue (https://www.ietf.org/mail-archive/web/ipv6/current/msg27336.html).

"I have heard from several persons being concerned about the possibility of new text in 2460bis being blindly used to block header insertion work in the future. I just want to confirm that header insertion work can be considered in the future, and that it should be judged on its own merits and not be blocked solely based on the header insertion related text in 2460bis."

When the ippm work hits the IESG, I (if I am still on it :-)) will hold that work to the same standard. There is some work ongoing (albeit very slowly) in 6man to specify safe header insertion

https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-03

and hopefully this work will complete before the in-situ OAM work will hit the IESG. If not, I see encapsulation and tight scoping as the only way forward on this issue.


Would someone outside IETF
reading RFC8200 interpret this sentence as an absolute requirement?
I won't list the many possible interpretations.


there is no need to add a
special case for this (as middleboxes perform any number of
transformations that not standards compliant).
[acm]
Right, but we would want to know those translations happened.
Keep in mind that IPPM is in the measurement business,
and our systems work better if we detect the unexpected.
So, If you are reading the bullet text below as some form of
encouragement to insert/delete headers, it is not.

Given that safe header insertion/deletion is a
hard problem that has not been solved, I would remove this text or
significantly augment it to describe potential issues that may occur due to
header insertion/deletion (similar to the sections related to 6lowpan and
translation).
[acm]
I think we would be glad to cite several references to cover
the potential issues that you provide, but this bullet point has real
value to the measurement community.

Yep. That would be a good way to address this DISCUSS point, because I will clear right away as long as the issues are put forth just like the extensive work you have done in Section 5 for the other *similar* transforms.



* Section 4

I think this text should be removed

  [RFC8250] endorses the use of IPv6 extension headers for measurement
  purposes, consistent with other approved IETF specifications.

as RFC8250 uses a destination option and defining new extension headers has
been explicitly recommended against by section 4.8 of RFC8200.
[acm]
Then how was RFC8250 approved? This RFC was developed in IPPM, too.
We are clearly not on the same page for this topic, and IPPM's
new charter including In-situ OAM may insert more space between us.

RFC8250 defines a new *destination option* and not a new extension header. That is why it was approved :-)

Thanks
Suresh