Subject: [BEHAVE] SD-NAT

From: Alain Durand <[email-masked]>
Date: Mon, 14 Nov 2011 03:14:49 -0800

Dear Behave wg:

SD-NAT ( http://tools.ietf.org/html/draft-penno-softwire-sdnat-01 ) was presented today in Softwire and will be presented again in Behave on Thursday.

The overall feedback in Softwire was that SD-NAT is a stretch for this wg and maybe Behave could be a better place as this is really CGN optimization. So, I'd like to restart the discussion here on this mailling list in preparation to the Behave meeting.

** So, what is SD-NAT and what problem does it solve?

To deal with IPv4 exhaust, the commonly deployed approach today is IPv4 address sharing, usually wih a CGN in NAT44 (or NAT444) if the access network is IPv4 or with an AFTR in DS-Lite if the access network is IPv6. The message that came loud and clear to the IETF community was that service providers didn't like much having state and heavy logging in the middle of the network. Techniques like deterministic NAT have addressed the logging issue, but the state remains an issue.

In a nutshell, SD-NAT is a way to make those CGNs stateless by introducing a simple configuration change on the CPEs.

** What does a stateless CGN bring to the table?

Having a stateless CGN means higher performance, lower delay, lower cost and a very simple high availability solution.

** Related work

A first answer was the so called 'stateless' approach in Softwire with IPv4 address & port mapping. SD-NAT is another (much simpler) approach to make the CGN stateless, without introducing this notion of address and port mapping. It makes no assumption on what kind of network, IPv4 or IPv6 there is on the access network. In the SD-NAT architecture, the CPE remains essentially unchanged (modulo a new configuration parameter). Just like in NAT44, NAT444 or DS-Lite, the CPE does not need the explicit knowledge of which global IPv4 addres and port range it will be mapped to.

** How does SD-NAT work?

The details are in the draft. At a hight level, the architecture relies on the CPE to translate the src IP address to the one configured on it's WAN interface (as usual), but not use the full [0-65535] port range, instead use a limited range [1024-MaxPort]. That port range is the same for all CPEs.
Because this range is fixed and known by the CGN, the CGN can programmatically map it to a global IPv4 address and port range by shifting it's base IPv4/port by a customer ID multiplied by the number of ports assigned per customers.

All this is just shift/add/multiply on the CGN, there is no per session state to maintain.

   - Alain.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 14 Nov 2011 07:04:34 -0800

On Nov 14, 2011 3:18 AM, "Alain Durand" <[email-masked]> wrote:
>
> Dear Behave wg:
>
> SD-NAT ( http://tools.ietf.org/html/draft-penno-softwire-sdnat-01 ) was
presented today in Softwire and will be presented again in Behave on
Thursday.
>
> The overall feedback in Softwire was that SD-NAT is a stretch for this wg
and maybe Behave could be a better place as this is really CGN
optimization. So, I'd like to restart the discussion here on this mailling
list in preparation to the Behave meeting.
> To deal with IPv4 exhaust, the commonly deployed approach today is IPv4
address sharing, usually wih a CGN in NAT44 (or NAT444) if the access
network is IPv4 or with an AFTR in DS-Lite if the access network is IPv6.
The message that came loud and clear to the IETF community was that service
providers didn't like much having state and heavy logging in the middle of
the network. Techniques like deterministic NAT have addressed the logging
issue, but the state remains an issue.
>
> In a nutshell, SD-NAT is a way to make those CGNs stateless by
introducing a simple configuration change on the CPEs.
> Having a stateless CGN means higher performance, lower delay, lower cost
and a very simple high availability solution.

I have heard this several times but I have never seen these quantified

I ask that the wg reject these assumptions until data is provided that
specifically support each of these claims with quantifiable deltas of
stateful vs stateless

I am aware of the qualitative allure of stateless, but we should be data
driven.

Cb

> ** Related work
>
> A first answer was the so called 'stateless' approach in Softwire with
IPv4 address & port mapping. SD-NAT is another (much simpler) approach to
make the CGN stateless, without introducing this notion of address and port
mapping. It makes no assumption on what kind of network, IPv4 or IPv6 there
is on the access network. In the SD-NAT architecture, the CPE remains
essentially unchanged (modulo a new configuration parameter). Just like in
NAT44, NAT444 or DS-Lite, the CPE does not need the explicit knowledge of
which global IPv4 addres and port range it will be mapped to.
>
>
> ** How does SD-NAT work?
>
> The details are in the draft. At a hight level, the architecture relies
on the CPE to translate the src IP address to the one configured on it's
WAN interface (as usual), but not use the full [0-65535] port range,
instead use a limited range [1024-MaxPort]. That port range is the same for
all CPEs.
> Because this range is fixed and known by the CGN, the CGN can
programmatically map it to a global IPv4 address and port range by shifting
it's base IPv4/port by a customer ID multiplied by the number of ports
assigned per customers.
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Nov 2011 05:40:36 +0900

On 2011-11-15 00:04, Cameron Byrne wrote:
>  > Having a stateless CGN means higher performance, lower delay, lower
> cost and a very simple high availability solution.
>  >
>

Well, simplicity and high availability are qualitative and any classical 
networking textbook will demonstrate that stateless is better on these 
two aspects.

I agree with you about the other claims (performance, delay, cost).

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Nov 2011 12:35:33 +1300

I agree that this draft should be discussed somewhere that's interested in helping
users and SPs to avoid IPv6 as long as possible. I'm not sure BEHAVE is such
a place.

> the architecture relies on the CPE to translate the src IP address to the one configured on it's WAN interface (as usual), but not use the full [0-65535] port range, instead use a limited range [1024-MaxPort]. That port range is the same for all CPEs.

What % of existing CPEs can be remotely configured by the ISP to restrict the port range in this way?

What % of existing CPEs cannot be configured remotely, but can be configured by the user to restrict the port range in this way?

Regards
   Brian

---

From: Alain Durand <[email-masked]>
Date: Mon, 14 Nov 2011 17:14:33 -0800

> I agree with you about the other claims (performance, delay, cost).

On the boxes I'm familiar with, NAT/CGN is done on service cards. The simple reason is that it requires lots of memory to keep the state. A stateless solution would enable to move the implementation to the line card and essentially do NAT at full lime rate. Huge difference.

About high availability, doing fail-over of the full state table is possible, but very expensive. In a stateless solution like SD-NAT, you simply rely on anycast to achieve HA. See the draft for details.

Alain.

---

From: Alain Durand <[email-masked]>
Date: Mon, 14 Nov 2011 17:23:42 -0800

> What % of existing CPEs cannot be configured remotely, but can be configured by the user to restrict the port range in this way?

The functionality is part of the basic IPTABLES module on Linux. There are apparently a couple different favors, but they all have the functionality.

Example on Linux based CPE (Open-WRT, …)

/lib/firewall/uci_firewall.sh

OLD:
$IPTABLES -I zone_${zone}_nat 1 -t nat -o "$ifname" -j MASQUERADE

NEW:
$IPTABLES -I zone_${zone}_nat 1 -t nat -o "$ifname" -j MASQUERADE -p tcp --to-ports 1024-2023

Alain.

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 15 Nov 2011 09:28:01 +0800

does the number of ports allocated on each CPE (i.e. 1024-2023 in the below example) need to be synchronized (i.e. same number of ports per CPE) with the configuration of the CGN?

Marc.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 14 Nov 2011 17:37:44 -0800

On Nov 14, 2011 5:25 PM, "Alain Durand" <[email-masked]> wrote:
> >> the architecture relies on the CPE to translate the src IP address to
the one configured on it's WAN interface (as usual), but not use the full
[0-65535] port range, instead use a limited range [1024-MaxPort]. That port
range is the same for all CPEs.
> > What % of existing CPEs cannot be configured remotely, but can be
configured by the user to restrict the port range in this way?
>
> The functionality is part of the basic IPTABLES module on Linux. There
are apparently a couple different favors, but they all have the
functionality.
> $IPTABLES -I zone_${zone}_nat 1 -t nat -o "$ifname" -j MASQUERADE -p tcp
--to-ports 1024-2023

Using this logic, deploying native ipv6 is trivial on home routers too,
right?

My understanding of the market is that home routers will almost uniformly
need a forklift to support  ipv6 .... And this sd nat as well.  It's more a
market dynamic issue than a technical one.

I will put in a guess that for North America both percentages are less than
1, therefore this solution requires a long term commitment from the sp and
greenfield cpe deployment.

Cb

> Alain

---

From: Alain Durand <[email-masked]>
Date: Mon, 14 Nov 2011 17:45:33 -0800

> does the number of ports allocated on each CPE (i.e. 1024-2023 in the below example) need to be synchronized (i.e. same number of ports per CPE) with the configuration of the CGN?

This is a matter of how much provisioning the service provider is willing to do.

The simplest model is same number of ports for everybody.
The next level is to group subscriber in different categories, make sure their WAN IP address in in a common IP prefix. Then you can easily have a different number of ports per subscriber in each category.
The extreme end of this spectrum is a static per-user mapping table loaded on the CGNs. Note: this remains stateless on a per session basis.

Alain.

---

From: Alain Durand <[email-masked]>
Date: Mon, 14 Nov 2011 17:56:03 -0800

On Nov 14, 2011, at 8:37 PM, "Cameron Byrne" <[email-masked]<mailto:[email-masked]>> wrote:

Using this logic, deploying native ipv6 is trivial on home routers too, right?

Not necessarily.
A number of ISP that provide CPE to their customers have told me that getting simple IPv4 patch for their vendor was relatively easy, getting IPv6 was much harder.

My understanding of the market is that home routers will almost uniformly need a forklift to support  ipv6 .... And this sd nat as well.  It's more a market dynamic issue than a technical one.

I agree with the 1st part of your assertion, but not necessarily with the second one. Yes, SD-NAT introduce a change on the CPEs, yes, the legacy retail CPEs may be out of reach, but the this seems to be doable on managed CPEs or any device where code patch can be uploaded (eg a smart phone)

Alain.

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 15 Nov 2011 09:59:03 +0800

say CGN is configured for 1000 ports per user.  Ehat happens if one CPE1 is configured 1024-2023 and CPE2 is configured 1024-3050 and they are in the same CGN domain?  (for example, CPE1 vendor is X, CPE2 vendor is Y and they have different default setup). What happens to the CGN about the fact that CPE2 can not use 2024-3050? let it use them and overlap with the user of CPE3? error message? silent drop?

Marc.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 14 Nov 2011 20:06:04 -0600

Hi Marc,

I think the assumption is that each CPE has a different WAN address. No
shara.

Regards,

Behcet

On Mon, Nov 14, 2011 at 7:59 PM, Marc Blanchet <[email-masked]>wrote:

> say CGN is configured for 1000 ports per user.  Ehat happens if one CPE1
> is configured 1024-2023 and CPE2 is configured 1024-3050 and they are in
> the same CGN domain?  (for example, CPE1 vendor is X, CPE2 vendor is Y and
> they have different default setup). What happens to the CGN about the fact
> that CPE2 can not use 2024-3050? let it use them and overlap with the user
> of CPE3? error message? silent drop?
>
> Marc.
>
> >> does the number of ports allocated on each CPE (i.e. 1024-2023 in the
> below example) need to be synchronized (i.e. same number of ports per CPE)
> with the configuration of the CGN?
> >
> > The next level is to group subscriber in different categories, make sure
> their WAN IP address in in a common IP prefix. Then you can easily have a
> different number of ports per subscriber in each category.
> > The extreme end of this spectrum is a static per-user mapping table
> loaded on the CGNs. Note: this remains stateless on a per session basis.
> >
> > Alain.
>

---

From: Rajesh Mohan <[email-masked]>
Date: Mon, 14 Nov 2011 18:06:42 -0800

The draft proposes (Section 4.6) that an ICMP error message type 13 be sent.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Blanchet
Sent: Monday, November 14, 2011 5:59 PM
To: Alain Durand
Cc: [email-masked]
Subject: Re: [BEHAVE] SD-NAT

Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 15 Nov 2011 10:07:46 +0800

Le 2011-11-15 à 10:06, Behcet Sarikaya a écrit :

> Hi Marc,
> 
> I think the assumption is that each CPE has a different WAN address.

indeed. I was assuming it. My question is the behavior of the CGN in the case below.  Like when a CGN is out of ports for an end-user?

Marc.

> No shara.
> 
> Regards,
> 
> Behcet
> 
> On Mon, Nov 14, 2011 at 7:59 PM, Marc Blanchet <[email-masked]> wrote:

---

From: Alain Durand <[email-masked]>
Date: Mon, 14 Nov 2011 18:14:49 -0800

Correct.
Each CPE has a unique WAN address (private v4 or v6).
All CPEs (in a category) use the same port range [1024...Maxport]

Alain.

On Nov 14, 2011, at 9:06 PM, "Behcet Sarikaya" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Marc,

I think the assumption is that each CPE has a different WAN address. No shara.

Regards,

Behcet

On Mon, Nov 14, 2011 at 7:59 PM, Marc Blanchet <[email-masked]<mailto:[email-masked]>> wrote:
say CGN is configured for 1000 ports per user.  Ehat happens if one CPE1 is configured 1024-2023 and CPE2 is configured 1024-3050 and they are in the same CGN domain?  (for example, CPE1 vendor is X, CPE2 vendor is Y and they have different default setup). What happens to the CGN about the fact that CPE2 can not use 2024-3050? let it use them and overlap with the user of CPE3? error message? silent drop?

Marc.

Le 2011-11-15 à 09:45, Alain Durand a écrit :

> On Nov 14, 2011, at 8:28 PM, "Marc Blanchet" <[email-masked]<mailto:[email-masked]>> wrote:
>

_______________________________________________
Behave mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/behave

---

From: Alain Durand <[email-masked]>
Date: Mon, 14 Nov 2011 18:16:08 -0800

> indeed. I was assuming it. My question is the behavior of the CGN in the case below.  Like when a CGN is out of ports for an end-user?

ICMP error. See draft for details.

Alain.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 14 Nov 2011 20:33:22 -0600

I share Cameron's concerns here as this draft removes the nicest feature of
DS-Lite: IPv6 only access network :-).

Behcet

On Mon, Nov 14, 2011 at 9:04 AM, Cameron Byrne <[email-masked]> wrote:

> > The overall feedback in Softwire was that SD-NAT is a stretch for this
> wg and maybe Behave could be a better place as this is really CGN

---

From: Alain Durand <[email-masked]>
Date: Mon, 14 Nov 2011 18:38:41 -0800

On Nov 15, 2011, at 10:33 AM, "Behcet Sarikaya" <[email-masked]> wrote:

> I share Cameron's concerns here as this draft removes the nicest feature of DS-Lite: IPv6 only access network :-).
> 
> Behcet

Actually, SD-NAT works quite well with DS-Lite to make a stateless DS-Lite solution.
Details in the draft, but essentially all CPEs nat to 192.0.0.2 and the AFTR use the IPv6 address of the CPE as customer ID.

Alain.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 14 Nov 2011 20:57:48 -0600

Without IPv6, DS-Lite becomes double NAT or NAT444.

Behcet

On Mon, Nov 14, 2011 at 8:38 PM, Alain Durand <[email-masked]> wrote:

> > I share Cameron's concerns here as this draft removes the nicest feature
> of DS-Lite: IPv6 only access network :-).
> >
> > Behcet
>
> Details in the draft, but essentially all CPEs nat to 192.0.0.2 and the
> AFTR use the IPv6 address of the CPE as customer ID.
>
> Alain.

