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

Robert Sparks <rjsparks@xxxxxxxxxxx> · Wed, 18 Jan 2017 12:34:11 -0600



    The changes all look good.
    I still think you should say something in the document about what
      "the time of packet arrival" and "transmission" means, and call
      out the point you made about being careful to not introduce
      apparent jitter by not making those measurements consistently.
      (The definitions you point to in your earlier mail from G.8013
      don't really help - they just say "time of packet arrival". Again,
      the first and last bit are likely to be several nanoseconds apart
      so I think it matters. Perhaps you're saying it doesn't matter as
      long as each node is consistent (there will be error in the
      residence time measurement, but it will be constant at each node,
      so the sum of errors will be constant, and the clocks will be ok?)
    Please look at the new first paragraph of section 2 - there's a
      mix of "as case" and "in case" that should be made consistent. I
      suspect it would be easiest to simply say "referred to as using a
      one-step clock" and "referred to as using a two-step clock" or
      similar.
    RjS

    
    On 1/18/17 12:03 PM, Greg Mirsky wrote:

    
      Hi Robert,
        Sasha Vainshtein came with elegant idea to address
          disconnection between discussion of one-step and two-step
          modes that you've pointed out. We've moved Section 7 as
          sub-section into Section 2 now. Attached are updated diff and
          the proposed new version -13.
        

        Regards,
        Greg
      
      
        On Wed, Jan 18, 2017 at 8:13 AM, Greg
          Mirsky <gregimirsky@xxxxxxxxx>
          wrote:

          
            Hi Robert,
              once again, thank you for your thorough review and
                the most detailed comments. 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
            
            
              On Wed, Jan 11,
                  2017 at 7:48 AM, Robert Sparks <rjsparks@xxxxxxxxxxx>
                  wrote:

                
                    Reviewer:
                      Robert Sparks

                      Review result: Ready with Nits

                      
                      I am the assigned Gen-ART reviewer for this draft.
                      The General Area

                      Review Team (Gen-ART) reviews all IETF documents
                      being processed

                      by the IESG for the IETF Chair.  Please treat
                      these comments just

                      like any other last call comments.

                      
                      For more information, please see the FAQ at

                      <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

                      
                      Document: draft-ietf-mpls-residence-time-12

                      Reviewer: Robert Sparks

                      Review Date: 2017-01-10

                      IETF LC End Date: 2017-01-17

                      IESG Telechat date: 2017-02-02

                      
                      Summary: Ready (with nits) for publication as a
                      Proposed Standard

                      
                      I have two primary comments. I expect both are
                      rooted in the authors

                      and working group knowing what the document means
                      instead of seeing

                      what

                      it says or doesn't say:

                      
                      1) The document is loose with its use of 'packet',
                      and where TTLs

                      appear when

                      they are discussed. It might be helpful to
                      rephrase the text that

                      speaks

                      of RTM packets in terms of RTM messages that are
                      encoded as G-ACh

                      messages and

                      not refer to packets unless you mean the whole
                      encapsulated packet

                      with MPLS

                      header, ACH, and G-ACh message.

                      
                      2) Since this new mechanic speaks in terms of
                      fractional nanoseconds,

                      some

                      discussion of what trigger-point you intend people
                      to use for taking

                      the

                      precise time of a packet's arrival or departure
                      seems warranted. (The

                      first and

                      last bit of the whole encapsulated packet above
                      are going to appear at

                      the

                      physical layer many nanoseconds apart at OC192
                      speeds if I've done the

                      math

                      right). It may be obvious to the folks discussing
                      this, but it's not

                      obvious

                      from the document.  If it's _not_ obvious and
                      variation in technique

                      is

                      expected, then some discussion about issues that
                      might arise from

                      different

                      implementation choices would be welcome.

                      
                      The rest of these are editorial nits:

                      
                      It would help to pull an overview description of
                      the difference

                      between

                      one-step and two-step much earlier in the
                      document. I suggest in the

                      overview

                      in section 2. Otherwise, the reader really has to
                      jump forward and

                      read section

                      7 before section 3's 5th bullet makes any sense.

                      
                      In section 3, "IANA will be asked" should be made
                      active. Say "This

                      document

                      asks IANA to" and point to the IANA consideration
                      section. Apply

                      similar

                      treatment to the other places where you talk about
                      future IANA

                      actions.

                      
                      There are several places where there are missing
                      words (typically

                      articles or

                      prepositions). You're less likely to end up with
                      misinterpretations

                      during the

                      RFC Editor phase if you provide them before the
                      document gets that far

                      in the

                      process. The spots I found most disruptive were
                      these (this is not

                      intended to

                      be exhaustive):

                      
                        Section 3: "set 1 according" -> "set to 1
                      according"

                        Section 3: "the Table 19 [IEEE..." -> "Table
                      19 of [IEEE..."

                        Section 4.2: "Detailed discussion of ... modes
                      in Section 7."

                                              -> "Detailed discussion
                      of ... modes appears

                      in Section 7."

                        Section 10: "most of" -> "most of all"

                      
                      In Setion 3.1 at "identity of the source port",
                      please point into the

                      document

                      that defines this identity and its representation.
                      I suspect this is a

                      pointer

                      into a specific section in IEEE.1588.2008].