Re: [Softwires] [Softwire] Algorithmic feature for SD-NAT

[Alain Durand <[e-mail]>]

On Mar 24, 2012, at 1:56 PM, Peng Wu wrote:

> Hi Alain,
> 
> Same question I raised in the other thread.
> 1) So this table is fully static, and we don't consider user entering
> or leaving which may affect the bindings. Instead, the bindings only
> rely on the addresses which won't change along the time.

The bindings are created for paying customers. The idea is that you do not need to make
any pre-supposition on the format of their IPv6 nor the IPv4 address they will be give, both are
totally independent. In particular, this does not require sequential allocation of IP addresses.

Now, how do those static stables change when a customer is added or deleted?
There are essentially 2 ways.
1) out of band configuration. For example Netconf. When the provisioning system add/dele a subscriber,
part of the process is to send a Netconf update to the AFTR.
2) dynamic. When the AFTR sees a new potential subscriber (outside of the known ranges), it ask the central repository
about this subscriber. This could be a radius query. THe results is then cache for next packets. The advantage is that
a 'brand new' AFTR can learn the state on the go, the inconvenient is that it may take a while.



> 2) Then this falls in the manner of pre-configuration for every
> possible user IPv6 address, not on-demand allocation.

Configuration for every IPv6 subscriber, not every possible IPv6 address in the various /64
This is actually not that bad. Compare to BNGs that do the same and more today for IPv4 or IPv6.
In the end, this is about clustering subscribers on groups of AFTR, the size of the cluster being in the
order of magnitude of the number of subscriber per BNGs, maybe up to 10x more.

Alain