---

From: Alain Durand <[email-masked]>
Date: Mon, 14 Nov 2011 19:12:55 -0800

I don't understand what you mean by 'without IPv6'?
In the proposal here with SD-DS-Lite, the CPEs are still provisioned with IPv6-only.

Alain.

Sent from my iPad

On Nov 15, 2011, at 10:57 AM, "Behcet Sarikaya" <[email-masked]<mailto:[email-masked]>> wrote:

Behcet

On Mon, Nov 14, 2011 at 8:38 PM, Alain Durand <[email-masked]<mailto:[email-masked]>> wrote:

Alain.

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 15 Nov 2011 07:26:54 +0000

My understanding is if DS-NAT will need to do double-NAT when apply in
DS-lite. This defeats one of the major advantage of DS-lite, doesn't it?

On 11/14/11 10:12 PM, "Alain Durand" <[email-masked]> wrote:

>On Nov 15, 2011, at 10:57 AM, "Behcet Sarikaya"
><[email-masked]<mailto:[email-masked]>> wrote:
>
>On Mon, Nov 14, 2011 at 8:38 PM, Alain Durand
><[email-masked]<mailto:[email-masked]>> wrote:
>On Nov 15, 2011, at 10:33 AM, "Behcet Sarikaya"
><[email-masked]<mailto:[email-masked]>> wrote:
>
>> I share Cameron's concerns here as this draft removes the nicest
>>feature of DS-Lite: IPv6 only access network :-).
>>
>> Behcet
>

