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