RE: iSNS comments

[Joshua Tseng <jtseng@NishanSystems.com>]

Hi Sandeep,

Thanks for your helpful comments.

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

The iSNS can send ESI messages to either the Portal IP address
or the Management IP address.  The ESI TCP/UDP Port attribute
is merely there to allow the client to specify to the server
that it wants to receive ESI messages on a different port,
if that is what it wants.

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

A new entity is akin to a new iSCSI instance or device being
plugged into the network.  An expiring DHCP lease resulting
in a new IP address being assigned to a portal would be an
example of an update or a change to an existing portal IP address.
A new NIC being hot-plugged into an existing operational iSCSI
device would be an example of a new portal added to an existing
entity.

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

If the iSNS database is trashed, then the ESI would be the least
of your worries.  You are right that SLP and SNMP would be
alternative ways of finding 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.

Currently, SCN is specified as a unicast service.  However, I
could imagine using vendor-defined attributes to store a multicast
group for each Discovery Domain, and then multicasting SCN's.  iSNS
is structured to provide flexibility depending on the needs of the
implementer.

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

Section 6.6 is left over from a previous version of iSNS, and will
be updated in the next revision--thanks.  Section 3.2.2 describes
how it is up to an implementer to decide whether a new device that
hasn't been explicitly registered into a DD should be put into a
"default DD", or remain without a DD.  If a device is not a member
of a DD, then it shall be inaccessible.  It is up to the implementer
to decide whether to put new devices with no DD into the "default DD".

Regards,
Josh

> 
> -Sandeep
> 
> Kevin Gibbons wrote:
> > 
> > Sandeep,
> >         thanks for the iSNS feedback.  Please see responses below.
> >                 Regards, Kevin
> > 
> > -----Original Message-----
> > From: sandeepj@research.bell-labs.com
> > [mailto:sandeepj@research.bell-labs.com]
> > Sent: Thursday, March 08, 2001 7:35 AM
> > To: ips@ece.cmu.edu
> > 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
>