Re: [Ips] no DHCP-assigned InitiatorName

<G_Chawla@Dell.com> Mon, 22 September 2008 21:17 UTC

Return-Path: <ips-bounces@ietf.org>
X-Original-To: ips-archive@optimus.ietf.org
Delivered-To: ietfarch-ips-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80CD43A6B7B; Mon, 22 Sep 2008 14:17:32 -0700 (PDT)
X-Original-To: ips@core3.amsl.com
Delivered-To: ips@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8D0D3A67AE for <ips@core3.amsl.com>; Mon, 22 Sep 2008 14:17:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.999
X-Spam-Level:
X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lJfxKj7Jmnj for <ips@core3.amsl.com>; Mon, 22 Sep 2008 14:17:25 -0700 (PDT)
Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) by core3.amsl.com (Postfix) with ESMTP id 1A1153A6B7B for <ips@ietf.org>; Mon, 22 Sep 2008 14:17:24 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 22 Sep 2008 16:18:40 -0500
Message-ID: <42D8A6CDC96A5A4D8D91DE26991A51AA02016FCC@ausx3mpc108.aus.amer.dell.com>
In-Reply-To: <46A00B48CC54E4468EF6911F877AC4CA019D6963@blrx3m10.blr.amer.dell.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Ips] no DHCP-assigned InitiatorName
thread-index: Ackc6XVrlRzKxSf0TEy+wtYv9BwVHAAAXBXQAABNyzAAAxb08A==
References: <48D6F3EB.1080400@scalent.com><OF51EB8C4B.4A802DE0-ON852574CC.003C9899-852574CC.003D1E7C@il.ibm.com><48D79AA6.9040104@scalent.com><OF2B1DCFAA.18C9A07A-ON852574CC.004985AD-852574CC.004A10C4@il.ibm.com><48D7BC9D.7060306@scalent.com><OFBBCF89D4.CCDF2FC8-ON852574CC.005E8F41-852574CC.005F3669@il.ibm.com><48D7DF92.9030605@scalent.com><46A00B48CC54E4468EF6911F877AC4CA019D6922@blrx3m10.blr.amer.dell.com> <48D7F1DE.5060000@scalent.com> <42D8A6CDC96A5A4D8D91DE26991A51AA02016F63@ausx3mpc108.aus.amer.dell.com> <46A00B48CC54E4468EF6911F877AC4CA019D6963@blrx3m10.blr.amer.dell.com>
From: G_Chawla@Dell.com
To: Shyam_Iyer@Dell.com, michael.howard@scalent.com
X-OriginalArrivalTime: 22 Sep 2008 21:16:57.0533 (UTC) FILETIME=[8B8A3ED0:01C91CF8]
Cc: SIVANT@il.ibm.com, psarkar@almaden.ibm.com, ips@ietf.org, Julian_Satran@il.ibm.com
Subject: Re: [Ips] no DHCP-assigned InitiatorName
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ips>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

We should be able to leverage CHAP based security (already defined for
iSCSI) to provide the necessary security (authentication) between the
initiators and targets. 

Thanks,
Gaurav Chawla
Technology Strategist, Network Storage Architecture | Office of the CTO,
Dell, Inc.
Phone: 512.724.4064 (work)


-----Original Message-----
From: Iyer, Shyam 
Sent: Monday, September 22, 2008 3:07 PM
To: Chawla, G; 'Michael Howard'
Cc: 'SIVANT@il.ibm.com'; 'psarkar@almaden.ibm.com'; 'ips@ietf.org';
'Julian_Satran@il.ibm.com'
Subject: RE: [Ips] no DHCP-assigned InitiatorName

Thanks Gaurav. 
You are right. The fact that most of the pre-OS iSCSI initiators don't
have iSNS clients, takes us away from the iSNS scenario atleast for the
boot environment.

On the other hand the scenario where in there are iSNS clients(or a more
enterprise ready environment) we could probably think more on the lines
of security since parameters with DHCP(clear text) is going to be less
secure.

Thanks,
Shyam Iyer

-----Original Message-----
From: Chawla, G 
Sent: Tuesday, September 23, 2008 1:16 AM
To: Michael Howard; Iyer, Shyam
Cc: SIVANT@il.ibm.com; psarkar@almaden.ibm.com; ips@ietf.org;
Julian_Satran@il.ibm.com; Chawla, G
Subject: RE: [Ips] no DHCP-assigned InitiatorName

My 2 cents based on my understanding of iSNS. 

- iSNS clients (initiators and targets) need to have an IQN address
before they register with the iSNS server.
- Most pre-OS iSCSI initiators available today are not iSNS clients i.e.
they don't register with and/or query iSNS server.

Given this, it seems better to have a DHCP based standardized mechanism
for acquiring the initiator IQN. Based on initial email from Michael,
most pre-OS iSCSI Initiators available today have the capability to be a
DHCP client.

Thanks,
Gaurav Chawla
Technology Strategist, Network Storage Architecture | Office of the CTO,
Dell, Inc.
Phone: 512.724.4064 (work)


-----Original Message-----
From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of
Michael Howard
Sent: Monday, September 22, 2008 2:29 PM
To: Iyer, Shyam
Cc: SIVANT@il.ibm.com; psarkar@almaden.ibm.com; ips@ietf.org;
Julian_Satran@il.ibm.com
Subject: Re: [Ips] no DHCP-assigned InitiatorName

Shyam_Iyer@Dell.com wrote:
> My 2cents on the issue. Please correct me if I am wrong. 

Thank you for participating in this discussion.

> Shouldn't it be possible to configure the isns server with a set of 
> possibly regex rules for the control path. If this not possible today,

> then it could possibly be the root to take towards standardizing.

I am not familiar enough with iSNS to comment.

I have been exposed to about about a dozen commercial environments with
some level of iSCSI use/experimentation. I am not aware that any of them
  were running iSNS servers.

> This can solve the problem of provisioning for dynamic boot 
> environments with minimum changes to legacy iqn implementations, many 
> of which would need to relearn to the new iqn mechanism that might end

> up as a result of this discussion.

Frankly, my concern is that Broadcom/IBM already have a non-standard
DHCP Vendor Option work-around for this problem.

Adding a new/standardized InitiatorName DHCP option would not break
existing initiator implementations. Vendors would integrate support for
this new InitiatorName option into their code/firmware releases over
time.

> Instead of changing numerous configurations we could simply change the

> isns server control mechanism.

I need to do some homework regarding iSNS.

> Comments?

iSCSI is still a very small part of the market.

I advocate addressing this deficiency sooner rather than later.


Michael
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www.ietf.org/mailman/listinfo/ips
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www.ietf.org/mailman/listinfo/ips