Subject: [sfc] Services eligible for chaining

From: Zhuangyuxin <[email-masked]>
Date: Mon, 27 Jan 2014 01:06:21 +0000

Hello, Folks,

For SFC, do you have any concrete service candidates which are eligible for chaining? How about load balancer and NAT, which usually cross subnets and change packet header? Are they suitable for the chain we are discussing here?

Thanks,
Yuxin

---

From: Ron Parker <[email-masked]>
Date: Mon, 27 Jan 2014 01:29:23 +0000

Yuxin,

Both load balancer and NAT are definitely candidates for SFC service functions.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Zhuangyuxin
Sent: Sunday, January 26, 2014 8:06 PM
To: [email-masked]
Subject: [sfc] Services eligible for chaining

Hello, Folks,

Thanks,
Yuxin

---

From: "Songhaibin (A)" <[email-masked]>
Date: Mon, 27 Jan 2014 01:49:12 +0000

I guess it also implies that the original packet as the payload can be changed by the service functions.

Best Regards!
-Haibin

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, January 27, 2014 9:29 AM
To: Zhuangyuxin; [email-masked]
Subject: Re: [sfc] Services eligible for chaining

Yuxin,

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Zhuangyuxin
Sent: Sunday, January 26, 2014 8:06 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] Services eligible for chaining

Hello, Folks,

Thanks,
Yuxin

---

From: Zhuangyuxin <[email-masked]>
Date: Mon, 27 Jan 2014 02:31:44 +0000

Hi, Ron,

Thanks for the reply.

When we consider inserting LB/NAT in the chain, I have some further questions here.

-        Let’s take a chain with NAT service function as an example, user is using this chain to process traffic produced by VM1 accessing Internet. I assume the topology is like this:
         VM1  --- (chain including NAT) --- Router --- Internet
         When traffic from Internet arrives at the router, its destIP points at NAT. How does the router decide the next hop?
-        As the packet is directly addressed to the NAT, does it conflict with the ‘transparent midbox’ concept in draft-parker-sfc-chain-to-path-00?
-        Is it possible for the Router to send out ARP to query for the IP address on NAT? How does NAT react to ARP request especially when NAT is SFC-aware?

Thanks,
Yuxin

发件人: Ron Parker [mailto:[email-masked]]
发送时间: 2014年1月27日 9:29
收件人: Zhuangyuxin; [email-masked]
主题: RE: Services eligible for chaining

Yuxin,

   Ron

Hello, Folks,

Thanks,
Yuxin

---

From: Melinda Shore <[email-masked]>
Date: Sun, 26 Jan 2014 17:56:55 -0900

On 1/26/14 5:31 PM, Zhuangyuxin wrote:
>          When traffic from Internet arrives at the router, its destIP
> points at NAT. How does the router decide the next hop?
> 
> -        As the packet is directly addressed to the NAT, does it
> conflict with the ‘transparent midbox’ concept in
> draft-parker-sfc-chain-to-path-00?
> 
> -        Is it possible for the Router to send out ARP to query for the
> IP address on NAT? How does NAT react to ARP request especially when NAT
> is SFC-aware?

When I first read this I thought "Well, yes, and NAT
is particularly sensitive to network topology (device
ordering)."  But, I think this needn't actually
create a particularly difficult problem here, since
the original packet is going to be encapsulated
by the SFC transport."  However, there can be the
usual problems with service ordering that you find
within a single box - for example, you need to be
attentive to which addresses you're putting into your
firewalling rules, etc.  But that's going to be true,
regardless whether the services are decomposed into
different boxes or co-resident within the same box.
Similarly, the NAT-from-the-outside problem exists
whether or not you're using SFC.

If there's interest I can contribute a draft on middlebox
considerations.

Melinda

---

From: "Songhaibin (A)" <[email-masked]>
Date: Mon, 27 Jan 2014 09:36:45 +0000

> -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of Melinda Shore
> Sent: Monday, January 27, 2014 10:57 AM
> To: [email-masked]
> Subject: Re: [sfc] 答复: Services eligible for chaining
> 

I think the NAT service function is transparent to the end users, but not to SFC.

