iFCP: review comments

["Mallikarjun C." <cbm@rose.hp.com>]

Charles,

Some review comments below.  I figured I will post my scribbled notes
even though the WG Last Call is long gone.  Sorry for the delay.

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com

> 1.2 Purpose of this document

> standards controlled by NCITS T10 and T11. This material is

S/b "NCITS" w/ "INCITS".

> 2.1 Definitions

> Gateway Region û The portion of an iFCP fabric accessed through an
> iFCP gateway. Fibre channel devices in the region consist
> of all fibre channel devices locally attached to the
> gateway.

The first sentence here when interpreted wrt a Nx_port sitting within
a given gateway region, implies something that isn't right - viz. the rest
of the iFCP fabric.  The second sentence makes the intention clear, if
"locally attached" includes the entire local fabric.  My suggestion would
be: "The portion of an iFCP fabric that accesses the rest of the fabric through
one iFCP gateway."

> 3.3.1 Fabric-Supplied Link Services

> Time Server û- Intended for the management of fabric-wide
> expiration timers or elapsed time values and is not intended for
> precise time synchronization.

I am curious about this - is it the conclusion the iFCP authors reached?
The reason I ask is that IIRC, FCIP allows using this for time sync.

> 3.7 Fibre Channel Frame Format

> The source and destination N_PORT fabric addresses embedded in the
> S_ID and D_ID fields represent the physical MAC addresses of
> originating and receiving N_PORTs.

I am not sure that it is a correct analogy....S_ID and D_ID are actually
(potentially transient) addresses assigned by the fabric, Port Names are
more akin to the MAC addresses.

> 4. The iFCP Network Model
> The iFCP protocol enables the implementation of fibre channel mixed
> or switched fabric functionality on an IP network

I am not sure what is intended by "fibre channel mixed or switched" here,
perhaps this could use rewording.

> Each iFCP gateway contains two standards-compliant fibre channel
> ports and an iFCP Portal for attachment to the IP network.

Why are two FC ports required?  As far as I can tell, even one E_Port
works just as well - is it to be technically called as a "switch"?

Also, is there a reason for limiting to only one IP address (implied by
one iFCP Portal)?  I see that supporting multiple iFCP Portals would
require enahancements to the data structures presented - but can you
please comment on any architectural issues here?

> channel switch element. At this interface, remote N_PORTs are
> presented as fabric-attached devices. Conversely, on the IP network
> side, the gateway presents each locally connected N_PORT as a
> logical fibre channel device.

I am not sure the last sentence is correct - I think "logical fibre channel
device" should probably be replaced by "a TCP connection".

> 4.1 Fibre Channel Fabric Topologies Supported by iFCP

> cases, the gateway may support any standards-compliant fibre
> channel fabric type by incorporating the functionality required to

Can you please comment if really "fabric type" is meant here?  Or, is
it the "fabric port type"?

> present locally attached N_PORTs as logical iFCP devices.

It may be useful to define "iFCP device" in section 2.1.

> 4.4.1 Address Transparency

> messages, a gateway cannot convert such addresses in the payload of
> vendor- or user-specific fibre channel frame traffic.

Not being very familiar with today's FC, can you please comment if these
proprietary versions of frame formats (with even the D_ID out of place) are
legal on regular fabrics?  Seems like the entire fabric should be capable
of special handling these ....

> 4.4.3 Fault Tolerance
> In an unbounded iFCP fabric, limiting the scope of an N_PORT
> address to a gateway region reduces the likelihood that

Does it not prevent the likelihood?

> reassignment of domain I/Ds caused by a disruption in one gateway
> region will cascade to others.
>
> In addition, a bounded iFCP fabric has an increased dependency on

Suggest S/b "In addition" W/ "On the other hand".

> Finally, adding a gateway to a bounded fabric is more likely to
> disrupt the operation of all devices in the gateway region along
> with those already in the fabric as new, fabric-wide N_PORT
> addresses are assigned