---

From: Olivier Vautrin <[email-masked]>
Date: Mon, 14 Nov 2011 23:59:56 -0800

Yes. But you gain the advantage of having a Stateless AFTR. It is a
tradeoff.

/Olivier

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Nov 2011 09:34:06 +0100 (CET)

> I am aware of the qualitative allure of stateless, but we should be data 

I have one data point:

A Cisco 7600 can to 6to4 at 10-15Mpps on the SUP because it's stateless, 
it'll do 128-256k flows of regular NAT, because it's stateful.

There are network processor blades that does stateful NAT as well, they 
usually have limitations in the millions of flows and gigabits/s, whereas 
stateless solutions if properly implemented scales to 10x or more and no 
limitation in number of flows.

I understand the "citation needed", but what kind of data do you need to 
feel that it's been quantified?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 15 Nov 2011 03:57:06 -0500

How about this draft?

http://tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-00

It is the base premise of dozens of other drafts in softwires WG.

Thanks,

Reinaldo

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Nov 2011 09:25:39 -0500

On 11/14/2011 08:23 PM, Alain Durand wrote:
> The functionality is part of the basic IPTABLES module on Linux.

Even though many CPEs are based on Linux, many of them do not use
iptables for their NAT functionality. Instead they have their own code 
or they use hardware-assisted NAT. So I'm not sure this argument has weight.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Qiong <[email-masked]>
Date: Wed, 16 Nov 2011 09:45:47 +0800

