A few comments on this draft.
IPv6 specifies complete source routing. But this specification can only
consider what happens within the MANET. So for a packet from somewhere in the
MANET to somewhere well outside the MANET, the packet must be source routed to
the gateway between MANET and rest of Internet, and not source routed after
that. This I think should be explicitly mentioned. Whether that is considered
compliant with IPv6 I leave to others.
7.1 SR_addr would better say "originator" address rather than "network"
address. (That makes it an address without a netmask, see RFC 7181.)
8.1 This is suggesting creating TC messages that have on neighbour addresses
but have only a SOURCE_ROUTE TLV. This is not the design I would have suggested
as consistent with how I would expect an extension to OLSRv2 to do things. We
need to consider two kinds of routers: those sending TC messages anyway, those
that (other than this extension) do not. In the former case you could just add
the SOURCE_ROUTE TLV to those TC messages it sends. Then that information is
maintained up to date. Routers that don't usually send TC messages could send
TC messages with just that TLV. But then there's an issue over validity time. A
parameter SR_HOLD_TIME_MULTIPLIER is introduced. There's no need for that - you
can simply incorporate that into the validity time recorded in the message.
That avoids a need to handle the two cases of routers differently. There is
then an oddity that you get some routers sending TC messages with normal
validity times and addresses, and some that can be sent !
less frequently with no addresses and longer validity times. But that's
suspect - note that it's not done in OLSRv2 for attached networks (another
reason to send TC messages although no neighbours need reporting). That's
because longer intervals make reacting to new routers joining (and network
reassembly after fragmentation) slow. Rather a better design would simply be to
add SOURCE_ROUTE TLV to normal TC messages. When sending TC messages for just
that reason, that could be just the usual case, but you could allow as an
option in this case to send less frequently with validity time increased
accordingly. When not using that option, once a router needs to send a TC
message, it could then decide to report neighbours, increasing the topology
distributed and allowing more routes, this also being an option.
8.3 second bullet. You should here (and possibly elsewhere) exclude routers
with routing willingness zero.
8.3 there seems to be an inconsistency. When operating proactively and no
multiple routes, drop the packet, but reactively use standard routing. The
latter seems more appropriate in the former case also.
9 CUTOFF_RATIO. Insists of strictly, but as defined earlier, may be >= 1`.
--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________
T: +44 3300 467500 | E: chris(_dot_)dearlove(_at_)baesystems(_dot_)com
BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,
Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
-----Original Message-----
From: manet [mailto:manet-bounces(_at_)ietf(_dot_)org] On Behalf Of The IESG
Sent: 20 April 2017 22:51
To: IETF-Announce
Cc: manet(_at_)ietf(_dot_)org;
draft-ietf-manet-olsrv2-multipath(_at_)ietf(_dot_)org;
manet-chairs(_at_)ietf(_dot_)org
Subject: [manet] Last Call: <draft-ietf-manet-olsrv2-multipath-12.txt>
(Multi-path Extension for the Optimized Link State Routing Protocol version 2
(OLSRv2)) to Experimental RFC
----------------------! WARNING ! ---------------------- This message
originates from outside our organisation, either from an external partner or
from the internet.
Consider carefully whether you should click on any links, open any attachments
or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on
reporting suspicious email messages.
--------------------------------------------------------
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.
The IESG has received a request from the Mobile Ad-hoc Networks WG
(manet) to consider the following document:
- 'Multi-path Extension for the Optimized Link State Routing Protocol
version 2 (OLSRv2)'
<draft-ietf-manet-olsrv2-multipath-12.txt> as Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2017-05-04. Exceptionally, comments
may be sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain
the beginning of the Subject line to allow automated sorting.
Abstract
This document specifies a multi-path extension for the Optimized Link
State Routing Protocol version 2 (OLSRv2) to discover multiple
disjoint paths, so as to improve reliability of the OLSRv2 protocol.
The interoperability with OLSRv2 is retained.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/
IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ballot/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
manet mailing list
manet(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/manet
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************