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