Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option

[Ole Trøan <[e-mail]>]

> indeed. The contiguous port mask is one example of MAP algorithm. But we hope to simplify it from both implementation and operational point of view, by removing all these parameters and algorithms. Contiguous port-set using port mask is all we need, so we do not need anything more. 

I don't think we'll get anywhere with each of us claiming that "our" algorithm is simpler than yours.
it might be that the formal text in the MAP draft confuses the matter unduly.

let me try and explain again. MAP is based on the very simple idea of describing a port range as a port prefix.
for example I give you the port prefix 10.0/8, if we want to use the same notation as we do for IP prefixes.
10/8 is 256 ports, in the range from 2560 - 2815.

   0                          8                         15
   +---------------+----------+--------------------------+
   | Port Prefix / PSID       |       Port range         |
   +---------------+----------+--------------------------+

for this you need two parameters, port prefix and port prefix length. that is the simplest scheme that anyone has proposed as far as I know.
do you agree?

then the _only_ thing MAP does that is different from the above, is to introduce one more configuration parameter, the offset.
so that instead of it being purely a port _prefix_, the PSID can be a port _infix_ or port _post-fix_.

represented something like this:

   0                          8                         15
   +---------------+----------+--------------------------+
   | Port range    |         PSID       |  Port range    |
   +---------------+----------+--------------------------+

the problem with the port prefix (offset=0) in the top figure for the use as embedded address bits, is that when the PSID is 0 then you'll end up giving the system ports to a user. that would typically not be what you want, and recommending an offset = 4, and the first port range > 0, effectively excludes the system ports. for the case where you create DHCP binding state per customer, you can just make sure to never assign PSID = 0, so in your case you can of course use offset=0

are you still with me?

> And besides, what we need is a DHCPv4 option, not DHCPv6.

why? that's certainly not the only solution. given that you need a DHCPv6 option to provision your IPv4 DHCP server. plus a lot of new complex IPv4 DHCP machinery...?
there is already a DHCPv6 option in process of being standardised. you already depend on options from DHCPv6. why not reuse those existing protocol mechanisms? 

what I would suggest:
  - you merge with / ensure you have your requirements fulfilled by
    draft-ietf-softwire-map-dhcp-01
  - rewrite LW4over6 / Public 4over6 to use DHCPv6 for complete provisioning, using draft-ietf-softwire-map-dhcp

cheers,
Ole