[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJmoNQHFxgfEqgZUWFdR_WzemBqGctWgKUez2H9956M0pLLaUg@mail.gmail.com>
Date: Mon, 6 Jul 2015 10:53:33 -0700
From: Shrijeet Mukherjee <shm@...ulusnetworks.com>
To: Nicolas Dichtel <nicolas.dichtel@...nd.com>
Cc: David Ahern <dsa@...ulusnetworks.com>,
Netdev <netdev@...r.kernel.org>,
Roopa Prabhu <roopa@...ulusnetworks.com>,
Andy Gospodarek <gospo@...ulusnetworks.com>,
Jon Toppins <jtoppins@...ulusnetworks.com>,
Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
Dinesh Dutt <ddutt@...ulusnetworks.com>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
Stephen Hemminger <stephen@...workplumber.org>,
Jamal Hadi Salim <hadi@...atatu.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
David Miller <davem@...emloft.net>
Subject: Re: [RFC net-next 0/6] Proposal for VRF-lite - v2
No no problem,
Just trying to get the functional aspects worked out. the global
search replace will be easy.
Was hoping to see some more responses on the naming suggestions here
from the community. If there is not disagreement we can spin patches
with MRF as the name.
On Mon, Jul 6, 2015 at 8:40 AM, Nicolas Dichtel
<nicolas.dichtel@...nd.com> wrote:
> Le 06/07/2015 17:03, David Ahern a écrit :
>>
>> In the context of internet scale routing a requirement that always
>> comes up is the need to partition the available routing tables into
>> disjoint routing planes. A specific use case is the multi-tenancy
>> problem where each tenant has their own unique routing tables and in
>> the very least need different default gateways.
>>
>> This is an attempt to build the ability to create virtual router
>> domains aka VRF's (VRF-lite to be specific) in the linux packet
>> forwarding stack. The main observation is that through the use of
>> rules and socket binding to interfaces, all the facilities that we
>> need are already present in the infrastructure. What is missing is a
>> handle that identifies a routing domain and can be used to gather
>> applicable rules/tables and uniqify neighbor selection. The scheme
>> used needs to preserves the notions of ECMP, and general routing
>> principles.
>
> [snip]
>>
>> drivers/net/vrf.c | 486
>> ++++++++++++++++++++++++++++++++++++++++++
>
> [snip]
>
> I'm still opposed to name this 'vrf', see the v1 thread:
> - http://www.spinics.net/lists/netdev/msg332357.html
> - http://www.spinics.net/lists/netdev/msg332376.html
>
> Shrijeet seemed to agree to rename it, is there a problem?
>
>
> Regards,
> Nicolas
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists