[Xorp-hackers] XORP and Multi-Topology (MT) Routing in OSPF

[Atanu Ghosh]

Hi,

Multi-Topology (MT) Routing in OSPF is not something that we have been
looking at.

According to the draft the association of a topology with an incoming
packet is outside its scope. It seems the first thing that you would
need to do is to find an operating system that supports multiple
forwarding tables based on the DSCP in the IP header or some other
feature, then the FEA would need to be taught how to install such an MT
route.

Apart from the FEA for all the other XORP processes the MT identifier
can be opaque. New route add, delete and replace XRLs will need to carry
this extra MT identifier, a value such as zero could be choosen for the
default topology.

The RIB already supports multiple tables, a routing protocol on startup
creates one or more tables in the RIB to which it will add routes. The
MT identifier could be added as part of the creation process. The RIB
can then use the MT identifier when a route is sent to the FEA.

If I was adding this feature to OSPF I would be inclined to make it a
configuration option to ospf4. As far as I can tell from a quick reading
of the draft the protocol hasn't really changed much. The majority of
the changes are in the MT routing table computations. At the moment
there is one routing table per area it shouldn't be too complicated to
make multiple routing table instances; it's already a separate class.

By design no changes will be required to POLICY or the CLI, all the
changes will be in the template files.

The show commands that operate on the RIB to show routing tables will
need to be enhanced to support a MT identifier argument.

     Atanu.

>>>>> "Jon" == Jon Andersson <jonirucoeith at gmail.com> writes:

    Jon> Hi, Are there any plans to support this in XORP?

    Jon> I have been looking into the possibillity of doing an
    Jon> implementation of Multi-Topology (MT) Routing in OSPF
    Jon> (draft-ietf-ospf-mt-08.txt) with XORP as the framework.

    Jon> I would like some feedback on a few design issues, mostly
    Jon> related to roadmap and overall philosophy:

    Jon> a) Should the design aim for a separate protocol (making it
    Jon> ospf4, ospf6, ospf4mt...) or configurable extensions to
    Jon> existing implementations?

    Jon> b) After a look at the XORP architecture, I have (so far)
    Jon> identified changes (apart from ospf) in RIB, CLI(!) and POLICY.

    Jon> c) My impression is theat changes to FEA might depend on chosen
    Jon> implementation. Other changes I would need to make?


    Jon> Cheers,

    Jon> Jon

    Jon> _______________________________________________ Xorp-hackers
    Jon> mailing list Xorp-hackers at icir.org
    Jon> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers