FC Frame Encapsulation Technical Comments & Proposed Resolutions

[Ralph Weber <[e-mail]>]

This message reviews the Technical Comments provided
during Working Group Last Call for:

   FC Frame Encapsulation
   draft-ietf-ips-fcencapsulation-06.txt

A description of all the Working Group Last Call comments can be
found at:

http://www.ietf.org/internet-drafts/draft-ietf-ips-fcencap-wglc-00.pdf
http://www.ietf.org/internet-drafts/draft-ietf-ips-fcencap-wglc-00.txt

The PDF document is highly recommended because it contains:

 * Bookmarks to help you find comments by number
 * Color coding to help you get your bearings in the
   barrage of letters and white space

A proposed resolution is provided for every Technical Comment listed
in this message.

IF YOU WISH TO DEBATE A PROPOSED RESOLUTION
  please start a new list thread with the comment number in the subject
  Thanks for your help in this regard.

The chairs are hereby requested to follow the discussion of the
resolutions for these comments and act to identify consensus
as quickly as possible.

Thanks.

Ralph...

1. Comments from David Black
   =========================

Comment 5 Technical

   -- Section 3 - The FC Encapsulation Header
   -- Section 3.1 - FC Encapsulation Header Format

      The values in the Protocol# field are assigned by
      IANA [8]. The following values are known to be in use:

       - FCIP -- TO BE ASSIGNED by IANA
       - iFCP -- TO BE ASSIGNED by IANA

   [T] Delete the text starting with "The following values" and insert
   a forward reference to the IANA Consideration section.

   Accepted as written.


Comment 6 Technical

   -- Section 3 - The FC Encapsulation Header
   -- Section 3.1 - FC Encapsulation Header Format

      FC Encapsulation receivers may compare the Protocol# and -Protocol#
      fields as an additional verification that an FC Encapsulation
      Header is being processed.

      FC Encapsulation receivers may compare the Version and -Version
      fields as an additional verification that an FC Encapsulation
      Header is being processed.

   [T] Those "may"s are misleading. I think "SHOULD" is appropriate, but
   I could accept "SHOULD"s that only applied when the CRC is not valid.

   Accepted as follows

   Replace the two cited sentences with:

      FC Encapsulation receivers SHOULD either validate the CRC or
      compare the Protocol# and -Protocol# fields to verify that an
      FC Encapsulation Header is being processed according to a
      policy defined by the encapsulating protocol.

      FC Encapsulation receivers SHOULD either validate the CRC or
      compare the Version and -Version fields to verify that an
      FC Encapsulation Header is being processed according to a
      policy defined by the encapsulating protocol.

   As per comment 8, sentences similar to those shown above will be
   added to the -Flags and -Frame Length descriptions.


Comment 7 Technical

   -- Section 3 - The FC Encapsulation Header
   -- Section 3.1 - FC Encapsulation Header Format

      Flags (bits 31-26 in word 3): The Flags bits provide information
      about the usage of the FC Encapsulation Header as shown in figure
      3.

      Note: Implementers are advised to consult the specifications of
      protocols that use this header to determine how each individual
      protocol uses the bits in the Flags field.

   [T] The "Note:" paragraph is part of the CRCV issue (see below), and
   probably needs to be deleted as part of resolving that issue. This
   paragraph also has the additional problem in that it implies that
   protocol specific uses of the reserved flags are allowed, which is not
   the case.

   Accepted


