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

From: Christopher Dearlove <[email-masked]>
Date: Mon, 13 Jun 2016 22:53:01 +0100

I’v looked at draft -09, and I think it still needs work. I have some followups from previous comments, some new comments, and some editorial comments that I didn’t get round to making last time. And this may not be complete, but I’m up against the too short one week limit set. (I’m afraid we just aren’t getting given the necessary time in this group. And I seem to be the only one commenting.)

Section 1.1, fifth bullet, “very important”. To whom? Not justified. And should make it clear this applies to FEC applied across packets, not within a packet.

Page 4, third bullet, why discuss hop count? OLSRv2 is not hop count limited, it’s not even an explicit special case.

Page 5, second bullet. How does FEC help with packet re-ordering?

Page 5, fourth bullet, add “with” after “experiment”.

Page 6, first paragraph. I still disagree with characterising as low data rate links. At most the protocol multiplies capacity by a small factor, not the orders pf magnitude that link capacities span.

RFC0791, I think omitting the 0 is usual style.

Section 4, first paragraph, not requires, perhaps uses.

The reactive approach in particular has interactions with IP. The requirements this protocol imposes on IP need to be documented. (This point was made about AODVv2, it applies here - the interactions aren’t identical, but need to be specified.

MAX_SRC_HOPS - explain 11.

CUTOFF_RATIO - why strictly greater than one? Should work equal to one.

Section 6.1.1, last word, messages.

Section 7, capitalise Base.

Section 7.1. No need for OLSR in element names, never used anywhere else. Usual OLSRv2 style is SR_time without valid. Also SR_orig_addr (we are careful about usage).

Delete “it” in multiple element definitions after -

PT_… Explain n. Note that n may not be same in all cases.

PT_… What about hop count? Elsewhere in OLSRv2 we record that as well (e.g Routing Set).

Various places, delete “the” before Section.

Still no discussion of advertised addresses, should they be encouraged in TC messages. Except SR required TC messages, see previous proposal on strongly recommending against them. I can’t see that added.

Section 8.2 Setting what should be SR_orig_addr, add address after originator.

A major omission is discussion of expiry of new Tuples without expiry times. If proactive you can (but don’t) discuss when supporting sets change. If reactive it’s rather a mess (a reason I dislike the reactive mechanism). When to discard? When to recreate? If dependent on packet flow then that’s another interaction with IP to document - and implement.

You could when acting reactively forward by usual means in all cases while waiting.

The actual packet forwarding by round-robin is an IP process, not this protocol. Needs to not be buried in 8.4. And if it’s an IP process, why mandate exactly how it’s used?

Page 12, second bullet. How is this information known? There’s no signalling that includes it.

Capitalise all instances of Tuple for consistency.

Page 13. Brutally is not really appropriate language.

Section 8.5.2, I haven’t had time to review this.

Section 9, delete track after experimental.

Section 9, related to not reviewing 8.5.2, it’s not clear how the final bullet points arise. And what does “tend to” mean?

Section 10, not reviewed.

Appendices, not reviewed.

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 13 Jun 2016 18:38:01 -0400

Chris,

The 1-week WGLC was predicated on the thought that we had basically
concluded - that your issues had been addressed, and therefore, what was
needed was a "once-over" check. Apparently, that's not the case.

Having said that, the desire is not to set unreasonable timeframes, but to
make progress, and produce a quality document. So, if the conversation and
revisions take more than the 1-week period, so be it. Let's get it right.

Regards,
Stan

On Mon, Jun 13, 2016 at 5:53 PM, Christopher Dearlove <
[email-masked]> wrote:

> I’v looked at draft -09, and I think it still needs work. I have some
> followups from previous comments, some new comments, and some editorial
> comments that I didn’t get round to making last time. And this may not be
> complete, but I’m up against the too short one week limit set. (I’m afraid
> we just aren’t getting given the necessary time in this group. And I seem
> to be the only one commenting.)
>
> Section 1.1, fifth bullet, “very important”. To whom? Not justified. And
> should make it clear this applies to FEC applied across packets, not within
> a packet.
>
> Page 4, third bullet, why discuss hop count? OLSRv2 is not hop count
> limited, it’s not even an explicit special case.
>
> Page 6, first paragraph. I still disagree with characterising as low data
> rate links. At most the protocol multiplies capacity by a small factor, not
> the orders pf magnitude that link capacities span.
>
> The reactive approach in particular has interactions with IP. The
> requirements this protocol imposes on IP need to be documented. (This point
> was made about AODVv2, it applies here - the interactions aren’t identical,
> but need to be specified.
>
> Section 7.1. No need for OLSR in element names, never used anywhere else.
> Usual OLSRv2 style is SR_time without valid. Also SR_orig_addr (we are
> careful about usage).
>
> Still no discussion of advertised addresses, should they be encouraged in
> TC messages. Except SR required TC messages, see previous proposal on
> strongly recommending against them. I can’t see that added.
>
> A major omission is discussion of expiry of new Tuples without expiry
> times. If proactive you can (but don’t) discuss when supporting sets
> change. If reactive it’s rather a mess (a reason I dislike the reactive
> mechanism). When to discard? When to recreate? If dependent on packet flow
> then that’s another interaction with IP to document - and implement.
>
> The actual packet forwarding by round-robin is an IP process, not this
> protocol. Needs to not be buried in 8.4. And if it’s an IP process, why
> mandate exactly how it’s used?
>
> Section 9, related to not reviewing 8.5.2, it’s not clear how the final
> bullet points arise. And what does “tend to” mean?
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 14 Jun 2016 08:43:52 +0000

The problem with one week is that it’s really easy to just not have time in it. (It’s quite easy even for longer, but really easy for one week.) If you do the timezone calculation, you’ll see how I squeezed it in.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

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 Stan Ratliff
Sent: 13 June 2016 23:38
To: Christopher Dearlove
Cc: MANET IETF
Subject: Re: [manet] draft-ietf-olsrv2-multipath-09

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

Chris,
The 1-week WGLC was predicated on the thought that we had basically concluded - that your issues had been addressed, and therefore, what was needed was a "once-over" check. Apparently, that's not the case.
Having said that, the desire is not to set unreasonable timeframes, but to make progress, and produce a quality document. So, if the conversation and revisions take more than the 1-week period, so be it. Let's get it right.
Regards,
Stan

On Mon, Jun 13, 2016 at 5:53 PM, Christopher Dearlove <[email-masked]<mailto:[email-masked]>> wrote:
I’v looked at draft -09, and I think it still needs work. I have some followups from previous comments, some new comments, and some editorial comments that I didn’t get round to making last time. And this may not be complete, but I’m up against the too short one week limit set. (I’m afraid we just aren’t getting given the necessary time in this group. And I seem to be the only one commenting.)

_______________________________________________
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: Jiazi YI <[email-masked]>
Date: Wed, 15 Jun 2016 00:03:57 +0200

Hi Stan, Chris:

firstly, thanks very much for the comments and reply.

On Tue, Jun 14, 2016 at 12:38 AM, Stan Ratliff <[email-masked]>
wrote:

> needed was a "once-over" check.
>

I kinda have the same impression because we didn't get much feedback
several days after we replied Chris' post and released a -09alpha revision
on the mailing list.
But of course, we all have other work to do, so it's totally
understandable.

> Apparently, that's not the case.
>

sure

We will make further updates based on the comments received, and provide a
detailed reply.

cheers

Jiazi

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 20 Jun 2016 13:56:06 +0000

One followup to that. I indicated I didn't think a reference of the form [RFC0791], rather than [RFC791] was usual. I'm still not sure of that. But a (high reputation) book I'm currently reading, and the last ID (but not RFC) that I just looked at do the same. Ultimately it will be down to the RFC Editor, but it's probably possible to check recent RFCs to see what the style is. This is of course right at the editorial (not critical) end of the comment spectrum.

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

www.baesystems.com/ai

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Christopher Dearlove
Sent: 13 June 2016 22:53
To: MANET IETF
Subject: [manet] draft-ietf-olsrv2-multipath-09

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

---

From: Jiazi YI <[email-masked]>
Date: Mon, 20 Jun 2016 16:19:19 +0200

Dear Chris,

Thanks very much for your detailed review. I have updated the draft
according to your comments.

Please check our reply inline.  A preliminary draft is also attached.

> should make it clear this applies to FEC applied across packets, not within

removed "very important" to make it more neutral. Clarified that it's FEC
across packets.

> limited, it’s not even an explicit special case.

removed the text related to hop count. We agree that hop count is infamous
:)

> Page 5, second bullet. How does FEC help with packet re-ordering?

Normally, the packets are coded in different "blocks" and those blocks are
transmitted in different paths. The arriving order of those "blocks" is
less important.

<snip>

> the orders pf magnitude that link capacities span.

We won't claim that there will be orders of magnitude that link capacities
span, but it would be beneficial to have aggregated throughput and load
balancing.

So what do you think of:

MP-OLSRv2 is designed for networks with dynamic topology by avoiding single
route failure. It can also provide higher aggregated throughput and load
balancing, which is beneficial for low data rate links.

> RFC0791, I think omitting the 0 is usual style.

hmm... actually, the 0 is generated automatically by xml2rfc, as we simply
used the reference to bibxml:

in the reference, we put:

<references title="Normative References">
...
   &RFC791;
...
</references>

and in the begin of the document, we put:

<!ENTITY RFC791 SYSTEM "
http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml">

then we got RFC0791 in the draft, because in the xml link provided by IETF,
it's

        <reference anchor="RFC0791" target="
http://www.rfc-editor.org/info/rfc791">

<snip>

> but need to be specified.

We added the text:

*In the reactive approach, a multi-path algorithm is invoked on demand,
i.e., only when there is a datagram to be sent from the source to the
destination, and there is no available Routing Tuple in the Multi-path
Routing Set. This requires the IP to trigger the multi-path calculation
specified in Section 8.5 when no Multi-path Routing Tuple is available.*

Based on our experience, this is enough. Unlike AODVv2, which needs to wait
for the route discovery), no buffering is required for olsrv2-multipath.

