FW: Reliable Server Pooling (Rserpool) minutes IETF #61
| Newsgroups | gmane.ietf.rserpool |
|---|---|
| Message-ID | <57A26D272F67A743952F6B4371B8F811046EE46D@daebe007.americas.nokia.com> |
Any comments? -- Maureen Reliable Server Pooling (Rserpool) minutes IETF #61 This meeting was attended by approximately 35 people. The Rserpool architecture document was discussed. Changes in terminology will be added to the document. These changes are to clarify the architecture and make it easier for the reader to understand Rserpool. The document contains several examples of applications of Rserpool. We are interested in adding a load balancing example due to the recent work of the design team in load balancing. Due to these changes we will reissue the document and perform another last call. The Rserpool policy document was recently made a WG item. It describes a collection of optional pool policies. One recent change to the document is that it allows two modes of operation. Either the ENRP server can determine the next address or the PU can be given a list of IP addresses from which it selects an address. This change was debated and will be brought to the list. The ASAP and ENRP protocols have been stable for a long time. Currently, changes have been suggested on the mailing list from people who are implementing Rserpool. Several changes have been incorporated into both protocols. The authors will update the terminology in the protocol documents to match the architecture document. We solicit and encourage more implementation feedback. The load balancing design team has been meeting for two months and has made good progress. We are working with load balancing vendors to understand their requirements. Based on requirements, our goal is to identify changes to the Rserpool protocol and examine the advantages and disadvantages of several approaches. The design team is working on an internet draft to reflect load balancing requirements. This will be released after IETF #61 for review and comment. The design team will continue to meet. An internet draft on high availability and Rserpool was discussed. The IPR on this work needs to be clarified before the WG can make a determination about making it a WG item. The final talk was a discussion of Rserpool socket APIs. There is a draft not yet released with several authors. An overview of the functions was presented. The goal would be for this document to become an informational RFC. The draft will be sent to the list for review before deciding on its WG status. -- Maureen