[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
iFCP: review comments
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 firstname.lastname@example.org > 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.... > 188.8.131.52 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"? > 184.108.40.206.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)? > 220.127.116.11 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. > 18.104.22.168 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. > 22.214.171.124 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? > 126.96.36.199 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 188.8.131.52). 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?
Last updated: Thu Apr 04 08:18:33 2002
9481 messages in chronological order