> > IP address on NAT? How does NAT react to ARP request especially when
> > NAT is SFC-aware?
> 
> When I first read this I thought "Well, yes, and NAT is particularly sensitive to
> network topology (device ordering)."  But, I think this needn't actually create
> a particularly difficult problem here, since the original packet is going to be
> encapsulated by the SFC transport."  However, there can be the usual
> problems with service ordering that you find within a single box - for example,
> you need to be attentive to which addresses you're putting into your firewalling
> rules, etc.  But that's going to be true, regardless whether the services are
> decomposed into different boxes or co-resident within the same box.
> Similarly, the NAT-from-the-outside problem exists whether or not you're using
> SFC.

I do not think we should make the service functions aware of the service function chaining.  SFs should only receive the original packet as they conventionally do, without any SFC headers. The SFC forwarding engine should be responsible for adding/removing the header.

> 
> If there's interest I can contribute a draft on middlebox considerations.

What about also documenting the deployment considerations in it?

BR,
-Haibin

> 
> Melinda
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Melinda Shore <[email-masked]>
Date: Mon, 27 Jan 2014 01:14:25 -0900

On 1/27/14 12:36 AM, Songhaibin (A) wrote:
> I do not think we should make the service functions aware of the
> service function chaining.  SFs should only receive the original
> packet as they conventionally do, without any SFC headers. The SFC
> forwarding engine should be responsible for adding/removing the
> header.

Yes, but NAT is a special case, since it's a service
that actually modifies the IP packet contents and
consequently there's a sensitivity in the *service*
topology.  This is a deployment consideration but
it's also a middlebox consideration.  If I am applying
filtering rules based on source or destination
addresses I need to know what those are at which point
in the network.  If a packet traverses a firewall then
a NAT the firewall rules need to be constructed with
different addresses than if the order is reversed.

I thought the original question was a bit confused, since
the same questions about packets arriving at a NAT are the
same whether the service is decomposed or not decomposed.

Melinda

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 27 Jan 2014 14:10:23 +0000

Hi Haibin,

> I do not think we should make the service functions aware of the service function chaining.  SFs should only receive the original packet as they conventionally do, without any SFC headers. The SFC…

What exactly do you mean by "aware"?  In certain cases, the SFs will need to be aware of the SFC encap.

---

From: Zhuangyuxin <[email-masked]>
Date: Tue, 28 Jan 2014 00:48:21 +0000

Actually, with these questions, I’m trying to figure out when we put any service (e.g. NAT/LB/VPN) with L3 address in the chain, a) how the possible ARP packets are handled, b) how the routing table is configured for the routers which are not in the chain, but the traffic coming out of the chain will go thru.

Thanks,
Yuxin

发件人: sfc [mailto:[email-masked]] 代表 Zhuangyuxin
发送时间: 2014年1月27日 10:32
收件人: Ron Parker; [email-masked]
主题: [sfc] 答复: Services eligible for chaining

Hi, Ron,

Thanks for the reply.

Thanks,
Yuxin

发件人: Ron Parker [mailto:[email-masked]]
发送时间: 2014年1月27日 9:29
收件人: Zhuangyuxin; [email-masked]<mailto:[email-masked]>
主题: RE: Services eligible for chaining

Yuxin,

   Ron

Hello, Folks,

Thanks,
Yuxin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Jan 2014 19:58:01 -0500

A priori, ARP internal to the network will work as always.  Whether that 
is relevant for directing service chain traffic depends upon the service 
chain transport.

In terms of general operation, it helps to keep the two different 
directions, and two different cases.  Traffic from the users should be 
directed via service chain to the services, which are not addressed by 
the user.  The NAT is an example of such a service.

In the reverse direction, there are two ways to handle it, although they 
work out very similarly in the end.
Initially, the easy shortcut is to put the NAT at the end of the chain, 
co-resident with the Internet facing ingress to the chain.  Thus, 
packets will arrive at the right place.
Clearly, that is quite limiting.
So the other laternative is for the NAT to inform the control structure 
of the induced flow bindings (i.e. what the subscriber flow is 
translated into) so that the ingress classifier can put the packets from 
the Internet on the correct chain based on that information.

Yours,
Joel

