Re: [manet] draft-ietf-manet-olsrv2-multipath-06

["Dearlove, Christopher (UK)" <[e-mail]>]

Short version: I do not think this draft is ready for WGLC acceptance. There are at least two major issues for me, and various details I haven’t dug into.

My main reservation about this draft has always been, and remains, that OLSRv2, by design, maintains a subset of the network topology sufficient for a best route to each destination. Picking multiple paths from that subset will not guarantee to find all alternative paths that may exist.

There was a mechanism in OLSRv1 (coverage parameter when creating MPRs) that would have ensured that. But it coexisted very uneasily with link metrics in particular, and it didn’t end up in OLSRv2.

Also, before getting to the draft itself, the point above about link metrics applies here. With arbitrary link metrics, alternative paths having exactly the same link metric may often be rare or accidental. Which leads to the question whether alternative paths must have the same metric (so may often not exist) or may have a different metric – and if so how to decide a cutoff. (And how to avoid looping – unless using source routing, which may also be needed to enforce using the alternative paths.)

So on to the draft

Section 1.1, first list, point 3. I don’t see this as a motivation for multiple path routing. If routers are not to be used, that’s an issue for single path routing too.

Section 1.1, second list. Some of the wording isn’t really focussed on what experiments are requested to advance beyond experimental. The most obvious case is the penultimate point which discusses what would be interesting. Some are more important than others. I don’t like the implication of the third point that hop count is normal. Metrics other than hop count are what we are all assuming these days I think, and if this only works well with hop count (and I have my concerns there, as indicated above) it is for me a non-starter.

I see the comment about interoperability with OLSRv2. This is managed by requiring a SOURCE_ROUTE MPR in all TC messages from routers that support this. (I haven’t yet checked details.) Note however that not all routers create TC messages, and those that don’t are because there is an alternative route. (That’s the effect, the actual rule is to do with having advertised neighbours, at least MPR selectors.) But that alternative route may be not source routed. The net effect (a special case of the limited topology problem I note above) is that although there may be a source routable route to a destination, one may never be reported. To force that it’s not good enough to say all source routable routers must send a TC, instead I’m fairly sure you will need to modify MPR selection so that source routable routers cover neighbours using other source routable neighbours to the maximum extent possible. Is that sufficient? Not sure. There is however no consideration of this.

This alone is for me a showstopper, I do not think this draft is good enough to pass WGLC.

7.2 has costs of paths. If this is OLSRv2 path metric, use that term. If not, why not?

8.3 In round-robin fashion? That needs defining. There’s also an “or else”. Compatibility issues? The approach we’ve always taken in the OLSRv2 set of protocols is (a) specify the required properties of the process, (b) give compliant example algorithm(s), usually in an appendix. I don’t know at this point what key routers are, or have a forward reference. I’m not sure if a hop limit is correct for a general metric.

(There are some stylistic differences in naming that I’d try to iron out if proceeding, but I’m not going to consider those in detail.)

Datagram forwarding. I’m unhappy here about that we now have a routing protocol that’s doing the data plane forwarding. I’ve been critical of AODVv2 for assuming too much of IP, this is actually worse in some regards, it’s doing the forwarding, and modifying the packet (if it’s using IPsec, what happens?) and not using IP source routing. This also is a showstopper for WGLC as far as I’m concerned, even more so than the last one. What are the implementations described in section 10 doing here?

I have my doubts that the security considerations section is adequate, but that’s not critical at this point.

IANA – you can drop TLV naming – it’s now an RFC, it’s been done. No need even to reference it. Table 1 it’s not up to you to specify the lines TBD-223 and 224 to 255 (especially the latter, which is unchanged).

Appendix, I haven’t studied, but I’d like to see an example not using hop count. There’s a lot at the end that raises more questions than it answers. Delay isn’t just about number of hops (and 50 is an exceptional case). If delay matters, it should be part of your metric and handled that way.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________

T:  [phone]  |  E: [e-mail]<mailto:[e-mail]>

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: manet [mailto:[e-mail]] On Behalf Of Jiazi YI
Sent: 13 October 2015 23:19
To: MANET IETF
Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06


*** 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://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

Dear all,

As a reminder, the WGLC of draft-ietf-manet-olsrv2-multipath-06 (https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/) will be closed on Oct. 16.

Your comments on the document will be highly appreciated :)

cheers

Jiazi

On Fri, Oct 2, 2015 at 3:33 PM, Stan Ratliff <[e-mail]<mailto:[e-mail]>> wrote:
Hello WG participants,

The above referenced draft seems to have addressed all of the outstanding WG comments to date. Therefore, it's time for a Working Group Last Call (WGLC) on this document. The WGLC period will close on October 16. Please read and review the document, and provide comments, prior to that time if possible.

Regards,
Stan

_______________________________________________
manet mailing list
[e-mail]<mailto:[e-mail]>
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.
********************************************************************