Subject: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT)

From: Suresh Krishnan <[email-masked]>
Date: Tue, 11 Apr 2017 12:08:23 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-ippm-6man-pdm-option-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

* Section 3.2.1.
  The option length seems to be wrong here. This will make the parser
parse incorrectly onto a following option or worse. I think this MUST be
set to 10 instead of 16 (Or some field is missing from the description of
the option)

   8-bit unsigned integer. Length of the option, in octets, excluding
   the Option Type and Option Length fields. This field MUST be set to
   16.

* Section 3.2.1.
  The option does not seem to state an alignment requirement, but I think
one is required to properly align the multi-byte PSN and Delta fields.
Can you please specify one.

* Section 5

The IANA considerations section needs to be more specific as you are
requesting a specific type of option.

e.g. This draft requests an Destination Option Type assignment with
   the act bits set to 00 and the chg bit set to 0 from the ...

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* Section 1.6

I am not sure where this inference comes from. Can you please clarify?

It is likely that an IPv6 packet containing PDM will be dropped if using
IPv6 transition technologies.

* Section 3.1

This text is not correct as the PDM option is not an implementation of
the Destination options *header*.

The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) is
an implementation of the Destination Options Header.

Suggest rewording to 

The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) is
implemented as an IPv6 Option carried in the Destination Options Header.

---

From: <[email-masked]>
Date: Wed, 12 Apr 2017 01:44:36 +0000 (UTC)

Suresh,

I am only responding to the DISCUSS section below.

Nalini

--------------------------------------------
On Tue, 4/11/17, Suresh Krishnan <[email-masked]> wrote:

 Subject: Suresh Krishnan's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT)
 To: "The IESG" <[email-masked]>
 Cc: [email-masked], "Al Morton" <[email-masked]>, "Bill Cerveny" <[email-masked]>, [email-masked], [email-masked], [email-masked]
 Date: Tuesday, April 11, 2017, 12:08 PM
 
 > Suresh Krishnan has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: Discuss
 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions.
 
> The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/

> * Section 3.2.1.   The option length seems to be wrong here. This will make the parser parse incorrectly onto a following option or worse. I think this MUST be set to 10 instead of 16 (Or some field
> is missing from the description of the option)
 
>   8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 16.

You are correct.  The option length is 10 not 16.   I will fix that.

> * Section 3.2.1.
>  The option does not seem to state an alignment requirement, but I think one is required to properly align the multi-byte PSN and Delta fields.

The alignment for PSN and delta fields follows the alignment requirements for all extension headers.

>From RFC2460, I see:

Each extension header is an integer multiple of 8 octets long, in order to retain 8-octet alignment for subsequent headers.  Multi-octet fields within each extension header are aligned on their
natural boundaries, i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n = 1, 2, 4, or 8.

The PSN and Delta fields are all on a half-word boundary.   So, I think we are OK.   Do you think I should restate the above in the draft?

> The IANA considerations section needs to be more specific as you are requesting a specific type of option.
 
>  e.g. This draft requests an Destination Option Type assignment with the act bits set to 00 and the chg bit set to 0 from the ...

Current Text
----------------

5 IANA Considerations

   This draft requests an Option Type assignment in the Destination Options and Hop-by-Hop Options sub-registry of Internet Protocol
   Version 6 (IPv6) Parameters [ref to RFCs and URL below].

   http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

Hex Value      Binary Value      Description             Reference 
                       act chg rest
   -------------------------------------------------------------------  
   TBD             TBD            Performance and          [This draft]
                                          Diagnostic Metrics 
                                         (PDM)          

New Text
----------------

5 IANA Considerations

   This draft requests a Destination Option Type assignment with the act bits set to 00 and the chg bit set to 0
   from the Destination Options and Hop-by-Hop Options sub-registry of Internet Protocol
   Version 6 (IPv6) Parameters [ref to RFCs and URL below].

   http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

Hex Value      Binary Value      Description             Reference 
                       act chg rest
   ------------------------------------------------------------------------------------  
   TBD             00   0    TBD     Performance and          [This draft]
                                                Diagnostic Metrics 
                                                (PDM)

---

From: <[email-masked]>
Date: Wed, 12 Apr 2017 19:14:56 +0000 (UTC)

Suresh,

Sorry for the top post.   I am responding to your comment on alignment.

I looked again and RFC2460 says: (in the Extension Header section)

4.2  Options

  Two of the currently-defined extension headers -- the Hop-by-Hop  Options header and the Destination Options header -- carry a variable number of type-length-value (TLV) encoded "options", of the following
  format:

          ...

  Individual options may have specific alignment requirements, to ensure that multi-octet values within Option Data fields fall on natural boundaries.  The alignment requirement of an option is
  specified using the notation xn+y, meaning the Option Type must appear at an integer multiple of x octets from the start of the header, plus y octets.  For example:

      2n    means any 2-octet offset from the start of the header.
      8n+2  means any 8-octet offset from the start of the header,  plus 2 octets.

