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 21, 2018, at 12:30 PM, MORTON, ALFRED C (AL) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Suresh,
Thanks for your reply. We’re getting closer. Let’s keep going…

Excellent.


From: ippm [mailto:[e-mail]] On Behalf Of Suresh Krishnan
Sent: Thursday, June 21, 2018 11:40 AM
To: MORTON, ALFRED C (AL) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-2330-ipv6-05: (with DISCUSS and COMMENT)

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!).
[acm]
Yes, we heard this position on 2119 terms during the exchange
with 6man folks. IMO, it doesn’t help to take a fringe/exception position
when stating such an important requirement. As I said,
someone reading this “cold” is not going to see a requirement, and
so the IETF’ers have heavy baggage to carry – to explain this to
everyone who gets it wrong. This is one reason we need to be prepared
to detect this in measurement systems (and that’s the relationship,
ambiguous requirement wording will make this error more likely!).

OK. Fair enough.



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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_ipv6_current_msg27336.html&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=c0q9R673pxJFQtApvfYaAgkBdWTLaVGLE0njCE2DVl8&s=Y8OnjtPK9mZSD4B6zvXu932dgzCwYYfIMBwB1PJXwzQ&e=>)..

"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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dvoyer-2D6man-2Dextension-2Dheader-2Dinsertion-2D03&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=c0q9R673pxJFQtApvfYaAgkBdWTLaVGLE0njCE2DVl8&s=bHo-N2I44qQUiGNT3deL8lrmvmBLV0hGN_SNBYU4OOo&e=>

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.
[acm]
As I said above, we need some help here. We have already cited:

   The topic of IPv6 Extension Headers brings current controversies into
   focus as noted by [RFC6564<https://tools.ietf.org/html/rfc6564>] and [RFC7045<https://tools.ietf.org/html/rfc7045>].

in the sentences leading to this bullet list. If you (or others)
can provide additional references that describe the issues, then
it’s completely appropriate to include them, IMO. At the same
time, I hope you are not asking that we research and summarize
all discussions on Extension Header Insertion issues in this memo.
That’s well beyond our scope, and would seem to be better positioned
if the issues were cataloged in the Internet Area literature.

Sounds good. I will propose some text here. If that works for you, we can move past this.



* 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 :-)
[acm]
So, it seems our terminology needs reconciliation, too.
RFC8250 says
3.1.  Destination Options Header

   The IPv6 Destination Options extension header [RFC8200] is used to
   carry optional information that needs to be examined only by a
   packet's destination node(s).  The Destination Options header is
   identified by a Next Header value of 60 in the immediately preceding
   header and is defined in RFC 8200 [RFC8200].

and goes on to define the PDM DOH.

RFC 8200 (sec 4) says:
   A full implementation of IPv6 includes implementation of the
   following extension headers:

      Hop-by-Hop Options
      Fragment
      Destination Options
      Routing
      Authentication
      Encapsulating Security Payload

What subtlety of RFC8200 are we missing here?

I don’t see any contradiction in RFC8250. It creates an option for use in an existing extension header instead of creating a new extension header. I think the following text change proposal is both accurate and would make the intent clearer.

OLD:

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

NEW:

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

Regards
Suresh