SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    FC Frame Encapsulation Technical Comments & Proposed Resolutions



    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"
    
    
    


Home

Last updated: Tue Apr 02 22:18:19 2002
9438 messages in chronological order