Le 2012-03-07 à 15:27, Ole Trøan a écrit :

> Remi,
> 
>>>> Trying to figure out what the MAP port-set algorithm is, I was confused:
>>>> (a) According to MAP dhcp-option-02, parameters are AFAIK:
>>>> - the PSID length (implicit, derived from ea-len and prefix4-len)
>>>> - excluded-ports
>>>> - offset
>>>> (b) According to MAP address-and-port-03 parameters are:
>>>> - Sharing ratio R 
>>>> - Maximum number of contiguous ports M
>>>> - an apparently fixed set of excluded ports (0-4095)
>>>> Could you clarify what is proposed?
>>> 
>>> sharing ratio can be derived from the PSID length. M can be derived from 16 
>>> - offset - PSID length.
>>> PSID length is derived from EA-bits length.
>> 
>>> the only specific to the algorithm that may be provisioned (it is optional) 
>>> is the offset.
>>> and in theory the excluded ports.
>> 
>> "in theory" doesn't really clarify.
>> Is it a parameter?
>> - If yes, the MAP-address-and-port draft needs AFAIK an update
>> - If no, the MAP-dhcp-02 draft needs AFAIK to be modified
>> 
>> If I missed something, thanks for an explanation.
> 
> you are likely right, that there is some discrepancy between the two.
> offset versus excluded ports may be an open issue. e.g an offset of 0, 
> implies that the system ports are included. should we allow that also for 
> offset > 0. (I would prefer not.)

Well, if offset=0, it depends the PSID length whether some of of the 0-1023 
ports are distributed among several CEs (only one CE gets, for example, port 
80, or all assigned to a single CE. 
This is a complexity for which, again, I cannot see a real use case. 


> 
>>> my personal view, is that we should drop the optional parameters too.
>> 
>> Sees (*) below.
>> 
>>> the algorithm would still be the same though.
>> 
>> See (**) below
>> 
>> 
>>>> 2.
>>>> Detailed MAP examples you give have excluded ports 0-4095, offset=4, and 
>>>> no M.
>>>> This is exactly what 4rd has without needing any parameter, and with a 
>>>> trivial algorithm instead of the somewhat brain-teasing algorithm copied 
>>>> below.
>> 
>> 
>>>> Could you clarify which use cases you see that would justify such 
>>>> complexity?
>> 
>> (*) So, you don't personally see any use case than would justify a 
>> PSID-algorithm parameter.
>> We both agree on this.
> 
> my personal preference is for fixed offset, and that the only way to assign 
> system ports is by assigning a full IPv4 address. the design team reached a 
> compromise on allowing the algorithm to be tunable though.

A compromise between what and what?
Since there is no MAP-discussion archive, it's hard to guess what the issue has 
been.
Since we both believe no parameter is needed, can we consider this is the WG 
provisional as long as no significant use case is provided?
 

>>> I think you misunderstand. what you see below is the 4rd algorithm.
>> 
>> ??? (see below)
>> 
>>> please write an implementation of your version of the algorithm, and see if 
>>> you don't end up with pretty much the same as is shown below.
>> 
>> (**) 4rd derives a port set from a PSID as shown in the picture below. I 
>> would implement it with masks and shifts rather than with multiplications 
>> and divisions and, in any case, without needing to think of any "Maximum 
>> number of contiguous ports" and a "Sharing ratio".
>> 
>>                          : 4 :    
>>                          +---+----+---------+
>> Ports in the CE port set |> 0|PSID|any value|
>>                          +---+----+---------+
>>                          :        16        :
> 
> 
> ehem, "any value" is what we call "Maximum number of contiguous ports".

You explanation is still confusing:
- Maximum number of contiguous ports is of course NOT "any value".
- It should be AFAIK 2^(12 - PSID length).

I agree however that, with adequate parameter values, a non ambiguous 
Generalized Modulus Algorithm could create port of the PSID-derived port set 
above, but all the algorithmic complexity below (copied again since you deleted 
it from your response) is completely SUPERFLUOUS to specify this port set.

"The port number (P) of a given PSID (K) is composed of: P = R * M * j + M * K 
+ i  Where: 
*  PSID: K = 0 to R - 1
*  Port range index: j = (4096 / M) / R to ((65536 / M) / R) - 1, if the 
well-known port numbers (0 - 4096) are excluded.
*  Contiguous Port index: i = 0 to M - 1"

BTW, j is very indirectly defined if excluded ports are different from 0-4096 
(actually  0-4095).


Leaving this discussion at this point would be OK for me until a justification 
for a flexible algorithm is provided.
Cheers,
RD

 

> that we chose to label the field, can hardly be an argument for it being more 
> complex.
> all shared IP address solution has a notion of sharing ratio.
> 
> cheers,
> Ole
> 

_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to