Hi Med, I am, as you remember, well aware of these rules.
But the fact is that, with the fixed PSID offset = 4 of 4rd-u (which could easily also apply to MAP), we have the following: R-4: sharing ratios are from 1 to 2048 (PSID length limited to 11 for odd-even pairs always be in port sets) => OK R-7: ports 0-1023 are excluded for sharing ratios 2 to 2048 => OK R-8: well-known ports can be assigned to CEs with sharing ratio 1 => OK So far, this seems to me so completely sufficient. Yet, if some ISP has a deployment plan where it is convincingly necessary to have more flexibility, that is of course worth discussing. But if there is none, time has come IMHO to simplify what can be simplified. Cheers, RD Le 2012-03-07 à 16:59, <[email protected]> a écrit : > Hi Rémi, all, > > During the MAP discussion, we identified the following requirements: > > R-4: MAP must allow service providers to define their own address > sharing ratio. MAP MUST NOT in particular restrict by design > the possible address sharing ratio; ideally 1:1 and 1:65536 > should be supported. The mapping must at least support a > sharing ratio of 64, 1024 ports per end-user. > > R-7: The MAP solution should support excluding the well known ports > 0-1023. > > R-8: It MUST be possible to assign well known ports to a CE. > > The offset has been proposed as a flexible means to meet the requirements > above. > > Cheers, > Med > > >> -----Message d'origine----- >> De : [email protected] >> [mailto:[email protected]] De la part de Rémi Després >> Envoyé : mercredi 7 mars 2012 16:32 >> À : Ole Trøan >> Cc : Softwires WG >> Objet : Re: [Softwires] Port-set algorithm of MAP - what is >> it? Why so complex? > >>> >>> 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? _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
