iFCP -06 comments

[Black_David@emc.com]

At the request of the iFCP authors, I've reviewed the -06 version of
the iFCP draft.  Here are my comments divided into Major, Minor and/or
Editorial, and Formatting categories.  

----- Major -----

5.3.2/5.3.2.1/5.3.2.1.1 - These are written as descriptions of a possible
implementation.  That's fine, but it's necessary to be crisp about what
the requirements are on an implementation that may not go about this in
the fashion envisioned here.  Please go over these sections, figure out
the requirements on an arbitrary implementation and put in the requisite
MUSTs and SHOULDs in addition to the current description of how things
could be implemented.  I believe the functional equivalent of the
translation
table and its entries MUST exist, so that's somewhere to start from.
Other areas of the document have lesser versions of this problem, so please
go over the entire document and check it for this.  I also saw a number
of places with lower case requirements words (e.g., "shall") that probably
need to be upper case.

6.2.1
         An N_PORT is identified by its network address consisting of:

         a) The N_PORT I/D assigned by the gateway to which the N_PORT is
            locally attached and

         b) The IP address of the gateway's iFCP Portal.

Use of an IP address to identify a remote gateway needs to be reconsidered.
Please add something to allow multiple iFCP implementations to exist at
different TCP ports on the same IP address (or explain why this has to
be prohibited).  This is strongly related to the NAPT issues that the
FCIP folks are in the midst of working through.

6.2.2.2 - This section carries a strong risk of over-specification.
As work on TCP evolves, there's a strong risk of entries in this
table conflicting with the then-applicable RFCs.  The ground rule should
be to only specify something here when it has serious consequences
(i.e., there are potentially very bad effects from ignoring the SHOULD).
I think I can accept this argument for the first 4 lines in the table,
but I think the last three should be removed as I don't think
they're crucial to iFCP per se (the discussion of them seems to
amount to "good things to do in general", and there's a strong risk
of further requirements changes/tweaks in this area).  Keep in mind
that I'm one of the co-authors of RFC 3168 (ECN).  Also, I think
keeping the "should"s and "should not"s lower case (so that they're
advice to implementers rather than protocol requirements) is a good
thing to do in this section.

6.2.2.3 - I think this Section needs to go away.  6.2.2.3.1 is essentially
repeating information about TCP implementations in general that is already
to be found elsewhere and should be removed.  6.2.2.3.2 should be moved
to 6.2.3.2.

I think the order of Sections 7 and 8 should be reversed, as the TCP
connection control material is needed to understand how iFCP functions
before discussing the interesting things it has to do to some ELSs.

9.2.1 - The last paragraph on what to do on loss of synchronization seems
inadequate.  It's current state appears to allow stale frame propagation
by a compliant implementation.  Was this the intended outcome?

10.4 b) - How can one be sure that the local gateway knows about all the
remote gateways?  I suspect this involves iSNS, and needs to be explained.

10.4 b) What happens when the broadcast frame exceeds the MTU size?  This
seems to result in a rather unreliable broadcast service, as all of the UDP
datagrams could well be dropped, consistently and repeatedly for large
enough broadcast frames.


---- Minor and/or Editorial -----

4.4 a) It's not exactly correct to describe the Node WWN
as being an identifier for the device.  While that
was the original intent, it isn't always implemented
that way.  In practice, I don't think Node WWNs are
used for much, and that might be worth noting.

4.7.1 - It might be worth describing how Area ID and Port ID
are assigned when an FC-AL loop is attached to a switch
to give the reader a slightly better feel for this
(Area ID is assigned to switch port and Port ID is the
loop port identifier).

4.8 - Track state of things in T11 in determining whether
its appropriate to add Class 4 and 6 to this description.
From FCIP discussions, it sounds like at least Class 4
should be added.

4.9 - Might want to add a sentence to make it clear that these
login processes occur at FC-2, and ULP (FC-4) protocol
setup takes place over the established FC-2 N_Port to N_Port
session in whatever manner the ULP desires

Figure 7 - I think "IP network" would be a better term for what's
below the line than "IP fabric".  I understand what an
"iFCP fabric" is, but I'm not at all sure about an "IP fabric".

