Re: FCIP WG Last Call Comment 34 - Frame Sync Recovery

[Ralph Weber <ralphoweber@compuserve.com>]

David,

I am confident that the authors are equally appreciative of your 
flexibility regarding the degree of change required to address 
Comments 36 and 37.

As for comment 34:

> 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 EOF validation referenced in item 3) serves the purpose
of verifying that the contents of the Frame Length field
are correct. This reasoning cannot be used to justify a 
requirement that the SOF be validated because such a 
validation proves nothing about the correctness of 
the Frame Length field.

I believe that the most that can reasonably be said would
look something like this:

Add a note in a separate paragraph that immediately follows
the paragraph that starts "At least 5 of the 18 tests ...",
with the text of the note reading as follows:

"Note: The process of selecting an 8b/10b encoding for the
SOF by necessity includes some validation of the SOF fields."

Thanks.

.Ralph

Black_David@emc.com wrote:

>
> 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
> ---------------------------------------------------