RE: FC Encapsulation WG Last Call comments

[Black_David@emc.com]

Murali,

Ralph and I had essentially the same discussion.  Based on the
recent volatility of these codes for some of the IETF IPS uses,
and the fact that work on figuring out which ones to use had
extended back to Orlando, well over a year ago, I was concerned
that these codes were in a sufficient state of flux that
IANA was needed to stabilize the situation.

Given that the codes have normative definitions in FC-BB, and those
definitions are stable (the IETF issues have been merely which
ones to use, and those should [finally] be settled), referencing
FC-BB as the source of these definitions will be fine, and I'm
sure IANA will appreciate one less registry to manage.

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

> -----Original Message-----
> From: Murali Rajagopal [mailto:muralir@cox.net]
> Sent: Tuesday, March 19, 2002 11:48 AM
> To: Elizabeth G. Rodriguez; Black_David@emc.com; ips@ece.cmu.edu
> Subject: RE: FC Encapsulation WG Last Call comments
> 
> 
> 
> A little background history on SOF/EOF may help ...
> 
> SOF/EOF codes were introduced by me in T11/FC-BB about 3 
> years ago. The
> codes were derived from a chip implementation at Gadzoox (and another
> company). Since then, a number of implementations exist in 
> the FIELD which
> use these byte-encodings. While a large number of these codes 
> were defined,
> a number of them were not initially supported in FC-BB. The 
> expectation was
> someday they may come into use. An example of this is Class 4 
> codes. Given
> this background, these codes cannot be arbitarily changed or 
> redefined. The
> end consumer of these codes lies clearly in the T11 community quite
> independent of the Internet. As such, it is not appropriate 
> for IANA to
> manage these codes.
> 
> Hope this helps.
> 
> Murali Rajagopal
> 
> FCIP Technical Coordinator
> T11/FC-BB-2 Editor
> 
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Elizabeth G. Rodriguez
> Sent: Monday, March 18, 2002 3:54 PM
> To: Black_David@emc.com; ips@ece.cmu.edu
> Subject: 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
> ---------------------------------------------------
>