Suggestion on nsh_entry and nsh_mapping
When I test the nsh node, I found that some code could be improved.
For encap-none case, there is no need to look up nsh_mappings table. So I suggest moving encap-none to nsh_entry.
In nsh_entry, it could add “encap-none | nsh-map | nsh-proxy”:
(1). For encap-none case, just decap nsh header, and then move to next-protocol’s nodes, i.e. ipv4, ipv6.
(2).For nsh-map case, look up nsh-mapping table, and do vxlan-gpe or gre encap etc.
(3).For nsh-proxy case, send to nsh-proxy node for further process.
Keith Burns <alagalah@...>
toggle quoted message Show quoted text
Sorry for the top post but probably warranted here.
I was trying to separate the NSH header (nsh-entry) from it's use-case (nsh-map).
That way NSH is just a resource that could potentially be used for entirely different use-cases.
I'd need to think on it though but certainly open to alternate ways of doing things.
I do need at some point to refactor the existing patch for it to work correctly, due to the incorrect way I wired things together (see VPP patch today).
The good news is the way Dave B helped me re-wire it (which is something we have indeed done before, I had just forgotten <facepalm> ) it makes vxlan-gpe far more extensible and I would hope make it easier for the NSH plugin to integrate with other encaps too.
What do others think? I'd like to get something rolling, code-wise in the repo :)
On Mon, May 16, 2016 at 8:05 PM Ni, Hongjun <hongjun.ni@...> wrote:
|1 - 2 of 2|