Dear Keith,

 

Ack. Note that as soon as we pull the release throttle branch, it’s fair to merge big change-sets again in the master branch...

 

Thanks… Dave

 

From: vpp-dev-bounces@... [mailto:vpp-dev-bounces@...] On Behalf Of Keith Burns
Sent: Wednesday, May 4, 2016 8:50 AM
To: vpp-dev <vpp-dev@...>; nsh_sfc-dev@...
Subject: [vpp-dev] Moving NSH from VPP to NSH_SFC

 

Folks,

 

As I started moving stuff over on the weekend I realised I was ending up with two very large monolithic patches in two different repos (VPP and NSH_SFC). 

 

This seemed the wrong thing to do given we are in F0.

 

Instead I am taking the following approach:

 

-------------

WHAT I WILL DO:

1. Moved VPP-15 to be an Epic which has Tasks underneath it. Patches shouldn't be linked to VPP-15, they should have more granular Tasks so we can identify them in the git log more readily

 

2. Making an NSH folder in VPP. First task (VPP-39) is to simply start moving over NSH specific header files, definitions from NSH-GRE and NSH-VXLAN-GPE etc to maintain existing functionality but encapsulate NSH things in one place.

 

3. Move functionality so that anything that reads/writes NSH fields in the definitions above punts that to a new graph node in common with NSH-GRE and NSH-VXLAN-GPE

 

4. Rename NSH-VXLAN-GPE to be just VXLAN-GPE, and potentially remove NSH-GRE as it should be handled by the generic GRE case as a NEXT-PROTOCOL (EtherType essentially in GRE case).

 

5. Then we can move the NSH folder to be a plugin in the NSH_SFC repo.

 

-------------

WHAT I WON'T DO:

- Add GPE next protocol type MPLS (VPP-13). This is net new functionality. Not appropriate post-F0

 

-------------

 

WHAT I MIGHT DO:

- leverage the existing VPP ReWrite facilities (marked as a "??????" TODO in the nsh-vxlan-gpe code). It's entirely possible that this may be only applicable to the NSH portion of this, in which case it can be address in the NSH_SFC repo at a later date.

 

 ------------

 

IMPLICATIONS:

- The goal is to do this in bite size reviewable chunks in one repo until I have a unit I can splat down in nsh_sfc. If this cannot be completed by RC0, then any discussions of nsh_sfc doing a "release" of some sort and what version of VPP it aligns to get very sticky indeed. The best case is this just gets done so we have options (ie any nsh_sfc "release" will then be able to align with vpp 16.06 or master. I want to give the project the options. 

 

I feel confident I can get this done with the wind at my back/beam. Whilst its technically feasible to actually sail faster into a headwind, it is decidedly unpleasant :) which may indeed result in sub-par performance from the crew, resulting in loss of boat speed... ie if you want this done, and I think we should, then please be my tailwind, not my headwind :D