Subject: [BEHAVE] CGN REQ: Load-balancing

From: <[email-masked]>
Date: Thu, 17 Mar 2011 08:05:55 +0100

Dear authors,

The current I-D text does not elaborate on load-balancing when several CGNs are deployed. It would be useful to have something documented in the requirement document.

Examples of requirement to be included:
* Avoid oscillation
* Avoid traffic split between several CGNs
* when (static) port forwarding is used, ensure the appropriate CGN is used
* Etc.

You can find more discussion on this in:

* http://tools.ietf.org/html/draft-xu-behave-stateful-nat-standby-05#section-5
* http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-01#section-3

Cheers,
Med

---

From: Simon Perreault <[email-masked]>
Date: Fri, 25 Mar 2011 20:37:49 -0400

> * Avoid traffic split between several CGNs

The above two do not seem to be specific to CGNs. They could also apply to plain
routers, could they not?

> * when (static) port forwarding is used, ensure the appropriate CGN is used

I don't understand this one. Since it is static, why does it matter which CGN is
used?

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

---

From: <[email-masked]>
Date: Sun, 27 Mar 2011 13:47:28 +0200

Dear Simon,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Simon Perreault
Envoyé : samedi 26 mars 2011 01:38
À : [email-masked]
Objet : Re: [BEHAVE] CGN REQ: Load-balancing

Med: because 

* The CGN is not necessarily embedded in a router
* the stateful nature of the CGN 
* if two CGNs are used, distinct external IP addresses will be used
* imagine your RTP flows handled by CGN1 and RTCP by CGN2...

Med: Because the static mappings are not instantiated in all CGNs in the network! Per-subscriber static mappings are likely to be configured only in one CGN. If you load balance your traffic between several CGN in a blind manner, the service will be broken for those customers. To avoid this, your load-balancing must redirect the customers to the CGN where their static mappings are instantiated. 

BTW, this less critical for PCP-instructed mappings because the PCP Client or IWF will recreate the mapping when a new CGN is assigned. 

Thanks,
Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Francis Dupont <[email-masked]>
Date: Sun, 27 Mar 2011 14:13:21 +0200

In your previous mail you wrote:

=> I disagree about this argument: the NAT function is a super set
of the router function (yes I know you can write a NAT code for
a L2 device but such a thing should be at least strongly NOT RECOMMENDED).

Regards

[email-masked]

---

From: <[email-masked]>
Date: Sun, 27 Mar 2011 14:24:54 +0200

Re-,

An IP router is not supposed to NAT; it should forward IP datagrams.

A CGN is an IP node but not necessarily an IP router. BTW, we have a similar issue in the VoIP case where we have SBCs (which are some kind of CGN); some products in the market do not embed OSPF/ISIS/BGP/6PE/etc stacks...

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : dimanche 27 mars 2011 14:13
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Simon Perreault; [email-masked]
Objet : Re: [BEHAVE] CGN REQ: Load-balancing 

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 27 Mar 2011 14:39:50 +0200

=> so you share my opinion the IP router function is to forward IP packets.

   A CGN is an IP node but not necessarily an IP router.

=> this is a point where I disagree: a CGN MUST be an IP router
(it is so obvious BEHAVE never emits such a requirement, BTW RFC 2663
(the place where NATs are defined) explicitly stands NATs are router,
cf 2.2. Transparent routing).

   BTW, we have a similar issue in the VoIP case where we have SBCs
   (which are some kind of CGN); some products in the market do not
   embed OSPF/ISIS/BGP/6PE/etc stacks...
   
=> to be an IP router doesn't mean to have to support routing protocols
(even someone could argue this makes an IP router easier to use).

Regards