On 1/27/14 7:48 PM, Zhuangyuxin wrote:
> Actually, with these questions, I’m trying to figure out when we put any
> service (e.g. NAT/LB/VPN) with L3 address in the chain, a) how the
> possible ARP packets are handled, b) how the routing table is configured
> for the routers which are not in the chain, but the traffic coming out
> of the chain will go thru.
>
> Thanks,
>
> Yuxin
>
> *发件人:*sfc [mailto:[email-masked]] *代表 *Zhuangyuxin
> *发送时间:*2014年1月27日10:32
> *收件人:*Ron Parker; [email-masked]
> *主题:*[sfc] 答复: Services eligible for chaining
>
> Hi, Ron,
>
> Thanks for the reply.
>
> -        Let’s take a chain with NAT service function as an example,
> user is using this chain to process traffic produced by VM1 accessing
> Internet. I assume the topology is like this:
>
> *发件人:*Ron Parker [mailto:[email-masked]]
> *发送时间:*2014年1月27日9:29
> *收件人:*Zhuangyuxin; [email-masked] <mailto:[email-masked]>
> *主题:*RE: Services eligible for chaining
>
> Yuxin,
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Zhuangyuxin
> *Sent:* Sunday, January 26, 2014 8:06 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [sfc] Services eligible for chaining
>
> Hello, Folks,
>
> For SFC, do you have any concrete service candidates which are eligible
> for chaining? How about load balancer and NAT, which usually cross
> subnets and change packet header? Are they suitable for the chain we are
> discussing here?
>
> Thanks,
>
> Yuxin
>
>
>

---

From: "Songhaibin (A)" <[email-masked]>
Date: Tue, 28 Jan 2014 01:35:18 +0000

Hi Paul,

> From: Paul Quinn (paulq) [mailto:[email-masked]]
> Sent: Monday, January 27, 2014 10:10 PM
> To: Songhaibin (A)
> Cc: Melinda Shore; [email-masked]
> >> When I first read this I thought "Well, yes, and NAT is particularly
> >> sensitive to network topology (device ordering)."  But, I think this
> >> needn't actually create a particularly difficult problem here, since
> >> the original packet is going to be encapsulated by the SFC
> >> transport."  However, there can be the usual problems with service
> >> ordering that you find within a single box - for example, you need to
> >> be attentive to which addresses you're putting into your firewalling
> >> Similarly, the NAT-from-the-outside problem exists whether or not
> >> you're using SFC.
> >
> > I do not think we should make the service functions aware of the service
> function chaining.  SFs should only receive the original packet as they
> conventionally do, without any SFC headers. The SFC forwarding engine should
> be responsible for adding/removing the header.
> >
> 

I mean they(SFs) can process the packets as there were no SFC. Otherwise we need to upgrade the service functions to support SFC, which will be a hindrance for the adoption of SFC. Maybe I missed something or my thought is too ideal, but what is the use case in your mind that a SF must be aware of the SFC encap? The metadata?

BR,
-Haibin

---

From: Leejun <[email-masked]>
Date: Tue, 28 Jan 2014 02:15:49 +0000

Without SFC, packets can already be forwarded to service functions with L3 address.  In this regard,  service functions with L3 address are quite different to those ‘transparent midbox’.
So, I wonder why SFC should cover NAT and LB.

Regards
Li jun

发件人: sfc [mailto:[email-masked]] 代表 Zhuangyuxin
发送时间: 2014年1月28日 8:48
收件人: Zhuangyuxin; Ron Parker; [email-masked]; Melinda Shore
主题: [sfc] 答复: Services eligible for chaining

Thanks,
Yuxin

Hi, Ron,

Thanks for the reply.

Thanks,
Yuxin

Yuxin,

   Ron

Hello, Folks,

Thanks,
Yuxin

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Tue, 28 Jan 2014 09:53:56 +0000

sfc chain edge nodes have the responsibility to insert/extract the traffic into the chain.  An edge node virtual switch for example will have the responsibility to receive incoming
packets and tie them to corresponding service chains. From that point it can select the next local service function or service Hop that should process the packets.

Let's assume the Service Node is a NAT. The NAT takes the incoming packet from this internet, does its job and sends the traffic to the new destination IP/port.  Somehow,  the Service Node must associate this packet to a service chain and encapsulate the packet so that it goes to the next Service Hop. I don't see how the Service Node virtual switch can do that without some kind of hint from the NAT Service Function: the NAT could for example configure the virtual switch when it create a map entry for a TCP or UDP flow.  A legacy NAT running in a VM and relying only on socket connections could not do the job.

We could decide not to include the NAT in the service chain, use it as a default gateway and distribute its function via virtualization independently.  It makes sense if we don't expect it to apply a specific policy depending on the service chain associated to the traffic.  The draw back here is that we maintain a NAT configuration and management silo in the infrastructure.

The LB case is different and covers different cases as its servers can be "visible" or not from the service chaining point of view. In all cases  the LB itself should be visible in order to receive  the traffic so that it can load balance the traffic: it must be a Service Hop in a Service Chain.

Load balancing can be achieved without a specific LB Service Function: if the service chains contains the selected server instead of the LB as a Service Hop. This technically feasible at the Classifier point (the Edge Node) when the load balancing criteria is a hash on IP source for example.  In fact the Load balancing responsibility is then transferred to the Classifier. This puts a lot of HA responsibility on the central SDN controller which must then monitor the server status.

Although we can do without in some cases, I believe as Ron  that NAT and LB are SFC awareness candidate and should appear in the use cases.

Nicolas
________________________________
From: Leejun [[email-masked]]
Sent: Tuesday, January 28, 2014 3:15 AM
To: Zhuangyuxin; Zhuangyuxin; Ron Parker; [email-masked]; Melinda Shore
Subject: [sfc] 答复: Services eligible for chaining

Regards
Li jun

Thanks,
Yuxin

Hi, Ron,

Thanks for the reply.

Thanks,
Yuxin

Yuxin,

   Ron

Hello, Folks,

Thanks,
Yuxin

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 28 Jan 2014 13:33:13 +0000

Hi,

> I mean they(SFs) can process the packets as there were no SFC. Otherwise we need to upgrade the service functions to support SFC, which will be a hindrance for the adoption of SFC. Maybe I missed s…

Certainly, SFC needs to support services that do not support the SFC encap.  However, the SFC encap can provide valuable information to the SFs such as, as you point out, metadata.  

Paul

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 28 Jan 2014 10:07:36 -0500

NAT for sure needs to be in the SFC at least in the direction that performs the NAT because in that direction the packet dstIP is of the ultimate dst and not that of the NAT.  Typically, you will want your FW, etc to be in the chain before this so the original packets can be inspected, but SFC should not require that specifically.

In the opposite direction, however, SFC is not required to direct the flow through the NAT because the dstIP takes care of that.  The same could be said for L3 LB because that's how we force traffic through the LB in a non SFC world.  However, that shouldn't mean that we *can't* use SFC for these functions esp as its use might allow one to do things with flows that were otherwise not possible.

From: [email-masked]<[email-masked]>
To: Zhuangyuxin<[email-masked]>,Zhuangyuxin<[email-masked]>,Ron Parker<[email-masked]>,[email-masked]<[email-masked]>,Melinda Shore<[email-masked]>
Sent: Monday, January 27, 2014
Subject: [sfc] 答复: Services eligible for chaining

Without SFC, packets can already be forwarded to service functions with L3 address.  In this regard,  service functions with L3 address are quite different to those
‘transparent midbox’.
So, I wonder why SFC should cover NAT and LB.

Regards
Li jun

发件人: sfc [mailto:[email-masked]]
代表 Zhuangyuxin

发送时间: 2014年1月28日
 8:48

 

Actually, with these questions, I’m trying to figure out when we put any service (e.g. NAT/LB/VPN) with L3 address in the chain, a) how the possible ARP packets are handled, b) how the routing table
 is configured for the routers which are not in the chain, but the traffic coming out of the chain will go thru.

Thanks,
Yuxin

发件人: sfc [mailto:[email-masked]]
代表 Zhuangyuxin

发送时间: 2014年1月27日
 10:32

 
Hi, Ron,
 
Thanks for the reply.

-        Is it possible for the Router to send out ARP to query for the IP address on NAT? How does NAT react to ARP request especially when
 NAT is SFC-aware?
 
Thanks,
Yuxin

发送时间: 2014年1月27日
 9:29

收件人: Zhuangyuxin; 
[email-masked]

 
Yuxin,

   Ron

From: sfc [mailto:[email-masked]]
On Behalf Of Zhuangyuxin

To: [email-masked]

 
Hello, Folks,
 
For SFC, do you have any concrete service candidates which are eligible for chaining? How about load balancer and NAT, which usually cross subnets and change packet header? Are they suitable for the chain we are discussing
 here?
 
Thanks,
Yuxin

---

From: Ron Parker <[email-masked]>
Date: Tue, 28 Jan 2014 15:58:17 +0000

