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

From: [email-masked]
Date: Wed, 10 May 2017 07:05:14 -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 of the IETF.

        Title           : Multipath Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)
        Authors         : Jiazi Yi
                          Benoit Parrein
	Filename        : draft-ietf-manet-olsrv2-multipath-13.txt
	Pages           : 25
	Date            : 2017-05-10

Abstract:
   This document specifies a multipath 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 are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-13
https://datatracker.ietf.org/doc/html/draft-ietf-manet-olsrv2-multipath-13

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

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: Wed, 10 May 2017 16:15:40 +0200

Dear all, 

We just submitted a new revision of the olsrv2-multipath draft based on the comments received since the IETF LC, mainly from:

Chris: https://www.ietf.org/mail-archive/web/manet/current/msg19426.html <https://www.ietf.org/mail-archive/web/manet/current/msg19426.html>
Zhen: https://www.ietf.org/mail-archive/web/manet/current/msg19425.html <https://www.ietf.org/mail-archive/web/manet/current/msg19425.html>
Mirja: https://www.ietf.org/mail-archive/web/manet/current/msg19424.html <https://www.ietf.org/mail-archive/web/manet/current/msg19424.html>
Peter: https://www.ietf.org/mail-archive/web/manet/current/msg19423.html <https://www.ietf.org/mail-archive/web/manet/current/msg19423.html>
Alvaro: https://www.ietf.org/mail-archive/web/manet/current/msg19420.html <https://www.ietf.org/mail-archive/web/manet/current/msg19420.html>
Suresh: https://www.ietf.org/mail-archive/web/manet/current/msg19431.html <https://www.ietf.org/mail-archive/web/manet/current/msg19431.html>

We appreciate the review and the comments, which certainly help improving the quality of the draft a lot. Thanks very much! Further feedback is welcome. 

regards

Jiazi

> On 10 May 2017, at 16:05, [email-masked] wrote:
> 
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 10 May 2017 15:03:27 +0000

Section 7.1 SR_addr original -> originator.

Section 8.1, second paragraph: You can say that because a TC message will be created in every TC_INTERVAL, and because SR_TC_INTERVAL >= TC_INTERVAL [you want >=, even with a  SHOULD for normal behaviour] the normal behaviour will ensure a TC message with a SOURCE_ROUTE TLV at least every SR_TC_INTERVAL, there's no need to make it a new requirement.

Section 8.1, third paragraph, should I think more clearly say that it is about routers support source routing but would not, according to RFC 7181, send TC messages, but now MUST do so. The MUST NOT applied to neighbour addresses arguably isn't, as it's not actually broken for it to do so, but might advertise neighbours for too long. Perhaps a SHOULD NOT? It could also note that if this TC message carries an INTERVAL_TIME TLV (which is optional) it MUST report SR_TC_INTERVAL.

Section 8.2 SR_time. We haven't put in place the condition that we never reduce validity times in analogous places in RFC 7181, so I don't think that is needed here.

Last line on page 13 route -> routed.

Section 9, I think the SR_TC_INTERVAL and SR_HOLD_TIME constraints are a bit messy, and missing a constraint.

SR_TC_INTERVAL: MUST be greater than or equal to TC_INTERVAL, SHOULD be significantly greater than TC_INTERVAL, default 10 x TC_INTERVAL.

