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

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 1 Jul 2015 08:50:32 +0000

Actually, coming off the fence, I'm not a big fan of the bit vector idea, it's rather inflexible and it makes combining extensions that might use it messy.

The most flexible option, and the one with lowest overhead if just using one extension, is the separate type extensions for different cases. Each can then define its own data requirements.

It would then be worth considering whether to use type extensions of an already allocated type. That I don't yet have a view on.

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

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

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

-----Original Message-----
From: manet [mailto:[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:
> 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.)

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

_______________________________________________
manet mailing list
[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, 1 Jul 2015 12:20:33 +0200

I have no strong preference. But thinking of flexibility, clarity and
readability, having it in a separate type extension seems to be a better
idea.

I'm think about making use of an allocated type, in:

Type 7 Message TLV Type Extensions

in which, type extension 0 has been allocated as:

0 MPR_WILLING Bits 0-3 specify the originating router's willingness to act
as a flooding MPR; bits 4-7 specify the originating router's willingness to
act as a routing MPR.

We can ask for type extension 1, SR_WILLING (or SOURCE_ROUTE), to identify
a route is willing to join the source route.

best

Jiazi

On Wed, Jul 1, 2015 at 10:50 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> Actually, coming off the fence, I'm not a big fan of the bit vector idea,
> it's rather inflexible and it makes combining extensions that might use it
> messy.
>
> The most flexible option, and the one with lowest overhead if just using
> one extension, is the separate type extensions for different cases. Each
> can then define its own data requirements.
>
> It would then be worth considering whether to use type extensions of an
> already allocated type. That I don't yet have a view on.
>
> --
> Christopher Dearlove
> ----------------------! WARNING ! ---------------------- This message
> originates from outside our organisation, either from an external partner
> or from the internet.
> 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
> >
>
> > 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 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: Wed, 1 Jul 2015 10:24:01 +0000

Type extension 1 of that TLV is already requested by MT-OLSRv2 (MPR_TYPES).

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

www.baesystems.com/ai<http://www.baesystems.com/ai>

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiazi YI
Sent: 01 July 2015 11:21
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; 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<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>.
I have no strong preference. But thinking of flexibility, clarity and readability, having it in a separate type extension seems to be a better idea.

0 MPR_WILLING Bits 0-3 specify the originating router's willingness to act as a flooding MPR; bits 4-7 specify the originating router's willingness to act as a routing MPR.

We can ask for type extension 1, SR_WILLING (or SOURCE_ROUTE), to identify a route is willing to join the source route.

best

Jiazi

On Wed, Jul 1, 2015 at 10:50 AM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
Actually, coming off the fence, I'm not a big fan of the bit vector idea, it's rather inflexible and it makes combining extensions that might use it messy.

T:  +44 (0)1245 242194<tel:%2B44%20%280%291245%20242194>  |  E: [email-masked]<mailto:[email-masked]>

www.baesystems.com/ai<http://www.baesystems.com/ai>

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

Henning
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

---

From: Jiazi YI <[email-masked]>
Date: Wed, 1 Jul 2015 12:32:05 +0200

Ah, sorry. I was just looking at the IANA protocol registry page.
https://www.iana.org/assignments/manet-parameters/manet-parameters.xhtml#message-tlv-types

Then, need to ask for the next available one -- I believe we still have
some code points left under type 7 :)

Jiazi

On Wed, Jul 1, 2015 at 12:24 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> *-- *
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence *
> *__________________________________________________________________________
> *
> *T*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Jiazi
> YI
> *Sent:* 01 July 2015 11:21
> *To:* Dearlove, Christopher (UK)
> *Cc:* Henning Rogge; 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
> <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: Henning Rogge <[email-masked]>
Date: Wed, 1 Jul 2015 12:35:26 +0200

so "Source Route capability" could become extension 2...

and "Source Specific routing capability" potentially later extension 3?

Henning Rogge

On Wed, Jul 1, 2015 at 12:24 PM, Dearlove, Christopher (UK)
<[email-masked]> wrote:
> 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.
>
> We can ask for type extension 1, SR_WILLING (or SOURCE_ROUTE), to identify a
> route is willing to join the source route.
>
>
>
> best
>
>
>
> Jiazi
>
>
>
> On Wed, Jul 1, 2015 at 10:50 AM, Dearlove, Christopher (UK)
> <[email-masked]> wrote:
>
> The most flexible option, and the one with lowest overhead if just using one
> extension, is the separate type extensions for different cases. Each can
> then define its own data requirements.
>
> originates from outside our organisation, either from an external partner or
> from the internet.
> 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>
>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 1 Jul 2015 10:40:01 +0000

I think that would work. It seems a suitable TLV to use, as the existing two essentially signal an extension (considering OLSRv2 as an extension to NHDP, as it is in part).

And the existing examples are instructive in requiring data, not being simply binary.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 01 July 2015 11:35
To: Dearlove, Christopher (UK)
Cc: Jiazi YI; manet
Subject: Re: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-multipath-04.txt

Henning Rogge

On Wed, Jul 1, 2015 at 12:24 PM, Dearlove, Christopher (UK) <[email-masked]> wrote:
> BAE Systems Applied Intelligence Limited Registered in England & Wales 
> No: 01337451
>
> For information regarding Red Flags that you can look out for in 
> emails you receive, click here.
>
>
> readability, having it in a separate type extension seems to be a 
> better idea.
>
>
>
> 0 MPR_WILLING Bits 0-3 specify the originating router's willingness to 
> act as a flooding MPR; bits 4-7 specify the originating router's 
> willingness to act as a routing MPR.
>
>
>
> We can ask for type extension 1, SR_WILLING (or SOURCE_ROUTE), to 
> identify a route is willing to join the source route.
>
>
>
> best
>
>
>
> Jiazi
>
>
>
> Actually, coming off the fence, I'm not a big fan of the bit vector 
> idea, it's rather inflexible and it makes combining extensions that 
> might use it messy.
>
> The most flexible option, and the one with lowest overhead if just 
> using one extension, is the separate type extensions for different 
> cases. Each can then define its own data requirements.
>
> It would then be worth considering whether to use type extensions of 
> an already allocated type. That I don't yet have a view on.
>
> --
> Christopher Dearlove
> BAE Systems Applied Intelligence Limited Registered in England & Wales 
> No: 01337451 Registered Office: Surrey Research Park, Guildford, 
> Surrey, GU2 7YP
>
>
> originates from outside our organisation, either from an external 
> partner or from the internet.
> Follow the 'Report Suspicious Emails' link on IT matters for 
> instructions on reporting suspicious email messages.
> 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/Docu
> ments/Dealing%20With%20Suspicious%20Emails.pdf>
>
>
>> 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.
> 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
>