RE: iSCSI: NIC interoperability

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

Mallikarjun is advocating including A,B,and C statements explicitly in the
document.  I support this.

Marj

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Friday, October 12, 2001 10:03 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: NIC interoperability
> 
> 
> Mallikarjun,
> 
> I have repeatedly stated that from a practical point of view we are
> spending a lot of ink on a non-issue.
> I have even insisted on mandating C in the draft. Some of the list
> members/readers/authors seem to consider such a requirement 
> as "excessive"
> - as it implies resorting to a higher authority on every 
> session creation -
> and that might not be strictly necessary (although it will be 
> sufficient).
> Adding a text key is neither simpler nor easier nor will it solve the
> conflict problem.
> And I have very little time and patience left for pages of 
> debate on the
> merits of one or other port naming script.
> 
> Julo
> 
> 
> 
>                                                               
>                                 
>                     "Mallikarjun                              
>                                 
>                     C."                  To:     ips 
> <ips@ece.cmu.edu>                        
>                     <cbm@rose.hp.c       cc:                  
>                                 
>                     om>                  Subject:     iSCSI: 
> NIC interoperability             
>                     Sent by:                                  
>                                 
>                     owner-ips@ece.                            
>                                 
>                     cmu.edu                                   
>                                 
>                                                               
>                                 
>                                                               
>                                 
>                     10-10-01 04:14                            
>                                 
>                     Please respond                            
>                                 
>                     to cbm                                    
>                                 
>                                                               
>                                 
>                                                               
>                                 
> 
> 
> 
> After seeing some of the emails on this topic from Dave
> Sheehy, David Black and Jim Hafner, I have some comments
> and questions.
> 
> It appears to me that the following three are the major
> issues that one has to deal with for building a multi-NIC
> iSCSI Node, where the NICs are potentially from different
> vendors.
>            A. Each NIC MUST allow the Node name to be configurable.
>            B. Each NIC MUST allow the ISID range to be configurable
>            (if deployed in an initiator configuration).
>            C. In addition, if only one (initiator/target) portal group
>            is sought to be presented (i.e. session spanning across
>            any and all of these NICs is a requirement), each NIC
>            MUST allow itself to be managed by an externally-resident
>            "session manager" in some "TBD standard way".
> 
> Admittedly, C is is the hardest and till the "TBD standard way"
> is defined to interact with a session manager, it cannot be
> mandated.  Failure to comply with C would only create multiple
> portal groups in an iSCSI implementation - each portal group
> limited to NIC(s) from a given vendor.
> 
> But, A and B above seem reasonable and in fact seem required
> to be mandated - both to avoid the problems as with FC Node
> Name, and also to address the concerns of not leaving target
> with a deterministic way to enforce access control mechanisms
> and such.
> 
> I realize that the "no duplicate nexus" goal does not strictly
> require A (hence neither B), but I recommend that A be mandated,
> thus automatically making B an additional requirement for initiator
> configurations.  Rev08 iSCSI draft seems to refer to A and B
> in section 9 (implementation notes) as "should".  Was there a
> concern about the appropriateness of mandating A and B in the
> main modeling discussion?  They appear fairly straightforward
> to implement.
> 
> If the reasoning was not to require _any_ configuration of an
> iSCSI NIC, I would argue that you require some "name" to be
> configurable anytime you want to build a logically monolithic
> entity (as in a node) from smaller components (each of which
> can act as a logically independent entity in its own right).
> 
> Comments from NDT and/or Julian would help.
> 
> Thanks.
> --
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668 Hewlett-Packard, Roseville.
> cbm@rose.hp.com
> 
> 
> 
>