Subject: RE: [Ips] iSNS failover and multi-server configurations

From: "Kevin Gibbons" <[email-masked]>
Date: Thu, 5 Feb 2004 14:49:57 -0800

All,
	please see below for comments.  Regards, Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, February 04, 2004 6:37 PM
To: [email-masked]
Subject: [Ips] iSNS failover and multi-server configurations

The iSNS draft (draft-ietf-ips-isns-21.txt) mentions the concept of
backup servers (especially in the heartbeat PDU) and says it will
describe client interatctions with multiple servers (Section 2.8).
However I can't find any discussion of client interactions in that
section.

KAG> Yes, section 2.8, "Backup iSNS Servers", primarily talks about iSNS
server interaction.  It does not discuss how a client interacts with
them.  It only says that a client can interact with multiple iSNS
servers, some of which are backup servers.

So can we either have some more text, or some sort of suplimental
document that gives guidelines on how to deal with these concepts? I
have a few questions, and while I can answer them, I want to make sure
my answers agree with everyone else's. :-)

KAG> If I understand the IETF WG process correctly, it should be
possible to add some text at this stage - if it is agreed that the text
is not changing the technical operation of the protocol.

Questions:

1) Say a device is using iSNS heartbeats to find the server. Say it
starts up and can't connect to the primary server (or specifically it is
only hearing messages from a backup server). Say it registers with the
backup server. Now say the primary server comes back on line. What does
the device need to do?

KAG> As described in Section 2.7, "Transfer of iSNS Database Records
between iSNS Servers", and Section 2.8, "Backup iSNS Servers", the
primary and backup servers must have a coordinated database.  It states:
"If the primary backup server or other higher-precedence backup server
returns, then the existing active server is responsible for ensuring
that the new active server's database is up-to-date before demoting
itself to its original status as backup."  How the coordination is done
is beyond the scope of the current iSNS specification.

1a) does it re-register its configuration with the new primary server,
or does it assume that the new server synchronized itself before
resuming being hte primary server?

KAG> since the iSNS server database is coordinated between the primary
and backup servers, no re-registration by an iSNS Client is required.

KAG> I agree that adding some text to clarify this in Section 2.8 would
be helpful.  Perhaps the following: "Since the primary and backup iSNS
servers maintain a coordinated database, no re-registration by an iSNS
Client is required when a secondary server takes the active server role.
Likewise, no re-registration by an iSNS Client is required when the
previous primary server returns to the active server role."

1b) does it need to register SCN requests with the new server? Does it
need to de-register its old SCN registrations?

KAG> no re-registration should be required.

2) I see that DHCP can indicate multiple servers. But what about SLP in
face of multiple servers? Andy Currid suggested that SLP should only
have the most-senior operational server registered. But what happens
when either a formerly-off-line server comes back on line or an on-line
server goes off-line? SLP does not seem well-suited for "server moved"
notifications. Also, with SLP, if a server fails, what are the security
considerations for the backup server to be able to de-register the
server?

Would it be easier for SLP to add a "precedence" attribute and have each
server register with SLP, then have the client perform the same failover
as DHCP and heartbeat do?

KAG> It may be best for SLP template to also indicate the iSNS server
precedence in some manner.

Thanks!

Take care,

Bill

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

SPECIAL NOTICE 

All information transmitted hereby is intended only for the use of the 
addressee(s) named  above and may contain confidential and privileged 
information. Any unauthorized  review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader of
this message is not the intended recipient(s) or the employee or agent 
responsible for delivering the message to the intended recipient, you
are hereby notified that you must not read this transmission and that
disclosure, copying, printing, distribution or use of any of the
information contained in or attached to this transmission is STRICTLY 
PROHIBITED.

Anyone who receives confidential and privileged information in error should 
notify us immediately by telephone and mail the original message to us at the
above address and destroy all copies.  To the extent any portion of this
communication contains public information, no such restrictions 
apply to that information. (gate01)

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips