Subject: [sfc] comments on draft-song-sfc-legacy-sf-mapping-00

From: Ron Parker <[email-masked]>
Date: Wed, 16 Apr 2014 18:37:42 +0000

To the authors of draft-song-sfc-legacy-sf-mapping:

Thank you for contributing this well written draft.   I think this is a very worthwhile issue to tackle, but do have some concerns in the current revision of the draft.   My specific comments are below.

Thanks.

    Ron

Section 2. Terminology

* Suggest enhancing your definition of Transparent SF to also state that it does not inject independent flows into the data stream.   For example, some transparent HTTP Proxies are not source-ip transparent for some or all of their upstream connections, instead using their own loopback or interface IP addresses.

Section 3.1.1. Layer 2 MAC Address

* Legacy service functions that operate above layer 3 would typically not be able to preserve the original SMAC.   Take for example the HTTP Proxy, again.   A typical implementation accepts sockets on the client-facing side and binds/connects sockets on the server-facing side.   Outgoing packets are encapsulated with an Ethernet header containing the local MAC address as the SMAC.

Section 3.1.2. VLAN

* This could be problematic in a virtualized environment where the connection from the SFI to the SFE may not be a direct physical connection.   An SDN-based network typically owns the VLAN ID allocations and interpretation.

Section 3.1.3. QinQ

* Same comment as for VLAN.

Section 3.2.  For Non-transparent Service Functions

* Use of control plane signaling at a packet or flow level would be difficult to scale.

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 17 Apr 2014 01:48:21 +0000

> -----邮件原件-----
> 发件人: sfc [mailto:[email-masked]] 代表 Ron Parker
> 发送时间: 2014年4月17日 2:38
> 收件人: [email-masked]
> 主题: [sfc] comments on draft-song-sfc-legacy-sf-mapping-00
> 
> Thank you for contributing this well written draft.   I think this is a very
> worthwhile issue to tackle, but do have some concerns in the current revision of
> the draft.   My specific comments are below.
> 
> Thanks.
> 
>     Ron
> 
> 
> 
> 
> Section 2. Terminology
> 
> * Suggest enhancing your definition of Transparent SF to also state that it does
> not inject independent flows into the data stream.   For example, some
> transparent HTTP Proxies are not source-ip transparent for some or all of their
> upstream connections, instead using their own loopback or interface IP
> addresses.

I agree that no injection of additional flows should be another requirement for transparent SF. However, I think the transparent legacy SF which is applicable for service chain should at least meet the following requirement: no change to the 5-tuple of the original packet. Otherwise, it would be very hard or even impossible for the SFF to do the mapping without the assistance from the SF (e.g., provide the mappings created on the SF to the SFF). Given the above requirement has been met, why not directly use the 5-tuple for the mapping purpose?

Best regards,
Xiaohu

> * Legacy service functions that operate above layer 3 would typically not be able
> to preserve the original SMAC.   Take for example the HTTP Proxy, again.   A
> typical implementation accepts sockets on the client-facing side and
> binds/connects sockets on the server-facing side.   Outgoing packets are
> encapsulated with an Ethernet header containing the local MAC address as the
> SMAC.
> 
> 
> 
> Section 3.1.2. VLAN
> 
> * This could be problematic in a virtualized environment where the connection
> from the SFI to the SFE may not be a direct physical connection.   An
> SDN-based network typically owns the VLAN ID allocations and interpretation.
> 
> 
> 
> Section 3.1.3. QinQ
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "Songhaibin (A)" <[email-masked]>
Date: Mon, 21 Apr 2014 03:05:49 +0000

Hi Ron and Xiaohu,

Thank you for the wonderful comments.

What about the following changes & clarifications?

Transparent SF: A service function that does not change any bit of the original service packet header sent to it, neither inject any independent flows into the data stream.

>Section 3.1.1. Layer 2 MAC Address

*Legacy service functions that operate above layer 3 would typically not be able to preserve the original SMAC.   Take for example the HTTP Proxy, again.   A typical implementation accepts sockets on the client-facing side and binds/connects sockets on the server-facing side.   Outgoing packets are encapsulated with an Ethernet header containing the local MAC address as the SMAC.

In this doc, the HTTP Proxy is regarded as the non- transparent SF. So the methods for transparent SF is not applicable.

>Section 3.1.2. VLAN

*This could be problematic in a virtualized environment where the connection from the SFI to the SFE may not be a direct physical connection.   An SDN-based network typically owns the VLAN ID allocations and interpretation.

This method is applicable for transparent SF, meanwhile, the connection between the SFI and SFE is in a L2 network.

This method is applicable for transparent SF, meanwhile, the connection between the SFI and SFE is in a L2 network.

For non-transparent SF, two methods are introduced in the doc, one is using 5-tuple (application condition: 5-tuple of the original packet will not be modified by the legacy SF). The other is using control plane, i.e. the control plane provides the mapping rules. Please see the table for details. It would be difficult per packet level, but for per flow level, its complexity is similar as NAT hot standby.

                     Table 1: Operation Consideration

+-----------+--------+-----------------+-------------+-------------------+
|           |Methods |Ingress Flow     |Egress Flow  |Application        |
|           |        |Mapping          |Mapping      |Condition          |
+-----------+--------+-----------------+-------------+-------------------+
|           |MAC     |1.5-tuple->Source|Source MAC   |L2 header won't    |
|For Trans- |Address |MAC address      |address->SFC |be modified by     |
|parent SF  |        |2.Any SFC        |header       |the SFI.           |
|           |        |packet->Source   |             |                   |
|           |        |MAC address      |             |                   |
|           +--------+-----------------+-------------+-------------------+
|           |VLAN    |5-tuple->VLAN ID |VLAN ID->SFC |L2 header won't    |
|           |        |                 |header       |be modified by     |
|           |        |                 |             |the SFI.           |
|           +--------+-----------------+-------------+-------------------+
|           |QinQ    |5-tuple->Outer   |Outer VLAN   |The SFI is required|
|           |        |VLAN ID          |ID->SFC      |to support QinQ.   |
|           |        |                 |header       |L2 header won't    |
|           |        |                 |             |be modified by     |
|           |        |                 |             |the SFI.           |
|           +--------+-----------------+-------------+-------------------+
|           |VXLAN   |5-tuple->VNI     |VNI->SFC     |The SFI is required|
|           |        |                 |header       |to support VXLAN.  |
|           |        |                 |             |L2 header won't    |
|           |        |                 |             |be modified by     |
|           |        |                 |             |the SFI.           |
+-----------+--------+-----------------+-------------+-------------------+
|           |5-tuple |5-tuple          |5-tuple      |The 5-tuple of the |
|For        |Mapping |->5-tuple        |->SFC header |original packet    |
|Non-trans- |        |                 |             |won't be modified  |
|parent SF  |        |                 |             |by the SFI.        |
|           +--------+-----------------+-------------+-------------------+
|           |Control |e.g. 5-tuple     |e.g. 5-tuple'|The SFE must be    |
|           |Plane   |->5-tuple'       |->SFC header |configured or be   |
|           |        |                 |             |able to obtain the |
|           |        |                 |             |mapping rules of   |
|           |        |                 |             |the SFI. The SFI   |
|           |        |                 |             |only changes the   |
|           |        |                 |             |5-tuple according  |
|           |        |                 |             |to the 5-tuple     |
|           |        |                 |             |mapping rules.     |
+-----------+--------+-----------------+-------------+-------------------+

Best Regards!

-Haibin

> -----Original Message-----

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

> Sent: Thursday, April 17, 2014 9:48 AM

> To: Ron Parker; [email-masked]

> Subject: [sfc] 答复: comments on draft-song-sfc-legacy-sf-mapping-00

> > worthwhile issue to tackle, but do have some concerns in the current revision

> of

> > * Suggest enhancing your definition of Transparent SF to also state that it

> does

> > transparent HTTP Proxies are not source-ip transparent for some or all

> > of their upstream connections, instead using their own loopback or

> > interface IP addresses.

> I agree that no injection of additional flows should be another requirement for

> transparent SF. However, I think the transparent legacy SF which is applicable

> for service chain should at least meet the following requirement: no change to

> the 5-tuple of the original packet. Otherwise, it would be very hard or even

> impossible for the SFF to do the mapping without the assistance from the SF

> (e.g., provide the mappings created on the SF to the SFF). Given the above

> requirement has been met, why not directly use the 5-tuple for the mapping

> purpose?

> > * Legacy service functions that operate above layer 3 would typically not be

> able

> > to preserve the original SMAC.   Take for example the HTTP Proxy, again.

> A

> > encapsulated with an Ethernet header containing the local MAC address

> > as the SMAC.

> > * This could be problematic in a virtualized environment where the

> connection

> > SDN-based network typically owns the VLAN ID allocations and

> interpretation.

> > * Use of control plane signaling at a packet or flow level would be

> > difficult to scale.

---

From: Ron Parker <[email-masked]>
Date: Mon, 21 Apr 2014 12:43:39 +0000

Please see inline, below.

   Ron

From: Songhaibin (A) [mailto:[email-masked]]
Sent: Sunday, April 20, 2014 11:06 PM
To: Xuxiaohu; Ron Parker; [email-masked]
Subject: RE: comments on draft-song-sfc-legacy-sf-mapping-00

Hi Ron and Xiaohu,

Ron>> editorial comment, only – change “neither inject” to “nor shall it inject”

Ron>> That L2 connection between SFI and SFE may be emulated via SDN.   In this case, that would need to be a VLAN-transparent E-Line.

Best Regards!

-Haibin

> To: Ron Parker; [email-masked]<mailto:[email-masked]>

> > 收件人: [email-masked]<mailto:[email-masked]>

> > [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

---

From: "Songhaibin (A)" <[email-masked]>
Date: Tue, 22 Apr 2014 05:51:57 +0000

Hi Ron,

From: Ron Parker [mailto:[email-masked]]
Sent: Monday, April 21, 2014 8:44 PM
To: Songhaibin (A); Xuxiaohu; [email-masked]
Subject: RE: comments on draft-song-sfc-legacy-sf-mapping-00

   Ron

From: Songhaibin (A) [mailto:[email-masked]]
Sent: Sunday, April 20, 2014 11:06 PM
To: Xuxiaohu; Ron Parker; [email-masked]<mailto:[email-masked]>
Subject: RE: comments on draft-song-sfc-legacy-sf-mapping-00

Hi Ron and Xiaohu,

[Haibin] Yes. I agree.  Actually the assumption is that the line between SFI and SFE does not change any bit of the packet on layer 2 or the above. In this case, we can use the VLAN field or some other fields for the mapping and retrieval of the SFC header.

BR,

-Haibin

Best Regards!

-Haibin