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

[Christopher Dearlove <[e-mail]>]

Unless you manage the MPRs there may (in a mixed network) be destinations you cannot source route to, although (with complete knowledge) that would be possible.

--  
Christopher Dearlove
[e-mail] (iPhone)
[e-mail] (home)

> On 20 Oct 2015, at 01:02, Jiazi YI <[e-mail]> wrote:
> 
> Hi, 
>  
>> 
>> Sorting out MPRs and interworking can't be fixed with just a SHOULD. There isn't even a proof on the table that making it a MUST works. This is not good enough to proceed.
>> 
>> No, creating a TC is anything but mandatory. It's mandatory under certain conditions, which may not apply. Again, this misunderstanding is fundamental to whether the protocol will interwork with basic OLSRv2.
> 
> The point I want to make is:
>    - The SOURCE_ROUTE TLV are sent over both HELLO and TC messages. 
>    - I'm skeptical to making it a MUST, because even we don't consider it at all, it won't bring any negative impact to the network. Although a router with this extension will find less SOURCE_ROUTE enabled routers in that case, it can still work perfectly with other OLSRv2-only routers like a normal OLSRv2 router. 
>  
>> 
>> I haven't had time to consider the source routing. But if it's being done by IP, just say so and don't confuse matters here.
> 
> Agree. 
>  
>> This draft is, I'm afraid, not in a suitable state for a WGLC. It needs to go back, have some major changes made, and re-enter pre-WGLC discussion.
> 
> The authors are, of course, willing to discuss related issues with the WG and have them appropriately resolved. 
>  
>> 
>> (A point I've not previously made is that we have multitopology now out of the IESG and heading to be an RFC soon. I'd not be happy with this draft if incompatible with that, also a discussion worth having.)
> 
> I don't see the how the multipath draft would be incompatible with the multi-topology draft. 
> In fact, those two drafts are two different approaches to solve different problems. This olsrv2-multipath draft tries to make use of multiple parallel paths to send packets. It can even make use of the multiple topology to build multiple paths -- this is, of course, not tested yet. But we wrote it as a possible experiment to do in the "Motivation and Experiments to Be Conducted" section. 
> 
> best
> 
> Jiazi
>  
>> 
>> --  
>> Christopher Dearlove
>> [e-mail] (iPhone)
>> [e-mail] (home)
>> 
>>> On 19 Oct 2015, at 21:49, Jiazi YI <[e-mail]> wrote:
>>> 
>>> Dear Ulrich, Chris, all:
>>> 
>>> Thanks very much for your valuable comments. We appreciate your detailed review of the draft. 
>>> 
>>> At this point, please allow me to reply to some of your major concerns first. For the rest, I'll respond in another mail later, or integrate directly into the draft.  
>>> 
>>> - Source routing intrusion to the IP stack  
>>> 
>>> This is one of the major concerns brought out by Chris, Ulrich and Geoff Ladwig on the list or privately. 
>>> In fact, this draft uses the standard source routing. The steps defined in  https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-06#section-8.5 is simply a synthesis of RFC 791 (for IPv4) and RFC 6554 (for IPv6). 
>>> Therefore, if the system support the IPv4 source routing defined in RFC791, or the IPv6 source routing defined in RFC6554, this part is already there. 
>>> I'll make it more explicit in the next revision. 
>>> 
>>> -  Finding alternative paths in OLSRv2
>>> 
>>> From Chris:
>>>> 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.
>>> 
>>> Finding all alternative paths - no. It's not the design goal either. Finding useful multiple paths - yes. 
>>> As each router selects MPR independently, and it's hard to get an optimal set of MPR (most of the time, the greedy algorithm is used), we always have redundancies in the topology graph. Multiple paths can thus be found. 
>>> Simulation study and testbed experiments (not only from the authors, but also from different parties) have shown that the extension obtain the multiple disjoint paths desired.  
>>> In fact, in the OLSRv1 epoch, we actually played with the TC_REDUNDANCY parameter to obtain the whole topology graph. But it didn't give us any gain, but much more significant control overhead, as expected.    
>>> 
>>> 
>>> - Link metrics
>>> 
>>> From Chris:
>>>> 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.)
>>> 
>>> This multipath extension does not require the paths have the same metric. It can use any metrics that are suitable for OLSRv2. As Chris said, it uses source routing to avoid looping. 
>>> 
>>> - Interoperability with OLSRv2
>>> 
>>> From Chris:
>>>> 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? 
>>> 
>>> In fact, the SOURCE_ROUTE TLV is not only in TC messages, but also HELLO messages. 
>>> It's very good point that it's preferred to choose multipath-extension enabled router as MPR, to make them visible. We are thinking about having it as a SHOULD/RECOMMENDATION in the next revision. 
>>> 
>>> Is that sufficient? From interoperability point of view, I think yes. For my understanding, when we have extension-foo to bring certain performance gain, being interoperable means that using extension-foo won't interrupt the existed operations. We don't expect in a mixed environment can have the same performance gain as all routers with extension-foo. 
>>> Here, the worst case is that the SOURCE_ROUTE enabled routers are not advised -- it won't break the network. But of course, the performance gain is less than all SOURCE_ROUTE enabled network. We have observed that by simulation study. 
>>> 
>>> I also have a question to Chris:
>>> You said not all routers create TC messages, but in RFC7181, we read:
>>> 
>>>>   A router with one or more OLSRv2 interfaces, and with any Neighbor
>>>>    Tuples with N_advertised = true, or with a non-empty Local Attached
>>>>    Network Set MUST generate TC messages.  A router that does not have
>>>>    such information to advertise MUST also generate "empty" TC messages
>>>>    for a period A_HOLD_TIME after it last generated a non-empty TC
>>>>    message.
>>> 
>>> 
>>> If I understand well, generating TC message is a MUST for OLSRv2, even an "empty" one? 
>>> 
>>> Above is just a reply to some of the major issues that I would like to discuss and clarify in the first place. I'll reply to other comments in another mail later. 
>>> 
>>> Thanks again for your time reviewing the document and bringing out all those issues -- I believe that, if we can't make the document clear to you, it must be we doing something wrong :)
>>> 
>>> regards
>>> 
>>> Jiazi
>>> 
>>> 
>>> 
>>> 
>>>> On Thu, Oct 15, 2015 at 1:33 PM, Dearlove, Christopher (UK) <[e-mail]> wrote:
>>>> I agree with all of Ulrich's points, which overlap mine - he's caught some good points I haven't made such as the multiple addressing point, and that willingness is local (only in HELLO messages and Neighbour Set) in OLSRv2.
>>>> 
>>>> --
>>>> Christopher Dearlove
>>>> Senior Principal Engineer
>>>> BAE Systems Applied Intelligence
>>>> __________________________________________________________________________
>>>> 
>>>> T:  [phone]  |  E: [e-mail]
>>>> 
>>>> 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:[e-mail]] On Behalf Of Ulrich Herberg
>>>> Sent: 14 October 2015 18:13
>>>> To: Jiazi YI
>>>> Cc: 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 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.
>>>> 
>>>> 
>>>> Jiazi,
>>>> 
>>>> thanks for the reminder. I read the draft and have a few comments and questions. Overall, I think that the draft is well written, but lacks some details that would have to be specified before I'd feel comfortable implementing this in an interoperable fashion.
>>>> 
>>>> 
>>>> - section 5.1. (router parameters).
>>>> o NUMBER_OF_PATHS: Is this a constant? Can it change during router operations? If so what are the constraints, and how does the change impact existing routes? Is this a constant per router, or could I have, say, 3 paths for a certain destination that I need a lot, but only 1 for others?
>>>> o MAX_SRC_HOPS: same as above. (constant? constraints?) Do these two parameters have to be negotiated between all routers or are there no interop problems if routers use different values in the network?
>>>> o fp/fe: This is a function (of what?). I am not sure I understand why this is listed under a section Parameters. How can I implement this?
>>>> 
>>>> - section 6:
>>>> "To support source
>>>>    routing, a source routing header is added to each datagram routed by
>>>>    this extension."
>>>> 
>>>> I think there is a section missing about interaction with FIB/RIB.
>>>> Somewhere else it is said that "[...] the MP-OLSRv2 routing process receives a datagram from upper layers or interfaces connecting other routing domains". How does this work? This may also need some additions to the applicability statement section.
>>>> 
>>>> - section 7.2:
>>>> How does this interact with the Routing Set in OLSRv2? Is this used instead? Does the MR_valid_time have to be the same as the timeout on the Routing Set?
>>>> 
>>>> - "PT_cost -   the cost of the path to the destination"
>>>> Cost in what? Hops? Does this support metrics other than hop count?
>>>> 
>>>> - "PT_address[1...n] -   the addresses of intermediate routers to be
>>>>       visited numbered from 1 to n."
>>>> 
>>>> A router may have multiple addresses for each of its interfaces. Does it matter which addresses are used in this list? Is loop-freedom guaranteed?
>>>> 
>>>> - Section 8.2.: SR_OLSR_HOLD_TIME
>>>> What is the relationship with other OLSRv2 information sets? Could there be a situation where I still have an SR-OLSR Router Tuple, but the same destination is not present anymore in other OLSRv2 sets (Routing Set, Topology Set etc). Since the hold_time can be chosen independently, that seems possible.
>>>> 
>>>> - Section 8.3: " When the MP-OLSRv2 routing process receives a datagram from upper
>>>>    layers or interfaces connecting other routing domains..."
>>>> How does this work, "other routing domains"? How would a router determine this?
>>>> 
>>>> - "   o  If the length of the path (n) is greater than MAX_SRC_HOPS, only
>>>>       the key routers in the path are kept.  By default, the key routers
>>>>       are uniformly chosen in the path."
>>>> 
>>>> What are key routers? How does this work?
>>>> 
>>>>    o  The routers with higher priority (such as higher routing
>>>>       willingness defined in [RFC7181]) are preferred.
>>>> 
>>>> How?
>>>> 
>>>> - Section 8.4: This doesn't use the information bases that have been defined before. How can I implement this using the existing information form the protocol? (without all that abstraction)
>>>> 
>>>> - Section 8.5. This seems to be quite intrusive into the IP stack. I thought it would be enough to add the source route header at the first router along the path, and then just use standard source routing. Or is the path changed during forwarding the packet?
>>>> 
>>>> - Security:
>>>> 
>>>> "Compared to OLSRv2, the use of source routing header in this
>>>>    specification introduces vulnerabilities related to source routing
>>>>    attacks, which include bypassing filtering devices, bandwidth
>>>>    exhaustion of certain routers, etc.  Those attacks are discussed in
>>>>    Section 5.1 of [RFC6554] and [RFC5095].  To make sure that the
>>>>    influence is limited to the OLSRv2/MP-OLSRv2 routing domain, the
>>>>    source routing header MUST be used only in the current routing
>>>>    domain."
>>>> 
>>>> Is this enough to let this pass the Sec ADs? How is this enforced, "only in the current routing domain"?
>>>> 
>>>> Best regards
>>>> Ulrich
>>>> 
>>>> On Tue, Oct 13, 2015 at 3:18 PM, Jiazi YI <[e-mail]> wrote:
>>>> > 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]> 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]
>>>> >> https://www.ietf.org/mailman/listinfo/manet
>>>> >>
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > manet mailing list
>>>> > [e-mail]
>>>> > https://www.ietf.org/mailman/listinfo/manet
>>>> >
>>>> 
>>>> _______________________________________________
>>>> manet mailing list
>>>> [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.
>>>> ********************************************************************
>>> 
>>> _______________________________________________
>>> manet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/manet
>