[manet] draft-lou-manet-sturp-00 (was Re: IETF 117 draft agenda posted)

I’ve had a quicklook at this document, although not in full detail. I have a few immediate points

In section 1 it says

"The Optimized Link State Routing (OLSR) protocol defined in [RFC3626] and further optimized by  [RFC7181]”

This is not an accurate statement of the relationship between those documents. OLSRv2 (RFC 7181) is a
replacement or alternative to OLSRv1 (RFC 3626). It of course is an improvement (we believe) but RFC 3626
Is not optimised by RFC 7181, no part of RFC 3626 is required by OLSRv2 (RFC 7181). [There are further
optimisations of RFC 7181, such as RFC 7183 and RFC 7466, and RFC 7181 builds on other RFCs such as
RFC 6130, but that’s a different issue.]

The draft also says that

"It is important to note that STURP does constitute a routing protocol
per se, but merely addresses the crucial component for providing
opology update.  As such, we target the integration of STURP with
existing routing protocols, improving thus the efficacy of those
existing protocols.”

I will here only consider OLSRv2. The approach of this draft is the wrong way to consider improving OLSRv2.
Building a new set of topology bases, and defining a new set of parallel signalling would be highly inefficient.
If there are improvements to be made to OLSRv2, the sensible approach is to work out what you are trying to
Add (and of course why) and consider adding to its information bases, and augmenting its signalling - because
one of the key features of OLSRv2, built on the packet/message structure of RFC 5444 - and also see RFC 8245
- is the extensibility of messages.

It’s also worth considering what you can do with the protocol as is. One of the regrets of this author is that we
never published (pieces exist in unpublished notes) a guide to how the multiple features of OLSRv2 can be
used in ways that might not immediately be obvious. For example, this draft says

"the frequent periodic refreshing leads to higher power
 consumption, which is not desirable for battery enabled devices”

How frequent the updates are is up to how devices are configured. In fact, by setting update periods to very large
values, but using the permission granted for updates in response to changes, you can actually run an almost
entirely responsive rather than proactive protocol, provided that you have sometime - lower layers or network
traffic are the obvious candidates - to indicate that updates are required.

Features such as this should be carefully considered before concluding that you need an improvement. And then
if needed should be more efficiently developed. And always one should consider that OLSRv2 is a Proposed
Standard in use, and backward compatibility and interoperability with other devices (as, for example, was
maintained by RFC 7722) should be considered.

I thus strongly consider that this draft has should not, in its current form, be accepted as a WG draft. It hasn’t
made a strong enough case for why it is wanted and its approach, certainly in the case of OLSRv2 (which is the
only protocol that has been standardised by this WG, others are at best experimental) is not a good one - including
not considering what OLSRv2 can already be made to do.

However, I would note that there is one area that this draft has a relevant concept, one which as an extension to
OLSRv2 has in the past been considered, but never developed (as far as I know - certainly not in the IETF).
This is in the area of a bulk topology update. Such an extension should be one designed to fit the existing protocol
and would (properly signalled)| be fully interoperable with routers not using the extension. 

Such an update might be relevant in two cases. One is the above mentioned responsive use of the protocol. The
other is to accelerate a new router joining the network, where a neighbour on recognising that the router could use
a fast update, could copy the relevant parts of its information bases to the neighbour. This could be included in a
HELLO message on a suitable interface. What relevant means would need discussion, and so would the formatting.
(Information is naturally about links from one router to another, but the RFC 5444 format is better suited to information
attached to single addresses. However, there are possible ideas that could be used here.

> On 13 Jul 2023, at 15:12, Velt, R. (Ronald) in 't <Ronald.intVelt=40tno.nl@dmarc.ietf.org> wrote:
> 
> MANET WG,
>  
> A draft agenda for the WG session at IETF 117 has been posted here:
> https://datatracker.ietf.org/doc/agenda-117-manet/
>  
> Proposals for changes are welcome. There is room at the end of our session for an additional presentation (or discussion) (15 minutes max.). Please let the chairs know if you want to make use of this slot. The final agenda is due next Monday at 23:59 UTC.
>  
> Thanks,
> MANET chairs (DDR)
>  
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org <mailto:manet@ietf.org>
> https://www.ietf.org/mailman/listinfo/manet