FCIP WG Last Call Comments 34-37 - Frame Sync Recovery

[Black_David@emc.com]

First, I want to thank the FCIP authors for resolving the
issues around the recovery algorithm in Annex/Appendix C
(comments 36 and 37).  I suspect they think I owe them one
(I probably do) and they will doubtless want to collect
at some point :-).

I have one remaining concern about the resolution to
Comment 34 - part of its resolution says:

   b) Explicit testing of the SOF and EOF values is not MANDATORY
      in this section because they must be used to reconstruct the
      FC Frame prior to transmission in the FC Fabric. That process
      will necessarily validate the SOF and EOF; 

The EOF already had to be validated at item 3) of the list
just above this.  It would be good to add the gist of b)
to the draft - SOF MUST be validated in a manner similar
to EOF before forwarding the frame, and doing it at the
same stage of processing as EOF validation is one possibility.

The proposed resolution of comment 35 is fine - it's included
here for completeness.

Thanks,
--David

----- Comments 34-37 ---------

Comment 34 Technical
 
   -- Section 6.6.2.2 - Errors in FCIP Headers and Discarding FCIP
    Frames
 
      In addition to the tests above, the validity and positioning of
      the following FCIP Frame information SHOULD be used to detect
      encapsulation errors that may or may not affect synchronization:
 
      a)  Protocol # field and its ones complement (2 tests);
      b)  Version field and its ones complement (2 tests);
   [... list continues, snipped ...]
 
   [T] I think at least these two are MUSTs. At a minimum, the
   Protocol# and Version field must be checked against expected values -
   I might accept the checks against their ones complements being
   SHOULDs. Same comment applies to the Flags field and SOF. Someone
   MUST check the FC frame CRC before forwarding the frame, but that
   responsibility could be assigned to the FC Entity.
 
   Accepted (Partially) with the following results
 
   1) Add to 6.6.2.2 checking Protocol# and Version#. This addition
      will have to be in a separate paragraph before the current 1),
      2), 3) list because it is not a synchronization issue;
   2) Keep the one's complement tests in the SHOULD a), b), c) list,
      but reduce the number of tests in that list by 2 (1 in a and
      1 in b); and
   3) Change the count of optional tests required from "5 of 18" to
      "3 of 18".
 
   Responses to other issues raised by comment
 
   a) The Flags field is not a MUST test because it provides no 
      certain identification of the protocol beyond that provided by


Ralph Weber                                                    [Page 15]

Internet-Draft             FCIP 1st WG Last Call             April, 2002


      the Protocol# field;
   b) Explicit testing of the SOF and EOF values is not MANDATORY
      in this section because they must be used to reconstruct the
      FC Frame prior to transmission in the FC Fabric. That process
      will necessarily validate the SOF and EOF; and
   c) Not even the Fibre Channel standards require that the FC CRC
      be validated by FC Fabric elements. FC Endnode validation of
      the FC CRC is sufficient.
 
 
Comment 35 Technical
 
   -- Section 6.6.2.2 - Errors in FCIP Headers and Discarding FCIP
    Frames
 
      At least 5 of the 18 tests listed above SHALL be performed.
      Failure of any of the above tests actually performed SHALL
      indicate an encapsulation error and the frame SHALL NOT be
      forwarded on to the FC Entity. Further, such errors SHOULD be
      considered carefully, since some may be synchronization errors.
 
   [T] There aren't 18 tests, and I think some of the individual tests
   (or subsets) are MUSTs (see previous comment). This needs to be gone
   over carefully - in essence a MUST is only appropriate where failure
   to apply the test carries a non-negligible risk of forwarding a bad
   frame to FC.
   The authors are the experts on this and need to do this analysis. I
   don't understand the last "SHOULD" - what is the (testable)
   requirement on an implementation?
 
   No changes made
 
   There are 18 tests: 2 + 2 + 1 + 2 + 2 + 1 + 4 + 1 + 2 + 1 = 18
 
   What tests are MUSTs is covered by comment 34.
 
   The authors have gone over the tests carefully and have concluded
   that no individual test or specific group of tests associates
   specifically with a non-negligible risk of forwarding a bad frame
   to FC. The requirement is that a suitable number (at least 5, or 
   12 when the 7 required tests are included) tests is necessary to
   reduce the risk of forwarding a bad frame to FC to a negligible
   level. The specific tests selected depends on the implementation,
   i.e., what test can be performed most efficiently in the
   implementation hardware.
 
   The "SHOULD" statement is intended to guide implementations.
   Repeated failures of, for example, the CRC equal to zero test may