Typically, a source NAT/NAPT performed from client to server wants to be reversed in the server to client direction.   This is an excellent use case for a bidirectional chain or coordination of 2 unidirectional chains.   It is often desirable to put the NAT function last in the client to server direction and first in the server to client direction (although this is not universally done).

Also, NAT is traditionally coordinated with routing.   In the server to client direction, the replacement IP addresses must get routed back to the service function that performed the NAT.    This could be achieved in the traditional manner by assuming that the routing is handled outside of SFC.

Alternatively, the reverse flows could be handled by having the classifier arranged topologically such that it sees all traffic arriving from the server side and determines that the relevant flows must go to the NAT service function to be un-NAT’d.    In the classifier approach, either the classifier must be provisioned with filters that match the NAT replacement IP addresses (i.e., coordinated configuration) or some dynamic mechanism must exist between the NAT service function and the classifier such that dynamic policy rules can be installed.

IMO, NAT would be an excellent candidate for one of those 3-5 use cases in our use case document.

    Ron

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 28, 2014 10:08 AM
To: [email-masked]; [email-masked]; Ron Parker; [email-masked]; [email-masked]
Subject: RE: [sfc] 答复: Services eligible for chaining

From: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
To: Zhuangyuxin<[email-masked]<mailto:[email-masked]>>,Zhuangyuxin<[email-masked]<mailto:[email-masked]>>,Ron Parker<[email-masked]<mailto:[email-masked]>>,[email-masked]<[email-masked]<mailto:[email-masked]>>,Melinda Shore<[email-masked]<mailto:[email-masked]>>
收件人: Zhuangyuxin; Ron Parker; [email-masked]<mailto:[email-masked]>; Melinda Shore
收件人: Ron Parker; [email-masked]<mailto:[email-masked]>

---

From: Kevin Glavin <[email-masked]>
Date: Tue, 28 Jan 2014 17:32:00 +0000

Another example of the "bidirectional chain or coordination of 2 unidirectional chains" scenario would be chaining Wan Optimization along with some inspection service such as IPS. Assuming that the segment between the two Wan Opt nodes (Data Center and Branch) is transformed then you have the same scenario where IPS has to be done on the untransformed flow.

In the data center in the outbound direction (towards a remote site) IPS needs to happen before Wan Opt while inbound into the DC, Wan Opt has to be processed before IPS for the IPS to function correctly.

Kevin

________________________________
From: sfc [[email-masked]] on behalf of Ron Parker [[email-masked]]
Sent: Tuesday, January 28, 2014 7:58 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] 答复: Services eligible for chaining

    Ron

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 28 Jan 2014 17:51:40 +0000

Frankly I think the simple response to this is that if *all* you want to do is NAT then you don’t need service chaining; the fundamental point therefore to realize is that if we are using service chaining then presumably NAT is just one of multiple functions that will be applied to the selected traffic flows. In this case SFC is necessary to overcome all of the issues as laid out in the problem statement.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, January 28, 2014 at 10:07 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] 答复: Services eligible for chaining