Comment 8 Technical

   -- Section 3 - The FC Encapsulation Header
   -- Section 3.1 - FC Encapsulation Header Format

      Reserved (Flags, bits 31-27 in word 3): These bits are reserved for
      use by future versions of the FC Encapsulation and SHALL be set to
      zero on send. Protocols employing this encapsulation MAY require
      checking for zero on receive, however doing so has the potential to
      create incompatibilities with future versions of this
      encapsulation.

   [E] Second sentence is poorly worded. Suggested rewrite: Protocols
   employing this encapsulation SHOULD ignore the Reserved bits on
   receive in order to avoid creating incompatibilities with possible
   future versions of this encapsulation. I believe this change is
   editorial, and it also applies to the -Flags and -Frame Length fields.

   Rejected

   This change is not editorial. It is technical and specifically
   recommends against some of the validity checking described in FCIP.
   The working group argued this issue several times and (I thought)
   agreed that checking the version number was sufficient to know that
   the reserved flags must be zero.

   The last sentence of the comment is a misnomer with respect to the
   rest of the comment, however it makes sense when applied to comment 6.


Comment 9 Technical

   -- Section 3 - The FC Encapsulation Header
   -- Section 3.1 - FC Encapsulation Header Format

      CRCV (CRC Valid Flag, bit 26 in word 3): A CRCV bit value of one
      indicates that the contents of the CRC field are valid. A CRCV bit
      value of zero indicates that CRC are invalid. Some protocols may
      always check the CRC without regard for the state of this bit. The
      value of the CRCV bit SHALL be constant for all FC Encapsulation
      Headers sent on a given TCP connection.

   [T] The "Some protocols may always check the CRC ..." is the CRCV
   issue that Mallikarjun also found and that has been problematic in the
   past. I believe that what's going on here is that all protocols have
   to check the Protocol#, and once that's been checked, the
   implementation knows whether there's supposed to be a CRC there and
   hence doesn't need to look at CRCV. In practice this won't cause
   problems, as including the CRC when it's not supposed to be there is
   harmless, and failing to include it when it should be there will
   almost certainly cause a CRC check failure.

   I offer a proposal to resolve this by expanding the Protocol#
   registry that IANA will create so that each registered protocol
   must supply not only its name and an RFC reference, but also whether
   the protocol uses (Yes) or does not use (No) the CRC in this header.
   The above text could then be revised to make the CRCV check at the
   receiver OPTIONAL in all cases because its value can be inferred
   from the protocol#.

   Rejected in principle, with some changes required

   At the Nashua interim, someone wanted a client protocol to be free
   to use CRC or not according to operating environments (e.g., lab-
   local vs. network attachment). The proposed definition of usage by
   IANA based on protocol would eliminate this option.

   It must be noted that the content of Annex A also conflicts with
   this result from the Nashua interim. To correct that, the following
   text from Annex A must be replaced:

      "CRC

      "Protocols employing this encapsulation SHALL either:

      "1) Require a valid CRC to be sent and the CRCV Flag bit to be
          sent as one, or
      "2) Require the CRC field to be sent as zero and the CRCV Flag
          bit to be sent as zero."

   The Annex A CRC discussion (shown above) will be replaced with:

      "Protocols employing this encapsulation SHALL define the
       procedures and policies necessary for verifying that an
       FC Encapsulation Header is being processed."

   Also, make the change described in the response to comment 35.


Comment 11 Technical

   -- Section 3 - The FC Encapsulation Header
   -- Section 3.1 - FC Encapsulation Header Format

   [T] Here or in the description of the Protocol Specific fields, a
   warning to implementers is needed says some sort of error checking
   redundancy (e.g., the ones complements found elsewhere in the header)
   SHOULD (or MUST) be used when the CRC is not used. This warning
   should be duplicated in Section 3.2.1. This is a technical comment,
   but should not be controversial.

   Rejected

   Specific statements of action have been added to each applicable
   field as per comment 6.


