Multiple routing protocols for a single prefix

[cgundogan]

There is a lengthy discussion in #3721 that the use of multiple routing protocols for the same net prefix will result in undesireable behaviours if they all operate on a shared FIB.

[cgundogan]

@tcschmidt

This should be no issue as long as one prefix/host is under the control
of a single routing protocol, as discussed at length in spring (?) '15.
@waehlish asked for use cases otherwise - I don't see any in the IoT ??

@tcschmidt @waehlisch P2P-RPL is in general a very short-lived routing protocol and is not running continuously like other routing protocols would do. Use cases exist where P2P-RPL would find a shorter path than a concurrently running vanilla RPL, because it does not rely on the previously built DAG structure (see [1]). It is possible to use a different net prefix for that one route that P2P-RPL finds, but I am not sure whether we want to use X different prefixes for X different (short-lived) P2P-RPL invocations. Having multiple net prefixes increases memory usage (more ipv6 addresses assigned to the interface) and would also require to adapt the application layer .. it's easier and more transparent to send user traffic to one prefix/host within the same network.

I also agree that multiple routing protocols should use separate net prefixes, but I also think that RPL+P2P-RPL concurrently might form an exception, where it may make more sense to use the same prefix.

[1] https://tools.ietf.org/html/rfc7733#appendix-A

[cgundogan]

I also agree that multiple routing protocols should use separate net prefixes, but I also think that RPL+P2P-RPL concurrently might form an exception, where it may make more sense to use the same prefix.

And this is the part where a prioritization of both protocols is imperative. Otherwise, RPL would keep overriding routes that were found by short-lived P2P-RPL invocations.

[tcschmidt]

@tcschmidt @waehlisch P2P-RPL is in general a very short-lived routing protocol and is not running continuously like other routing protocols would do. Use cases exist where P2P-RPL would find a shorter path than a concurrently running vanilla RPL, because it does not rely on the previously built DAG structure (see [1]). It is possible to use a different net prefix for that one route that P2P-RPL finds, but I am not sure whether we want to use X different prefixes for X different (short-lived) P2P-RPL invocations. Having multiple net prefixes increases memory usage (more ipv6 addresses assigned to the interface) and would also require to adapt the application layer .. it's easier and more transparent to send user traffic to one prefix/host within the same network.

I also agree that multiple routing protocols should use separate net prefixes, but I also think that RPL+P2P-RPL concurrently might form an exception, where it may make more sense to use the same prefix.

After reading this, P2P-RPL seems like an ill-defined protocol (loops?). However, RFC 6997 says in its abstract

"This document specifies a point-to-point route discovery mechanism,
complementary to the Routing Protocol for Low-power and Lossy
Networks (RPL) core functionality."

So I would expect this to be an extension mechanism of core RPL meaning that one instance of a RPL+P2P protocol operate. In 1. it says

"This document describes an extension to core RPL (i.e., the RPL
functionality described in [RFC6550]) that enables an IPv6 router in
the LLN to discover routes to one or more IPv6 routers in the LLN "on
demand".

... and later in 6. p2p route discovery is coined as a mode of operation for RPL.

Unfortunately, the document is not written in a way that I can understand it in a reasonable amount of time. Still I would suspect that

(a) P2P-RPL is just an extension of RPL and introduces an additional discovery mode
(b) there is no need for considering two concurrent routing protocols at the FIB level, as the best route selection is done within (P2P-)RPL, which is a single routing instance per prefix.

@cgundogan: Is it possible that the entire problem simply arose from a misunderstanding of this (indeed poorly written) document (RFC 6997 )?

[cgundogan]

@tcschmidt

(a) P2P-RPL is just an extension of RPL and introduces an additional discovery mode
(b) there is no need for considering two concurrent routing protocols at the FIB level, as the best route selection is done within (P2P-)RPL, which is a single routing instance per prefix.
@cgundogan: Is it possible that the entire problem simply arose from a misunderstanding of this (indeed poorly written) document (RFC 6997 )?

