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

From: Silverton Aron-C1710C <[email-masked]>
Date: Thu, 14 Oct 2004 16:37:37 -0500

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-masked] [mailto:[email-masked]] On Behalf Of Johnson Walter-CWJ002
Sent: Thursday, October 14, 2004 3:23 PM
To: [email-masked]
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-masked]
https://www1.ietf.org/mailman/listinfo/rserpool

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

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 15 Oct 2004 00:15:20 +0200

I also support this. It makes the protocol simpler.

Best regards
Michael

On Oct 14, 2004, at 23:37 Uhr, Silverton Aron-C1710C wrote:

> 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
>
> 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.
>

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 14 Oct 2004 19:14:01 -0500

Sounds good to me.

-Q