Suggestion on nsh_entry and nsh_mapping
|
Ni, Hongjun
Hi Keith,
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.
Regards, Hongjun |
|
|
|
Keith Burns <alagalah@...>
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:
|
|
|