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

Magnus Westerlund <[email protected]> Mon, 18 Feb 2008 17:27:13 +0100
Newsgroups gmane.ietf.rserpool
Message-ID <[email protected]>
Thanks,

This document is ready for IETF last call.

Cheers

Magnus

Thomas Dreibholz skrev:
> * PGP Signed by an unknown key: 10/23/2007 at 04:26:39 PM
> 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


-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email protected]
----------------------------------------------------------------------