Hi Med,

Here is an update concerning 4rd-addmapping in this draft (sec 2.1.6): 

   +-------------------------------------------+---------------------+
   |                                  Property | Value               |
   +-------------------------------------------+---------------------+
   |                                Complexity | --                  |
   |                     Address Sharing Ratio | 1:2^p,  p up to 14  |
   |             Number of ports in a Port-Set | 2^p * 15/16         |
   |       Guessing Complexity of a Valid Port | --                  |
   | Guessing Complexity of the whole Port-Set | --                  | 
   |                            Excluded ports | 0-4095, to be 0-1023|
   |                     Minimal Sharing Ratio | 1:1                 |
   |                     Maximal Sharing Ratio | 1:16K               |
   |                        Multiple Port Sets | Supported           |
   |                  Differentiated Port Sets | Supported           |
   |                       DomPref Flexibility | Supported           |
   |                    IPv4 traffic Isolation | Supported           |
   |                        Prefix Aggregation | Preserved           |
   |            Encode Routing Bits in 64 bits | Supported           |
   |                  Compliancy with RTP/RTCP | Compliant           |
   +-------------------------------------------+---------------------+

The line on Multiple Port Sets has been kept, but you announcement that it will 
be deleted is understood and approved.

It is also understood that you intend to distinguish Differentiated port set 
sizes "Per-customer" from  "Per customer class" (a clarifying distinction)

A suggestion is to also distinguish between "Per-customer with PRR states" from 
"Per customer without PRR states".
(The new 4rd has been designed to support the latter, which is useful for 
direct CPE-CPE routes. This isn't the case of all proposals.)

Another criterion that differentiates proposals is whether the port set 
derivation depends on Domain-specific parameters, or is purely algorithmic 
without parameter.

As we discussed, I also work on tables listing differentiating features of 
proposed solutions.
They distinguish functional features of:
- port-set specifications 
- IPv6 address formats of CPEs and AFTRs
- Packet formats for IPv6-domain traversal
They are intended to be easily modifiable, so as to be a temporary tool to 
facilitate discussion. 

FYI, Alain having expressed interest in having them in draft form before the 
meeting, I plan to edit the draft this week.

Cheers,
RD





Le 5 sept. 2011 à 18:44, <[email protected]> 
<[email protected]> a écrit :

> Dear all,
> 
> We have just submitted an I-D analysing the port set algorithms we have on 
> the table. A set of properties are used to characterize the port set 
> algorithms.
> 
> This is a call for review. In particular, we invite authors of the following 
> proposals to review their section:
> 
>  o  [I-D.boucadair-behave-ipv6-portrange]
>  o  [I-D.xli-behave-divi]
>  o  [I-D.murakami-softwire-4v6-translation]
>  o  [I-D.murakami-softwire-4rd]
>  o  [I-D.despres-softwire-4rd-addmapping]
> 
> Questions, suggestions, corrections and contributions are more than welcome.
...
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to