SR_HOLD_TIME: MUST be greater than SR_TC_INTERVAL, SHOULD allow for a small number of lost messages, default is 3 x SR_TC_INTERVAL. (There's no need to directly relate to TC_INTERVAL here.)

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

T:  +44 3300 467500  |  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: 10 May 2017 15:16
To: manet
Cc: Dearlove, Christopher (UK); Zhen Cao; Peter Yee; Suresh Krishnan; Mirja Kühlewind
Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-13.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://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Dealing%20With%20Suspicious%20Emails.pdf>.
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

Dear all,

Chris: https://www.ietf.org/mail-archive/web/manet/current/msg19426.html
Zhen: https://www.ietf.org/mail-archive/web/manet/current/msg19425.html
Mirja: https://www.ietf.org/mail-archive/web/manet/current/msg19424.html
Peter: https://www.ietf.org/mail-archive/web/manet/current/msg19423.html
Alvaro: https://www.ietf.org/mail-archive/web/manet/current/msg19420.html
Suresh: https://www.ietf.org/mail-archive/web/manet/current/msg19431.html

regards

Jiazi

On 10 May 2017, at 16:05, [email-masked]<mailto:[email-masked]> wrote:

Abstract:

_______________________________________________
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: Thu, 11 May 2017 01:12:27 +0200

Dear Chris, 

> On 10 May 2017, at 17:03, Dearlove, Christopher (UK) <[email-masked]> wrote:
> 
> Section 8.1, second paragraph: You can say that because a TC message will be created in every TC_INTERVAL, and because SR_TC_INTERVAL >= TC_INTERVAL [you want >=, even with a  SHOULD for normal behaviour] the normal behaviour will ensure a TC message with a SOURCE_ROUTE TLV at least every SR_TC_INTERVAL, there’s no need to make it a new requirement.
>  
> Section 8.1, third paragraph, should I think more clearly say that it is about routers support source routing but would not, according to RFC 7181, send TC messages, but now MUST do so. The MUST NOT applied to neighbour addresses arguably isn’t, as it’s not actually broken for it to do so, but might advertise neighbours for too long. Perhaps a SHOULD NOT? It could also note that if this TC message carries an INTERVAL_TIME TLV (which is optional) it MUST report SR_TC_INTERVAL.

We plan to update the draft with following text: 

TC messages are generated according to Section 16.1 of [RFC7181] plus a single message TLV with Type := SOURCE_ROUTE included. 

For the routers that do not generate TC messages according to [RFC7181], at least one TC message MUST be generated by an MP-OLSRv2 Routing Process during the SR_TC_INTERVAL (Section 5), which MUST be greater than TC_INTERVAL. Those TC messages MUST NOT carry any advertised neighbor addresses. This serves for those routers to advertise the 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 validity time associated with the VALIDITY_TIME TLV in such TC messages equals SR_HOLD_TIME, which MUST be greater than the SR_TC_INTERVAL. If the TC message carries an optional INTERVAL_TIME TLV, it MUST have a value encoding the SR_TC_INTERVAL.

I prefer keeping the MUST NOT applied to neighbour address — or else, it has possibility of setting longer validity time of related addresses, which is something that we don’t intend to do. 

Other issues will be fixed in the updated revision also. 

best

Jiazi

>  
> Section 8.2 SR_time. We haven’t put in place the condition that we never reduce validity times in analogous places in RFC 7181, so I don’t think that is needed here.
>  
> SR_HOLD_TIME: MUST be greater than SR_TC_INTERVAL, SHOULD allow for a small number of lost messages, default is 3 x SR_TC_INTERVAL. (There’s no need to directly relate to TC_INTERVAL here.)
>  
> --
> 
> Christopher Dearlove
> T:  +44 3300 467500  |  E: [email-masked] <mailto:[email-masked]>
> 
> www.baesystems.com/ai <http://www.baesystems.com/ai>
> From: manet [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Jiazi Yi
> Sent: 10 May 2017 15:16
> To: manet
> For information regarding Red Flags that you can look out for in emails you receive, click here <http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Red%20Flags.pdf>.
> If you feel the email is suspicious, please follow this process <http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Dealing%20With%20Suspicious%20Emails.pdf>.
> 
> *** WARNING ***
> On 10 May 2017, at 16:05, [email-masked] <mailto:[email-masked]> wrote:
>  
> 
> https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ <https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/>
> 
> https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-13 <https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-13>
> https://datatracker.ietf.org/doc/html/draft-ietf-manet-olsrv2-multipath-13 <https://datatracker.ietf.org/doc/html/draft-ietf-manet-olsrv2-multipath-13>
> 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-multipath-13 <https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-multipath-13>
> 
> 
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 11 May 2017 08:47:58 +0000

s/SR_TC_INTERVAL (Section 5), which MUST be greater than TC_INTERVAL/SR_TC_INTERVAL (Section 5), which MUST be greater than or equal to TC_INTERVAL/

Otherwise looks good to me. Also need to address Section 9 to match of course.

From: Jiazi Yi [mailto:[email-masked]]
Sent: 11 May 2017 00:12
To: Dearlove, Christopher (UK)
Cc: manet
Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-13.txt

*** WARNING ***

On 10 May 2017, at 17:03, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:

best

Jiazi

*** WARNING ***

Dear all,

regards

Jiazi

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