|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] iFCP Last Call comments
[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
black_david@emc.com Cell: +1 (978) 394-7754
---------------------------------------------------
Home Last updated: Mon Mar 18 08:18:11 2002 9174 messages in chronological order |