Ralph Weber                                                    [Page 16]

Internet-Draft             FCIP 1st WG Last Call             April, 2002


   mean that synchronization has been lost. There are no hard and fast
   rules here.
 
Comment 36 Technical
 
   -- Section 6.6.2.3 - Synchronization Failures
 
      If the FCIP_DE attempts to recover synchronization, the
      resynchronization algorithm used SHALL meet the following
      requirements:
 
   [T] One requirement is missing, which may be part of b):
 
      b)  return to sending valid FC Frames only after synchronization
          has been verified; and
 
   [T] Verification of synchronization MUST exclude any possibility of
   forwarding an FC frame that was not sent by the transmitting FCIP
   Entity. This includes the scenario in which a valid encapsulated FCIP
   frame occurs in the payload of an FC frame that is encapsulated and
   sent over FCIP; excluding this scenario is necessary but not
   sufficient to meet the requirement.
 
   Accepted with the following results
 
   Replace b) with: "return to forwarding FC Frames only after
   synchronization on the transmitted FCIP Frame stream has been
   verified; and"
 
Comment 37 Technical
 
   -- Section 6.6.2.3 - Synchronization Failures
 
      An example algorithm meeting these requirements can be found in
      annex C.
 
   [T] That doesn't meet the missing requirement that my above 
   comment wants to add. The problem is at step 2 of the algorithm
   description.
 
      2)  Use multiple strong candidate headers to locate a verified
          candidate header:
 
          The Frame Length in one strong candidate header is used to skip
          incoming bytes until the expected location of the next strong
          candidate header is reached. Then the tests described in step
          1) are applied to see if another strong candidate header has
          successfully been located.


Ralph Weber                                                    [Page 17]

Internet-Draft             FCIP 1st WG Last Call             April, 2002


 
   The "skip incoming bytes" step makes it possible that a set of valid
   FC headers is interlaced in the payloads of FC frames in a fashion
   that causes all the real headers to be skipped. This is a rather
   unlikely, but not impossible scenario. This could be dealt with by
   searching for headers instead of skipping data and aborting if a
   header is found where data should have been or carrying on and
   aborting if an interlaced header chain scenario arises. The
   algorithm in Annex C does address the scenario of FCIP frames
   occurring in FC frame payloads, but it doesn't meet the "can't be
   fooled" requirement that I think should be added.
 
   Unfortunately, this issue appears to not be resolvable within the WG.
   I have had heated and lengthy offline discussion with the FCIP
   Authors in which they have made clear their strong opposition to the
   "missing requirement" and the need to scan rather than skip data, and
   have argued that the algorithm in Annex C produces a long enough
   chain of headers that the odds of having followed a chain that is
   interlaced through frame payloads is small enough to be ignored.
   I will have to consult the Area Directors.
 
   Accepted with the following comment
 
   Modifications to either step 2 or step 3 will achieve the requested
   results. Because step 3 already includes complex steps such as
   verifying the FC CRC value, changes in response to the comment will
   be made in step 3.
 
   Actions to be taken
 
   1) Change the first paragraph of Annex C step 3 from:
 
       "Incoming bytes are skipped and discarded until the next
       verified candidate header is reached. Each verified candidate
       header is tested against the full collection of tests listed in
       section 6.6.2.2 as would normally be the case."
 
   to:
 
       "Incoming bytes are inspected and discarded until the next
       verified candidate header is reached. Inspection of the incoming
       bytes includes testing for other candidate headers using the
       criteria described in step 1. Each verified candidate header is
       tested against the tests listed in section 6.6.2.2 as would
       normally be the case."
 
 
 


Ralph Weber                                                    [Page 18]

Internet-Draft             FCIP 1st WG Last Call             April, 2002


   2) Change the second sentence in the third paragraph of Annex C
      step 3 from:
 
       "If any verified candidate headers are invalid and fail to meet
       the tests for a strong candidate header, increment the retry
       counter and return to step 1."
 
   to:
 
       "If any verified candidate headers are invalid and fail to
       meet the tests for a strong candidate header or inspection
       of the bytes between verified candidate headers discovers
       any candidate headers, increment the retry counter and
       return to step 1."
 
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------