Subject: iFCP Last Call comments

From: [email-masked]
Date: Mon, 18 Mar 2002 00:44:19 -0500

[E] Editorial, [T] Technical

------ iFCP -10 ----------

[E] Remove Change Log in the version after a successful WG Last Call.

[E] Section 2.1 - Definitions

         Terms needed to clarify the concepts presented in this document are
         presented here.

[E] I don't like the usage of "clarify".  How about "Terms used to
describe the concepts presented in this document are defined here." ?

         Address-translation mode û A mode of gateway operation in which the
                 scope of N_PORT fabric addresses for locally attached

[E] Some tool has helpfully inserted a non-ASCII character.  MS Word
AutoCorrect
is a likely suspect.  Hunt all of these down and fix them, then discipline
the tool severely ;-).

         FC-4 - The fibre channel application layer. This layer is
                 functionally equivalent to the TCP/IP application layer.

[T] I don't understand this.  Are you equating FC-4 with OSI layer 7?  If
so, I'm not sure that is correct, and it might be better to leave out this
attempted analogy.

-- Section 3.2 - Fabric Topologies

         a)  Arbitrated Loop -- A series of N_PORTs connected together in
             daisy-chain fashion.  Data transmission between N_PORTs
             requires arbitration for control of the loop in a manner
             similar to a token ring network.

[T] That's not a fabric topology, unless the loop is fabric attached, in
which case you're in case c), Mixed Fabric.  iFCP can't support an FC-AL
loop that isn't fabric-attached.

         Depending on the topology, the N_PORT and fabric port variants
         through which a fibre channel device is attached to the network may
         be one of the following:

              Fabric Topology  Fabric Port Type    N_PORT Variant
              ---------------  ----------------    --------------

              Loop             L_PORT              NL_PORT

              Switched         F_PORT              N_PORT

              Mixed            FL_PORT             NL_PORT

                               F_PORT              N_PORT

[T] I believe the Loop line in this table does not match the other lines
and if so, this is one more reason to leave non-fabric-attached FC-AL out
of this description.

-- Section 3.3.1 - Fabric-Supplied Link Services

         All switched fabrics must provide the following services:

            Fabric F_PORT server û Services an N_PORT request to access the
            fabric for communications.

[E] "request" --> "requests"

-- Section 4.4 - iFCP Fabric Properties

         As discussed below, an
         unbounded iFCP fabric may have any number of switch elements and
         gateways.

[E] It's not "any", but the limit is a very large number by comparison to
239.
At some point the need to reuse 24-bit addresses for outbound traffic from a
single FC link behind an iFCP gateway will be a problem.  This comment also
applies to the second paragraph in Section 4.4.2.

-- 4.5 - The iFCP N_PORT Address Model

         In the iFCP protocol, an N_PORT is represented by the following
         addresses:

[E] "addresses" --> "types of addresses" to avoid implying that there's
only one alias.  Different gateways will assign different aliases to the
same N_PORT.

         The mode of gateway operation is settable in an implementation-
         specific manner.  The implementation MUST NOT allow the mode to be
         changed after the gateway begins processing fibre channel frame
         traffic.

[E] Might want to add a MUST that a gateway cannot operate in more than
one mode at the same time, and a repeat of the (implied) requirement that
all gateways in an iFCP fabric MUST operate in the same mode.

-- 4.6 - Operation in Address Transparent Mode

         b) When interoperating with locally attached fibre channel switch
            elements, each iFCP gateway MUST assume control of DOMAIN_ID
            assignments in accordance with the appropriate fibre channel
            standard or vendor-specific protocol specification.

[T] This is ok, but turns up another requirement that needs to be explicitly
stated earlier.  Any given FC N_PORT MUST NOT be behind more than one iFCP
gateway.  Address Transparent mode satisfies this because only one gateway
can become the principal switch, so the others presumably shut down, but
Address
Translation mode appears to have the potential for seriously nasty
misbehavior
unless the "iFCP gateway MUST become the principal switch" requirement is
imposed on it also.  Need to add a sentence or two on how an iFCP gateway
can be assured of becoming the principal switch.  Beyond this, the fact that
any Fabric Attached FC-AL loop can have only one FL port completes the
picture,
ensuring that a loop can't stitch two gateway domains together.  Requiring
the
iFCP gateway to be the principal switch also avoids problems with the
gateway
being unable to obtain sufficient Domain IDs from the principal switch.

