|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] iFCP: Response to technical comments from Mallikarjun Chadalapaka
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
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"
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
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 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 enhancements to the data structures
presented - but can you please comment on any architectural
issues here?
Response
The figure is 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.
[From comment 12]
For either iFCP fabric type, an N_PORT may be behind more than
one gateway provided:
a) One gateway becomes the 'principal switch' and
b) All gateways attached to a given gateway region coordinate
the assignment of N_PORT IDs and N_PORT aliases such that
each N_PORT has one and only one assigned address.
The above will be added to the specification.
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...
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 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 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.
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.
"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 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
The specified behavior is meant to serve as a
tie-breaking mechanism. Once the session is established, the
PLOGI response will be generated by the receiving N_PORT in
accordance with the semantics defined in [FC-FS].
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 include 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
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..."
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
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.
Charles Monia
Senior Technology Consultant
Nishan Systems
email: cmonia@nishansystems.com
voice: (408) 519-3986
fax: (408) 435-8385
Home Last updated: Mon Apr 29 13:18:30 2002 9838 messages in chronological order |