RE: iFCP: Response to technical comments from Mallikarjun Chadalapaka

[Charles Monia <cmonia@NishanSystems.com>]

Hi Mallikarjun:

Re Comment 110:

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


Your surmise is correct, the PLOGI is deferred to be sent when the iFCP
session is created.

The scenario is that once the tie-breakling mechanism is invoked and the
iFCP session is established, the PLOGIs from each side are sent and
processed by the N_PORTs in accordance with the PLOGI sematics specified in
FC-FS.

I will revise the text to make this clearer.

See other responses below.


> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Wednesday, April 24, 2002 11:50 AM
> To: Charles Monia
> Cc: ips@ece.cmu.edu
> Subject: Re: iFCP: Response to technical comments from Mallikarjun
> Chadalapaka
> 
> 
> 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).
> 

Point taken.

I'll give this another try.

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

The gateway entity is defined as having one and only one iFCP portal.
Externally, the configuration you describe would behave as two gateways
enclosed in one piece of sheet metal.

> >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 accepted.  I will revise to be consistent with T11 usage.


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

Rhetorically, the query response is the "result of 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".
>

Comment accepted.

Charles