Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-04.txt

From: [email-masked]
Date: Mon, 29 Jun 2015 15:37:50 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.

        Title           : Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)
        Authors         : Jiazi Yi
                          Benoit Parrein
	Filename        : draft-ietf-manet-olsrv2-multipath-04.txt
	Pages           : 19
	Date            : 2015-06-29

Abstract:
   This document specifies a multi-path extension for the Optimized Link
   State Routing Protocol version 2 (OLSRv2) to discover multiple
   disjoint paths, so as to improve reliability of the OLSRv2 protocol.
   The interoperability with OLSRv2 is retained.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-multipath-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Jiazi YI <[email-masked]>
Date: Tue, 30 Jun 2015 00:58:48 +0200

Hi,

We just submitted a new revision of olsrv2-multipath. The updates include:

 - Changed the SR_OLSRv2 TLV (for identifying a router supporting source
routing) from message-type-specific TLV to Message TLV. By doing so, only
one additional TLV is needed for the extension. In fact, identifying a
source-routing supported router may be useful for other extensions also.

  - Based on the comments from Philippe (
http://www.ietf.org/mail-archive/web/manet/current/msg17683.html), I added
an example in the appendix, which clarifies the choice of the Multi-path
Dijkstra algorithm.

  - Updated the link of the open source implementations.

  - nits picking.

regards

Jiazi

---------- Forwarded message ----------
From: <[email-masked]>
Date: Tue, Jun 30, 2015 at 12:37 AM
Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-04.txt
To: [email-masked]
Cc: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 This draft is a work item of the Mobile Ad-hoc Networks Working Group of
the IETF.

        Title           : Multi-path Extension for the Optimized Link State
Routing Protocol version 2 (OLSRv2)
        Authors         : Jiazi Yi
                          Benoit Parrein
        Filename        : draft-ietf-manet-olsrv2-multipath-04.txt
        Pages           : 19
        Date            : 2015-06-29

Abstract:

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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 30 Jun 2015 08:44:13 +0000

I haven’t had time to read this yet, but just as an immediate observation, if the meaning of this TLV is to say “supports source routing” and may be applicable more widely, then SR_OLSRv2 is not a good name, it needs to be independent of OLSRv2. Suitable name depends on next point, but assuming not, could be e.g. SOURCE_ROUTE (I like to keep names down to no more than 13 characters, they fit better in message etc. pictures).

Then, it’s worth having a quick thought as to how general this should be. A valueless TLV that says “supports source routing” is fine, and might be the answer. But it could be (for example) a TLV that carries information in its value(s) one possibility for which is source routing.

(If no one make any suggestion along the latter lines, then what’s there is – apart from name – the right answer.)

--
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: 29 June 2015 23:59
To: manet
Subject: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-multipath-04.txt

*** 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 ***
This message originates from outside our organization, either from an external partner or the internet. Consider carefully whether you should click on any links, open any attachments or reply. For additional information about Spearphishing, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Pages/SpearphishingTips.aspx>. 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,

 - Changed the SR_OLSRv2 TLV (for identifying a router supporting source routing) from message-type-specific TLV to Message TLV. By doing so, only one additional TLV is needed for the extension. In fact, identifying a source-routing supported router may be useful for other extensions also.

  - Based on the comments from Philippe (http://www.ietf.org/mail-archive/web/manet/current/msg17683.html), I added an example in the appendix, which clarifies the choice of the Multi-path Dijkstra algorithm.

  - nits picking.

regards

Jiazi

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Tue, Jun 30, 2015 at 12:37 AM
Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-04.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

_______________________________________________
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: Henning Rogge <[email-masked]>
Date: Tue, 30 Jun 2015 10:59:41 +0200

On Tue, Jun 30, 2015 at 10:44 AM, Dearlove, Christopher (UK)
<[email-masked]> wrote:
> I haven’t had time to read this yet, but just as an immediate observation,
> if the meaning of this TLV is to say “supports source routing” and may be
> applicable more widely, then SR_OLSRv2 is not a good name, it needs to be
> independent of OLSRv2. Suitable name depends on next point, but assuming
> not, could be e.g. SOURCE_ROUTE (I like to keep names down to no more than
> 13 characters, they fit better in message etc. pictures).
>
> Then, it’s worth having a quick thought as to how general this should be. A
> valueless TLV that says “supports source routing” is fine, and might be the
> answer. But it could be (for example) a TLV that carries information in its
> value(s) one possibility for which is source routing.

We will need something similar for "source specific routing" too.

Maybe we could start a "NODE_CAPABILITY" TLV which contains a bit-array?

And the first allocated bit in this array will be "supports source-routing" ?

Henning Rogge

---

From: Jiazi YI <[email-masked]>
Date: Tue, 30 Jun 2015 14:38:03 +0200

Thanks to Chris and Henning.

I think it's a good idea. Restricting the source-routing flag to OLSRv2 is
not necessary.

best

Jiazi

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 30 Jun 2015 13:03:07 +0000

For some reason Henning’s message hasn’t reached me, except as quoted here.

If we agree there are possible attributes to indicate, source routing being one, then I can see at least three ways to do that. Here I’m not trying to indicate a preference.

(a) We use a bit vector. While there are no more than eight attributes defined this takes a single octet value, but might need more later. (That would be backwardly compatible using RFC 7188 rules.)
(b) We define values, similarly to TLVs like LINK_STATUS. Difference is that we might sometimes need more than one value, which leads to a variable sized TLV value, or multiple use of the TLV.
(c) We let the meaning be a type extension. Source routed would (unless decided otherwise) get the plum type extension zero that can be omitted data point. Multiple cases need multiple TLVs.

There are various tradeoffs in the above in terms of space and simplicity - and the impact on this draft - that I'm not going to attempt to indicate here. (If any discussion happens I may then indicate a preference.) And of course I may have overlooked a (d).

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

www.baesystems.com/ai

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiazi YI
Sent: 30 June 2015 13:38
To: Henning Rogge
Cc: Dearlove, Christopher (UK); manet
Subject: Re: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-multipath-04.txt

*** 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.
If you feel the email is suspicious, please follow this process.
Thanks to Chris and Henning. 

I think it's a good idea. Restricting the source-routing flag to OLSRv2 is not necessary. 

best

Jiazi

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 30 Jun 2015 15:22:17 +0200

> (a) We use a bit vector. While there are no more than eight attributes defined this takes a single octet value, but might need more later. (That would be backwardly compatible using RFC 7188 rules.)

A bit vector would be fine, especially if we allow to increase the
length later. This would give us "as many capabilities as we want",
not that I expect that many.

Henning

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 30 Jun 2015 13:26:56 +0000

Is "would be fine" the same as "my preference among options"?

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 30 June 2015 14:22
To: Dearlove, Christopher (UK)
Cc: manet
Subject: Re: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-multipath-04.txt

----------------------! 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 ***
This message originates from outside our organization, either from an external partner or the internet. Consider carefully whether you should click on any links, open any attachments or reply. For additional information about Spearphishing, click here <http://intranet.ent.baesystems.com/howwework/security/spotlights/Pages/SpearphishingTips.aspx>. 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 30, 2015 at 3:03 PM, Dearlove, Christopher (UK) <[email-masked]> wrote:
> (a) We use a bit vector. While there are no more than eight attributes 
> defined this takes a single octet value, but might need more later. 
> (That would be backwardly compatible using RFC 7188 rules.)

A bit vector would be fine, especially if we allow to increase the length later. This would give us "as many capabilities as we want", not that I expect that many.

Henning

---

From: Henning Rogge <[email-masked]>
Date: Tue, 30 Jun 2015 15:28:31 +0200

> Is "would be fine" the same as "my preference among options"?

Yes... especially if we keep it constraint to "binary capabilities"...
something a node does support or does not support.

Anything more complicated should have a TLV of its own.

Henning

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 30 Jun 2015 14:35:58 +0000

The IANA considerations section isn’t right. Of course exactly what it should look like depends on current consideration, but first you need to request a TLV from the Message TLVs registry. You don’t get to choose the number, just TBD. That requires you to create a type extensions registry for that type. The naming style and table layout you should take from the IANA registry as modified by the TLV naming draft (already changed by IANA as that draft is with the RFC editor). (You can probably steal from that draft’s XML.) You may then need (two of the three options I indicated, but not this as it currently stands) a further definition of the value, probably needing another table.

*** WARNING ***

Hi,

  - nits picking.

regards

Jiazi

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Tue, Jun 30, 2015 at 12:37 AM
Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-04.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Abstract:

---

From: Jiazi YI <[email-masked]>
Date: Tue, 30 Jun 2015 22:27:45 +0200

A bit vector seems to be enough in this case and future extensions for
NODE_CAPABILITY
TLV (which generally indicates ON/OFF status of a function).

And thanks Chris for indicating the error in the IANA consideration
section. I'll draft a new text after we decided which approach to take for
the source-route related TLV.

best

Jiazi