Comment 12 Technical

   -- Section 3 - The FC Encapsulation Header
   -- Section 3.1 - FC Encapsulation Header Format

      Time Stamp [integer] and Time Stamp [fraction] (words 4 and 5): The
      two Time Stamp fields contain time at which the FC Encapsulated
      frame was sent as known to the sender. The format of integer and
      fraction Time Stamp word values is specified in Simple Network Time
      Protocol (SNTP) Version 4 [9]. The contents of the Time Stamp
      [integer] and Time Stamp [fraction] words SHALL be set as described
      in section 4.

   [E] For convenience, it might be good to summarize those formats here
   with an indication that [9] is the normative authority. I don't feel
   strongly about this, though.

   [T] We have a problem here - RFC 2030 is Informational, and hence
   can't be referenced in a normative fashion from a standards track
   document. I'll talk to Ralph offline about how to get around this.

   Accepted resulting in the following changes

   1) Copy the definitions of the two time stamp words from RFC 2030
      to this draft (estimated to be 2 paragraphs);
   2) Copy any necessary ancillary definition text from RFC 2030 to
      this draft (estimated to be no more than 5 paragraphs); and
   3) Make the reference to RFC 2030 information, both in the body
      text and in a Informative References section (which will have
      to be added).


Comment 14 Technical

   -- Section 3.2.1

   [T] The warning that the protocol-specific fields SHOULD (or MUST) be
   protected by redundancy needs to go here.

   Accepted.


Comment 18 Technical

   -- Section 4 - Measuring Fibre Channel frame transit time

      When originating an encapsulated frame, an entity that does not
      support transit time calculation SHALL always set the Time Stamp
      [integer] and Time Stamp [fraction] fields to zero. When receiving
      an encapsulated frame, an entity that does not support transit time
      calculation SHALL ignore the contents of the Time Stamp words. The
      protocol SHALL specify whether or not implementation support is
      required.

   [T] This is about "MUST/SHOULD/MAY implement". Need a similar
   requirement on the protocol to specify "MUST/SHOULD/MAY use" and under
   what conditions.

   Accepted with the following results

   Add the following sentence: "The protocol SHALL specify those
   conditions under which a received encapsulated frame MUST have
   its transit time checked before forwarding."


Comment 19 Technical

   -- Section 4 - Measuring Fibre Channel frame transit time

      The policy for processing frames while in the Unsynchronized state
      SHALL be defined by the protocol specification, including whether
      or not the entity may continue to send and receive frames from the
      IP network.

   [T] On the receive side, this condition appears to be specified in the
   wrong direction. Receiving frames from the IP network cannot possibly
   cause problems, the issues are in forwarding (stale) frames into FC.

   Accepted resulting in the following changes

   1) Change "processing" to "forwarding"; and
   2) Remove "including whether ..." to the end of the sentence.


Comment 24 Technical

   -- Section 5.3 - FC SOF and EOF

      SOF (bits 31-24 and bits 23-16 in word 0): The SOF fields contain
      the encoded SOF value selected from table 1.

   [T] As we've learned from the Class 4 adventure, this table is subject
   to change/extension. IANA will need to manage it, and will need some
   sort of allocation guidelines to remain consistent with whatever
   mechanism produced this peculiar set of values. While we probably
   don't want to allow value recycling, we may want to write some text
   dealing with retiring values (making them no longer usable). This
   also applies to the EOF values in Table 2.

   Rejected

   The SOF/EOF codes are stable and have not changed for at least three
   years. They have been implemented in numerous products for tunneling
   FC over ATM and SONET. The only instability is the editor's lack of
   understanding about which SOF/EOF codes are required for FC Class 4
   operation.

   The codes are assigned by T11 and involving IANA in there assignment
   would constitute a conflict of jurisdictions.


2. Comments from Mallikarjun Chadalapaka
   =====================================

Comment 33 Technical

   - Section 3.1, page 4. For the Protocol# values for FCIP and iFCP,
     the Annex B should instead be referred.

   Accepted see comment 5.


