Re: iFCP: Response to technical comments from Mallikarjun Chadalapaka

["Mallikarjun C." <cbm@rose.hp.com>]

Charles,

Thanks for the resolutions.  Some comments below -
all editorial with one possible exception.

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com

----- Original Message ----- 
From: "Charles Monia" <cmonia@NishanSystems.com>
To: "Ips (E-mail)" <ips@ece.cmu.edu>
Sent: Tuesday, April 23, 2002 8:17 PM
Subject: iFCP: Response to technical comments from Mallikarjun Chadalapaka


>           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.  

Please call it out as an example more clearly -  in particular, the text description seems
fairly generic, I incorrectly assumed it as the description of any iFCP gateway (as opposed to 
that of the example).

>              The considerations to be addressed when connecting multiple
>              iFCP portals to a gateway region are discussed in Comment 12.

I am not sure the resolution for comment 12 is quite applicable here.  My question
is the legality (or lack thereof) of two iFCP portals in *one* iFCP gateway - essentially
multiple portals into the IP network from one gateway box.

>Comment 104. [E] Section 4.6.1, pp 25, para 4
>"In its role as principal switch within the gateway region, an
>iFCP..."
>General comment - Change to "...as the Principal Switch...".
>Rejected

This is a nit, but am curious about the rejection.  IIRC, the uppercase in "Principal
Switch" is what's used by FC-SW documents....

> 
>           Comment 108.       [T] Section 5.2.2.1.1, pp 31, para 1
> 

>              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

I agree with the resolution, but still have an editorial suggestion for some of the similar
proposed text changes.  In the request-response model, "query" corresponds to a "request"
in my mind.  So, I expect only a "response" to update descriptors, not the query.

>          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.  

I agree with the rest of the resolution, but my reading of FC-FS (clause 
15.3.3.3 of rev1.70) is that a PLOGI collision results in an LS_RJT
to one party.  My original comment was to suggest that iFCP specify the 
LS_RJT reason code, since the PLOGI is being turned back from the 
iFCP gateway (or is PLOGI expected to be held off until the colliding PLOGI
is completely taken care of?) as I read it.  Please comment.

>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.

I am fine with the resolution, but would still suggest a couple of editorial
changes to this sentence.  a) "release" should be replaced with "unbind"
b)"optionally" should be replaced with "at either gateway's discretion".