SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: FC Encapsulation WG Last Call comments



    Hi David,
    
    	[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.
    
    I think there is a misconception with the EOF/SOF encodings.
    The encodings themselves have been fairly stable for some time. 
    The issues that came about recently is identifying which encodings
    pertained to Class 4 specifically -- that was not obvious.
    
    In any case, even if the encodings were not stable, SOF/EOF encodings
    are in the domain of INCITS and the FC-FS/FC-BB/2 documents.  I do not
    see how we can have IANA govern these encodings.
    
    Thanks,
    
    Elizabeth
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of
    Black_David@emc.com
    Sent: Sunday, March 17, 2002 11:31 PM
    To: ips@ece.cmu.edu
    Subject: FC Encapsulation WG Last Call comments
    
    Comments flagged with [E] for editorial, [T] for technical.
    
    ----- FC Encapsulation -06 -----
    
    -- Section 1 - Scope
    
       The organization responsible for the Fibre Channel standards (NCITS
       Technical Committee T11) has determined that some functions and
       modes of operation are not interoperable to the degree required by
       the IETF. This draft includes applicable T11 interoperability
       determinations in the form of restrictions on the use of this
       encapsulation mechanism.
    
    [E] Is there an official citation for this statement?  It really needs
    one
    to be published in an archival unchangeable format such as an RFC.
    
    -- Section 2 - Encapsulation Concepts
    
    	FC frames have several possible lengths.
    
    [E] Should read "variable length" or something like that - this implies
    several possible choices of fixed length, which is incorrect.
    
       To facilitate transporting FC frames over TCP the native FC frame
    needs
       to be contained in (encapsulated in) a slightly larger structure as
       shown in figure 1.
    
    [E] The use of TCP in this context is overly restrictive.  This
    encapsulation
    is in principle applicable to any means of transport over IP, including
    TCP, SCTP, UDP, and carrier pigeon ;-), even though in practice all the
    initial uses will use TCP.
    
       The format and content of an FC frame is described in the FC
    
    [E] "is" --> "are"
    
    -- 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.
    
       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.
    
       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.
    
       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.
    
       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#.
    
    [E] Also need to generalize away from TCP connection to allow possible
    future
    use with other transports.
    
    [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.
    
       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.
    
       CRC (word 6): When the CRCV Flag bit is zero, the CRC field SHALL
       contain zero. When the CRCV Flag bit is one, the CRC field SHALL
       contain a CRC for words 0 to 5 of the FC Encapsulation Header
       computed using the polynomial, initial value, and bit order defined
       for Fibre Channel in FC-FS [3]. Using this algorithm, the bit order
       of the resulting CRC corresponds to that of FC-1 layer. The CRC
       transmitted over the IP network shall correspond to the equivalent
       value converted to FC-2 format as specified in FC-FS.
    
    [E] I realize that FC-FS is the latest and greatest version of the FC
    frame standard, BUT, referencing a project in progress for this sort of
    basic CRC mechanism is an invitation to procedural problems.  Can this
    reference be changed to FC-PH accompanied by a note that FC-FS is
    supplanting FC-PH, but will make *no* changes in this area?  Note that
    I'm comfortable with the earlier reference to FC-FS for frame contents.
    
    -- Section 3.2.1
    
    [T] The warning that the protocol-specific fields SHOULD (or MUST) be
    protected
    by redundancy needs to go here.
    
       Redundancy based header validation can be built from simple logic
       (e.g., XORs and comparisons). Header validation based on redundancy
       also is a step wise process in that the first word is validated,
       then the second, then the third and so on. A decision that a
       candidate header is not valid may be reached before the complete
       header is available.
    
    [E] First sentence is superfluous and probably should be deleted as it's
    rather hardware-oriented.
    
    -- Section 3.2.2
    
       CRC based header validation employs a straight forward algorithm
       (e.g., compute the CRC for all bytes preceding the CRC word and
       compare the results to the CRC word's contents). The number of
       comparisons required to perform CRC validation is exactly one and
       the method for computing the CRC is well known with proven
       implementations.
    
    [E] Last sentence is superfluous and probably should be deleted as it's
    rather hardware-oriented.
    
    -- Section 4 - Measuring Fibre Channel frame transit time
    
       To comply with FC-FS [3], an FC Fabric must specify and limit the
       lifetime of a frame.
    
    [E] Same comment as before about referencing FC-FS.  Can this be changed
    to
    reference FC-PH with a note that FC-FS won't change this ... or is FC-FS
    tinkering with things here?
    
       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.
    
       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.
    
       When de-encapsulating a frame, an entity in the Synchronized state
       SHALL:
    
    [E] While the sub-bullets are correct, they leave a reader unfamiliar
    with FC somewhat high and dry.  I would include a "for example" in both
    a) and b), along the lines of:
     
    	a) For example, if a calculated transit time exceeds a value
    that
    		could cause the frame to violate FC maximum time in
    transit
    		limits (Time Out Values), the protocol may specify that
    the
    		frame is to be discarded.
    	b) For example, a protocol may specify that frames for which
    transit
    		time cannot be determined are never to be forwarded over
    FC.
    
    
    [T] At the end of this section, it would be good to warn protocol
    designers
    that well-designed protocols are unlikely to accomplish useful
    communication
    when the communicating entities are in different states, and hence
    protocol
    designers need to consider how to coordinate state transitions,
    especially
    the Unsynchronized to Synchronized transition on startup and an
    unexpected
    Synchronized to Unsynchronized transition (e.g., caused by loss of
    contact
    with an external time service).  This is related to some issues that
    Mallikarjun
    found.
    
    -- Section 5 - The FC frame
    -- Section 5.1 - FC frame content
    
       As shown in figure 4, the FC frame content is defined as the data
       between the EOF and SOF delimiters (including the FC CRC) after
       conversion from FC-1 to FC-2 format as specified by FC-FS [3].
    
    [E] This needs some more explanation.  The important things that need to
    be said are:
    	- FC uses the same 8b/10b encoding as Gigabit Ethernet in which
    		each 8 bit byte is transmitted using 10 bits on the wire
    		for reasons that include redundancy and low level timing
    		synchronization between sender and receiver.
    	- All discussion of FC frame content in this draft is at the 8b
    		level prior to 8b->10b expansion on send or after
    10b->8b
    		reduction on receive.
    The Gigabit Ethernet reference is particularly important in increasing
    accessibility of this document to a network-savvy, but new to FC
    audience.
    
    -- Section 5.3 - FC SOF and EOF
     
       The FC frame content is composed of 8-bit bytes that can be
       translated directly for transmission over TCP. The FC SOF and EOF
       [3] require 8b/10b special characters that cannot be translated
       directly to 8-bit bytes, encoded values are required.
    
    [E] I think this paragraph needs to be moved to Section 5.1, and
    replaced
    with a sentence here that refers back to it.  One important editorial
    change is "8b/10b special characters that cannot be translated directly
    to 8-bit bytes" should be changed to "10b special characters that have
    no 8b equivalents" or something like that.
    
       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.
    
       Note: FC-BB-2 [6] lists SOF and EOF codes not shown in table 1 and
       table 2 (e.g., SOFi1 and SOFn1). However, FC-MI [7] identifies these
       codes as not interoperable, so they are not listed in this
       specification.
    
    [T] There are a couple of problems here.  If FC-BB-2 has assigned values
    to SOF and EOF encodings that MUST NOT be used with FCIP, then we need
    to
    instruct IANA to reserve and not allocate those values.  As part of
    allocating future values in this table, we need to (1) instruct the
    author(s)
    of the draft/RFC doing the allocation to ensure that T11.3 review of the
    proposed allocation is obtained (2) that the IPS WG chair(s) (if the IPS
    WG still exists) and the Transport ADs are informed of this review, and
    (3) that IANA allocates the values approved by T11.3 as opposed to
    choosing
    values.  Since Murali's been appointed as T11's official liaison to
    IETF,
    I think it's his responsibility to suggest a coordination process.
    
    -- Section 7 - Normative References
    
    I would really like to remove the normative reference to FC-FS,
    substituting
    FC-PH with a note that FC-FS will replace FC-PH.  I don't object to an
    FC-FS
    reference where it's really needed, but the portions of FC-FS that this
    draft
    relies on are sufficiently basic and stable that an FC-PH reference will
    make
    their stability clear.  The FC-BB-2 and FC-MI references for SOF and EOF
    codes
    need to become non-normative as part of setting up the IANA registry and
    management
    process.  The FC-SW-2 reference may not need to be normative here.
    
    RFC 1700 is almost certainly the wrong reference to instruct IANA on
    what
    procedures to follow.  See RFC 2434 for guidance on this topic, although
    it
    may
    not be necessary to reference it.
    
    -- ANNEX A - Protocol Requirements
    
    [E] I think this should be an Appendix, rather than an Annex.  Some
    changes
    may be in order here based on the above comments.
    
    -- ANNEX B - IANA Considerations
    
    [T] This needs to be made somewhat more explicit and direct.  IANA is
    looking for
    simple straightforward instructions roughly of the form "IANA is
    instructed
    to
    do <X>".  in particular, the following sentence is a problem:
    
       Standards action on this RFC should be accompanied by IANA
       assignment of the following two Protocol# values:
    
    It should read something like:
    
       In addition to creating the FC Encapsulation Protocol Number
    Registry,
       the standards action of this RFC allocates the following
       two values from this registry:
    
    While one normally asks IANA to allocate values, the exception is that
    when creating a registry, one can instruct IANA as to what the initial
    contents are (i.e., a new registry does not have to be created empty).
    
    [T] Also, earlier comments suggest that the Protocol# registry needs to
    be
    expanded with a CRC field (Yes/No) and that registries need to be
    created
    for the SOF and EOF values.
    
       It is requested that the ips working group chairs or the
       Transport Services area directors be notified when any new Protocol#
       value assignment is requested.
    
    [T] Given that an approved RFC is required, this sentence seems
    redundant.
    If the intent was notification of the IPS WG chairs and/or ADs when a
    an I-D draft is submitted that will cause a Protocol# assignment if/when
    approved as an RFC, the language needs to say that and should be
    rephrased to require notification of the IP Storage WG chairs (don't
    use WG acronyms here) and notification of the Transport ADs instead
    in the case that the IPS WG does not exist or is not active.
    
    [T] Also see previous comments about needing to set up an IANA
    registry for SOF and EOF values.  I'll work with Ralph on crafting the
    right IANA instructions.
    
    Thanks,
    --David
    
    ---------------------------------------------------
    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
    ---------------------------------------------------
    
    


Home

Last updated: Tue Mar 19 12:18:12 2002
9198 messages in chronological order