> MAX_SRC_HOPS - explain 11.

this is due to the limit of IPv4 header length. Explained in the draft.

> CUTOFF_RATIO - why strictly greater than one? Should work equal to one.

Setting CUTOFF_RATIO to one means looking for disjoint equal length paths.
If we are not using hop-count as metric type, it would be rare to get two
equal metric paths.
We modified the text to "equal to or greater than one", with a note "Note
that setting the value to 1 means looking for equal length paths, which may
not be possible in some networks. "

<snip>

> PT_… What about hop count? Elsewhere in OLSRv2 we record that as well (e.g

Actually, the number of the items in the array PT_address[1...n] already
gives the hop count -- is it necessary to repeat the information with an
additional field? It is not used anyways.

<snip>

> strongly recommending against them. I can’t see that added.

hmmm... in the text, we now have:

Please note that the TC message generation based on SR_TC_INTERVAL *does
not replace the ordinary TC message generation specified in [RFC7181] and
does not carry any address.* This is due to the fact that not all routers
will generate TC messages based on OLSRv2. The TC generation based on
SR_TC_INTERVAL serves for those routers to advertise SOURCE_ROUTE TLV so
that the other routers can be aware of the source-route enabled routers so
as to be used as destinations of multipath routing. The SR_TC_INTERVAL is
set to a longer value than TC_INTERVAL.

it should be OK, no? Well, it's probably more accurate by saying "*does not
carry any advised address*", because there will be at least originator
address.

> change.

If reactive it’s rather a mess (a reason I dislike the reactive mechanism).
> When to discard? When to recreate? If dependent on packet flow then that’s
> another interaction with IP to document - and implement.

The update of the the Multi-path routing set is described in section 8.6.
The expiry timers are removed since -07 based on the comments received. One
of the reasons is to be consistent with the OLSRv2 routing set, in which no
expiry timer is used.
Generally speaking, in proactive mode, it follows the same mechanism as
OLSRv2: when ever there is a need to update the OLSRv2 routing set, the
multi-path routing set is updated.
In reactive mode, all the Multi-path routing tuples are removed when the
"topology graph" is changed.  The new tuples are recreated "on-demand".

> mandate exactly how it’s used?

Choosing which path to put in the source routing header is olsrv2-multipath
specific, because there are multiple of them. Of course, using round-robin
is not mandatory -- using other schedulers won't impact the compatibility.
Actually, we put it as one of the experiment points also:

>
>
>
> * Different path-selection schedulers.  By default, Round-Robin
> scheduling is used to select a path to be used for datagrams.  In      some
> scenarios, weighted scheduling can be considered: for      example, the
> paths with lower metrics (i.e., higher quality) can      transfer more
> datagrams compared to paths with higher metrics.*

> signalling that includes it.

The second bullet was:

   o  If the length of the path (n) is greater than MAX_SRC_HOPS, only
      the "key" routers in the path are kept.  The key routers can be
      chosen based on the capacity of the routers (e.g., battery life)
      or the router's willingness in forwarding data.  If no such
      information is available, the key routers are uniformly chosen in
      the path.

The point we want to make is: if there is such information available (based
on metrics or other extensions), it can be used. If no, then choose
uniformly. We rephrased the text a bit:

*  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. If further information such as capacity of
the routers (e.g., battery life) or the routers' willingness in forwarding
data is available, the routers with higher capacity and willingness are
preferred.*

<snip>

> bullet points arise. And what does “tend to” mean?

Those parameters defines different possible settings of multiple paths to
be calculated by using different punish functions.
We added more precise text for this part.

Again, we appreciate your review. If you have any further comments, please
let us know.

regards

Jiazi

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 20 Jun 2016 15:56:01 +0000

Comments below.

Short version, still some points I think can be improved. Down to one sticking point, on deciding on how to handle changes to, and cessation of, the reactive set. (Longer text below.) I think this is a real issue. Take a look at what you do in your implementation - now see if someone could work out to do that from the text. I don’t think they can.

From: manet [mailto:[email-masked]] On Behalf Of Jiazi YI
Sent: 20 June 2016 15:19
To: Christopher Dearlove
Cc: MANET IETF
Subject: Re: [manet] draft-ietf-olsrv2-multipath-09

*** WARNING ***

Dear Chris,

Thanks very much for your detailed review. I have updated the draft according to your comments.

On Mon, Jun 13, 2016 at 11:53 PM, Christopher Dearlove <[email-masked]<mailto:[email-masked]>> wrote:
I’v looked at draft -09, and I think it still needs work. I have some followups from previous comments, some new comments, and some editorial comments that I didn’t get round to making last time. And this may not be complete, but I’m up against the too short one week limit set. (I’m afraid we just aren’t getting given the necessary time in this group. And I seem to be the only one commenting.)

removed "very important" to make it more neutral. Clarified that it's FEC across packets.

removed the text related to hop count. We agree that hop count is infamous :)

C<D> Though it is the one case where CUTOFF_RATIO equal to one might make sense.

Normally, the packets are coded in different "blocks" and those blocks are transmitted in different paths. The arriving order of those "blocks" is less important.

CMD> I still don’t see how it helps with packet re-ordering.

<snip>

We won't claim that there will be orders of magnitude that link capacities span, but it would be beneficial to have aggregated throughput and load balancing.

So what do you think of:

MP-OLSRv2 is designed for networks with dynamic topology by avoiding single route failure. It can also provide higher aggregated throughput and load balancing, which is beneficial for low data rate links.

CMD> Still not convinced by the phrase low data rate links. The issues are ones of load relative to network capacity, and in particular if there are underutilised parts of the network. Plus of course a redundancy issue if packets do not all need to arrive. These can all occur in high data rate networks as much as low data rate ones.

hmm... actually, the 0 is generated automatically by xml2rfc, as we simply used the reference to bibxml:

<!ENTITY RFC791 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml">

then we got RFC0791 in the draft, because in the xml link provided by IETF, it's

        <reference anchor="RFC0791" target="http://www.rfc-editor.org/info/rfc791">

CMD> I stand corrected. Though it will be interesting to see what happens in another 2000 RFCs time. Which won’t be long.

<snip>

We added the text:

In the reactive approach, a multi-path algorithm is invoked on demand, i.e., only when there is a datagram to be sent from the source to the destination, and there is no available Routing Tuple in the Multi-path Routing Set. This requires the IP to trigger the multi-path calculation specified in Section 8.5 when no Multi-path Routing Tuple is available.

Based on our experience, this is enough. Unlike AODVv2, which needs to wait for the route discovery), no buffering is required for olsrv2-multipath.

CMD> As an editorial comment “the IP” doesn’t real right. The IP something, or IP.

Setting CUTOFF_RATIO to one means looking for disjoint equal length paths. If we are not using hop-count as metric type, it would be rare to get two equal metric paths.
We modified the text to "equal to or greater than one", with a note "Note that setting the value to 1 means looking for equal length paths, which may not be possible in some networks. "

