Wiki link for proposed decoupling of VPP and NSH_SFC
|
Keith Burns <alagalah@...>
https://wiki.fd.io/view/NSH_SFC/Docs/Designs (note that the actual header isn't ToC'ing yet, so link is in the above) |
|
|
|
Zhou, Danny
Nice initial work Keith.
A few questions: 1) It looks to me this design only covers the SFF behavior, and I’d would extend it to support classifier (doing NSH encap followed by transport encap), NSH proxy (doing NSH to local circuit bi-directional conversion) and NSH-aware SF (doing NSH decap followed by encap and decrement SI) behaviors if possible. Can a plugin include multiple graph nodes? I am thinking about using a single plugin to support different use cases or one plugin per use case, obviously former one would make control logic much more complicated than the one in your diagram. 2) Can you share a editable version somewhere so we can directly update it?
From: nsh_sfc-dev-bounces@... [mailto:nsh_sfc-dev-bounces@...]
On Behalf Of Keith Burns
Sent: Monday, April 25, 2016 10:45 PM To: nsh_sfc-dev@... Subject: [nsh_sfc-dev] Wiki link for proposed decoupling of VPP and NSH_SFC
https://wiki.fd.io/view/NSH_SFC/Docs/Designs
(note that the actual header isn't ToC'ing yet, so link is in the above) |
|
|
|
Keith Burns <alagalah@...>
On Mon, Apr 25, 2016 at 8:18 AM Zhou, Danny <danny.zhou@...> wrote:
Its just finishing the work I started, not presuming a final design of all features, use-cases etc. The initial work was a very trivial SFF implementation (pass packets so that stuff goes in and out right) and I have done a rudimentary instantiation (classifier) PoC that is still in draft, mainly because it required work that may have impacted existing use-cases (but that's now sorted) and because it would have bypassed RPF checks (which is bad). I had no intention of attempting or presuming an NSH proxy implementation. Theres an important point also driving this. VPP F0 is this Friday. Its a target date to get big things done, but I've been told that NSH removal isn't a "scary change" but still, in keeping with the spirit of the VPP 16.06 release plan, I'd like for the vpp repo to reflect what we expect to go out the door before F0 as much as possible from an NSH standpoint. Also it would be nice to get this into our own repo so you can have at things like, nsh proxy, and any other SF use case features you need (especially instrumentation, very excited by the work your team is doing there).
I can't see any reason why a single plugin couldn't contain multiple graph nodes. See vnet/vnet/sr/sr.c grep: VLIB_REGISTER_NODE .. that register 3 graph nodes. That's an implementation detail we as a project have to decide upon. At a NSHSFC repo level we can have a make file that builds multiple plugins, each with 1..n graph nodes (like sr.c) or we can have an uber-plugin that contains 1...n graph nodes. I may express a preference when the time comes, but for now its moot. I'm simply trying to get stuff "finished" and moved over without fully complete
Sure. Please request access. I'd rather it not be "fully editable" as then anyone can come in and graffiti it (which is more a nuisance than anything else). Happy to share edit rights with folks like yourself who have a genuine interest in working on the project.
|
|
|
|
Zhou, Danny
The ideas about decoupling VPP and NSH_SFC and decoupling VxLAN-GPE and NSH in the design makes perfect sense to me as it adds a lot more flexibility (allows us to add more NSH relevant features easily) than the existing tunneling port type of implementation in VPP.
Looking forward to the our own NSH SFC repo. In the meantime, will do design work based on initial diagram to cover more use cases mentioned below.
From: Keith Burns [mailto:alagalah@...]
Sent: Tuesday, April 26, 2016 12:02 AM To: Zhou, Danny <danny.zhou@...>; nsh_sfc-dev@... Subject: Re: [nsh_sfc-dev] Wiki link for proposed decoupling of VPP and NSH_SFC
On Mon, Apr 25, 2016 at 8:18 AM Zhou, Danny <danny.zhou@...> wrote:
The initial work was a very trivial SFF implementation (pass packets so that stuff goes in and out right) and I have done a rudimentary instantiation (classifier) PoC that is still in draft, mainly because it required work that may have impacted existing use-cases (but that's now sorted) and because it would have bypassed RPF checks (which is bad).
I had no intention of attempting or presuming an NSH proxy implementation.
Theres an important point also driving this. VPP F0 is this Friday. Its a target date to get big things done, but I've been told that NSH removal isn't a "scary change" but still, in keeping with the spirit of the VPP 16.06 release plan, I'd like for the vpp repo to reflect what we expect to go out the door before F0 as much as possible from an NSH standpoint. Also it would be nice to get this into our own repo so you can have at things like, nsh proxy, and any other SF use case features you need (especially instrumentation, very excited by the work your team is doing there).
I can't see any reason why a single plugin couldn't contain multiple graph nodes. See vnet/vnet/sr/sr.c grep: VLIB_REGISTER_NODE .. that register 3 graph nodes.
That's an implementation detail we as a project have to decide upon. At a NSHSFC repo level we can have a make file that builds multiple plugins, each with 1..n graph nodes (like sr.c) or we can have an uber-plugin that contains 1...n graph nodes. I may express a preference when the time comes, but for now its moot. I'm simply trying to get stuff "finished" and moved over without fully complete
Sure. Please request access. I'd rather it not be "fully editable" as then anyone can come in and graffiti it (which is more a nuisance than anything else). Happy to share edit rights with folks like yourself who have a genuine interest in working on the project.
|
|
|
|
Keith Burns <alagalah@...>
On Mon, Apr 25, 2016 at 5:32 PM Zhou, Danny <danny.zhou@...> wrote:
Hongjun has been really helpful digging in, finding issues and fixing things. See how my energy levels go, but once I get something REALLY rough perhaps I can do a webex with you guys at a more China friendly time to walk through and perhaps divide and conquer? (I'm more an early AM person, and after 6pm with the family then bed time evenings are tough - so no promises if I don't have the energy :)) |
|
|
|
Zhou, Danny
Sure, we can discuss some of performance related topic as well in the to-be-scheduled WebEx meeting. 4pm PST is good for us.
From: Keith Burns [mailto:alagalah@...]
Sent: Tuesday, April 26, 2016 8:51 PM To: Zhou, Danny <danny.zhou@...>; nsh_sfc-dev@... Subject: Re: [nsh_sfc-dev] Wiki link for proposed decoupling of VPP and NSH_SFC
On Mon, Apr 25, 2016 at 5:32 PM Zhou, Danny <danny.zhou@...> wrote:
Hongjun has been really helpful digging in, finding issues and fixing things. See how my energy levels go, but once I get something REALLY rough perhaps I can do a webex with you guys at a more China friendly time to walk through and perhaps divide and conquer? (I'm more an early AM person, and after 6pm with the family then bed time evenings are tough - so no promises if I don't have the energy :))
|
|
|