V4 via V6 and IGP routing protocols

Mon Apr 4 13:05:09 UTC 2022

Pascal Thubert (pthubert) wrote:

> Hello Ohta-san

Hi,

>> it is hopeless.
> 
> If you look at it, LS - as OSPF and ISIS use it - 

My team developed our own.

	Hierarchical QoS Link Information Protocol (HQLIP)
	https://datatracker.ietf.org/doc/draft-ohta-ric-hqlip/

which support 256 levels of hierarchy with hierarchical
thinning of link information, including available QoS.

> depends on the
> fact that all nodes get the same information and react the same way.
> Isn't that hopeless too?

If you insist on OSPF or ISIS, yes.

> Clearly, the above limits LS applicability to stable links and
> topologies, and powered devices. This is discussed at length in
> https://datatracker.ietf.org/doc/html/draft-ietf-roll-protocols-survey.
> OLSRv2 pushes the model to its limit, don't drive it any faster.

You don't have to say "low power" to notice OSPF not so good.

With just a quick look at OSPF, I noticed OSPF effectively
using link local reliable multicast hopeless (as a basis
to construct hierarchical QoS routing system).

Worse, minimum hello interval of OSPF is too long for quick
recovery (low power is not required, for example, at backbone),
which is why additional complication to have an optical
layer were considered useful.

> RIFT (https://datatracker.ietf.org/doc/draft-ietf-rift-rift/) shows
> that evolution outside that box is possible.
OK. RIFT is "for Clos and fat-tree network topologies" of data
centers.

 > RIFT develops
 > anisotropic routing concepts (arguably from RPL) and couples DV and
 > LS to get the best of both worlds.

It usually results in the worst of both, I'm afraid.

> But none of the above allow an source router to decide once and for
> all what it will get.

As there are not so many alternative routes with Clos and
fat-tree network topologies of data centers, pure source
routing combined with some transport protocol to
simultaneously try multiple routes should be the best
solution, IMO, because avoiding link saturation is an
important goal.

> When you drive and the street is blocked, you can U-turn around the
> block and rapidly restore the shortest path. The protocols above will
> not do that; this is why technologies such as LFA were needed on top.
> But then the redundancy is an add-on as opposed to a native feature
> of the protocol.

What if network is not very large and minimum hello interval of
OSPF is 1ms?

> Thinking outside that box would then mean: - To your end-to-end
> principle point, let the source decide the packet treatment
> (including path) based on packet needs

To apply the E2E argument for LS routing, all the routers
are *dumb* intermediate systems to quickly flood LS. At
the same time, all the routers are ends to initiate
flooding of local LS, to receive flooded LS and to
compute the best route to destinations in a way
consistent with other routers because they share same
flooded LS except during short transition periods.

					Masataka Ohta