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