RE: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

["Pengshuping (Peng Shuping)" <[e-mail]>]

Hi Bob, Gorry,

Thank you for the updates!

First, I have some questions on the "Hdr Ext Len" described in RFC8200 as below.
What is the intention to have the sentence "not including the first 8 octets"?
Does "the first 8 octets" include the "Next Header" 1 octet, "Hdr Ext Len" 1 octet, "Option Type" 1 octet, and "Opt Data Len" 1 octet, in total 4 octets?

      Hdr Ext Len         8-bit unsigned integer.  Length of the
                          Hop-by-Hop Options header in 8-octet units,
                          not including the first 8 octets.

As described in RFC8200 as below, the length of the options is to make the complete Hop-by-Hop Options header an integer multiple of 8 octets long.
So considering the description above, if the first option is 4 octets long, does that mean the "Hdr Ext Len" is zero?
If the first option is 8 octets long, does that mean it has to have a 6-octet padding?

      Options             Variable-length field, of length such that the
                          complete Hop-by-Hop Options header is an
                          integer multiple of 8 octets long.  Contains
                          one or more TLV-encoded options, as described
                          in Section 4.2<https://datatracker.ietf.org/doc/html/rfc8200#section-4.2>.

In this new draft, I have some questions on the length of the new HBH options in this draft.


   *  Fixed size in 8-octet units.  Specifically any new Hop-by-Hop

      options should not be variable size that could extend beyond what

      can be executed in the Fast Path.

"Fixed size in 8-octet units": does that mean it has a fixed size that is 8 octets? Or an integer multiple of 8 octets long? Because in RFC8200, it is also written as "Length of the Hop-by-Hop Options header in 8-octet units".

Is what you meant to say that the first option should have a fixed size that is 8 octets?

You do have this specification in Section 5.1 of the new draft "This field specifies the length of the Option Header in 8-octet units." which means that it is not changed compared to RFC8200.

So if the first option has a fixed size in 8 octets, considering the above specification in RFC8200, does that mean it has to always have a 6-octet padding when there is only one option?

In Section 10, there is "Removed requirement for HBH Option size and alignment". Do you mean that in RFC8200 the length of options needs to make the HBH header an integer multiple of 8 octets long, but now you only define the length of the option itself as a fixed size value, 8 octets? But again you keep the "the length of the Option Header in 8-octet units"...


Nit:
page 5 - would have be processed -> would have been processed
page 7 - at least one node on the patch -> at least one node on the path
page 8 - it's function -> its function; it's usage -> its usage; it's use -> its usage; it's processing -> its processing
page 9 - it can be proceed -> it can be proceeded

Best regards,
Shuping


From: ipv6 [mailto:[e-mail]] On Behalf Of Bob Hinden
Sent: Thursday, June 3, 2021 2:31 AM
To: IPv6 List <[e-mail]>
Cc: Gorry Fairhurst <[e-mail]>; Bob Hinden <[e-mail]>
Subject: Fwd: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

Hi,

We posted a new version of draft-hinden-6man-hbh-processing.    The changes include:

   *  Expanded terminology section to include Forwarding Plane and
      Control Plane.
   *  Changed draft that only one HBH Option MUST be processed and
      additional HBH Options MAY be processed based on local
      configuration.
   *  Clarified that all HBH options (with one exception) must be
      processed on the Fast Path.
   *  Kept the Router Alert options as the single exception for Slow
      Path processing.
   *  Rewrote and expanded section on New Hop-by-Hop Options.
   *  Removed requirement for HBH Option size and alignment.
   *  Removed sections evaluating currently defined HBH Options.
   *  Added content to the Security Considerations section.
   *  Added people to the acknowledgements section.
   *  Numerous editorial changes

We think this resolves most of the issues raised on the list and at the pervious IETF meeting.

Please review and comment on the list.

Bob & Gorry


Begin forwarded message:

From: [e-mail]<mailto:[e-mail]>
Subject: New Version Notification for draft-hinden-6man-hbh-processing-01.txt
Date: June 2, 2021 at 11:27:07 AM PDT
To: "Robert M. Hinden" <[e-mail]<mailto:[e-mail]>>, "Godred Fairhurst" <[e-mail]<mailto:[e-mail]>>, "Gorry Fairhurst" <[e-mail]<mailto:[e-mail]>>, "Robert Hinden" <[e-mail]<mailto:[e-mail]>>


A new version of I-D, draft-hinden-6man-hbh-processing-01.txt
has been successfully submitted by Robert M. Hinden and posted to the
IETF repository.

Name:             draft-hinden-6man-hbh-processing
Revision: 01
Title:        IPv6 Hop-by-Hop Options Processing Procedures
Document date:    2021-06-02
Group:            Individual Submission
Pages:             13
URL:            https://www.ietf.org/archive/id/draft-hinden-6man-hbh-processing-01.txt
Status:         https://datatracker.ietf.org/doc/draft-hinden-6man-hbh-processing/
Html:           https://www.ietf.org/archive/id/draft-hinden-6man-hbh-processing-01.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-hinden-6man-hbh-processing
Diff:           https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-hbh-processing-01

Abstract:
  This document specifies procedures for how IPv6 Hop-by-Hop options
  are processed.  It modifies the procedures specified in the IPv6
  Protocol Specification (RFC8200) to make processing of IPv6 Hop-by-
  Hop options practical with the goal of making IPv6 Hop-by-Hop options
  useful to deploy and use in the Internet.  When published, this
  document updates RFC8200.




The IETF Secretariat