________________________________
From: [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
To: Zhuangyuxin<[email-masked]<mailto:[email-masked]>>,Zhuangyuxin<[email-masked]<mailto:[email-masked]>>,Ron Parker<[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>,Melinda Shore<[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 27, 2014
Subject: [sfc] 答复: Services eligible for chaining

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 28 Jan 2014 13:16:15 -0500

Actually, even if all you want to do is NAT, but you don't want to have to put the NAT inline (e.g. you only want some of the traffic to be NATed but don't want to pay for links to support all of the traffic that has no need for the NAT service), SFC would be kind of ideal.   

That being said, what does it matter if the NAT is one of multiple functions in a chain or the sole function in the chain?  Either way, it is a valid SF.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 28 Jan 2014 18:18:41 +0000

True enough.

On 1/28/14, 1:16 PM, "[email-masked]" <[email-masked]> wrote:

>Actually, even if all you want to do is NAT, but you don't want to have
>to put the NAT inline (e.g. you only want some of the traffic to be NATed
>but don't want to pay for links to support all of the traffic that has no
>need for the NAT service), SFC would be kind of ideal.
>
>That being said, what does it matter if the NAT is one of multiple
>functions in a chain or the sole function in the chain?  Either way, it
>is a valid SF.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 Jan 2014 14:37:58 -0500

I agree with Jim.  If you have only one service you want to insert, 
there are likely MUCH simpler solutions that the work this group is doing.

If you are using NAT with other services, you need service chaining. 
There are multiple ways to include NAT in the chains (in each 
direction).  Eventually, with a NAT function which preserve the metadata 
and transport headers, the inclusion should be very straightforward.

Yours,
Joel

On 1/28/14, 12:51 PM, Jim Guichard (jguichar) wrote:
> Frankly I think the simple response to this is that if *all* you want to
> do is NAT then you don’t need service chaining; the fundamental point
> therefore to realize is that if we are using service chaining then
> presumably NAT is just one of multiple functions that will be applied to
> the selected traffic flows. In this case SFC is necessary to overcome
> all of the issues as laid out in the problem statement.
>
> From: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>"
> <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> NAT for sure needs to be in the SFC at least in the direction that
> performs the NAT because in that direction the packet dstIP is of the
> ultimate dst and not that of the NAT.  Typically, you will want your FW,
> etc to be in the chain before this so the original packets can be
> inspected, but SFC should not require that specifically.
>
> In the opposite direction, however, SFC is not required to direct the
> flow through the NAT because the dstIP takes care of that.  The same
> could be said for L3 LB because that's how we force traffic through the
> LB in a non SFC world.  However, that shouldn't mean that we *can't* use
> SFC for these functions esp as its use might allow one to do things with
> flows that were otherwise not possible.
>
>
>
>
>
> ------------------------------------------------------------------------
> *From: [email-masked]
> <mailto:[email-masked]><[email-masked] <mailto:[email-masked]>>
> *To: *Zhuangyuxin<[email-masked]
> <mailto:[email-masked]>>,Zhuangyuxin<[email-masked]
> <mailto:[email-masked]>>,Ron
> Parker<[email-masked]
> <mailto:[email-masked]>>,[email-masked]
> <mailto:[email-masked]><[email-masked] <mailto:[email-masked]>>,Melinda
> Shore<[email-masked] <mailto:[email-masked]>>
> *Sent: *Monday, January 27, 2014
> *Subject: *[sfc] 答复: Services eligible for chaining
>
> Without SFC, packets can already be forwarded to service functions with
> L3 address. In this regard, service functions with L3 address are quite
> different to those ‘transparent midbox’.
>
> *发送时间:*2014年1月28日8:48
> *收件人:*Zhuangyuxin; Ron Parker; [email-masked] <mailto:[email-masked]>;
> Melinda Shore
> *收件人:*Ron Parker; [email-masked] <mailto:[email-masked]>
> - Let’s take a chain with NAT service function as an example, user is
> using this chain to process traffic produced by VM1 accessing Internet.
> I assume the topology is like this:
>
> When traffic from Internet arrives at the router, its destIP points at
> NAT. How does the router decide the next hop?
>
> - As the packet is directly addressed to the NAT, does it conflict with
> the ‘transparent midbox’ concept in draft-parker-sfc-chain-to-path-00?
>
> - Is it possible for the Router to send out ARP to query for the IP
> address on NAT? How does NAT react to ARP request especially when NAT is
> SFC-aware?
>
> Thanks,
>
> Yuxin
>

---

From: Srinivasa Chaganti <[email-masked]>
Date: Wed, 29 Jan 2014 11:54:50 -0800

I agree, NAT is a good candidate to be a Service Function in SFC
architecture especially when it is chained with other service functions.
SFC architecture allows any service function to reclassify the traffic and
pick a different service-chain if classifier says so. With NAT we may need
an additional service-chain "NAT chain" just to perform deNAT
functionality on the internet to client direction traffic and do
reclassification of translated packets to pick reverse-chain for rest of
the service functions to be performed. "NAT chain" will be picked by the
classifier for all the traffic destined to public addresses of NAT
function.

Thanks
Chaganti

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, January 28, 2014 10:16 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] 答复: Services eligible for chaining

Actually, even if all you want to do is NAT, but you don't want to have to
put the NAT inline (e.g. you only want some of the traffic to be NATed but
don't want to pay for links to support all of the traffic that has no need
for the NAT service), SFC would be kind of ideal.

That being said, what does it matter if the NAT is one of multiple
functions in a chain or the sole function in the chain?  Either way, it is
a valid SF.
_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc