RE: Elimination of Registration Response Success /w Wa rning/Modificat ion from ASAP draft
Silverton Aron-C1710C <[email protected]>
| Newsgroups | gmane.ietf.rserpool |
|---|---|
| Message-ID | <FD52892BD296D71183B400065BFCB6901067DFCD@il02exm12> |
I agree with the proposal below. The current method assumes that the PE is capable of supporting whichever pool policy is returned in the warnings/modifications. I don't think that this is a safe assumption, so I support the change. Aron -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Johnson Walter-CWJ002 Sent: Thursday, October 14, 2004 3:23 PM To: [email protected] Subject: [Rserpool] Elimination of Registration Response Success /w Warning/Modificat ion from ASAP draft Currently the registration procedure of the ASAP draft in section 3.1 supports three cases. 1) Success 2) Success /w warnings/modifications 3) Failure I believe that the registration procedure should only result in either success or failure eliminating case 2. Let me explain. For instance, let say the PE can't adapt its policy from the policy sent in the registration message. If the PE receives a registration success /w warnings/modifications and can't adapt, it should remove itself from the pool. Then the PE would need to deregister or not re-register itself to be removed from the pool. This would cause updates to happen across all peer ENRP servers since the PE would need to be removed from the pool to which it was recently added, resulting in many messages being sent to maintain namespace synchronization. Also before this deregistration occurred, several PUs could have starting using this PE for service which results in its own problems. If instead the registration was rejected using the operation error codes regarding the problem, the PE could simply send a single message to register again if changes could be made. Otherwise no message would be sent if the PE couldn't adapt. I believe this is much simpler and would result in fewer overall messages being sent within the RSerPool architecture and would result in a cleaner ASAP implementation. What does everyone think? _______________________________________________ rserpool mailing list [email protected] https://www1.ietf.org/mailman/listinfo/rserpool