Le 2013-01-30  13:47, Ole Troan <[email protected]> :

> Tom,
> 
> [...]
> 
>>> I don't at all see why moving the port mapping algorithm out of the
>>> document would make things simpler. it would make it a lot more
>>> complex. then you'd end up with having to support many different port
>>> algorithms.
>>> 
>>> 
>> My first reaction to that is to say: unless we fix a at 4, you're going to 
>> be stuck with implementing the a = 0 case anyway, so you might as well use 
>> that and exclude the lowest values of PSID if you want to keep things 
>> simple. The WG really needs to have an opinion on which direction to go here.
> 
> a premise of MAP is to not put any dependency on the IPv6 addressing plan of 
> the ISP. excluding e.g. PSID = 0, would require the ISP
> to not delegate that prefix to the end-user. that's a dependency we do not 
> want.
> 
> I'm fine with fixing a to 4.
> if an end user needs well known ports, give her a full address.

An alternative is possible that
- permits ISPs that want it to assign well-known ports to some privileged users 
without necessarily giving them full IPv4 addresses;
- uses a trivially simple algorithm.

That which has been chosen for 4rd can be used for MAP-E as well. It uses for 
this an option to be used if well-nown ports must be assignable.

It is specified in two sentences, in 
http://tools.ietf.org/html/draft-ietf-softwire-4rd-04#page-15, at the end of 
the first paragraph. 
Its complete picture representation is in a part of Figure 5:
  
                 (by default)           (If WKPs authorized)
                    :    :                  :    :
                +---+----+---------+        +----+-------------+
   Ports in     |> 0|PSID|any value|   OR   |PSID|  any value  |
the CE port set +---+----+---------+        +----+-------------+
                : 4 :     12       :        :        16        :


Regards,
RD



>> Thinking in terms of the broader picture, I still wonder if the port mapping 
>> algorithm should be documented separately with MAP having a normative 
>> dependency on it, just so the algorithm is reusable amongst all A+P variants.
> 
> that is really water under the bridge at this stage.
> we have been there and tried that. that's how we started with MAP as the base 
> document, and separate MAP-E and MAP-T documents.
> 
> cheers,
> Ole
> _______________________________________________
> Softwires mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to