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

[Jiazi YI <[e-mail]>]

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