Hi Rémi,
Thank you for this input.
As for the differentiated port sets, I'm planning to add the following
properties to -01 of draft-bsd-* (need to be discussed with my co-authors):
o Differentiated Port Sets (Bound to the same IP address):
Capability to assign port sets of different sizes to customers
assigned with the same IPv4 address.
o Differentiated Port Sets (Network Level): Capability to assign
port sets of different sizes to customers attached to the same
network.
These properties aim to assess the ability of the solution to define different
classes of customers having distinct port usage needs. This feature can be
supported by dedicating distinct IPv4 address pools but this impacts route
aggregation.
To double check the ability of 4rd-addmapping algo to support differentiated
port sets without any state on the BR, could you please provide some examples
to show this behaviour? FWIW, below are listed some configuration proposals:
(1) Differentiated port sets bound to distinct IPv4 address
* Port sets of 4096 ports when the shared IPv4 belongs to POOL_IPv4@_1
* Port sets of 1024 ports when the shared IPv4 belongs to POOL_IPv4@_2
(2) Differentiated port sets bound to the same IPv4 address (Because 0-4095
range is excluded, (n+1)*4096 + m*1024 = 2^16))
* Port sets of 4096 ports assigned to n CPEs
* Port sets of 1024 ports assigned to m CPEs
Thanks.
Cheers,
Med
-----Message d'origine-----
De : Rémi Després [mailto:[email protected]]
Envoyé : lundi 12 septembre 2011 12:01
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Softwires-wg; Wojciech Dec
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms
(draft-bsd-softwire-stateless-port-index-analysis)
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
