[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <83b0fb79-c349-4e64-8d5a-72e913670002.mao-linux@maojianwei.com>
Date: Thu, 23 Apr 2020 20:12:50 +0800
From: "Jianwei Mao (Mao)" <mao-linux@...jianwei.com>
To: "Dave Taht" <dave.taht@...il.com>
Cc: "netdev" <netdev@...r.kernel.org>, "davem" <davem@...emloft.net>,
"kuznet" <kuznet@....inr.ac.ru>,
"yoshfuji" <yoshfuji@...ux-ipv6.org>, "kuba" <kuba@...nel.org>,
"lkp" <lkp@...el.com>
Subject: Re: [PATCH net-next v2] net: ipv6: support Application-aware IPv6 Network (APN6)
Hi Dave,
Thanks for your attention :)
1. APN6 has no association with spring and oam, although other people can
design an APN6-driven SR, or APN6-driven OAM solution.
So we can promote this linux code work for APN6.
2. Yes, in high-level-design of APN6, we will finally build a whole
APN6 system/solution set up with linux servers, routers, switches, etc.
And we are also doing that thing, and linux kernel is surely one key step
to build that. Btw, if you have interests for that, you're welcome to enjoy
the APN6 demo in 2020 Interop ShowNet (it will be held online for this year).
3. In this patch, we have considered arbitrary injection problem
as you mentioned. And this patch just allows applications to config three
fields (SLA, AppId, and UserId), which are allocated by network operator
and application server, moreover, they will be verified by network devices
(router/bras/etc.).
In conclusion, in APN6, this patch makes linux act as end device,
so it will not affected by that problem and en-route mtu problem. :)
Thanks,
Mao
------------------------------------------------------------------
From:Dave Taht <dave.taht@...il.com>
Subject:Re: [PATCH net-next v2] net: ipv6: support Application-aware IPv6 Network (APN6)
as near as I can tell, this is not even an accepted working group item
in ietf 6man. (?). Normally I welcome running code long before rough
consensus, but in this case I would be inclined to wait. There also
seems to be some somewhat conflicting ideas in spring and oam that
need working out.
It would be good to have an example implementation that could actually
parse and "do smart things" with this additional header, e.g a tc
filter, ebpf, etc. It has the same flaws diffserv has always had in
that any application can set these fields arbitrarily, with the
additional flaw of changing the mtu if these headers are added or
modified en-route.
Powered by blists - more mailing lists