Subject: RE: iSNS comments

From: Kevin Gibbons <[email-masked]>
Date: Thu, 8 Mar 2001 11:34:00 -0800

Sandeep,
	thanks for the iSNS feedback.  Please see responses below.
		Regards, Kevin

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Thursday, March 08, 2001 7:35 AM
To: [email-masked]
Subject: Re: iSNS comments

> some comments on the new iSNS draft
> 
> 1) it lacks a Table of contents, unlike iSCSI.  please add one.
>    (given that, i am liable to have missed some section which 
>     might have answered the questions raised below!)

kg> we can add a TOC to the next update of the document.

> 
> 2) What happens if an iSNS client tries to update its 
>    TCP/UDP port or IP address (for Portal/ESI/etc) ?
>    
>    So the entry exists, and now the client sends a RegDevAttr
>    request with the update flag set for changing the above.
>    
>    If the port(s) is going to be well-known, the questions below 
>    may not arise.  If not,...
>  
>    a) Will the old TCP connection be broken by the iSNS server ?

kg> Who breaks the former connection first is implementation 
dependent.  However, the iSNS server initiates the TCP 
connection to the new port for the next ESI message.  The ip 
address and port used for ESI messages does not have to be the 
same as portal addresses that an entity has registered.

>    b) Would the RegDevResponse be sent to the old/new port ?

kg> as described in section 7.2, the response will be sent 
to the same IP Address and Port that the registration 
message originated from.

>    c) Who initiates the new connection (client or server) ?

kg> the iSNS server will initiate the connection for the next 
ESI.  There was concern during the design that the server, 
rather then the client, be in control of the ESI period and 
connection process to manage the ESI handling overhead.

>    d) How would the client know the request succeeded ?

> i see what i missed here.. SLP, which is orthogonally managing 
> the "control" plane.  the questions above dont arise.

kg> The client will know the request succeeded from the 
RegDevResponse message status field, sent by the iSNS is 
response to the request.

>    
> 3) Is there a requirement to provide (keyword=MUST) a secondary 
>    iSNS server ?  If I am not mistaken, DNS does mandate a  
>    secondary server for every zone to avoid single-pt-of-failure.
>   

kg> There was concern that the design not mandate a requirement 
for a secondary server for situations where High Availability 
is not a concern.  If desired, additional text can be added to 
recommend secondary server in HA configurations.

> -Sandeep

---

From: Sandeep Joshi <[email-masked]>
Date: Sat, 10 Mar 2001 17:48:09 -0500

Hi Kevin,

Thanks for the clarifications.  Some more questions.

What scenarios require changes in ESI IP address/port ? 
I would have assumed one wouldnt want to change these 
things but just keep them read-only.

I can see DHCP being one reason for IP address changes, but
in that case, question (2) below should result in something 
more akin to a new entity insert (NOT an update).  The other 
reason could be a multi-NIC device where one interface goes 
down and one wants to switch the ESI/mgmt address to be the 
other interface.  Anything else?

Changing the ESI portnumber could be a headache if the iSNSdb 
is trashed, since one would then have to resort to port scans
to find network entities.  (or SLP/SNMP could help but then 
there is no way to "manually" find your way around).

On a (port) related note, is SCN going to be a unicast service 
or can multicast(reliable/unreliable) also be defined for use.
It might seem like all clients would be interested in generic
events like "network changed" and such events might get generated
more often than anticipated.

One other comment.  I noticed that iSNS will generate a new DDid 
for an iSNS client which does not supply one(Sec 6.6)  This seems 
to conflict with soft-zoning since initiators can only find 
targets in the same DD.  Am I interpreting this correctly?  
Perhaps the default DDid should be a wildcard of some sort 
(subnet or all within same domain)

-Sandeep