Hi Mikael,

I agree stateless is a good point in terms of scalability, reduced logging
and cost, etc. And I think it is a reasonable model for NAT444 which can
greatly reduce the burden of CGN.

Best wishes

Qiong

On Tue, Nov 15, 2011 at 4:34 PM, Mikael Abrahamsson <[email-masked]>wrote:

> ______________________________**_________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/behave<https://www.ietf.org/mailman/listinfo/behave>
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 Nov 2011 10:53:38 +0800

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Mikael Abrahamsson
> Sent: Tuesday, November 15, 2011 4:34 PM
> To: Cameron Byrne
> Cc: [email-masked]; Alain Durand
> A Cisco 7600 can to 6to4 at 10-15Mpps on the SUP because it's
> stateless, it'll do 128-256k flows of regular NAT, because 
> it's stateful.

I understand the implementation of tunneling and NAT in that box 
is different, as well -- tunneled packets are processed in the 
interrupt path, whereas NATted packets are processed by punting
the packets out of the interrupt path.  This is always slower,
but due to an implementation decision on that platform.

As a counter-example, there are many $100 consumer-grade NATs 
which handle tens of megabits.  They NAT packets in what
is effectively their interrupt path.

-d

---

From: Alain Durand <[email-masked]>
Date: Tue, 15 Nov 2011 19:43:29 -0800