-- Section 5.2.2.2 - Creating an iFCP Session

        The gateway SHALL initiate the creation of an iFCP session in
         response to a PLOGI ELS directed to a remote N_PORT from a locally
         attached N_PORT as described in the following steps.

         a) Using the D_ID field in the PLOGI frame header, locate the
            remote N_PORT descriptor.  If no descriptor exists, the iFCP
            gateway SHALL return a response of LS_RJT, with a Reason Code of
            'Unable to Perform Command Request' (0x09) and a Reason Code
            Explanation of 'Invalid N_PORT_ID' (0x1F). An iFCP session SHALL
            NOT be created.

[E] Need to explain why this is ok.  The answer is that a properly operating
FC N_PORT will have previously issued an FC nameserver query that the
gateway
translated to an iSNS query, and hence when it issues PLOGI to the result of
the nameserver query, the iSNS query response created the required
descriptor
in the gateway before being translated to the FC nameserver result.  There's
an implication here that remote N_PORT descriptors that result from iSNS
queries translated from FC nameserver queries MUST NOT be discarded as long
as any N_PORT that has issued a query for that remote N_PORT is logged into
the fabric.

       e) If a CBIND response is returned with one of the following
            statuses, the PLOGI SHALL be terminated with an LS_RJT message.
            Depending on the CBIND failure status, the Reason Code and
            Reason Explanation SHALL be set to the following values
            specified in [FC-FS].

[E] Add a statement that this plus case f) is a comprehensive list of
possible
CBIND failure statuses, as specified in Section 6.1.

         f) A CBIND response with a CBIND STATUS of "N_PORT session already
            exists" indicates that the remote gateway has concurrently
            initiated a CBIND request to create an iFCP session between the
            same pair of N_PORTs. The receiving gateway SHALL terminate this
            attempt, return the connection to the Unbound state and prepare
            to respond to an incoming CBIND request as described below.

[E] Add a sentence indicating that the "simultaneous open" race is dealt
with
by allowing the sender with the numerically larger N_PORT name to succeed in
establishing the session.

     The gateway receiving a CBIND request SHALL respond as follows:

         a) If the receiver has a duplicate iFCP session in the OPEN PENDING
            state, then the receiving gateway SHALL compare the Source
            N_PORT Name in the incoming CBIND payload with the Destination
            N_PORT Name.

         b) If the Source N_PORT Name is greater, the receiver SHALL issue a
            CBIND response of "Success" and SHALL place the session in the
            OPEN state.

[E] Add a sentence indicating that in case b), case c) will occur at the
other gateway because N_PORT names are globally unique WWNs, and hence this
gateway's duplicate session will receive a CBIND STATUS of "N_PORT session
already exists" and will be terminated in due course.

[T] There's no discussion of what to do if a TCP connection closes
unexpectedly
during this process (e.g., if closing of unbound connections is allowed at
arbitrary times for reasons such as reducing the resources consumed by
unbound
connections).  This needs to be added even if the reason in parentheses is
not
allowed.

         Upon receiving such a request, the gateway providing the
         connectivity probe SHALL transmit LTEST messages at the specified
         interval. 

[T] This requires liveness test (LTEST) messages even when the connection is
in active use.  Was that intended?

-- Section 5.2.2.4 - Use of TCP Features and Settings

[E] For Wrapped sequence detection, "Should use" in the table should be
"SHOULD use".

-- Section 5.2.3.1 - iFCP Session Completion

         In response to the Unbind message, either gateway may choose to
         close the TCP connection or return it to a pool of unbound
         connections.

[T] This assumes that Unbind is always successful.  It can fail, as
documented
in Section 6.2.  Need to specify how to deal with this (e.g., close the TCP
connection).

[T] Can an iFCP gateway reduce the pool of unbound connections (e.g., due to
demands for resources for other connections), possibly by closing them?  If
yes, need to say so, and 

-- Section 5.3 - IANA Considerations

[E] Put this near the end of the document where IANA can more easily find
it.

-- Section 5.4.1 - Encapsulation Header Format

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

[T] It's 2 - cite the FC Encapsulation draft's IANA Considerations section
as
the authority for this.

-- Section 5.4.2 - SOF and EOF Delimiter Fields

[E] Need to say that the format is specified in the FC Common Encapsulation
document
and reproduced here for convenience.

          SOF (bits 31-24 and bits 23-16 in word 0):  iFCP uses the
          following subset of the SOF fields described in [ENCAP].

[T] This is a problem because these codes are being specified in more
than one place.  I think the FC Frame Encapsulation document is the right
place for the normative specification of these codes (and see my comments
against it on the need to get IANA involved).  This would be ok as a list
of codes that are currently valid, but the specification authority needs
to be in one place.  Same comment applies to EOF.

-- Section 6 - TCP Session Control Messages