5.2.1 - Might want to add a sentence indicating how an FC device
discovers that Class 1 isn't supported (gets told by the
iFCP gateway on Fabric Login).

p. 20
         All iFCP implementations MUST support operation in address
         translation mode. Support for address transparent mode is optional

"optional" should be all upper-case.

         The implementation MUST NOT allow the mode to be
         changed after iFCP sessions have been established.

So, the mode can be changed while a session is being established?  I don't
think so and suggest that the above wording be changed.  One possibility
would be to prohibit a mode change while any device is logged into it
via FLOGI.

5.3.1 - Somewhere near the end of this section please say that FC
frame CRCs have to be regenerated as a consequence of performing
address translation.

Both 5.3 and 5.3.1 contain some rationale text about the differences between
address-transparent and address-translation mode and why one might select
one or the other that might be better separated out from the description
of how iFCP works in these modes.  In particular, iSNS pops up without any
introduction in 5.3.1 a) - this text really needs to come after a discussion
of iSNS and its responsibilities for/interaction with iFCP.


5.3.1.1 - The whole discussion of domain ID assignment is rather imprecise.
Please put in a "MUST" requirement for unique domain IDs, and indicate that
iSNS can do this (with a specific description of how) in addition to manual
assignment.

5.3.1.2 - Please upper-case "shall" in the first sentence here.  Also
applies
to 5.3.2.3.

6.2.2.1 - For a), please indicate how the gateway knows which remote
gateway to use and what it's address is.  This involves translation
table entries that were initialized by iSNS replies.

6.2.3 - Please be clear about what exactly is being terminated or aborted.
I think the iFCP session (TCP connection) between gateways is
what's involved, but there's enough FC mechanism discussion here
to be unclear.

6.3 - I guess this reference to RFC1323 is ok, although it strikes me
as superfluous.  Please indicate that it's Appendix B of RFC 1323.

6.4.4 - State that the FC CRC MUST be recalculated due to the
address translation.

7.3.1 - Two translation types are shown for the ABTX Exchange originator.
I think this should be Type 1.

7.3.5 - Translation table is incomplete for FARP-REQ.

7.3.7 - Why is PLOGI in a subsection of 7.3 when it's not augmented?

7.3.8 - Three translation types are shown for the REC Exchange originator.
Again, I think this should be type 1.  Variants of this problem are also
present in all of 7.3.9 through 7.3.15.

7.4 - Table 4 consists entirely of "n" and "M" entries, so delete the
explanation of the unused "y" entry.

8.1 - For clarity indicate that the connection handle is needed to unbind
connections (yes, I know this is discussed in the next section).

11.3.1 - Please remove the "MUST implement" for DES (it's ok to make DES
OPTIONAL), and think about rewording the "As stated in" statements, as
we are overriding some of the requirements in some of the reference RFCs.

11.3.1.1 - This is ok in a working version of the draft, but will vanish
in the final version (ditto the subject to availability of an RFC
language about AES earlier) because either we will make a normative
reference to the AES RFCs or RFC-to-be, or we will delete requirements
for AES.

11.3.2
         If, however, the TCP session is
         maintained, then a Phase 2 delete message shall trigger a new Quick
         Mode exchange.  

Probably not a good idea.  The issue here is that some hardware crypto
accelerators only have room for a fixed number of phase 2 SAs and hence
delete old ones to make room for new ones (ideally deleting the least
recently used, but ...).  Triggering a new Quick Mode immediately in
response to any delete of an SA for an open TCP connection could
thrash the SA state resources in such an accelerator.  Triggering
the new Quick Mode based on traffic sent over the SA should work better.

12.2 - Please delete d) as MPLS is *NOT* a QoS technology.  In addition,
the entire paragraph after d) appears to have very little content, and
I'm not at all sure about the value of discussion SLAs here.  The
discussion of [00-603] is also questionable.

Appendix B - Is there an external version of this material that could
be referenced rather than including it here?

----- Formatting -----

There are a bunch of places where MS Word
has inserted non-standard MS punctuation characters
(mostly a u with a circumflex instead of a hyphen)
Turn off Smart Quotes and Auto Correct and correct these.

6.3 has a formatting problem - probably an MS Word style
that should not have been used.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------