Subject: Re: Review of draft-ietf-mpls-residence-time-12

From: Greg Mirsky <[email-masked]>
Date: Fri, 13 Jan 2017 10:11:57 -0800

Hi Jurgen,
thank you for the thorough review and the most detailed and helpful
comments.
We're preparing -13 version and will address your comments promptly. Please
find my responses in-lined and tagged GIM>>.

Regards,
Greg

On Fri, Jan 13, 2017 at 12:47 AM, <"Jürgen Schönwälder
<j.schoenwaelder@jac"@ietfa.amsl.com> wrote:

> Reviewer: Jürgen Schönwälder
> Review result: Has Nits
>
> I do not see any major OPS related issues. I am not an MPLS expert
> and
> this will likely show in my comments. Most of my comments below are
> editorial or trying to make the document easier to read for first
> time
> readers not deeply involved in the work.
>
> - Consider to avoid acronyms in the Abstract. I had to lookup what
>   G-ACh and PTP resolve to in order to read the abstract, which I
>   think should be avoided.
>
GIM>> Will use full versions in the Abstract.

>
> - The sentence starting 'I.e.' in parenthesis in the Introduction
>   almost reads like a definition of Residence Time. Is it useful to
>   have this sentence in parenthesis and starting with 'I.e.'? It
> would
>   be nice to have a clear definition of Residence Time. In fact, my
>   reading is that residence time sometimes refers to the per hop
>   residence them and sometimes to the accumulated per path residence
>   time. Does it make sense to distinguish a Node Residence Time from
> a
>   Path Residence Time? Or a Residence Time from an Accumulated
>   Residence Time?
>
GIM>> Perhaps if parenthesis removed and the sentence starts with
"Residence Time can be calculated as the sum ..."

>
> - While reading section 3, I was wondering what are 1-step nodes and
>   what are 2-step nodes? This is later explained in detail inq
> section
>   7. Perhaps it makes sense to introduce the concept earlier and to
>   provide a forward pointer to section 7 for the details.
>
GIM>> Will try to re-arrange the text to make the flow more logical.

>
> - I suggest to either always write one-step and two-step or 1-step
> and
>   2-step. Mixing writing styles makes searching in the text a bit
> more
>   complicated.
>
GIM>> Will pick and use one form throughout the document.

>
> - The document seems to be PTP specific even though there are
>   provisions to support other time synchronization protocols. I
>   wonder, though, to what extend this would work for lets say NTP.
>   There is quite some text refering to the correctionField, which
>   seems to be a PTP-specific field.
>
GIM>> Yes, NTP doesn't use residence time and thus no need for
correctionField. We assume that there may be interest in using RT by NTP at
some time.

>
> - s/Scratch Pad filed/Scratch Pad field/
>
GIM>> Great catch, thank you!

>
> - Does the Interface ID related to other interface numbers, e.g.,
>   SNMP's ifIndex? Or is this an entirely separate number space? Or
>   does it depend on the implementor's choice?
>
GIM>> This comes from PTP. AFAIK, it is different from SNMP index.

>
> - In section 7, enumerated item 1, there is a hanging open
> parenthesis
>   which seem to have to sub-items inside. I suggest to change this by
>   s/forthcoming (this/forthcoming. This/
>
GIM>> Accepted, thank you.

>
> - In section 8.3: s/.  .  /.  /
>
GIM>> Done

>
> - It may be useful to add instructions that the RFC editor is
> expected
>   to replace TBAx in the text once IANA has done the assignments.
>
> - What does 'particularly as applied to use related to PTP' mean?
>
GIM>> My interpretation would be "when used to measure the residence time
on behalf of PTP"

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 13 Jan 2017 20:55:07 +0100

> GIM>> This comes from PTP. AFAIK, it is different from SNMP index.

If this is specifically a PTP Interface ID, it might be desirable to
be explicit about this and that it may be different from other numeric
interface IDs. (This is what I heard you saying, I do not know much
about PTP and surely not any details how PTP defines Interface IDs.

/js

PS: This was actually the only operational comment I had. From an
    operational perspective, it is important to know whether interface
    numbers us a common or possibly different numbering scheme.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 16 Jan 2017 10:01:26 -0800

Hi Jurgen,
I apologize for confusion, been thinking of Port ID. Indeed, the Interface
ID is local ID and used in case of unnumbered interface as described in
section 4.7.1.3:

   Interface ID
      The identifier assigned to the link by the node specified by the Node ID.

Thus it MAY be SNMP' IfIndex , as you've pointed out. The document
leaves it to the implementation.

Regards,

Greg

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 18 Jan 2017 08:15:18 -0800

Hi Jurgen,
I've prepared updated version and would greatly appreciate if you review
the changes and let us know whether your comments been addressed. Attached
are diff and the new version.

Regards,
Greg