On Wed, 20 Jan 2016, jafar wrote:
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.
So, a VRF to me means a distinct and independent addressing and routing
context. A view or multi-instance share the same addressing/routing
context, but are distinct instances of the protocol.
VRF 1:m view/instance
Some routing protocols have further divisions internally, e.g. OSPF can
have multiple link-state domains, with distance-vector routing between
them, via areas.
Does VRF correspond to an "independent routing domain"/ a container?
To me, yes.
OR is that what name-space means now? Or they both valid definition
with one of them being an an encapsulation within the other?
A name-space is how Linux implements independent networking contexts. ?
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.
For me, it's separate instances of the same routing _protocol_. It could
be within the same daemon, or not. E.g. bgpd has internal support for
'views' (with some quirks), but you can also run multiple bgpds on
different IPs or ports (latter might be trickier). With internal views
we lack a way to 'peer' between the instances, be nice to add that (be a
bit like the 'pipes' in BIRD I guesS). In both ways you can not send
routes to zebra, which is a limitation.
ospfd inherently supports sub-division via areas, as mentioned, and so
can still reconcile them and update zebra.
OSPF Multi-Instance would be more like the views of BGP, and presumably
also couldn't update zebra. We probably need some kind of instance ID in
Zserv.
OSPF multi-topology runs in one instance of OSPF, right? But then
calculates independenent routing tables? So that'd be a strange case
right? So the protocol would run in one IP context, but calculate
independent routing tables? How will that fit in?
Do we need to refine the notion of VRF further, between addressing
contexts and routing contexts?
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.
Is the distinction not more about address spaces and routing contexts?
OSPF MT requires one cohesive addressing context across the network, but
then can calculate distinct routing contexts for the same underlying
topology?
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.
Indeed, interesting one.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
To any truly impartial person, it would be obvious that I am always right.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