[E] There's an LS_COMMAND field in figure 16 and a second one in the iFCP
portion
of the FC Common Encapsulation header (from Section 5.4.1).

          LS_COMMAND           For a special link service ACC
                                response to be processed by iFCP, the
                                LS_COMMAND field SHALL contain bits 31
                                through 24 of the LS_COMMAND to which
                                the ACC applies. Otherwise the
                                LS_COMMAND field shall be set to zero.

When a single section discusses both fields, as Section 6 does, this gets
confusing fast.  Please rename the LS_COMMAND field in the iFCP portion of
the FC Common Encapsulation header to something like ACC_LS_COMMAND or
LS_COMMAND_ACC.

                     Request            LS_COMMAND Short Name  iFCP Support
                     -------            ---------- ----------  -----------
         Connection Bind                  0xE0       CBIND      REQUIRED
         Unbind Connection                0xE4      UNBIND      REQUIRED
         Test Connection Liveness         0xE5       LTEST      REQUIRED

[T/E] How do we know that those three values (E0, E4, and E5) will not
conflict
with some future usage by Fibre Channel?  I think the answer is that SES=1
in the iFCP flags in the header, and would be 0 in any future use of these
values in an ELS, but the use of those three values looks like an
attempt to avoid conflict and should be explained. 

-- 6.2 - Unbind Connection (UNBIND)

         Unbind Status Description
          ------------- -----------

                0       Successful û No other status
             1 û 15     Reserved
               16       Failed û Unspecified Reason
               18       Failed û Connection ID Invalid
             Others     Reserved

Unbind can fail, but earlier specification of the use of Unbind (e.g., in
Section 5.2.3.1) assumes that it cannot fail.  Description of how to deal
with Failed status needs to be added there (e.g., close the TCP connection).

-- Section 7.2 - Link Services Requiring Payload Address Translation

         For translation type 3, the receiving gateway SHALL obtain the
         information needed to fill in the field in the link service frame
         payload by converting the specified N_PORT worldwide identifier to
         a gateway IP address and N_PORT ID.  This information MUST be
         obtained through an iSNS name server query. 

[E] This requires an iSNS query for every type 3 translation received even
if
it exists locally in a Remote N_PORT descriptor.  It looks like this was
intended due to the possibility of the descriptor being stale, but I wanted
to check if that was in fact the intention.

         When the ACC response requires iFCP intervention, the receiving
         gateway MUST act as a proxy for the originator, retaining the state
         needed to process the response from the N_PORT to which the request
         was directed.

[E] That doesn't parse for me.  I think the intended meaning was
that when an ELS request is sent whose ACC will require iFCP intervention,
the ELS also requires intervention to capture the state necessary to process
the ACC.

-- 7.3 - Fibre Channel Link Services Processed by iFCP

         The following Extended and FC-4 Link Service Messages must receive
         special processing.

[T] Process question - how does this list get coordinated with T11 so that
it gets updated when T11 defines a new ELS or FC-4 LS that requires iFCP
intervention?

-- 7.3.1.1 - Abort Exchange (ABTX)

         Fields Requiring       Translation   Supplemental Data
         Address Translation     Type (see      (type 3 only)
         -------------------    section 7.2)     ------------
                                 -----------

         Exchange Originator        1, 2              N/A
         S_ID

[T] Need to specify how to choose the translation type.  This comment also
applies to RES, RES ACC, RLS, RSS, RRQ, RSI, REC and REC ACC.  It may be
best
resolved by adding additional text in Section 7.2.

-- 7.3.1.3 - Discover Address Accept (ADISC ACC)

[E] Should the Command field be 0x20 or 0x02?

         Other Special Processing:

             The Hard Address of the ELS originator SHALL be set to 0.

[T] Doesn't this also require setting the LS_COMMAND iFCP-specific field
(to be renamed) in the FC Common Encapsulation header?  This comment also
applies to all other ACC's in Section 7.

-- Section 8.2.1 - Enforcing R_A_TOV Limits

[T] The rules in this section appear to allow forwarding of all frames
received
while in Unsynchronized mode or with a timestamp of 0,0.  This looks like a
formula for violating R_A_TOV - was this intended?

-- Section 9.4.1 - Establishing the Broadcast Configuration

         The broadcast configuration is managed using facilities provided by
         the iSNS server. Specifically:

         a)  An iSNS discovery domain is created and seeded with the network
             address of the global broadcast server N_PORT.  The global
             server is identified as such by setting the appropriate N_PORT
             entity attribute.

[T] There are no means for recovery from failure, so loss of the gateway
performing the broadcast service results in loss of the broadcast service.
This needs to be explained at a minimum, and probably corrected.

-- Section 10.2.2 - Security Threats

              Conformant implementations of the iFCP
         protocol MAY use such security definitions.

[T] I don't understand this sentence.  What was intended?

-- Section 10.2.3  Interoperability with Security Gateways

         Enterprise data center networks are considered mission-critical
         facilities that must be isolated and protected from all possible
         security threats.  Such networks are usually protected by security
         gateways, which at a minimum provide a shield against denial of
         service attacks.  The iFCP security architecture is capable of
         leveraging the protective services of the existing security
         infrastructure, including firewall protection, NAT and NAPT
         services, and IPSec VPN services available on existing security
         gateways.

[T] While this is true of iFCP, iSNS has some serious issues with NAT and
NAPT,
and iFCP cannot be operated without iSNS.

-- Section 10.2.4 - Authentication

         iFCP gateways MUST use Discovery Domain information obtained from
         the iSNS server [ISNS] to determine whether the initiating fibre
         channel N_PORT should be allowed access to the target N_PORT.
         N_PORT identities used in the Port Login (PLOGI) process shall be
         considered authenticated provided the PLOGI request is received
         from the remote gateway over a secure, IPSec-protected connection.

[T] Need to say something about the IKE identities (ID payloads) used for
the authentication, and how they correspond to information obtained from
iSNS - NATs/NAPTs will cause issues here.  Just requiring an IPsec-protected
connection isn't good enough as it may allow a node not registered with iSNS
to get in.

-- Section 10.2.6  Rekeying

[E] I believe the security draft has changed in this area (small rekeying
interval example), please check it.

-- Section 10.2.7  Authorization

         Authorization is outside of the scope of this specification, and is
         seen as fully orthogonal to the iFCP security design. Such design,
         however, includes key authorization-enabling features in the form
         of Identity Payload (e.g., ID_FQDN), certificate-based
         authentication (e.g., with X509v3 certificates), and discovery
         domains [ISNS].

[T] What??  If iSNS doesn't know about an iFCP gateway, that gateway
shouldn't
be able to talk to any other iFCP gateway.  That's access control, which
counts
as authorization in my book.

-- Section 10.3.2 - Use of IKE and IPsec

         If an iFCP implementation makes use of unbound TCP connections, and
         such connections belong to an iFCP Portal with security
         requirements, then the unbound connections MUST be protected by an
         SA at all times just like bounded connections.

[E] "bounded" --> "bound"

         Upon receiving an IKE Phase-2 delete message, there is no
         requirement to terminate the protected TCP connections or delete
         the associated IKE Phase-1 SA. Since an IKE Phase-2 SA may be
         associated with multiple TCP connections, terminating such
         connections might in fact be inappropriate and untimely. An iFCP
         Portal must instead attempt to create a new Phase-2 SA while there
         are outstanding iFCP sessions.

[T] That's a problem.  If the other side is behaving in accordance with the
next paragraph ...:

         To minimize the number of active Phase-2 SAs, IKE Phase-2 delete
         messages may be sent for Phase-2 SAs whose TCP connections have not
         handled data traffic for a while. To minimize the use of SA
         resources while the associated TCP connections are idle, creation
         of a new SA may be deferred until new data is to be sent over the
         connections.

... and is deleting the Phase-2 SAs because it lacks the resources to
support
them, immediately creating a new Phase-2 SA in response to delete messages
risks
livelock (massive churn in Phase-2 SA creation/destruction).  Creating a
new Phase-2 SA in response to a Phase-2 delete message SHOULD be deferred
until
there is traffic to send over that SA.

-- Section 13. - Normative References

[E] RFC 2451 reference shows up twice.

-- Section A.2 - Link Services Processed Transparently

           ACC       Accept

[T] Is that right?  I thought this was intercepted in some cases, as
indicated
in Table 6.

           FDISC     Discover F_Port Service Parameters
           FLOGI     F_Port Login
           RTV       Read Timeout Value

[T] Definitely wrong - the iFCP gateway has to implement these itself as
specified in Section 9.1.

           LINIT     Loop Initialize
           LPC       Loop Port Control
           LSTS      Loop Status
           SCL       Scan Remote Loop

[T] I don't have time to check these, but I'm suspicious about whether
anything that has "Loop" as part of its name can/should be forwarded
transparently into an FC fabric, although SCL seems plausible.  Please\
verify whether these are transparent.

           RSCN      Registered State Change Notification
           SCN       State Change Notification
           SCR       State Change Registration

[T] Those can't be transparent, as Section 9.2 requires the iFCP gateway to
implement them.

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
[email-masked]         Cell: +1 (978) 394-7754
---------------------------------------------------