On Nov 16, 2011, at 10:54 AM, "Dan Wing" 
> is effectively their interrupt path.

The level of performance and reliability expected from those boxes is very different than the ones expected for CGNs. In particular, there is no HA and things are not done at 10Gbps or more.

Alain

---

From: Alain Durand <[email-masked]>
Date: Tue, 15 Nov 2011 20:35:03 -0800

> DS-lite. This defeats one of the major advantage of DS-lite, doesn't it?

Actually, because the CGN is stateless, this is more a split NAT model than a double NAT.

Alain.

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 16 Nov 2011 06:17:03 +0000

I don't understand the difference between split NAT and double-NAT. Could you please explain the difference?

---

From: Nejc Škoberne <[email-masked]>
Date: Wed, 16 Nov 2011 14:39:06 +0800

Hi,

> A number of ISP that provide CPE to their customers have told me that getting simple IPv4 patch for their vendor was relatively easy, getting IPv6 was much harder.

I am really curious about this. Why would this be? I am really interested 
in the technical details.

Thanks,
Nejc

---

From: Olivier Vautrin <[email-masked]>
Date: Tue, 15 Nov 2011 22:55:48 -0800

As an example, I cannot install Ipv6 on my Linksys WAP54G at home because
of memory limitation (cannot run the correct dd-wrt image).

