lkml.org 
[lkml]   [2020]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [net-next,v2,4/5] seg6: add support for the SRv6 End.DT4 behavior
From
Date
Il 2020-11-13 20:40, Jakub Kicinski ha scritto:
> On Fri, 13 Nov 2020 10:04:44 -0700 David Ahern wrote:
>> On 11/13/20 10:02 AM, Stefano Salsano wrote:
>>> Il 2020-11-13 17:55, Jakub Kicinski ha scritto:
>>>> On Thu, 12 Nov 2020 18:49:17 -0700 David Ahern wrote:
>>>>> On 11/12/20 6:28 PM, Andrea Mayer wrote:
>>>>>> The implementation of SRv6 End.DT4 differs from the the
>>>>>> implementation of SRv6
>>>>>> End.DT6 due to the different *route input* lookup functions. For
>>>>>> IPv6 is it
>>>>>> possible to force the routing lookup specifying a routing table
>>>>>> through the
>>>>>> ip6_pol_route() function (as it is done in the
>>>>>> seg6_lookup_any_nexthop()).
>>>>>
>>>>> It is unfortunate that the IPv6 variant got in without the VRF piece.
>>>>
>>>> Should we make it a requirement for this series to also extend the v6
>>>> version to support the preferred VRF-based operation? Given VRF is
>>>> better and we require v4 features to be implemented for v6?
>>>
>>> I think it is better to separate the two aspects... adding a missing
>>> feature in IPv4 datapath should not depend on improving the quality of
>>> the implementation of the IPv6 datapath :-)
>>>
>>> I think that Andrea is willing to work on improving the IPv6
>>> implementation, but this should be considered after this patchset...
>>
>> agreed. The v6 variant has existed for a while. The v4 version is
>> independent.
>
> Okay, I'm not sure what's the right call so I asked DaveM.
>
> TBH I wasn't expecting this reaction, we're talking about a 200 LoC
> patch which would probably be 90% reused for v6...
>

Jakub, we've considered the possibility to extend the v6 version to
support the preferred VRF-based operation as you suggested

at first glance, it would break the uAPI compatibility with existing
scripts that use SRv6 DT6, currently we configure the decap operation in
this way

ip -6 route add 2001:db8::1/128 encap seg6local action End.DT6 table 100
dev eth0

if the v6 version is extended to support the VRF-based operation, in
order to configure the decap operation we have to do (like we do in the
v4 version)

ip link add vrf0 type vrf table 100
sysctl -w net.vrf.strict_mode=1
ip -6 route add 2001:db8::1/128 encap seg6local action End.DT6 table 100
dev eth0

(of course the sysctl is needed globally once... while the "ip link
add..." command is needed once for every table X that is used in a script)

considering how much we care of not breaking existing functionality...
it is not clear IMO if we should go into this direction or we should
think twice... and maybe look for another design to introduce VRFs into v6

so I would prefer finalizing the DT4 patchset and then start discussing
the VRF support in v6 version

--
*******************************************************************
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail : stefano.salsano@uniroma2.it
Cell. : +39 320 4307310
Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
*******************************************************************

\
 
 \ /
  Last update: 2020-11-13 22:35    [W:0.073 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site