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.
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.
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
