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

From: Stan Ratliff <[email-masked]>
Date: Fri, 2 Oct 2015 09:33:54 -0400

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

---

From: Jiazi YI <[email-masked]>
Date: Wed, 14 Oct 2015 00:18:55 +0200

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 <[email-masked]> wrote:

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 14 Oct 2015 10:12:52 -0700

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 <[email-masked]> 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.
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 15 Oct 2015 11:30:26 +0000

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:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

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:[email-masked]] 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.

cheers

Jiazi

On Fri, Oct 2, 2015 at 3:33 PM, Stan Ratliff <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
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.
********************************************************************

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 15 Oct 2015 11:33:24 +0000

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.

T:  +44 (0)1245 242194  |  E: [email-masked]

www.baesystems.com/ai

-----Original Message-----
From: manet [mailto:[email-masked]] 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 ***

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

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?

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?

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:

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 <[email-masked]> wrote:
> (https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/) 
> will be closed on Oct. 16.
>
>> 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
>>

---

From: Jiazi YI <[email-masked]>
Date: Mon, 19 Oct 2015 22:49:59 +0200

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) <
[email-masked]> 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
> ----------------------! WARNING ! ---------------------- This message
> originates from outside our organisation, either from an external partner
> or from the internet.
> 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.
>
>
> 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?
> routing domains". How does this work? This may also need some additions to
> the applicability statement section.
>
> - section 7.2:
> instead? Does the MR_valid_time have to be the same as the timeout on the
> Routing Set?
>
> 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?
>
> 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.
>
> defined before. How can I implement this using the existing information
> form the protocol? (without all that abstraction)
>
> router along the path, and then just use standard source routing. Or is the
> path changed during forwarding the packet?
>
> - Security:
>

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 19 Oct 2015 23:40:42 +0100

As I may not find time to reply in detail immediately, I'll just make a few points.

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.

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. If not, there's a problem.

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.

(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.)

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 19 Oct 2015, at 21:49, Jiazi YI <[email-masked]> 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. 
> -  Finding alternative paths in OLSRv2
> 
> From Chris:
> 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. 
> 
> 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) <[email-masked]> wrote:

---

From: Jiazi YI <[email-masked]>
Date: Tue, 20 Oct 2015 02:02:37 +0200

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

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

---

From: Christopher Dearlove <[email-masked]>
Date: Tue, 20 Oct 2015 07:13:31 +0100

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.

> On 20 Oct 2015, at 01:02, Jiazi YI <[email-masked]> wrote:
> 
> Hi, 
>  
>> 
>    - 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. 
>  
> The authors are, of course, willing to discuss related issues with the WG and have them appropriately resolved. 
>  
>> 
> 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

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 20 Oct 2015 16:25:27 +0200

Just two quick points...

> On 20 Oct 2015, at 02:02, Jiazi YI <[email-masked]> wrote:
> 
> Hi, 
>  
>> 
>> No, creating a TC is anything but mandatory. It's mandatory under certain conditions, which may not apply.

Specifically, a TC is mandatory only if having a non-empty MPR-selector set, or a non-empty Attached Network set -- or, having recently had non-empty such sets (in which case empty TCs are mandated for a bit to "purge stale information").

A case where an OLSRv2-router will not send TCs would, for example, be with MPR_WILLING == WILL_NEVER. And a case where it likely would not would be a router with WILL_NEVER+1, in a dense network.

>> Again, this misunderstanding is fundamental to whether the protocol will interwork with basic OLSRv2.
> 

Gotta consider this, at least, these ways:

"Will the presence of an OLSRv2 router in an OLSRv2-MP network break the -MP network"? 

"Will the presence of an OLSRv2-MP router in an OLSRv2 network break the OLSRv2 network"?

"Will an OLSRv2-MP router be able to function in an OLSRv2 network"?

"Will an OLSRv2 router be able to function in an OLSRv2-MP network"?

And then, of course, what happens if it's not "a single" but "a bunch of" ....

Thomas

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 20 Oct 2015 10:56:53 -0400

All,

Based on this discussion, and an email or two between myself and Justin and
Ulrich, here's the plan going forward:

I've just moved the document back to "WG Document" state. I think there is
general agreement that there are issues to be addressed, and that the doc
isn't yet ready for publication. We have a good discussion going here on
the list; hopefully that discussion will lead to a resolution on all
issues. At that point, we can reissue WGLC when the WG consensus indicates
that the doc is ready.

Other opinions? Questions?  Flames?

Regards,
Stan

On Tue, Oct 20, 2015 at 10:25 AM, Thomas Clausen <[email-masked]>
wrote:

>> 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.
>>
>> conditions, which may not apply.
>>
>
> Specifically, a TC is mandatory only if having a non-empty MPR-selector
> set, or a non-empty Attached Network set -- or, having recently had
> non-empty such sets (in which case empty TCs are mandated for a bit to
> "purge stale information").
>
> A case where an OLSRv2-router will not send TCs would, for example, be
> with MPR_WILLING == WILL_NEVER. And a case where it likely would not would
> be a router with WILL_NEVER+1, in a dense network.
>
>> 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.
>>
>
>> (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.)
>>
>
> [snip]

---

From: Christopher Dearlove <[email-masked]>
Date: Tue, 20 Oct 2015 16:24:03 +0100

That sounds like the right plan to me.

> On 20 Oct 2015, at 15:56, Stan Ratliff <[email-masked]> wrote:
> 
> All, 
> 
> Based on this discussion, and an email or two between myself and Justin and Ulrich, here's the plan going forward: 
> 
> I've just moved the document back to "WG Document" state. I think there is general agreement that there are issues to be addressed, and that the doc isn't yet ready for publication. We have a good discussion going here on the list; hopefully that discussion will lead to a resolution on all issues. At that point, we can reissue WGLC when the WG consensus indicates that the doc is ready. 
> 
>> On Tue, Oct 20, 2015 at 10:25 AM, Thomas Clausen <[email-masked]> wrote:
>> Just two quick points...
>>

---

From: Jiazi YI <[email-masked]>
Date: Tue, 20 Oct 2015 22:00:08 +0200

Thanks very much, Stan.

I agree with the decision, and am happy to work with the WG to have the
issues resolved.

cheers

Jiazi

On Tue, Oct 20, 2015 at 4:56 PM, Stan Ratliff <[email-masked]> wrote:

> All,
>
> Based on this discussion, and an email or two between myself and Justin
> and Ulrich, here's the plan going forward:
>