Subject: [Rserpool] Elimination of Registration Response Success /w Warning/Modificat ion from ASAP draft

From: Johnson Walter-CWJ002 <[email-masked]>
Date: Thu, 14 Oct 2004 15:23:28 -0500

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-masked]
https://www1.ietf.org/mailman/listinfo/rserpool

---

From: Thomas Dreibholz <[email-masked]>
Date: Fri, 15 Oct 2004 11:28:16 +0200

On Thursday 14 October 2004 22:23, Johnson Walter-CWJ002 wrote:
> 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.
>

This is useful. The rsplib prototype already does not try to adapt a PE's 
policy to another one and directly rejects the registration with an 
appropriate error code.

Best regards
- -- 
=======================================================================
 Dipl.-Inform. Thomas Dreibholz

 University of Essen,                            Room ES210
 Inst. for Experimental Mathematics              Ellernstraße 29
 Computer Networking Technology Group            D-45326 Essen/Germany
- -----------------------------------------------------------------------
 E-Mail:     [email-masked]
 Homepage:   http://www.exp-math.uni-essen.de/~dreibh
=======================================================================