The text has disappeared under the interpretation (Nietzsche) (:
I will look again at the appropriate passages of the RFC, but your statements sound very reasonable.

Although, I prefer to think of multiple "RPL instances" as different (sub-)routing protocols running concurrently, because each instance can have its own metric and other parameters. As per RFC6550, it's not possible to join multiple DAGs from the same instance, but it's surely possible to be part of multiple instances (and thus multiple DAGs, for each instance one) at the same time. I can see the point that running those RPL instances on the same net prefix makes everything complicated concerning the route selection, but IMO we cannot just prohibit that. I agree with you that this seems to be highly RPL-specific. Currently, we don't have any kind of best route selection, be it on the RPL-level or not, and my question would be whether it makes sense to draft one to be highly RPL-specific, or rather be a more general concept which can be adapted to different routing protocols with ease?

Furthermore, how (and do we want to?) are we going to allow an administrator to set up static routes that should not be overwritten by routing protocols? This functionality must be independent of any routing protocol, so we may still need a common/shared place, where all routing protocols have access to.. That's why I proposed prioritization on the FIB level.

[waehlisch]

@cgundogan not too many steps at once. First, we need to finally clarify if in a pure P2P RPL setup, P2P RPL runs concurrently with RPL (or if P2P RPL mode is an extension/replacement of RPL basic mode). Maybe @emmanuelsearch can shed some light on this.

[tcschmidt]

Although, I prefer to think of multiple "RPL instances" as different (sub-)routing protocols running concurrently, because each instance can have its own metric and other parameters.

Careful: multiple independent routing machineries may lead to unpredictable disasters ... just think of "how can we assure loop prevention then?"

Also: we want a standard-compliant implementation ... not expressing our personal "how we think it should be" ;)

As per RFC6550, it's not possible to join multiple DAGs from the same instance,

Where is that said?

Furthermore, how (and do we want to?) are we going to allow an administrator to set up static routes that should not be overwritten by routing protocols?

Is this a (common) use case for the IoT: Manual route configuration?

This functionality must be independent of any routing protocol, so we may still need a common/shared place, where all routing protocols have access to.. That's why I proposed prioritization on the FIB level.

I suggest to check back with BSD/Linux implementations ... and then sort out, what is really needed. We want a lean, efficient general-purpose FIB. We definitely don't want to blow this up with all sorts of stuff that is 'eventually useful'.

[emmanuelsearch]

As an (indeed poor) co-author of this spec (@tcschmidt please do suggest improvements, this is an experimental spec) here's what my understanding is, as already stated before in this thread:

• P2P-RPL was designed as an extension of RFC6550, except that
  • it should be able to run without basic RPL running in parallel
  • it should also be able to run with basic RPL in parallel
• RFC6998 is used as a tool to decide which path is better between the P2P path discovered and the existing path
  • based on that, comparison, some logic should prefer the "best path" and stick to it.

Currently we do not have RFC6998 implemented in RIOT. I guess it's fair to say we only support P2P-RPL standalone, in storing mode.

If we want to support other modes and/or RPL+P2P-RPL running in parallel, we need some more work, yes.

If we decide to support the case of several non-cooperating routing protocols running in parallel, we might reuse some of the mechanisms for that, to support RPL+P2P-RPL too, altogether more efficiently.

[cgundogan]

Currently we do not have RFC6998 implemented in RIOT. I guess it's fair to say we only support P2P-RPL standalone, in storing mode.

Just to state the obvious: from the RPL point of view, we do support multiple instances in parallel. We could e.g. run 1 instance (storing-mode), 1 instance (another storing mode, [e.g. with another net prefix]), and 1 instance (p2p mode [again with another net prefix]). We only have a problem if multiple instances use the same net prefix, because of the route clashes in the shared fib.

[tcschmidt]

P2P-RPL was designed as an extension of RFC6550, except that
it should be able to run without basic RPL running in parallel
it should also be able to run with basic RPL in parallel

The way I read these statements is:

• P2P-RPL is designed as an extension to pure RPL, so it is applied as an additional mode of operation within the same routing instance (aka daemon) as pure RPL.
• In addition, it provides complete route discovery capabilities, so one can discard RPL basic mode, if desired.
• Finally, one can start multiple instances of the two protocol modes as is possible sometimes in routing (recall here: many implementations of routing daemons run as singletons by acquiring a kernel lock).

Is this correct?

RFC6998 is used as a tool to decide which path is better between the P2P path discovered and the existing path
    based on that, comparison, some logic should prefer the "best path" and stick to it.

O.K. - for best path selection (aka the routing algorithm), access to all possible/discovered paths is required. This is naturally done on grounds of the internal data/state of a routing protocol instance. It would actually be a problem to organize this between multiple independent instances (and the FIB is not a universal interface for inter-RP communication).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.