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

[Christopher Dearlove <[e-mail]>]

My comments below. In particular note the last one on attendance.

More broadly, I’m out of touch with current policy in the WG. It was, when I was last involved beyond watching
And the occasional comment, all about Standards Track - the successful attempt to release OLSRv2, and the less
successful attempt to define AODVv2 (aka DYMO). Thus, if that policy still applied then experimental ideas
(as the four Experimental RFCs and greater numbers of drafts the WG produced) would not be the WG’s remit.
But, as I said, I don’t know what current policy is.

[Note that there is also DLEP, but I’m here just considering routing protocols.]

> On 16 Jul 2023, at 21:34, Zhe Lou <[e-mail]> wrote:
> 
> Hi Christopher,
>  
> Thanks for your comments! Before more detailed comments inline, let me re-iterate the intention of this draft. It outlines a general concept and mechanism with the intention to integrate into existing routing protocols through specific extensions to them. It is clear to us that the specifics of those extensions are very much dependent on the routing protocol in question.
>  
> With this mind, we see the STURP draft as the initial starting point for engaging with the specific community of interest about the needed and possible extensions. In the case of MANET, we would very much like to work with the wider community on which aspects of STURP may be useful to OLSRv2 and how they could specifically be integrated.
>  
> Please see detailed comments inline.
>  
> Regards
> David
>  
> From: manet <[e-mail] <mailto:[e-mail]>> On Behalf Of Christopher Dearlove
> Sent: Thursday, July 13, 2023 10:09 PM
> To: [e-mail] <mailto:[e-mail]>
> Subject: [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.]
> [DL] Good point, thanks. The text will be updated accordingly in the next version.
>  
> 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.
> [DL] As mentioned in the beginning, the purpose of the STURP draft is to introduce a new mechanism to improve the efficiency of topology refresh. A chapter, “Integration with Existing Routing Protocols”, well in our plan, has not been finished. Thanks to your comments, I do see that the messages in current formats might not be an ideal approach to be integrated into OLSRv2. We will try to come out with a proposal following the message structure of RFC 5444 in the next version.

I think that interoperability is also critical. Note that OLSRv2 is very permissive in allowing different routers to use different parameters,
different MPR selection algorithms and more, and still interoperate. (The choice of the constant C being a rare exception.) You can even
have some but not all routers using MT-OLSRv2. (Choice of metric type of types is also an exception, as is authentication.)

> 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.
> [DL] Proactive or responsive topology updates are two approach with their advantages and disadvantages. In the STURP draft, we try to find a way in between. The topology update happens in response to the changes of ongoing communication relations, i.s.o. alter of topology (e.g. nodes joining of leaving), which makes it more efficient. While the regular update interval could be indeed set to large values.

Which is - if the regular interval is sufficiently large that it essentially never happens - what I’m referring to by “responsive” in what I wrote.
The largest possible time value, as reported using RFC 5497 with C =1/1024 second is about 3 days, which is effectively infinite as intervals
are reset any time there is a change.

The scenario that needs thinking through is that if, for example, a new router joins the network, this will induce exchanges of HELLO messages
Near the new router, and some new TC messages, as two hop neighbours become aware of the new router, and recalculate MPRs, hence
further updating HELLO messages. This will fairly quickly (depending on transmission delays and RFC 5148 jitter). That means that all other
routers will get to know how to reach the new router. But we also need the new router to learn how to reach remote routers, which means that
all routers that do so should create new TC messages. Whether and how that occurs is worth thinking through. (It relies on routers using their
permission to send TC messages on identifying a network change - the exact rules for that need checking.)

The bulk update suggested below as a possibility would be an accelerant to that, and provide greater robustness against routers not resending
TC messages.

> 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. 
> [DL] Agree.
>  
> 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.
> [DL] I suggest to discuss about it in the MANET meeting during IETF117.

While I would love to do that, unfortunately I won’t be there. I am now retired from my previous employer (as credited on all the RFCs I’m an author of)
and the cost of travel, hotels, and IETF attendance paid personally makes that financially impractical. Actually were that not so, I’d have a clash with
something else to physically attend. But that clash doesn’t cover the meeting date. I’ve just checked the IETF website and I could apply for a fee waiver
for remote attendance. Manet is 00:00-01:00 UTC or 01:00-02:00 local here. So not ideal - and I’d have to experiment with the IT. So maybe.

> On 13 Jul 2023, at 15:12, Velt, R. (Ronald) in 't <Ronald.intVelt=[e-mail] <mailto:Ronald.intVelt=[e-mail]>> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/manet
>