<snip>

Actually, the number of the items in the array PT_address[1...n] already gives the hop count -- is it necessary to repeat the information with an additional field? It is not used anyways.

CMD> That it’s there could be called out. It gets used in OLSRv2 as a suggested tie-breaker, and some tools might use it. I thought I’d made a comment to say what n is, which I don’t see here. This can combine with that,

<snip>

Please note that the TC message generation based on SR_TC_INTERVAL does not replace the ordinary TC message generation specified in [RFC7181] and does not carry any address. This is due to the fact that not all routers will generate TC messages based on OLSRv2. The TC generation based on SR_TC_INTERVAL serves for those routers to advertise SOURCE_ROUTE TLV so that the other routers can be aware of the source-route enabled routers so as to be used as destinations of multipath routing. The SR_TC_INTERVAL is set to a longer value than TC_INTERVAL.

it should be OK, no? Well, it's probably more accurate by saying "does not carry any advised address", because there will be at least originator address.

CMD> Yes, I’d add “neighbour” or even “advertised neighbour” before address. Or rather before addresses.

A major omission is discussion of expiry of new Tuples without expiry times. If proactive you can (but don’t) discuss when supporting sets change.
If reactive it’s rather a mess (a reason I dislike the reactive mechanism). When to discard? When to recreate? If dependent on packet flow then that’s another interaction with IP to document - and implement.

The update of the the Multi-path routing set is described in section 8.6. The expiry timers are removed since -07 based on the comments received. One of the reasons is to be consistent with the OLSRv2 routing set, in which no expiry timer is used.
Generally speaking, in proactive mode, it follows the same mechanism as OLSRv2: when ever there is a need to update the OLSRv2 routing set, the multi-path routing set is updated.
In reactive mode, all the Multi-path routing tuples are removed when the "topology graph" is changed.  The new tuples are recreated "on-demand".

CMD> OK, let’s think about that in the reactive case. (Proactive is easy, but it needs to be said, which it isn’t.) You want a set, you generate it on demand. There is a change to the Topology Graph. So do you recalculate the set? If not then you introduce a stutter, as the packets are flowing and the set disappears and you need to trigger it again. Which means monitoring for that throughout a flow, not just at its start. If you do (recalculate the set when the graph changes) how do you know when to stop calculating it? That depends on knowing when the flow stops. And “the Topology Graph changes” is more than is required - some changes to the graph would have no effect (for example the increase in metric of a link not being used). But it’s hard to specify. On this point (which changes) some sort of permissive wording to indicate that you can avoid making changes when you know they don’t matter is probably right. The when do you stop calculating question is more important - and needs text discussing it.

Choosing which path to put in the source routing header is olsrv2-multipath specific, because there are multiple of them. Of course, using round-robin is not mandatory -- using other schedulers won't impact the compatibility. Actually, we put it as one of the experiment points also:

 Different path-selection schedulers.  By default, Round-Robin
      scheduling is used to select a path to be used for datagrams.  In
      some scenarios, weighted scheduling can be considered: for
      example, the paths with lower metrics (i.e., higher quality) can
      transfer more datagrams compared to paths with higher metrics.

CMD> This is missing my point. It’s not the round-robin that matters, it’s that IP needs to do anything. That’s what needs not to be buried. Putting together a clear “what IP needs to do” section early on, perhaps in the applicability section, is needed.

The second bullet was:

The point we want to make is: if there is such information available (based on metrics or other extensions), it can be used. If no, then choose uniformly. We rephrased the text a bit:

  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. If further information such as capacity of the routers (e.g., battery life) or the routers' willingness in forwarding data is available, the routers with higher capacity and willingness are preferred.

CMD> Better.

<snip>

Those parameters defines different possible settings of multiple paths to be calculated by using different punish functions.
We added more precise text for this part.

CMD> Still need to read this - the revised version.

Again, we appreciate your review. If you have any further comments, please let us know.

regards

Jiazi

---

From: Jiazi YI <[email-masked]>
Date: Tue, 21 Jun 2016 00:41:44 +0200

Hi,

On Mon, Jun 20, 2016 at 5:56 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> Comments below.
>
>
>
> Short version, still some points I think can be improved. Down to one
> sticking point, on deciding on how to handle changes to, and cessation of,
> the reactive set. (Longer text below.) I think this is a real issue. Take a
> look at what you do in your implementation - now see if someone could work
> out to do that from the text. I don’t think they can.
>
>
>

we clarified this in the draft. Please check the our detailed reply below.

<snip>

> CMD> I still don’t see how it helps with packet re-ordering.

When FEC is applied, the encoder takes one or several packets and produce
several coded blocks (denoted block-1, block-2, ... block-n). Those blocks
are forwarded as IP datagrams in the disjoint paths. Because the encoded
blocks are unordered for FEC, the arriving order of the encoded blocks of
the same packet(s) doesn't really matter.

> MP-OLSRv2 is designed for networks with dynamic topology by avoiding
> single route failure. It can also provide higher aggregated throughput and
> load balancing, which is beneficial for low data rate links.
>
>
>
> CMD> Still not convinced by the phrase low data rate links. The issues are
> ones of load relative to network capacity, and in particular if there are
> underutilised parts of the network. Plus of course a redundancy issue if
> packets do not all need to arrive. These can all occur in high data rate
> networks as much as low data rate ones.
>
>
>

It makes sense. I'm OK with removing the text related to low data rate
links.

<snip>

> CMD> That it’s there could be called out. It gets used in OLSRv2 as a
> suggested tie-breaker, and some tools might use it. I thought I’d made a
> comment to say what n is, which I don’t see here. This can combine with that
>

Yes. we added some text on what "n" is.

<snip>

