IPS C. Monia
F. Travostino
J. Tseng
Internet Draft Nishan Systems
Document: draft-ietf-ips-ifcp-wglcc-00.txt May 2002
Category: Informational
Responses to iFCP Rev. 10 Last Call Comments
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Monia, et-al Category - Expiration [Page 1]
Responses to iFCP Rev. 10 Last Call Comments May 2002
Status of this Memo...................................................1
Abstract..............................................................3
Change Log............................................................3
1. Conventions used in this document...............................3
2. Comments from David Black.......................................3
3. Comments From Elizabeth Rodriguez..............................21
4. Comments from Brian Forbes.....................................25
5. Comments from Mallikarjun Chadalapaka..........................30
6. Security Considerations........................................43
7. References.....................................................43
8. Author's Addresses.............................................44
Full Copyright Statement.............................................44
Monia, et-al Category - Expiration [Page 2]
Responses to iFCP Rev. 10 Last Call Comments May 2002
Abstract
This document is a compilation of responses to review comments
received for revision 10 if the iFCP specification [IFCP] during the
preliminary last call period from 3/4/2002 to 3/18/2002.
Change Log
Revision 0 of draft-monia-ips-ifcplcc-00 to draft-ietf-ips-ifcp-
wglcc-00.txt, revision 0.
Comment 49 -- Modified to comply with IESG policy on number of co-
authors.
Modified the following responses per feedback from David Black and
Mallikarjun Chadalapaka.
Comment 5,
Comment 12,
Comment 94,
Comment 104,
Comment 110.
Comment 120
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].
In the following, [E] designates an editorial comment, [T] a
technical comment.
The keywords 'Rejected' or 'Accepted' indicate fundamental agreement
or disagreement with the position stated in the comment.
The keyword 'Response' is used when a comment is predicated on a
query. The explanatory text should be consulted for details.
2. Comments from David Black
Comment 1. [E} Page 5, Change Log
Remove Change Log in the version after a successful WG Last
Call.
Accepted
Comment 2. [E] Section 2.1, page 7, paragraph 1
"Terms needed to clarify the concepts presented in this
document are presented here."
Monia, et-al Category - Expiration [Page 3]
Responses to iFCP Rev. 10 Last Call Comments May 2002
I don't like the usage of "clarify". How about "Terms used to
describe the concepts presented in this document are defined
here." ?
Accepted
The text will be revised as suggested.
Comment 3. [E] Section 2.1, Address Translation Mode Definition
Some tool has helpfully inserted non-ASCII characters. MS Word
AutoCorrect is a likely suspect. Hunt all of these down and
fix them, then discipline the tool severely ;-).
Accepted.
Comment 4. [T] Section 2.1, Definition of FC-4 Layer
"FC-4 - The fibre channel application layer. This layer is
functionally equivalent to the TCP/IP application layer."
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.
Accepted
The definition will be changed to:
"FC-4 - The fibre channel mapping of an upper level protocol,
such as [FCP-2], the fibre channel SCSI mapping."
Comment 5. [T] Section 3.2, page 10
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."
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.
Accepted in part
The terminology will be changed to "fibre channel network
topologies".
In addition, the following definition will be added:
"Fabric -- From [FC-FS]: "The entity which interconnects
N_PORTs attached to it and is capable of routing frames by
using only the address information in the fibre channel frame."
Monia, et-al Category - Expiration [Page 4]
Responses to iFCP Rev. 10 Last Call Comments May 2002
With regard to FC-AL support, an iFCP gateway implementation
can emulate either a public (fabric attached) or private loop
environment. The gateway may support a private loop by
representing remotely attached devices as if they were resident
on a local loop and by emulating the semantics required to
support the loop control frames and primitives. Since these
functions are implemented internally by the gateway, iFCP
protocol support is not required. However, the specification
should explicitly prohibit the forwarding of fibre channel loop
control frames via iFCP.
A related issue is support for the set of extended link
services for remote loop control, such as LINIT (Loop
Initialize). These are standard link service messages
addressed to the loop fabric address (LFA) of the FL port
controlling the loop. A gateway that chooses to expose remote,
loop-connected devices as NL_Ports must also expose the LFA.
To do so, it should assign the local alias such that the
corresponding LFA or the remote loop can be derived by setting
the port_id component of the alias to zero in accordance with
[FC-FS].
The specification will be modified to discuss these loop
topology support issues.
Comment 6. [T] Section 3.2, page 11, para 5
"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"
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.
Accepted in part
Since the loop topology can be supported, it should remain in
the table. However, the terminology should be changed per
Comment 5 and the table modified as shown below:
"FC Network Topology N_PORT Variant FC Network Interface
-------------------- -------------- --------------------
Monia, et-al Category - Expiration [Page 5]
Responses to iFCP Rev. 10 Last Call Comments May 2002
Loop NL_PORT L_PORT
Switched N_PORT F_PORT
Mixed NL_PORT FL_PORT via L_PORT"
In the case of a mixed fabric, additional supporting text will
be provided.
Comment 7. [E] Section 3.3.1, page 14, para 2
"All switched fabrics must provide the following services:
"Fabric F_PORT server Services an N_PORT request to access
the fabric for communications.
Change "request" to "requests"
Accepted
Replace special character and reword as follows:
"Fabric F_PORT server -- Services N_PORT requests to access the
fabric for communications."
Comment 8. [E] Section 4.4, page 21, para 2
"As discussed below, an unbounded iFCP fabric may have any
number of switch elements and gateways."
It's not "any", but the limit is a very large number by
comparison to 239.
Accepted
The sentence will be changed to:
"As discussed below, an unbounded iFCP fabric is not limited to
239 switches and gateways."
Comment 9. [T] Section 4.4 - iFCP Fabric Properties
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.
Accepted
A discussion of address re-use issues will be added to the
spec.
Comment 10. [E] Section 4.5, page 23, para 2
Monia, et-al Category - Expiration [Page 6]
Responses to iFCP Rev. 10 Last Call Comments May 2002
"In the iFCP protocol, an N_PORT is represented by the
following addresses:"
Change "addresses" to "types of addresses" to avoid implying
that there's only one alias. Different gateways will assign
different aliases to the same N_PORT.
Rejected
The description of an alias will be revised as follows:
b) "A 24-bit N_PORT alias. The fibre channel N_PORT address
assigned by each gateway operating in address translation
mode to identify a remotely attached N_PORT.
Frame traffic is intercepted by an iFCP gateway and
directed to a remotely attached N_PORT by means of the
N_PORT alias. The address assigned by each gateway is
unique within the scope of the gateway region."
Comment 11. [T] Section 4.5, pp 24, para 14
"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."
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.
Accepted
Comment 12. [T] Section 4.6. pp 24, para 2
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."
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
Monia, et-al Category - Expiration [Page 7]
Responses to iFCP Rev. 10 Last Call Comments May 2002
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.
Accepted in Part
An N_PORT can be behind more than one gateway if the following
rules are observed:
a) The gateways MUST cooperate in the assignment of N_PORT IDs
for locally attached devices and aliases for remotely
attached devices such that each local or remotely attached
N_PORT has one and only one N_PORT address within the scope
of the gateway region.
b) All iFCP frame traffic between any two N_PORTs MUST flow
through a single iFCP session. However, each session may
traverse a different gateway attached to the region.
In order to meet these constraints, a multi-gateway
implementation may require an out of band mechanism for
redirecting frame traffic from one physical gateway to another.
The above will be added to the specification.
Comment 13. [T] Section 5.2.2.2, pp 32, para 4
"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."
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.
Monia, et-al Category - Expiration [Page 8]
Responses to iFCP Rev. 10 Last Call Comments May 2002
Accepted in part
Although a name server query is almost always done in practice
prior to a PLOGI, an N_PORT compliant with [FC-FS] is not
required to do so. For that reason, the specification should
cover the case where a fibre channel device attempts to send
frames to an address without having executed a previous name
server query.
Also, while the policies for remote N_PORT descriptor retention
are implementation-specific, the specification should at least
contain recommendations. In that regard, the following added
text is proposed:
"Remote N_PORT Descriptors should be reclaimed based on a last
in, first out policy.
"An iFCP implementation should have sufficient resources to
insure that a newly created descriptor is not reclaimed before
the referencing iFCP session is created."
Comment 14. [E] Section 5.2.2.2 - Creating an iFCP Session
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]."
Add a statement that this plus case f) is a comprehensive list
of possible CBIND failure statuses, as specified in Section
6.1.
Accepted
Comment 15. [E] Section 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 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."
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.
Accepted
Comment 16. [E] Section 5.2.2.2, pp 34, para 2
Monia, et-al Category - Expiration [Page 9]
Responses to iFCP Rev. 10 Last Call Comments May 2002
"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."
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.
Accepted
Comment 17. [T] Section 5.2.2.2 - Creating an iFCP Session
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.
Accepted
Comment 18. [T] Section 5.2.2.2, pp 35, para 4
"Upon receiving such a request, the gateway providing the
connectivity probe SHALL transmit LTEST messages at the
specified interval."
This requires liveness test (LTEST) messages even when the
connection is in active use. Was that intended?
Response
The intent is to require LTEST messages at the specified
interval regardless of whether or not there is other traffic.
Comment 19. [E] Section 5.2.2.4 - Use of TCP Features and
Settings
For Wrapped sequence detection, "Should use" in the table
should be "SHOULD use".
Accepted
Monia, et-al Category - Expiration [Page 10]
Responses to iFCP Rev. 10 Last Call Comments May 2002
Comment 20. [T] Section 5.2.3.1, pp 38, para 1
"In response to the Unbind message, either gateway may choose
to close the TCP connection or return it to a pool of unbound
connections."
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).
Accepted
The sentence will be modified as follows:
"Upon successful completion of an Unbind operation, either
gateway may choose to close the TCP connection or return it to
a pool of unbound connections."
The processing for the failure cases will also be specified.
Comment 21. [T] Section 5.2.3.1 - iFCP Session Completion
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.
Accepted
A gateway may close an unbound connection due to resource
demands. The spec will be modified appropriately.
Comment 22. [E] Section 5.3 - IANA Considerations
Put this near the end of the document where IANA can more
easily find it.
Accepted
Comment 23. [T] Section 5.4.1, pp 40, para 1
"Protocol# IANA-assigned protocol number identifying
the protocol using the encapsulation. For iFCP the value is
(/TBD/)."
It's 2 - cite the FC Encapsulation draft's IANA Considerations
section as the authority for this.
Accepted
Comment 24. [E] Section 5.4.2 - SOF and EOF Delimiter
Fields
Monia, et-al Category - Expiration [Page 11]
Responses to iFCP Rev. 10 Last Call Comments May 2002
Need to say that the format is specified in the FC Common
Encapsulation document and reproduced here for convenience.
Accepted
Comment 25. [T] Section 5.4.2 - SOF and EOF Delimiter
Fields
"SOF (bits 31-24 and bits 23-16 in word 0): iFCP uses the
following subset of the SOF fields described in [ENCAP].
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.
Accepted in Part
The specification will be revised in accordance with Comment
24.
Comment 26. [E] Section 6, pp 46
"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."
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).
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.
Accepted
The mnemonic will be changed to LS_COMMAND_ACC.
Comment 27. [T/E] Section 6 - TCP Session Control Messages
Request LS_COMMAND Short Name iFCP Support
------- ---------- ---------- -----------
Connection Bind 0xE0 CBIND REQUIRED
Unbind Connection 0xE4 UNBIND REQUIRED
Test Connection Liveness 0xE5 LTEST REQUIRED
Monia, et-al Category - Expiration [Page 12]
Responses to iFCP Rev. 10 Last Call Comments May 2002
[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.
Accepted
That is correct. These values were chosen as patterns readily
distinguishable by a protocol analyzer.
Comment 28. [T] 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).
Accepted
Comment 29. [E] Section 7.2, pp 56, para 7
"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."
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.
Accepted
The intention was to update a potentially stale entry or force
the creation of a new descriptor.
Comment 30. [E] Section 7.2, pp 57, para 3
Monia, et-al Category - Expiration [Page 13]
Responses to iFCP Rev. 10 Last Call Comments May 2002
"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."
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.
Accepted
The text will be modified as follows:
"When the ACC response requires iFCP intervention, the
receiving gateway MUST intervene to process the response from
the N_PORT to which the request was directed."
Comment 31. [T] 7.3 - Fibre Channel Link Services Processed
by iFCP
"The following Extended and FC-4 Link Service Messages must
receive special processing."
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?
Response
The specification must be revised to track the evolving fibre
channel specifications, including, among other things, the
addition of new link services that require special processing.
Comment 32. [T] 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"
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.
Accepted
Comment 33. [E] 7.3.1.3 - Discover Address Accept (ADISC
ACC)
Monia, et-al Category - Expiration [Page 14]
Responses to iFCP Rev. 10 Last Call Comments May 2002
Should the Command field be 0x20 or 0x02?
Response
The command field for all ACC response frames is 0x02. No
change to the specification is required.
Comment 34. [T] 7.3.1.3 - Discover Address Accept (ADISC
ACC)
"Other Special Processing:
The Hard Address of the ELS originator SHALL be set to 0."
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.
Accepted
The specification will be modified accordingly.
Comment 35. Section 8.2.1 - Enforcing R_A_TOV Limits
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 formula for violating
R_A_TOV - was this intended?
Response
The intention was to abort all iFCP sessions and not allow the
creation of new ones. The specification will be revised
accordingly.
Comment 36. [T] 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."
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.
Accepted
Monia, et-al Category - Expiration [Page 15]
Responses to iFCP Rev. 10 Last Call Comments May 2002
An implementation may designate a local server as a standby
global broadcast server. The local server uses the LTEST
message to determine if the global server is functioning and
may assume control if not.
The specification will be revised accordingly.
Comment 37. [T] Section 10.2.2, page 82, para 1
"Conformant implementations of the iFCP protocol MAY use such
security definitions."
I don't understand this sentence. What was intended?
Accepted
The paragraph will be changed to:
ôIt is imperative to thwart these attacks, given that an iFCP
gateway is the last line of defense for a whole fibre channel
island, which may include several hosts and fibre channel
switches. To do so, the iFCP gateway must implement and may use
confidentiality, data origin authentication, integrity, and
replay protection on a per-datagram basis. The iFCP gateway
must implement and may use bi-directional authentication of the
communication endpoints. Finally, it must implement and may use
a scalable approach to key management.ö
Comment 38. [T] Section 10.2.3, pp 82, para 1
"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."
While this is true of iFCP, iSNS has some serious issues with
NAT and NAPT and iFCP cannot be operated without iSNS.
Rejected
iSNS issues with NA(P)Ts are thought to be resolved (see
Section 3.6 in the iSNS specification). iSNS has at least two
non-exclusive options to cope with NA(P)Ts, a) the use of FQDNs
instead of IP addresses, and b) the option to establish a
confederation of iSNS servers and have them doctor IP numbers
in transit as part of their mutual confederation contract.
Comment 39. [T] Section 10.2.4, pp 82, para 1
Monia, et-al Category - Expiration [Page 16]
Responses to iFCP Rev. 10 Last Call Comments May 2002
"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."
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.
Accepted in part
It would be premature to enumerate ID payloads in section
10.2.4, which describes the scope of the overall security
design prior to any IKE/IPsec requirement (to follow in
sections 10.3). The requested information will be supplied
after the last paragraph in section 10.3.1.
Regarding intervening NA(P)Ts between iSNS clients and servers,
it is possible to put a proxy iSNS server at the boundary
between addressing domains. Such proxy will terminate the
IKE/IPSec so that the ID_IPV4_ADDR identity can be used
natively by IKE. It is also possible to use the second method
described in the response to comment 38 -- a confederation of
iSNS servers where the NAT(P)T mediation now occurs between
iSNS servers.
Admission control is performed by the iSNS server, based upon
the Discovery Domain (DD) configuration information stored in
that iSNS server. Once the authenticity of a gateway is
verified (e.g., via a pre-shared key) and IPsec SAs are
established, then the gateway is trusted to behave according to
the specification, which mandates a handshake with iSNS for
admission.
Comment 40. [E] Section 10.2.6 Rekeying
I believe the security draft has changed in this area (small
rekeying interval example), please check it.
Response
We appear to be consistent with [SECIPS] version 11 still, end
of section 5.4, when BellareÆs results are taken into
consideration. Therefore, no change to iFCP is required.
Comment 41. [T] Section 10.2.7 Authorization
Monia, et-al Category - Expiration [Page 17]
Responses to iFCP Rev. 10 Last Call Comments May 2002
"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]."
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.
Accept
The paragraph will be re-written as follows.
ôBasic access control properties stem from the requirement that
the communicating iFCP gateways be known to one or more iSNS
servers before they can engage in iFCP exchanges. The optional
use of Identity Payloads (e.g., ID_FQDNs), certificate-based
authentication (e.g., with X509v3 certificates), and discovery
domains [ISNS] enables authorization schemas of increasing
complexity. The definition of such schemas (e.g., role-based
access control) is outside of the scope of this specification."
Comment 42. [E] Section 10.3.2, pp 86, para 8
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.
Change "bounded" to "bound".
Accepted
Comment 43. [T] Section 10.3.2, pp 86, para 9
"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."
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
Monia, et-al Category - Expiration [Page 18]
Responses to iFCP Rev. 10 Last Call Comments May 2002
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.
Accepted
We shall be removing the misleading sentence ôAn iFCP Portal
must instead attempt to create a new Phase-2 SA while there are
outstanding iFCP sessions." and promote from may to SHOULD
prior to the word ædeferredÆ.
The resulting modified text is shown below:
"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.
"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 SHOULD be deferred
until new data is to be sent over the connections."
Comment 44. [E] Section 13. - Normative References
RFC 2451 reference shows up twice.
Accepted
Comment 45. [T] Section A.2 - Link Services Processed
Transparently
"ACC Accept"
Is that right? I thought this was intercepted in some cases,
as indicated in Table 6.
Response
The ACC description will be modified to discriminate between
the transparent and non-transparent cases.
Comment 46. [T] Section A.2 - Link Services Processed
Transparently
Monia, et-al Category - Expiration [Page 19]
Responses to iFCP Rev. 10 Last Call Comments May 2002
FDISC Discover F_Port Service Parameters
FLOGI F_Port Login
RTV Read Timeout Value
Definitely wrong - the iFCP gateway has to implement these
itself as specified in Section 9.1.
Accepted in Part
Special link service messages are those which require
intervention by an iFCP protocol implementation before they are
passed to the destination N_PORT. Transparent link service
messages are passed to the destination N_PORT without such
intervention. In that regard, the above link services are
processed transparently.
The specification will be modified to make the above
distinction clearer and the section will be re-titled as: "Link
Services Processed Transparently by the iFCP layer".
Comment 47. [T] Section A.2 - Link Services Processed
Transparently
LINIT Loop Initialize
LPC Loop Port Control
LSTS Loop Status
SCL Scan Remote Loop
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.
Response
SCL must be processed as a special link service message. iFCP
will be modified accordingly. The remaining link services
listed above are transparent.
Comment 48. [T] Section A.2 - Link Services Processed
Transparently
RSCN Registered State Change Notification
SCN State Change Notification
SCR State Change Registration
Those can't be transparent, as Section 9.2 requires the iFCP
gateway to implement them.
Response
See response to Comment 46.
Monia, et-al Category - Expiration [Page 20]
Responses to iFCP Rev. 10 Last Call Comments May 2002
3. Comments From Elizabeth Rodriguez
Comment 49. [E] Title Page, Number of Authors
Looks like you have 8 authors listed. Rule of thumb I think is
6. I am having difficulty locating the guidelines, but may want
to consider how you can move a couple of the listed authors
into an acknowledgements section of some sort. With 8, it may
or may not get flagged by the IESG...
Accepted
We will reduce the roster of co-authors in accordance with IETF
policy.
Comment 50. [E] Capitalize Fibre Channel
I believe "Fibre Channel" should be capitalized throughout
document.
Rejected
The specification is consistent with T11 lower case usage.
Comment 51. [E] Acknowledgements
Braces around SECIPS do not match.
Accepted
Comment 52. [E] Section 1.2
"NCITS" should be "INCITS".
Accepted
Comment 53. [E] "About This Document"
There should be a page break before this section.
Accepted
Comment 54. [E] Definitions, iFCP Frame
Technically, the title is of the comment encapsulation
specification is "FC Frame Encapsulation".
Accepted
Comment 55. [E] Definitions
Monia, et-al Category - Expiration [Page 21]
Responses to iFCP Rev. 10 Last Call Comments May 2002
In the definitions of "N_PORT Alias" and "N_PORT I/D", two
dashes should be used to separate the term from the body of the
definition.
Accepted
Comment 56. [E] Section 3, pp 9, para 1
"Fibre channel is a frame-based, serial technology designed for
peer-to-peer communication between devices at gigabit speeds
and with low overhead and latency."
May want to change to gigabit or greater speeds. Technically,
2, 4, 10 gigabit speeds are still gigabit, but many today
interpret gigabit strictly as 1 gigabit.
Rejected
The term 'speeds' implies rates of 1Gb/sec and above.
Comment 57. [E] Section 3.1
a) "N_PORTs -- The end points for fibre channel traffic. In
the FC standards, N_PORT interfaces have several variants,
depending on the topology of the fabric to which they are
attached. As used in this specification, the term applies
to any one of the variants."
Suggestion -- sometimes referred to in literature as Nx_PORTs?
Rejected
A parenthetical Nx_PORT digression does not add any value to
the iFCP specification, given that the following statement
claims that N_PORT is used for any such variants.
Comment 58. [E] 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."
Accepted in part
Rewrite as:
a) ôArbitrated Loop -- A series of N_PORTs connected together
in daisy-chain fashion. Loop-connected N_PORTS are referred
to as NL_PORTS. Data transmission between NL_PORTS
requires...ö
Comment 59. [E] Section 3.3, pp 13, para 6
Monia, et-al Category - Expiration [Page 22]
Responses to iFCP Rev. 10 Last Call Comments May 2002
"FC-4 û- Application protocols, such as FCP, the fibre channel
SCSI protocol."
Reword to read: "...such as FCP, commonly used abbreviation for
"Fibre Channel Protocol for SCSI"
Accepted in part
The sentence will be revised to read: "...such as the fibre
channel protocol for SCSI (FCP)."
Comment 60. [E] Section 3.7, pp 16, par 2
"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 think the term MAC is inappropriate here -- MAC is really an
ethernet term. Something like physical world wide unique
address, similar to an ethernet MAC address... Or ... represent
the physical MAC like address...
Accepted
The text will be changed to:
"The source and destination N_PORT fabric addresses embedded in
the S_ID and D_ID fields represent the physical addresses of
the originating and receiving N_PORTs."
Comment 61. [E] Section 3.8, Fibre Channel Transport
Services
Does class 6 still exist, or has it been made obsolete?
Response
Class 6 is still specified in [FC-FS].
Comment 62. [E] Section 4.5, pp 24, para 5
"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."
Does this need to be qualified -- e.g. MUST NOT allow the mode
to be changed after the gateway begins processing Fibre Channel
traffic without first terminating all connections to that
gateway, or some such -- in other words, really someone can
change the mode of operation, but just cannot do so while the
gateway is in use.
Monia, et-al Category - Expiration [Page 23]
Responses to iFCP Rev. 10 Last Call Comments May 2002
Rejected
The specification will not be changed. The intent is to latch
the operational mode after gateway power is turned on and the
gateway begins handling FC frame traffic. A change in
operational mode is not intended to be easy or graceful.
Comment 63. [E] Section 5.2.2.1, pp 31, para 9
"When creating a descriptor in response to an incoming CBIND
request, the iFCP gateway SHALL perform an iSNS name server
query using the worldwide port name of the remote N_PORT in the
SOURCE N_PORT NAME field within the CBIND payload. The
descriptor SHALL be filled in using the query results."
Need to make sure that iSNS gets through WG last call soon as
well, since this is a normative dependency.
Accepted
Comment 64. [E] Section 5.4, pp 39, para 1
"This section describes the iFCP encapsulation of fibre channel
frames. The encapsulation is based on the common encapsulation
format defined in [ENCAP]."
The reference to "common encapsulation" should be "FC Frame
Encapsulation".
Rejected
The reference is appropriate.
Comment 65. [E] Section 6.2, Unbind Connection (UNBIND)
It should be noted that the Unbind status codes listed in this
section are decimal values.
Accepted
The rules for numeric representation will be added to the
"Conventions" section.
Comment 66. [E] Section 7, pp 53
a) "Transparent û The link service message and reply MUST be
transported to the receiving N_PORT by the iFCP gateway
without altering the message payload. The link service
message and reply are not processed by the iFCP
implementation."
Since iFCP has Transparent and Translation modes, use of the
term transparent here might get confusing -- Transparent is
Monia, et-al Category - Expiration [Page 24]
Responses to iFCP Rev. 10 Last Call Comments May 2002
referring to the fact that the link service must be propogated
across the IP network, correct? As opposed to a link service
that is applicable only to transparent mode...
Accepted
The term "transparent" in this context will be changed to
"pass-though".
4. Comments from Brian Forbes
Comment 67. [E] Section 2.1, Special Characters
For some reason the file contains a number of occurrences of
the character <funny character> instead of a hyphen or dash.
Occurs throughout the text.
Accepted
Comment 68. [E] Section 2.1, Definitions
"iFCP Session - An association created when an N_PORT sends a
PLOGI request to a remotely attached N_PORT. It is comprised of
the N_PORTs and TCP connection that carries traffic between
them."
Grammar: ôit is comprised ofö should be ôit comprisesö.
Accepted
Comment 69. [E] Section 2.1, Definitions
"N_PORT Alias -- The N_PORT address assigned by a gateway to
represent a remote N_PORT accessed via the iFCP protocol. When
routing frame traffic in address translation mode, the gateway
automatically converts N_PORT aliases to N_PORT network
addresses and vice versa."
Consistency: in the list of 2.1 definitions, some entries use a
double hyphen and others only a single one (which at least one
reader interpreted as a change in level)
Accepted
Comment 70. [E] Section 3.1, The Fibre Channel Network
"Unlike a layered network architecture, a fibre channel
network is largely..."
Remove the extra space after the comma.
Accepted
Monia, et-al Category - Expiration [Page 25]
Responses to iFCP Rev. 10 Last Call Comments May 2002
Comment 71. [E] Section 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"
Parallel structure: ôand is not intendedö seems to read better
as ôand not intendedö
Accepted
Text will be changed to read:
"Time Server û- Intended for the management of fabric-wide
expiration timers or elapsed time values and not intended for
precise time synchronization"
Comment 72. [E] Section 3.7.1, page 6, para 3
"...The value of the Domain I/D ranges from 1 to 239 (0xEF)."
Both ôIDö and ôI/Dö are used to mean ôidentifierö within the
same paragraph. Common usage suggests ôIDö throughout. Also
occurs elsewhere, e.g. page 21
Accepted
Comment 73. [E] Section 3.7.1, page 17, para 3
For some reason the file contains a number of occurrences of a
non-ascii character instead of an apostrophe. Also occurs on
pages 64 for example.
Accepted
Comment 74. [E] Section 3.7.1, page 17, para 4
ôFLOGIö: this is the first occurrence of this FC term; it
should be spelled out here or a forward reference could be
provided
Accepted
Comment 75. [E] Section 3.9, page 18. item a)
a) "Fabric Login (FLOGI) -- An operation whereby the N_PORT
registers its presence on the fabric, obtains fabric
parameters, such as classes of service supported, and
receives its N_PORT address,"
Reads better without the comma after ôfabric parametersö.
Monia, et-al Category - Expiration [Page 26]
Responses to iFCP Rev. 10 Last Call Comments May 2002
Accepted
Comment 76. [E] Section 4, page 18, para 3
"Within the fibre channel device domain, fabric-addressable
entities consist of other N_PORTs and devices internal to the
fabric that perform the fabric services defined in [FC-GS3]."
ôdevicesö is possibly ambiguous here, could say ôFC devicesö or
iFCP devicesö depending on the intent.
Accepted
Text will be changed to:
"Within the fibre channel device domain, fabric-addressable
entities consist of other N_PORTs and fibre channel devices
internal to the fabric that perform the fabric services defined
in [FC-GS3]."
Comment 77. [E] Section 4.6.1, Page 25, Para 1
"As described in section 4.6, each gateway and fibre channel
switch in a bounded iFCP fabric MUST have a unique domain I/D.
In a gateway region containing fibre channel switch elements,
each element obtains a domain I/D by querying the principal
switch as described in [FC-SW2] -- in this case the iFCP
gateway itself. The gateway in turn MUST obtain domain I/Ds on
demand from the iSNS name server acting as the central address
allocation authority. In effect, the iSNS server assumes the
role of principal switch for the bounded fabric. In that case,
the iSNS database contains:"
The fact that a gateway can act as the FC principal switch is
mentioned in this section and others, but there seems to be no
normative text determining when it must do so. This will be
obvious to a knowledgeable reader, or perhaps is covered in an
ancillary document, but given the care taken elsewhere to
provide normative language for æobviousÆ functionality it seems
to be an oversight
Rejected
Since the paragraph is intended to describe behavior that is
normatively specified elsewhere, the use of "MUST" is
incorrect. The text will be changed to the following:
"As described in section 4.6, each gateway and fibre channel
switch in a bounded iFCP fabric has a unique domain I/D. In a
gateway region containing fibre channel switch elements, each
element obtains a domain I/D by querying the principal switch
as described in [FC-SW2] -- in this case the iFCP gateway
itself. The gateway in turn obtains domain I/Ds on demand from
Monia, et-al Category - Expiration [Page 27]
Responses to iFCP Rev. 10 Last Call Comments May 2002
the iSNS name server acting as the central address allocation
authority. In effect, the iSNS server assumes the role of
principal switch for the bounded fabric. In that case, the iSNS
database contains..."
Comment 78. [E] Section 5.2.2.3, page 35, paras 3 and 4
These two paragraphs use the terms æheartbeatÆ and
æconnectivity probeÆ as informal synonyms for LTESTs. Use of
the same synonym in both places would keep the reader from
wondering whether the two synonyms represent the same concept.
Accepted
Comment 79. [E] Section 5.2.2.4.3, page 37, para 1
"Window scaling, as specified in [RFC1323], allows full
utilization of links with large bandwidth - delay products and
should be supported by an iFCP implementation."
Is ôshouldö intended to be normative (capitalized)?
Response
The lower case usage is intentional. The goal is to reflect a
desirable bias rather than the sort of mandate defined in
[RFC2119].
Comment 80. [E] Section 5.2,3, page 32, items c) and d)
a) "For an FC frame received from the IP network, a gateway
detects a CRC error in the encapsulation header. The gateway
shall abort the session as described in section....
b) "The TCP connection associated with the login session fails
for any reason. The gateway detecting the failed connection
shall abort the session as described in section...."
ôshallö should be capitalized.
Accepted
Comment 81. [E] Section 5.4, page 39, last paragraph
"When operating in Address Translation mode, (see section ...)
the iFCP gateway must recalculate the fibre channel CRC."
ômustö should be in caps.
Accepted
Comment 82. [E] Section 5.4, page 41, "TRN" mnemonic
Monia, et-al Category - Expiration [Page 28]
Responses to iFCP Rev. 10 Last Call Comments May 2002
ItÆs unfortunate that ôTRNö can be read as either ôtransparentö
or ôtranslationö and therefore has less mnemonic value.
Accepted
"TRN", the mnemonic for "transparent mode", will be changed to
"TRP".
Comment 83. [E] Section 6.2, page 49, para 1
"UNBIND is used to release a bound TCP connection and.
optionally, return it to the pool of unbound TCP connections."
Punctuation: ôand. optionally, ö should be ôand optionallyö.
Accepted
Comment 84. [E] Section 7.3, page 58, para 2
"The formats of each special link service message, including
supplemental data where applicable, are shown in the following
sections."
ôThe formats of eachà message areö is awkward, suggest ôThe
format of eachà message isö.
Accepted
Comment 85. [E] Section 7.3.1.6, page 63, para 2
"This ELS shall always be sent as an augmented ELS regardless
of the translation mode in effect."
"Shall" should be capitalized.
Accepted
The text must also be modified to replace "augmented" with
"special", as given below.
"This ELS SHALL always be sent as a special ELS regardless of
the translation mode in effect."
[E] Section 7.3.1.14, page 71, last paragraph
"The size of each frame to be sent to the destination N_PORT
MUST NOT exceed the maximum frame size that the destination
N_PORT can accept. The sequence identifier in each frame
header SHALL be copied from the augmented ELS and the sequence
count shall be monotonically increasing."
"Shall" should be capitalized.
Monia, et-al Category - Expiration [Page 29]
Responses to iFCP Rev. 10 Last Call Comments May 2002
Accepted
Comment 86. [E] Section 10.2.4, page 82, paras 1 and 2
"iFCP is a peer-to-peer protocol. iFCP sessions may be
initiated by either or both peer gateways. Consequently, bi-
directional authentication of peer gateways MUST be provided.
"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."
These paragraphs seem to be statements of required
functionality but are too general to use normative language
(ôMUSTö). Later sections contain the normative text necessary
to cover these topics.
Accepted
Comment 87. [E] Section 10.2.5, page 82, para 1
See Comment 86.
Accepted
Comment 88. [E] Section 10.2.6, pages 82 and 82, all
paragraphs
See Comment 86.
Accepted
5. Comments from Mallikarjun Chadalapaka
Comment 89. [E] Section 1.2
"...standards controlled by NCITS T10 and T11."
"NCITS" should be "INCITS".
Accepted
Comment 90. [E] 2.1 Definitions
"Gateway Region -- The portion of an iFCP fabric accessed
through an iFCP gateway. Fibre channel devices in the region
Monia, et-al Category - Expiration [Page 30]
Responses to iFCP Rev. 10 Last Call Comments May 2002
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."
Accepted
The definition will be changed to the following:
"Gateway Region -- The portion of an iFCP fabric accessed
through an iFCP gateway by a remotely attached N_PORT. Fibre
channel devices in the region consist of all those locally
attached to the gateway."
Comment 91. [T] Section 3.3.1, pp 14, para 7
"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.
Response
See Comment 71 for the proposed change to this section.
The characterization is found in the literature and based on
the following from the [FC-GS3] specification, section 7, page
161.
"The Time Service is provided to serve time information that is
sufficient for managing expiration time."
Comment 92. [T] Section 3.7, pp 14, para 2
"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.
Accepted
Monia, et-al Category - Expiration [Page 31]
Responses to iFCP Rev. 10 Last Call Comments May 2002
See Comment 60.
Comment 93. [E] 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.
Accepted
The text will be changed to:
"The iFCP protocol enables the implementation of fibre channel
fabric functionality on an IP network."
Comment 94. [E] Section 4, pp 20, para 1
"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?
Response
The specification will be revised to emphasize that the figure
is but one example of a supported implementation. It was
intended to parallel the earlier fibre channel fabric example
as a way of showing the transition to an equivalent iFCP
fabric.
The selected example was chosen because it was easier to depict
within the constraints of ASCII text. An E_PORT example could
have also been used. In either case, the device incorporating
iFCP portal functionality would be called an "iFCP gateway".
The considerations to be addressed when connecting multiple
iFCP portals to a gateway region are discussed in Comment 12.
Comment 95. [E] section 4, pp 20, para 2
"... channel switch element. At this interface, remote N_PORTs
are presented as fabric-attached devices. Conversely, on the IP
Monia, et-al Category - Expiration [Page 32]
Responses to iFCP Rev. 10 Last Call Comments May 2002
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".
Rejected
The logical fibre channel device represents the layer 4
abstraction visible on the IP network.
Comment 96. [E] Section 4.1, pp 20, para 1
"...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"?
Response
More accurately, "fabric type" should be changed to "fibre
channel network topology." The specification will be changed
accordingly. See Comment 5.
Comment 97. [E] Section 4.1, pp 20, para 1
"...present locally attached N_PORTs as logical iFCP devices."
It may be useful to define "iFCP device" in section 2.1.
Rejected
From section 2.1:
"Logical iFCP Device - The abstraction representing a single
fibre channel device as it appears on an iFCP network."
The specification will not be changed.
Comment 98. [T] Section 4.4.1, pp 22, para 2
"...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...
Monia, et-al Category - Expiration [Page 33]
Responses to iFCP Rev. 10 Last Call Comments May 2002
Response
There is one and only one acceptable format for FC frames. That
said, the issue is not the frame format but the payload
contents.
Besides the addresses in the FC frame header, an iFCP
implementation is only cognizant of N_PORT addresses that may
be embedded in the payload of standards-compliant link service
messages. It cannot remap such addresses if present in the
payloads of user-specified or vendor-specific frames.
No change to the specification will be made.
Comment 99. [T] Section 4.4.3, pp 22, para 1
"In an unbounded iFCP fabric, limiting the scope of an N_PORT
address to a gateway region reduces the likelihood that
reassignment of domain I/Ds caused by a disruption in one
gateway region will cascade to others."
"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?
Accepted
The text will be changed to:
"In an unbounded iFCP fabric, limiting the scope of an N_PORT
address to a gateway region prevents reassignment of domain
I/Ds caused when a disruption in one gateway region cascades to
others."
Comment 100. [T] Section 4.4.3, pp 22, para 2
"In addition, a bounded iFCP fabric has an increased dependency
on..."
Suggest changing "In addition" to "On the other hand".
Accepted
Comment 101. [E] Section 4.4.3, pp 22, para 3
"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."
Monia, et-al Category - Expiration [Page 34]
Responses to iFCP Rev. 10 Last Call Comments May 2002
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.
Rejected
Adding a new gateway region is distinct from disrupting an
existing region and therefore merits its own mention.
Comment 102. [E] Section 4.4.3, pp 23, para 4
...be done non-disruptively and requires only that new
gateway's iSNS..."
Change "that" to "that the".
Accepted
Comment 103. [T] Section 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, even though
this mode allows the same N_PORT 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.
Accepted in Part
While the addressability in a given gateway region is
constrained by the fibre channel address model, the aggregate
addressability of all gateway regions comprising an unbounded
iFCP fabric can exceed that limit.
To make this clearer, the text will be changed as follows:
b) "Since N_PORT fibre channel addresses in an unbounded iFCP
fabric are not fabric-wide, the number of iFCP gateways,
fibre channel devices and switch elements that may be
internetworked may exceed the fibre channel fabric limits."
Comment 104. [E] Section 4.6.1, pp 25, para 4
"In its role as principal switch within the gateway region, an
iFCP..."
Monia, et-al Category - Expiration [Page 35]
Responses to iFCP Rev. 10 Last Call Comments May 2002
General comment - Change to "...as the Principal Switch...".
Accepted
Comment 105. [T] Section 5.2.1, pp 30, para 4
"...A gateway implementation MAY establish a pool of unbound
connections to reduce the session setup time. Such pre-
existing TCP connections between iFCP Portals remain unbound
and uncommitted until allocated to an iFCP session through a
CBIND message"
I wonder if there is a scope for DoS attack here with the
possibility of one gateway potentially holding onto several
unused TCP connections infinitely...."
Response
No. However, the specification will be modified to point out
that a gateway may recover resources at any time by simply
closing unbound connections. See Comment 21.
Comment 106. [E] Section 5.2.2.1, pp31, para 6
"If a descriptor does not exist, one SHALL be created in
response to an iSNS name server query."
Did you mean "SHALL be created after the response to an iSNS
name server query is received"?
Response
The test will be changed to:
"If a descriptor does not exist, one SHALL be created using the
information returned by an iSNS name server query."
Comment 107. [E] Section 5.2.2.1.1, pp 31, para 1
"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.
Monia, et-al Category - Expiration [Page 36]
Responses to iFCP Rev. 10 Last Call Comments May 2002
3. Consults with iSNS server
4. iSNS provides the remote N_PORT for the WWN
5. iFCP gateway assigns a local alias if in translation mode
and if the remote N_PORT ID clashes with a pre-existing
local NPORT_ID.
I do not see why this sequence should be prohibited. Comments
will certainly help.
Accepted in Part
The text will be modified as described in Comment 108.
The 24-bit N_PORT component of the remote N_PORTs address and
its local alias can never clash. The gateway transparently
converts the alias to a network address, consisting of the TCP
connection I/D, TCP Port number and the N_PORT ID assigned by
the remote gateway.
Comment 108. [T] Section 5.2.2.1.1, pp 31, para 1
"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.
"Until such an update occurs, the contents of a descriptor may
become stale as the result of any event that invalidates or
triggers a change in the N_PORT network address of the remote
device, such as a fabric reconfiguration or the device's
removal or replacement."
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.
Accepted in Part
Descriptors are only built and updated as a consequence of name
server requests or state change notifications. An iFCP session
may not necessarily be associated with these activities.
The text will be reworded as shown below to add the state
change case and clarify the order of events leading to a stale
descriptor.
"A Remote N_PORT descriptor SHALL only be updated as the result
of an iSNS query to obtain information for the specified
worldwide port name or from information returned by an iSNS
state change notification. Following such an update, a new
N_PORT alias SHALL NOT be assigned.
Monia, et-al Category - Expiration [Page 37]
Responses to iFCP Rev. 10 Last Call Comments May 2002
"Before such an update, the contents of a descriptor may have
become stale as the result of any event that invalidates or
triggers a change in the N_PORT network address of the remote
device, such as a fabric reconfiguration or the device's
removal or replacement."
Comment 109. [E] Section 5.2.2.1.1, pp 31, para 4
"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 N_PORT 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 N_PORT?
Accepted
The text will be changed to:
"Once the originating N_PORT learns of the reconfiguration,
usually through the name server state change notification
mechanism, information returned in the notification or the
subsequent name server lookup needed to reestablish the iFCP
session will automatically purge such stale data from the
gateway."
Comment 110. [T] Section 5.2.2.2, pp 33
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 N_PORTs 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.
Rejected
As described in Comment 15, the specified behavior is meant to
serve as a tie-breaking mechanism for the establishment of the
iFCP session. Once the session is established, the PLOGIs from
each side are sent and processed by the N_PORTs in accordance
with the PLOGI semantics specified in [FC-FS].
Monia, et-al Category - Expiration [Page 38]
Responses to iFCP Rev. 10 Last Call Comments May 2002
A PLOGI after an iFCP session exists is handled in accordance
with section 7.3.1.7, paragraph 5, which states:
"As specified in section 5.2.2.2, a PLOGI request addressed to
a remotely attached N_PORT MUST cause the creation of an iFCP
session if one does not exist. Otherwise, the PLOGI and PLOGI
ACC payloads MUST be passed transparently to the destination
N_PORT using the existing iFCP session."
Section 5.2.2.2 will be modified to describe the simultaneous
PLOGI scenario above and the case of a PLOGI issued when an
iFCP session exists.
Comment 111. [T] Section 5.2.2.3, pp 35
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.
Rejected
See Comment 18.
If liveness testing was requested for an iFCP session, an LTEST
message must be received within twice the specified interval
regardless of whether or not other traffic is present.
Comment 112. [T] Section 5.2.3, pp 37
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 N_PORT and complete the session as described in..."
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.
[Also,] I recommend "terminate"/"close" in all the places
"complete" is used.
Accepted
The text will be modified as follows:
a) "An LS_RJT response is returned to the gateway from which
the PLOGI ELS originated. That gateway SHALL forward the
LS_RJT to the locally attached N_PORT and terminate the
session as described in..."
Monia, et-al Category - Expiration [Page 39]
Responses to iFCP Rev. 10 Last Call Comments May 2002
Comment 113. [E] Section 5.2.3.1, pp 37, para 2
"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?
Response
Since Unbind is an iFCP session control message, the text will
be changed to:
"Unbind session control message as described in section 6.2."
Comment 114. [T] Section 5.2.3.2, pp 38, para 4
"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).
Accepted
Comment 115. [T] Section 5.4.1, pp 40
"Protocol# IANA-assigned protocol number identifying the
protocol using the encapsulation. For iFCP the value is
(/TBD/)."
Should FCEncap document be referred here instead?
Accepted
See Comment 23.
Comment 116. [E] Section 5.4.3, pp 43, para 2
"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?
Monia, et-al Category - Expiration [Page 40]
Responses to iFCP Rev. 10 Last Call Comments May 2002
Accepted
The specification will be modified to address the case where a
frame triggers the creation of an iFCP session.
Comment 117. [E] Section 5.4.3, pp 43, para 3
"Frames types submitted for encapsulation and forwarding on the
IP..."
"Frames" should be "Frame".
Accepted
Comment 118. [E] Section 6, pp 44, para 1
"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?).
Instead 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).
Accepted in Part
In accordance with Comment 26, the mnemonic for the LS_COMMAND
field in the encapsulation header will be changed to eliminate
confusion as follows:
From section 5.4, Encapsulation of Fibre Channel Frames:
"LS_COMMAND_ACC For a special link service ACC
response to be processed by iFCP, the
LS_COMMAND_ACC field SHALL contain
bits 31 through 24 of the LS_COMMAND
to which the ACC applies. Otherwise
this field shall be set to zero."
From section 6, TCP Session Control Messages:
Monia, et-al Category - Expiration [Page 41]
Responses to iFCP Rev. 10 Last Call Comments May 2002
LS_COMMAND_ACC 0
With the addition of the new mnemonic, the above text clearly
specifies how the field is to be set.
Comment 119. [E] Section 6.1, pp 46, para 2
"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.
Rejected
That is correct. The existing text seems to explain this
adequately.
Comment 120. [T] Section 6.2, pp 49, para 1
"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?
Response
See Comment 21 regarding the disposition of "unbound" TCP
connections. The above paragraph will be expanded to clarify
the rationale for the unbound connection pool as follows:
"UNBIND is used to terminate an iFCP session and disassociate
the TCP connection. To expedite the creation of a new iFCP
session, the TCP connection MAY remain open at the discretion
of either gateway and kept in a pool of unbound connections.
In order to recover resources, either gateway may spontaneously
close the unbound TCP connection at any time."
Comment 121. [E] Section 6.2, pp 50, para 1
"transmitted in the connection that is to be unbound. The
time..."
Change "in" to "on".
Accepted
Monia, et-al Category - Expiration [Page 42]
Responses to iFCP Rev. 10 Last Call Comments May 2002
Comment 122. [T] Section 8.2.1, pp 76, para 1
"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 -
a) Is Unsynchronized operation allowed? If so, how is the
R_A_TOV expectation met?
b) 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?
Accepted in Part
For item a), see the response to Comment 35.
For item b), iFCP specifies the following behavior:
d) "If the incoming frame has a non-zero time stamp, the
receiving gateway SHALL compute the absolute value of the
time in flight and SHALL compare it against the value of
IP_TOV specified for the IP fabric.
e) "If the result in step (d) exceeds IP_TOV, the encapsulated
frame shall be discarded. Otherwise, the frame shall be
de-encapsulated as described in section ...."
Since it is impossible to guarantee that one time reference
won't be skewed negatively with respect to the other. the
propagation delay test is against the absolute value of the
time difference.
The iFCP spec will be modified to state that an iFCP gateway
implementation MAY terminate an iFCP session if the rate at
which stale frames are detected exceeds some administratively-
specified threshold.
6. Security Considerations
The applicable security provisions are defined in [IFCP].
7. References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
Monia, et-al Category - Expiration [Page 43]
Responses to iFCP Rev. 10 Last Call Comments May 2002
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[IFCP] Monia, C., et al, ö iFCP - A Protocol for Internet Fibre
Channel Storage Networking", draft-ietf-ips-ifcp-10.txt,
February 2002
[FC-FS] dpANS INCITS.XXX-200X, "Fibre Channel Framing and Signaling
Interface", Revision 1.7, NCITS Project 1331-D, February
2002
[SECIPS] Aboba, B., et-al., "Securing Block Storage Protocols Over
IP", revision 11, February 2002
[FC-GS3] dpANS X3.XXX-200X, "Fibre Channel Generic Services -3 (FC-
GS3)", revision 7.01, NCITS Project 1356-D, November 2000
8. Author's Addresses
Charles Monia Franco Travostino
Josh Tseng Director, Content
Internetworking Lab,
Nishan Systems Nortel Networks
3850 North First Street 3 Federal Street
San Jose, CA 95134 Billerica, MA 01821
Phone: 408-519-3986 Phone: 978-288-7708
Email: Email:
cmonia@nishansystems.com travos@nortelnetworks.com
Full Copyright Statement
"Copyright (C) The Internet Society May 2002. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
Monia, et-al Category - Expiration [Page 44]
Responses to iFCP Rev. 10 Last Call Comments May 2002
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Monia, et-al Category - Expiration [Page 45]
