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

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

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.
********************************************************************