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

[Ulrich Herberg <[e-mail]>]

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
>