Hi,
A while back we went into a discussion about VRFs, 6WIND's VRF
contribution which what we have in the code now, names spaces and kernel
routing tables. The terminology was not exactly well defined and at
least to me it is still vague. I can tell you what I think they should
mean but I am not sure if we all agree about that or how do they relate
to each other. It is ok to have different meaning in different context,
but in quagga's context they should be well defined. Now we also have
VRF-device, views, multiple-instances, and maybe soon we will have
multi-topology.
Does VRF correspond to an "independent routing domain"/ a container?
OR is that what name-space means now?
Or they both valid definition with one of them being an an
encapsulation within the other?
Multi-instance, does it mean multi-daemon (one instance per daemon) or
multiple instances within a daemon? One routing instance can also be run
in multiple daemons.
6WINd's Nicolas Dichtel tried to clear some of the confusion and avoided
controversy and went ahead and submitted a patch that has not been
applied yet renaming vrf_id (VRF) to ltid (logical table). The move was
made to better map to what was actually implemented. When you create a
vrf, it maps to one kernel routing table in one name space.
I'm bringing this up because I'm also trying to see how Multi-topology
for OSPF would fit into the picture or what it should map to.
Regards,
Jafar
On 2016-01-20 16:16, Vipin Kumar wrote:
Hi Paul,
Thanks for taking a look at the write-up, please see my comments
inline..
On Tue, Jan 19, 2016 at 2:31 AM, Paul Jakma <[email protected]> wrote:
On Mon, 18 Jan 2016, Vipin Kumar wrote:
Hi Vincent,
Here is a brief write-up about how we can (and some of it we have
already
done) make name-space and vrf-device based vrfs co-exist.
In the kernel, hierarchically, vrf-devices are well within a
name-space.
We can keep the same in quagga. In fact, its looking quite
feasible to
leverage both to take the effective vrf scale further.
I am attaching it as a text-file for a better view of the ansii
art.
Might have been better to just include it directly. Very difficult
to
reply to attachments. ASCII art should come over just fine in email,
and
if not, get a better MUA.
Here's the thing. I very much think Quagga needs to become more
'componentised'. I think this is required for scalability and
isolation and will be important for the future of Quagga.
CPUs are not getting faster anymore. Transistor counts however are
still increasing, so cores/die and RAM are increasing. Any
development path that seeks to optimise for a resource that is still
growing and plentiful, at the cost of requiring more of a resources
that is not growing (and that we already ask too much of in some
cases) while ignoring one important area where resources are
growing, is a path that is detrimental to the future of Quagga.
Thanks for attaching the contents inline.
Given that.
How it is with 6wind vrf lib patch —
Configuration:
vrf <vrf-id> ns-name <path>
Main data-structures:
Global vrf_table which holds vrfs in a tree indexed by vrf-id.
Interface list is moved inside VRFs.
vrf_init() creates a default vrf.
+----------------------+
| struct vrf { |
| |
| vrf_id_t vrf_id;|
| char *name; |
| |
| void *info; +---------+
| } | |
+----------------------+ |
| (in case of zebra)
+---+----------------+
| struct zebra_vrf { |
| /*tables etc. *|
| |
| } |
+--------------------+
Here is how name-space based model is filling well after
integration with vrf-devices
Configuration:
name-space <ns-id> ns-name <path> // proposing renaming of the
previous vrf command.
vrf <name> // the new config mode
As for the reflection of hierarchies in the running config, we
have two possibilities:
1. Continue with the approach we took with interface and
vrf, where a vrf is shown in the interface command. Do the same
with the vrf command and show name-space next to the vrfs it owns.
name-space ID name NSNAME
vrf VRFNAME name-space NSNAME
interface IFNAME vrf VRFNAME
2. Implement name-space config mode which contains VRFs and
interfaces within it.
We believe (1) is sufficient.
Main data-structures:
Global ns_table which holds NSs in a tree indexed by ns-id.
vrf_table is moved inside name-space structure.
ns/vrf_init() create default ns/vrf.
+-------------------------+
|struct zebra_ns { |
| ns_id_t nsid; |
| |
| /* vrf_table etc. */ |
| +----+
|} | | +--------------+
+-------------------------+ +——>+struct vrf { |
| | |
+--------------------+
| |} +> |struct
zebra_vrf { |
| +--------------+ |
|
| |}
|
| |
|
|
+--------------------+
|
+-->
|
|
+
I think the VRF creation needs to be a separate daemon, and probably
has to handle at least some interface mgt too. It probably also
needs to manage the child processes.
That is, I think, required to have a RIB process per VRF/namespace.
It is much easier to design this as completely separate processes I
think, and let others merge them into one if they wish, than the
other way around.
I would like to see a vrfd that handles vrf creation. Potentially we
need something to also launch and manage RIBs and routing instances
as children in the right VRFs (maybe an extension of watchquagga).
Whether those two things should be in the same daemon or not I'm not
100% sure, probaly they do.
Sure. I dont deny the value of carving out logically/functionally
separate components and introducing some new daemons running with
those functionalities. However, I think that can be done incrementally
as a separate project (after this) as well.
The nature of the changes through which we are doing VRF device
integration and BGP VRF is really building upon the existing
code-flows/components. e.g.
- BGP VRF is based on existing BGP views
- VRF devices are read just like interface links are read
- VRF config is coded just how interface config is.
- Rest of the flow of information, based on vrf-id etc in zapi is
same as its in the previously integrated VRF lib.
To highlight that point, I am attaching some of current patches (which
work for default name-space only for now)
Please note these are not quite consumable set of patches yet(you can
see bunch of Pending items), we will submit those later after handling
more corner cases and UT/IT.
Donald and I will keep quagga-dev posted as we progress more on the
code for netns + vrf device together.
I assume, overall, introducing a new name-space specific structure is
fine to move forward.
Regards,
Vipin
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
We ran out of dial tone and we're and waiting for the phone company
to deliver another bottle.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
