Subject: [sfc] an NSH implementation

From: Ryo Nakamura <[email-masked]>
Date: Thu, 7 Jan 2016 15:32:25 +0900

Hi,

I'm Ryo Nakamura, PhD studnet at University of Tokyo.

I implemented Network Service Header (based on draft-ietf-sfc-nsh-0) as a single Linux Kernel Module.
This module provides Ethernet over NSH over VXLAN-GPE, Ethernet over NSH over Ethernet and a modified iproute2 package.
https://github.com/upa/nshkmod

In this implementation, a service path is abstracted as a virtual interface similar to Linux vxlan driver (a vxlan interface becomes an entry point to a vxlan virtual network). For example, "ip link add type nsh spi 10 si 5" creates virtual interface "nsh0" and transmitted packets to the interface are encapsulated in network service header with service path index 10 and service index 5.

SFF mapping table is implemented in kernel space, and can be configured by "ip nsh" command.

Any comments, feedback and pull requests are welcome.
I hope this will help you and standardization process.

Sincerely
Ryo Nakamura

--
[email-masked]

---

From: "Duarte Cardoso, Igor" <[email-masked]>
Date: Thu, 7 Jan 2016 11:54:43 +0000

Hi Ryo,

I am not involved in the standardization process but your project looks very interesting and I will definitely play with it a bit. 

Best regards,
Igor.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ryo Nakamura
Sent: Thursday, January 7, 2016 6:32 AM
To: [email-masked]
Subject: [sfc] an NSH implementation

Hi,

Sincerely
Ryo Nakamura

--
[email-masked]

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Jan 2016 09:58:22 -0500

Thank you for doing this work, and for letting us know about it.

Were there any issues you noticed while implementing this.  Or, equally 
important, were there any areas where you found the draft unclear?

Yours,
Joel

---

From: Ryo Nakamura <[email-masked]>
Date: Fri, 8 Jan 2016 01:39:44 +0900

> Were there any issues you noticed while implementing this. 

Outer UDP source port selection on VXLAN-GPE (UDP) encapsulation.
The UDP source port number is used for ECMP/load-balancing, so that it is recommended that this has entropy.

RFC7348 Sec 5 says, “it is recommended that the UDP source port number be calculated using a hash of fields from the inner packet”. But, in NSH, do the fields mean network service header? or inner Ethernet or IP header and so on.

In this implementation, the UDP source port number is calculated using a hash of inner Ethernet header like Linux VXLAN driver. It will have high entropy, however, it may cause packet reordering on a single service path.
Should we use only SPI and SI? or some fields from inner packets?

This is a little thing I noticed while implementing.

Sincerely,
Ryo Nakamura

On Jan 7, 2016, at 23:58, Joel M. Halpern <[email-masked]> wrote:

> Were there any issues you noticed while implementing this.  Or, equally important, were there any areas where you found the draft unclear?
> 
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Jan 2016 11:54:59 -0500

An important implementation point.

My personal take is that it is perfectly acceptable if the underlying 
transport re-orders packets across different flows, as long as order 
within flows is preserved.  Thus, what you implemented seems a good choice.

part of the reason for this view is that service functions may well 
reorder packets from different flows anyway, particularly if it turns 
out the different flows need different amounts of service / processing.

Yours,
Joel

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 7 Jan 2016 11:33:11 -0600

> The UDP source port number is used for ECMP/load-balancing, so that it is recommended that this has entropy.

Ryo, I think you are talking about VXLAN encapsulation (see your RFC
reference below and Linux implementation). VXLAN-GPE is something
else.

Regards,

Behcet