On Tue, 19 Jan 2016, Jafar Al-Gharaibeh wrote:
As a follow up to our discussion in the meeting earlier today regarding the
design of MTR. The comments and proposed changes from the previous effort
(see the link) still hold and make perfect sense :
https://lists.quagga.net/pipermail/quagga-dev/2009-July/006791.html
Many of the data structures are replicated per topology. Most of them
will be arrays of pointers instead of just one pointer.
Cool.
One thing to discuss was the interfaces around this. You were thinking
of publishing the routes for a topology against a 'table'? Can that
identifier just be a VRF ID, or does that need to be something else
again?
In addition to MT-OSPF, we also have MI-OSPF and VRF-OSPF. Both
MI-OSPF (Donald?) and VRF-OSPF (Vincent?) are efforts that have been
brought up but we have not yet seen proposed patches for them.
The MI OSPF patches exist. That approach should extend to arbitrary IDs.
The one issue is discriminating packets received, if more than instance
is configured to be active on the same interface:subnet. OSPFv3 has
instance IDs, v2 does not. I guess the answer is "don't do that", or is
there a better way?
All of these have to deal with the same issue, maintaining several
states in the same ospf daemon (ospfd). They all have to replicate
data structures to maintain the different states, if I understand VRF-
and MI- ospf correctly. MT-OSPF can be used with both of them. Each
VRF or instance can have one or more topologies. This whole
replication of data structures business needs to be coordinated and
well defined so down the road when the time comes to merge all three
it wont be a nightmare.
This is the kind of thing I was alluding to in my email the other day in
another thread on 'development scalability'.
We are heading for near deadlock dealing with conflicts if we keep all
trying to add awareness of features into the same bits of code, across
all the code base, instead of taking approaches that encapsulate
existing code and wrap new features around them with the minimum of
change.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
All the simple programs have been written.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