> If reactive it’s rather a mess (a reason I dislike the reactive
> CMD> OK, let’s think about that in the reactive case. (Proactive is easy,
> but it needs to be said, which it isn’t.) You want a set, you generate it
> on demand. There is a change to the Topology Graph. So do you recalculate
> the set?
>

No, at this point, we only clear the entire Multi-path Routing Set.

> If not then you introduce a stutter, as the packets are flowing and the
> set disappears and you need to trigger it again.
>

Yes, it necessary to trigger the calculation again. But the time required
is trivial, because this is only local: no additional message exchange with
other routers is required.

> Which means monitoring for that throughout a flow, not just at its start.
>

We don't actually have the concept "flow" in this extension. For each
datagram, yes, it's necessary to check if a tuple exist or not. There is no
much difference from checking the FIB for IP.

> If you do (recalculate the set when the graph changes) how do you know
> when to stop calculating it? That depends on knowing when the flow stops.
>
And “the Topology Graph changes” is more than is required - some changes to
> the graph would have no effect (for example the increase in metric of a
> link not being used). But it’s hard to specify.
>

For the moment, we simply take "the topology graph changes", because even
links that not used might matters: for example, the decrease in metric of a
not used metric that introduces a better path.
It's true that it's possible that it's more than required and could be
optimised in the future, but considering it's a reactive approach, I
believe it's acceptable.

On this point (which changes) some sort of permissive wording to indicate
> that you can avoid making changes when you know they don’t matter is
> probably right. The when do you stop calculating question is more important
> - and needs text discussing it.
>

> Choosing which path to put in the source routing header is
> olsrv2-multipath specific, because there are multiple of them. Of course,
> using round-robin is not mandatory -- using other schedulers won't impact
> the compatibility. Actually, we put it as one of the experiment points also:
>
>
>
>
>
>
>
> some scenarios, weighted scheduling can be considered: for       example,
> the paths with lower metrics (i.e., higher quality) can       transfer more
> CMD> This is missing my point. It’s not the round-robin that matters, it’s
> that IP needs to do anything. That’s what needs not to be buried. Putting
> together a clear “what IP needs to do” section early on, perhaps in the
> applicability section, is needed.
>
>
>

We added the following text in the applicability statement:

*MP-OLSRv2 supports two different, but interoperable multi-path calculation
approaches: proactive and reactive. In the proactive calculation, the paths
to all the destinations are calculated before needed. In the reactive
calculation, only the paths to desired destination(s) are calculated on
demand. The proactive approach requires more computational resources than
the reactive one. The reactive approach requires the IP forwarding plan to
trigger the multi-path calculation.*

*MP-OLSRv2 forwards datagrams using the source routing header. As there are
multiple paths to each destination, MP-OLSRv2 requires the IP forwarding
plan to be able to choose which source route to be put in the source
routing header based on the path scheduler defined by MP-OLSRv2. For IPv4
networks, implementation of loose source routing is required following
[RFC0791]. For IPv6 networks, implementation of strict source routing is
required following [RFC6554].*

As usual, an updated draft is attached, in case needed.

regards

Jiazi

---

From: Christopher Dearlove <[email-masked]>
Date: Tue, 21 Jun 2016 00:02:12 +0100

"Because the encoded blocks are unordered for FEC" is, at best, only applicable to some FEC methods, it's definitely not universal.

--  
Christopher Dearlove

> On 20 Jun 2016, at 23:41, Jiazi YI <[email-masked]> wrote:
> 
> Hi, 
> 
>> On Mon, Jun 20, 2016 at 5:56 PM, Dearlove, Christopher (UK) <[email-masked]> wrote:
>> Comments below.
>> 
>>  
>> 
> When FEC is applied, the encoder takes one or several packets and produce several coded blocks (denoted block-1, block-2, ... block-n). Those blocks are forwarded as IP datagrams in the disjoint paths. Because the encoded blocks are unordered for FEC, the arriving order of the encoded blocks of the same packet(s) doesn't really matter. 
>  
>>  
>> 
>> <snip>
>> 
> It makes sense. I'm OK with removing the text related to low data rate links. 
> 
> <snip>
>  
>> CMD> That it’s there could be called out. It gets used in OLSRv2 as a suggested tie-breaker, and some tools might use it. I thought I’d made a comment to say what n is, which I don’t see here. This can combine with that
>> 
> 
>> CMD> OK, let’s think about that in the reactive case. (Proactive is easy, but it needs to be said, which it isn’t.) You want a set, you generate it on demand. There is a change to the Topology Graph. So do you recalculate the set?
>> 
> 
>> If not then you introduce a stutter, as the packets are flowing and the set disappears and you need to trigger it again.
>> 
> 
> Yes, it necessary to trigger the calculation again. But the time required is trivial, because this is only local: no additional message exchange with other routers is required. 
>  
> We don't actually have the concept "flow" in this extension. For each datagram, yes, it's necessary to check if a tuple exist or not. There is no much difference from checking the FIB for IP. 
>  
>> If you do (recalculate the set when the graph changes) how do you know when to stop calculating it? That depends on knowing when the flow stops. 
>> 
>> And “the Topology Graph changes” is more than is required - some changes to the graph would have no effect (for example the increase in metric of a link not being used). But it’s hard to specify.
>> 
> 
> For the moment, we simply take "the topology graph changes", because even links that not used might matters: for example, the decrease in metric of a not used metric that introduces a better path.  
> It's true that it's possible that it's more than required and could be optimised in the future, but considering it's a reactive approach, I believe it's acceptable. 
> 
>> On this point (which changes) some sort of permissive wording to indicate that you can avoid making changes when you know they don’t matter is probably right. The when do you stop calculating question is more important - and needs text discussing it. 
>> 
>>  
>> 
>> 
> MP-OLSRv2 supports two different, but interoperable multi-path calculation approaches: proactive and reactive. In the proactive calculation, the paths to all the destinations are calculated before needed. In the reactive calculation, only the paths to desired destination(s) are calculated on demand. The proactive approach requires more computational resources than the reactive one. The reactive approach requires the IP forwarding plan to trigger the multi-path calculation.
> 
> MP-OLSRv2 forwards datagrams using the source routing header. As there are multiple paths to each destination, MP-OLSRv2 requires the IP forwarding plan to be able to choose which source route to be put in the source routing header based on the path scheduler defined by MP-OLSRv2. For IPv4 networks, implementation of loose source routing is required following [RFC0791]. For IPv6 networks, implementation of strict source routing is required following [RFC6554].
> 
> <draft-ietf-manet-olsrv2-multipath.txt>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 21 Jun 2016 08:39:40 +0000

Reed Solomon itself needs the bytes in order. Possibly a packaging of it may be able to cope.

From: Benoit Parrein [mailto:[email-masked]]
Sent: 21 June 2016 08:14
To: Christopher Dearlove
Cc: Jiazi YI; Dearlove, Christopher (UK); MANET IETF
Subject: Re: [manet] draft-ietf-olsrv2-multipath-09

*** 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>.
hi christopher
you are right. a reformulation seems to be necessary.
but most of fec methods (reed solomon, ldpc, mojette...) can decode in any order of reception (hopefully)
thanks for your comment
bparrein

Le 21 juin 2016 à 01:02, Christopher Dearlove <[email-masked]<mailto:[email-masked]>> a écrit :
"Because the encoded blocks are unordered for FEC" is, at best, only applicable to some FEC methods, it's definitely not universal.

--
Christopher Dearlove

On 20 Jun 2016, at 23:41, Jiazi YI <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

On Mon, Jun 20, 2016 at 5:56 PM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
Comments below.

<snip>

<snip>

So what do you think of:

<snip>

<snip>

regards

Jiazi

---

From: Benoît Parrein <[email-masked]>
Date: Tue, 21 Jun 2016 12:26:46 +0200

we talk about packet erasure coding there with an identifier of received 
packets. the bytes arrive in order and correctly (if they arrive). a 
reformulation about this point will be done.

cheers
bparrein

Le 21/06/2016 10:39, Dearlove, Christopher (UK) a écrit :
> *-- *
> *Christopher Dearlove
> **__________________________________________________________________________
> *
> *T*:  +44 (0)1245 242194  | *E: [email-masked] 
> <mailto:[email-masked]>
>
> www.baesystems.com/ai <http://www.baesystems.com/ai>
>
> *From:*Benoit Parrein [mailto:[email-masked]]
> *Sent:* 21 June 2016 08:14
> *To:* Christopher Dearlove
> *Cc:* Jiazi YI; Dearlove, Christopher (UK); MANET IETF
> *Subject:* Re: [manet] draft-ietf-olsrv2-multipath-09
>
> **** 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>.//
>
> hi christopher
>
> Le 21 juin 2016 à 01:02, Christopher Dearlove 
> <[email-masked] 
> <mailto:[email-masked]>> a écrit :
>
>     "Because the encoded blocks are unordered for FEC" is, at best,
>     only applicable to some FEC methods, it's definitely not universal.
>
>     -- 
>
>     Christopher Dearlove
>
>
>         On Mon, Jun 20, 2016 at 5:56 PM, Dearlove, Christopher (UK)
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>         Comments below.
>
>         Short version, still some points I think can be improved. Down
>         to one sticking point, on deciding on how to handle changes
>         to, and cessation of, the reactive set. (Longer text below.) I
>         think this is a real issue. Take a look at what you do in your
>         implementation - now see if someone could work out to do that
>         from the text. I don’t think they can.
>
>             Normally, the packets are coded in different "blocks" and
>             those blocks are transmitted in different paths. The
>             arriving order of those "blocks" is less important.
>
>         When FEC is applied, the encoder takes one or several packets
>         and produce several coded blocks (denoted block-1, block-2,
>         ... block-n). Those blocks are forwarded as IP datagrams in
>         the disjoint paths. Because the encoded blocks are unordered
>         for FEC, the arriving order of the encoded blocks of the same
>         packet(s) doesn't really matter.
>
>             <snip>
>
>                 Page 6, first paragraph. I still disagree with
>                 characterising as low data rate links. At most the
>                 protocol multiplies capacity by a small factor, not
>             We won't claim that there will be orders of magnitude that
>             link capacities span, but it would be beneficial to have
>             aggregated throughput and load balancing.
>
>             So what do you think of:
>
>             MP-OLSRv2 is designed for networks with dynamic topology
>             by avoiding single route failure. It can also provide
>             higher aggregated throughput and load balancing, which is
>             beneficial for low data rate links.
>
>             CMD> Still not convinced by the phrase low data rate
>             links. The issues are ones of load relative to network
>             capacity, and in particular if there are underutilised
>             parts of the network. Plus of course a redundancy issue if
>             packets do not all need to arrive. These can all occur in
>             high data rate networks as much as low data rate ones.
>
>             Actually, the number of the items in the array
>             PT_address[1...n] already gives the hop count -- is it
>             necessary to repeat the information with an additional
>             field? It is not used anyways.
>
>             CMD> That it’s there could be called out. It gets used in
>             OLSRv2 as a suggested tie-breaker, and some tools might
>             use it. I thought I’d made a comment to say what n is,
>             which I don’t see here. This can combine with that
>
>                 A major omission is discussion of expiry of new Tuples
>                 without expiry times. If proactive you can (but don’t)
>                 discuss when supporting sets change.
>
>                 If reactive it’s rather a mess (a reason I dislike the
>                 reactive mechanism). When to discard? When to
>                 recreate? If dependent on packet flow then that’s
>             The update of the the Multi-path routing set is described
>             in section 8.6. The expiry timers are removed since -07
>             based on the comments received. One of the reasons is to
>             be consistent with the OLSRv2 routing set, in which no
>             expiry timer is used.
>
>             Generally speaking, in proactive mode, it follows the same
>             mechanism as OLSRv2: when ever there is a need to update
>             the OLSRv2 routing set, the multi-path routing set is
>             updated.
>
>             In reactive mode, all the Multi-path routing tuples are
>             removed when the "topology graph" is changed.  The new
>             tuples are recreated "on-demand".
>
>             CMD> OK, let’s think about that in the reactive case.
>             (Proactive is easy, but it needs to be said, which it
>             isn’t.) You want a set, you generate it on demand. There
>             is a change to the Topology Graph. So do you recalculate
>             the set?
>
>             If not then you introduce a stutter, as the packets are
>             flowing and the set disappears and you need to trigger it
>             again.
>
>         Yes, it necessary to trigger the calculation again. But the
>         time required is trivial, because this is only local: no
>         additional message exchange with other routers is required.
>
>         We don't actually have the concept "flow" in this extension.
>         For each datagram, yes, it's necessary to check if a tuple
>         exist or not. There is no much difference from checking the
>         FIB for IP.
>
>             If you do (recalculate the set when the graph changes) how
>             do you know when to stop calculating it? That depends on
>             knowing when the flow stops.
>
>             And “the Topology Graph changes” is more than is required
>             - some changes to the graph would have no effect (for
>             example the increase in metric of a link not being used).
>             But it’s hard to specify.
>
>         For the moment, we simply take "the topology graph changes",
>         because even links that not used might matters: for example,
>         the decrease in metric of a not used metric that introduces a
>         better path.
>
>         It's true that it's possible that it's more than required and
>         could be optimised in the future, but considering it's a
>         reactive approach, I believe it's acceptable.
>
>             On this point (which changes) some sort of permissive
>             wording to indicate that you can avoid making changes when
>             you know they don’t matter is probably right. The when do
>             you stop calculating question is more important - and
>             needs text discussing it.
>
>
>                 The actual packet forwarding by round-robin is an IP
>                 process, not this protocol. Needs to not be buried in
>                 8.4. And if it’s an IP process, why mandate exactly
>                 how it’s used?
>
>             olsrv2-multipath specific, because there are multiple of
>             them. Of course, using round-robin is not mandatory --
>             using other schedulers won't impact the compatibility.
>                 / Different path-selection schedulers. By default,
>                 Round-Robin
>                       transfer more datagrams compared to paths with
>                 higher metrics./
>
>             CMD> This is missing my point. It’s not the round-robin
>             that matters, it’s that IP needs to do anything. That’s
>             what needs not to be buried. Putting together a clear
>             “what IP needs to do” section early on, perhaps in the
>         /MP-OLSRv2 supports two different, but interoperable
>         multi-path calculation approaches: proactive and reactive. In
>         the proactive calculation, the paths to all the destinations
>         are calculated before needed. In the reactive calculation,
>         only the paths to desired destination(s) are calculated on
>         demand. The proactive approach requires more computational
>         resources than the reactive one. The reactive approach
>         requires the IP forwarding plan to trigger the multi-path
>         calculation./
>
>         /MP-OLSRv2 forwards datagrams using the source routing header.
>         As there are multiple paths to each destination, MP-OLSRv2
>         requires the IP forwarding plan to be able to choose which
>         source route to be put in the source routing header based on
>         the path scheduler defined by MP-OLSRv2. For IPv4 networks,
>         implementation of loose source routing is required following
>         [RFC0791]. For IPv6 networks, implementation of strict source
>         routing is required following [RFC6554]./
>
>     [email-masked] <mailto:[email-masked]>

-- 
----------------
Benoît Parrein
Maître de Conférences (HDR)
Université de Nantes (Polytech Nantes), laboratoire IRCCyN
web: http://www.irccyn.ec-nantes.fr/~parrein/
tel: +33(0)240683050

---

From: Jiazi YI <[email-masked]>
Date: Tue, 21 Jun 2016 23:23:38 +0200

We will add some text to make it more precise.

best

Jiazi

On Tue, Jun 21, 2016 at 1:02 AM, Christopher Dearlove <
[email-masked]> wrote:

> "Because the encoded blocks are unordered for FEC" is, at best, only
> applicable to some FEC methods, it's definitely not universal.
>
> --
> Christopher Dearlove
>
>> Normally, the packets are coded in different "blocks" and those blocks
>> are transmitted in different paths. The arriving order of those "blocks" is
>> less important.
>>
>>
>>
>> We won't claim that there will be orders of magnitude that link
>> capacities span, but it would be beneficial to have aggregated throughput
>> and load balancing.
>>
>>
>>
>> So what do you think of:
>>
>>
>>
>> CMD> Still not convinced by the phrase low data rate links. The issues
>> are ones of load relative to network capacity, and in particular if there
>> are underutilised parts of the network. Plus of course a redundancy issue
>> if packets do not all need to arrive. These can all occur in high data rate
> And “the Topology Graph changes” is more than is required - some changes
>> to the graph would have no effect (for example the increase in metric of a
>> CMD> This is missing my point. It’s not the round-robin that matters,
>> it’s that IP needs to do anything. That’s what needs not to be buried.
>> Putting together a clear “what IP needs to do” section early on, perhaps in
>> the applicability section, is needed.
>>
>>
>>
>
> *MP-OLSRv2 supports two different, but interoperable multi-path
> calculation approaches: proactive and reactive. In the proactive
> calculation, the paths to all the destinations are calculated before
> needed. In the reactive calculation, only the paths to desired
> destination(s) are calculated on demand. The proactive approach requires
> more computational resources than the reactive one. The reactive approach
> requires the IP forwarding plan to trigger the multi-path calculation.*
>
> *MP-OLSRv2 forwards datagrams using the source routing header. As there
> are multiple paths to each destination, MP-OLSRv2 requires the IP
> forwarding plan to be able to choose which source route to be put in the
> source routing header based on the path scheduler defined by MP-OLSRv2. For
> IPv4 networks, implementation of loose source routing is required following

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 23 Jun 2016 09:39:20 +0000

Coincidentally, I was reading about IPv6 source routing, and the deprecation of RH0 in RFC 5095. RFC 6554 that you refer to claims to have resolved the security concerns that led to that deprecation. Part of that is that RFC 6554 is only defined as working in an RPL domain. Now that can probably be generalised to a MANET - but I don’t think you’ve done that, and so I think that needs doing.

I’m then left wondering if the security threat described in RFC 5095 applies to IPv4 source routing. (I’m afraid I haven’t had time to dig into this, the coincidence has only just happened, and I thought better to get an incomplete question out.) RFC 5095 doesn’t discuss IPv4 at all, but the basic problem (repeating an address in a source route as an attack) would appear to still apply. I haven’t understood yet how RFC 6554 avoids this. It’s possible that RFC 5095 doesn’t consider IPv4 on the basis that most people have given up on it, or just it wasn’t of interest to the authors.

At the minimum I think the draft needs to comment on extending RFC 6554 to MANETs not RPL domains. Ideally (this may or may not cause added security considerations) someone with a better knowledge of this area (practical as well as theoretical) will comment on the above.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiazi YI
Sent: 21 June 2016 22:24
To: Christopher Dearlove
Cc: Dearlove, Christopher (UK); MANET IETF
Subject: Re: [manet] draft-ietf-olsrv2-multipath-09

*** WARNING ***

best

Jiazi

On Tue, Jun 21, 2016 at 1:02 AM, Christopher Dearlove <[email-masked]<mailto:[email-masked]>> wrote:
"Because the encoded blocks are unordered for FEC" is, at best, only applicable to some FEC methods, it's definitely not universal.

--
Christopher Dearlove

<snip>

<snip>

So what do you think of:

<snip>

<snip>

regards

Jiazi

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 23 Jun 2016 13:49:50 +0000

Digging further, there was a draft-reitzel-ipv4-source-routing-is-evil-00 that pointed out that IPv4 source routing had exactly the same problems as the deprecated RH0 IPv6 source routing, and recommended deprecating that. But the draft never preceded further. I don’t know why. I have seen it indicated that most operators drop such packets, so maybe it wasn’t felt necessary.

As for why RFC 6554 avoids the RH0 problem, essentially it defines it away: “a RPL router drops datagrams that include multiple addresses assigned to any interfaces on that router to avoid forwarding loops” Note that’s not as simple as dropping datagrams with duplicate addresses, it also includes dropping datagrams with two addresses of the same interface - which only that router can do.

So, in order to use RFC 6554 source routing here, we need to (a) say that a required condition is that the MANET routers support RFC 6554, because that RFC itself only specifies this for RPL routers, and (b) that they must support the required features in particular the datagram suppression noted above.

But, I wouldn’t expect a typical router currently to do this, because it won’t be “an RPL router” - here input from people who have done this hands on would be useful, did they have to add this functionality?

And for IPv4, need (loose) source routing to be supported within the MANET, which again it may or may not be.

(Note that RFC 6554 source routing isn’t the same as RH0 source routing, because RFC 6554 source routing includes compression.)

From: manet [mailto:[email-masked]] On Behalf Of Dearlove, Christopher (UK)
Sent: 23 June 2016 10:39
To: Jiazi YI; Christopher Dearlove
Cc: MANET IETF
Subject: Re: [manet] draft-ietf-olsrv2-multipath-09

*** WARNING ***

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jiazi YI
Sent: 21 June 2016 22:24
To: Christopher Dearlove
Cc: Dearlove, Christopher (UK); MANET IETF
Subject: Re: [manet] draft-ietf-olsrv2-multipath-09

*** WARNING ***

best

Jiazi

--
Christopher Dearlove

<snip>

<snip>

So what do you think of:

<snip>

<snip>

regards

Jiazi

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Thu, 23 Jun 2016 14:02:29 +0000

Chris,

I see your point on RFC 6554. But didn’t we *just* go through an exercise with AODVv2 where that draft attempted to reference a RPL RFC, and the consensus of the WG was that this was a “terrible, awful thing that should not be done”?????

Regards,
Stan

From: manet [mailto:[email-masked]] On Behalf Of Dearlove, Christopher (UK)
Sent: Thursday, June 23, 2016 9:50 AM
To: MANET IETF <[email-masked]>
Subject: Re: [manet] draft-ietf-olsrv2-multipath-09

*** WARNING ***

*** WARNING ***

best

Jiazi

--
Christopher Dearlove

<snip>

<snip>

So what do you think of:

<snip>

<snip>

regards

Jiazi

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 23 Jun 2016 14:08:30 +0000

I think this is really a comment for Jiazi. I’m not suggesting adding a reference to RFC 6554, that reference is already in the draft.

I’m saying that if you reference RFC 6554, you’re referencing something that doesn’t apply unless and until you add some text to make it apply.

Whether that is a terrible awful thing that should not be done (not my words - in fact I don’t recall commenting on that aspect of AODVv2) is up to the community to judge.

But input from the people who have implemented this draft would be useful. Did they find RFC 6554 already in place? Already implemented and portable to in place? Had to write in from scratch? Didn’t actually use RFC 6554 but something else (e.g. deprecated RH0)? Only implemented for IPv4?

From: Ratliff, Stanley [mailto:[email-masked]]
Sent: 23 June 2016 15:02
To: Dearlove, Christopher (UK); MANET IETF
Subject: RE: [manet] draft-ietf-olsrv2-multipath-09

*** WARNING ***

Regards,
Stan

From: manet [mailto:[email-masked]] On Behalf Of Dearlove, Christopher (UK)
Sent: Thursday, June 23, 2016 9:50 AM
To: MANET IETF <[email-masked]<mailto:[email-masked]>>
Subject: Re: [manet] draft-ietf-olsrv2-multipath-09

*** WARNING ***

*** WARNING ***

best

Jiazi

--
Christopher Dearlove

<snip>

<snip>

So what do you think of:

<snip>

<snip>

regards

Jiazi

---

From: Jiazi YI <[email-masked]>
Date: Thu, 23 Jun 2016 23:24:45 +0200

Hi Chris, Stan:

It's good point that we need to add some text about applying RFC6554 to
MANET. We will make a proposal later.

Regarding the issues of "referencing an RPL RFC", the problem we have with
AODVv2 is very different from this.

AODVv2 tries to reference RFC6551, which defines a set of metric types and
it states

*     Low-Power and Lossy Networks (LLNs) have unique characteristics*
*     compared with traditional wired and ad hoc networks that require the*
*     specification of new routing metrics and constraints. *

as the first sentence in the abstract.

For olsrv2-multipath, it has a reference to RFC6554, which defines a source
routing header with address compression. Although it has "RPL" in its
title, the format itself is protocol-neutral. I would imagine if someone
want to implement DSR with IPv6, the RFC6554 would be a natural choice.
As we will restrict the header to be used only in foo-protocol routing
domain, there won't be any interoperability issue.
We can, of course, proposal another RFC and ask for new "IPv6 Routing Type"
to support source routing in IPv6 by just removing RPL-related clause in
RFC6554. But it would be the same packet format, except the "IPv6 Routing
Type" number --- personally, I don't think it's necessary.

I'm having Alvaro in cc also, because it's kind of cross WG issue.
Alvaro: Using source routing is not a rare case in IPv6. Only considering
MANET WG, there is DSR, and AODVv2 (although it's now off the charter) also
discussed possible extension with path accumulation.
Personally, I believe having a reference to RFC6554 should be OK, with some
explanations in the draft. Your advice would be appreciated.

cheers

Jiazi

On Thu, Jun 23, 2016 at 4:08 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> I think this is really a comment for Jiazi. I’m not suggesting adding a
> reference to RFC 6554, that reference is already in the draft.
>
>
>
> I’m saying that if you reference RFC 6554, you’re referencing something
> that doesn’t apply unless and until you add some text to make it apply.
>
>
>
> Whether that is a terrible awful thing that should not be done (not my
> words - in fact I don’t recall commenting on that aspect of AODVv2) is up
> to the community to judge.
>
>
>
> But input from the people who have implemented this draft would be useful.
> Did they find RFC 6554 already in place? Already implemented and portable
> to in place? Had to write in from scratch? Didn’t actually use RFC 6554 but
> something else (e.g. deprecated RH0)? Only implemented for IPv4?
>
>
>
> *-- *
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *__________________________________________________________________________
> *
> *From:* Ratliff, Stanley [mailto:[email-masked]]
> *Sent:* 23 June 2016 15:02
> *To:* Dearlove, Christopher (UK); MANET IETF
> *Subject:* RE: [manet] draft-ietf-olsrv2-multipath-09
>
>
>
>
>
> **** 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>.*
>
> Chris,
>
>
>
> I see your point on RFC 6554. But didn’t we **just** go through an
> exercise with AODVv2 where that draft attempted to reference a RPL RFC, and
> the consensus of the WG was that this was a “terrible, awful thing that
> should not be done”?????
>
>
>
> Regards,
>
> Stan
>
>
>
> *From:* manet [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Dearlove, Christopher (UK)
> *Sent:* Thursday, June 23, 2016 9:50 AM
> *To:* MANET IETF <[email-masked]>
> Digging further, there was a draft-reitzel-ipv4-source-routing-is-evil-00
> that pointed out that IPv4 source routing had exactly the same problems as
> the deprecated RH0 IPv6 source routing, and recommended deprecating that.
> But the draft never preceded further. I don’t know why. I have seen it
> indicated that most operators drop such packets, so maybe it wasn’t felt
> necessary.
>
>
>
> As for why RFC 6554 avoids the RH0 problem, essentially it defines it
> away: “a RPL router drops datagrams that include multiple addresses
> assigned to any interfaces on that router to avoid forwarding loops” Note
> that’s not as simple as dropping datagrams with duplicate addresses, it
> also includes dropping datagrams with two addresses of the same interface -
> which only that router can do.
>
>
>
> So, in order to use RFC 6554 source routing here, we need to (a) say that
> a required condition is that the MANET routers support RFC 6554, because
> that RFC itself only specifies this for RPL routers, and (b) that they must
> support the required features in particular the datagram suppression noted
> above.
>
>
>
> But, I wouldn’t expect a typical router currently to do this, because it
> won’t be “an RPL router” - here input from people who have done this hands
> on would be useful, did they have to add this functionality?
>
>
>
> (Note that RFC 6554 source routing isn’t the same as RH0 source routing,
> because RFC 6554 source routing includes compression.)
>
>
>
> *-- *
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *__________________________________________________________________________
> *
> *From:* manet [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Dearlove, Christopher (UK)
> *Sent:* 23 June 2016 10:39
> *To:* Jiazi YI; Christopher Dearlove
> *Cc:* MANET IETF
> *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 ******
> Coincidentally, I was reading about IPv6 source routing, and the
> deprecation of RH0 in RFC 5095. RFC 6554 that you refer to claims to have
> resolved the security concerns that led to that deprecation. Part of that
> is that RFC 6554 is only defined as working in an RPL domain. Now that can
> probably be generalised to a MANET - but I don’t think you’ve done that,
> and so I think that needs doing.
>
>
>
> I’m then left wondering if the security threat described in RFC 5095
> applies to IPv4 source routing. (I’m afraid I haven’t had time to dig into
> this, the coincidence has only just happened, and I thought better to get
> an incomplete question out.) RFC 5095 doesn’t discuss IPv4 at all, but the
> basic problem (repeating an address in a source route as an attack) would
> appear to still apply. I haven’t understood yet how RFC 6554 avoids this.
> It’s possible that RFC 5095 doesn’t consider IPv4 on the basis that most
> people have given up on it, or just it wasn’t of interest to the authors.
>
>
>
> At the minimum I think the draft needs to comment on extending RFC 6554 to
> MANETs not RPL domains. Ideally (this may or may not cause added security
> considerations) someone with a better knowledge of this area (practical as
> well as theoretical) will comment on the above.
>
>
>
> *-- *
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *__________________________________________________________________________
> *
> *From:* [email-masked] [mailto:[email-masked] <[email-masked]>]
> *On Behalf Of *Jiazi YI
> *Sent:* 21 June 2016 22:24
> *Cc:* Dearlove, Christopher (UK); MANET IETF
> *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>.*
>

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 23 Jun 2016 22:31:29 +0100

What I didn’t say was that this (the RFC 6554 packet discard as a security feature) is part of the “what IP needs to do to support this protocol” rather than being this protocol itself.

> On 23 Jun 2016, at 22:24, Jiazi YI <[email-masked]> wrote:
> 
> Hi Chris, Stan:
> 
> It's good point that we need to add some text about applying RFC6554 to MANET. We will make a proposal later. 
> 
> Regarding the issues of "referencing an RPL RFC", the problem we have with AODVv2 is very different from this. 
> 
> AODVv2 tries to reference RFC6551, which defines a set of metric types and it states 
> 
>      Low-Power and Lossy Networks (LLNs) have unique characteristics
>      compared with traditional wired and ad hoc networks that require the
>      specification of new routing metrics and constraints. 
> 
> For olsrv2-multipath, it has a reference to RFC6554, which defines a source routing header with address compression. Although it has "RPL" in its title, the format itself is protocol-neutral. I would imagine if someone want to implement DSR with IPv6, the RFC6554 would be a natural choice. 
> As we will restrict the header to be used only in foo-protocol routing domain, there won't be any interoperability issue. 
> We can, of course, proposal another RFC and ask for new "IPv6 Routing Type" to support source routing in IPv6 by just removing RPL-related clause in RFC6554. But it would be the same packet format, except the "IPv6 Routing Type" number --- personally, I don't think it's necessary.  
> 
> Alvaro: Using source routing is not a rare case in IPv6. Only considering MANET WG, there is DSR, and AODVv2 (although it's now off the charter) also discussed possible extension with path accumulation. 
> Personally, I believe having a reference to RFC6554 should be OK, with some explanations in the draft. Your advice would be appreciated. 
> 
> cheers
> 
> Jiazi
> 
> On Thu, Jun 23, 2016 at 4:08 PM, Dearlove, Christopher (UK) <[email-masked] <mailto:[email-masked]>> wrote:
> T:  +44 (0)1245 242194 <tel:%2B44%20%280%291245%20242194>  |  E: [email-masked] <mailto:[email-masked]>
> 
> From: Ratliff, Stanley [mailto:[email-masked] <mailto:[email-masked]>] 
> Sent: 23 June 2016 15:02
> 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>.
> 
> Chris,
> 
>  
> 
> From: manet [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Dearlove, Christopher (UK)
> To: MANET IETF <[email-masked] <mailto:[email-masked]>>
> T:  +44 (0)1245 242194 <tel:%2B44%20%280%291245%20242194>  |  E: [email-masked] <mailto:[email-masked]>
> 
> From: manet [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Dearlove, Christopher (UK)
> Sent: 23 June 2016 10:39
> 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 ***
> T:  +44 (0)1245 242194 <tel:%2B44%20%280%291245%20242194>  |  E: [email-masked] <mailto:[email-masked]>
> 
> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Jiazi YI
> Sent: 21 June 2016 22:24
> To: Christopher Dearlove
> 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>.
> 
> On Tue, Jun 21, 2016 at 1:02 AM, Christopher Dearlove <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On 20 Jun 2016, at 23:41, Jiazi YI <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi, 
> 
>  
> 
> On Mon, Jun 20, 2016 at 5:56 PM, Dearlove, Christopher (UK) <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Comments below.
> 
>  
> 
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
> 
>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 23 Jun 2016 23:10:13 +0000

On 6/23/16, 5:24 PM, "[email-masked]<mailto:[email-masked]> on behalf of Jiazi YI" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Jiazi:

Hi!

Disclaimer:  I'm jumping in the middle of the thread here...

...

I don't think that "referencing RFC6554" is as simple as referencing any other RFC.  First of all, there's the (already mentioned) issue of the RPL-specific language in RFC6554, which means that (potentially) extensive updates would have to be put in place to clearly have MANET (OLSR or otherwise) routers apply it properly.

Then there is the huge issue of RH0 being deprecated deprecated [rfc5095].  RFC6554 went through significant discussion at the time (not just within roll, but in 6man/v6ops, etc.) because it is basically resurrecting functionality that the IETF already said shouldn't be.  Clearly, RFC6554 defies specific RPL-related behaviors, for example "RPL routers implement a strict source route policy where each and every IPv6 hop between the source and destination of the source route is specified within the SRH" -- IOW, roll clearly defined use cases and conditions that required source routing and could be controlled in the network.  I think that the use cases and justifications for a MANET network are different.  I don't think that putting MANET-specific language as an update to RFC6554 would be enough for the IETF to approve - it feels to me like trying to run around the process.

Roll is not the only WG that has successfully justified needs for source routing functionality.  The spring WG is in the process of also adding IPv6 extensions for source routing [1] [2] -- it justified the need and (similar to RFC6554) includes segment routing-speficic behavior to reduce concerns about rfc5095.

I believe that to add source routing functionality to anything new (beyond rpl and segment routing networks), we will have to go through the same process: justify the functionality/needs and work with 6man on the extension.

If I read this thread correctly, part of the reason for referencing RFC6554 is to use the format and other functionality (compression?) in MANET networks.  I don't see (provided the right justification) a reason for not reuse the packets and compression mechanisms specified there (if that is what MANET needs/wants).

Having said all that, I think that a good first step would be to talk to the 6man Chairs about the need/intent.  They will probably want clear justification (use cases) and, eventually, the specification (which I think can point to RFC6554 for packet format, etc).  I think both could be covered I a single document.  I suggest having the WG Chairs do that initial approach.

Now to a slightly separate topic.  Even though the WG (in the updated charter [3]) is responsible to work on "maintenance of OLSR", this work really goes beyond my definition of "maintenance" because of the significant effort that may be needed (not just in writing, but cross-WG coordination, etc.).  I really want the WG to focus on the specifically chartered items and hope that we can complete them within the milestone dates.  To be clear: I'm not asking you not to do this work, I want the WG Chairs to prioritize appropriately and this work (draft-ietf-olsrv2-multipath) being currently tagged as Experimental doesn't seem to raise in priority to me [*].

Thanks!

Alvaro.

[1] https://tools.ietf.org/html/draft-ietf-spring-ipv6-use-cases
[2] https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header
[3] https://datatracker.ietf.org/doc/charter-ietf-manet/

[*] I doubt that 6man will want to put in an extension (even if it's already defied in RFC6554) for an Experimental effort.  I of course may be wrong and the Experimental nature may make it easier in their eyes to simply reference RFC6554.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 24 Jun 2016 08:55:40 +0000

While I don't have anything concrete to bring to the WG at this time, and might never, in discussion on the charter the chairs gave the impression, to me at least, that OLSRv2 maintenance didn't exclude new items.

How much any such new item would impact other work would, I agree, be an issue. Here we do (at the last minute, and partly by chance - though someone outside the WG would probably have spotted the issue later) have something that's cross-WG and is therefore a bigger issue. But I would hope that something that is self-contained would be acceptable. And while I've had my issues with this draft, they've been about making it better (in some places, good enough).

From: Alvaro Retana (aretana) [mailto:[email-masked]]
Sent: 24 June 2016 00:10
To: Jiazi YI; Dearlove, Christopher (UK); Ratliff, Stanley
Cc: MANET IETF; Justin Dean
Subject: Re: [manet] draft-ietf-olsrv2-multipath-09

*** WARNING ***

Jiazi:

Hi!

...

Thanks!

Alvaro.

---

From: Jiazi YI <[email-masked]>
Date: Fri, 24 Jun 2016 11:16:07 +0200

Hi Alvaro:

Thanks very much for your advices.

<snip>

> If I read this thread correctly, part of the reason for referencing
> RFC6554 is to use the format and other functionality (compression?) in
> MANET networks.  I don't see (provided the right justification) a reason
> for not reuse the packets and compression mechanisms specified there (if
> that is what MANET needs/wants).
>

Yes, correct.

>
>
> Having said all that, I think that a good first step would be to talk to
> the 6man Chairs about the need/intent.  They will probably want clear
> justification (use cases) and, eventually, the specification (which I think
> can point to RFC6554 for packet format, etc).  I think both could be
> covered I a single document.  I suggest having the WG Chairs do that
> initial approach.
>

We will discuss with the WG chairs to see how to communicate with the 6man
chairs and ask for their advices.

>
>
> Now to a slightly separate topic.  Even though the WG (in the updated
> charter [3]) is responsible to work on "maintenance of OLSR", this work
> really goes beyond my definition of "maintenance" because of the
> significant effort that may be needed (not just in writing, but cross-WG
> coordination, etc.).  I really want the WG to focus on the specifically
> chartered items and hope that we can complete them within the milestone
> dates.  To be clear: I'm not asking you not to do this work, I want the WG
> Chairs to prioritize appropriately and this work
> (draft-ietf-olsrv2-multipath) being currently tagged as Experimental
> doesn't seem to raise in priority to me [*].
>

The multipath routing in MANET has attracted lots of interests in academia.
olsrv2-multipath has already several implementations, verified in both
field tests and simulations.  We believe now it's the right time to have it
clearly specified and request for more experience from the community --
that's why we prudently aim for experimental track.

Of course, As a WG, the priority is achieving the milestones, but I don't
think it would preclude having extensions to OLSRv2, which is part of the
charter also. In fact, IIRC, during the recharter discussion, several
extensions for OLSRv2 were proposed. The WG finished with using the term
"The MANET WG is responsible for the *maintenance* of OLSRv2 [RFC 7181],
NHDP [RFC 6130] and the Generalized MANET Packet/Message Format [RFC5444],
and their *extensions*.", instead of listing possible extensions
explicitly.

regards

Jiazi

> [*] I doubt that 6man will want to put in an extension (even if it's
> already defied in RFC6554) for an Experimental effort.  I of course may be
> wrong and the Experimental nature may make it easier in their eyes to
> simply reference RFC6554.
>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 24 Jun 2016 11:40:24 +0000

On 6/24/16, 5:16 AM, "[email-masked]<mailto:[email-masked]> on behalf of Jiazi YI" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi!

Of course, As a WG, the priority is achieving the milestones, but I don't think it would preclude having extensions to OLSRv2, which is part of the charter also. In fact, IIRC, during the recharter discussion, several extensions for OLSRv2 were proposed. The WG finished with using the term "The MANET WG is responsible for the maintenance of OLSRv2 [RFC 7181],
NHDP [RFC 6130] and the Generalized MANET Packet/Message Format [RFC5444],
and their extensions.", instead of listing possible extensions explicitly.

As I said: "To be clear: I'm not asking you not to do this work, I want the WG Chairs to prioritize appropriately..."  That's it!  If the WG wants to take this work on, I don't have a problem - it is with in the charter.  Let's just not forget about the other work we have...

The second part of the point I tried to make was, I think, more important:  extensions to IPv6 are not within the manet WG's charter, but they belong to 6man.  It would probably be more effective if the source routing work was in the Standards Track.  I'm assuming that Multi-path is just one use case for source routing, but there are probably more.  I also wrote: "[*] I doubt that 6man will want to put in an extension (even if it's already defied in RFC6554) for an Experimental effort.  I of course may be wrong and the Experimental nature may make it easier in their eyes to simply reference RFC6554."

Note that what I'm suggesting is not to put the Multi-path work in the Standards Track (that is a separate discussion) - but to justify source routing for MANET networks as a larger need (including multi-path, but bigger than that).

Thanks!

Alvaro.

---

From: Jiazi YI <[email-masked]>
Date: Fri, 1 Jul 2016 01:05:24 +0200

Hi,

Regarding the use of source routing header in IPv6 and the reference to
RFC6554, we have contacted the 6man chairs.

The answer from Ole (one of the chairs) was that he didn't see why it can't
be used, and suggested the experimental code points of the IPv6 Routing
Types.

So in the next revision of the olsrv2-multipath, we will:

       - Use the experimental code point of IPv6 Routing Types for SRH.

       - Have a well scoped reference to RFC6554: for example, for SRH
format, use section 3, for SRH processing, use section 4, etc. Other than
that, the olsrv2-multipath would be self-contained.

       - Have a well defined scope of the use of the SRH: only the
OLSRv2/MP-OLSRv2 routing domain.

Any other comments on the approach?

best

Jiazi

On Fri, Jun 24, 2016 at 1:40 PM, Alvaro Retana (aretana) <[email-masked]>
wrote:

> On 6/24/16, 5:16 AM, "[email-masked] on behalf of Jiazi YI" <
> [email-masked] on behalf of [email-masked]> wrote:
>
> Hi!
>
> As I said: "To be clear: I'm not asking you not to do this work, I want
> the WG Chairs to prioritize appropriately…"  That's it!  If the WG wants to
> take this work on, I don't have a problem — it is with in the charter.
> Let's just not forget about the other work we have…
>
> The second part of the point I tried to make was, I think, more important:
>  extensions to IPv6 are not within the manet WG's charter, but they
> belong to 6man.  It would probably be more effective if the source routing
> work was in the Standards Track.  I'm assuming that Multi-path is just one
> use case for source routing, but there are probably more.  I also wrote:
> "[*] I doubt that 6man will want to put in an extension (even if it's
> simply reference RFC6554."
>
> Note that what I'm suggesting is not to put the Multi-path work in the
> Standards Track (that is a separate discussion) — but to justify source
> routing for MANET networks as a larger need (including multi-path, but
> bigger than that).
>
> Thanks!
>
> Alvaro.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 1 Jul 2016 05:32:54 +0000

Looks good, Jiazi.

I wonder if in the future we can create deeper bounds between an OLSR core and a RPL edge, make that a combined domain where SRH can be used end to end.

Maybe on occasion we can chat about the way RPL handles instances, which are like L3 VLANs.

Take care,

Pascal

Le 1 juil. 2016 ? 01:05, Jiazi YI <[email-masked]<mailto:[email-masked]>> a ?crit :

Hi,

Regarding the use of source routing header in IPv6 and the reference to RFC6554, we have contacted the 6man chairs.

The answer from Ole (one of the chairs) was that he didn't see why it can't be used, and suggested the experimental code points of the IPv6 Routing Types.

       - Have a well scoped reference to RFC6554: for example, for SRH format, use section 3, for SRH processing, use section 4, etc. Other than that, the olsrv2-multipath would be self-contained.

       - Have a well defined scope of the use of the SRH: only the OLSRv2/MP-OLSRv2 routing domain.

best

Jiazi

On Fri, Jun 24, 2016 at 1:40 PM, Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>> wrote:
On 6/24/16, 5:16 AM, "[email-masked]<mailto:[email-masked]> on behalf of Jiazi YI" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi!

Thanks!

Alvaro.

---

From: Henning Rogge <[email-masked]>
Date: Fri, 1 Jul 2016 07:40:33 +0200

> Maybe on occasion we can chat about the way RPL handles instances, which are

Wouldn't the multi-topology extension of OLSRv2 having a similar
effect? Multiple (partly) overlapping routing topologies with the same
routing agent.

Henning Rogge