In PDM, what we have is:

 Alignment: 2n =  Scale Delta Time Last Received (SCALEDTLR, 1 octet)
 Alignment: 3n =  Scale Delta Time Last Sent (SCALEDTLS, 1 octet)
 Alignment  4n =  Packet Sequence Number This Packet (PSNTP, 2 octets)
 Alignment  6n  = Packet Sequence Number Last Received (PSNLR, 2 octets)
 Alignment  8n  =  Delta Time Last Received (DELTATLR, 2 octets)
 Alignment 10n =  Delta Time Last Sent (DELTATLS, 2 octets)
 
 With the entire header being 12 bytes.  But in the length code should be= 10 = 12 - 2 (taking out option type and length)

I will also redo the Figure to take out the numbering as the Figure implies word boundaries that may not exist in reality. 

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

--------------------------------------------
On Tue, 4/11/17,  <[email-masked]> wrote:

 Subject: Re: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT)
 To: "The IESG" <[email-masked]>, "Suresh Krishnan" <[email-masked]>
 Cc: [email-masked], "Bill Cerveny" <[email-masked]>, [email-masked], [email-masked], [email-masked]
 Date: Tuesday, April 11, 2017, 6:44 PM
 
 Suresh,
 
 I am only responding to the DISCUSS
 section below.
 
 Nalini
 
 --------------------------------------------
 On Tue, 4/11/17, Suresh Krishnan <[email-masked]>
 wrote:
 
  Subject: Suresh Krishnan's Discuss on
 draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and
 COMMENT)
  To: "The IESG" <[email-masked]>
  Cc: [email-masked],
 "Al Morton" <[email-masked]>,
 "Bill Cerveny" <[email-masked]>,
 [email-masked],
 [email-masked],
 [email-masked]
  Date: Tuesday, April 11, 2017, 12:08
 PM
  
  > Suresh Krishnan has entered the
 following ballot position for
 draft-ietf-ippm-6man-pdm-option-09: Discuss
  
 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
 for more information about IESG DISCUSS and COMMENT
 positions.
  
 > The document, along with other
 ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/
  
 > DISCUSS:
  >
  
 > * Section 3.2.1.   The option
 length seems to be wrong here. This will make the parser
 parse incorrectly onto a following option or worse. I think
 this MUST be set to 10 instead of 16 (Or some field
  
 >   8-bit unsigned integer. Length
 of the option, in octets, excluding the Option Type and
 Option Length fields. This field MUST be set to 16.
 
 You are correct.  The option length is
 10 not 16.   I will fix that.

 > * Section 3.2.1.
 >  The option does not seem to
 state an alignment requirement, but I think one is required
 to properly align the multi-byte PSN and Delta fields.
 > Can you please specify one.
 
 The alignment for PSN and delta fields
 follows the alignment requirements for all extension
 headers.
 
 >From RFC2460, I see:
 
 Each extension header is an integer
 multiple of 8 octets long, in order to retain 8-octet
 alignment for subsequent headers.  Multi-octet fields
 within each extension header are aligned on their
 natural boundaries, i.e., fields of
 width n octets are placed at an integer multiple of n octets
 from the start of the header, for n = 1, 2, 4, or 8.
 
 The PSN and Delta fields are all on a
 half-word boundary.   So, I think we are OK.   Do
 you think I should restate the above in the draft?

 > The IANA considerations section
 needs to be more specific as you are requesting a specific
 type of option.
  
 >  e.g. This draft requests an
 Destination Option Type assignment with the act bits set to
 00 and the chg bit set to 0 from the ...
 
 Current Text
 ----------------
 
 5 IANA Considerations
 
    This draft requests an Option
 Type assignment in the Destination Options and Hop-by-Hop
 Options sub-registry of Internet Protocol
    Version 6 (IPv6) Parameters
 [ref to RFCs and URL below].

 Hex Value      Binary
 Value      Description     
        Reference 
          
              act chg rest

    TBD       
      TBD           
 Performance and          [This
 draft]

 Diagnostic Metrics 

 (PDM)          

 New Text
 ----------------
 
 5 IANA Considerations
 
    This draft requests a
 Destination Option Type assignment with the act bits set to
 00 and the chg bit set to 0
    from the Destination Options
 and Hop-by-Hop Options sub-registry of Internet Protocol
    Version 6 (IPv6) Parameters
 [ref to RFCs and URL below].

 Hex Value      Binary
 Value      Description     
        Reference 
          
              act chg rest

    TBD       
      00   0    TBD    
 Performance and          [This
 draft]

       Diagnostic Metrics 

       (PDM)         

 
 _______________________________________________
 ippm mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/ippm