Re: AD comments on draft-ietf-rserpool-policies-06

Hi Magnus,

see my comments inline.

> 1. In a number of places I find this document talking about policies
> returning multiple PEs in answer. However, I can't remember any requests
> that support asking for multiple answers. So please inform me how this
> was intended to use. Or if not currently supported what the intention
> was with specifying this for the policies.

The ENRP server decides how many PE identities to return upon a handle 
resolution request. Then, the requested number of PE identities is selected 
by policy.

This should be clearified in the ASAP draft.


> 2. Section 5.2.2:
> I think one need to clarify that this policy should be selecting the
> pool element that gets the lowest value when calculating: load value +
> degradation counter * load degradation
>
> Forgetting to multiply the load degradation factor with the counter of
> loads assigned I think miss the whole purpose of this policy.

Done. The description has been misleading, since "counter" has been increased 
by "load degradation". A counter should be incremented by 1. Therefore, I 
have changed the part as follows:

-----
For every pool element entry, a degradation counter MUST be stored. When
a pool element entry is added or updated by registration or reregistration, 
this counter MUST be set to 0. When an entry is selected for being returned 
to a pool user, the internal degradation counter MUST be incremented by 1. 
The selection of pool element entries is handled like for LU, except that the 
selected pool element entries SHOULD have the lowest possible sum of load 
value + degradation counter * load degradation value.
-----


> 3. Section 5.4.1:
> "ratio of 100%-load to
>    the sum of all pool elements' load values."
>
> I think you should change this formula. I first interpreted the minus
> sign as continunation but that didn't make much sense. Also I think 100%
> needs to be represented as it is in the protocol with 0xFFFFFFFF.
>
> Also shouldn't the used ratio be = (0xFFFFFFFF - load_A) /
> (sum(0xFFFFFFFF-load_x)) i.e. this PE's unload part related to the whole
> pools unload rate. I think that makes more sense than to calculate it as
> unloaded divided by the sum of the total load.

Done.  The description has been changed as follows:

-----
The Randomized Least Used (RLU) policy combines LU and WRAND. That is, the 
pool element entries are selected randomly. The probability for a pool 
element entry A, utilized with load_A, to be selected is (0xFFFFFFFF - 
load_A) / (sum(0xFFFFFFFF-load_x)), i.e. this PE's unload part related to the 
whole pool unload rate.
-----


> 4. Section 6.
>
> Shouldn't this section discuss the sensitivity the different policies
> has against different type of attacks. For example if an ENRP gets a lot
> of requests for a particular pool and it used a least used policy that
> requires the PE to update its load, then all these requests will end
> pointing to that particular PE. So it is sensitive to flash floods of
> requests. I think there are other considerations that also should be
> noted about the policies.

Policies are affected by misinformation propagated into the handlespace by an 
attacker. This generic security threat is already handled in the Threats 
document.


> 5. Section 7.1: I can't understand what the policy is for value
> 0x80000000-0xFFFFFFFF. Is that also specification required, can't be
> registered? To me it seems this range would be best served by first come
> first served.

The idea of this policy range is to have an ID space which can be safely used 
for private, non-standard policies.

I have replaced "user-defined" by "private use" and also added the following 
sentence:
"The Policy Type space from 0x80000000 to 0xffffffff is designated for private 
use."


Best regards
-- 
=======================================================================
 Dr. Thomas Dreibholz

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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBHHgSf32BbsHYPLWURAkjaAKCIA2nIxWR1Zn4LTa7FdmBu0hYydQCffFfK
784Ar2pWZogrMgUs7fuCwxY=
=CD+E
-----END PGP SIGNATURE-----