Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-data

["Frank Brockners (fbrockne)" <[e-mail]>]

Hi Al,

Many thanks for serving as doc shepherd and for your comments.

Please see inline (“…FB”)

From: ippm <[e-mail]> On Behalf Of MORTON, ALFRED C (AL)
Sent: Sonntag, 31. Mai 2020 17:28
To: Tommy Pauly <tpauly=[e-mail]>; IETF IPPM WG <[e-mail]>; [e-mail]
Subject: Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-data

Hi Tommy and Draft ioam-data Authors,

After completing one pass through the memo in the role of Doc Shepherd,
I ended-up with a few comments that are more like WGLC comments than
those of the shepherd.  Since we are only a few days over WGLC closure,
I have uploaded the preliminary shepherd write-up and share
the comments for optional action below (I don’t think these comments
should have any special status, IOW).

It is clear that lots of work an negotiation went into the present text.
I appreciate that fact and thank all who participated for preparing
an excellent draft.

The current shepherd’s write-up [0] is available for comment, as well.

Al
(as doc shepherd)

[0] https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/shepherdwriteup/


Doc Shepherd's Comments:

Closed PR https://github.com/inband-oam/ietf/pull/96
Two Comments indicate the value of a Manageability Considerations section while resolving issues in the discussion. However, the -09 version still does not have this section a year later... The important topic discussed was congestion management, but there are no instances of "congest" in the -09 text.  (more, see below)

Section 3, Scope, etc. contains the topic:
Deployment domain (or scope) of in-situ OAM deployment:, in which many operational considerations are detailed that could be part of a Manageability Considerations: section.

…FB: Deployment and Manageability is a pretty wide topic. This is why we created a dedicated document for it:
https://tools.ietf.org/html/draft-brockners-opsawg-ioam-deployment-01. Are you ok if we continue to keep it as a dedicated document, or should we consider to replicate information from draft-brockners-opsawg-ioam-deployment into draft-ietf-ippm-ioam-data? Personally I’d prefer to avoid replication between documents.

4.4 Trace Option types
...
   ...The maximum number of hops and the minimum path MTU of the IOAM domain is assumed
   to be known.

What are the consequences when they are not known?
     Looks like the Flag Bit 0 O-bit handles this case for number of hops.  (Add this here?)
…FB: Good point. We can add a sentence stating that the O-bit is there to deal with situations where the PMTU was underestimated, i.e. where the number of hops which are IOAM capable exceeds the available space in the packet.

Or, is this knowledge highly likely, and expected to be violated only under the most unexpected conditions (restoration from multiple failures)?
See point below on "minimum path MTU".

4.4.1
RemainingLen:
...
      Given that the sender knows the minimum path MTU, the sender MAY
      set the initial value of RemainingLen according to the number of
      node data bytes allowed before exceeding the MTU.
"minimum path MTU" is the smallest Maximum Transmission Unit for all links in a path, or simply the Path MTU, PMTU, right?
https://en.wikipedia.org/wiki/Path_MTU_Discovery

…FB: Good catch – sloppy language indeed. Let’s do s/minimum path MTU/PMTU/

4.5 Proof of Transit

Is there a Reference for "Shamir's Secret Sharing Schema (SSSS)" ?
Or, is it a secret?

…FB: We’ll add a reference to https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing like we did in the PTO draft.  Martin caught the glitch as well.


7.  IANA Considerations
(apologies in advance for a long/recent/good experience with IANA, and the many other folks who try to help our friends at IANA)
This section appears to define a set of related registries.
The hierarchy could be named a bit more efficiently than:

7.1 In-Situ OAM Protocol Parameters Registry (IOAM) Protocol Parameters IANA registry

Suggest:
In-Situ OAM (IOAM) Protocol Parameters Group
7.1  IOAM Protocol Parameters Registry
     7.2  IOAM Option-Type Registry
     7.3  IOAM Trace-Type Registry
       ...
…FB: Thanks for the great suggestion.

Thanks again, Frank

From: ippm [mailto:[e-mail]] On Behalf Of Tommy Pauly
Sent: Thursday, May 28, 2020 12:43 PM
To: Tommy Pauly <tpauly=[e-mail]<mailto:tpauly=[e-mail]>>; IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-data

Our WGLC call for draft-ietf-ippm-ioam-data is now concluded! Thanks everyone.

I’ve marked the document as having WG consensus, and needing a revised I-D (to incorporate Martin’s comments). Once that is ready and we have the shepherd write-up, we’ll submit this to the IESG.

As a reminder, we are still in the WGLC for draft-ietf-ippm-stamp-option-tlv. Please review and comment if you have not already!

Thanks,
Tommy

On May 14, 2020, at 10:16 AM, Tommy Pauly <tpauly=[e-mail]<mailto:tpauly=[e-mail]>> wrote:

Hi IPPM,

At our virtual interim meeting, we decided to put draft-ietf-ippm-ioam-data through a second last call, based on the new revisions, in mid-May. This email starts a two-week WGLC for this draft.

The latest version can be found here: https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-09<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dioam-2Ddata-2D09&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=YwMkvN3mqHRxnwcgkB4l4psDqQViP1UTeOxJeyv5T7k&s=_Lv2krlY6UiX1GbDsvMqDhkXEWZf66f0UkBcR3O3csg&e=>

This last call will end on Thursday, May 28. Please reply to [e-mail]<mailto:[e-mail]> with your reviews and comments.

Thanks,
Tommy & Ian
_______________________________________________
ippm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwQFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=YwMkvN3mqHRxnwcgkB4l4psDqQViP1UTeOxJeyv5T7k&s=BSOHsMgZ_JR-B6_CAnlIGEEoEv1CXcvWQ-vOS7UsHRg&e=>