Comment 34 Technical

   - Section 3.1, pages 4 & 5. I notice that all the ones complement
     fields (-Protocol#, -Version etc.) are described as "contains the
     ones complement" as opposed to "SHALL contain ones complement",
     whereas the corresponding non-1's complement fields have the SHALL
     wording. Any reasons for this distinction?

   Accepted

   Change -xxx descriptions to use SHALL.


Comment 35 Technical

   - Section 3.1, page 5, CRCV bit description.
           "Some protocols may always check the CRC without regard for
           the state of this bit."
      I am troubled by the literal implication of this sentence. Why
      would that be so?
      Would the encapsulating protocol not mandate CRCV to be set to
      valid always instead? It seems like the purpose of defining a
      common encapsulation format and associated semantics is watered
      down for no stated reason...

   Accepted

   Delete the cited sentence.

   The following response is provided in response to the question asked
   in the last paragraph of the comment. FCIP mandates that CRCV be
   zero. iFCP mandates that CRCV be one.


Comment 39 Technical

   - I think it might be useful to add a statement in this section along
     the lines of - If the encapsulating protocol mandates Synchronized
     operation, the entity MUST NOT accept TCP connections on the well-
     known port(s) unless the entity is in the Synchronized state.

   Rejected

   Since encapsulating protocols are allowed to specify operation in
   the Unsynchronized state, specifying this level of detail about how
   Synchronized operation is handled over reaches the bounds of this
   specification.


Comment 40 Technical

   - Section 4, page 9, Synchronized state rules. I think this should
     also address what is to be done in case there's a case of "bad
     synchronization" when Time Stamp words are valid. For ex., when the
     received value is smaller than the received entity's timebase, I
     assume it would result in arriving at a huge transit time. While
     the huge transit time may cause the frame to be discarded, it isn't
     clear to me what may cause the TCP connection drop and a re-synch.

   Accepted with the following results

   Change the recommended transit time evaluation to use the absolute
   value of the time difference.


4. Additional Changes Discovered After WG Last Call
   ================================================

Comment 77 Technical

   The draft fails to conform to the following requirement stated in
   http://www.ietf.org/ID-nits.html.

   Historically, RFCs have specified byte and bit order according
   to a US DoD rule which made byte zero be the first byte in an
   address range, and bit zero be the most significant bit in a
   word or field. For example, you will find drawings like this
   one (from RFC 791) in many RFCs: when you make drawings like
   it, you should follow the same rule. Label your bit positions,
   bit zero is the most significant bit, and place the first
   addressable byte at the upper left-hand corner.

   3.1.  Internet Header Format

     A summary of the contents of the Internet header follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version|  IHL  |Type of Service|          Total Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Identification        |Flags|      Fragment Offset    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Time to Live |    Protocol   |         Header Checksum       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Destination Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Options                    |    Padding    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Accepted with the following results

   1) Add the following paragraph immediately following the Table Of
      Contents: "Warning to Readers Familiar With Fibre Channel: Both
      Fibre Channel and IETF standards use the same byte transmission
      order. However, the bit and byte numbering is different. See
      Appendix A for guidance."
   2) Change figures 2, 3, and 5 to conform to the IETF bit and byte
      numbering;
   3) Remove bit and byte numbers wherever they appear in the text; and
   4) Insert Appendix A with the following text:


   "Appendix A - Fibre Channel Bit and Byte Numbering Guidance

      "Both Fibre Channel and IETF standards use the same byte
      transmission order. However, the bit and byte numbering is
      different.

      "Fibre Channel bit and byte numbering can be observed if the
      data structure heading shown in figure 6, is cut and pasted
      at the top of figure 2 and figure 5.

     W|------------------------------Bit------------------------------|
     o|                                                               |
     r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1                    |
     d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0|

        Fig. 6 - Fibre Channel Data Structure Bit and Byte Numbering

      "Fibre Channel bit numbering for the Flags field can be observed
      if the data structure heading shown in figure 7, is cut and
      pasted at the top of figure 3.

        |------------------------Bit--------------------------|
        |                                                     |
        |   31       30       29       28       27       26   |

        Fig. 7 - Fibre Channel Flags Bit Numbering"