Isn't the issue in this para the same as that in the first para, albeit from
the bounded fabric's perspective?  If so, suggest merging them.

> be done non-disruptively and requires only that new gateway's iSNS

S/b "that" W/ "that the"

> 4.5 The iFCP N_PORT Address Model

> b) A 24-bit N_PORT alias. A fibre channel N_PORT address assigned
> by a gateway operating in address translation mode to identify a
> remotely attached N_PORT. Frame traffic is directed to a
> remotely attached N_PORT by means of the N_PORT alias.

At any point in time, there can only be 2^24 N_PORTs communicating
even in the address translation mode, eventhough this mode allows the same
nport_id to be mapped to different nports in different gateway regions at
different times.  If this is a correct interpretation, I suggest that this be made
clear in section 4.4.2, which currently simply states that there are no architectural
limitations on the number of fibre channel devices in this mode.

> 4.6.1 Transparent Mode Domain I/D Management

General comment - S/b "principal switch" W/ "Principal Switch".

> In its role as principal switch within the gateway region, an iFCP

S/b "as" W/ "as the"

> 5.2.1 iFCP Session Model

> iFCP session. A gateway implementation MAY establish a pool of

I wonder if there is a scope for DoS attack here with the possibility of
one gateway potentially holding onto several ununsed TCP connections
infinitely....

> 5.2.2.1 The Remote N_PORT Descriptor

> SHALL be created in response to an iSNS name server query. Such

Did you mean "SHALL be created after the response to an iSNS name
server query is received"?

> 5.2.2.1.1 Updating a Remote N_PORT Descriptor
>
>
> Monia et-al. Standards Track [Page 31]
>
> iFCP Revision 10 February 2002
>
> A Remote N_PORT descriptor SHALL only be updated as the result of
> an iSNS query that returns information for the specified worldwide
> port name. Following such an update, a new N_PORT alias SHALL NOT
> be assigned.

- I assume you meant "iSNS response" instead of "iSNS query"?
- I am a little confused by the SHALL NOT.  Here's what I was assuming
  as the sequence of events - 1. Local FC Name Server query
  2. iFCP gateway picks it up 3. Consults with iSNS server 4. iSNS
  provides the remote nport_id for the WWN 5. iFCP gateway
  assigns a local alias if in translation mode and if the remote nport_id
  clashes with a pre-existing local nport_id.

   I do not see why this sequence should be prohibited.  Comments
   will certainly help.

> Until such an update occurs, the contents of a descriptor may

I assume that generally what is meant by "Until such an update occurs"
is "In the absence of an operational iFCP session based on a descriptor".
If so, it perhaps requires rewording.

> Once the originating N_PORT learns of the reconfiguration, usually
> through the name server state change notification mechanism, the
> name server lookup needed to reestablish the iFCP session will
> automatically purge such stale data from the gateway.

Just a clarification here - it seems to me that the SCN for a remote nport_id
needs to delivered via the iFCP gateway anyway, so why not purge
the stale mapping then (instead of waiting for the new SNS query from
the local nport)?

> 5.2.2.2 Creating an iFCP Session

> f) A CBIND response with a CBIND STATUS of "N_PORT session already
> exists" indicates that the remote gateway has concurrently

I think the document should specify that this status be mapped to the
LS_RJT reason code of "Login/command already in progress" - 0x0E.

Also, there may be nports that go down without issuing a LOGO, and attempt
a PLOGI once they come back - unbeknownst to the iFCP gateway still with
the old session descriptor.  It isn't clear to me how this is proposed to be dealt with.

> 5.2.2.3 Monitoring iFCP Connectivity

> b) An LTEST message is not received within twice the specified
> interval or the iFCP session has been quiescent for longer than
> twice the specified interval.

I think "or" above should be "and" - else it implies that the LTEST
message must be received periodically even in the presence of other
traffic.

> 5.2.3 Terminating an iFCP Session

