|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] FC Frame Encapsulation Technical Comments & Proposed ResolutionsThis 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 |