You can have a look here for the the different dd-wrt image size:
http://www.dd-wrt.com/wiki/index.php/What_is_DD-WRT%3F#File_Versions

/Olivier

On 11/16/11 2:39 PM, "Nejc Škoberne" <[email-masked]> wrote:

>> A number of ISP that provide CPE to their customers have told me that
>>getting simple IPv4 patch for their vendor was relatively easy, getting
>>IPv6 was much harder.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Nov 2011 08:28:21 +0100 (CET)

On Wed, 16 Nov 2011, Dan Wing wrote:

> As a counter-example, there are many $100 consumer-grade NATs which 
> handle tens of megabits.  They NAT packets in what is effectively their 
> interrupt path.

You're right, generally, stateless can be implemented in classic 
forwarding ASIC. Stateful needs to have CPUs to handle it. This generally 
means magnitudes of performance difference.

---

From: Nejc Škoberne <[email-masked]>
Date: Wed, 16 Nov 2011 19:19:50 +0800

Hi,

> http://www.dd-wrt.com/wiki/index.php/What_is_DD-WRT%3F#File_Versions

Okay, if you need dd-wrt, that's true (and it's also true that WAP54G is
a severly restricted piece of hardware). However, you could always run
other less by-default-feature-rich distributions as OpenWRT? I am 
running a Whiterussian on a ASUS router with 2MB flash memory. WAP54G
ver. >= 2 has 4MB of flash memory AFAIK ...

Nejc

---

From: Dean cheng <[email-masked]>
Date: Wed, 16 Nov 2011 14:20:08 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Alain Durand
> Sent: Monday, November 14, 2011 5:15 PM
> To: Simon Perreault
> Cc: [email-masked]
> On the boxes I'm familiar with, NAT/CGN is done on service cards. The
> simple reason is that it requires lots of memory to keep the state. A
> stateless solution would enable to move the implementation to the line
> card and essentially do NAT at full lime rate. Huge difference.
> 
> About high availability, doing fail-over of the full state table is
> possible, but very expensive. In a stateless solution like SD-NAT, you
> simply rely on anycast to achieve HA. See the draft for details.
> 
> Alain.
> 

Just want to add that even still with service cards, this solution has a significant advantage by eliminating logging on CGN that has been a big concern and new for ISP. Perfect things are rare in reality, but SD-NAT gives one more option for ISP when they have to deploy CGN.

Dean

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 16 Nov 2011 06:43:49 -0800

On Nov 16, 2011 6:23 AM, "Dean cheng" <[email-masked]> wrote:
> Just want to add that even still with service cards, this solution has a
significant advantage by eliminating logging on CGN that has been a big
concern and new for ISP. Perfect things are rare in reality, but SD-NAT
gives one more option for ISP when they have to deploy CGN.

Right. More is better , right ?

Cb

---

From: Dean cheng <[email-masked]>
Date: Wed, 16 Nov 2011 00:02:28 +0000

> simply rely on anycast to achieve HA. See the draft for details.

Just want to add that even still with service cards, this solution has
a significant advantage by eliminating logging on CGN that has been a big 
concern and new for ISP. Perfect things are rare in reality, but SD-NAT
gives one more option for ISP when they have to deploy CGN.

Dean

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 16 Nov 2011 20:10:54 -0500

Updated based on comments from Senthil and others.

Thanks,

Reinaldo