I think point 3 should be “may” rather than “will”, but otherwise good.
--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________
T: +44 3300 467500 | E:
chris(_dot_)dearlove(_at_)baesystems(_dot_)com<mailto:chris(_dot_)dearlove(_at_)baesystems(_dot_)com>
BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,
Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
From: Jiazi Yi [mailto:ietf(_at_)jiaziyi(_dot_)com]
Sent: 10 May 2017 13:41
To: Dearlove, Christopher (UK)
Cc: ietf(_at_)ietf(_dot_)org; manet(_at_)ietf(_dot_)org;
draft-ietf-manet-olsrv2-multipath(_at_)ietf(_dot_)org;
manet-chairs(_at_)ietf(_dot_)org
Subject: Re: [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 the internet.
Consider carefully whether you should click on any links, open any attachments
or reply.
For information regarding Red Flags that you can look out for in emails you
receive, click
here<http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this
process<http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Dealing%20With%20Suspicious%20Emails.pdf>.
Hi Chris,
OK, it makes sense. So the policy will be:
- the SOURCE_ROUTE TLV won’t have any value
- Every TC message originated by the source-route supported routers
will have a SOURCE_ROUTE TLV
- The TC message not containing any neighbour address will have a
longer validity time compared to OLSRv2 normal TC messages.
best
Jiazi
On 10 May 2017, at 11:33, Dearlove, Christopher (UK)
<chris(_dot_)dearlove(_at_)baesystems(_dot_)com<mailto:chris(_dot_)dearlove(_at_)baesystems(_dot_)com>>
wrote:
Additional comments >>> below. What I'm proposing (spelled out a bit more) is
all win, and removes problems with the current design. I think this is a must
do.
--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________
T: +44 3300 467500 | E:
chris(_dot_)dearlove(_at_)baesystems(_dot_)com<mailto:chris(_dot_)dearlove(_at_)baesystems(_dot_)com>
BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,
Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://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: Jiazi Yi [mailto:ietf(_at_)jiaziyi(_dot_)com]
Sent: 09 May 2017 23:49
To: Dearlove, Christopher (UK)
Cc: ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org>; IETF-Announce;
manet(_at_)ietf(_dot_)org<mailto:manet(_at_)ietf(_dot_)org>;
draft-ietf-manet-olsrv2-multipath(_at_)ietf(_dot_)org<mailto:draft-ietf-manet-olsrv2-multipath(_at_)ietf(_dot_)org>;
manet-chairs(_at_)ietf(_dot_)org<mailto:manet-chairs(_at_)ietf(_dot_)org>
Subject: Re: [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.
--------------------------------------------------------
Hi Chris,
Thanks a lot for the comments! Please check our reply inline:
On 9 May 2017, at 12:13, Dearlove, Christopher (UK)
<chris(_dot_)dearlove(_at_)baesystems(_dot_)com<mailto:chris(_dot_)dearlove(_at_)baesystems(_dot_)com>>
wrote:
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.
Good point. We added some text at the end of section 8.4" Datagram Processing
at the MP-OLSRv2 Originator"
7.1 SR_addr would better say "originator" address rather than
"network" address. (That makes it an address without a netmask, see
RFC 7181.)
fixed.
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.
IIRC, we had a long discussion on this issue and produced the current text.
The purpose is to identify the routers that don’t send TC messages but support
source routing. To avoid unnecessary TC flooding, the interval is much longer
than the normal TC interval.
The normal TC messages (generated based on RFC7181) always have a SOURCE_ROUTE
TLV. But if we use the same validity time for both RFC7181 normal TC processing
and MP-OLSRv2 SR_ROUTE TLV processing, the valid time in the SR-OLSRv2 Router
Set would be much shorter than expected. A possible case is that, the router
stops sending normal TC messages, the corresponding entry in the SR-OLSRv2
Router set will soon expire.
Therefore, I think it’s reasonable to make use of the SR_HOLD_TIME_MULTIPLIER
to distinguish the valid time of normal TC message information and SR_ROUTE
information.
I don't agree, and I think what you are suggesting introduces a problem and
unnecessary overhead.
The problem is that everywhere in OLSRv2 we are careful to ensure that
parameters can be independently set, and that routers don't need to coordinate
to interoperate. (They may do better if they do, but that's a refinement.) Here
you are using an SR_HOLD_TIME_MULTIPLIER that the receiver has to know is what
the sender intends. And it's unnecessary. If all that's in the TC message is
the SOURCE_ROUTE TLV, you can just give that a longer validity time, because
the only thing that validity time will impact on is the source routing status.
If the router is also sending normal TC messages and you send separate
SOURCE_ROUTE TLV TC messages then that would still be so. But that's
inefficient, because if the router is already sending TC messages, why send
separate ones with added overhead, when you can put the SOURCE_ROUTE TLV in the
same TC message? That would then (without SR_HOLD_TIME_MULTIPLIER, but that's a
good thing because SR_HOLD_TIME_MULTIPLIER is not good) give a shorter validity
time to the SOURCE_ROUTE TLV, but that's fine, because that router will be
sending more TC messages within that timescale anyway. Furthermore, this also
allows the router that's sending TC messages more frequently to provide its
information more responsively in the cases of nodes joining and networks
reassembling.
That gives two behaviours: routers sending TC messages anyway, just add a
SOURCE_ROUTE TLV, and routers not sending TC messages otherwise, just include a
SOURCE_ROUTE TLV and set the validity time according to what schedule that
router chooses to use - which can be at the same rate as the other routers, or
at a slower route, or (a new capability you don't have) slowly, except if you
learn of the existence of a new router in the network you can send one or more
responsive SOURCE_ROUTE TLV only TLVs to enable that new router (or routers) to
learn of the source routing quicker.
It's all win: combining messages, source set control, ability to do more clever
things if you want to. (You could probably even still send separate TC
messages with a SOURCE_ROUTE TLV when also sending normal TC messages if you
really wanted to, as an option I can't see wanting to use - although it might
introduce a minor problem that I haven't worked through the OLSRv2
specification to check, because it's unnecessary.)
The point is that what I suggest can gain everything you do, and allow more,
plus not breaking expected OLSRv2 behaviour.
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`.
All fixed.
Thanks again for the valuable comments!
best
Jiazi
--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
______________________________________________________________________
____
T: +44 3300 467500 | E:
chris(_dot_)dearlove(_at_)baesystems(_dot_)com<mailto:chris(_dot_)dearlove(_at_)baesystems(_dot_)com>
BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,
Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://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<mailto:manet(_at_)ietf(_dot_)org>;
draft-ietf-manet-olsrv2-multipath(_at_)ietf(_dot_)org<mailto:draft-ietf-manet-olsrv2-multipath(_at_)ietf(_dot_)org>;
manet-chairs(_at_)ietf(_dot_)org<mailto: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<mailto:ietf(_at_)ietf(_dot_)org> mailing lists by
2017-05-04. Exceptionally, comments may be sent to
iesg(_at_)ietf(_dot_)org<mailto: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/bal
lot/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
manet mailing list
manet(_at_)ietf(_dot_)org<mailto: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.
********************************************************************