[vpp-dev] Moving NSH from VPP to NSH_SFC

Keith Burns <alagalah@...>

No worries.

Since initially these are all VPP repo changes who from the VPP committer list can be my shepherd?

Ie who can I hassle for a timely review so I have at least one person familiar with the train of patches ?

On Wed, May 4, 2016, 6:08 AM Dave Barach <dave@...> wrote:

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




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:




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.




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





- 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.





- 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