> a) An LS_RJT response is returned to the gateway that issued the
> PLOGI ELS. The gateway SHALL forward the LS_RJT to the local

My reading is that the gateway does not "issue" the PLOGI ELS, it merely
facilitates the transport of an issued PLOGI ELS.  The wording here is a little
confusing - I also believe that the forwarding should be to the remote
N_PORT, not local.

> N_PORT and complete the session as described in section

I recommend "terminate"/"close" in all the places "complete" is used.

> 5.2.3.1 iFCP Session Completion

> Unbind session control ELS as described in section 6.2.

I am a little confused about the status of Unbind here - is it a
FC-FS approved ELS or an iFCP session control message?

> 5.2.3.2 Aborting an iFCP Session

> In any event, the TCP connection SHOULD be terminated with a
> connection reset (RST). If the local N_PORT has logged in to the
> remote N_PORT, the gateway SHALL send a LOGO to the local N_PORT.

I think the draft should specify both OPEN and OPEN PENDING
cases here.  For OPEN state, a local LOGO is required as stated,
whereas for OPEN PENDING, a local LS_RJT may be appropriate.

Also, it is useful to state that the proxied ELS (in either case) be indistinguishable
from the end-to-end ELS in its payload (so any sanity checking done by endnode
software would continue to work).

> 5.4.1 Encapsulation Header Format

> Protocol# IANA-assigned protocol number
> identifying the protocol using the
> encapsulation. For iFCP the value is
> (/TBD/).

Should FCEncap document be referred here instead?

> 5.4.3 Frame Encapsulation

> Following frame validation, the S_ID and D_ID fields in the frame
> header SHALL be referenced to lookup the iFCP session descriptor
> (see section 5.2.2.2). If no iFCP session descriptor exists, the
> frame SHALL be discarded.

With the exception of PLOGI?

> Frames types submitted for encapsulation and forwarding on the IP

S/b "Frames" W/ "Frame".

> 6. TCP Session Control Messages
> TCP session control messages are used to create and manage an iFCP
> session as described in section 5.2.2. They are passed between peer
> iFCP Portals and are only processed within the iFCP layer.
> The message format is based on the fibre channel extended link
> service message template shown below.

It may be useful to state that this message forms the "FC Frame" payload
of the iFCP frame.

It may also be useful to state the value of LS_COMMAND in the encap
header (0?).

In stead of having two LS_COMMAND fields - one in the header and
one in the payload - for these messages, a simpler approach could be to
state that LS_COMMAND in the header contains an iFCP-defined
value when SES=1 (and remove the one in the payload).

> 6.1 Connection Bind (CBIND)

> The following shows the format of the CBIND request.

I take it that this CBIND structure goes into the Session Control
Message starting from word 6?  Same question on CBIND response.

> 6.2 Unbind Connection (UNBIND)
> UNBIND is used to release a bound TCP connection and. optionally,
> return it to the pool of unbound TCP connections.

I assume "release" here implies - "remove the binding"?

Is there a way to convey the preference to not terminate the connection
on the part of the sender?  IOW, where is the optionality selected?

> transmitted in the connection that is to be unbound. The time

S/b "in" W/ "on"

> 8.2.1 Enforcing R_A_TOV Limits
> The R_A_TOV limit on frame lifetimes SHALL be enforced by means of
> the time stamp in the encapsulation header (see section 5.4.1) as
> described in this section.

A couple of general questions on this section -

- Is Unsynchronized operation allowed?  If so, how is the R_A_TOV
   expectation met?
- If an incorrect configuration causes the timestamp of the incoming frame
  to be higher than the gateway's time base, it is better if there is a way to
  detect and perhaps resync both ends with the same SNTP server (as opposed to
  one out of a list returned by iSNS).  As far as I can tell, the current text
  specifies that it would simply cause the frames to be discarded, but doesn't
  break the binding nor terminate the TCP connection - perhaps relying on
  the end nodes to LOGOUT?