Subject: [Rserpool] I-D ACTION:draft-ietf-rserpool-enrp-03.txt

From: [email-masked]
Date: Tue, 07 May 2002 07:35:49 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Server Pooling Working Group of the IETF.

	Title		: Enpoint Name Resolution Protocol (ENRP)
	Author(s)	: Q. Xie, R. Stewart, M. Stillman
	Filename	: draft-ietf-rserpool-enrp-03.txt
	Pages		: 24
	Date		: 06-May-02
	
Endpoint Name Resolution Protocol (ENRP) is designed to work in
conjunction with the Aggregate Server Access Protocol (ASAP)
to accomplish the functionality of the Reliable Server Pooling
(Rserpool) requirements and architecture.
Within the operational scope of Rserpool, ENRP defines the
procedures and message formats of a distributed, fault-tolerant
registry service for storing, bookkeeping, retrieving, and
distributing pool operation and membership information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rserpool-enrp-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rserpool-enrp-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-rserpool-enrp-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 08 May 2002 18:29:47 -0500

Hi, everyone,

The new version of ENRP, ASAP drafts are online for your review and
comments now. Here is a summary about this new version.

Major changes:
 - restructured the document
   1) We spun off the common text between ENRP and ASAP into a separate
"common-param" draft. This is just to make life easier for doc editors,
not for any tech reasons. We can always merge it back at the end if that
is what we want.

   2) Per decision at last IETF, we introduce an "interface" document,
describing how services are presented to the ULP (this will come from
Phil).

 - support non-SCTP transports
   1) for PU<->PE communications, we now support SCTP, TCP, and UDP.

   2) for PU/PE<->ENRP server communications, we use SCTP only.

   3) for ENRP server<->ENRP server communications, we use SCTP only.

   We added transport proto type to the registration to support non-SCTP
   transport.
 
 - removed dependency on multicast
   We added text to describe how and when to use multicast for for ENRP
   server<->ENRP server communications, and how to determine a new 
   peer is or is not using multicast. This changes how the bootstrap is 
   done when a new ENRP server join the service.

   We also added text on how a PU/PE find its home ENRP server with or
   without multicast.

Minor changes:
  - New message for reporting operation errors.
  - Re-organized the error code in multiple places
  - Server ID and PE ID are simplified.
  - more expandable TLV for load policy parameter.
  - added ENDPOINT_KEEP_ALIVE_ACK message to ASAP.
  - Enhancement to the text (much more to be done in this department,
reader be patient).

Remaining issues: the following issues are still open and I'd suggest to
consider them as discussion points for the upcoming interim meeting.

 - how to pass business card:
   1. inband signaling (efficient by not elegant)?
   2. outband signaling (a separate SCTP assoc)?
   3. reverse ENRP translation query?, etc.

 - how to mend two pieces of a split namespace:
   1. ask for a peer list when run across a previously unknown server?

 - how to audit namespace data and how to re-sync if there is
   discrepancy?

 - operation error parameter is there, but message is still missing:

 - detecting duplicate PE Identifiers: how critical, by whom, and how? 

 - detecting duplicate Server ID: how critical, by whom, and how? 

 - the current PE format is quite accommodating, e.g., it even allows
   you to register with:

   [PE-id; pool-name; 
    SCTP-trans1; 
    SCTP-trans2; 
    TCP-trans1; 
    TCP-trans2; 
    UDP-trans
    ...]

   should we tighten it up?

 - how to handle conflicting load policies at registration? The draft
   presents one solution ("if ENRP server can't override it, reject 
   the reg"), but is there a better solution?

 - security precautions when multicast is used among ENRP servers. more
   text for the security section.

 - ENRP is still missing handling ENDPOINT_KEEP_ALIVE_ACK (my
   oversight).

Randy and Maureen, please feel free to add discussion points to the
above list. I might have missed some since my vision is ENRP-distorted
:-)

regards,
-Qiaobing

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

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 08 May 2002 18:29:47 -0500

Hi, everyone,

Major changes:

 

Minor changes:

   [PE-id; pool-name; 
    SCTP-trans1; 
    SCTP-trans2; 
    TCP-trans1; 
    TCP-trans2; 
    UDP-trans
    ...]

   should we tighten it up?

regards,
-Qiaobing