From jvasseur@cisco.com Thu Nov 1 02:42:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68F321F8533 for ; Thu, 1 Nov 2012 02:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.864 X-Spam-Level: X-Spam-Status: No, score=-9.864 tagged_above=-999 required=5 tests=[AWL=0.734, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOc5fNBpvZJZ for ; Thu, 1 Nov 2012 02:42:00 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4C08F21F8539 for ; Thu, 1 Nov 2012 02:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17298; q=dns/txt; s=iport; t=1351762920; x=1352972520; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QZ52srjR9FKP0l0QUKfoYktmFIUpNFphVrXU97EPCiU=; b=K6W9sfmnRcvAwmGZ+m5NGTEdy386fbgVhGqB4V2MWpwl+5agLN55T9PY ggeVUYV8M/fn+2XvmOvGr8BQ40ef/0aicLIBaBJY83sD8nphaQWx51qO3 lia2WptFfVNaIJqjhH6kiTSbAZhVNf4PAtbp0ytt4cRUl2jKbGv0kDts5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABNDklCtJV2a/2dsb2JhbABEgkmvB5IagQiCHgEBAQQBAQEPAVsLEAIBCA4DBAEBCx0HJwsTAQkIAgQOBQgTB4dSAw8LmyagHQSLFGeFWmEDlCaNAoMmgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,692,1344211200"; d="scan'208,217";a="137670042" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 01 Nov 2012 09:41:59 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA19fxW7013273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 09:41:59 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 04:41:58 -0500 From: "JP Vasseur (jvasseur)" To: Jon Black Thread-Topic: [manet] (no subject) Thread-Index: AQHNt7RXxBNcBUy08k2NlcZzRgkbFg== Date: Thu, 1 Nov 2012 09:41:57 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> In-Reply-To: <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.73.195] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--47.599700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77220486F0xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "thierry.lys@erdfdistribution.fr" , "manet@ietf.org" Subject: Re: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 09:42:01 -0000 --_000_03B78081B371D44390ED6E7BADBB4A77220486F0xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jon, On Nov 1, 2012, at 12:39 AM, Jon Black wrote: Yes it shows that it does work in a rather large deployment. JP> This is not just a question of "how large" it is =85 but also how dynam= ic. I could show you few hundreds (if not less number of nodes) not working if the traffic pattern is too dynamic. This is a fundamental pr= oblem. I have heard others say that it works in other deployments as well - just t= he same as you say RPL works in some deployments. JP> I do not not think that we should go in a RPL versus Load-NG debate but= rather try to find a good solution for MANET. That being said, RPL *for* LLNs the the result of a 4-year work with a DT, weekly call= s, interim WG meetings to make it work in LLNs. Please share your results. You keeps saying you will and you we keep askin= g you to - where's the results so they can be reviewed. JP> Once again, I would first like to hear chair's decision. PLEASE note th= at I would be happy to see Load's results too. And just be patient, I just need to find a bit of time to compile results and you will = get many results backing up my claims. Please also refer to the number of discussions prior to designing RPL that took place on the ROLL ma= iling list. Believe me there was a reason not NOT choosing a reactive protocol for LLN (again I am NOT against reactive routing for ot= her use cases at all). Would you ignore the findings of a WG that worked for 4 years on the subject matter ? I guess not =85 Just trying= to raise my voice (as many others on this list) to protect the Internet. Thanks. JP. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: "manet@ietf.org" >; "thierry.lys@erdfdistribution.fr" > Sent: Wednesday, October 31, 2012 4:09 PM Subject: Re: [manet] (no subject) On Oct 31, 2012, at 6:57 PM, Jon Black wrote: On October 31, 2012 Thierry.Lys wrote: I speak in the name of EDF group. We started first to use LOAD as a routing algorithm and deployed 2000 PLC-m= eters for smart grid purposes in 2011. Taking advantage of this field test,= we have been actively participating to the working group to adopt enhancem= ents in the LOADng specification. We are now extremely pleased with what LOADng is capable of and are confide= nt that future deployements will be equipped with it. This would seem to indicate that LOADng does work and in a rather large dep= loyment. JP> No this means that LoadNG works in *a* network. But the major technical= difference here is that reactive routing is highly impacted by the user traffic =85 If you poll a meter every 24 hours, it may work per= fectly well. Now if you start having more frequent traffic flows you can either cache paths (ending up with more frequent broken paths consi= dering how flappy these networks are, thus leading to more floods =85 very undesirable =85 especially when you have hundreds of meters= sharing a few Kbits/s) or you use short cache timers and you keep flooding :-( If you take actual traces of these networks (both using 1= 5.4g and P1901.2) and you start adjusting the user traffic rate you immediately see the issues in terms of scalability. Yes you can try to miti= gate the undesirable flooding effect to some extends but showing the limits in terms of scalability is easy to show. Note that I MOT against= reactive routing by any means, this is IMO just not applicable to LLNs unless the traffic flows are deterministic and very well knows =85 Les= sons from the past show us how difficult it is to predict user applications. We all started with meter reading to continue with that examp= le and now many utilities wants to use these smart metering networks for a number of applications which different SLA, =85 Hope this helps. Once again, when/if required I would be happy to share man= y results. "We believe in rough consensus and running code" rough consensus : Don't you think we have a rough consensus on LOADng compa= red to DYMO ? 10 authors and major companies are supporters of LOADng. running code : interoperability has been checked with 4 sources and other i= mplementations are in progress. Obviously from the list we don't have rough consensus. We have two alterna= tives each with proponents. The WG should weigh the technical benefits (de= sign, implementation/running code, maturity) of each and the group should = choose a path forward. In my opinion option 3 is not an option - this is the working group shirkin= g its responsibility. This is an option =85 since listed by the chairs. I agree that we should av= oid it, especially when I think we have a very reasonable solution (option1). JP. Jon _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A77220486F0xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Jon,

On Nov 1, 2012, at 12:39 AM, Jon Black wrote:

Yes it shows that it does work in a rather large deployment.&nbs= p;

JP> This is not just a question of "how large" it is =85 = but also how dynamic. I could show you few hundreds (if not less number of = nodes)
not working if the traffic pattern is too dynamic. This is a fundament= al problem.

I have heard others say that it works in other deployments as we= ll - just the same as you say RPL works in some deployments.


JP> I do not not think that we should go in a RPL versus Load-NG de= bate but rather try to find a good solution for MANET. That being
said, RPL *for* LLNs the the result of a 4-year work with a DT, weekly= calls, interim WG meetings to make it work in LLNs.

Please share your results.  You keeps saying you will and you we= keep asking you to - where's the results so they can be reviewed.


JP> Once again, I would first like to hear chair's decision. PLEASE= note that I would be happy to see Load's results too. And just be
patient, I just need to find a bit of time to compile results and you = will get many results backing up my claims. Please also refer to the
number of discussions prior to designing RPL that took place on the RO= LL mailing list. Believe me there was a reason not NOT choosing
a reactive protocol for LLN (again I am NOT against reactive routing f= or other use cases at all). Would you ignore the findings of a WG
that worked for 4 years on the subject matter ? I guess not =85 Just t= rying to raise my voice (as many others on this list) to protect the
Internet.

Thanks.

JP.

Jon


From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@ietf.org>; "thierry.lys@erdfdistribution.fr" <thierry.lys@erdfdistribution.fr>
Sent: Wednesday, October 3= 1, 2012 4:09 PM
Subject: Re: [manet] (no s= ubject)


On Oct 31, 2012, at 6:57 PM, Jon Black wrote:

On October 31, 2012 Thierry.Lys wrote:

I speak in the name of EDF group.

We started first to use LOAD as a rout= ing algorithm and deployed 2000 PLC-meters for smart grid purposes in 2011.= Taking advantage of this field test, we have been actively participating t= o the working group to adopt enhancements in the LOADng specification.
We are now extremely pleased with what= LOADng is capable of and are confident that future deployements will be eq= uipped with it. 

This would seem to indicate that LOADng does work and in a rather large dep= loyment.

JP> No this means that LoadNG works in *a* network. But the major t= echnical difference here is that reactive routing is highly impacted
by the user traffic =85 If you poll a meter every 24 hours, it may wor= k perfectly well. Now if you start having more frequent traffic flows
you can either cache paths (ending up with more frequent broken paths = considering how flappy these networks are, thus leading to more
floods =85 very undesirable =85 especially when you have hundreds of m= eters sharing a few Kbits/s) or you use short cache timers and you
keep flooding :-( If you take actual traces of these networks (both us= ing 15.4g and P1901.2) and you start adjusting the user traffic rate you
immediately see the issues in terms of scalability. Yes you can try to= mitigate the undesirable flooding effect to some extends but showing =
the limits in terms of scalability is easy to show. Note that I MOT ag= ainst reactive routing by any means, this is IMO just not applicable to
LLNs unless the traffic flows are deterministic and very well knows = =85 Lessons from the past show us how difficult it is to predict user =
applications. We all started with meter reading to continue with that = example and now many utilities wants to use these smart metering 
networks for a number of applications which different SLA, =85 

Hope this helps. Once again, when/if required I would be happy to shar= e many results.



"We believe in rough consensus an= d running code"

rough consensus : Don't you think we h= ave a rough consensus on LOADng compared to DYMO ? 10 authors and major com= panies are supporters of LOADng.

running code : interoperability has be= en checked with 4 sources and other implementations are in progress.

Obviously from the list we don't ha= ve rough consensus.  We have two alternatives each with proponents.&nb= sp; The WG should weigh the technical benefits (design, implementation/runn= ing code, maturity)  of each and the group should choose a path forward.

In my opinion option 3 is not an option - this is the working group shirkin= g its responsibility.

This is an option =85 since listed by the chairs. I agree that we shou= ld avoid it, especially when I think we have a very reasonable solution
(option1).

JP.


Jon

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet




--_000_03B78081B371D44390ED6E7BADBB4A77220486F0xmbrcdx02ciscoc_-- From Chris.Dearlove@baesystems.com Thu Nov 1 03:10:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746D621F854A for ; Thu, 1 Nov 2012 03:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dojur5r2FKoL for ; Thu, 1 Nov 2012 03:10:51 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA4A21F854F for ; Thu, 1 Nov 2012 03:10:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,692,1344207600"; d="scan'208,217";a="282820638" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 01 Nov 2012 10:10:48 +0000 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qA1AAmKK030015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 10:10:48 GMT Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Thu, 1 Nov 2012 10:10:48 +0000 From: "Dearlove, Christopher (UK)" To: "JP Vasseur (jvasseur)" , Jon Black Thread-Topic: [manet] (no subject) Thread-Index: AQHNt5FAW04pQ2kKUkuXa5XekiOSAZfT+YyAgADI6EA= Date: Thu, 1 Nov 2012 10:10:47 +0000 Message-ID: References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB598AGLKXM0002VGREEN_" MIME-Version: 1.0 Cc: "manet@ietf.org" , "thierry.lys@erdfdistribution.fr" Subject: Re: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 10:10:54 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB598AGLKXM0002VGREEN_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If I were in charge of requirements, that requirement would be now. Attempting to sway a decision on the basis of "I have results" but not offering those results until the decision is made is not helpful. And the most important thing is are there any comparisons between the two (or with base AODV)? Without those, the issue is how do the two differ technically in a manner that matters? -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur) Sent: 31 October 2012 22:09 To: Jon Black Cc: thierry.lys@erdfdistribution.fr; manet@ietf.org Subject: Re: [manet] (no subject) *** WARNING *** This message originates from outside our organisation, either from an external partner or the internet. Keep this in mind if you answer this message. Please see this process on how to deal with suspicious emails. On Oct 31, 2012, at 6:57 PM, Jon Black wrote: On October 31, 2012 Thierry.Lys wrote: I speak in the name of EDF group. We started first to use LOAD as a routing algorithm and deployed 2000 PLC-meters for smart grid purposes in 2011. Taking advantage of this field test, we have been actively participating to the working group to adopt enhancements in the LOADng specification. We are now extremely pleased with what LOADng is capable of and are confident that future deployements will be equipped with it. This would seem to indicate that LOADng does work and in a rather large deployment. JP> No this means that LoadNG works in *a* network. But the major technical difference here is that reactive routing is highly impacted by the user traffic ... If you poll a meter every 24 hours, it may work perfectly well. Now if you start having more frequent traffic flows you can either cache paths (ending up with more frequent broken paths considering how flappy these networks are, thus leading to more floods ... very undesirable ... especially when you have hundreds of meters sharing a few Kbits/s) or you use short cache timers and you keep flooding :-( If you take actual traces of these networks (both using 15.4g and P1901.2) and you start adjusting the user traffic rate you immediately see the issues in terms of scalability. Yes you can try to mitigate the undesirable flooding effect to some extends but showing the limits in terms of scalability is easy to show. Note that I MOT against reactive routing by any means, this is IMO just not applicable to LLNs unless the traffic flows are deterministic and very well knows ... Lessons from the past show us how difficult it is to predict user applications. We all started with meter reading to continue with that example and now many utilities wants to use these smart metering networks for a number of applications which different SLA, ... Hope this helps. Once again, when/if required I would be happy to share many results. "We believe in rough consensus and running code" rough consensus : Don't you think we have a rough consensus on LOADng compared to DYMO ? 10 authors and major companies are supporters of LOADng. running code : interoperability has been checked with 4 sources and other implementations are in progress. Obviously from the list we don't have rough consensus. We have two alternatives each with proponents. The WG should weigh the technical benefits (design, implementation/running code, maturity) of each and the group should choose a path forward. In my opinion option 3 is not an option - this is the working group shirking its responsibility. This is an option ... since listed by the chairs. I agree that we should avoid it, especially when I think we have a very reasonable solution (option1). JP. Jon _______________________________________________ manet mailing list manet@ietf.org 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. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB598AGLKXM0002VGREEN_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

If I were in charge of requirements, that requirement would be now. Attempting to sway a decision on the basis of "I have results" but not offering those results until the decision is made is not helpful. And the most important thing is are there any comparisons between the two (or with base AODV)? Without those, the issue is how do the two differ technically in a manner that matters?

 

--

Christopher Dearlove

Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur)
Sent: 31 October 2012 22:09
To: Jon Black
Cc: thierry.lys@erdfdistribution.fr; manet@ietf.org
Subject: Re: [manet] (no subject)

 

 

*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

 

On Oct 31, 2012, at 6:57 PM, Jon Black wrote:



On October 31, 2012 Thierry.Lys wrote:

 

I speak in the name of EDF group.

We started first to use LOAD as a routing algorithm and deployed 2000 PLC-meters for smart grid purposes in 2011. Taking advantage of this field test, we have been actively participating to the working group to adopt enhancements in the LOADng specification.
We are now extremely pleased with what LOADng is capable of and are confident that future deployements will be equipped with it. 

 

This would seem to indicate that LOADng does work and in a rather large deployment.

 

JP> No this means that LoadNG works in *a* network. But the major technical difference here is that reactive routing is highly impacted

by the user traffic … If you poll a meter every 24 hours, it may work perfectly well. Now if you start having more frequent traffic flows

you can either cache paths (ending up with more frequent broken paths considering how flappy these networks are, thus leading to more

floods … very undesirable … especially when you have hundreds of meters sharing a few Kbits/s) or you use short cache timers and you

keep flooding :-( If you take actual traces of these networks (both using 15.4g and P1901.2) and you start adjusting the user traffic rate you

immediately see the issues in terms of scalability. Yes you can try to mitigate the undesirable flooding effect to some extends but showing 

the limits in terms of scalability is easy to show. Note that I MOT against reactive routing by any means, this is IMO just not applicable to

LLNs unless the traffic flows are deterministic and very well knows … Lessons from the past show us how difficult it is to predict user 

applications. We all started with meter reading to continue with that example and now many utilities wants to use these smart metering 

networks for a number of applications which different SLA, … 

 

Hope this helps. Once again, when/if required I would be happy to share many results.

 




"We believe in rough consensus and running code"

rough consensus : Don't you think we have a rough consensus on LOADng compared to DYMO ? 10 authors and major companies are supporters of LOADng.

running code : interoperability has been checked with 4 sources and other implementations are in progress.

Obviously from the list we don't have rough consensus.  We have two alternatives each with proponents.  The WG should weigh the technical benefits (design, implementation/running code, maturity)  of each and the group should choose a path forward.

In my opinion option 3 is not an option - this is the working group shirking its responsibility.

 

This is an option … since listed by the chairs. I agree that we should avoid it, especially when I think we have a very reasonable solution

(option1).

 

JP.




Jon

 

_______________________________________________
manet mailing list
manet@ietf.org
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.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB598AGLKXM0002VGREEN_-- From boberry@cisco.com Thu Nov 1 03:21:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E700E21F84D5 for ; Thu, 1 Nov 2012 03:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTsKSMUniYhP for ; Thu, 1 Nov 2012 03:21:41 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id CD48021F84A7 for ; Thu, 1 Nov 2012 03:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5581; q=dns/txt; s=iport; t=1351765300; x=1352974900; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zjzxm6Scg8e9WnWaG5ueg0c/J/NTIEP34yAXRvRdoA8=; b=kkR3q7vTxKdD7fJnq9+MGNchxvaeY9pLupUDEa5KQXFQ5S/c06vaPy4i VHMQGcbnh5KiY93Q81BKp+alD4YLi3fQ+1J3AN+iqlMcXrb22bc3VJiWU xdbDBracXMT1xchNlI6yeDyFCYc340vtqVQmx3QdNn+8W66GP0PLFXAPx 8=; X-IronPort-AV: E=Sophos;i="4.80,692,1344211200"; d="scan'208";a="137656901" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 01 Nov 2012 10:21:40 +0000 Received: from [192.168.1.201] (ggsg-1vpn2-230-76.cisco.com [10.81.230.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA1ALdiq022620; Thu, 1 Nov 2012 10:21:39 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Bo Berry In-Reply-To: Date: Thu, 1 Nov 2012 06:22:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2CF862E3-F417-4442-B597-6DCBA035D4B9@cisco.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1085) Cc: "thierry.lys@erdfdistribution.fr" , "manet@ietf.org" Subject: Re: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 10:21:42 -0000 And to be fair, I've not seen results on Loadng wrt to mobility. The = smart meter attached to my house has not moved sense it was installed. =20= On Nov 1, 2012, at 6:10 AM, Dearlove, Christopher (UK) wrote: > If I were in charge of requirements, that requirement would be now. = Attempting to sway a decision on the basis of "I have results" but not = offering those results until the decision is made is not helpful. And = the most important thing is are there any comparisons between the two = (or with base AODV)? Without those, the issue is how do the two differ = technically in a manner that matters? > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of JP Vasseur (jvasseur) > Sent: 31 October 2012 22:09 > To: Jon Black > Cc: thierry.lys@erdfdistribution.fr; manet@ietf.org > Subject: Re: [manet] (no subject) > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an = external partner or the internet. > Keep this in mind if you answer this message. > Please see this process on how to deal with suspicious emails. >=20 > =20 > On Oct 31, 2012, at 6:57 PM, Jon Black wrote: >=20 >=20 > On October 31, 2012 Thierry.Lys wrote: > =20 > I speak in the name of EDF group.=20 >=20 > We started first to use LOAD as a routing algorithm and deployed 2000 = PLC-meters for smart grid purposes in 2011. Taking advantage of this = field test, we have been actively participating to the working group to = adopt enhancements in the LOADng specification.=20 > We are now extremely pleased with what LOADng is capable of and are = confident that future deployements will be equipped with it.=20 > =20 > This would seem to indicate that LOADng does work and in a rather = large deployment. > =20 > JP> No this means that LoadNG works in *a* network. But the major = technical difference here is that reactive routing is highly impacted > by the user traffic =85 If you poll a meter every 24 hours, it may = work perfectly well. Now if you start having more frequent traffic flows > you can either cache paths (ending up with more frequent broken paths = considering how flappy these networks are, thus leading to more > floods =85 very undesirable =85 especially when you have hundreds of = meters sharing a few Kbits/s) or you use short cache timers and you > keep flooding :-( If you take actual traces of these networks (both = using 15.4g and P1901.2) and you start adjusting the user traffic rate = you > immediately see the issues in terms of scalability. Yes you can try to = mitigate the undesirable flooding effect to some extends but showing=20 > the limits in terms of scalability is easy to show. Note that I MOT = against reactive routing by any means, this is IMO just not applicable = to > LLNs unless the traffic flows are deterministic and very well knows =85 = Lessons from the past show us how difficult it is to predict user=20 > applications. We all started with meter reading to continue with that = example and now many utilities wants to use these smart metering=20 > networks for a number of applications which different SLA, =85=20 > =20 > Hope this helps. Once again, when/if required I would be happy to = share many results. > =20 >=20 >=20 >=20 > "We believe in rough consensus and running code"=20 >=20 > rough consensus : Don't you think we have a rough consensus on LOADng = compared to DYMO ? 10 authors and major companies are supporters of = LOADng.=20 >=20 > running code : interoperability has been checked with 4 sources and = other implementations are in progress. >=20 > Obviously from the list we don't have rough consensus. We have two = alternatives each with proponents. The WG should weigh the technical = benefits (design, implementation/running code, maturity) of each and = the group should choose a path forward. >=20 > In my opinion option 3 is not an option - this is the working group = shirking its responsibility. > =20 > This is an option =85 since listed by the chairs. I agree that we = should avoid it, especially when I think we have a very reasonable = solution > (option1). > =20 > JP. >=20 >=20 >=20 > Jon > =20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > =20 >=20 > ******************************************************************** > 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. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ietf@thomasclausen.org Thu Nov 1 05:18:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713E921F86AC for ; Thu, 1 Nov 2012 05:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0A6EAR4aL9l for ; Thu, 1 Nov 2012 05:18:33 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB1E21F85B0 for ; Thu, 1 Nov 2012 05:18:33 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 7E1815588A3 for ; Thu, 1 Nov 2012 05:18:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D55DD1C025C; Thu, 1 Nov 2012 05:18:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E99721C0251; Thu, 1 Nov 2012 05:18:28 -0700 (PDT) References: <061.dd96a35b96e4ad8b95c1f2b46c7199f8@trac.tools.ietf.org> Mime-Version: 1.0 (1.0) In-Reply-To: <061.dd96a35b96e4ad8b95c1f2b46c7199f8@trac.tools.ietf.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <9FCCC536-EB92-4276-AC30-D92A4A9A9324@thomasclausen.org> X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Thu, 1 Nov 2012 13:18:26 +0100 To: "manet@ietf.org" Cc: "manet@ietf.org" Subject: Re: [manet] #3: Use msg-hop-count in RFC 5444 header to limit # of hops X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 12:18:33 -0000 That would be a direct violation of the definition of and in RFC5444, and would render any generic demultiplexing/dispat= ching/forwarding framework inapplicable. This proposal is, therefore, not acceptable under any circumstances. Thomas Sent from my iPad On 30 oct. 2012, at 19:07, "manet issue tracker" wrote: > #3: Use msg-hop-count in RFC 5444 header to limit # of hops >=20 > The current AODVv2 specification uses msg-hop-limit to control the > dissemination of routing messages. It is proposed instead to use msg-hop-= > count to have a direct hop count for disseminated routing messages, and to= > use a protocol constant to limit the number of hops (e.g., MAX_HOP_COUNT > =3D=3D 64). Even 64 is too much for practically any foreseeable ad hoc > network. For networks that need to have finer-grained control (e.g., > controlling dissemination to be less than the manifest constant), msg-hop-= > limit could be used for just those messages needing it. The specification= > can (independently) still specify TTL=3D255 according to RFC 5082. >=20 > --=20 > --------------------------------+---------------------------------- > Reporter: charliep@=E2=80=A6 | Owner: Charlie Perkins > Type: enhancement | Status: new > Priority: major | Milestone: > Component: dymo | Version: > Severity: Active WG Document | Keywords: hop count, hop limit > --------------------------------+---------------------------------- >=20 > Ticket URL: > manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Thu Nov 1 06:50:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454E721F8BF7 for ; Thu, 1 Nov 2012 06:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWXLbnITTcAo for ; Thu, 1 Nov 2012 06:50:35 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id E7C2921F8B67 for ; Thu, 1 Nov 2012 06:50:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,693,1344207600"; d="scan'208";a="282918154" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 01 Nov 2012 13:50:34 +0000 Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qA1DoXWH024984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 13:50:34 GMT Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0309.002; Thu, 1 Nov 2012 13:50:33 +0000 From: "Dearlove, Christopher (UK)" To: Thomas Heide Clausen , "manet@ietf.org" Thread-Topic: [manet] #3: Use msg-hop-count in RFC 5444 header to limit # of hops Thread-Index: AQHNuDEJRJDm31GEnkOtb86CCsIhLZfU+iDw Date: Thu, 1 Nov 2012 13:50:33 +0000 Message-ID: References: <061.dd96a35b96e4ad8b95c1f2b46c7199f8@trac.tools.ietf.org> <9FCCC536-EB92-4276-AC30-D92A4A9A9324@thomasclausen.org> In-Reply-To: <9FCCC536-EB92-4276-AC30-D92A4A9A9324@thomasclausen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] #3: Use msg-hop-count in RFC 5444 header to limit # of hops X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 13:50:36 -0000 I must be missing something here. I think I have an idea what it is, but le= t's confirm. Let's consider an RREQ message, which is flooded. The issue is, does it mut= ate on its travels? If not, I don't see why we can't use the 5444 hop limit= . If it does, then that is not technically an issue for 5444, but does have= two bad effects: - There is a general processing/forwarding engine described in OLSRv2. In a= n ideal world this is another thing that should be in a separate draft. It = is designed for wider use (hence its inclusion of message type). There are = reasons I would find that a good model for what I'm going to call son-of-AO= DV, whatever that ends up being based on and called. - Unmutated (other than hop count/limit) messages work well with message si= gnatures described in 6622 for end to end verification. Mutating messages a= re a bigger headache. They need either new signatures each hop, in which ca= se let's just not bother signing messages, but let's sign packets - a valid= choice, but loses a tool - or some sort of difference collecting and aggre= gating signature that I know nothing about, and may not even exist. I'm guessing Thomas is against this case. But more details needed. (The IP = TTL being a separate issue is I think common ground.) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=C2=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of T= homas Heide Clausen Sent: 01 November 2012 12:18 To: manet@ietf.org Cc: manet@ietf.org Subject: Re: [manet] #3: Use msg-hop-count in RFC 5444 header to limit # of= hops ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- That would be a direct violation of the definition of and <= msg-hop-count> in RFC5444, and would render any generic demultiplexing/disp= atching/forwarding framework inapplicable. This proposal is, therefore, not acceptable under any circumstances. Thomas Sent from my iPad On 30 oct. 2012, at 19:07, "manet issue tracker" wrote: > #3: Use msg-hop-count in RFC 5444 header to limit # of hops >=20 > The current AODVv2 specification uses msg-hop-limit to control the > dissemination of routing messages. It is proposed instead to use msg-hop= - > count to have a direct hop count for disseminated routing messages, and t= o > use a protocol constant to limit the number of hops (e.g., MAX_HOP_COUNT > =3D=3D 64). Even 64 is too much for practically any foreseeable ad hoc > network. For networks that need to have finer-grained control (e.g., > controlling dissemination to be less than the manifest constant), msg-hop= - > limit could be used for just those messages needing it. The specificatio= n > can (independently) still specify TTL=3D255 according to RFC 5082. >=20 > --=20 > --------------------------------+---------------------------------- > Reporter: charliep@=E2=80=A6 | Owner: Charlie Perkins > Type: enhancement | Status: new > Priority: major | Milestone: > Component: dymo | Version: > Severity: Active WG Document | Keywords: hop count, hop limit > --------------------------------+---------------------------------- >=20 > Ticket URL: > manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org 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 abdussalambaryun@gmail.com Thu Nov 1 07:22:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29C221F867B for ; Thu, 1 Nov 2012 07:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICysbTpnx9si for ; Thu, 1 Nov 2012 07:22:46 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 40C2021F8453 for ; Thu, 1 Nov 2012 07:22:44 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3050813vbb.31 for ; Thu, 01 Nov 2012 07:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sxH0ZmSaCU1M8o40HYnrPEnDx96wGaZ6Z2USDUk6oT8=; b=MGDWVl1QNryGfqsmmpQ2h0JAEIo1WePDZE2AH5cOFpvVkN18WucfKhtr+O+MGyIdG8 +lzkk6ytWMXG1qPWO6I/dVbZ6hjkY2ObVfL3EbRTUKN71pcNr9A9EeEtXez+u0U0n4cq 7JlHniGKIQT2cwrICLPFAqh9Wpj95aLDkkVs7/iRiTp5vFbikjPoRDTd1HZINjpRw9If q+dtIWwZ/7m/c+nBX2/zAvmBFWu/cPazSBbHcfX2vCZ1XCWmukxe/CoTbxLXao9k2Jxh RDOK8QEJ8KD8jbLvpTL3nNNi2Of4erG7cARJvt/RV/rgzUFhSPNBdde+Mg0XaLnFc89o +aCw== MIME-Version: 1.0 Received: by 10.58.143.12 with SMTP id sa12mr56132127veb.43.1351779762222; Thu, 01 Nov 2012 07:22:42 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 07:22:41 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Nov 2012 14:22:41 +0000 Message-ID: From: Abdussalam Baryun To: Joseph Macker Content-Type: multipart/alternative; boundary=047d7b6766508ab70804cd6fc08d Cc: manet@ietf.org, Stan Ratliff Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:22:48 -0000 --047d7b6766508ab70804cd6fc08d Content-Type: text/plain; charset=ISO-8859-1 Dear Joseph Macker and Stan, MANET WG Chairs I disagree that the WG arranged/guided to merge the documents, I never heard that there was a consensus on such activity. DYMO is a reactive WG draft, but LOADng is not. Why did you guide to merge documents, I recommend that you ment to merge the team drafts co-authors to one WG draft (which is only DYMO so far). The authority is for the WG to decide to merge individual drafts to its WG draft. Therefore, my vote is for option 1 only. Thanking you for updating us with the status. Regards AB On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker wrote: > Hello MANET working group (form Stan and Joe), > > As you are all probably aware, there has been WG activity lately on > competing drafts for a MANET reactive protocol - DYMO (reviving the current > working group document that was parked due to inactivity), and LOADng. Many > months ago there was a somewhat authorship led movement towards a common > document effort and given positive feedback at the time we the chairs > thought this was the best approach given the authors potential to come > together and gain the best of both efforts. Since that period, there has > been some fairly strident and rancorous "at times" debate between the > authors of the two documents. > > During IETF 84 in Vancouver, the co-chairs held a discussion with some of > the co-authors of the two documents. Our guidance to the co-authors was to > find a way to merge the two documents into one, as it was perceived that > are not technically far apart and they both derive roughly from AODV > concepts and LOADng had fairly active authorship and implementation > efforts. We provided a co-editing proposal to the authors and gave them the > timeframe of the Atlanta to come up with an answer back to us regarding > this. As of this writing, those discussions of a potential commonn > document and authorship merger have failed. > > Therefore, we find ourselves at a crossroads. The authors of the two > documents are divided, and it is unlikely that progress on a merged > document can be reached based upon recent author feedback. I have also > polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat > disengaged on the issue at the present time. We see only 3 possible paths > forward: > > 1. Continue the work on the DYMO document, starting with whether there is > consensus on its continued approach and also the desire to rename it to > AODVv2. > 2. Replace the existing DYMO document effort with the LOADng related > document effort, defusing ealier references to LLNs as recommended in the > last meeting minutes, and to focus more motivationally on general MANET > problem spaces (the authors seem to have agreed to this issue if its a WG > document). > 3. Remove the working group charter for a reactive protocol, effectively > killing both documents, at least from a working group (WG) standpoint. This > would not be a reflection on the technology in either case, just an > admission that we are not working together and reaching consensus. > > The co-chairs request and need your opinions on the options. We have been > some silent collecting initial feedback and waiting for author feedback at > this point. Stan and I are both on travel prior to Atlanta so our > responses may be sparse and we will also likely be in a "receive mode" for > a few days. So send your opinions. > > -Joe > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --047d7b6766508ab70804cd6fc08d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Joseph Macker and Stan,
MANET WG Chairs
=A0
I disagree that the=A0WG=A0arranged/guided to merge the documents,= I never heard that there was a consensus on such activity. DYMO is a react= ive WG draft, but LOADng is not. Why did you guide to merge documents, I re= commend that you ment to merge the team drafts co-authors to one=A0WG draft= (which is only DYMO so far). The authority is for the WG to decide to merg= e individual drafts to its WG draft.
=A0
Therefore, my vote is for option 1 only. Thanking you fo= r updating us with the status.
=A0
Regards
AB=

On Tue, Oct 30, 2012 at 11:13 PM, = Joseph Macker <jpmacker@gmail.com> wrote:
Hello MANET working group (form Stan and Joe),

As y= ou are all probably aware, there has been WG activity lately on competing d= rafts for a MANET reactive protocol - DYMO (reviving the current working gr= oup document that was parked due to inactivity), and LOADng. Many months ag= o there was a somewhat authorship led movement towards a common document ef= fort and given positive feedback at the time we the chairs thought this was= the best approach given the authors potential to come together and gain th= e best of both efforts.=A0 Since that period, there has been some fairly st= rident and rancorous "at times" debate between the authors of the= two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some = of the co-authors of the two documents. Our guidance to the co-authors was = to find a way to merge the two documents into one, as it was perceived that= are not technically far apart and they both derive roughly from AODV conce= pts and LOADng had fairly active authorship and implementation efforts. We = provided a co-editing proposal to the authors and gave them the timeframe o= f the Atlanta to come up with an answer back to us regarding this.=A0 As of= this writing, those discussions of a potential commonn document and author= ship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two do= cuments are divided, and it is unlikely that progress on a merged document = can be reached based upon recent author feedback. I have also polled the ea= rlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the= issue at the present time.=A0 We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there = is consensus on its continued approach and also the desire to rename it to = AODVv2.
2. Replace the existing DYMO document effort with the LOADng rel= ated document effort, defusing ealier references to LLNs as recommended in = the last meeting minutes, and to focus more motivationally on general MANET= problem spaces (the authors seem to have agreed to this issue if its a WG = document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.=A0 We have= been some silent collecting initial feedback and waiting for author feedba= ck at this point.=A0 Stan and I are both on travel prior to Atlanta so our = responses may be sparse and we will also likely be in a "receive mode&= quot; for a few days.=A0 So send your opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--047d7b6766508ab70804cd6fc08d-- From abdussalambaryun@gmail.com Thu Nov 1 07:28:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5369321F8B55 for ; Thu, 1 Nov 2012 07:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmaZ86PoMo4P for ; Thu, 1 Nov 2012 07:28:45 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAAE21F8B18 for ; Thu, 1 Nov 2012 07:28:45 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3058215vbb.31 for ; Thu, 01 Nov 2012 07:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yolvaF8pQyFi2YOqh3eqlz0faFuB0uC57hsP07mmNWE=; b=dEc1QB26POsdb06q7nUs/cPupffo98Mu2mBWRw4M7S0KBo7ZommDaPM9azUNhl5a5v gWxmhJKSR/uYhr89vhrRuXdbUmE1MgxU+lm8zw/fLR1wpE3iAzc7/53wCQzD7qoMlhOa OaUKUIN4/dybqTbjCSm5xxBcpprsjcP6LgyF+TpCKy3SRhCQsjGpDTvjbZYA0NRTQBKT YrTW0I3tqvwmURJ8L6IYOc3KS0VzVrjLC5PG6aELy4nNH3oMyGUjm/tNuTeaUfalhYiR 3RKY1758ghurE3y0AOv6O8e8eLTb6cYW+QTRFRFbVnsnXftWaGUo2Y5QBumF1jMLbPBR dMig== MIME-Version: 1.0 Received: by 10.52.35.82 with SMTP id f18mr50782814vdj.99.1351780124919; Thu, 01 Nov 2012 07:28:44 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 07:28:44 -0700 (PDT) In-Reply-To: References: <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com> Date: Thu, 1 Nov 2012 14:28:44 +0000 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=20cf307c9fbe29093d04cd6fd6b8 Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:28:47 -0000 --20cf307c9fbe29093d04cd6fd6b8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 31, 2012 at 10:02 AM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > As someone who has not (yet) stated an opinion on the matter, except I > also think option 3 is not good, I would very much like to hear technical > arguments, so if you have technical arguments against LOADng, I think we > need to hear them rather than just suggesting they exist. I haven't yet > read LOADng carefully to form a view there. I have just recently read the > AODVv2 draft carefully, and have some technical issues there (which > overlap) regarding asymmetric links, possible dependency on NHDP, and the > compatibility of options. If option 1 is followed, the draft needs work > (which Charlie has acknowledged).**** > > ** > > > I don't think we have time to waste with LOADng, it was presented twice and no progress, the authors failed to discuss on MANET list, and failed to update the draft to match MANET reuirements. I agree that we focus our efforts to submit AODVv2 as soon as possible, AB > > > -- **** > > Christopher Dearlove**** > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124**** > > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687**** > > ** ** > > *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On Behalf > Of *JP Vasseur (jvasseur) > *Sent:* 31 October 2012 08:29 > *To:* Joseph Macker > *Cc:* > *Subject:* Re: [manet] Reactive Protocol Situation**** > > ** ** > > ** ** > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.** > Keep this in mind if you answer this message. > Please see this processon how to deal with suspicious emails. > ***** > > Dear chairs, **** > > ** ** > > Remembering that I am not a co-authors of either of these drafts.**** > > ** ** > > *Not commenting on recent discussions but rather focussing on what I hope > will be a good solution for the WG and the Internet at large.***** > > ** ** > > Option 3) is my opinion *not* desirable; I wish we could have a reactive > routing protocol for MANET**** > > ** ** > > Option 2) is an option I would be *strongly* opposed to for a number of > technical reasons that I would be happy to elaborate on the**** > > mailing list and/or in a new I-D (which I would, should option 2 be > chosen).**** > > ** ** > > That being said, *I am extremely supportive of option 1)*, *especially in > light of what Charlie said*. First of all DYMO is the working group**** > > document and excellent progress has been made with recent revisions. But > even more importantly, Charlie managed to make it compatible **** > > with options, which is in my opinion *the best of both worlds*; calling > it AODVv2 is only not very sensible but avoids useful sensitivity around * > *** > > names.**** > > ** ** > > *Thus I would strongly support Option 1), continue the work that Charlie > has started*, which by the way is not far from completion. And **** > > as WG,we need to remember that this had been the WG document, the result > of years of work. Still by making it compatible with other options, **** > > this is technically flexible and sound.**** > > ** ** > > Thanks.**** > > ** ** > > JP.**** > > ** ** > > On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:**** > > > > **** > > Hello MANET working group (form Stan and Joe), > > As you are all probably aware, there has been WG activity lately on > competing drafts for a MANET reactive protocol - DYMO (reviving the current > working group document that was parked due to inactivity), and LOADng. Many > months ago there was a somewhat authorship led movement towards a common > document effort and given positive feedback at the time we the chairs > thought this was the best approach given the authors potential to come > together and gain the best of both efforts. Since that period, there has > been some fairly strident and rancorous "at times" debate between the > authors of the two documents. > > During IETF 84 in Vancouver, the co-chairs held a discussion with some of > the co-authors of the two documents. Our guidance to the co-authors was to > find a way to merge the two documents into one, as it was perceived that > are not technically far apart and they both derive roughly from AODV > concepts and LOADng had fairly active authorship and implementation > efforts. We provided a co-editing proposal to the authors and gave them the > timeframe of the Atlanta to come up with an answer back to us regarding > this. As of this writing, those discussions of a potential commonn > document and authorship merger have failed. > > Therefore, we find ourselves at a crossroads. The authors of the two > documents are divided, and it is unlikely that progress on a merged > document can be reached based upon recent author feedback. I have also > polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat > disengaged on the issue at the present time. We see only 3 possible paths > forward: > > 1. Continue the work on the DYMO document, starting with whether there is > consensus on its continued approach and also the desire to rename it to > AODVv2. > 2. Replace the existing DYMO document effort with the LOADng related > document effort, defusing ealier references to LLNs as recommended in the > last meeting minutes, and to focus more motivationally on general MANET > problem spaces (the authors seem to have agreed to this issue if its a WG > document). > 3. Remove the working group charter for a reactive protocol, effectively > killing both documents, at least from a working group (WG) standpoint. This > would not be a reflection on the technology in either case, just an > admission that we are not working together and reaching consensus. > > The co-chairs request and need your opinions on the options. We have been > some silent collecting initial feedback and waiting for author feedback at > this point. Stan and I are both on travel prior to Atlanta so our > responses may be sparse and we will also likely be in a "receive mode" for > a few days. So send your opinions. > > -Joe > _______________________________________________ > manet mailing list > manet@ietf.org > 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. > ******************************************************************** > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --20cf307c9fbe29093d04cd6fd6b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 31, 2012 at 10:02 AM, Dearlove, Chri= stopher (UK) <Chris.Dearlove@baesystems.com> wro= te:

As someone who has n= ot (yet) stated an opinion on the matter, except I also think option 3 is n= ot good, I would very much like to hear technical arguments, so if you have technical arguments against LOADng, I think we need to hear= them rather than just suggesting they exist. I haven't yet read LOADng= carefully to form a view there. I have just recently read the AODVv2 draft= carefully, and have some technical issues there (which overlap) regarding asymmetric links, possible dependen= cy on NHDP, and the compatibility of options. If option 1 is followed, the = draft needs work (which Charlie has acknowledged).

=A0

=A0

I don't think we have time to waste with = LOADng, it was presented twice and no progress, the authors failed to discu= ss on MANET list, and failed to update the draft to match MANET reuirements= . I agree that we focus our efforts to submit AODVv2 as soon as possible,
=A0
AB
=A0
=A0

=A0

--

Christopher Dearlove=

Senior Principal Eng= ineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesy= stems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

=A0

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur)
Sent: 31 October 2012 08:29
To: Joseph Macker
Cc: <manet@ie= tf.org>
Subject: Re: [manet] Reactive Protocol Situation

=A0

=A0

*** WARNING ***<= /span>

This message originates from outside ou= r organisation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

Dear chairs,

=A0

Remembering that I am not a co-authors of either of = these drafts.

=A0

Not commenting on recent discussions but rather f= ocussing on what I hope will be a good solution for the WG and the Internet= at large.

=A0

Option 3) is my opinion not desirable;= I wish we could have a reactive routing protocol for MANET

=A0

Option 2) is an option I would be strongly= opposed to for a number of technical reasons that I would be happy to = elaborate on the

mailing list and/or in a new I-D (which I would, sho= uld option 2 be chosen).

=A0

That being said, I am extremely supportive of opt= ion 1), especially in light of what Charlie said. First of all DYMO is the w= orking group

document and excellent progress has been made with r= ecent revisions. But even more importantly, Charlie managed to make it comp= atible=A0

with options, which is in=A0my opinion the best o= f both worlds; calling it AODVv2 is only not very sensible but avoids u= seful sensitivity around=A0

names.

=A0

Thus I would strongly support Option 1), continue= the work that Charlie has started, which by the way is not far from co= mpletion. And=A0

as WG,we need to remember that this had been the WG = document, the result of years of work. Still by making it compatible with o= ther options,=A0

this is technically flexible and sound.

=A0

Thanks.

=A0

JP.

=A0

On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:



Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.=A0 Since = that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active author= ship and implementation efforts. We provided a co-editing proposal to the a= uthors and gave them the timeframe of the Atlanta to come up with an answer= back to us regarding this.=A0 As of this writing, those discussions of a potential commonn document and aut= horship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.=A0 We see = only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.=A0 We have bee= n some silent collecting initial feedback and waiting for author feedback a= t this point.=A0 Stan and I are both on travel prior to Atlanta so our resp= onses may be sparse and we will also likely be in a "receive mode" for a few days.=A0 So send your op= inions.

-Joe
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

=A0


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


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--20cf307c9fbe29093d04cd6fd6b8-- From hrogge@googlemail.com Thu Nov 1 07:30:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B7821F8CD2 for ; Thu, 1 Nov 2012 07:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KSpcJ2a0sYj for ; Thu, 1 Nov 2012 07:30:57 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0094821F8B18 for ; Thu, 1 Nov 2012 07:30:53 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so1774095pad.31 for ; Thu, 01 Nov 2012 07:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OhhEpShkxST0+aZJdJZIaQpYKZZ8W+RzArAiAPcZWVE=; b=jMjTp2ripDxNAS9iXze7MUDxaZZ5kQl9YVtwux/nGQX+3squvbFwHE+HhdOp0egJq2 prcjRbRYa5BRtOJcuWqcqt88rMYizVYuHYzAfAXlDZU/nCkJ9xQPu+bt6Nl0qNs+JMCj JSIL5azAH3niaVZSPC7Z6ip3kUDa8/6X38aplL2RBo2FMqPWqGh9fneugzB7McPIC3p/ aL4CYc8VGn/7VCrNZPm7ztQ4LJUfBYZLgFDvSOeOmEAzu3xzSngLjaTlr3CvI2/lDlT9 UJUPPAYB0yotxz1Qq1R8sWzKAG+xYZxBgkyk+J5raV2Nd9z+dHK/hFddEmyOPm0FGUg2 sQIQ== Received: by 10.66.85.227 with SMTP id k3mr111478979paz.79.1351780253747; Thu, 01 Nov 2012 07:30:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Thu, 1 Nov 2012 07:30:33 -0700 (PDT) In-Reply-To: References: <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com> From: Henning Rogge Date: Thu, 1 Nov 2012 15:30:33 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:30:58 -0000 On Thu, Nov 1, 2012 at 3:28 PM, Abdussalam Baryun wrote: > I don't think we have time to waste with LOADng, it was presented twice and > no progress, the authors failed to discuss on MANET list, and failed to > update the draft to match MANET reuirements. I agree that we focus our > efforts to submit AODVv2 as soon as possible, I totally disagree with you. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Thu Nov 1 07:33:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8520021F8C7D for ; Thu, 1 Nov 2012 07:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQucazNb1eUQ for ; Thu, 1 Nov 2012 07:33:35 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA5E21F8C71 for ; Thu, 1 Nov 2012 07:33:35 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3046493vcb.31 for ; Thu, 01 Nov 2012 07:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MJN+1CotXx077lQVRZSVsEY37k2faI1Fw6Q0tf6KD0I=; b=iCXdoHghcViAZ0ifiEdp0oG2VYkmwu3ENQ/CChLIQpNWJTZMadqBnJJ2TYIGOQ9k3J 95lC299HO+CJhLUuxX06g558ZQw52B3hSI9qTI3fp0ygr/tkZMqbWTtodqoSe4VA5VQL zdM41QfrlY3pSEPkIDF5D4WbjADZzl6aMDrHoaR3OUu9nAwY9Jtxulc5hXoh8UaxnC/N jkCMmhIUwCTPJThZm0QHJ1kLiXh9cqejJIRl3nLTGWUfmxxQZRU5sYyYfhxiMO+DhmH7 fbO0XlniTAloS2/i/RIB4p4EEuLz2ANFpfNHWX5vIW70bFPwWUu8/BSnN6GrLoOOlHuJ JPrA== MIME-Version: 1.0 Received: by 10.58.137.7 with SMTP id qe7mr62222001veb.23.1351780415040; Thu, 01 Nov 2012 07:33:35 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 07:33:34 -0700 (PDT) In-Reply-To: References: <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com> Date: Thu, 1 Nov 2012 14:33:34 +0000 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7b5da80973ee0604cd6fe7a5 Cc: manet Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:33:36 -0000 --047d7b5da80973ee0604cd6fe7a5 Content-Type: text/plain; charset=ISO-8859-1 For discussion purpose, please give your reasons, so I can understand, I want that we not waste time and finish the work we were doing in years, AB On Thu, Nov 1, 2012 at 2:30 PM, Henning Rogge wrote: > On Thu, Nov 1, 2012 at 3:28 PM, Abdussalam Baryun > wrote: > > > I don't think we have time to waste with LOADng, it was presented twice > and > > no progress, the authors failed to discuss on MANET list, and failed to > > update the draft to match MANET reuirements. I agree that we focus our > > efforts to submit AODVv2 as soon as possible, > > I totally disagree with you. > > Henning Rogge > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > --047d7b5da80973ee0604cd6fe7a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For discussion purpose, please give your reasons, so I can understand,=
I want that we not waste time and finish the work we were doing = in years,
=A0
AB

On Thu, Nov 1, 2012 at 2:30 PM, Henning Rogge <hrogge@googlemail.com> wrote:
On Thu, Nov 1, 2012 at 3:28 PM, Abdussalam Baryun
<abdussalambaryun@gmail.co= m> wrote:

> I don't think we have time to waste with LOADng, it was presented = twice and
> no progress, the authors failed to discuss on MANET list, and failed t= o
> update the draft to match MANET reuirements. I agree that we focus our=
> efforts to submit AODVv2 as soon as possible,

I totally disagree with you.

Henning Rogge

--
Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that
was before the present government."

--047d7b5da80973ee0604cd6fe7a5-- From abdussalambaryun@gmail.com Thu Nov 1 07:44:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8716621F8AA4 for ; Thu, 1 Nov 2012 07:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uzj-UMt5XJra for ; Thu, 1 Nov 2012 07:44:52 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B537621F8A96 for ; Thu, 1 Nov 2012 07:44:52 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3060260vcb.31 for ; Thu, 01 Nov 2012 07:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BIcACjMh4UNYIhoow9+TT1ntGaFccDYfgw80W1jUIPA=; b=mjnWK959OGxng3rO7yL7LiErEHRB+j6RRAKCTbG4JnxKAU066RnLrnWueF5YAiwqiW by/D0FzoUPzpsdBTNJFcpQyJLHKn0zHjA7B8U18GEs0pCCMh4xTa012x/944Fi7HEulk HzeG7mWtegS3KvTA18NQQLv+dN2BRaOEQosMxAUL4/FQ/OYig93I5rJI7h6rIJW4g5Da /TpXt33Xokt2ZWZT3qxHamdt4/OlhhETgoV10wDap66kjGnDUh6mYY/28cRGCY2zDV6W U6l7dZ4nFsAOGGJzFOnl+vcbC0fMaScAUyo44zX6lqCTX+DpzS1wfJ3xhJ2p4J+LExf3 2xYg== MIME-Version: 1.0 Received: by 10.220.8.195 with SMTP id i3mr22750703vci.44.1351781091758; Thu, 01 Nov 2012 07:44:51 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 07:44:51 -0700 (PDT) In-Reply-To: References: <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7722042AFB@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A77220449D8@xmb-rcd-x02.cisco.com> Date: Thu, 1 Nov 2012 14:44:51 +0000 Message-ID: From: Abdussalam Baryun To: "" Content-Type: multipart/alternative; boundary=bcaec54fbbb8c9d3f504cd700fa5 Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:44:53 -0000 --bcaec54fbbb8c9d3f504cd700fa5 Content-Type: text/plain; charset=ISO-8859-1 I agree that it was clear in the 84 ( last MANET f2f discuss) meeting that LOADng was proposed for WG, but was not accepted and was recommended that it needs rework with discussions on the MANET list. I never understood mentioning that LOADng to be designed within an on-going work. AB On Wed, Oct 31, 2012 at 6:14 PM, Joseph Macker wrote: > Certainly if the LOADng derived work in whatever form is accepted by manet > it needs to be considered a manet protocol and analyzed and designed as > such in ongoing work. This point is non-negotiable and I think the chairs > made that clear at the last meeting but just to reiterate the point so we > do not need to keep going over that. > -------- > > Jiazi: As one chair, given my two year old review I felt DYMO-21 needed > significant work and revision to be ready for STD track submission. If you > feel DYMO-23 has regressed in some way in terms of clarity or specification > that makes me uneasy but I have less personal insight on that at present to > discuss. So other opinions would be welcome perhaps from an implementor's > perspective and a non-LOADng author's view. > > > --bcaec54fbbb8c9d3f504cd700fa5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree that it was clear in the 84 (=A0last MANET f2f discuss)=A0meet= ing that LOADng was proposed for WG, but=A0was not accepted and was recomme= nded that it needs rework with discussions on the MANET list.=A0I never=A0u= nderstood mentioning that LOADng to be designed within an on-going work.
AB
On Wed, Oct 31, 2012 at 6= :14 PM, Joseph Macker <jpmacker@gmail.com> wrote:
Certainly if the LOADng derived work in whatever form is accepted by manet = it needs to be considered a manet protocol and analyzed and designed as suc= h in ongoing work.=A0 This point is non-negotiable and I think the chairs m= ade that clear at the last meeting but just to reiterate the point so we do= not need to keep going over that.
--------

Jiazi: As one chair, given my two year old review I felt DY= MO-21 needed significant work and revision to be ready for STD track submis= sion. If you feel DYMO-23 has regressed in some way in terms of clarity or = specification that makes me uneasy but I have less personal insight on that= at present to discuss. So other opinions would be welcome perhaps from an = implementor's perspective and a non-LOADng author's view.


--bcaec54fbbb8c9d3f504cd700fa5-- From d.sturek@att.net Thu Nov 1 07:47:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14F721F8A91 for ; Thu, 1 Nov 2012 07:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.431 X-Spam-Level: X-Spam-Status: No, score=-1.431 tagged_above=-999 required=5 tests=[AWL=1.168, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iehi7r8124wa for ; Thu, 1 Nov 2012 07:47:51 -0700 (PDT) Received: from nm25-vm0.access.bullet.mail.mud.yahoo.com (nm25-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.191]) by ietfa.amsl.com (Postfix) with ESMTP id 4448A21F841B for ; Thu, 1 Nov 2012 07:47:51 -0700 (PDT) Received: from [66.94.237.199] by nm25.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Nov 2012 14:47:50 -0000 Received: from [68.142.198.204] by tm10.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Nov 2012 14:47:50 -0000 Received: from [127.0.0.1] by smtp105.sbc.mail.mud.yahoo.com with NNFMP; 01 Nov 2012 14:47:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1351781270; bh=6yCZeXOVmPgTA0K4AoQf/UCpH/y7gaYZZJFbgidW7wk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=tbLBnV0eEOn8mDozQvy5kv6tBhzKdaM7RDLLoYmcw08l5ai95IQSC6sQpQk2wuYZnku7wAqoiQNUsQlzDVVnNZXkrsKe3x8UZ+TasDckoAF0FiVgWfqcS8llvzx8sVElfvWyvdCf2bQgReb+JUHafEq5WURU0VS+bFU8hdmMHcA= X-Yahoo-Newman-Id: 903014.44832.bm@smtp105.sbc.mail.mud.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: EgTHOfgVM1l.UfnXyHBfCGtVgW.60CRlRFF2Ol1c35ZOcX_ AOs5Hddro81TDjRWOyr6xFyuKr00h95UUGlcCnZHydoytEky5Y5IbTgJysbM 0PbwVQL1qxo4VuHbupKKYH44QZMt7d9tK1e5H1NQ0nGz.I6xr5BeAyWNnfzM 6CVqOU4Xvb.MGnvZWEC7yoEmTnINUeSjjhK6MsRgIHo1q_epplyfkjKbQ23F jx2kxMHnrMNIpxydVnlTVvwC1MrpYFckvv5PcyxHpLYxUVR6pC_877wDijDO 0sPn9f3ENMMGpwoX46h60vLaECzgsC1_YvWcubtpqoSvpcPv_f6nBKvjqj5S uWMX9p84DRU291cfsD4H509aDpmBVOJM2PLwnMt7wW7lSrpGvNOeoAG2vpep R7XTF7agr0cWxxB7oswOTzm2y2CrgSBK.2NU5wBk7qAyRef6oaZyZqczUHmw Sb4N8zA1_iak6lCH0WQ-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.198] (d.sturek@69.105.136.31 with login) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 01 Nov 2012 07:47:50 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 01 Nov 2012 07:47:48 -0700 From: Don Sturek To: " List" Message-ID: Thread-Topic: Reactive Protocol - LOADng vs. AODVv2 at Atlanta In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [manet] Reactive Protocol - LOADng vs. AODVv2 at Atlanta X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:47:52 -0000 Why not just have presentations from both prospective solutions in Atlanta (LOADng and AODVv2) and let the WG decide between these options as a work plan to address the reactive protocol requirement in MANET: 1) Progress LOADng (which seems to be happening anyway) 2) Progress AODVv2 (which seems to have stalled for 2+ years but now there are promises to pick that up) 3) Merge AODVv2 and LOADng (which I think is impractical given e-mail reflector traffic....) Not working on a reactive protocol seems like the least desirable outcome. While there have been inputs for each possible path, it is unclear from the reflector what the consensus of the group is. Personally, it would be useful to hear in Atlanta about large scale deployments (eg, working code) from each to help the WG decide. I think all relevant technical information should be provided by Atlanta to help the WG make the right decision. Don From abdussalambaryun@gmail.com Thu Nov 1 07:53:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0267521F8D7C for ; Thu, 1 Nov 2012 07:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.748, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDA4pEKLkZ-d for ; Thu, 1 Nov 2012 07:53:24 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC9921F8D79 for ; Thu, 1 Nov 2012 07:53:24 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3089242vbb.31 for ; Thu, 01 Nov 2012 07:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=frAMOYilCvQH9UWy3E1BWot7TPWYaAnn8AeVQ6F2z7o=; b=qZ0xZXIKkhoEWK2SioXeLHlZSZMkduTzHO51/fxCihbIlC0d7HOipTprwz5ebf92ng e/skyVLggKVST4l2Hx8TvF46KlLX2tDjUUTsKVq3vso87lCwaMIKHGYij0ni9XfHXm9H DdWwaEA1o63nYMkH/JEDhiG4Ai0CIExd7RlW3OFEZkgoGoz6PaggRpYcYBIm1LKYj07R b/6QF9BfE6wkZ/0Ub/7A4Uu+spkJ7l0uU8og5+osTrE/nAKxPfXyWqwCsNZ0s/ivmPRE LKhnsFUtEjj/bmIGyG7RWdCpeybsdgNQ7p3Ab6Vb41OOR5VQWQP66K/3tn9jJri5neoz 5xNQ== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr51885676vdv.20.1351781603646; Thu, 01 Nov 2012 07:53:23 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 07:53:23 -0700 (PDT) In-Reply-To: <50916F40.3000804@computer.org> References: <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7722042AFB@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A77220449D8@xmb-rcd-x02.cisco.com> <50916F40.3000804@computer.org> Date: Thu, 1 Nov 2012 14:53:23 +0000 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=bcaec50162bd4c9df404cd702e3b Cc: "" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:53:25 -0000 --bcaec50162bd4c9df404cd702e3b Content-Type: text/plain; charset=ISO-8859-1 I like that we make addition options as you call one 1.5, because there is no doubt that there is an interest of LOADng in MANET WG. I will support the 1.5 option only after we finish our job of AODVv2 with submission. Another alternative 2.5 option can be to start checking WG consensus for working on a new reactive protocol that merges the two drafts. However, still prefer option 1, without interrupts. AB On Wed, Oct 31, 2012 at 6:34 PM, Charles E. Perkins wrote: > > Hello Joe and all, > > Thanks for reiterating this important point. I feel that some of the > discussion > is aimed at finding fault. For myself, I think that the LOADng effort has > made > a positive contribution. With some minor exceptions, LOADng is basically > compatible with AODVv2 (almost by design, since both were derived from > AODV). I reiterate that my goal for the WG reactive document would be to > retain compatibility with LOADng. In this way, the working group will > retain > the benefits of LOADng (by design), reducing the need for any mutually > exclusive choice of (1) or (2). I'd call this alternative (1.5). > > In the meantime, I continue to offer improvements to the existing AODVv2 > specification, and I am confident that the results will soon satisfy the > most > demanding level of scrutiny. > > Regards, > Charlie P. > > > On 10/31/2012 11:14 AM, Joseph Macker wrote: > >> Certainly if the LOADng derived work in whatever form is accepted by >> manet it needs to be considered a manet protocol and analyzed and designed >> as such in ongoing work. This point is non-negotiable and I think the >> chairs made that clear at the last meeting but just to reiterate the point >> so we do not need to keep going over that. >> -------- >> >> -- > Regards, > Charlie P. > > > ______________________________**_________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/**listinfo/manet > --bcaec50162bd4c9df404cd702e3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I like that we make=A0addition options as you call one 1.5, because th= ere is no doubt that there is an interest of LOADng in MANET WG. I will sup= port the 1.5 option only after we finish our job of AODVv2 with submission.=
=A0
Another alternative 2.5 option can=A0be to start checkin= g WG consensus for working on a new reactive protocol that merges the two= =A0drafts. However, still prefer option 1, without interrupts.
= =A0
AB

On Wed, Oct 31, 2012 at 6:3= 4 PM, Charles E. Perkins <charliep@computer.org> wrote:<= br>

Hello Joe and all,

Thanks for reiterating this important point. =A0I feel that some of the dis= cussion
is aimed at finding fault. =A0For myself, I think that the LOADng effort ha= s made
a positive contribution. =A0With some minor exceptions, LOADng is basically=
compatible with AODVv2 (almost by design, since both were derived from
AODV). =A0I reiterate that my goal for the WG reactive document would be to=
retain compatibility with LOADng. =A0In this way, the working group will re= tain
the benefits of LOADng (by design), reducing the need for any mutually
exclusive choice of (1) or (2). =A0I'd call this alternative (1.5).

In the meantime, I continue to offer improvements to the existing AODVv2 specification, and I am confident that the results will soon satisfy the mo= st
demanding level of scrutiny.

Regards,
Charlie P.


On 10/31/2012 11:14 AM, Joseph Macker wrote:
Certainly if the LOADng derived work in whatever form is accepted by manet = it needs to be considered a manet protocol and analyzed and designed as suc= h in ongoing work. =A0This point is non-negotiable and I think the chairs m= ade that clear at the last meeting but just to reiterate the point so we do= not need to keep going over that.
--------

--
Regards,
Charlie P.


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--bcaec50162bd4c9df404cd702e3b-- From jpmacker@gmail.com Thu Nov 1 07:57:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A097C21F8826 for ; Thu, 1 Nov 2012 07:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.959 X-Spam-Level: X-Spam-Status: No, score=-2.959 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcJweeZZDJUH for ; Thu, 1 Nov 2012 07:57:48 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 279A721F883C for ; Thu, 1 Nov 2012 07:57:47 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3076843vcb.31 for ; Thu, 01 Nov 2012 07:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jRvCTvLEBIqQygUEIEj9FeThGGppQS1oiPdPaqTlrSc=; b=eYxS2FoTVoD6LOFOtJbsOUbDrVvOvrPtpx2J4yYzWJA1P+u7mr86zNdTTax+gpFQSs I5van624kKHUSyt2HnE+ut+kaIp7tzMPcb9rXebkVDxHEEaJvXN05shYQ4AK6JoiV4zt Qb6vt2PFsI79c4DQMeDYI84/1RSHj1xYvmFkiVfdKN2+/pfn20lLQa0w1CXKnmaK8iF+ hoJuJO8uPrwi2P7d7VAh6KfSPG0EiEFv/ExMixphgR1zEwKqTg87KuixakgkwA2MxERw 9dCuJvBUmT7jyFZjikH3DvndEnOd0XA7xmxPpoGsjJqg9JdueQWqs6v/9OpEocSL3wYP IHSA== MIME-Version: 1.0 Received: by 10.220.150.82 with SMTP id x18mr23264834vcv.73.1351781866478; Thu, 01 Nov 2012 07:57:46 -0700 (PDT) Received: by 10.58.161.206 with HTTP; Thu, 1 Nov 2012 07:57:46 -0700 (PDT) In-Reply-To: References: <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com> Date: Thu, 1 Nov 2012 10:57:46 -0400 Message-ID: From: Joseph Macker To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=f46d043c7c1ef71c5a04cd703d8b Cc: manet Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:57:50 -0000 --f46d043c7c1ef71c5a04cd703d8b Content-Type: text/plain; charset=ISO-8859-1 Your facts are off. Actually reading the new LOADng update last night it looks like the authors did begin to modify it to meet some of the WG requirements for focus stated at the last meeting. What is your statement that they didnt update it based upon? Not saying its been vetted yet but they made the effort. On Thu, Nov 1, 2012 at 10:28 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > On Wed, Oct 31, 2012 at 10:02 AM, Dearlove, Christopher (UK) < > Chris.Dearlove@baesystems.com> wrote: > >> As someone who has not (yet) stated an opinion on the matter, except I >> also think option 3 is not good, I would very much like to hear technical >> arguments, so if you have technical arguments against LOADng, I think we >> need to hear them rather than just suggesting they exist. I haven't yet >> read LOADng carefully to form a view there. I have just recently read the >> AODVv2 draft carefully, and have some technical issues there (which >> overlap) regarding asymmetric links, possible dependency on NHDP, and the >> compatibility of options. If option 1 is followed, the draft needs work >> (which Charlie has acknowledged).**** >> >> ** >> >> >> > I don't think we have time to waste with LOADng, it was presented twice > and no progress, the authors failed to discuss on MANET list, and failed to > update the draft to match MANET reuirements. I agree that we focus our > efforts to submit AODVv2 as soon as possible, > > AB > > > >> >> >> -- **** >> >> Christopher Dearlove**** >> >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124**** >> >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687**** >> >> ** ** >> >> *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On >> Behalf Of *JP Vasseur (jvasseur) >> *Sent:* 31 October 2012 08:29 >> *To:* Joseph Macker >> *Cc:* >> *Subject:* Re: [manet] Reactive Protocol Situation**** >> >> ** ** >> >> ** ** >> >> **** WARNING **** >> >> *This message originates from outside our organisation, either from an >> external partner or the internet.** >> Keep this in mind if you answer this message. >> Please see this processon how to deal with suspicious emails. >> ***** >> >> Dear chairs, **** >> >> ** ** >> >> Remembering that I am not a co-authors of either of these drafts.**** >> >> ** ** >> >> *Not commenting on recent discussions but rather focussing on what I >> hope will be a good solution for the WG and the Internet at large.***** >> >> ** ** >> >> Option 3) is my opinion *not* desirable; I wish we could have a reactive >> routing protocol for MANET**** >> >> ** ** >> >> Option 2) is an option I would be *strongly* opposed to for a number of >> technical reasons that I would be happy to elaborate on the**** >> >> mailing list and/or in a new I-D (which I would, should option 2 be >> chosen).**** >> >> ** ** >> >> That being said, *I am extremely supportive of option 1)*, *especially >> in light of what Charlie said*. First of all DYMO is the working group*** >> * >> >> document and excellent progress has been made with recent revisions. But >> even more importantly, Charlie managed to make it compatible **** >> >> with options, which is in my opinion *the best of both worlds*; calling >> it AODVv2 is only not very sensible but avoids useful sensitivity around >> **** >> >> names.**** >> >> ** ** >> >> *Thus I would strongly support Option 1), continue the work that Charlie >> has started*, which by the way is not far from completion. And **** >> >> as WG,we need to remember that this had been the WG document, the result >> of years of work. Still by making it compatible with other options, **** >> >> this is technically flexible and sound.**** >> >> ** ** >> >> Thanks.**** >> >> ** ** >> >> JP.**** >> >> ** ** >> >> On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:**** >> >> >> >> **** >> >> Hello MANET working group (form Stan and Joe), >> >> As you are all probably aware, there has been WG activity lately on >> competing drafts for a MANET reactive protocol - DYMO (reviving the current >> working group document that was parked due to inactivity), and LOADng. Many >> months ago there was a somewhat authorship led movement towards a common >> document effort and given positive feedback at the time we the chairs >> thought this was the best approach given the authors potential to come >> together and gain the best of both efforts. Since that period, there has >> been some fairly strident and rancorous "at times" debate between the >> authors of the two documents. >> >> During IETF 84 in Vancouver, the co-chairs held a discussion with some of >> the co-authors of the two documents. Our guidance to the co-authors was to >> find a way to merge the two documents into one, as it was perceived that >> are not technically far apart and they both derive roughly from AODV >> concepts and LOADng had fairly active authorship and implementation >> efforts. We provided a co-editing proposal to the authors and gave them the >> timeframe of the Atlanta to come up with an answer back to us regarding >> this. As of this writing, those discussions of a potential commonn >> document and authorship merger have failed. >> >> Therefore, we find ourselves at a crossroads. The authors of the two >> documents are divided, and it is unlikely that progress on a merged >> document can be reached based upon recent author feedback. I have also >> polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat >> disengaged on the issue at the present time. We see only 3 possible paths >> forward: >> >> 1. Continue the work on the DYMO document, starting with whether there is >> consensus on its continued approach and also the desire to rename it to >> AODVv2. >> 2. Replace the existing DYMO document effort with the LOADng related >> document effort, defusing ealier references to LLNs as recommended in the >> last meeting minutes, and to focus more motivationally on general MANET >> problem spaces (the authors seem to have agreed to this issue if its a WG >> document). >> 3. Remove the working group charter for a reactive protocol, effectively >> killing both documents, at least from a working group (WG) standpoint. This >> would not be a reflection on the technology in either case, just an >> admission that we are not working together and reaching consensus. >> >> The co-chairs request and need your opinions on the options. We have >> been some silent collecting initial feedback and waiting for author >> feedback at this point. Stan and I are both on travel prior to Atlanta so >> our responses may be sparse and we will also likely be in a "receive mode" >> for a few days. So send your opinions. >> >> -Joe >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> 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. >> ******************************************************************** >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --f46d043c7c1ef71c5a04cd703d8b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Your facts are off. Actually reading the new LOADng update last night it lo= oks like the=20 authors did begin to modify it to meet some of the WG requirements for=20 focus stated at the last meeting.=A0 What is your statement that they=20 didnt update it based upon?=A0 Not saying its been vetted yet but they made= the effort.



On Thu, Nov 1, 2012 at 10:28 AM, Abdussalam Baryun <abduss= alambaryun@gmail.com> wrote:
On Wed, Oct 31, 2012 at 10:02 AM, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:

As someone who has n= ot (yet) stated an opinion on the matter, except I also think option 3 is n= ot good, I would very much like to hear technical arguments, so if you have technical arguments against LOADng, I think we need to hear= them rather than just suggesting they exist. I haven't yet read LOADng= carefully to form a view there. I have just recently read the AODVv2 draft= carefully, and have some technical issues there (which overlap) regarding asymmetric links, possible dependen= cy on NHDP, and the compatibility of options. If option 1 is followed, the = draft needs work (which Charlie has acknowledged).

=A0

=A0

I don't think we have time to waste= with LOADng, it was presented twice and no progress, the authors failed to= discuss on MANET list, and failed to update the draft to match MANET reuir= ements. I agree that we focus our efforts to submit AODVv2 as soon as possi= ble,
=A0
AB
=A0
=A0

=A0

--

Christopher Dearlove=

Senior Principal Eng= ineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124=

chris.dearlove@baesystems.com | http://www.baesy= stems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

=A0

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur)
Sent: 31 October 2012 08:29
To: Joseph Macker
Cc: <manet@ie= tf.org>
Subject: Re: [manet] Reactive Protocol Situation

=A0

=A0

*** WARNING ***<= /span>

This message originates from outside ou= r organisation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

Dear chairs,

=A0

Remembering that I am not a co-authors of either of = these drafts.

=A0

Not commenting on recent discussions but rather f= ocussing on what I hope will be a good solution for the WG and the Internet= at large.

=A0

Option 3) is my opinion not desirable;= I wish we could have a reactive routing protocol for MANET

=A0

Option 2) is an option I would be strongly= opposed to for a number of technical reasons that I would be happy to = elaborate on the

mailing list and/or in a new I-D (which I would, sho= uld option 2 be chosen).

=A0

That being said, I am extremely supportive of opt= ion 1), especially in light of what Charlie said. First of all DYMO is the w= orking group

document and excellent progress has been made with r= ecent revisions. But even more importantly, Charlie managed to make it comp= atible=A0

with options, which is in=A0my opinion the best o= f both worlds; calling it AODVv2 is only not very sensible but avoids u= seful sensitivity around=A0

names.

=A0

Thus I would strongly support Option 1), continue= the work that Charlie has started, which by the way is not far from co= mpletion. And=A0

as WG,we need to remember that this had been the WG = document, the result of years of work. Still by making it compatible with o= ther options,=A0

this is technically flexible and sound.

=A0

Thanks.

=A0

JP.

=A0

On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:



Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.=A0 Since = that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active author= ship and implementation efforts. We provided a co-editing proposal to the a= uthors and gave them the timeframe of the Atlanta to come up with an answer= back to us regarding this.=A0 As of this writing, those discussions of a potential commonn document and aut= horship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.=A0 We see = only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.=A0 We have bee= n some silent collecting initial feedback and waiting for author feedback a= t this point.=A0 Stan and I are both on travel prior to Atlanta so our resp= onses may be sparse and we will also likely be in a "receive mode" for a few days.=A0 So send your op= inions.

-Joe
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

=A0


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


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--f46d043c7c1ef71c5a04cd703d8b-- From jpmacker@gmail.com Thu Nov 1 08:02:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A826521F8D7C for ; Thu, 1 Nov 2012 08:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t95+PL1cogSL for ; Thu, 1 Nov 2012 08:02:31 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92D6721F8B2E for ; Thu, 1 Nov 2012 08:02:31 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3082972vcb.31 for ; Thu, 01 Nov 2012 08:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QpDi3I4K5DI/aW2JtnVX7mz/ttKDCIuO2fkQbBkEtNU=; b=n4wjOT6KTbj2ixD9+mfv/Pi8rTijmiaOKikDzVVgt5RoJDbgorffnX2FeNt7mFBmAR vlPtOSBizDec/R1xy0jPMBcpKfGXbuoSkdXdmc/l6C821BWxD/I/zuVJaqi/C/9ZG2Mq YeNwpe/E1tRzVPW64QpsjBW61ZR5fVz1pkzdSM5II2uGOkkV15I99OQcsret/UR5Bxky fCY1mugAUF0iCfhz9o5HnwOv0B7EOt8B/wY5FkDzQvMrGNshEBIlDQnmG5fxdRcjU61t VYFyeYDx2J7FyEpy5IgXzz6KhVsQr2O39wPP8XjZM1X6TzHUbcfomHPQ7CxzeUk7UZrX cDxA== MIME-Version: 1.0 Received: by 10.52.37.43 with SMTP id v11mr9301677vdj.29.1351782151102; Thu, 01 Nov 2012 08:02:31 -0700 (PDT) Received: by 10.58.161.206 with HTTP; Thu, 1 Nov 2012 08:02:31 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Nov 2012 11:02:31 -0400 Message-ID: From: Joseph Macker To: Don Sturek Content-Type: multipart/alternative; boundary=20cf30780a72ee211d04cd704ec8 Cc: " List" Subject: Re: [manet] Reactive Protocol - LOADng vs. AODVv2 at Atlanta X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:02:34 -0000 --20cf30780a72ee211d04cd704ec8 Content-Type: text/plain; charset=ISO-8859-1 Presentations will happen as your recommend. Co-chair, WG, and AD are important elements to discuss this with.. ------- My private opinions may align with yours. On Thu, Nov 1, 2012 at 10:47 AM, Don Sturek wrote: > > Why not just have presentations from both prospective solutions in Atlanta > (LOADng and AODVv2) and let the WG decide between these options as a work > plan to address the reactive protocol requirement in MANET: > 1) Progress LOADng (which seems to be happening anyway) > 2) Progress AODVv2 (which seems to have stalled for 2+ years but now > there are promises to pick that up) > 3) Merge AODVv2 and LOADng (which I think is impractical given e-mail > reflector traffic....) > > Not working on a reactive protocol seems like the least desirable outcome. > While there have been inputs for each possible path, it is unclear from > the reflector what the consensus of the group is. > > Personally, it would be useful to hear in Atlanta about large scale > deployments (eg, working code) from each to help the WG decide. I think > all relevant technical information should be provided by Atlanta to help > the WG make the right decision. > > Don > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf30780a72ee211d04cd704ec8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Presentations will happen as your recommend.
Co-chair, WG, and AD are im= portant elements to discuss this with..

-------
My private opinio= ns may align with yours.


On Thu, Nov 1, 2012 at 10:47 AM, Don Sturek <d.sturek@att.net> wrote:

Why not just have presentations from both prospective solutions in Atlanta<= br> (LOADng and AODVv2) and let the WG decide between these options as a work plan to address the reactive protocol requirement in MANET:
1) =A0Progress LOADng (which seems to be happening anyway)
2) =A0Progress AODVv2 (which seems to have stalled for 2+ years but now
there are promises to pick that up)
3) =A0Merge AODVv2 and LOADng (which I think is impractical given e-mail reflector traffic....)

Not working on a reactive protocol seems like the least desirable outcome.<= br> =A0 While there have been inputs for each possible path, it is unclear from=
the reflector what the consensus of the group is.

Personally, it would be useful to hear in Atlanta about large scale
deployments (eg, working code) from each to help the WG decide. =A0 I think=
all relevant technical information should be provided by Atlanta to help the WG make the right decision.

Don



_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf30780a72ee211d04cd704ec8-- From abdussalambaryun@gmail.com Thu Nov 1 08:13:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3007E21F8C9C for ; Thu, 1 Nov 2012 08:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.119 X-Spam-Level: X-Spam-Status: No, score=-3.119 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ye-T4QH4LkCV for ; Thu, 1 Nov 2012 08:13:41 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B75BA21F8C58 for ; Thu, 1 Nov 2012 08:13:39 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3096584vcb.31 for ; Thu, 01 Nov 2012 08:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CK2ozhMHunU7fGxg+Q3qoBl/7n/2zgBm1By9+yKdy6I=; b=rodBL6xZJuNb+vJs+90QYKuHPfIf23Kl0/L3pTDSJ5g1BxdhOFgzYLJkndK0K8IT6E v8L12bKbBbvIdprt4cgitooLpB/uAJVHf9DjDmo3m9C+EnTIumHkBQ8g3DysopnTPd6J aSsn8o8Ja/0mMhSlgg9IyORxb0oYqheCe/zwqZR7zH6kHG4m+X4yg2YmviJPDWhXgODz d3jTFNNVILbh7w5FsmxNxU7VrSACBdj3NRsmFHZ3cfGFZq+z/P0eXhOwQKIYpMcf4K/7 xYtdghrSmJnX8UoukT08qrhBcXfAudPJeXypkW/R4Md3aJfum6SD0EtVngy7JtxU25V1 HrGA== MIME-Version: 1.0 Received: by 10.220.16.12 with SMTP id m12mr45004845vca.14.1351782819065; Thu, 01 Nov 2012 08:13:39 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 08:13:38 -0700 (PDT) In-Reply-To: References: <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com> Date: Thu, 1 Nov 2012 15:13:38 +0000 Message-ID: From: Abdussalam Baryun To: Joseph Macker Content-Type: multipart/alternative; boundary=bcaec54b46c4be70cc04cd7076e7 Cc: manet Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:13:43 -0000 --bcaec54b46c4be70cc04cd7076e7 Content-Type: text/plain; charset=ISO-8859-1 Ok, if we read the inputs of the WG on the list, we can understand the conclusion I mentioned. It was not discussed by the WG, while I already tried my best with the authors, they postpone it. Please note that ignoring input is not acceptable, I got to 4th reminder. I agree that the last draft was better but still without valuable discussions. IMHO, this draft will need a full hour discussion because it is an interrupt work so far. The needed requirements and updates are: 1-Able to Discuss on the MANET list, not outside within companies 2-Replying to requests from the WG, not just with the chairs 3-The draft collides with ROLL WG which was clear in last 84 meeting 4-The name of the draft is not draft-manet, which was requested without respond from the authors. 5- The last meeting requested adding heterogeniety issue update to the draft, so will not collide with other works. AB On Thu, Nov 1, 2012 at 2:57 PM, Joseph Macker wrote: > Your facts are off. Actually reading the new LOADng update last night it > looks like the authors did begin to modify it to meet some of the WG > requirements for focus stated at the last meeting. What is your statement > that they didnt update it based upon? Not saying its been vetted yet but > they made the effort. > > > > > On Thu, Nov 1, 2012 at 10:28 AM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> On Wed, Oct 31, 2012 at 10:02 AM, Dearlove, Christopher (UK) < >> Chris.Dearlove@baesystems.com> wrote: >> >>> As someone who has not (yet) stated an opinion on the matter, except I >>> also think option 3 is not good, I would very much like to hear technical >>> arguments, so if you have technical arguments against LOADng, I think we >>> need to hear them rather than just suggesting they exist. I haven't yet >>> read LOADng carefully to form a view there. I have just recently read the >>> AODVv2 draft carefully, and have some technical issues there (which >>> overlap) regarding asymmetric links, possible dependency on NHDP, and the >>> compatibility of options. If option 1 is followed, the draft needs work >>> (which Charlie has acknowledged).**** >>> >>> ** >>> >>> >>> >> I don't think we have time to waste with LOADng, it was presented twice >> and no progress, the authors failed to discuss on MANET list, and failed to >> update the draft to match MANET reuirements. I agree that we focus our >> efforts to submit AODVv2 as soon as possible, >> >> AB >> >> >> >>> >>> >>> -- **** >>> >>> Christopher Dearlove**** >>> >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124**** >>> >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>> Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687**** >>> >>> ** ** >>> >>> *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On >>> Behalf Of *JP Vasseur (jvasseur) >>> *Sent:* 31 October 2012 08:29 >>> *To:* Joseph Macker >>> *Cc:* >>> *Subject:* Re: [manet] Reactive Protocol Situation**** >>> >>> ** ** >>> >>> ** ** >>> >>> **** WARNING **** >>> >>> *This message originates from outside our organisation, either from an >>> external partner or the internet.** >>> Keep this in mind if you answer this message. >>> Please see this processon how to deal with suspicious emails. >>> ***** >>> >>> Dear chairs, **** >>> >>> ** ** >>> >>> Remembering that I am not a co-authors of either of these drafts.**** >>> >>> ** ** >>> >>> *Not commenting on recent discussions but rather focussing on what I >>> hope will be a good solution for the WG and the Internet at large.***** >>> >>> ** ** >>> >>> Option 3) is my opinion *not* desirable; I wish we could have a >>> reactive routing protocol for MANET**** >>> >>> ** ** >>> >>> Option 2) is an option I would be *strongly* opposed to for a number of >>> technical reasons that I would be happy to elaborate on the**** >>> >>> mailing list and/or in a new I-D (which I would, should option 2 be >>> chosen).**** >>> >>> ** ** >>> >>> That being said, *I am extremely supportive of option 1)*, *especially >>> in light of what Charlie said*. First of all DYMO is the working group** >>> ** >>> >>> document and excellent progress has been made with recent revisions. But >>> even more importantly, Charlie managed to make it compatible **** >>> >>> with options, which is in my opinion *the best of both worlds*; calling >>> it AODVv2 is only not very sensible but avoids useful sensitivity around >>> **** >>> >>> names.**** >>> >>> ** ** >>> >>> *Thus I would strongly support Option 1), continue the work that >>> Charlie has started*, which by the way is not far from completion. And * >>> *** >>> >>> as WG,we need to remember that this had been the WG document, the result >>> of years of work. Still by making it compatible with other options, **** >>> >>> this is technically flexible and sound.**** >>> >>> ** ** >>> >>> Thanks.**** >>> >>> ** ** >>> >>> JP.**** >>> >>> ** ** >>> >>> On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:**** >>> >>> >>> >>> **** >>> >>> Hello MANET working group (form Stan and Joe), >>> >>> As you are all probably aware, there has been WG activity lately on >>> competing drafts for a MANET reactive protocol - DYMO (reviving the current >>> working group document that was parked due to inactivity), and LOADng. Many >>> months ago there was a somewhat authorship led movement towards a common >>> document effort and given positive feedback at the time we the chairs >>> thought this was the best approach given the authors potential to come >>> together and gain the best of both efforts. Since that period, there has >>> been some fairly strident and rancorous "at times" debate between the >>> authors of the two documents. >>> >>> During IETF 84 in Vancouver, the co-chairs held a discussion with some >>> of the co-authors of the two documents. Our guidance to the co-authors was >>> to find a way to merge the two documents into one, as it was perceived that >>> are not technically far apart and they both derive roughly from AODV >>> concepts and LOADng had fairly active authorship and implementation >>> efforts. We provided a co-editing proposal to the authors and gave them the >>> timeframe of the Atlanta to come up with an answer back to us regarding >>> this. As of this writing, those discussions of a potential commonn >>> document and authorship merger have failed. >>> >>> Therefore, we find ourselves at a crossroads. The authors of the two >>> documents are divided, and it is unlikely that progress on a merged >>> document can be reached based upon recent author feedback. I have also >>> polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat >>> disengaged on the issue at the present time. We see only 3 possible paths >>> forward: >>> >>> 1. Continue the work on the DYMO document, starting with whether there >>> is consensus on its continued approach and also the desire to rename it to >>> AODVv2. >>> 2. Replace the existing DYMO document effort with the LOADng related >>> document effort, defusing ealier references to LLNs as recommended in the >>> last meeting minutes, and to focus more motivationally on general MANET >>> problem spaces (the authors seem to have agreed to this issue if its a WG >>> document). >>> 3. Remove the working group charter for a reactive protocol, effectively >>> killing both documents, at least from a working group (WG) standpoint. This >>> would not be a reflection on the technology in either case, just an >>> admission that we are not working together and reaching consensus. >>> >>> The co-chairs request and need your opinions on the options. We have >>> been some silent collecting initial feedback and waiting for author >>> feedback at this point. Stan and I are both on travel prior to Atlanta so >>> our responses may be sparse and we will also likely be in a "receive mode" >>> for a few days. So send your opinions. >>> >>> -Joe >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> 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. >>> ******************************************************************** >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > --bcaec54b46c4be70cc04cd7076e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ok, if we read the inputs of the WG on the list, we can understand the= conclusion I mentioned.=A0It was not discussed by the WG, while I already = tried my best with the authors, they postpone it. Please note that ignoring= input is not acceptable, I got to 4th reminder. I agree that the last draf= t was better but still without valuable=A0discussions. IMHO, this draft wil= l need a full hour discussion because it is an interrupt work so far.
=A0
The needed requirements and updates=A0are:
=A0=
1-Able to Discuss on the MANET list, not outside within companie= s
2-Replying to requests from the WG, not just with the chairs
3-The draft collides with ROLL WG which was clear in last 84 meeting
4-The name of the draft is not draft-manet, which was requested wi= thout respond from the authors.
5- The last meeting requested add= ing heterogeniety issue update to the draft, so will not collide with other= works.
=A0
AB

On Thu, Nov 1= , 2012 at 2:57 PM, Joseph Macker <jpmacker@gmail.com> wrote= :
Your facts are off. Actually reading the new LOADng update last night it lo= oks like the=20 authors did begin to modify it to meet some of the WG requirements for=20 focus stated at the last meeting.=A0 What is your statement that they=20 didnt update it based upon?=A0 Not saying its been vetted yet but they made= the effort.




On Thu, Nov 1, 2012 at 10:28= AM, Abdussalam Baryun <abdussalambaryun@gmail.com>= wrote:
On Wed, Oct 31, 2012 at 10= :02 AM, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.= com> wrote:

As someone who has n= ot (yet) stated an opinion on the matter, except I also think option 3 is n= ot good, I would very much like to hear technical arguments, so if you have technical arguments against LOADng, I think we need to hear= them rather than just suggesting they exist. I haven't yet read LOADng= carefully to form a view there. I have just recently read the AODVv2 draft= carefully, and have some technical issues there (which overlap) regarding asymmetric links, possible dependen= cy on NHDP, and the compatibility of options. If option 1 is followed, the = draft needs work (which Charlie has acknowledged).

=A0

=A0

I don't think we have time to waste= with LOADng, it was presented twice and no progress, the authors failed to= discuss on MANET list, and failed to update the draft to match MANET reuir= ements. I agree that we focus our efforts to submit AODVv2 as soon as possi= ble,
=A0
AB
=A0
=A0

=A0

--

Christopher Dearlove=

Senior Principal Eng= ineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesy= stems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

=A0

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur)
Sent: 31 October 2012 08:29
To: Joseph Macker
Cc: <manet@ie= tf.org>
Subject: Re: [manet] Reactive Protocol Situation

=A0

=A0

*** WARNING ***<= /span>

This message originates from outside ou= r organisation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

Dear chairs,

=A0

Remembering that I am not a co-authors of either of = these drafts.

=A0

Not commenting on recent discussions but rather f= ocussing on what I hope will be a good solution for the WG and the Internet= at large.

=A0

Option 3) is my opinion not desirable;= I wish we could have a reactive routing protocol for MANET

=A0

Option 2) is an option I would be strongly= opposed to for a number of technical reasons that I would be happy to = elaborate on the

mailing list and/or in a new I-D (which I would, sho= uld option 2 be chosen).

=A0

That being said, I am extremely supportive of opt= ion 1), especially in light of what Charlie said. First of all DYMO is the w= orking group

document and excellent progress has been made with r= ecent revisions. But even more importantly, Charlie managed to make it comp= atible=A0

with options, which is in=A0my opinion the best o= f both worlds; calling it AODVv2 is only not very sensible but avoids u= seful sensitivity around=A0

names.

=A0

Thus I would strongly support Option 1), continue= the work that Charlie has started, which by the way is not far from co= mpletion. And=A0

as WG,we need to remember that this had been the WG = document, the result of years of work. Still by making it compatible with o= ther options,=A0

this is technically flexible and sound.

=A0

Thanks.

=A0

JP.

=A0

On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:



Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.=A0 Since = that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active author= ship and implementation efforts. We provided a co-editing proposal to the a= uthors and gave them the timeframe of the Atlanta to come up with an answer= back to us regarding this.=A0 As of this writing, those discussions of a potential commonn document and aut= horship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.=A0 We see = only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.=A0 We have bee= n some silent collecting initial feedback and waiting for author feedback a= t this point.=A0 Stan and I are both on travel prior to Atlanta so our resp= onses may be sparse and we will also likely be in a "receive mode" for a few days.=A0 So send your op= inions.

-Joe
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

=A0


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


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



--bcaec54b46c4be70cc04cd7076e7-- From abdussalambaryun@gmail.com Thu Nov 1 08:20:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5EF21F8DF2 for ; Thu, 1 Nov 2012 08:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.406 X-Spam-Level: X-Spam-Status: No, score=-3.406 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1gUTkdUR2J2 for ; Thu, 1 Nov 2012 08:20:13 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 293A521F8B36 for ; Thu, 1 Nov 2012 08:20:13 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3122826vbb.31 for ; Thu, 01 Nov 2012 08:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RDMlccZWDF032/ipHRPRdZMlm8oVrUqJK5oG+fZ2z40=; b=umxJ1OKGdH4GvCBfrUrYgDQ5yuZtGlmAygdWMAw7qBQY/yn2e9gX01oH60lmmxq7hq Oz47UGDzQ8EumBfKrzJOv3WIz9DrhOHfUI1SwhAkatkK5h67nPRgDzX7mKyCB5m98aHt xTX19RZRAnrQXZMwAIyWGJUDBecBDvCar1Hx1Yo8zAFk6wGlKEnRydRdLbuvF8AO6f+Z NYBxfWevFkAZp7pWBjWQ3Md5dJBjZw5f/Abw8h16lBnm8Ms+spQEuGa12HwtD38vhr94 H6zNQ1RhAdQDwTkr71sAQxazZXzUQf5Qtw+qk0CMmMvn3OAfgJNiRiAEzy7ESrzd0V2R yhdg== MIME-Version: 1.0 Received: by 10.52.77.101 with SMTP id r5mr51241894vdw.25.1351783212477; Thu, 01 Nov 2012 08:20:12 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 08:20:12 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Nov 2012 15:20:12 +0000 Message-ID: From: Abdussalam Baryun To: Don Sturek Content-Type: multipart/alternative; boundary=20cf307abd93316cd304cd708eaf Cc: " List" Subject: Re: [manet] Reactive Protocol - LOADng vs. AODVv2 at Atlanta X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:20:14 -0000 --20cf307abd93316cd304cd708eaf Content-Type: text/plain; charset=ISO-8859-1 I disagree with the present of LOADng, because it will need a full hour discussion and will waste time as it already did twice. I recommend its polace to discuss SHOULD be first on the MANET list (as required by MANET Chair before but not followed). However, I agree that the Chairs and AD are kindly recommended to organise the meeting and to make it efficient and progress mostly the WG works without other companies issues. AB On Thu, Nov 1, 2012 at 2:47 PM, Don Sturek wrote: > > Why not just have presentations from both prospective solutions in Atlanta > (LOADng and AODVv2) and let the WG decide between these options as a work > plan to address the reactive protocol requirement in MANET: > 1) Progress LOADng (which seems to be happening anyway) > 2) Progress AODVv2 (which seems to have stalled for 2+ years but now > there are promises to pick that up) > 3) Merge AODVv2 and LOADng (which I think is impractical given e-mail > reflector traffic....) > > Not working on a reactive protocol seems like the least desirable outcome. > While there have been inputs for each possible path, it is unclear from > the reflector what the consensus of the group is. > > Personally, it would be useful to hear in Atlanta about large scale > deployments (eg, working code) from each to help the WG decide. I think > all relevant technical information should be provided by Atlanta to help > the WG make the right decision. > > Don > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf307abd93316cd304cd708eaf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I disagree with the present of LOADng, because it will need a full hou= r discussion and will waste time as it already did twice. I recommend its p= olace to discuss SHOULD be first on the MANET list (as required by MANET Ch= air before but not followed).
=A0
However, I agree that the Chairs and AD are kindly=A0rec= ommended to organise the meeting and to make it efficient and progress most= ly the WG works without other companies issues.
=A0
AB<= br>
On Thu, Nov 1, 2012 at 2:47 PM, Don St= urek <d.sturek@att.net> wrote:

Why not just have presentations from both prospective solutions in Atlanta<= br> (LOADng and AODVv2) and let the WG decide between these options as a work plan to address the reactive protocol requirement in MANET:
1) =A0Progress LOADng (which seems to be happening anyway)
2) =A0Progress AODVv2 (which seems to have stalled for 2+ years but now
there are promises to pick that up)
3) =A0Merge AODVv2 and LOADng (which I think is impractical given e-mail reflector traffic....)

Not working on a reactive protocol seems like the least desirable outcome.<= br> =A0 While there have been inputs for each possible path, it is unclear from=
the reflector what the consensus of the group is.

Personally, it would be useful to hear in Atlanta about large scale
deployments (eg, working code) from each to help the WG decide. =A0 I think=
all relevant technical information should be provided by Atlanta to help the WG make the right decision.

Don



_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf307abd93316cd304cd708eaf-- From abdussalambaryun@gmail.com Thu Nov 1 08:30:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C78A21F8D91 for ; Thu, 1 Nov 2012 08:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eec892KQgfju for ; Thu, 1 Nov 2012 08:30:22 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2572B21F8D8E for ; Thu, 1 Nov 2012 08:30:22 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3136226vbb.31 for ; Thu, 01 Nov 2012 08:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=usgaRO342KY+KCqht5mzBPKnZ0O+w4GOiPL0BVsnNqc=; b=z5+wK0RzWy/dEB65HKi5Ijc9fKALu8rHOGkJCz4HthMQ0QHK1AdswQrJvTSSSnBuMn e2bYhX7NxCafypr+FTS8STpJepH7MVKG53idvBqrBWb24RWkRCT9vCPFn52HJk1tf2L2 UsFCx6ncEuMLum5/4VHK+NxRyUdSPDLXWHJPxA7oUPYCWSM1NCvMR/UsBaeWZ8uJJNRi EEKx3z4TNgB1rY0HnHZB6bcZfxR5ipeOm8hbLPKGGKjEJ0mzQlChiQ/tZxXHAsc/tAdy kyWz9osNYmRlL53LbmCJwY0sfczWkbXgMqBOMSeF0ewuJg3AFTigassJM5VvaDIHawkO Ld7g== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr52031049vdv.20.1351783821196; Thu, 01 Nov 2012 08:30:21 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 08:30:21 -0700 (PDT) In-Reply-To: References: <5091D7A0.8090808@computer.org> Date: Thu, 1 Nov 2012 15:30:21 +0000 Message-ID: From: Abdussalam Baryun To: Joseph Macker Content-Type: multipart/alternative; boundary=bcaec50162bd79bfb704cd70b24b Cc: "manet@ietf.org" Subject: Re: [manet] Slides please X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:30:23 -0000 --bcaec50162bd79bfb704cd70b24b Content-Type: text/plain; charset=ISO-8859-1 I disagree to put our WG draft with an individual draft within reactive protocol, we SHOULD separate discussions, or we can discuss the WG draft DYMO including merging other ideas into it (LOADng idea not draft). Any individual draft SHOULD be in the end. I think any action out of the WG agreement should be reported as complain. AB On Thu, Nov 1, 2012 at 2:34 AM, Joseph Macker wrote: > Yes slots for DYMO and LOADng authors were both requested and will be > accomodated. > We left ample time for reactive discussion on the schedule. > > -Joe > > > > On Wed, Oct 31, 2012 at 10:29 PM, Ulrich Herberg wrote: > >> Hello Charlie, >> >> I wrote this email in my function as WG secretary. It is up to the chairs >> to decide the slots and who presents. I simply upload the slides and assist >> the chairs with organizing the meeting. >> >> Best regards >> Ulrich >> >> >> On Wed, Oct 31, 2012 at 7:00 PM, Charles E. Perkins < >> charliep@computer.org> wrote: >> >>> >>> Hello Ulrich, >>> >>> If I can make a presentation about AODVv2, I would like to do that. >>> >>> Regards, >>> Charlie P. >>> >>> >>> >>> On 10/31/2012 4:00 PM, Ulrich Herberg wrote: >>> >>> Hello, >>> >>> for those who present at the MANET meeting: please send your slides >>> (in ppt or pdf) to the chairs and me. Please send them by this weekend, so >>> that I can upload the slides on Sunday. >>> >>> Thank you >>> Ulrich >>> >>> >>> _______________________________________________ >>> manet mailing listmanet@ietf.orghttps://www.ietf.org/mailman/listinfo/manet >>> >>> >>> >>> -- >>> Regards, >>> Charlie P. >>> >>> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --bcaec50162bd79bfb704cd70b24b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I disagree to put our WG draft with an individual draft within reactiv= e protocol, we SHOULD separate discussions, or we can discuss the WG draft = DYMO including=A0merging other ideas into it (LOADng idea not draft). Any i= ndividual draft SHOULD be in the end. I think any action out of the WG agre= ement should be reported as complain.
=A0
AB

On Thu, Nov 1= , 2012 at 2:34 AM, Joseph Macker <jpmacker@gmail.com> wrote= :
Yes slots for DYMO and LOADng authors were both requested and will be accom= odated.
We left ample time for reactive discussion on the schedule.
<= br>-Joe



On Wed, Oct 31, 2012 at 10:29 PM, Ulrich= Herberg <ulrich@herberg.name> wrote:
Hello Charlie,

I wrote this email in my= function as WG secretary. It is up to the chairs to decide the slots and w= ho presents. I simply upload the slides and assist the chairs with organizi= ng the meeting.

Best regards
Ul= rich


On Wed, Oct = 31, 2012 at 7:00 PM, Charles E. Perkins <charliep@computer.org>= wrote:
=20 =20 =20

Hello Ulrich,

If I can make a presentation about AODVv2, I would like to do that.

Regards,
Charlie P.



On 10/31/2012 4:00 PM, Ulrich Herberg wrote:
Hello,

for those who present at the MANET meeting: please send your slides (in ppt or pdf) to the chairs and me. Please send them by this weekend, so that I can upload the slides on Sunday.

Thank you
Ulrich


_______________________________________________
manet mailing list
manet@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/manet



--=20
Regards,
Charlie P.


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--bcaec50162bd79bfb704cd70b24b-- From jblack.ietf@yahoo.com Thu Nov 1 08:32:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B06621F8DE6 for ; Thu, 1 Nov 2012 08:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.64 X-Spam-Level: X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[AWL=1.958, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1N8vV4sD7HQR for ; Thu, 1 Nov 2012 08:32:18 -0700 (PDT) Received: from nm11-vm0.bullet.mail.bf1.yahoo.com (nm11-vm0.bullet.mail.bf1.yahoo.com [98.139.213.136]) by ietfa.amsl.com (Postfix) with ESMTP id B5B3021F8DE4 for ; Thu, 1 Nov 2012 08:32:17 -0700 (PDT) Received: from [98.139.212.150] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 15:32:17 -0000 Received: from [98.139.212.211] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 15:32:17 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 15:32:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 50399.24883.bm@omp1020.mail.bf1.yahoo.com Received: (qmail 51869 invoked by uid 60001); 1 Nov 2012 15:32:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351783936; bh=M4VbCDWe/NYdIb7MSZWdnGatlMz1soY07/jgVlFMoMI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=h0QD4P4uGiH1SuX6xklXi4srsf3JRirpenjqgPTpu6j9LoGq+MIDJiNNfEly/MKzV7iV7yq5SxfJxq4jQeOfsz58ffBwmmRt69M6QNlpiWnVMh8NYakTsMU+X9YXW2+jhEV9Dhle6UrN9qN8BerPlaKPzmu+qHTt5wV8xqd6IJY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=L87RRcb2KPvwwG+YqZIMnywp+yJscVEpAWzAQGUW3OfFCj0cWeeXlrgFZ9cydf802PPDeat2a5VSaZvs6d5lXvd5caRABUMzadFieiucEwRstUgu+1rHTi9iz5gEpv9BGr4qYPOR6A4UggVU98yIO38D4RM0I4HgnQ4TRE5YKoE=; X-YMail-OSG: SLGi2roVM1kLCkbS7hVkMRj9d49ArVjiP468UHjwLMntCM5 rBI2DmmtPku8m4ASWBu7Fg4i8dgg4NNbzhjTGPJjocETUm.SeRQng9SenDlM CaohstK2M2VT98GyaJ8ISsFYUMzsBkydH749j22TAYY6rFj4GotPdmwIuTUn gS._9iGHMD_FNTdWw_7VAhD9B2EUR9JVLo7.BV5mAcZirKsUJQyvVjbIHHL2 U1r0kh.tcX0FsF9C9ZdxgwAj7pvryOqbx4qljX4y8Ka2Sb1Eje7.REGF0j9t XWeuAL_m.MUsHWN_oU6POsF369y.Lt4EU8NaC40ACfjAHqB5uPn0wlcRvilo S58kDYvgxNckODUngERBroL.zcq8WaCsMBFG0WU8jPD3t6a5qErFYTwuJU7e t5crW7zq8CDOil_QY3NFuPIbQ9nTj8v5HO.hm25HjXuowifz.iwgZ9ARFrlQ ry0NPYg-- Received: from [67.213.218.74] by web160601.mail.bf1.yahoo.com via HTTP; Thu, 01 Nov 2012 08:32:16 PDT X-Rocket-MIMEInfo: 001.001, CgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogSlAgVmFzc2V1ciAoanZhc3NldXIpIDxqdmFzc2V1ckBjaXNjby5jb20.ClRvOiBKb24gQmxhY2sgPGpibGFjay5pZXRmQHlhaG9vLmNvbT4gCkNjOiAibWFuZXRAaWV0Zi5vcmciIDxtYW5ldEBpZXRmLm9yZz47ICJ0aGllcnJ5Lmx5c0BlcmRmZGlzdHJpYnV0aW9uLmZyIiA8dGhpZXJyeS5seXNAZXJkZmRpc3RyaWJ1dGlvbi5mcj4gClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxLCAyMDEyIDM6NDEgQU0KU3ViamVjdDogUmU6IFsBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> Message-ID: <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> Date: Thu, 1 Nov 2012 08:32:16 -0700 (PDT) From: Jon Black To: "JP Vasseur \(jvasseur\)" In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1737431079-776138881-1351783936=:31212" Cc: "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:32:19 -0000 --1737431079-776138881-1351783936=:31212 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A=0A________________________________=0A From: JP Vasseur (jvasse= ur) =0ATo: Jon Black =0ACc: "ma= net@ietf.org" ; "thierry.lys@erdfdistribution.fr" =0ASent: Thursday, November 1, 2012 3:41 AM=0ASubj= ect: Re: [manet] (no subject)=0A =0A=0AHi Jon, =0A=0A=0AOn Nov 1, 2012, at = 12:39 AM, Jon Black wrote:=0A=0AYes it shows that it does work in a rather = large deployment.=C2=A0 =0A=0AJP> This is not just a question of "how large= " it is =E2=80=A6 but also how dynamic. I could show you few hundreds (if n= ot less number of nodes)=0Anot working if the traffic pattern is too dynami= c. This is a fundamental problem.=0A=0A[Jon] Are you saying that their AMI = PLC deployment was not dynamic?=0A=0A=0AI have heard others say that it wor= ks in other deployments as well - just the same as you say RPL works in som= e deployments.=0A>=0A>=0A=0AJP> I do not not think that we should go in a R= PL versus Load-NG debate but rather try to find a good solution for MANET. = That being=0Asaid, RPL *for* LLNs the the result of a 4-year work with a DT= , weekly calls, interim WG meetings to make it work in LLNs.=0A=0A[Jon] I d= id not cast this as a RPL vs LOADng debate - you just did.=C2=A0 I am sayin= g that LOADng works in some scenarios and proof is the EDF deployment in th= eir AMI network.=0A=0A=0APlease share your results.=C2=A0 You keeps saying = you will and you we keep asking you to - where's the results so they can be= reviewed.=0A>=0A>=0A>=0A=0AJP> Once again, I would first like to hear chai= r's decision. PLEASE note that I would be happy to see Load's results too. = And just be=0Apatient, I just need to find a bit of time to compile results= and you will get many results backing up my claims. Please also refer to t= he=0Anumber of discussions prior to designing RPL that took place on the RO= LL mailing list. Believe me there was a reason not NOT choosing=0Aa reactiv= e protocol for LLN (again I am NOT against reactive routing for other use c= ases at all). Would you ignore the findings of a WG=0Athat worked for 4 yea= rs on the subject matter ? I guess not =E2=80=A6 Just trying to raise my vo= ice (as many others on this list) to protect the=0AInternet.=0A=0A[Jon] As = others have said - you have it backwards.=C2=A0 If you have data that would= show that LOADng or a reactive protocol will not work in MANETs please sha= re it.=C2=A0 That would be=0Avery insightful and would help guide this disc= ussion and decision.=C2=A0 It would not be prudent to make a decision and t= hen bring out data that would try to suggest that the decision was incorrec= t.=0A=0AWhat findings are you referring to?=C2=A0 Where is there a WG docum= ent that documents these findings? =0A=0A=0AThanks.=0A=0AJP.=0A=0AJon=0A>= =0A>=0A>=0A>=0A>=0A>________________________________=0A> From: JP Vasseur (= jvasseur) =0A>To: Jon Black =0A= >Cc: "manet@ietf.org" ; "thierry.lys@erdfdistribution.fr" <= thierry.lys@erdfdistribution.fr> =0A>Sent: Wednesday, October 31, 2012 4:09= PM=0A>Subject: Re: [manet] (no subject)=0A>=0A>=0A>=0A>=0A>On Oct 31, 2012= , at 6:57 PM, Jon Black wrote:=0A>=0A>On October 31, 2012 Thierry.Lys wrote= :=0A>>=0A>>=0A>>I speak in the name of EDF group. =0A>>=0A>>We started firs= t to use LOAD as a routing algorithm and deployed 2000 PLC-meters for smart= grid purposes in 2011. Taking advantage of this field test, we have been a= ctively participating to the working group to adopt enhancements in the LOA= Dng specification. =0A>>We are now extremely pleased with what LOADng is ca= pable of and are confident that future deployements will be equipped with i= t.=C2=A0=0A>>=0A>>=0A>>This would seem to indicate that LOADng does work an= d in a rather large deployment.=0A>>=0A>=0A>=0A>JP> No this means that Load= NG works in *a* network. But the major technical difference here is that re= active routing is highly impacted=0A>by the user traffic =E2=80=A6 If you p= oll a meter every 24 hours, it may work perfectly well. Now if you start ha= ving more frequent traffic flows=0A>you can either cache paths (ending up w= ith more frequent broken paths considering how flappy these networks are, t= hus leading to more=0A>floods =E2=80=A6 very undesirable =E2=80=A6 especial= ly when you have hundreds of meters sharing a few Kbits/s) or you use short= cache timers and you=0A>keep flooding :-( If you take actual traces of the= se networks (both using 15.4g and P1901.2) and you start adjusting the user= traffic rate you=0A>immediately see the issues in terms of scalability. Ye= s you can try to mitigate the undesirable flooding effect to some extends b= ut showing=C2=A0=0A>the limits in terms of scalability is easy to show. Not= e that I MOT against reactive routing by any means, this is IMO just not ap= plicable to=0A>LLNs unless the traffic flows are deterministic and very wel= l knows =E2=80=A6 Lessons from the past show us how difficult it is to pred= ict user=C2=A0=0A>applications. We all started with meter reading to contin= ue with that example and now many utilities wants to use these smart meteri= ng=C2=A0=0A>networks for a number of applications which different SLA, =E2= =80=A6=C2=A0=0A>=0A>=0A>Hope this helps. Once again, when/if required I wou= ld be happy to share many results.=0A>=0A>=0A>=0A>=0A>>"We believe in rough= consensus and running code" =0A>>=0A>>rough consensus : Don't you think we= have a rough consensus on LOADng compared to DYMO ? 10 authors and major c= ompanies are supporters of LOADng. =0A>>=0A>>running code : interoperabilit= y has been checked with 4 sources and other implementations are in progress= . =0A>>=0A>>Obviously from the list we don't have rough consensus.=C2=A0 We= have two alternatives each with proponents.=C2=A0 The WG should weigh the = technical benefits (design, implementation/running code, maturity)=C2=A0 of= each and the group should choose a path forward.=0A>>=0A>>In my opinion op= tion 3 is not an option - this is the working group shirking its responsibi= lity.=0A>>=0A>=0A>=0A>This is an option =E2=80=A6 since listed by the chair= s. I agree that we should avoid it, especially when I think we have a very = reasonable solution=0A>(option1).=0A>=0A>=0A>JP.=0A>=0A>=0A>>Jon=0A>> =0A>>= =0A>>=0A_______________________________________________=0A>>manet mailing l= ist=0A>>manet@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/manet=0A>>= =0A>=0A>=0A> --1737431079-776138881-1351783936=:31212 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0A=0A

<= /div> --1737431079-776138881-1351783936=:31212-- From jblack.ietf@yahoo.com Thu Nov 1 08:37:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC7421F8DF2 for ; Thu, 1 Nov 2012 08:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.292 X-Spam-Level: X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[AWL=1.306, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf7qB1HbTRxe for ; Thu, 1 Nov 2012 08:37:33 -0700 (PDT) Received: from nm23.bullet.mail.bf1.yahoo.com (nm23.bullet.mail.bf1.yahoo.com [98.139.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7C53021F8DF1 for ; Thu, 1 Nov 2012 08:37:32 -0700 (PDT) Received: from [98.139.212.153] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 15:37:31 -0000 Received: from [98.139.212.243] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 15:37:31 -0000 Received: from [127.0.0.1] by omp1052.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 15:37:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 769577.16362.bm@omp1052.mail.bf1.yahoo.com Received: (qmail 59416 invoked by uid 60001); 1 Nov 2012 15:37:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351784251; bh=gwofqw3sGtb+ulQ0Cf8/oJV870XKtfY4Q9/+c+v4Fv4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xe34qQ0/QgxXQVs2B5CXzGwKxkDGqZpg5YSWskiMJQup6hKzeZdb+mNKsIiCWwdx0Hez8aSgRfnMU7ftRBKyYp4sZQW6SzF5uIirlKYNbylquU1TJVe8ELewOOjI9KEgxJs3In1Fzy7BkBJb7aFDDY+oAY/sMmKumzVlY8NDvzo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=f0Wh6x8vDXYmxAPSUxaax/3tzzSSqvUoL2FRXcjkjDElsmply8dNJ2uDfRoR7LvzNDoyZfSADBDD+dQE0P/a9eXHhWBAVLl0J6nE420fzTXE5YR0qOWuQHyG2CqUVPGzcBGq0dPkWtbqMn23rwZTpuWmGF7E7CuD16SoMQmqeEI=; X-YMail-OSG: XrY4Sb8VM1lvMjWfAr2ANu7Xlv4t3wIwUtU1aubV2MwPI4P .dsHKHadFkq9kCazVw3Lc1MBWmGGjBZ2fDAtKUchT0zir3qZ1jNAeGRt6N.s rXoeX_qMRlBTwUY4TOxbH02WJwnNojWA3VITEEQTwUT8FhmaDFDQvz8LvR_N T_bRJAY9Fqi60C2Qb7jww5piPtaOidinP8OOhHZduLlK9yyvjj9msCI87X98 bNFyWvhUb8gVD18lmS5xlIawya_tPutXdABBCtYvWiPWMzgudGgomyYkKHEU AcqHQzK8O6Vi1PIfz9.PLr1NaOjej8MugL2iw2YSFXUr9VAV1kkTVD4Eo.TT b6eB8wX1yIxoELs_kVnutLwjhu7HxA2pxG0BzaYWEgVTtl9Hw7e9Wo6neaHL C1goUrkAnlLlSvDBuMk7oiVvJ_86KMEjOHgUHA9KUNWi8nTP80Ev7oMUuelH yrIvVtw-- Received: from [67.213.218.74] by web160605.mail.bf1.yahoo.com via HTTP; Thu, 01 Nov 2012 08:37:31 PDT X-Rocket-MIMEInfo: 001.001, V2h5IHdvdWxkIHlvdSB0aGluayB0aGF0IExPQURuZyBpcyBub3QgcmVhY3RpdmU_wqAgSWYgaXQgaXMgbm90IGEgcmVhY3RpdmUgcHJvdG9jb2wsIHRoZW4gd2hhdCBpcyBpdD8KCkFzIHRvIG1lcmdpbmcgdGhlIGRvY3VtZW50cywgdGhpcyBpcyB3aGF0IFdHcyBkby7CoCBJZiB5b3UgaGF2ZSBtdWx0aXBsZSAiY29tcGV0aW5nIiBpZGVhcyB5b3UgYXNrIHRoZSBhdXRob3JzIHRvIHNlZSBpZiB0aGV5IGNhbiBtZXJnZSB0aGVpciBjb25jZXB0cyBhbmQgaWRlYXMuwqAgSWYgdGhleSBjYW5ub3Qgb3Igd2lsbCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: Message-ID: <1351784251.48543.YahooMailNeo@web160605.mail.bf1.yahoo.com> Date: Thu, 1 Nov 2012 08:37:31 -0700 (PDT) From: Jon Black To: Abdussalam Baryun , Joseph Macker In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1933122451-260341018-1351784251=:48543" Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:37:34 -0000 ---1933122451-260341018-1351784251=:48543 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Why would you think that LOADng is not reactive?=A0 If it is not a reactive= protocol, then what is it?=0A=0AAs to merging the documents, this is what = WGs do.=A0 If you have multiple "competing" ideas you ask the authors to se= e if they can merge their concepts and ideas.=A0 If they cannot or will not= then the WG must decide based on facts and not conjecture which is the mos= t prudent path to take.=0A=0AJon=0A=0A=0A=0A=0A____________________________= ____=0A From: Abdussalam Baryun =0ATo: Joseph M= acker =0ACc: manet@ietf.org; Stan Ratliff =0ASent: Thursday, November 1, 2012 8:22 AM=0ASubject: Re: [manet]= Reactive Protocol Situation=0A =0A=0ADear Joseph Macker and Stan,=0AMANET = WG Chairs=0A=A0=0AI disagree that the=A0WG=A0arranged/guided to merge the d= ocuments, I never heard that there was a consensus on such activity. DYMO i= s a reactive WG draft, but LOADng is not. Why did you guide to merge docume= nts, I recommend that you ment to merge the team drafts co-authors to one= =A0WG draft (which is only DYMO so far). The authority is for the WG to dec= ide to merge individual drafts to its WG draft.=0A=A0=0ATherefore, my vote = is for option 1 only. Thanking you for updating us with the status.=0A=A0= =0ARegards=0AAB=0A=0A=0AOn Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker wrote:=0A=0AHello MANET working group (form Stan and Joe)= ,=0A>=0A>As you are all probably aware, there has been WG activity lately o= n competing drafts for a MANET reactive protocol - DYMO (reviving the curre= nt working group document that was parked due to inactivity), and LOADng. M= any months ago there was a somewhat authorship led movement towards a commo= n document effort and given positive feedback at the time we the chairs tho= ught this was the best approach given the authors potential to come togethe= r and gain the best of both efforts.=A0 Since that period, there has been s= ome fairly strident and rancorous "at times" debate between the authors of = the two documents.=0A>=0A>During IETF 84 in Vancouver, the co-chairs held a= discussion with some of the co-authors of the two documents. Our guidance = to the co-authors was to find a way to merge the two documents into one, as= it was perceived that are not technically far apart and they both derive r= oughly from AODV concepts and LOADng had fairly active authorship and imple= mentation efforts. We provided a co-editing proposal to the authors and gav= e them the timeframe of the Atlanta to come up with an answer back to us re= garding this.=A0 As of this writing, those discussions of a potential commo= nn document and authorship merger have failed.=0A>=0A>Therefore, we find ou= rselves at a crossroads. The authors of the two documents are divided, and = it is unlikely that progress on a merged document can be reached based upon= recent author feedback. I have also polled the earlier WG editor of DYMO, = Ian Chakeres, and he is somewhat disengaged on the issue at the present tim= e.=A0 We see only 3 possible paths forward:=0A>=0A>1. Continue the work on = the DYMO document, starting with whether there is consensus on its continue= d approach and also the desire to rename it to AODVv2.=0A>2. Replace the ex= isting DYMO document effort with the LOADng related document effort, defusi= ng ealier references to LLNs as recommended in the last meeting minutes, an= d to focus more motivationally on general MANET problem spaces (the authors= seem to have agreed to this issue if its a WG document).=0A>3. Remove the = working group charter for a reactive protocol, effectively killing both doc= uments, at least from a working group (WG) standpoint. This would not be a = reflection on the technology in either case, just an admission that we are = not working together and reaching consensus.=0A>=0A>The co-chairs request a= nd need your opinions on the options.=A0 We have been some silent collectin= g initial feedback and waiting for author feedback at this point.=A0 Stan a= nd I are both on travel prior to Atlanta so our responses may be sparse and= we will also likely be in a "receive mode" for a few days.=A0 So send your= opinions.=0A>=0A>-Joe=0A>=0A>_____________________________________________= __=0A>manet mailing list=0A>manet@ietf.org=0A>https://www.ietf.org/mailman/= listinfo/manet=0A>=0A>=0A=0A_______________________________________________= =0Amanet mailing list=0Amanet@ietf.org=0Ahttps://www.ietf.org/mailman/listi= nfo/manet ---1933122451-260341018-1351784251=:48543 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Why would you think t= hat LOADng is not reactive?  If it is not a reactive protocol, then wh= at is it?

As to merging the documents, this is what WGs do.  If= you have multiple "competing" ideas you ask the authors to see if they can= merge their concepts and ideas.  If they cannot or will not then the = WG must decide based on facts and not conjecture which is the most prudent = path to take.

Jon


From: Abduss= alam Baryun <abdussalambaryun@gmail.com>
To: Joseph Macker <jpmacker@gmail.com>
Cc: manet@ietf.org; Stan Ratliff = <sratliff@cisco.com>
Sent:= Thursday, November 1, 2012 8:22 AM
Subject: Re: [manet] Reactive Protocol Situation

=0A
Dear Joseph Macker and Stan,
<= div>MANET WG Chairs
 
I disagree that the WG&= nbsp;arranged/guided to merge the documents, I never heard that there was a= consensus on such activity. DYMO is a reactive WG draft, but LOADng is not= . Why did you guide to merge documents, I recommend that you ment to merge = the team drafts co-authors to one WG draft (which is only DYMO so far)= . The authority is for the WG to decide to merge individual drafts to its W= G draft.
=0A
 
Therefore, my vote is for option 1 o= nly. Thanking you for updating us with the status.
 
Regards
AB

On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker <jpmacker@gmail.com> wrote:=0A
Hello MANET working group (form Stan and = Joe),

As you are all probably aware, there has been WG activity late= ly on competing drafts for a MANET reactive protocol - DYMO (reviving the c= urrent working group document that was parked due to inactivity), and LOADn= g. Many months ago there was a somewhat authorship led movement towards a c= ommon document effort and given positive feedback at the time we the chairs= thought this was the best approach given the authors potential to come tog= ether and gain the best of both efforts.  Since that period, there has= been some fairly strident and rancorous "at times" debate between the auth= ors of the two documents.
=0A=0A
During IETF 84 in Vancouver, the co-= chairs held a discussion with some of the co-authors of the two documents. = Our guidance to the co-authors was to find a way to merge the two documents= into one, as it was perceived that are not technically far apart and they = both derive roughly from AODV concepts and LOADng had fairly active authors= hip and implementation efforts. We provided a co-editing proposal to the au= thors and gave them the timeframe of the Atlanta to come up with an answer = back to us regarding this.  As of this writing, those discussions of a= potential commonn document and authorship merger have failed.
=0A=0ATherefore, we find ourselves at a crossroads. The authors of the two docum= ents are divided, and it is unlikely that progress on a merged document can= be reached based upon recent author feedback. I have also polled the earli= er WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the is= sue at the present time.  We see only 3 possible paths forward:
=0A= =0A
1. Continue the work on the DYMO document, starting with whether the= re is consensus on its continued approach and also the desire to rename it = to AODVv2.
2. Replace the existing DYMO document effort with the LOADng = related document effort, defusing ealier references to LLNs as recommended = in the last meeting minutes, and to focus more motivationally on general MA= NET problem spaces (the authors seem to have agreed to this issue if its a = WG document).
=0A=0A3. Remove the working group charter for a reactive p= rotocol, effectively killing both documents, at least from a working group = (WG) standpoint. This would not be a reflection on the technology in either= case, just an admission that we are not working together and reaching cons= ensus.
=0A=0A
The co-chairs request and need your opinions on the opt= ions.  We have been some silent collecting initial feedback and waitin= g for author feedback at this point.  Stan and I are both on travel pr= ior to Atlanta so our responses may be sparse and we will also likely be in= a "receive mode" for a few days.  So send your opinions.
=0A=0A-Joe
=0A
_______________________________________________
=0Amanet= mailing list
=0Amanet@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/manet
=0A

=0A

_______________________________________________
manet m= ailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


---1933122451-260341018-1351784251=:48543-- From ulrich@herberg.name Thu Nov 1 08:38:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0B921F8A2A for ; Thu, 1 Nov 2012 08:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdXG4qZHrrHt for ; Thu, 1 Nov 2012 08:38:30 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0A02021F89D1 for ; Thu, 1 Nov 2012 08:38:30 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so1220159dan.31 for ; Thu, 01 Nov 2012 08:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=jkAPdCnkfeJoBjo0bxkP1Qdz9HpDi//A12pMKcbJajs=; b=Cc0zm5Wqtz7XbePqjHsYyM4zJxp1Ukc6G67FrgCUnWzt8R8GOJS8+L4wWnOXLeFiTt 224nO5u3o8H1HKpIvPP6hvZrKouMPiL+nEnxy3w9j58mLN2pmwqeLk/zXPjJ0CUl21q8 tFkgU3AhfZe4PGI5JsJe8gf24IjVHg756DWFI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=jkAPdCnkfeJoBjo0bxkP1Qdz9HpDi//A12pMKcbJajs=; b=WZFKGfaHAeZ8xAG+lynd2cox3giMIRASNuuykHereDP6Hc2eHVKIEb9HYA0ZqAA21b /fYeQYJCOrIfvoR0C5/Co+SY71Kb7PBqJlmJnN4XwqmXHdgBlJUP0l6+8q2rqvS0tw7i xpnTObbuYuYgEZ0JY5SxCRRv3nYGt4GuI9QD/CXRhGKtQFG4tI4Oy1GkLUdl/lKplDFm RXS49h70Gg0QGX/LB6vGoxEWIQ2F37Zfd9zGKjhnQirZXtnX1cD5gfVjv8RjET/RtvTv 5gt3DlIbHnp4cTjP/sovliDjseV5rm5dTrk1sDHSDyOjiASw/HlQ3Uc1n5p+0pFlkFyx Z+Cw== Received: by 10.66.87.132 with SMTP id ay4mr81978749pab.67.1351784309769; Thu, 01 Nov 2012 08:38:29 -0700 (PDT) Received: from [10.0.1.5] (c-76-102-41-234.hsd1.ca.comcast.net. [76.102.41.234]) by mx.google.com with ESMTPS id wo9sm4187437pbc.53.2012.11.01.08.38.28 (version=SSLv3 cipher=OTHER); Thu, 01 Nov 2012 08:38:28 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-11CEA42E-0710-4252-8DB4-01EC4C149153 Content-Transfer-Encoding: 7bit Message-Id: <5010FCBB-9E4A-4129-B141-3C434DD70177@herberg.name> X-Mailer: iPad Mail (10A403) From: Ulrich Herberg Date: Thu, 1 Nov 2012 08:38:30 -0700 To: Abdussalam Baryun X-Gm-Message-State: ALoCoQklZSNTYrXF1Rwv9TivHyCvvWf7DlQOIvz/WRmOMf2ogvJ1WB1icVdR0Iuse4CFxCM13nBP Cc: " List" Subject: Re: [manet] Reactive Protocol - LOADng vs. AODVv2 at Atlanta X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:38:31 -0000 --Apple-Mail-11CEA42E-0710-4252-8DB4-01EC4C149153 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable You don't have to participate in this discussion if you think it is such a w= aste of time. It would be much more productive if you actually read both dra= fts and give technical arguments for your opinion. Note that LOADng was only= started after there was no activity on DYMO for 2.5 years. A half-hour disc= ussion in the meeting seems not overly wasted time compared to that. Ulrich On Nov 1, 2012, at 8:20, Abdussalam Baryun wrot= e: > I disagree with the present of LOADng, because it will need a full hour di= scussion and will waste time as it already did twice. I recommend its polace= to discuss SHOULD be first on the MANET list (as required by MANET Chair be= fore but not followed). > =20 > However, I agree that the Chairs and AD are kindly recommended to organise= the meeting and to make it efficient and progress mostly the WG works witho= ut other companies issues. > =20 > AB >=20 > On Thu, Nov 1, 2012 at 2:47 PM, Don Sturek wrote: >>=20 >> Why not just have presentations from both prospective solutions in Atlant= a >> (LOADng and AODVv2) and let the WG decide between these options as a work= >> plan to address the reactive protocol requirement in MANET: >> 1) Progress LOADng (which seems to be happening anyway) >> 2) Progress AODVv2 (which seems to have stalled for 2+ years but now >> there are promises to pick that up) >> 3) Merge AODVv2 and LOADng (which I think is impractical given e-mail >> reflector traffic....) >>=20 >> Not working on a reactive protocol seems like the least desirable outcome= . >> While there have been inputs for each possible path, it is unclear from= >> the reflector what the consensus of the group is. >>=20 >> Personally, it would be useful to hear in Atlanta about large scale >> deployments (eg, working code) from each to help the WG decide. I think= >> all relevant technical information should be provided by Atlanta to help >> the WG make the right decision. >>=20 >> Don >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-11CEA42E-0710-4252-8DB4-01EC4C149153 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
You don't have to participate in this discussion if you think it is such a waste of time. It would be much more productive if you actually read both drafts and give technical arguments for your opinion. Note that LOADng was only started after there was no activity on DYMO for 2.5 years. A half-hour discussion in the meeting seems not overly wasted time compared to that.

Ulrich

I disagree with the present of LOADng, because it will need a full hour discussion and will waste time as it already did twice. I recommend its polace to discuss SHOULD be first on the MANET list (as required by MANET Chair before but not followed).
 
However, I agree that the Chairs and AD are kindly recommended to organise the meeting and to make it efficient and progress mostly the WG works without other companies issues.
 
AB

On Thu, Nov 1, 2012 at 2:47 PM, Don Sturek <d.sturek@att.net> wrote:

Why not just have presentations from both prospective solutions in Atlanta
(LOADng and AODVv2) and let the WG decide between these options as a work
plan to address the reactive protocol requirement in MANET:
1)  Progress LOADng (which seems to be happening anyway)
2)  Progress AODVv2 (which seems to have stalled for 2+ years but now
there are promises to pick that up)
3)  Merge AODVv2 and LOADng (which I think is impractical given e-mail
reflector traffic....)

Not working on a reactive protocol seems like the least desirable outcome.
  While there have been inputs for each possible path, it is unclear from
the reflector what the consensus of the group is.

Personally, it would be useful to hear in Atlanta about large scale
deployments (eg, working code) from each to help the WG decide.   I think
all relevant technical information should be provided by Atlanta to help
the WG make the right decision.

Don



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--Apple-Mail-11CEA42E-0710-4252-8DB4-01EC4C149153-- From jblack.ietf@yahoo.com Thu Nov 1 08:40:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF25B21F8E2C for ; Thu, 1 Nov 2012 08:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=0.979, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0t-Sfr0uRYj for ; Thu, 1 Nov 2012 08:40:21 -0700 (PDT) Received: from nm11-vm0.bullet.mail.bf1.yahoo.com (nm11-vm0.bullet.mail.bf1.yahoo.com [98.139.213.136]) by ietfa.amsl.com (Postfix) with ESMTP id 500BA21F8E33 for ; Thu, 1 Nov 2012 08:40:21 -0700 (PDT) Received: from [98.139.215.141] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 15:40:20 -0000 Received: from [98.139.212.214] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 15:40:20 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 15:40:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 715630.31124.bm@omp1023.mail.bf1.yahoo.com Received: (qmail 70617 invoked by uid 60001); 1 Nov 2012 15:40:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351784420; bh=Cgm6SzhpnCt55cZhFFZbSUAggTepMjhjWJN/m0VNAEQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qMII2vEOtbcPRtb9Gj3xZMBRrAxMHYLnhNYV3gUz/BnDKt6RdSIS9CdZOa0Bu2E0pQKibpl3FeOt/NokDixw3gIDC9r7/I4h30R6KeyGdKk8zOtPYGOw2rg1syqlWoLDUkP5hR58+eW1SeYGE+HgGzmntRqGHraV/Gn34JJhPTE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=W5MliTXcyzGaW7C6y68uTzUoz6Dh9ebGoyEReAtNU//Qo/8TRlxXnk6e/KIan69nVJ9aMbVGo2uQMrhg+hmAHrj0ciLMjlpHZAD3uqM84deK2G/8bJBgex/a3PqJbZoATO6UfqC8yOIiS8RFw+xllHTQ3FZIDUMPga/Usfk0X6U=; X-YMail-OSG: nPARSJEVM1mxIJo78qIWEGphtcLAsh9B9cE4hqdAFSzZV1h pmRB4kGntWKxbTsgQBM_auLr9SkJo8KSYaGjkr9.uaRpu9XesFMKpsZ0v1A2 51r5Wx.2oJcd7C5i2HEyGkbwlO5fe31Dvq7W5VUtuGsxMRHxXTG_XhlQopxc vnYoAHZMKszC.pJ2OpJt6hM27S4N9Xum2NlOXiLkrirdB6KFUVDrACOMukPr 0pxdEHv7f5hK_X1n_xg2fDO33huLmaSwAsbzjjFLG5bf_5.kCu4QIRm5ZAd3 C5Q7gtiDUDGONiDT.71d.yXP5cRAXc7QF2V0m3rOc4KkxwhECbSGQvDsr7u5 7uQwtuRdt4.tXa7UyVVGITpLpTb4hfCUSG19FImZt2ftzWYdChgHbm4tN8ae hH4JiMzw_I.C1.YsSDKBi03x1xLW91a02QgVmxPjPXm_SmBetj4CVOObRRe1 R74F1XCtLs_lGcY1b._tXmmTsXmxWJQ0_K6CEcQd5TEcy26sDPpeyHZ34iBH SuMr4CZXqIIcMZRp5FUNDXg-- Received: from [67.213.218.74] by web160603.mail.bf1.yahoo.com via HTTP; Thu, 01 Nov 2012 08:40:20 PDT X-Rocket-MIMEInfo: 001.001, TW9iaWxpdHkgaW4gYSB3aXJlbGVzcyBzZW5zZSBtZWFucyBhIGNoYW5naW5nIGNvbm5lY3Rpdml0eS7CoCBBIHdpcmVsZXNzIGRldmljZSBkb2VzIG5vdCBuZWVkIHRvIHBoeXNpY2FsbHkgbW92ZSB0byBhcHBlYXIgbW9iaWxlIC0gdGhlIGNvbm5lY3Rpdml0eSBwYXRoIGNoYW5nZXMuCgpOb3cgaWYgeW91IGxpdmUgaW4gYSBtb2JpbGUgaG9tZSBtYXliZSB5b3VyIG1ldGVyIG1heSBhbHNvIHBoeXNpY2FsbHkgbW92ZS7CoCBNYXliZSB5b3VyIG1vYmlsZSBob21lIGRvZXNuJ3QgaGF2ZSB3aGVlbHMuCgpKb24BMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <2CF862E3-F417-4442-B597-6DCBA035D4B9@cisco.com> Message-ID: <1351784420.69738.YahooMailNeo@web160603.mail.bf1.yahoo.com> Date: Thu, 1 Nov 2012 08:40:20 -0700 (PDT) From: Jon Black To: Bo Berry , "Dearlove, Christopher \(UK\)" In-Reply-To: <2CF862E3-F417-4442-B597-6DCBA035D4B9@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1886287700-1465178282-1351784420=:69738" Cc: "thierry.lys@erdfdistribution.fr" , "manet@ietf.org" Subject: Re: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:40:23 -0000 --1886287700-1465178282-1351784420=:69738 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mobility in a wireless sense means a changing connectivity.=C2=A0 A wireles= s device does not need to physically move to appear mobile - the connectivi= ty path changes.=0A=0ANow if you live in a mobile home maybe your meter may= also physically move.=C2=A0 Maybe your mobile home doesn't have wheels.=0A= =0AJon=0A=0A=0A=0A=0A________________________________=0A From: Bo Berry =0ATo: "Dearlove, Christopher (UK)" =0ACc: JP Vasseur (jvasseur) ; Jon Black ; "manet@ietf.org" ; "thierry.lys@erdfdis= tribution.fr" =0ASent: Thursday, November= 1, 2012 4:22 AM=0ASubject: Re: [manet] (no subject)=0A =0AAnd to be fair, = I've not seen results on Loadng wrt to mobility.=C2=A0 The smart meter atta= ched to my house has not moved sense it was installed.=C2=A0 =0A=0A=0AOn No= v 1, 2012, at 6:10 AM, Dearlove, Christopher (UK) wrote:=0A=0A> If I were i= n charge of requirements, that requirement would be now. Attempting to sway= a decision on the basis of "I have results" but not offering those results= until the decision is made is not helpful. And the most important thing is= are there any comparisons between the two (or with base AODV)? Without tho= se, the issue is how do the two differ technically in a manner that matters= ?=0A>=C2=A0 =0A> --=0A> Christopher Dearlove=0A> Senior Principal Engineer,= Communications Group=0A> Communications, Networks and Image Analysis Capab= ility=0A> BAE Systems Advanced Technology Centre=0A> West Hanningfield Road= , Great Baddow, Chelmsford, CM2 8HN, UK=0A> Tel: +44 1245 242194 |=C2=A0 Fa= x: +44 1245 242124=0A> chris.dearlove@baesystems.com | http://www.baesystem= s.com=0A> =0A> BAE Systems (Operations) Limited=0A> Registered Office: Warw= ick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU1= 4 6YU, UK=0A> Registered in England & Wales No: 1996687=0A>=C2=A0 =0A> From= : manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of JP Va= sseur (jvasseur)=0A> Sent: 31 October 2012 22:09=0A> To: Jon Black=0A> Cc: = thierry.lys@erdfdistribution.fr; manet@ietf.org=0A> Subject: Re: [manet] (n= o subject)=0A>=C2=A0 =0A>=C2=A0 =0A> *** WARNING ***=0A> This message origi= nates from outside our organisation, either from an external partner or the= internet.=0A> Keep this in mind if you answer this message.=0A> Please see= this process on how to deal with suspicious emails.=0A> =0A>=C2=A0 =0A> On= Oct 31, 2012, at 6:57 PM, Jon Black wrote:=0A> =0A> =0A> On October 31, 20= 12 Thierry.Lys wrote:=0A>=C2=A0 =0A> I speak in the name of EDF group. =0A>= =0A> We started first to use LOAD as a routing algorithm and deployed 2000= PLC-meters for smart grid purposes in 2011. Taking advantage of this field= test, we have been actively participating to the working group to adopt en= hancements in the LOADng specification. =0A> We are now extremely pleased w= ith what LOADng is capable of and are confident that future deployements wi= ll be equipped with it. =0A>=C2=A0 =0A> This would seem to indicate that LO= ADng does work and in a rather large deployment.=0A>=C2=A0 =0A> JP> No this= means that LoadNG works in *a* network. But the major technical difference= here is that reactive routing is highly impacted=0A> by the user traffic = =E2=80=A6 If you poll a meter every 24 hours, it may work perfectly well. N= ow if you start having more frequent traffic flows=0A> you can either cache= paths (ending up with more frequent broken paths considering how flappy th= ese networks are, thus leading to more=0A> floods =E2=80=A6 very undesirabl= e =E2=80=A6 especially when you have hundreds of meters sharing a few Kbits= /s) or you use short cache timers and you=0A> keep flooding :-( If you take= actual traces of these networks (both using 15.4g and P1901.2) and you sta= rt adjusting the user traffic rate you=0A> immediately see the issues in te= rms of scalability. Yes you can try to mitigate the undesirable flooding ef= fect to some extends but showing =0A> the limits in terms of scalability is= easy to show. Note that I MOT against reactive routing by any means, this = is IMO just not applicable to=0A> LLNs unless the traffic flows are determi= nistic and very well knows =E2=80=A6 Lessons from the past show us how diff= icult it is to predict user =0A> applications. We all started with meter re= ading to continue with that example and now many utilities wants to use the= se smart metering =0A> networks for a number of applications which differen= t SLA, =E2=80=A6 =0A>=C2=A0 =0A> Hope this helps. Once again, when/if requi= red I would be happy to share many results.=0A>=C2=A0 =0A> =0A> =0A> =0A> "= We believe in rough consensus and running code" =0A> =0A> rough consensus := Don't you think we have a rough consensus on LOADng compared to DYMO ? 10 = authors and major companies are supporters of LOADng. =0A> =0A> running cod= e : interoperability has been checked with 4 sources and other implementati= ons are in progress.=0A> =0A> Obviously from the list we don't have rough c= onsensus.=C2=A0 We have two alternatives each with proponents.=C2=A0 The WG= should weigh the technical benefits (design, implementation/running code, = maturity)=C2=A0 of each and the group should choose a path forward.=0A> =0A= > In my opinion option 3 is not an option - this is the working group shirk= ing its responsibility.=0A>=C2=A0 =0A> This is an option =E2=80=A6 since li= sted by the chairs. I agree that we should avoid it, especially when I thin= k we have a very reasonable solution=0A> (option1).=0A>=C2=A0 =0A> JP.=0A> = =0A> =0A> =0A> Jon=0A>=C2=A0 =0A> _________________________________________= ______=0A> manet mailing list=0A> manet@ietf.org=0A> https://www.ietf.org/m= ailman/listinfo/manet=0A>=C2=A0 =0A> =0A> *********************************= ***********************************=0A> This email and any attachments are = confidential to the intended=0A> recipient and may also be privileged. If y= ou are not the intended=0A> recipient please delete it from your system and= notify the sender.=0A> You should not copy it or use it for any purpose no= r disclose or=0A> distribute its contents to any other person.=0A> ********= ************************************************************=0A> =0A> _____= __________________________________________=0A> manet mailing list=0A> manet= @ietf.org=0A> https://www.ietf.org/mailman/listinfo/manet --1886287700-1465178282-1351784420=:69738 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Mobility in a wireles= s sense means a changing connectivity.  A wireless device does not nee= d to physically move to appear mobile - the connectivity path changes.
<= br>Now if you live in a mobile home maybe your meter may also physically mo= ve.  Maybe your mobile home doesn't have wheels.

Jon


From: Bo Berry <boberry@cisco.com>
To: "Dearlove, Christopher (= UK)" <chris.dearlove@baesystems.com>
Cc: JP Vasseur (jvasseur) <jvasseur@cisco.com>; Jo= n Black <jblack.ietf@yahoo.com>; "manet@ietf.org" <manet@ietf.org&= gt;; "thierry.lys@erdfdistribution.fr" <thierry.lys@erdfdistribution.fr&= gt;
Sent: Thursday, N= ovember 1, 2012 4:22 AM
Subject:<= /span> Re: [manet] (no subject)

=0AAnd to be fai= r, I've not seen results on Loadng wrt to mobility.  The smart meter a= ttached to my house has not moved sense it was installed. 

On Nov 1, 2012, at 6:10 AM, Dearlove, Christopher (UK) wrote:

> = If I were in charge of requirements, that requirement would be now. Attempt= ing to sway a decision on the basis of "I have results" but not offering th= ose results until the decision is made is not helpful. And the most importa= nt thing is are there any comparisons between the two (or with base AODV)? = Without those, the issue is how do the two differ technically in a manner t= hat matters?
> 
> --
> Christopher Dearlove
>= Senior Principal Engineer, Communications Group
> Communications, Ne= tworks and Image Analysis Capability
> BAE Systems Advanced Technolog= y Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN,= UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | = http://www.baesystems.com
>
> BAE Systems (Operations) Limited=
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace= Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England &am= p; Wales No: 1996687
> 
> From: manet-bounces@ie= tf.org [mailto:manet-bounces@ietf.org] On Behalf Of JP Vas= seur (jvasseur)
> Sent: 31 October 2012 22:09
> To: Jon Black> Cc: thierry.lys@erdfdistribution.fr; = manet@ietf.org
> Subject: Re: [ma= net] (no subject)
> 
> 
> *** WARNING ***
= > This message originates from outside our organisation, either from an = external partner or the internet.
> Keep this in mind if you answer t= his message.
> Please see this process on how to deal with suspicious= emails.
>
> 
> On Oct 31, 2012, at 6:57 PM, Jon B= lack wrote:
>
>
> On October 31, 2012 Thierry.Lys wrote= :
> 
> I speak in the name of EDF group.
>
>= ; We started first to use LOAD as a routing algorithm and deployed 2000 PLC= -meters for smart grid purposes in 2011. Taking advantage of this field tes= t, we have been actively participating to the working group to adopt enhanc= ements in the LOADng specification.
> We are now extremely pleased w= ith what LOADng is capable of and are confident that future deployements will be equipped with it.
> 
> This would = seem to indicate that LOADng does work and in a rather large deployment.> 
> JP> No this means that LoadNG works in *a* network.= But the major technical difference here is that reactive routing is highly= impacted
> by the user traffic =E2=80=A6 If you poll a meter every 2= 4 hours, it may work perfectly well. Now if you start having more frequent = traffic flows
> you can either cache paths (ending up with more frequ= ent broken paths considering how flappy these networks are, thus leading to= more
> floods =E2=80=A6 very undesirable =E2=80=A6 especially when y= ou have hundreds of meters sharing a few Kbits/s) or you use short cache ti= mers and you
> keep flooding :-( If you take actual traces of these n= etworks (both using 15.4g and P1901.2) and you start adjusting the user tra= ffic rate you
> immediately see the issues in terms of scalability. Y= es you can try to mitigate the undesirable flooding effect to some extends but showin= g
> the limits in terms of scalability is easy to show. Note that I = MOT against reactive routing by any means, this is IMO just not applicable = to
> LLNs unless the traffic flows are deterministic and very well kn= ows =E2=80=A6 Lessons from the past show us how difficult it is to predict = user
> applications. We all started with meter reading to continue w= ith that example and now many utilities wants to use these smart metering <= br>> networks for a number of applications which different SLA, =E2=80= =A6
> 
> Hope this helps. Once again, when/if required I= would be happy to share many results.
> 
>
>
= >
> "We believe in rough consensus and running code"
> > rough consensus : Don't you think we have a rough consensus on LOADng= compared to DYMO ? 10 authors and major companies are supporters of LOADng= .
>
> running code : interoperability has been checked with 4 = sources and other implementations are in progress.
>
> Obvious= ly from the list we don't have rough consensus.  We have two alternati= ves each with proponents.  The WG should weigh the technical benefits = (design, implementation/running code, maturity)  of each and the group= should choose a path forward.
>
> In my opinion option 3 is n= ot an option - this is the working group shirking its responsibility.
&g= t; 
> This is an option =E2=80=A6 since listed by the chairs. I= agree that we should avoid it, especially when I think we have a very reas= onable solution
> (option1).
> 
> JP.
>
&= gt;
>
> Jon
> 
> __________________________= _____________________
> manet mailing list
> manet@ietf.org
>= ; = https://www.ietf.org/mailman/listinfo/manet
> 
>
= > ********************************************************************> This email and any attachments are confidential to the intended
&= gt; recipient and may also be privileged. If you are not the intended
&g= t; recipient please delete it from your system and notify the sender.
&g= t; You should not copy it or use it for any purpose nor disclose or
>= distribute its contents to any other person.
> *********************= ***********************************************
>
> __________= _____________________________________
> manet mailing list
> manet@iet= f.org
> https://www.ietf.org/mailman/listinfo/manet


--1886287700-1465178282-1351784420=:69738-- From abdussalambaryun@gmail.com Thu Nov 1 08:41:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A3221F8A2A for ; Thu, 1 Nov 2012 08:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmxZo1b94TkW for ; Thu, 1 Nov 2012 08:41:11 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAA321F8E31 for ; Thu, 1 Nov 2012 08:41:10 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3130193vcb.31 for ; Thu, 01 Nov 2012 08:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jdv9fhJMfcX/kHLMa1Lb4fAiVRMtPhXsP1R9sj8bCAA=; b=b8bzfZkmOs2g8TopmwLVH2yBParGaHcggopeD//YsPaFKuAWJqitypv2/eiHYxLLc3 38QComB9EmVLY2TWlV/JXfcb3R1H5tsXTJAmFRB2jNRHRMUTmEp6Uy+htfmhh4CMppaA OnJrE8b0KJ0fUP1axCI7Fy0LL3c3bVoaNRVYpA8Pn8cmRxp/pO/NQnR5dysVST/dU7aI JI5vBfZJGH87QMhp3nqqJEx+rkg2zFwhF1zDnTbiPoJa31Tg5A4C8LOLu1BM+XQDTI/I k23XjmYPr1HtBx+1WiSIgueugyMFQP2j4lbrnxiJBZf3PUXY/b3hP93x8ncFkJGSUFNe pc3w== MIME-Version: 1.0 Received: by 10.220.154.68 with SMTP id n4mr23467892vcw.22.1351784470435; Thu, 01 Nov 2012 08:41:10 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 08:41:10 -0700 (PDT) In-Reply-To: <50902CF3.9070903@computer.org> References: <50902CF3.9070903@computer.org> Date: Thu, 1 Nov 2012 15:41:10 +0000 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=f46d043be0be2c599804cd70d91b Cc: manet Subject: Re: [manet] Flooding: how to make a normative reference? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:41:11 -0000 --f46d043be0be2c599804cd70d91b Content-Type: text/plain; charset=ISO-8859-1 It will be interesting to have the flooding algorithm I-D as you mentioned so we can refer by MANET protocols, but also I support that OLSRv2 has no need to take out such technique (as chris mentioned). However, your suggestion will give more flexibility to AODVv2 as a MANET protocol. I also agree that AODVv2 should not reference OLSRv2 as normative for your mentioned reasons. AB On Tue, Oct 30, 2012 at 7:39 PM, Charles E. Perkins wrote: > > Hello folks, > > I think it is well recognized that brute force flooding often leads to > poor performance in ad hoc networks with many nodes. Thus, we > have RFC 6621 to describe various other approaches. Plus, we have > MPR flooding as described in the OLSRv2 document. > > For reactive, it is quite important to enable "better" algorithms > for flooding. AODVv2 could quite reasonable use a MPR-based > flooding, or flooding based over any connected dominating set. > > It seems wrong to have AODVv2 cite OLSRv2 in any normative > fashion, just to get access to the MPR flooding mechanism which > can run independently of the routing protocol (and, perhaps, > should do so). It also seems wrong to cite RFC 6621 in any > normative fashion since that is an Experimental specification. > > Don't we need to have some Proposed Standard documents that > specify more scalable approaches to flooding, that are independent > of routing protocols? > > I guess it's too late to suggest that the MPR specification should > be pulled out of OLSRv2 for this purpose... > > I looked back for some discussion about this on the list, but I > didn't find it, but my search was hardly exhaustive. > > -- > Regards, > Charlie P. > > ______________________________**_________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/**listinfo/manet > --f46d043be0be2c599804cd70d91b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It will be interesting to have the flooding algorithm I-D as you menti= oned so we can refer by MANET protocols, but also I support that OLSRv2 has= no need to take out such technique (as chris mentioned). However, your sug= gestion=A0will give more flexibility to AODVv2 as a MANET protocol.
=A0
I also agree that AODVv2 should not reference OLSRv2 as = normative for your mentioned reasons.
=A0
AB

On Tue, Oct 30, 2012 at 7:39 PM, Charles E. P= erkins <charliep@computer.org> wrote:

Hello folks,

I think it is well recognized that brute force flooding often leads to
poor performance in ad hoc networks with many nodes. =A0Thus, we
have RFC 6621 to describe various other approaches. =A0Plus, we have
MPR flooding as described in the OLSRv2 document.

For reactive, it is quite important to enable "better" algorithms=
for flooding. =A0AODVv2 could quite reasonable use a MPR-based
flooding, or flooding based over any connected dominating set.

It seems wrong to have AODVv2 cite OLSRv2 in any normative
fashion, just to get access to the MPR flooding mechanism which
can run independently of the routing protocol (and, perhaps,
should do so). =A0It also seems wrong to cite RFC 6621 in any
normative fashion since that is an Experimental specification.

Don't we need to have some Proposed Standard documents that
specify more scalable approaches to flooding, that are independent
of routing protocols?

I guess it's too late to suggest that the MPR specification should
be pulled out of OLSRv2 for this purpose...

I looked back for some discussion about this on the list, but I
didn't find it, but my search was hardly exhaustive.

--
Regards,
Charlie P.

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--f46d043be0be2c599804cd70d91b-- From jblack.ietf@yahoo.com Thu Nov 1 08:44:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A0A21F8E85 for ; Thu, 1 Nov 2012 08:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.515 X-Spam-Level: X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzlzzFw9fsuz for ; Thu, 1 Nov 2012 08:44:31 -0700 (PDT) Received: from nm39-vm3.bullet.mail.bf1.yahoo.com (nm39-vm3.bullet.mail.bf1.yahoo.com [72.30.239.147]) by ietfa.amsl.com (Postfix) with ESMTP id 57DB321F8E84 for ; Thu, 1 Nov 2012 08:44:29 -0700 (PDT) Received: from [98.139.212.148] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 15:44:28 -0000 Received: from [98.139.215.248] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 15:44:28 -0000 Received: from [127.0.0.1] by omp1061.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 15:44:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 291412.39669.bm@omp1061.mail.bf1.yahoo.com Received: (qmail 68089 invoked by uid 60001); 1 Nov 2012 15:44:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351784668; bh=Pk+ZVYKO9xMoe4TFLDhV+UPyEbuUP+kWYqXlHNqwM2g=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=lgdrMDGC0uKtGc4AYz2gp5ufDR1MbEfMReWVBrsdJtzxgxK9MSoOG/OT9D4lC7y9ijNekjAKO1q5i14ciirI/HN9FQ5fN40QmK8aJpKj4IF+bDW2+ceynGU8uzQCPfy+q3ystpu7jhffaYzsM78jXL8U8CFFPZUjBKuKfl9dBRc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=genlDZe+UlFImFMtG8MCD3VKY35VcFKio8gzpwRGxlA1rbM9OulJx2YU2B59dvrWsR9z+Ouh+5Fk89XDpxsHnXDqXgD7M9jZv+APKS9M93GYN1nN0jmcj9f4uv8K2sLDLMwdWx+Sq1vUGEB75ZQIZpFg6eCsE2dzm5XkZtNYlho=; X-YMail-OSG: 568ucKkVM1kAKLXdYkSnGaQgXnE_P1hL7fGib1R566e6br7 RaSO_Qvx.BQ2e68WKy2lznoc6yVSu5LfTxyUEo0mKx0JpMA1qdv5JlJS9Rgd bSPlhbCgE824eKDJ6hq5lvv7mcwIZ6hbdR9RImVfteowErKeCSSMRHeSQHQ1 Y7vaO7RDMkyd9LBL9UeO7LUH3hMDSMnBfalNsGtrEgM7LewczZJbnKbtBOLc 1Tp5njd3mFeia2g1cutO.Vkkb3DbWdZtnatRcaSDSrC_O45gzjO_UsQdqyAZ YGkmrbdrboYnlnFZQw3Vkl31UZGbr05RSj13ZWf7MyYhCH759Z9WTuLOKArE WjvMVCpXFe97NjMZ2gpWX7w4Sxle6FN7y4pepawJ7DtmAxrUY6rfGYNBu7WB gfK_QnXhj1NxwvO6.fbgs7TmemG30BWc7l9ybmIFU3MEnGr.j3ZYE5OHuxFS i1IZ9dN7OpCXGBrWnMKemyr7f5UWVcYCCpv2YhlN6tu75jh45gD9GqUo6Huo yVaiJw9lyAR9j63.XPpHm Received: from [67.213.218.74] by web160601.mail.bf1.yahoo.com via HTTP; Thu, 01 Nov 2012 08:44:28 PDT X-Rocket-MIMEInfo: 001.001, SSBkaXNhZ3JlZS7CoCBUaGUgcHJvdG9jb2wgaGFzIHByb2dyZXNzZWQuwqAgSXQgYXBwZWFycyB0aGF0IHRoZXJlIGFyZSBpbXBsZW1lbnRhdGlvbnMuwqAgVGhlcmUgaXMgaW50ZXJvcGVyYWJpbGl0eS7CoCBUaGVyZSBhcmUgZGVwbG95bWVudHMuwqAgVGhpcyBpcyBhbGwgcHJvZ3Jlc3MuCgpJJ20gbm90IGZhdm9yaW5nIExPQURuZyBvdmVyIERZTU8uwqAgSSB0aGluayB0aGUgd29ya2luZyBncm91cCBzaG91bGQgbG9vayBhdCBib3RoIGZhaXJseSBhbmQgZGVjaWRlIHRoZSBiZXN0IHBhdGggZm9yd2FyZCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com> Message-ID: <1351784668.10346.YahooMailNeo@web160601.mail.bf1.yahoo.com> Date: Thu, 1 Nov 2012 08:44:28 -0700 (PDT) From: Jon Black To: Abdussalam Baryun , manet In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1737431079-83964582-1351784668=:10346" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:44:32 -0000 --1737431079-83964582-1351784668=:10346 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I disagree.=A0 The protocol has progressed.=A0 It appears that there are im= plementations.=A0 There is interoperability.=A0 There are deployments.=A0 T= his is all progress.=0A=0AI'm not favoring LOADng over DYMO.=A0 I think the= working group should look at both fairly and decide the best path forward = - chose one over the other or find a way to merge the concepts even if the = authors are hesitant.=0A=0AJon=0A=0A=0A=0A=0A______________________________= __=0A From: Abdussalam Baryun =0ATo: manet =0ASent: Thursday, November 1, 2012 8:28 AM=0ASubject: Re: [ma= net] Reactive Protocol Situation=0A =0A=0AOn Wed, Oct 31, 2012 at 10:02 AM,= Dearlove, Christopher (UK) wrote:=0A=0AAs = someone who has not (yet) stated an opinion on the matter, except I also th= ink option 3 is not good, I would very much like to hear technical argument= s, so if you have technical arguments against LOADng, I think we need to he= ar them rather than just suggesting they exist. I haven't yet read LOADng c= arefully to form a view there. I have just recently read the AODVv2 draft c= arefully, and have some technical issues there (which overlap) regarding as= ymmetric links, possible dependency on NHDP, and the compatibility of optio= ns. If option 1 is followed, the draft needs work (which Charlie has acknow= ledged).=0A>=A0=0A>=A0=0AI don't think we have time to waste with LOADng, i= t was presented twice and no progress, the authors failed to discuss on MAN= ET list, and failed to update the draft to match MANET reuirements. I agree= that we focus our efforts to submit AODVv2 as soon as possible,=0A=A0=0AAB= =0A=A0=0A=A0=0A=A0=0A>-- =0A>Christopher Dearlove=0A>Senior Principal Engin= eer, Communications Group=0A>Communications, Networks and Image Analysis Ca= pability=0A>BAE Systems Advanced Technology Centre=0A>West Hanningfield Roa= d, Great Baddow, Chelmsford, CM2 8HN, UK=0A>Tel: +44 1245 242194=A0|=A0 Fax= : +44 1245 242124=0A>chris.dearlove@baesystems.com | http://www.baesystems.= com=0A>=0A>BAE Systems (Operations) Limited=0A>Registered Office: Warwick H= ouse, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU= , UK=0A>Registered in England & Wales No: 1996687=0A>=A0=0A>From:manet-boun= ces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of JP Vasseur (jvass= eur)=0A>Sent: 31 October 2012 08:29=0A>To: Joseph Macker=0A>Cc: =0A>Subject: Re: [manet] Reactive Protocol Situation=0A>=A0=0A>=A0=0A>= *** WARNING ***=0A>This message originates from outside our organisation, e= ither from an external partner or the internet.=0A>Keep this in mind if you= answer this message.=0A>Please see this process on how to deal with suspic= ious emails.=0A>Dear chairs, =0A>=A0=0A>Remembering that I am not a co-auth= ors of either of these drafts.=0A>=A0=0A>Not commenting on recent discussio= ns but rather focussing on what I hope will be a good solution for the WG a= nd the Internet at large.=0A>=A0=0A>Option 3) is my opinion not desirable; = I wish we could have a reactive routing protocol for MANET=0A>=A0=0A>Option= 2) is an option I would be strongly opposed to for a number of technical r= easons that I would be happy to elaborate on the=0A>mailing list and/or in = a new I-D (which I would, should option 2 be chosen).=0A>=A0=0A>That being = said, I am extremely supportive of option 1), especially in light of what C= harlie said. First of all DYMO is the working group=0A>document and excelle= nt progress has been made with recent revisions. But even more importantly,= Charlie managed to make it compatible=A0=0A>with options, which is in=A0my= opinion the best of both worlds; calling it AODVv2 is only not very sensib= le but avoids useful sensitivity around=A0=0A>names.=0A>=A0=0A>Thus I would= strongly support Option 1), continue the work that Charlie has started, wh= ich by the way is not far from completion. And=A0=0A>as WG,we need to remem= ber that this had been the WG document, the result of years of work. Still = by making it compatible with other options,=A0=0A>this is technically flexi= ble and sound.=0A>=A0=0A>Thanks.=0A>=A0=0A>JP.=0A>=A0=0A>On Oct 31, 2012, a= t 12:13 AM, Joseph Macker wrote:=0A>=0A>=0A>=0A>Hello MANET working group (= form Stan and Joe),=0A>=0A>As you are all probably aware, there has been WG= activity lately on competing drafts for a MANET reactive protocol - DYMO (= reviving the current working group document that was parked due to inactivi= ty), and LOADng. Many months ago there was a somewhat authorship=0A led mov= ement towards a common document effort and given positive feedback at the t= ime we the chairs thought this was the best approach given the authors pote= ntial to come together and gain the best of both efforts.=A0 Since that per= iod, there has been some fairly=0A strident and rancorous "at times" debate= between the authors of the two documents.=0A>=0A>During IETF 84 in Vancouv= er, the co-chairs held a discussion with some of the co-authors of the two = documents. Our guidance to the co-authors was to find a way to merge the tw= o documents into one, as it was perceived that are not technically far apar= t and they=0A both derive roughly from AODV concepts and LOADng had fairly = active authorship and implementation efforts. We provided a co-editing prop= osal to the authors and gave them the timeframe of the Atlanta to come up w= ith an answer back to us regarding this.=A0 As=0A of this writing, those di= scussions of a potential commonn document and authorship merger have failed= .=0A>=0A>Therefore, we find ourselves at a crossroads. The authors of the t= wo documents are divided, and it is unlikely that progress on a merged docu= ment can be reached based upon recent author feedback. I have also polled t= he earlier WG editor of DYMO, Ian Chakeres,=0A and he is somewhat disengage= d on the issue at the present time.=A0 We see only 3 possible paths forward= :=0A>=0A>1. Continue the work on the DYMO document, starting with whether t= here is consensus on its continued approach and also the desire to rename i= t to AODVv2.=0A>2. Replace the existing DYMO document effort with the LOADn= g related document effort, defusing ealier references to LLNs as recommende= d in the last meeting minutes, and to focus more motivationally on general = MANET problem spaces (the authors seem to have agreed=0A to this issue if i= ts a WG document).=0A>3. Remove the working group charter for a reactive pr= otocol, effectively killing both documents, at least from a working group (= WG) standpoint. This would not be a reflection on the technology in either = case, just an admission that we are not working together=0A and reaching co= nsensus.=0A>=0A>The co-chairs request and need your opinions on the options= .=A0 We have been some silent collecting initial feedback and waiting for a= uthor feedback at this point.=A0 Stan and I are both on travel prior to Atl= anta so our responses may be sparse and we will also=0A likely be in a "rec= eive mode" for a few days.=A0 So send your opinions.=0A>=0A>-Joe=0A>_______= ________________________________________=0A>manet mailing list=0A>manet@iet= f.org=0A>https://www.ietf.org/mailman/listinfo/manet=0A>=A0=0A>************= ********************************************************=0A>This email and = any attachments are confidential to the intended=0A>recipient and may also = be privileged. If you are not the intended=0A>recipient please delete it fr= om your system and notify the sender.=0A>You should not copy it or use it f= or any purpose nor disclose or=0A>distribute its contents to any other pers= on.=0A>********************************************************************= =0A>=0A>=0A>_______________________________________________=0A>manet mailin= g list=0A>manet@ietf.org=0A>https://www.ietf.org/mailman/listinfo/manet=0A>= =0A>=0A=0A_______________________________________________=0Amanet mailing l= ist=0Amanet@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/manet --1737431079-83964582-1351784668=:10346 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I disagree.  The= protocol has progressed.  It appears that there are implementations.&= nbsp; There is interoperability.  There are deployments.  This is= all progress.

I'm not favoring LOADng over DYMO.  I think the = working group should look at both fairly and decide the best path forward -= chose one over the other or find a way to merge the concepts even if the a= uthors are hesitant.

Jon


From:= Abdussalam Baryun <abdussalambaryun@gmail.com>
To: manet <manet@ietf.org> <= br> Sent: Thursday, Novemb= er 1, 2012 8:28 AM
Subject: Re: [manet] Reactive Protocol Situation

=0A
On Wed, Oct 31, 2012 at 10:02 A= M, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:
=0A
=0A=0A=0A=0A=0A=0A
=0A
=0A
As someone who has not (yet) stated an = opinion on the matter, except I also think option 3 is not good, I would ve= ry much like to hear technical arguments,=0A so if you have technical argum= ents against LOADng, I think we need to hear them rather than just suggesti= ng they exist. I haven't yet read LOADng carefully to form a view there. I = have just recently read the AODVv2 draft carefully, and have some technical= =0A issues there (which overlap) regarding asymmetric links, possible depen= dency on NHDP, and the compatibility of options. If option 1 is followed, t= he draft needs work (which Charlie has acknowledged).<= /div>=0A=0A
 
&nb= sp;
=0A
I don't think we have time to was= te with LOADng, it was presented twice and no progress, the authors failed = to discuss on MANET list, and failed to update the draft to match MANET reu= irements. I agree that we focus our efforts to submit AODVv2 as soon as pos= sible,
=0A
 
AB
 
 
=0A
=  
=0A
=0A
--=0A=0A
Christopher Dearlove
=0A
Senior Principal Engineer, Communications Group
=0ACommunications= , Networks and Image Analysis Capability
=0ABAE Systems Advanced Technol= ogy Centre
=0AWest Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN,= UK
=0ATel: +44 1245 242194 |&nbs= p; Fax: +44 1245 242124
=0A=0A
chri= s.dearlove@baesystems.com=0A | http://www.baesystems.com
=0A<= br>=0ABAE Syste= ms (Operations) Limited
=0ARegistered Office: Warwick House, PO Box 87, = Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
=0ARegist= ered in England & Wales No: 1996687
=0A
= =0A
 
=0A
=0A
=0A
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org]=0AOn = Behalf Of JP Vasseur (jvasseur)
=0ASent: 31 October 2012 08:2= 9
=0ATo: Joseph Macker
=0ACc: <manet@ietf.org>
=0ASubject: Re: [manet] Reactive Pr= otocol Situation
=0A
=0A
=0A
 
=0A
=0A
=  
=0A
=0A
*** WARNING ***<= /u>
=0A=0A
=0A
=0A
=0ATh= is message originates from outside our organisation, either from an externa= l partner or the internet.
=0A=0AKeep this in mind if you = answer this message.
=0APlease see =0Athis process on how to deal with suspicious emails.<= u>
=0A
=0A
=0A<= div class=3D"yiv56582096MsoNormal">Dear chairs,
=0A=0A
 
=0A
= =0A
=0A
Remembering that I am not a = co-authors of either of these drafts.
=0A
=0A
 
=0A
=0A
=0A=
Not commenting on recent discussions= but rather focussing on what I hope will be a good solution for the WG and= the Internet at large.
=0A
=0A
=0A
 
=0A
=0A
=0A<= div class=3D"yiv56582096MsoNormal">Option 3) is my opinion not desirable; I wish we could have a reactive routing protocol for MANET<= /u>
=0A
=0A
=0A
=  
=0A
=0A
=0A
Option 2) is an option I would be strongly opposed to for= a number of technical reasons that I would be happy to elaborate on the=
=0A
=0A
=0A
ma= iling list and/or in a new I-D (which I would, should option 2 be chosen).<= u>
=0A
=0A
=0A
=  
=0A
=0A
=0A
That being said, I am extremely supportive of option 1),=0Aespecially in light of what Charlie said. First of all DYMO is the wor= king group
=0A
=0A
=0A
document and excellent progress has been made with recent revisi= ons. But even more importantly, Charlie managed to make it compatible =
=0A
=0A
=0A
with options, which is in my opinion the best of both worlds; = calling it AODVv2 is only not very sensible but avoids useful sensitivity a= round 
=0A
=0A
=0A
names.
=0A
=0A
=0A
 
=0A
=0A
=0A
Thus I would strongly support Option 1), conti= nue the work that Charlie has started, which by the way is not far from= completion. And 
=0A
=0A
=0A
as WG,we need to remember that this had been the WG = document, the result of years of work. Still by making it compatible with o= ther options, 
=0A
=0A
=0A
this is technically flexible and sound.=0A
=0A
=0A
 
=0A
=0A
=0A
Thanks.<= u>
=0A
=0A
=0A
=  
=0A
=0A
=0A
JP.
=0A
=0A
=0A
 
=0A
=0A
=0A
On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:<= u>
=0A
=0A

=0A
=0A<= u>
=0A
Hello MANET worki= ng group (form Stan and Joe),
=0A
=0AAs you are all probably aware, t= here has been WG activity lately on competing drafts for a MANET reactive p= rotocol - DYMO (reviving the current working group document that was parked= due to inactivity), and LOADng. Many months ago there was a somewhat autho= rship=0A led movement towards a common document effort and given positive f= eedback at the time we the chairs thought this was the best approach given = the authors potential to come together and gain the best of both efforts.&n= bsp; Since that period, there has been some fairly=0A strident and rancorou= s "at times" debate between the authors of the two documents.
=0A
=0A= During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they=0A both derive roughly from AODV concep= ts and LOADng had fairly active authorship and implementation efforts. We p= rovided a co-editing proposal to the authors and gave them the timeframe of= the Atlanta to come up with an answer back to us regarding this.  As= =0A of this writing, those discussions of a potential commonn document and = authorship merger have failed.
=0A
=0ATherefore, we find ourselves at= a crossroads. The authors of the two documents are divided, and it is unli= kely that progress on a merged document can be reached based upon recent au= thor feedback. I have also polled the earlier WG editor of DYMO, Ian Chaker= es,=0A and he is somewhat disengaged on the issue at the present time. = ; We see only 3 possible paths forward:
=0A
=0A1. Continue the work o= n the DYMO document, starting with whether there is consensus on its contin= ued approach and also the desire to rename it to AODVv2.
=0A2. Replace t= he existing DYMO document effort with the LOADng related document effort, d= efusing ealier references to LLNs as recommended in the last meeting minute= s, and to focus more motivationally on general MANET problem spaces (the au= thors seem to have agreed=0A to this issue if its a WG document).
=0A3. = Remove the working group charter for a reactive protocol, effectively killi= ng both documents, at least from a working group (WG) standpoint. This woul= d not be a reflection on the technology in either case, just an admission t= hat we are not working together=0A and reaching consensus.
=0A
=0AThe= co-chairs request and need your opinions on the options.  We have bee= n some silent collecting initial feedback and waiting for author feedback a= t this point.  Stan and I are both on travel prior to Atlanta so our r= esponses may be sparse and we will also=0A likely be in a "receive mode" fo= r a few days.  So send your opinions.
=0A
=0A-Joe
=0A________= _______________________________________
=0Amanet mailing list
=0Amanet@ietf.org
=0Ahttps://ww= w.ietf.org/mailman/listinfo/manet
=0A
=0A
 
=0A
=0A
= =0A
=0A
=0A*******************************************= *************************
=0AThis email and any attachments are confiden= tial to the intended
=0Arecipient and may also be privileged. If you are= not the intended
=0Arecipient please delete it from your system and not= ify the sender.
=0AYou should not copy it or use it for any purpose nor = disclose or
=0Adistribute its contents to any other person.
=0A******= **************************************************************
=0A
= =0A
=0A=0A
_______________________________________________
=0Ama= net mailing list
=0Amanet@ietf.org
= =0Ahttps://www.ietf.org/mailman/listinfo/manet
=0A

=0A

_______________________________________________
ma= net mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/man= et


--1737431079-83964582-1351784668=:10346-- From abdussalambaryun@gmail.com Thu Nov 1 08:46:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119E821F8EB0 for ; Thu, 1 Nov 2012 08:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.384 X-Spam-Level: X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-BRDm23qu14 for ; Thu, 1 Nov 2012 08:46:15 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B22DC21F8E9A for ; Thu, 1 Nov 2012 08:46:14 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3136409vcb.31 for ; Thu, 01 Nov 2012 08:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZRAOkt9o26AFeR6QMl6Eil0sv5OyKbz5fAKwP3z2O30=; b=Zxu2mmw+XXHgdsrwggGSMn+xTo9fQGxFpakGFK+1NmVM72zBMbrIG7F46IusfMuOKo +CU2x387/t6x0rNYg6w66Yl59pX/IB3T+isnbxtmObOJeIVDtYUo1X9EIKWsvtQvPP9n /Mtqc2qUFlcRw6aT4GF2WGllGoqJSFU1vxT8oNGZLXMpDf9QXcDOVPIJtRvo+ccCeRRO jvAgvspuRT4BuLEl8eQDQxq81fPLYJt2o1Yf739PBq9OXkolVlUga8lmvUiEC6KZV75y zzQ/9hnzy4KpO3B7qM7UCdy9OMwv5AGpN8d8lgHbJrlgII5Y3ylEnXlNNuigUToZ4hpS DNbQ== MIME-Version: 1.0 Received: by 10.52.77.101 with SMTP id r5mr51341015vdw.25.1351784774046; Thu, 01 Nov 2012 08:46:14 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 08:46:13 -0700 (PDT) In-Reply-To: <5010FCBB-9E4A-4129-B141-3C434DD70177@herberg.name> References: <5010FCBB-9E4A-4129-B141-3C434DD70177@herberg.name> Date: Thu, 1 Nov 2012 15:46:13 +0000 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: multipart/alternative; boundary=20cf307abd9345161804cd70eb9c Cc: " List" Subject: Re: [manet] Reactive Protocol - LOADng vs. AODVv2 at Atlanta X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:46:16 -0000 --20cf307abd9345161804cd70eb9c Content-Type: text/plain; charset=ISO-8859-1 I am participating in the meeting which is a two hour meeting, and I don't like to avoid this discussion, but like to avoid interrupts to WG progresses. Please note that my recommendation prefers to let LOADng discussions on the lists first (seems a suitable place/channel for such confusing issues), use our valuable f2f meeting time on IETF-WG works. However, agree that AD and Chairs will do the best practice. AB On Thu, Nov 1, 2012 at 3:38 PM, Ulrich Herberg wrote: > You don't have to participate in this discussion if you think it is such a > waste of time. It would be much more productive if you actually read both > drafts and give technical arguments for your opinion. Note that LOADng was > only started after there was no activity on DYMO for 2.5 years. A half-hour > discussion in the meeting seems not overly wasted time compared to that. > > Ulrich > > > On Nov 1, 2012, at 8:20, Abdussalam Baryun > wrote: > > I disagree with the present of LOADng, because it will need a full hour > discussion and will waste time as it already did twice. I recommend its > polace to discuss SHOULD be first on the MANET list (as required by MANET > Chair before but not followed). > > However, I agree that the Chairs and AD are kindly recommended to organise > the meeting and to make it efficient and progress mostly the WG works > without other companies issues. > > AB > > On Thu, Nov 1, 2012 at 2:47 PM, Don Sturek wrote: > >> >> Why not just have presentations from both prospective solutions in Atlanta >> (LOADng and AODVv2) and let the WG decide between these options as a work >> plan to address the reactive protocol requirement in MANET: >> 1) Progress LOADng (which seems to be happening anyway) >> 2) Progress AODVv2 (which seems to have stalled for 2+ years but now >> there are promises to pick that up) >> 3) Merge AODVv2 and LOADng (which I think is impractical given e-mail >> reflector traffic....) >> >> Not working on a reactive protocol seems like the least desirable outcome. >> While there have been inputs for each possible path, it is unclear from >> the reflector what the consensus of the group is. >> >> Personally, it would be useful to hear in Atlanta about large scale >> deployments (eg, working code) from each to help the WG decide. I think >> all relevant technical information should be provided by Atlanta to help >> the WG make the right decision. >> >> Don >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --20cf307abd9345161804cd70eb9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am participating in the meeting which is a two hour meeting, and I d= on't like to avoid this discussion, but like to avoid interrupts to WG = progresses. Please note that my recommendation prefers to let LOADng discus= sions on the lists first (seems a suitable place/channel for such confusing= issues), use our valuable f2f meeting time on IETF-WG works. However, agre= e that AD and Chairs will do the best practice.
=A0
AB

On Thu, Nov 1= , 2012 at 3:38 PM, Ulrich Herberg <ulrich@herberg.name> wr= ote:
You don't have to participate i= n this discussion if you think it is such a waste of time. It would be much= more productive if you actually read both drafts and give technical argume= nts for your opinion.=A0Note that LOADng was only started after there was n= o activity on DYMO for 2.5 years. A half-hour discussion in the meeting see= ms not overly wasted time compared to that.

Ulrich


On Nov 1, = 2012, at 8:20, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

I disagree with the present o= f LOADng, because it will need a full hour discussion and will waste time a= s it already did twice. I recommend its polace to discuss SHOULD be first o= n the MANET list (as required by MANET Chair before but not followed).
=A0
However, I agree that the Chairs and AD are kindly=A0rec= ommended to organise the meeting and to make it efficient and progress most= ly the WG works without other companies issues.
=A0
AB<= br>
On Thu, Nov 1, 2012 at 2:47 PM, Don St= urek <d.sturek@att.net> wrote:

Why not just have presentations from both prospective solutions in Atlanta<= br> (LOADng and AODVv2) and let the WG decide between these options as a work plan to address the reactive protocol requirement in MANET:
1) =A0Progress LOADng (which seems to be happening anyway)
2) =A0Progress AODVv2 (which seems to have stalled for 2+ years but now
there are promises to pick that up)
3) =A0Merge AODVv2 and LOADng (which I think is impractical given e-mail reflector traffic....)

Not working on a reactive protocol seems like the least desirable outcome.<= br> =A0 While there have been inputs for each possible path, it is unclear from=
the reflector what the consensus of the group is.

Personally, it would be useful to hear in Atlanta about large scale
deployments (eg, working code) from each to help the WG decide. =A0 I think=
all relevant technical information should be provided by Atlanta to help the WG make the right decision.

Don



_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

___________________= ____________________________
manet mailing list
<= span>manet@ietf.org=
https://www.ietf.org/mailman/listinfo/manet

--20cf307abd9345161804cd70eb9c-- From jblack.ietf@yahoo.com Thu Nov 1 08:47:35 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F2321F8E97 for ; Thu, 1 Nov 2012 08:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYoF1t+tGMLs for ; Thu, 1 Nov 2012 08:47:34 -0700 (PDT) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 73E6121F8E63 for ; Thu, 1 Nov 2012 08:47:34 -0700 (PDT) Received: from [98.139.215.140] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 15:47:33 -0000 Received: from [98.139.212.219] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 15:47:33 -0000 Received: from [127.0.0.1] by omp1028.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 15:47:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 263586.48278.bm@omp1028.mail.bf1.yahoo.com Received: (qmail 31935 invoked by uid 60001); 1 Nov 2012 15:47:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351784853; bh=zd5TEP38t34/hp6Xd2kZ6JPubKrQa+UR96Rca0+S/6U=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=g+ImQgioEyOCcQ68YNHibgcZUf/zn7f5B7EW/16pREp8laVCUJxU1Xm72+23wSt0+K/9snupZduE3MEP3NcWQ/W7fzAETNpG4C82m+LDQ7a93wD+vdoNo/fkn+dfOMLI/uTznwcLwn6gwRbrtmxDMPWfOXuqZMfpxkNQ/S41rkQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=sBpVeSkkiSY3Y7Fu7xoVDho0W97Z23D+9SRWLACMXF1nt6gk6O5H/PCipqEPr73n5ib86D57d0wKVfvu6sTmMOv2SIwdNTisBkCoJn73dUfP0B89wsAA8XcPZvoXCj3uEZJ41jdeI9LfWuZiswNjWU6bBSpDW4Ty1aZ4SIEydMs=; X-YMail-OSG: be_UQjgVM1nhShXW9stQFCycyEnxmTEZSXXG0HSty2fRK9W Hk.iT63FQ Received: from [67.213.218.74] by web160604.mail.bf1.yahoo.com via HTTP; Thu, 01 Nov 2012 08:47:32 PDT X-Rocket-MIMEInfo: 001.001, KzEKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBEb24gU3R1cmVrIDxkLnN0dXJla0BhdHQubmV0PgpUbzogIjxtYW5ldEBpZXRmLm9yZz4gTGlzdCIgPG1hbmV0QGlldGYub3JnPiAKU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDEsIDIwMTIgODo0NyBBTQpTdWJqZWN0OiBbbWFuZXRdIFJlYWN0aXZlIFByb3RvY29sIC0gTE9BRG5nIHZzLiBBT0RWdjIgYXQgQXRsYW50YQogCgpXaHkgbm90IGp1c3QgaGF2ZSBwcmVzZW50YXRpb25zIGZyb20gYm90aCBwcm9zcGVjdGl2ZSBzb2wBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: Message-ID: <1351784852.3640.YahooMailNeo@web160604.mail.bf1.yahoo.com> Date: Thu, 1 Nov 2012 08:47:32 -0700 (PDT) From: Jon Black To: Don Sturek , " List" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-318397788-532125479-1351784852=:3640" Subject: Re: [manet] Reactive Protocol - LOADng vs. AODVv2 at Atlanta X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:47:35 -0000 ---318397788-532125479-1351784852=:3640 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable +1=0A=0A=0A=0A=0A________________________________=0A From: Don Sturek =0ATo: " List" =0ASent: Thurs= day, November 1, 2012 8:47 AM=0ASubject: [manet] Reactive Protocol - LOADng= vs. AODVv2 at Atlanta=0A =0A=0AWhy not just have presentations from both p= rospective solutions in Atlanta=0A(LOADng and AODVv2) and let the WG decide= between these options as a work=0Aplan to address the reactive protocol re= quirement in MANET:=0A1)=A0 Progress LOADng (which seems to be happening an= yway)=0A2)=A0 Progress AODVv2 (which seems to have stalled for 2+ years but= now=0Athere are promises to pick that up)=0A3)=A0 Merge AODVv2 and LOADng = (which I think is impractical given e-mail=0Areflector traffic....)=0A=0ANo= t working on a reactive protocol seems like the least desirable outcome.=0A= =A0 While there have been inputs for each possible path, it is unclear from= =0Athe reflector what the consensus of the group is.=0A=0APersonally, it wo= uld be useful to hear in Atlanta about large scale=0Adeployments (eg, worki= ng code) from each to help the WG decide.=A0 I think=0Aall relevant techni= cal information should be provided by Atlanta to help=0Athe WG make the rig= ht decision.=0A=0ADon=0A=0A=0A=0A__________________________________________= _____=0Amanet mailing list=0Amanet@ietf.org=0Ahttps://www.ietf.org/mailman/= listinfo/manet ---318397788-532125479-1351784852=:3640 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable _______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
+1
<= /div>

From: Don Sturek <d.sturek@att.net&g= t;
To: "<manet@ietf= .org> List" <manet@ietf.org>
Sent: Thursday, November 1, 2012 8:47 AM
Subject: [manet] Reactive Protocol - LO= ADng vs. AODVv2 at Atlanta

=0A
Why not just have = presentations from both prospective solutions in Atlanta
(LOADng and AOD= Vv2) and let the WG decide between these options as a work
plan to addre= ss the reactive protocol requirement in MANET:
1)  Progress LOADng = (which seems to be happening anyway)
2)  Progress AODVv2 (which see= ms to have stalled for 2+ years but now
there are promises to pick that = up)
3)  Merge AODVv2 and LOADng (which I think is impractical given= e-mail
reflector traffic....)

Not working on a reactive protocol= seems like the least desirable outcome.
  While there have been in= puts for each possible path, it is unclear from
the reflector what the c= onsensus of the group is.

Personally, it would be useful to hear in = Atlanta about large scale
deployments (eg, working code) from each to he= lp the WG decide.  I think
all relevant technical information shou= ld be provided by Atlanta to help
the WG make the right decision.

Don



_______________________= ________________________
manet mailing list
manet@ietf.org
https://www= .ietf.org/mailman/listinfo/manet


---318397788-532125479-1351784852=:3640-- From alexandru.petrescu@gmail.com Thu Nov 1 08:50:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FD421F8EE4 for ; Thu, 1 Nov 2012 08:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qlz+BDJCey8 for ; Thu, 1 Nov 2012 08:50:39 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1D78D21F8EE3 for ; Thu, 1 Nov 2012 08:50:38 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so399376wib.13 for ; Thu, 01 Nov 2012 08:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Xxv5ftvHU0b5N3/RiNGkyIJRDaYBl5A2Lc8SmVL5MeA=; b=bFPOlI4AhJp9i0/qaVqfUcWNo3tOj2KDhHoAmZpBW8iiOINrVO+e7EtqwmJuBP3HFh 9Bax6ItWm6kcfFb4AZoTmSnBZ9KYJXsvRoMD7kYTp1/b59achySUOukIWzyOy01T+BJa cMTnIit7pzSoFIp8R1gZEC884sUkCYjfp1wImwvonlweCCDp9c4GIMZGK/yiqRlCNzYd 285axfNOTOSRYyZQtLd60BB/AJ5zRItUMj5PcWqsX92v0XeyNBewuHEVjsf16dhE0O6q PLI/PhkxMyGCOMJNKFMwuA0vhhNyIEC+9V63oWMnarcqd/fB0jkM/dAk39t55lmuvKx4 UZjA== Received: by 10.180.81.37 with SMTP id w5mr2546310wix.10.1351785038145; Thu, 01 Nov 2012 08:50:38 -0700 (PDT) Received: from [192.168.0.14] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id eq2sm10935201wib.1.2012.11.01.08.50.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Nov 2012 08:50:36 -0700 (PDT) Message-ID: <50929A47.1000600@gmail.com> Date: Thu, 01 Nov 2012 16:50:31 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: manet@ietf.org References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <2CF862E3-F417-4442-B597-6DCBA035D4B9@cisco.com> <1351784420.69738.YahooMailNeo@web160603.mail.bf1.yahoo.com> In-Reply-To: <1351784420.69738.YahooMailNeo@web160603.mail.bf1.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [manet] Mobility and eMeters (was: no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:50:40 -0000 Le 01/11/2012 16:40, Jon Black a écrit : > Mobility in a wireless sense means a changing connectivity. A > wireless device does not need to physically move to appear mobile - > the connectivity path changes. I agree that mobility in a wireless sense means changing connectivity. And that devices do not need to physically move to appear mobile in that sense. > Now if you live in a mobile home maybe your meter may also > physically move. Maybe your mobile home doesn't have wheels. Or does it? A mobile home is an challenging concept with respect to connectivity of electricity Meters. Many mobile Homes plug on electricity lines either without any Meter, or with a Meter that is fixed outside the mobile home and that is somebody else's. 'Mobility' and electricity distributors is mentioned also as the mobility of an operator walking around fixed consumer householdings and reading the Meter data wirelessly, instead of entering the various places where Meters are stored. For these cases, I do not know whether a routing protocol in MANET is adapted, or not, or so and so. Alex > > Jon > > > ------------------------------------------------------------------------ > > > *From:* Bo Berry > *To:* "Dearlove, Christopher (UK)" > *Cc:* JP Vasseur (jvasseur) ; Jon Black > ; "manet@ietf.org" ; > "thierry.lys@erdfdistribution.fr" > *Sent:* Thursday, November 1, 2012 4:22 AM *Subject:* Re: [manet] > (no subject) > > And to be fair, I've not seen results on Loadng wrt to mobility. > The smart meter attached to my house has not moved sense it was > installed. > > > On Nov 1, 2012, at 6:10 AM, Dearlove, Christopher (UK) wrote: > >> If I were in charge of requirements, that requirement would be >> now. >> > Attempting to sway a decision on the basis of "I have results" but > not offering those results until the decision is made is not > helpful. And the most important thing is are there any comparisons > between the two (or with base AODV)? Without those, the issue is how > do the two differ technically in a manner that matters? >> >> -- Christopher Dearlove Senior Principal Engineer, Communications >> Group Communications, Networks and Image Analysis Capability BAE >> Systems Advanced Technology Centre West Hanningfield Road, Great >> Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 >> 1245 242124 chris.dearlove@baesystems.com >> > | http://www.baesystems.com >> >> BAE Systems (Operations) Limited Registered Office: Warwick House, >> PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> From: manet-bounces@ietf.org > [mailto:manet-bounces@ietf.org ] On > Behalf Of JP Vasseur (jvasseur) >> Sent: 31 October 2012 22:09 To: Jon Black Cc: >> thierry.lys@erdfdistribution.fr > ; manet@ietf.org > >> Subject: Re: [manet] (no subject) >> >> >> *** WARNING *** This message originates from outside our >> organisation, either from an > external partner or the internet. >> Keep this in mind if you answer this message. Please see this >> process on how to deal with suspicious emails. >> >> >> On Oct 31, 2012, at 6:57 PM, Jon Black wrote: >> >> >> On October 31, 2012 Thierry.Lys wrote: >> >> I speak in the name of EDF group. >> >> We started first to use LOAD as a routing algorithm and deployed >> 2000 > PLC-meters for smart grid purposes in 2011. Taking advantage of this > field test, we have been actively participating to the working group > to adopt enhancements in the LOADng specification. >> We are now extremely pleased with what LOADng is capable of and >> are >> > confident that future deployements will be equipped with it. >> >> This would seem to indicate that LOADng does work and in a rather > large deployment. >> >> JP> No this means that LoadNG works in *a* network. But the major > technical difference here is that reactive routing is highly > impacted >> by the user traffic … If you poll a meter every 24 hours, it may >> work > perfectly well. Now if you start having more frequent traffic flows >> you can either cache paths (ending up with more frequent broken >> paths > considering how flappy these networks are, thus leading to more >> floods … very undesirable … especially when you have hundreds of > meters sharing a few Kbits/s) or you use short cache timers and you >> keep flooding :-( If you take actual traces of these networks >> (both >> > using 15.4g and P1901.2) and you start adjusting the user traffic > rate you >> immediately see the issues in terms of scalability. Yes you can >> try >> > to mitigate the undesirable flooding effect to some extends but > showing >> the limits in terms of scalability is easy to show. Note that I >> MOT >> > against reactive routing by any means, this is IMO just not > applicable to >> LLNs unless the traffic flows are deterministic and very well >> knows … > Lessons from the past show us how difficult it is to predict user >> applications. We all started with meter reading to continue with >> that > example and now many utilities wants to use these smart metering >> networks for a number of applications which different SLA, … >> >> Hope this helps. Once again, when/if required I would be happy to > share many results. >> >> >> >> >> "We believe in rough consensus and running code" >> >> rough consensus : Don't you think we have a rough consensus on >> LOADng > compared to DYMO ? 10 authors and major companies are supporters of > LOADng. >> >> running code : interoperability has been checked with 4 sources >> and >> > other implementations are in progress. >> >> Obviously from the list we don't have rough consensus. We have >> two >> > alternatives each with proponents. The WG should weigh the > technical benefits (design, implementation/running code, maturity) > of each and the group should choose a path forward. >> >> In my opinion option 3 is not an option - this is the working >> group >> > shirking its responsibility. >> >> This is an option … since listed by the chairs. I agree that we > should avoid it, especially when I think we have a very reasonable > solution >> (option1). >> >> JP. >> >> >> >> Jon >> >> _______________________________________________ manet mailing list >> manet@ietf.org >> 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. >> ******************************************************************** > >> >> > >> _______________________________________________ manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > > > > > _______________________________________________ manet mailing list > manet@ietf.org https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Thu Nov 1 08:53:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA7221F8A53 for ; Thu, 1 Nov 2012 08:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.401 X-Spam-Level: X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnchSxGDK8VD for ; Thu, 1 Nov 2012 08:53:25 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 41AB321F8A50 for ; Thu, 1 Nov 2012 08:53:23 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3144935vcb.31 for ; Thu, 01 Nov 2012 08:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Dsns58Pb8xNQEWG1je8cYCkBQPetShPIMSCwXQJfrMU=; b=yyA0ctn3m0qxr1oVguclxJwrVfL1Zy39eIx70EseKZk40YBe0lJZU5k32rPuo1PdnZ H+MLpWVmFf76d6MSUWU459gURc3YaDLwTJ+YhrBVX7nuOsz2MzMkfpIpeC0f/4fa8tZC cU1ymZL+TLZrFFf0K9hCkyZ3SrrATUrwjnTRSxbfNwhX+rYlA3cXMHo6XPkW7sMrMKyX 8gKz5MQtZJZRLToancQhHjCoqfR9OTE5R3ZCX/krH5/D4jQXH0/pVY11SrrVatZQMGsa 18PmdtzFg44g0Bu2RGWMFqtJo0utZPHosKBmr35VX+a3RoCNroUmyjEjKblTU7/Dnfwv JPzQ== MIME-Version: 1.0 Received: by 10.220.8.195 with SMTP id i3mr23048339vci.44.1351785203511; Thu, 01 Nov 2012 08:53:23 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 08:53:23 -0700 (PDT) In-Reply-To: <1351784251.48543.YahooMailNeo@web160605.mail.bf1.yahoo.com> References: <1351784251.48543.YahooMailNeo@web160605.mail.bf1.yahoo.com> Date: Thu, 1 Nov 2012 15:53:23 +0000 Message-ID: From: Abdussalam Baryun To: Jon Black Content-Type: multipart/alternative; boundary=bcaec54fbbb8de312d04cd7104c6 Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:53:26 -0000 --bcaec54fbbb8de312d04cd7104c6 Content-Type: text/plain; charset=ISO-8859-1 Yes LOADng is a reactive protocols, but not the MANET WG reactive protocol (DYMO is already authorised). The WG is the only authorised to make such decisions for its WG drafts, if WG decides to add any LOADng ideas it can, or to accept such merge it can as well, AB On Thu, Nov 1, 2012 at 3:37 PM, Jon Black wrote: > Why would you think that LOADng is not reactive? If it is not a reactive > protocol, then what is it? > > As to merging the documents, this is what WGs do. If you have multiple > "competing" ideas you ask the authors to see if they can merge their > concepts and ideas. If they cannot or will not then the WG must decide > based on facts and not conjecture which is the most prudent path to take. > > Jon > > > ------------------------------ > *From:* Abdussalam Baryun > *To:* Joseph Macker > *Cc:* manet@ietf.org; Stan Ratliff > *Sent:* Thursday, November 1, 2012 8:22 AM > > *Subject:* Re: [manet] Reactive Protocol Situation > > Dear Joseph Macker and Stan, > MANET WG Chairs > > I disagree that the WG arranged/guided to merge the documents, I never > heard that there was a consensus on such activity. DYMO is a reactive WG > draft, but LOADng is not. Why did you guide to merge documents, I recommend > that you ment to merge the team drafts co-authors to one WG draft (which is > only DYMO so far). The authority is for the WG to decide to merge > individual drafts to its WG draft. > > Therefore, my vote is for option 1 only. Thanking you for updating us with > the status. > > Regards > AB > > On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker wrote: > > Hello MANET working group (form Stan and Joe), > > As you are all probably aware, there has been WG activity lately on > competing drafts for a MANET reactive protocol - DYMO (reviving the current > working group document that was parked due to inactivity), and LOADng. Many > months ago there was a somewhat authorship led movement towards a common > document effort and given positive feedback at the time we the chairs > thought this was the best approach given the authors potential to come > together and gain the best of both efforts. Since that period, there has > been some fairly strident and rancorous "at times" debate between the > authors of the two documents. > > During IETF 84 in Vancouver, the co-chairs held a discussion with some of > the co-authors of the two documents. Our guidance to the co-authors was to > find a way to merge the two documents into one, as it was perceived that > are not technically far apart and they both derive roughly from AODV > concepts and LOADng had fairly active authorship and implementation > efforts. We provided a co-editing proposal to the authors and gave them the > timeframe of the Atlanta to come up with an answer back to us regarding > this. As of this writing, those discussions of a potential commonn > document and authorship merger have failed. > > Therefore, we find ourselves at a crossroads. The authors of the two > documents are divided, and it is unlikely that progress on a merged > document can be reached based upon recent author feedback. I have also > polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat > disengaged on the issue at the present time. We see only 3 possible paths > forward: > > 1. Continue the work on the DYMO document, starting with whether there is > consensus on its continued approach and also the desire to rename it to > AODVv2. > 2. Replace the existing DYMO document effort with the LOADng related > document effort, defusing ealier references to LLNs as recommended in the > last meeting minutes, and to focus more motivationally on general MANET > problem spaces (the authors seem to have agreed to this issue if its a WG > document). > 3. Remove the working group charter for a reactive protocol, effectively > killing both documents, at least from a working group (WG) standpoint. This > would not be a reflection on the technology in either case, just an > admission that we are not working together and reaching consensus. > > The co-chairs request and need your opinions on the options. We have been > some silent collecting initial feedback and waiting for author feedback at > this point. Stan and I are both on travel prior to Atlanta so our > responses may be sparse and we will also likely be in a "receive mode" for > a few days. So send your opinions. > > -Joe > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > --bcaec54fbbb8de312d04cd7104c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes LOADng is a reactive protocols, but not the MANET=A0WG reactive pr= otocol (DYMO is already authorised). The WG is the only authorised to make = such decisions for its WG drafts, if WG decides to add any LOADng ideas it = can, or to accept such merge it can as well,
AB
On Thu, Nov 1, 2012 at 3:= 37 PM, Jon Black <jblack.ietf@yahoo.com> wrote:
Why would you think that LOADng is not reactive?=A0 If it is not a= reactive protocol, then what is it?

As to merging the documents, th= is is what WGs do.=A0 If you have multiple "competing" ideas you = ask the authors to see if they can merge their concepts and ideas.=A0 If th= ey cannot or will not then the WG must decide based on facts and not conjec= ture which is the most prudent path to take.

Jon


From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: Joseph Macker <jpmacker@gmail.com>
Cc: manet@ietf.org; Stan Ratliff <sratliff@cisco.com> Sent: Thursday, November = 1, 2012 8:22 AM

Subject: Re: [manet] Re= active Protocol Situation
<= br>
Dear Joseph Macker and Stan,
MANET WG Chairs
= =A0
I disagree that the=A0WG=A0arranged/guided to merge the docum= ents, I never heard that there was a consensus on such activity. DYMO is a = reactive WG draft, but LOADng is not. Why did you guide to merge documents,= I recommend that you ment to merge the team drafts co-authors to one=A0WG = draft (which is only DYMO so far). The authority is for the WG to decide to= merge individual drafts to its WG draft.
=A0
Therefore, my vote is for option 1 only. Thanking you fo= r updating us with the status.
=A0
Regards
AB=

On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker <jpmacker@gmail.com> wrote:
Hello= MANET working group (form Stan and Joe),

As you are all probably aw= are, there has been WG activity lately on competing drafts for a MANET reac= tive protocol - DYMO (reviving the current working group document that was = parked due to inactivity), and LOADng. Many months ago there was a somewhat= authorship led movement towards a common document effort and given positiv= e feedback at the time we the chairs thought this was the best approach giv= en the authors potential to come together and gain the best of both efforts= .=A0 Since that period, there has been some fairly strident and rancorous &= quot;at times" debate between the authors of the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some = of the co-authors of the two documents. Our guidance to the co-authors was = to find a way to merge the two documents into one, as it was perceived that= are not technically far apart and they both derive roughly from AODV conce= pts and LOADng had fairly active authorship and implementation efforts. We = provided a co-editing proposal to the authors and gave them the timeframe o= f the Atlanta to come up with an answer back to us regarding this.=A0 As of= this writing, those discussions of a potential commonn document and author= ship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two do= cuments are divided, and it is unlikely that progress on a merged document = can be reached based upon recent author feedback. I have also polled the ea= rlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the= issue at the present time.=A0 We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there = is consensus on its continued approach and also the desire to rename it to = AODVv2.
2. Replace the existing DYMO document effort with the LOADng rel= ated document effort, defusing ealier references to LLNs as recommended in = the last meeting minutes, and to focus more motivationally on general MANET= problem spaces (the authors seem to have agreed to this issue if its a WG = document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.=A0 We have= been some silent collecting initial feedback and waiting for author feedba= ck at this point.=A0 Stan and I are both on travel prior to Atlanta so our = responses may be sparse and we will also likely be in a "receive mode&= quot; for a few days.=A0 So send your opinions.

-Joe

_______________________________________________
manet mailing list
manet@= ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing = list
manet@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/manet



--bcaec54fbbb8de312d04cd7104c6-- From pal@cs.stanford.edu Thu Nov 1 09:05:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C8121F8EB6 for ; Thu, 1 Nov 2012 09:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxI3UxXXscv4 for ; Thu, 1 Nov 2012 09:04:59 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id 54B8721F8E89 for ; Thu, 1 Nov 2012 09:04:57 -0700 (PDT) Received: from dn0a210082.sunet ([10.33.0.130]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TTxGD-0007vb-PZ; Thu, 01 Nov 2012 09:04:55 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <1351704196.28009.YahooMailNeo@web160603.mail.bf1.yahoo.com> Date: Thu, 1 Nov 2012 09:04:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9272AD1B-C718-4F30-8764-D7BC75679238@cs.stanford.edu> References: <1351704196.28009.YahooMailNeo@web160603.mail.bf1.yahoo.com> To: Jon Black X-Mailer: Apple Mail (2.1283) X-Scan-Signature: 5fb79390a4aad79c01ba7e4883e5f1df Cc: "thierry.lys@erdfdistribution.fr" , "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:05:00 -0000 On Oct 31, 2012, at 10:23 AM, Jon Black wrote: > On October 31, 2012 at 12:45 PM, JPVasseur wrote: >=20 > >JP> Well let's see what the chairs think of course. Having all = authors of Load-NG supporting it was expected though. >=20 > And hearing from the RPL authors not supporting it is expected. There are many RPL authors. Some of us are remaining silent. Phil= From jblack.ietf@yahoo.com Thu Nov 1 09:09:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7947921F8DAE for ; Thu, 1 Nov 2012 09:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57GxJik6xe3t for ; Thu, 1 Nov 2012 09:09:18 -0700 (PDT) Received: from nm35-vm7.bullet.mail.bf1.yahoo.com (nm35-vm7.bullet.mail.bf1.yahoo.com [72.30.238.79]) by ietfa.amsl.com (Postfix) with ESMTP id B23E621F8DAD for ; Thu, 1 Nov 2012 09:09:17 -0700 (PDT) Received: from [98.139.214.32] by nm35.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 16:09:16 -0000 Received: from [98.139.212.231] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 16:09:16 -0000 Received: from [127.0.0.1] by omp1040.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 16:09:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 908281.36830.bm@omp1040.mail.bf1.yahoo.com Received: (qmail 59870 invoked by uid 60001); 1 Nov 2012 16:09:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351786156; bh=k+zXbhWCv3rohb5z3EHiatX/MiEKd2LTIqTD0hxURIs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=cCULh+jtbC8s7zSeQqAOsceM9ZSTU0BnGqqH73xLtpmdlSA2vg1LdzOqio7VSrCFUcWpoqoF3XNe8qw+FoRNtF1MpBIa/R3ccPJTsAOAdltI43rErd3FVk/78CspkcQfAigIIGXIQ/uEutBNXJbBedortrCc1ygzqQDvFq1z0Yw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GzInVNxbtUcIcadSU9+8q81v9HEEW816zqgQ9Mg733RCFIzvwf0/XfDx+SDsEOIYSPL4H1llJoIqF/eBn4EyLz+I1OkdeHI4evDTpbd/ASQpZPLoYvZ0u6XljerjjnXq0WNpkiEn6j1aW4uiyCbidqgN0nVbW+MPTNsw2HK/MNE=; X-YMail-OSG: FpxGDaYVM1lJww5jeV.zS_LW0zN1VGWZEG0U146p3k3PFwn 0QWebRUR03lbTpGWKgT8VaoVerTeQyrTEOwYeSYZwz15I1rjnhjk.DjInSyk lXFRxZ5h3qzUc0UXelMui4UmE0V2Q4SW_PFkxN6Jzz4jZXkcWH.JIrDyQi_8 PATb3zXbCa9zL0M_9_voAfbK3ikhIAWE_beBO6zn1bowj_7SG2HRIiB_7oh0 yqQzOkY8Pwi7VYr3oAOknJ2sryEUaDov4uNvxZBpgSjVjNbuvXGsSjGx6Okk _MHd2oLwjQWSuvgOMIQh7kdQwq02OHJEq8_agdpu7QDf2DKH9LXJg3F.5O22 u.FtXCnkRF3wXy1fqLDLjN7fAxsHG3ipJFDEiUJzNgswQRxbHsSuKI57W.MJ zH5rXGHm3_aHEEe2C37oI44.o9hjUKHk.bOHRF7VmCLB5OOgUheyuUGvkNMv 7RlioQrU- Received: from [67.213.218.74] by web160604.mail.bf1.yahoo.com via HTTP; Thu, 01 Nov 2012 09:09:16 PDT X-Rocket-MIMEInfo: 001.001, Tm90ZWQhCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBQaGlsaXAgTGV2aXMgPHBhbEBjcy5zdGFuZm9yZC5lZHU.ClRvOiBKb24gQmxhY2sgPGpibGFjay5pZXRmQHlhaG9vLmNvbT4gCkNjOiAibWFuZXRAaWV0Zi5vcmciIDxtYW5ldEBpZXRmLm9yZz47ICJ0aGllcnJ5Lmx5c0BlcmRmZGlzdHJpYnV0aW9uLmZyIiA8dGhpZXJyeS5seXNAZXJkZmRpc3RyaWJ1dGlvbi5mcj4gClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxLCAyMDEyIDEwOjA0IEFNClN1YmplY3Q6IFJlOiBbbWEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <1351704196.28009.YahooMailNeo@web160603.mail.bf1.yahoo.com> <9272AD1B-C718-4F30-8764-D7BC75679238@cs.stanford.edu> Message-ID: <1351786156.58385.YahooMailNeo@web160604.mail.bf1.yahoo.com> Date: Thu, 1 Nov 2012 09:09:16 -0700 (PDT) From: Jon Black To: Philip Levis In-Reply-To: <9272AD1B-C718-4F30-8764-D7BC75679238@cs.stanford.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-318397788-322038890-1351786156=:58385" Cc: "thierry.lys@erdfdistribution.fr" , "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:09:18 -0000 ---318397788-322038890-1351786156=:58385 Content-Type: text/plain; charset=us-ascii Noted! ________________________________ From: Philip Levis To: Jon Black Cc: "manet@ietf.org" ; "thierry.lys@erdfdistribution.fr" Sent: Thursday, November 1, 2012 10:04 AM Subject: Re: [manet] Reactive Protocol Situation On Oct 31, 2012, at 10:23 AM, Jon Black wrote: > On October 31, 2012 at 12:45 PM, JPVasseur wrote: > > >JP> Well let's see what the chairs think of course. Having all authors of Load-NG supporting it was expected though. > > And hearing from the RPL authors not supporting it is expected. There are many RPL authors. Some of us are remaining silent. Phil ---318397788-322038890-1351786156=:58385 Content-Type: text/html; charset=us-ascii
Noted!

From: Philip Levis <pal@cs.stanford.edu>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@ietf.org>; "thierry.lys@erdfdistribution.fr" <thierry.lys@erdfdistribution.fr>
Sent: Thursday, November 1, 2012 10:04 AM
Subject: Re: [manet] Reactive Protocol Situation

On Oct 31, 2012, at 10:23 AM, Jon Black wrote:

> On October 31, 2012 at 12:45 PM, JPVasseur wrote:
>
> >JP> Well let's see what the chairs think of course. Having all authors of Load-NG supporting it was expected though.
>
> And hearing from the RPL authors not supporting it is expected.

There are many RPL authors. Some of us are remaining silent.

Phil

---318397788-322038890-1351786156=:58385-- From ietf@thomasclausen.org Thu Nov 1 09:20:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6472B21F8FAB for ; Thu, 1 Nov 2012 09:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.041 X-Spam-Level: * X-Spam-Status: No, score=1.041 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Om01a4NyYJUM for ; Thu, 1 Nov 2012 09:20:29 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1341921F8F4C for ; Thu, 1 Nov 2012 09:20:29 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id B24A1559B70 for ; Thu, 1 Nov 2012 09:20:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A12B11C08C0; Thu, 1 Nov 2012 09:20:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.84.81.194] (37-8-167-152.coucou-networks.fr [37.8.167.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id A411C1C087B; Thu, 1 Nov 2012 09:20:24 -0700 (PDT) References: <50902CF3.9070903@computer.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-47880B23-1FA9-43E3-B455-E597361ABE93 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10A403) From: Thomas Heide Clausen Date: Thu, 1 Nov 2012 17:20:22 +0100 To: Abdussalam Baryun Cc: manet Subject: Re: [manet] Flooding: how to make a normative reference? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:20:46 -0000 --Apple-Mail-47880B23-1FA9-43E3-B455-E597361ABE93 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable You know of RFC6621, yes? --=20 Thomas Heide Clausen http://www.thomasclausen.org "Today's scientists have substituted mathematics for=20 experiments, and they wander off through equation=20 after equation, and eventually build a structure=20 which has no relation to reality." - Nikola Tesla,=20 Modern Mechanics and Inventions, July, 1934 On 1 nov. 2012, at 16:41, Abdussalam Baryun wro= te: > It will be interesting to have the flooding algorithm I-D as you mentioned= so we can refer by MANET protocols, but also I support that OLSRv2 has no n= eed to take out such technique (as chris mentioned). However, your suggestio= n will give more flexibility to AODVv2 as a MANET protocol. > =20 > I also agree that AODVv2 should not reference OLSRv2 as normative for your= mentioned reasons. > =20 > AB >=20 > On Tue, Oct 30, 2012 at 7:39 PM, Charles E. Perkins wrote: >>=20 >> Hello folks, >>=20 >> I think it is well recognized that brute force flooding often leads to >> poor performance in ad hoc networks with many nodes. Thus, we >> have RFC 6621 to describe various other approaches. Plus, we have >> MPR flooding as described in the OLSRv2 document. >>=20 >> For reactive, it is quite important to enable "better" algorithms >> for flooding. AODVv2 could quite reasonable use a MPR-based >> flooding, or flooding based over any connected dominating set. >>=20 >> It seems wrong to have AODVv2 cite OLSRv2 in any normative >> fashion, just to get access to the MPR flooding mechanism which >> can run independently of the routing protocol (and, perhaps, >> should do so). It also seems wrong to cite RFC 6621 in any >> normative fashion since that is an Experimental specification. >>=20 >> Don't we need to have some Proposed Standard documents that >> specify more scalable approaches to flooding, that are independent >> of routing protocols? >>=20 >> I guess it's too late to suggest that the MPR specification should >> be pulled out of OLSRv2 for this purpose... >>=20 >> I looked back for some discussion about this on the list, but I >> didn't find it, but my search was hardly exhaustive. >>=20 >> --=20 >> Regards, >> Charlie P. >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-47880B23-1FA9-43E3-B455-E597361ABE93 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
You know of RFC6621, yes?

= -- 
Thomas Heide Clausen

"To= day's scientists have substituted mathematics for 
 &nbs= p;experiments, and they wander off through equation 
 &n= bsp;after equation, and eventually  build a structure 
&= nbsp; which has no relation to reality."
 - Nikola Tesla= , 
    Modern Mechanics and Inventions, July, 1= 934

On 1 nov. 2012, at 16:41, Abdussalam Baryun <abdussalambaryun@gmail.com>= wrote:

It will be interest= ing to have the flooding algorithm I-D as you mentioned so we can refer by M= ANET protocols, but also I support that OLSRv2 has no need to take out such t= echnique (as chris mentioned). However, your suggestion will give more f= lexibility to AODVv2 as a MANET protocol.
 
I also agree that AODVv2 should not reference OLSRv2 a= s normative for your mentioned reasons.
 
AB
On Tue, Oct 30, 2012 at 7:39 PM, Charles E= . Perkins <charliep@computer.org> wrote:

Hello folks,

I think it is well recognized that brute force flooding often leads to
poor performance in ad hoc networks with many nodes.  Thus, we
have RFC 6621 to describe various other approaches.  Plus, we have
MPR flooding as described in the OLSRv2 document.

For reactive, it is quite important to enable "better" algorithms
for flooding.  AODVv2 could quite reasonable use a MPR-based
flooding, or flooding based over any connected dominating set.

It seems wrong to have AODVv2 cite OLSRv2 in any normative
fashion, just to get access to the MPR flooding mechanism which
can run independently of the routing protocol (and, perhaps,
should do so).  It also seems wrong to cite RFC 6621 in any
normative fashion since that is an Experimental specification.

Don't we need to have some Proposed Standard documents that
specify more scalable approaches to flooding, that are independent
of routing protocols?

I guess it's too late to suggest that the MPR specification should
be pulled out of OLSRv2 for this purpose...

I looked back for some discussion about this on the list, but I
didn't find it, but my search was hardly exhaustive.<= font color=3D"#888888">

--
Regards,
Charlie P.

_______________________________________________
manet mailing list
manet@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet

____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-47880B23-1FA9-43E3-B455-E597361ABE93-- From Chris.Dearlove@baesystems.com Thu Nov 1 09:22:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE3D21F8FD3 for ; Thu, 1 Nov 2012 09:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.544 X-Spam-Level: X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CycuYLlFu8vw for ; Thu, 1 Nov 2012 09:22:23 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 683AE21F8FCE for ; Thu, 1 Nov 2012 09:22:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,693,1344207600"; d="scan'208";a="282981732" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 01 Nov 2012 16:22:22 +0000 Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qA1GML6w003738 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 16:22:21 GMT Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0309.002; Thu, 1 Nov 2012 16:22:01 +0000 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: Reactive routing protocols, what are the differences? Thread-Index: Ac24S9gO52XASJQwQb67c7wvLBVIbQ== Date: Thu, 1 Nov 2012 16:22:00 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:22:25 -0000 The obviously best people to answer this should be document authors, but an= yone else may have useful additions and comments. Ideally the different doc= ument authors could agree a list. (If they differ in that one has X and the= other doesn't, but one wants to say "we plan to add/remove X" then X shoul= d be listed as a difference with that caveat, in at least my ideal world.) If we set aside, for the moment (though these things matter): - The presentational quality of the documents, - Any issues of 5444 compliance and other formatting issues, - Issues of internal data organisation, - Minor details such as possible different timeout parameters etc. then what are the technical (and I stress that word) differences between DY= MO and LOADng? (I'm withholding the term AODVv2 for reasons I may come back= to.) Note that it's a lot more useful to have direct differences than difference= s of each from AODV (especially when both have the same difference). And it= would be useful to have the objective differences separated from the "and = now why this is better" discussion - though that would be a next step. I'm not saying I don't see any of the differences. But I certainly haven't = worked out the complete list. In trying to form my view of how things shoul= d go forward (a view that is coming together, and when it does, I'll argue = for it) and I hope for other people as well, it would be good to know what = the differences are. Regardless of views for or against each, we should be = able to objectively list the significant differences - if we can't then som= ething is wrong. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** 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 pal@cs.stanford.edu Thu Nov 1 09:23:27 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1E621F8822 for ; Thu, 1 Nov 2012 09:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1g5dVv4RIxY for ; Thu, 1 Nov 2012 09:23:26 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id F16A921F87C1 for ; Thu, 1 Nov 2012 09:23:07 -0700 (PDT) Received: from dn0a210082.sunet ([10.33.0.130]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TTxXo-0005KI-R1; Thu, 01 Nov 2012 09:23:02 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: <3D320804-EE40-42FB-BF08-3F662B3F9542@axelcdv.com> Date: Thu, 1 Nov 2012 09:23:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220465DF@xmb-rcd-x02.cisco.com> <3D320804-EE40-42FB-BF08-3F662B3F9542@axelcdv.com> To: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= X-Mailer: Apple Mail (2.1283) X-Scan-Signature: 546af22962c57f92a5360e3333f3125c Cc: " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:23:27 -0000 Simulations of wireless networks using unit disc, time invariant models = have zero relevance to reality. Any results from such simulations MUST = NOT be used as evidence of the performance of protocols. :) Phil On Oct 31, 2012, at 3:26 PM, Axel Colin de Verdi=E8re wrote: > Hi JP, >=20 > As usual, there isn't just one situation, be it in MANETs in general = or in LLNs in particular. The simulations shown did make some = assumptions on the traffic, and some other assumptions might show = different results, but that's true of any protocol. Which is why I would = also be interested in your results concerning LOADng in LLNs. >=20 > Best, >=20 > Axel >=20 > Le 31 oct. 2012 =E0 15:12, JP Vasseur (jvasseur) = a =E9crit : >=20 >> Hi Bo, >>=20 >> We need to be very careful there =85 these documents provide results = that CANNOT be generalized to say the least. >> Hypothesis made on traffic flows are such that you get the results = that you would like to see =85 >>=20 >> Thanks >>=20 >> JP. >>=20 >> On Oct 31, 2012, at 7:29 PM, Bo Berry wrote: >>=20 >>>=20 >>> For background and perspective, ran across these two docs on the = origin=20 >>> and performance of Loadng. The WG may find helpful. >>>=20 >>> -Bo >>>=20 >>>=20 >>> The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next = Generation (LOADng)=09 >>> By T. Clausen. A. Colin de Verdiere.=20 >>> Published in INRIA Research Report 7692 on 2011-07-25. >>> = http://hipercom.thomasclausen.net/resteam/data/publications/414efa79c4c772= e5af46f426e77ca581.pdf >>>=20 >>>=20 >>> A Comparative Performance Study of the Routing Protocols LOAD and = RPL with Bi-Directional Traffic in Low-power and Lossy Networks (LLN)=09 >>> By T. Clausen, U. Herberg.=20 >>> Published in INRIA Research Report 7637 on 2011-06-01. >>> = http://hipercom.thomasclausen.net/resteam/data/publications/49eaae3228cf68= 6a462108aef8332ceb.pdf >>>=20 >>>=20 >>>=20 >>>=20 >>> On Oct 31, 2012, at 1:48 PM, Jon Black wrote: >>>=20 >>>> Certainly smart meters are one of the types of networks that are = MANETs. Just because houses do not move it does not mean that the = connectivity between those meters isn't changing. A smart meter network = is most certainly a MANET. [One could argue that it is not an LLN since = at least from the electrical power there is no lack of power.] >>>>=20 >>>> Totally agree that one size does not fit all. >>>>=20 >>>> Jon >>>>=20 >>>> On October 31, 2012 John.Dowdell wrote: >>>>=20 >>>> While I am very pleased for you and your co-authors that the LOADng = work has been so fruitful, I am not really sure that smart meters are = really the kind of MANET devices that the working group was intended to = address. I have been party to the conversations for only a year or two, = so I am very happy to be corrected by those with longer histories, but = MANET to me means dynamically moving nodes, with links being established = and broken often and without prior warning. Examples may be = communications networks built out of nodes contained in cars, trucks and = aircraft of all sizes. I appreciate a comment on the list a while back = that the RF environment for smart metering is actually more difficult = than one would think, but I would suggest to the chairs that unless = LOADng has applications in this dynamically mobile environment (and I = have to admit I have not read the spec in enough detail to determine if = this is the case), then we come to the conclusion that the DYMO/AODVv2 = path sh >>> ould be followed unless we collectively feel that such a direction = is not worth pursuing (and note I am definitely not proposing that = view). >>>>=20 >>>> In the two years or so that I have been working with MANETs, the = only conclusion I have come to is that very many use cases exist, and = that one size does not fit all. >>>>=20 >>>> Regards >>>>=20 >>>> John >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Thu Nov 1 09:27:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9885F21F8FE7 for ; Thu, 1 Nov 2012 09:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cebMqhulZcBg for ; Thu, 1 Nov 2012 09:27:28 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 0F60F21F8FAC for ; Thu, 1 Nov 2012 09:27:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,693,1344207600"; d="scan'208";a="282983563" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 01 Nov 2012 16:27:27 +0000 Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qA1GRQRF027882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 16:27:26 GMT Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0309.002; Thu, 1 Nov 2012 16:27:26 +0000 From: "Dearlove, Christopher (UK)" To: Philip Levis , =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNt4/7KZyE8G8hv0Kl9ZhEgIu1eJfTvFeAgAA+IACAAAPVgIABLOgAgAAAZKA= Date: Thu, 1 Nov 2012 16:27:26 +0000 Message-ID: References: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220465DF@xmb-rcd-x02.cisco.com> <3D320804-EE40-42FB-BF08-3F662B3F9542@axelcdv.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:27:30 -0000 They can be good evidence of the failure of protocols ;) But what is clear to me is that one important issue (and another of my post= s is attempting to both be more precise, as well as going elsewhere) is the= handling of unidirectional links. So any good evidence needs to consider t= hose. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of P= hilip Levis Sent: 01 November 2012 16:23 To: Axel Colin de Verdi=E8re Cc: List; Bo Berry (boberry) Subject: Re: [manet] Reactive Protocol Situation ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Simulations of wireless networks using unit disc, time invariant models hav= e zero relevance to reality. Any results from such simulations MUST NOT be = used as evidence of the performance of protocols. :) Phil On Oct 31, 2012, at 3:26 PM, Axel Colin de Verdi=E8re wrote: > Hi JP, >=20 > As usual, there isn't just one situation, be it in MANETs in general or i= n LLNs in particular. The simulations shown did make some assumptions on th= e traffic, and some other assumptions might show different results, but tha= t's true of any protocol. Which is why I would also be interested in your r= esults concerning LOADng in LLNs. >=20 > Best, >=20 > Axel >=20 > Le 31 oct. 2012 =E0 15:12, JP Vasseur (jvasseur) a = =E9crit : >=20 >> Hi Bo, >>=20 >> We need to be very careful there . these documents provide results that = CANNOT be generalized to say the least. >> Hypothesis made on traffic flows are such that you get the results that = you would like to see . >>=20 >> Thanks >>=20 >> JP. >>=20 >> On Oct 31, 2012, at 7:29 PM, Bo Berry wrote: >>=20 >>>=20 >>> For background and perspective, ran across these two docs on the origin= =20 >>> and performance of Loadng. The WG may find helpful. >>>=20 >>> -Bo >>>=20 >>>=20 >>> The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Genera= tion (LOADng)=09 >>> By T. Clausen. A. Colin de Verdiere.=20 >>> Published in INRIA Research Report 7692 on 2011-07-25. >>> http://hipercom.thomasclausen.net/resteam/data/publications/414efa79c4c= 772e5af46f426e77ca581.pdf >>>=20 >>>=20 >>> A Comparative Performance Study of the Routing Protocols LOAD and RPL w= ith Bi-Directional Traffic in Low-power and Lossy Networks (LLN)=09 >>> By T. Clausen, U. Herberg.=20 >>> Published in INRIA Research Report 7637 on 2011-06-01. >>> http://hipercom.thomasclausen.net/resteam/data/publications/49eaae3228c= f686a462108aef8332ceb.pdf >>>=20 >>>=20 >>>=20 >>>=20 >>> On Oct 31, 2012, at 1:48 PM, Jon Black wrote: >>>=20 >>>> Certainly smart meters are one of the types of networks that are MANET= s. Just because houses do not move it does not mean that the connectivity = between those meters isn't changing. A smart meter network is most certain= ly a MANET. [One could argue that it is not an LLN since at least from the= electrical power there is no lack of power.] >>>>=20 >>>> Totally agree that one size does not fit all. >>>>=20 >>>> Jon >>>>=20 >>>> On October 31, 2012 John.Dowdell wrote: >>>>=20 >>>> While I am very pleased for you and your co-authors that the LOADng wo= rk has been so fruitful, I am not really sure that smart meters are really = the kind of MANET devices that the working group was intended to address. I= have been party to the conversations for only a year or two, so I am very = happy to be corrected by those with longer histories, but MANET to me means= dynamically moving nodes, with links being established and broken often an= d without prior warning. Examples may be communications networks built out = of nodes contained in cars, trucks and aircraft of all sizes. I appreciate = a comment on the list a while back that the RF environment for smart meteri= ng is actually more difficult than one would think, but I would suggest to = the chairs that unless LOADng has applications in this dynamically mobile e= nvironment (and I have to admit I have not read the spec in enough detail t= o determine if this is the case), then we come to the conclusion that the D= YMO/AODVv2 path sh >>> ould be followed unless we collectively feel that such a direction is n= ot worth pursuing (and note I am definitely not proposing that view). >>>>=20 >>>> In the two years or so that I have been working with MANETs, the only = conclusion I have come to is that very many use cases exist, and that one s= ize does not fit all. >>>>=20 >>>> Regards >>>>=20 >>>> John >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org 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 hrogge@googlemail.com Thu Nov 1 09:31:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563E421F8FFC for ; Thu, 1 Nov 2012 09:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jtTSaTewG20 for ; Thu, 1 Nov 2012 09:31:37 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E4E2721F8FFB for ; Thu, 1 Nov 2012 09:31:36 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so1852676pbb.31 for ; Thu, 01 Nov 2012 09:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=66mU5Ur2+SmxmvGoB8mc8THzWmT7Mbeedaqpcye8AQs=; b=zLSS7v9tYjV+05ObvSs7FwWHI1VNONqmspG5VmEt1a7C7qySYk3ORmFnfkgqWMwMjy HyjukqPZ/pYtdJ6BcFw219XGeYxioeJUmlmtC6mBT0OygWX0llUnBnJ/4G+G7yCzyBRT xtCwDhljtk9KvftQ7AR1NuEDadiS1MBl5d77yjqWJVSIMMlDZTRaQc8G9mLzFkpuTe55 b6IymyptvRR3tyK4ke7GWOQprV5l3x6ihoU0G+Kusx8sjFtOABiTe4XpZQmYA1iY2Z5F j9tVLtGc97E1f69tJz+i8K7XvMVBWzY0UJHDM1ibUHs1EJTkaArcMFAvzZh67w0YyRWr euBQ== Received: by 10.68.209.230 with SMTP id mp6mr122943904pbc.8.1351787496714; Thu, 01 Nov 2012 09:31:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Thu, 1 Nov 2012 09:31:16 -0700 (PDT) In-Reply-To: <1351784420.69738.YahooMailNeo@web160603.mail.bf1.yahoo.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <2CF862E3-F417-4442-B597-6DCBA035D4B9@cisco.com> <1351784420.69738.YahooMailNeo@web160603.mail.bf1.yahoo.com> From: Henning Rogge Date: Thu, 1 Nov 2012 17:31:16 +0100 Message-ID: To: Jon Black Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "thierry.lys@erdfdistribution.fr" , Bo Berry Subject: Re: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:31:37 -0000 On Thu, Nov 1, 2012 at 4:40 PM, Jon Black wrote: > Mobility in a wireless sense means a changing connectivity. A wireless > device does not need to physically move to appear mobile - the connectivity > path changes. Especially if you share the frequency band with other "out of network" users... like the 2.4 and 5 GHz ISM bands. These links fluctuate a lot because of change in the noise level... without moving at all. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From d.sturek@att.net Thu Nov 1 09:40:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67A821F902C for ; Thu, 1 Nov 2012 09:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.867 X-Spam-Level: X-Spam-Status: No, score=-0.867 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 916XsDoVi1Wu for ; Thu, 1 Nov 2012 09:40:17 -0700 (PDT) Received: from nm17.access.bullet.mail.mud.yahoo.com (nm17.access.bullet.mail.mud.yahoo.com [66.94.237.218]) by ietfa.amsl.com (Postfix) with ESMTP id A41C121F902B for ; Thu, 1 Nov 2012 09:40:17 -0700 (PDT) Received: from [66.94.237.194] by nm17.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Nov 2012 16:40:17 -0000 Received: from [98.139.221.54] by tm5.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Nov 2012 16:40:16 -0000 Received: from [127.0.0.1] by smtp107.sbc.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 16:40:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1351788016; bh=JnxTt3ctlisVBHiXmM1SRbBs+N9PKO+MHBH4jGBY9h4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=gq2mkRiFx9/F4OyrxhAGBzzEGipsesW5lF6O3gQaIf0YDi5OuY9kJNkIa3l/CO6Rp0XDyJWZ6ZGMpbiHDa8cOUw+CdSvwlHpq7uK7EjpjTnz5ttkrPFOaMJies+rzCZd+wNQXyt8/T1t49cXMD14LAiIN3/8VYMNwk2284frlTI= X-Yahoo-Newman-Id: 842392.80455.bm@smtp107.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: JaHX2nwVM1ldrHvDrY5RvhAB3BjaC_SBxEtfKgeM0oecLJi YZkXJkWsUb.Yn6YJp0SejvrIDMZVuGYhBeaOTqeiJsIZ2T5BoRJQrAB.vORA QnFznPRf5MYFZXCxfYRngUrugFVT9cOAynJNQJfPoK36MtA6UXrASXRAPKXY SQG0euZXPw6IpnvCv2Vxmq1y9TDQS4Njk.n5ooGAe74HyFERNldXeZsnVqun OfWJULzwcuj5kbJvRoH4Oi2VqifABBAyIB19ytR.cjNN1axhtj1xytFS7l9p zZJcX9DpQUP.91lmddtPzr6RXXDaOWX9MpjrmiQpFVQaTU_e1WjSMfI5ldlQ EUKE4wEU.9rJALXBrQQOwLIBI29dRo5Wm3KnkdhipRpIvaHja.c7YEuNKQie Bn22K8wSaOHZcDS78W6cHfhCrpDOfglKmN_YnnVO9RgBtDvgB_HNCYTOFaph a.u96j4djzwtvjwykhA-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.135] (d.sturek@66.27.60.174 with login) by smtp107.sbc.mail.bf1.yahoo.com with SMTP; 01 Nov 2012 09:40:16 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 01 Nov 2012 09:40:11 -0700 From: Don Sturek To: Abdussalam Baryun , Jon Black Message-ID: Thread-Topic: [manet] Reactive Protocol Situation In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3434607615_26291" Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:40:18 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3434607615_26291 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Adbussalam, It is hard to consider a draft stalled 2+ years as the only way forward in MANET as a reactive protocol. Don From: Abdussalam Baryun Date: Thursday, November 1, 2012 8:53 AM To: Jon Black Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] Reactive Protocol Situation Yes LOADng is a reactive protocols, but not the MANET WG reactive protocol (DYMO is already authorised). The WG is the only authorised to make such decisions for its WG drafts, if WG decides to add any LOADng ideas it can, or to accept such merge it can as well, AB On Thu, Nov 1, 2012 at 3:37 PM, Jon Black wrote: > Why would you think that LOADng is not reactive? If it is not a reactive > protocol, then what is it? > > As to merging the documents, this is what WGs do. If you have multiple > "competing" ideas you ask the authors to see if they can merge their concepts > and ideas. If they cannot or will not then the WG must decide based on facts > and not conjecture which is the most prudent path to take. > > Jon > > > > > > > > From: Abdussalam Baryun > To: Joseph Macker > Cc: manet@ietf.org; Stan Ratliff > Sent: Thursday, November 1, 2012 8:22 AM > > Subject: Re: [manet] Reactive Protocol Situation > > > > Dear Joseph Macker and Stan, > MANET WG Chairs > > I disagree that the WG arranged/guided to merge the documents, I never heard > that there was a consensus on such activity. DYMO is a reactive WG draft, but > LOADng is not. Why did you guide to merge documents, I recommend that you ment > to merge the team drafts co-authors to one WG draft (which is only DYMO so > far). The authority is for the WG to decide to merge individual drafts to its > WG draft. > > Therefore, my vote is for option 1 only. Thanking you for updating us with the > status. > > Regards > AB > > On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker wrote: >> Hello MANET working group (form Stan and Joe), >> >> As you are all probably aware, there has been WG activity lately on competing >> drafts for a MANET reactive protocol - DYMO (reviving the current working >> group document that was parked due to inactivity), and LOADng. Many months >> ago there was a somewhat authorship led movement towards a common document >> effort and given positive feedback at the time we the chairs thought this was >> the best approach given the authors potential to come together and gain the >> best of both efforts. Since that period, there has been some fairly strident >> and rancorous "at times" debate between the authors of the two documents. >> >> During IETF 84 in Vancouver, the co-chairs held a discussion with some of the >> co-authors of the two documents. Our guidance to the co-authors was to find a >> way to merge the two documents into one, as it was perceived that are not >> technically far apart and they both derive roughly from AODV concepts and >> LOADng had fairly active authorship and implementation efforts. We provided a >> co-editing proposal to the authors and gave them the timeframe of the Atlanta >> to come up with an answer back to us regarding this. As of this writing, >> those discussions of a potential commonn document and authorship merger have >> failed. >> >> Therefore, we find ourselves at a crossroads. The authors of the two >> documents are divided, and it is unlikely that progress on a merged document >> can be reached based upon recent author feedback. I have also polled the >> earlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the >> issue at the present time. We see only 3 possible paths forward: >> >> 1. Continue the work on the DYMO document, starting with whether there is >> consensus on its continued approach and also the desire to rename it to >> AODVv2. >> 2. Replace the existing DYMO document effort with the LOADng related document >> effort, defusing ealier references to LLNs as recommended in the last meeting >> minutes, and to focus more motivationally on general MANET problem spaces >> (the authors seem to have agreed to this issue if its a WG document). >> 3. Remove the working group charter for a reactive protocol, effectively >> killing both documents, at least from a working group (WG) standpoint. This >> would not be a reflection on the technology in either case, just an admission >> that we are not working together and reaching consensus. >> >> The co-chairs request and need your opinions on the options. We have been >> some silent collecting initial feedback and waiting for author feedback at >> this point. Stan and I are both on travel prior to Atlanta so our responses >> may be sparse and we will also likely be in a "receive mode" for a few days. >> So send your opinions. >> >> -Joe >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --B_3434607615_26291 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Adbussalam,
<= br>
It is hard to consider a draft stalled 2+ years as the only wa= y forward in MANET as a reactive protocol.

Don



Fr= om: Abdussalam Baryun <abdussalambaryun@gmail.com>
Date:= Thursday, November 1, 2012 8:53 AM
To: Jon Black <jblack.ie= tf@yahoo.com>
Cc: "manet@ietf.org" <manet@ietf.org>, Stan Ratliff <sratliff@cisco.com>
Subject: <= /span> Re: [manet] Reactive Protocol Situation

= Yes LOADng is a reactive protocols, but not the MANET WG reactive proto= col (DYMO is already authorised). The WG is the only authorised to make such= decisions for its WG drafts, if WG decides to add any LOADng ideas it can, = or to accept such merge it can as well,
AB
On Thu, Nov 1, 2012 at 3:37 PM, Jon Black <= ;jblack.ietf@yahoo.co= m> wrote:
Why would you think that LOADng = is not reactive?  If it is not a reactive protocol, then what is it?
As to merging the documents, this is what WGs do.  If you have mul= tiple "competing" ideas you ask the authors to see if they can merge their c= oncepts and ideas.  If they cannot or will not then the WG must decide = based on facts and not conjecture which is the most prudent path to take.
Jon


=
From:= Abdussalam Baryun <abdussalambaryun@gmail.com>
To: Joseph Macker <jpmacker@gmail.com>
Cc: = manet@ietf.org; Stan Ratliff <sratliff@cisco.com>
Sent: Thursday, November 1, 2012 8:22 AM

<= b>Subject: Re: [manet] Reactive Pr= otocol Situation

Dear Joseph Macker and Stan,
MANET WG Chairs
 
I disagree that the WG arranged/guided to merge the documen= ts, I never heard that there was a consensus on such activity. DYMO is a rea= ctive WG draft, but LOADng is not. Why did you guide to merge documents, I r= ecommend that you ment to merge the team drafts co-authors to one WG dr= aft (which is only DYMO so far). The authority is for the WG to decide to me= rge individual drafts to its WG draft.
 
Therefore,= my vote is for option 1 only. Thanking you for updating us with the status.=
 
Regards
AB

On Tue, O= ct 30, 2012 at 11:13 PM, Joseph Macker <jpmacker@gmail.com>= wrote:
Hello MANET working group (form Stan and Joe),

As you are al= l probably aware, there has been WG activity lately on competing drafts for = a MANET reactive protocol - DYMO (reviving the current working group documen= t that was parked due to inactivity), and LOADng. Many months ago there was = a somewhat authorship led movement towards a common document effort and give= n positive feedback at the time we the chairs thought this was the best appr= oach given the authors potential to come together and gain the best of both = efforts.  Since that period, there has been some fairly strident and ra= ncorous "at times" debate between the authors of the two documents.

D= uring IETF 84 in Vancouver, the co-chairs held a discussion with some of the= co-authors of the two documents. Our guidance to the co-authors was to find= a way to merge the two documents into one, as it was perceived that are not= technically far apart and they both derive roughly from AODV concepts and L= OADng had fairly active authorship and implementation efforts. We provided a= co-editing proposal to the authors and gave them the timeframe of the Atlan= ta to come up with an answer back to us regarding this.  As of this wri= ting, those discussions of a potential commonn document and authorship merge= r have failed.

Therefore, we find ourselves at a crossroads. The auth= ors of the two documents are divided, and it is unlikely that progress on a = merged document can be reached based upon recent author feedback. I have als= o polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat dis= engaged on the issue at the present time.  We see only 3 possible paths= forward:

1. Continue the work on the DYMO document, starting with wh= ether there is consensus on its continued approach and also the desire to re= name it to AODVv2.
2. Replace the existing DYMO document effort with the = LOADng related document effort, defusing ealier references to LLNs as recomm= ended in the last meeting minutes, and to focus more motivationally on gener= al MANET problem spaces (the authors seem to have agreed to this issue if it= s a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This wo= uld not be a reflection on the technology in either case, just an admission = that we are not working together and reaching consensus.

The co-chair= s request and need your opinions on the options.  We have been some sil= ent collecting initial feedback and waiting for author feedback at this poin= t.  Stan and I are both on travel prior to Atlanta so our responses may= be sparse and we will also likely be in a "receive mode" for a few days.&nb= sp; So send your opinions.

-Joe

______________________________= _________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listin= fo/manet



_______________________= ________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/= manet



_______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/= mailman/listinfo/manet --B_3434607615_26291-- From pal@cs.stanford.edu Thu Nov 1 09:45:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2CF21F905C for ; Thu, 1 Nov 2012 09:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VuVx4UW0MM8 for ; Thu, 1 Nov 2012 09:45:36 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9331F21F905B for ; Thu, 1 Nov 2012 09:45:36 -0700 (PDT) Received: from dn0a210082.sunet ([10.33.0.130]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TTxtf-0000ZG-K6; Thu, 01 Nov 2012 09:45:36 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: Date: Thu, 1 Nov 2012 09:45:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6C031880-6176-491E-B822-CCE6B8B586FC@cs.stanford.edu> References: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220465DF@xmb-rcd-x02.cisco.com> <3D320804-EE40-42FB-BF08-3F662B3F9542@axelcdv.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1283) X-Scan-Signature: 72f97ea9660f372cf635c7c250d627db Cc: " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:45:37 -0000 On Nov 1, 2012, at 9:27 AM, Dearlove, Christopher (UK) wrote: > They can be good evidence of the failure of protocols ;) >=20 > But what is clear to me is that one important issue (and another of my = posts is attempting to both be more precise, as well as going elsewhere) = is the handling of unidirectional links. So any good evidence needs to = consider those. Since communication in wireless is rarely binary, I think the more = common term is asymmetric links. I'm confused; I don't believe that unit = disc models capture asymmetric links. Is the implied statement that RPL = doesn't properly handle asymmetric links but LOADng does? I think this = came up in draft-clausen-lln-rpl-experiences and there was some = discussion on the ROLL list about it. The neighbor set in RPL is defined = in 8.2.1: "First, the candidate neighbor set is a subset of the nodes that can be = reached via link-local multicast." then in DIO processing (8.2.3.1) it reads: "As DIO messages are received from candidate neighbors, the neighbors = may be promoted to DODAG parents by following the rules of DODAG = discovery as described in Section 8.2." I want to be clear here; I haven't read deeply about LOADng, thought = about it much, or experimented with it at all. So I have zero to say = about LOADng's strengths and weaknesses.=20 But just because somebody publishes (and republishes) a draft saying = something doesn't mean it's true. There are, in my opinion, some very = valid points in draft-clausen-lln-rpl-experiences that relate to = fundamental design decisions in RPL. For example, I think that the = issues raised about the state requirements of floating DODAGs and RPL = message fragmentation are valid and reasonable and something we need to = look at.=20 However, there are others that are the result of naive mistakes anyone = can make when implementing any wireless routing protocol, such as link = asymmetry and protocol convergence. Unfortunately the draft doesn't = distinguish the two. Implementing a protocol poorly then saying it = doesn't work isn't particularly meaningful. As I said in Paris, I = thought the draft is valuable because it outlines many of the basic = mistakes one makes the first time you try implementing a wireless = routing protocol. Phil= From d.sturek@att.net Thu Nov 1 09:46:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9D621F9077 for ; Thu, 1 Nov 2012 09:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzCYZQLl7ib4 for ; Thu, 1 Nov 2012 09:46:25 -0700 (PDT) Received: from nm1-vm0.access.bullet.mail.mud.yahoo.com (nm1-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0989821F9073 for ; Thu, 1 Nov 2012 09:46:22 -0700 (PDT) Received: from [66.94.237.199] by nm1.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Nov 2012 16:46:22 -0000 Received: from [98.139.221.57] by tm10.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Nov 2012 16:46:22 -0000 Received: from [127.0.0.1] by smtp110.sbc.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 16:46:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1351788381; bh=tyPb3Uk0+8vILZyhBD6NeHNtuqFV1zUZrfLTEwCcpaY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=vhaBn2gKLIWynjvbN/+jGN0dWL84fBL4KP9di+PRGK2d8ou9UUHdPfXXdQWJIDshtBoy6q1UNZih9WV5JkRvP/D/+jGvQixlcej7NzncVQYK0c/MQGhSKr/J37desC8yuQNtXXQ7KYJnGKhjL4vtfZ7vm1vzx4+qTdn3Zke5Mgk= X-Yahoo-Newman-Id: 918149.58130.bm@smtp110.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: pxABrfMVM1lsjCJXTkoOc_WNKOw55igKiAbQxDv4_2vDt9L U.ASLi9b60i.Q4cPnZLkEz8xrViqFE6hmr6BZAFdMwEXoSlHTDEhWqr2EEZI xiUBE2m8GZXfoCip.8mLcJXA8LIP8vgCGCQivRFjv3TSs9PwHr8wfA2AEYVV 2EdnVtOsP9HPADMkZZwEsjWvv7Pv8l3gfNq9C0EKgHH6c.DvQcGgUZjXR36N t1XCOjYbsbiR6HWXvvfZ6tJDcx7.a5WWdrX3qGbHGxdoDMMwpEPUm4ntvhlJ skLfCx8V9JhLGFPTSjcHnkEeo9M0C7o2y_InvNlugSW4AEYfItUL0mq2cwB3 97dBPlO9J3HCM_rgS2v0W9hlrcKn04nJSKOslizOGxPcQExo9x6qVaoKj81t IIaDfpEXYi.qXtYydptATlwEbC1L.RHRpFWAk5vtSLT_ShKLauFt7Ve3ZMx0 RosClULxY7jA7ytNf.5GDNQkEtFyaxRHyaMJfzkkxtnOqb6AoUwREccuBpqI _E_J97S2R4y3yCFnve1mTJ6qnBw-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.135] (d.sturek@66.27.60.174 with login) by smtp110.sbc.mail.bf1.yahoo.com with SMTP; 01 Nov 2012 09:46:21 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 01 Nov 2012 09:46:15 -0700 From: Don Sturek To: Jon Black , Bo Berry , "Dearlove, Christopher (UK)" Message-ID: Thread-Topic: [manet] (no subject) In-Reply-To: <1351784420.69738.YahooMailNeo@web160603.mail.bf1.yahoo.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3434607980_59398" Cc: "manet@ietf.org" , "thierry.lys@erdfdistribution.fr" Subject: Re: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:46:30 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3434607980_59398 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Jon, There is another use case where the concept of mobility (in the sense of changing RF characteristics) comes into play with eMeters: Multi-dwelling units. In many juristictions, these e-Meters are in the basement while the residence is well out of direct range. There are a variet of techniques t= o associate then route data from a specific e-Meter to the residence but all that I am aware of utilize protocols simlar to what we are discussing. Don From: Jon Black Reply-To: Jon Black Date: Thursday, November 1, 2012 8:40 AM To: Bo Berry , "Dearlove, Christopher (UK)" Cc: "thierry.lys@erdfdistribution.fr" , "manet@ietf.org" Subject: Re: [manet] (no subject) Mobility in a wireless sense means a changing connectivity. A wireless device does not need to physically move to appear mobile - the connectivity path changes. Now if you live in a mobile home maybe your meter may also physically move. Maybe your mobile home doesn't have wheels. Jon =20 =20 =20 =20 From: Bo Berry To: "Dearlove, Christopher (UK)" Cc: JP Vasseur (jvasseur) ; Jon Black ; "manet@ietf.org" ; "thierry.lys@erdfdistribution.fr" Sent: Thursday, November 1, 2012 4:22 AM Subject: Re: [manet] (no subject) =20 =20 And to be fair, I've not seen results on Loadng wrt to mobility. The smart meter attached to my house has not moved sense it was installed. On Nov 1, 2012, at 6:10 AM, Dearlove, Christopher (UK) wrote: > If I were in charge of requirements, that requirement would be now. Attem= pting to sway a decision on the basis of "I have results" but not offering those results until the decision is made is not helpful. And the most important t= hing is are there any comparisons between the two (or with base AODV)? Without t= hose, the issue is how do the two differ technically in a manner that matters? > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= JP Vasseur (jvasseur) > Sent: 31 October 2012 22:09 > To: Jon Black > Cc: thierry.lys@erdfdistribution.fr; manet@ietf.org > Subject: Re: [manet] (no subject) > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an ext= ernal partner or the internet. > Keep this in mind if you answer this message. > Please see this process on how to deal with suspicious emails. >=20 > =20 > On Oct 31, 2012, at 6:57 PM, Jon Black wrote: >=20 >=20 > On October 31, 2012 Thierry.Lys wrote: > =20 > I speak in the name of EDF group. >=20 > We started first to use LOAD as a routing algorithm and deployed 2000 PLC-meters for smart grid purposes in 2011. Taking advantage of this field = test, we have been actively participating to the working group to adopt enhanceme= nts in the LOADng specification. > We are now extremely pleased with what LOADng is capable of and are confi= dent that future deployements will be equipped with it. > =20 > This would seem to indicate that LOADng does work and in a rather large deployment. > =20 > JP> No this means that LoadNG works in *a* network. But the major technic= al difference here is that reactive routing is highly impacted > by the user traffic =8A If you poll a meter every 24 hours, it may work perfectly well. Now if you start having more frequent traffic flows > you can either cache paths (ending up with more frequent broken paths considering how flappy these networks are, thus leading to more > floods =8A very undesirable =8A especially when you have hundreds of meters sharing a few Kbits/s) or you use short cache timers and you > keep flooding :-( If you take actual traces of these networks (both using 15.4g and P1901.2) and you start adjusting the user traffic rate you > immediately see the issues in terms of scalability. Yes you can try to mitigate the undesirable flooding effect to some extends but showing > the limits in terms of scalability is easy to show. Note that I MOT again= st reactive routing by any means, this is IMO just not applicable to > LLNs unless the traffic flows are deterministic and very well knows =8A Les= sons from the past show us how difficult it is to predict user > applications. We all started with meter reading to continue with that exa= mple and now many utilities wants to use these smart metering > networks for a number of applications which different SLA, =8A > =20 > Hope this helps. Once again, when/if required I would be happy to share m= any results. > =20 >=20 >=20 >=20 > "We believe in rough consensus and running code" >=20 > rough consensus : Don't you think we have a rough consensus on LOADng com= pared to DYMO ? 10 authors and major companies are supporters of LOADng. >=20 > running code : interoperability has been checked with 4 sources and other implementations are in progress. >=20 > Obviously from the list we don't have rough consensus. We have two alternatives each with proponents. The WG should weigh the technical benef= its (design, implementation/running code, maturity) of each and the group shou= ld choose a path forward. >=20 > In my opinion option 3 is not an option - this is the working group shirk= ing its responsibility. > =20 > This is an option =8A since listed by the chairs. I agree that we should av= oid it, especially when I think we have a very reasonable solution > (option1). > =20 > JP. >=20 >=20 >=20 > Jon > =20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > =20 >=20 > ******************************************************************** > 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. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet =20 =20 =20 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --B_3434607980_59398 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Jon,

There is another use case where the concept of mobility (in the sense= of changing RF characteristics) comes into play with eMeters:   Multi-= dwelling units.

In many juristictions, these e-Mete= rs are in the basement while the residence is well out of direct range. &nbs= p; There are a variet of techniques to associate then route data from a spec= ific e-Meter to the residence but all that I am aware of utilize protocols s= imlar to what we are discussing.

Don

=


From: Jon Black <jblack.ietf@yahoo.com= >
Reply-To: Jon Black <<= a href=3D"mailto:jblack.ietf@yahoo.com">jblack.ietf@yahoo.com>
Date: Thursday, November 1, 2012 8:40 AMTo: Bo Berry <boberry@cisco.com>, "Dearlove, Christopher (UK)" <= ;chris.dearlove@baesystems.co= m>
Cc: "thierry.lys@erdfdistribution.fr" <thierry.lys@erdfdistribution.fr<= /a>>, "manet@ietf.org" <manet@ietf.org>
Subject: Re: [manet] (no subject)

Mobility in a wireless sense means= a changing connectivity.  A wireless device does not need to physicall= y move to appear mobile - the connectivity path changes.

Now if you l= ive in a mobile home maybe your meter may also physically move.  Maybe = your mobile home doesn't have wheels.

Jon


From: B= o Berry <boberry@cisco.com>
= To: "Dearlove, Christopher (= UK)" <chris.dearlove@baesy= stems.com>
Cc: JP Vasseur (jvasseur) <jvasseur@cisco.com>; Jon Black <jblack.ietf@yahoo.com>; "manet@ietf.org" <manet@ietf.org>; "thierry.lys@erdfdis= tribution.fr" <thier= ry.lys@erdfdistribution.fr>
= Sent: Thursday, November 1, 2012 4:22 AM
Subject: Re: [manet] (no subject)
And to be fair, I've not seen results on Loadng wrt to mobility.  The = smart meter attached to my house has not moved sense it was installed. =


On Nov 1, 2012, at 6:10 AM, Dearlove, Christopher (UK) wrote:
> If I were in charge of requirements, that requirement would be no= w. Attempting to sway a decision on the basis of "I have results" but not of= fering those results until the decision is made is not helpful. And the most= important thing is are there any comparisons between the two (or with base = AODV)? Without those, the issue is how do the two differ technically in a ma= nner that matters?
> 
> --
> Christopher Dearlove> Senior Principal Engineer, Communications Group
> Communications= , Networks and Image Analysis Capability
> BAE Systems Advanced Techno= logy Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8H= N, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>
>= ; BAE Systems (Operations) Limited
> Registered Office: Warwick House,= PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK> Registered in England & Wales No: 1996687
> 
> = From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org]= On Behalf Of JP Vasseur (jvasseur)
> Sent: 31 October 2012 22:09
&= gt; To: Jon Black
> Cc: thierry.lys@erdfdistribu= tion.fr; manet@ietf.org
> Subject: Re: [manet] (no subject)
>  =
> 
> *** WARNING ***
> This message originates from= outside our organisation, either from an external partner or the internet.<= br>> Keep this in mind if you answer this message.
> Please see thi= s process on how to deal with suspicious emails.
>
> 
= > On Oct 31, 2012, at 6:57 PM, Jon Black wrote:
>
>
>= On October 31, 2012 Thierry.Lys wrote:
> 
> I speak in th= e name of EDF group.
>
> We started first to use LOAD as a rou= ting algorithm and deployed 2000 PLC-meters for smart grid purposes in 2011.= Taking advantage of this field test, we have been actively participating to= the working group to adopt enhancements in the LOADng specification.
&g= t; We are now extremely pleased with what LOADng is capable of and are confi= dent that future deployements will be equipped with it.
> 
> This would = seem to indicate that LOADng does work and in a rather large deployment.
= > 
> JP> No this means that LoadNG works in *a* network. B= ut the major technical difference here is that reactive routing is highly im= pacted
> by the user traffic … If you poll a meter every 24 hour= s, it may work perfectly well. Now if you start having more frequent traffic= flows
> you can either cache paths (ending up with more frequent brok= en paths considering how flappy these networks are, thus leading to more
= > floods … very undesirable … especially when you have hundre= ds of meters sharing a few Kbits/s) or you use short cache timers and you> keep flooding :-( If you take actual traces of these networks (both us= ing 15.4g and P1901.2) and you start adjusting the user traffic rate you
= > immediately see the issues in terms of scalability. Yes you can try to mitigate the undesirable flooding effect to some extends but showin= g
> the limits in terms of scalability is easy to show. Note that I M= OT against reactive routing by any means, this is IMO just not applicable to=
> LLNs unless the traffic flows are deterministic and very well knows= … Lessons from the past show us how difficult it is to predict user <= br>> applications. We all started with meter reading to continue with tha= t example and now many utilities wants to use these smart metering
> = networks for a number of applications which different SLA, …
>&= nbsp;
> Hope this helps. Once again, when/if required I would be happ= y to share many results.
> 
>
>
>
> "= We believe in rough consensus and running code"
>
> rough cons= ensus : Don't you think we have a rough consensus on LOADng compared to DYMO= ? 10 authors and major companies are supporters of LOADng.
>
> running code : interoperability has been checked with 4 = sources and other implementations are in progress.
>
> Obviousl= y from the list we don't have rough consensus.  We have two alternative= s each with proponents.  The WG should weigh the technical benefits (de= sign, implementation/running code, maturity)  of each and the group sho= uld choose a path forward.
>
> In my opinion option 3 is not an= option - this is the working group shirking its responsibility.
>&nbs= p;
> This is an option … since listed by the chairs. I agree th= at we should avoid it, especially when I think we have a very reasonable sol= ution
> (option1).
> 
> JP.
>
>
>= ;
> Jon
> 
> ______________________________________= _________
> manet mailing list
> manet@ietf.org
> http= s://www.ietf.org/mailman/listinfo/manet
> 
>
> = ********************************************************************
>= This email and any attachments are confidential to the intended
> rec= ipient and may also be privileged. If you are not the intended
> recip= ient please delete it from your system and notify the sender.
> You sh= ould not copy it or use it for any purpose nor disclose or
> distribut= e its contents to any other person.
> ********************************= ************************************
>
> ______________________= _________________________
> manet mailing list
> manet@ietf.org
> = https:= //www.ietf.org/mailman/listinfo/manet



_________________________________________= ______ manet mailing list manet@ietf.org https://www.ietf.org/= mailman/listinfo/manet --B_3434607980_59398-- From d.sturek@att.net Thu Nov 1 09:55:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569DC21F8FCE for ; Thu, 1 Nov 2012 09:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcq806Hg5xJQ for ; Thu, 1 Nov 2012 09:55:08 -0700 (PDT) Received: from nm14.access.bullet.mail.sp2.yahoo.com (nm14.access.bullet.mail.sp2.yahoo.com [98.139.44.141]) by ietfa.amsl.com (Postfix) with ESMTP id 71ED421F9003 for ; Thu, 1 Nov 2012 09:55:08 -0700 (PDT) Received: from [98.139.44.100] by nm14.access.bullet.mail.sp2.yahoo.com with NNFMP; 01 Nov 2012 16:55:05 -0000 Received: from [98.138.84.212] by tm5.access.bullet.mail.sp2.yahoo.com with NNFMP; 01 Nov 2012 16:55:05 -0000 Received: from [127.0.0.1] by smtp101.sbc.mail.ne1.yahoo.com with NNFMP; 01 Nov 2012 16:55:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1351788905; bh=MJXeE2vGKSjGDKeELOJUFxZLM2O7JzNMJLfqQRxnoKk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=OerT+Bd9yq065foJvxJeAJG9kVIRFOH1NtmnmfWvEj8dxX1MQGleYEmh37QT2TGHoovZ5QD7whBC/Grumwey/aipFNe1H8JJIIAVQpwANH44bEUTN8XySOPJ3sE/uy9cEP25GPhl7W4cRYEan7xdt6qg7mHdkwXT+7Q/0clK/vA= X-Yahoo-Newman-Id: 609554.72880.bm@smtp101.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: a6iXgC0VM1lUULJ..fQVISgPyW1qzREpRg0CDFcl3xZcX.L .j5h0kyreUTMZboW13AZeVCL4Dg7ToXraSgZ4L20f0l8jH6rdbF7w._PN_jA v4VfohYs0s22Al_SEiji_q20qAIw3Y0Av0kYClU6nmkMQ.SQ9dG.5TP7MUyj qhwLng4OVgF9ElZY0c.WrFkcSPIsVqOLi3Dl4VYuB4wohLXs0uWP0o8Dloqm 20nyhgK7GFZl6h0_Fnh_K_NOV.oLtvgZucwEqxm6EY2TM3_zEbWdaA_n2TKh 9j6UR9lyj8l98uE7SIUHJAXjRZX2yWOlqOSYo5PPZfQfgCyTyYfL1nWcMraD boWJav_FR5B7lILj3IwEIl4o7guUSDF1mhaH.PxEkUg7RpATrEwF7Ck5cwSi HaQLtJm.oAkKOXojiKMnC8GML.MD9tixd0hahCS3tj_axwoMlxPrikjnV8c5 PHfnMkomab7m7Kwf2 X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.135] (d.sturek@66.27.60.174 with login) by smtp101.sbc.mail.ne1.yahoo.com with SMTP; 01 Nov 2012 09:55:04 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 01 Nov 2012 09:55:00 -0700 From: Don Sturek To: Philip Levis , "Dearlove, Christopher (UK)" Message-ID: Thread-Topic: [manet] Reactive Protocol Situation In-Reply-To: <6C031880-6176-491E-B822-CCE6B8B586FC@cs.stanford.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:55:10 -0000 Hi Phil, As you probably know, we (the ZigBee Alliance IP networking folks) are using ROLL RPL. To address the asymmetric link issue, we are using this draft: http://datatracker.ietf.org/doc/draft-kelsey-intarea-mesh-link-establishmen t/, and specifically the Link Quality exchange between neighbors. This, along with a policy of adjusting routing information for these links helps get around asymmetric link issues. The MLE draft was written to be routing protocol neutral and could be re-used for any commercial deployment and any mesh routing protocol. Don On 11/1/12 9:45 AM, "Philip Levis" wrote: >On Nov 1, 2012, at 9:27 AM, Dearlove, Christopher (UK) wrote: > >> They can be good evidence of the failure of protocols ;) >> >> But what is clear to me is that one important issue (and another of my >>posts is attempting to both be more precise, as well as going elsewhere) >>is the handling of unidirectional links. So any good evidence needs to >>consider those. > >Since communication in wireless is rarely binary, I think the more common >term is asymmetric links. I'm confused; I don't believe that unit disc >models capture asymmetric links. Is the implied statement that RPL >doesn't properly handle asymmetric links but LOADng does? I think this >came up in draft-clausen-lln-rpl-experiences and there was some >discussion on the ROLL list about it. The neighbor set in RPL is defined >in 8.2.1: > >"First, the candidate neighbor set is a subset of the nodes that can be >reached via link-local multicast." > >then in DIO processing (8.2.3.1) it reads: > >"As DIO messages are received from candidate neighbors, the neighbors may >be promoted to DODAG parents by following the rules of DODAG discovery as >described in Section 8.2." > >I want to be clear here; I haven't read deeply about LOADng, thought >about it much, or experimented with it at all. So I have zero to say >about LOADng's strengths and weaknesses. > >But just because somebody publishes (and republishes) a draft saying >something doesn't mean it's true. There are, in my opinion, some very >valid points in draft-clausen-lln-rpl-experiences that relate to >fundamental design decisions in RPL. For example, I think that the issues >raised about the state requirements of floating DODAGs and RPL message >fragmentation are valid and reasonable and something we need to look at. > >However, there are others that are the result of naive mistakes anyone >can make when implementing any wireless routing protocol, such as link >asymmetry and protocol convergence. Unfortunately the draft doesn't >distinguish the two. Implementing a protocol poorly then saying it >doesn't work isn't particularly meaningful. As I said in Paris, I thought >the draft is valuable because it outlines many of the basic mistakes one >makes the first time you try implementing a wireless routing protocol. > >Phil >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet From drdanhe@gmail.com Thu Nov 1 10:00:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058FD21F9079 for ; Thu, 1 Nov 2012 10:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45SbmFZ0OaGI for ; Thu, 1 Nov 2012 10:00:19 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 93E3E21F8FDD for ; Thu, 1 Nov 2012 10:00:18 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so452146wib.13 for ; Thu, 01 Nov 2012 10:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mEWRVQkeN1UcSySp3UfPCgdRD0ShmNd6dkGUw6C1h6s=; b=aGMTXpU/NJUYk6GkBPyZsCmgm1Sy8HZ+MNDaAm3/HuLJGnNeaYyGQJw71RFVuTON2c /ufo9FCIMuDoa3Wuy/holkRtiIn2TneOUAGMNPZcob0YTC2aVn/GM96hoMJg/rJ+B5IC GubjU8mYUFZU2DUqR7/xzTpyGvGbV2Udqkj5Xt3VTheFNisSJKiltKPdQmBxMnP1w/Sa Svlh6PrzeeJNFz5zKqE/cFR00PVwKyK6764u5NR0q8kNRYSJKXNSlG4JtYKMXgqD0uh9 pi/rYrKwGr920kE3HwUlWSasRm7q/za0oqLRVpU61HtN2muqe+CQWXWwuXGuKJh3FiSb 765Q== MIME-Version: 1.0 Received: by 10.216.204.101 with SMTP id g79mr19908612weo.65.1351789217740; Thu, 01 Nov 2012 10:00:17 -0700 (PDT) Received: by 10.194.59.71 with HTTP; Thu, 1 Nov 2012 10:00:17 -0700 (PDT) In-Reply-To: References: <1351784251.48543.YahooMailNeo@web160605.mail.bf1.yahoo.com> Date: Thu, 1 Nov 2012 17:00:17 +0000 Message-ID: From: Daniel He To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=0016e6d77da122790104cd71f444 Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 17:00:20 -0000 --0016e6d77da122790104cd71f444 Content-Type: text/plain; charset=ISO-8859-1 I vote the option 2 that may be more realistic choice for us. DYMO has been on the WG for long time but it is required a significant work to be a standard. and some work has been done by LOADng that I don't see it is not a reactive protocol. We should not waste the efforts of LOADng authors made to MANET WG. Option 2 therefore is the best and realistic choice for both drafts. Cheers, Dan On 1 November 2012 15:53, Abdussalam Baryun wrote: > Yes LOADng is a reactive protocols, but not the MANET WG reactive protocol > (DYMO is already authorised). The WG is the only authorised to make such > decisions for its WG drafts, if WG decides to add any LOADng ideas it can, > or to accept such merge it can as well, > AB > On Thu, Nov 1, 2012 at 3:37 PM, Jon Black wrote: > >> Why would you think that LOADng is not reactive? If it is not a reactive >> protocol, then what is it? >> >> As to merging the documents, this is what WGs do. If you have multiple >> "competing" ideas you ask the authors to see if they can merge their >> concepts and ideas. If they cannot or will not then the WG must decide >> based on facts and not conjecture which is the most prudent path to take. >> >> Jon >> >> >> ------------------------------ >> *From:* Abdussalam Baryun >> *To:* Joseph Macker >> *Cc:* manet@ietf.org; Stan Ratliff >> *Sent:* Thursday, November 1, 2012 8:22 AM >> >> *Subject:* Re: [manet] Reactive Protocol Situation >> >> Dear Joseph Macker and Stan, >> MANET WG Chairs >> >> I disagree that the WG arranged/guided to merge the documents, I never >> heard that there was a consensus on such activity. DYMO is a reactive WG >> draft, but LOADng is not. Why did you guide to merge documents, I recommend >> that you ment to merge the team drafts co-authors to one WG draft (which is >> only DYMO so far). The authority is for the WG to decide to merge >> individual drafts to its WG draft. >> >> Therefore, my vote is for option 1 only. Thanking you for updating us >> with the status. >> >> Regards >> AB >> >> On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker wrote: >> >> Hello MANET working group (form Stan and Joe), >> >> As you are all probably aware, there has been WG activity lately on >> competing drafts for a MANET reactive protocol - DYMO (reviving the current >> working group document that was parked due to inactivity), and LOADng. Many >> months ago there was a somewhat authorship led movement towards a common >> document effort and given positive feedback at the time we the chairs >> thought this was the best approach given the authors potential to come >> together and gain the best of both efforts. Since that period, there has >> been some fairly strident and rancorous "at times" debate between the >> authors of the two documents. >> >> During IETF 84 in Vancouver, the co-chairs held a discussion with some of >> the co-authors of the two documents. Our guidance to the co-authors was to >> find a way to merge the two documents into one, as it was perceived that >> are not technically far apart and they both derive roughly from AODV >> concepts and LOADng had fairly active authorship and implementation >> efforts. We provided a co-editing proposal to the authors and gave them the >> timeframe of the Atlanta to come up with an answer back to us regarding >> this. As of this writing, those discussions of a potential commonn >> document and authorship merger have failed. >> >> Therefore, we find ourselves at a crossroads. The authors of the two >> documents are divided, and it is unlikely that progress on a merged >> document can be reached based upon recent author feedback. I have also >> polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat >> disengaged on the issue at the present time. We see only 3 possible paths >> forward: >> >> 1. Continue the work on the DYMO document, starting with whether there is >> consensus on its continued approach and also the desire to rename it to >> AODVv2. >> 2. Replace the existing DYMO document effort with the LOADng related >> document effort, defusing ealier references to LLNs as recommended in the >> last meeting minutes, and to focus more motivationally on general MANET >> problem spaces (the authors seem to have agreed to this issue if its a WG >> document). >> 3. Remove the working group charter for a reactive protocol, effectively >> killing both documents, at least from a working group (WG) standpoint. This >> would not be a reflection on the technology in either case, just an >> admission that we are not working together and reaching consensus. >> >> The co-chairs request and need your opinions on the options. We have >> been some silent collecting initial feedback and waiting for author >> feedback at this point. Stan and I are both on travel prior to Atlanta so >> our responses may be sparse and we will also likely be in a "receive mode" >> for a few days. So send your opinions. >> >> -Joe >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > -- Dan He --------------------- Tel: +44-788-686-3428 --0016e6d77da122790104cd71f444 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I vote the option 2 that may be more realistic choice for us. DYMO has been= on the WG
for long time but it is required a significant work to be a s= tandard. and some work has been done by LOADng that I don't see it is n= ot a reactive protocol. We should not waste
the efforts of LOADng authors made to MANET WG. Option 2 therefore is the b= est and realistic choice for both drafts.

Cheers,

Dan

=
On 1 November 2012 15:53, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
Yes LOADng is a reactive protocols, but= not the MANET=A0WG reactive protocol (DYMO is already authorised). The WG = is the only authorised to make such decisions for its WG drafts, if WG deci= des to add any LOADng ideas it can, or to accept such merge it can as well,=
AB
On Thu, Nov 1, 2012 at 3:37 PM, Jon Black <jblack.iet= f@yahoo.com> wrote:
Why would you think that LOADng is not reactive?=A0 If it is not a= reactive protocol, then what is it?

As to merging the documents, th= is is what WGs do.=A0 If you have multiple "competing" ideas you = ask the authors to see if they can merge their concepts and ideas.=A0 If th= ey cannot or will not then the WG must decide based on facts and not conjec= ture which is the most prudent path to take.

Jon


From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: Joseph Macker <jpmacker@gmail.com>
Cc: manet@ietf.org; Stan Ratliff <sratliff@cisco.com> Sent: Thursday, November = 1, 2012 8:22 AM

Subject: Re: [manet] Re= active Protocol Situation

Dear Joseph Macker and Stan,
MANET WG Chairs
= =A0
I disagree that the=A0WG=A0arranged/guided to merge the docum= ents, I never heard that there was a consensus on such activity. DYMO is a = reactive WG draft, but LOADng is not. Why did you guide to merge documents,= I recommend that you ment to merge the team drafts co-authors to one=A0WG = draft (which is only DYMO so far). The authority is for the WG to decide to= merge individual drafts to its WG draft.
=A0
Therefore, my vote is for option 1 only. Thanking you fo= r updating us with the status.
=A0
Regards
AB=

On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker <jpmacker@gmail.com> wrote:
Hello= MANET working group (form Stan and Joe),

As you are all probably aw= are, there has been WG activity lately on competing drafts for a MANET reac= tive protocol - DYMO (reviving the current working group document that was = parked due to inactivity), and LOADng. Many months ago there was a somewhat= authorship led movement towards a common document effort and given positiv= e feedback at the time we the chairs thought this was the best approach giv= en the authors potential to come together and gain the best of both efforts= .=A0 Since that period, there has been some fairly strident and rancorous &= quot;at times" debate between the authors of the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some = of the co-authors of the two documents. Our guidance to the co-authors was = to find a way to merge the two documents into one, as it was perceived that= are not technically far apart and they both derive roughly from AODV conce= pts and LOADng had fairly active authorship and implementation efforts. We = provided a co-editing proposal to the authors and gave them the timeframe o= f the Atlanta to come up with an answer back to us regarding this.=A0 As of= this writing, those discussions of a potential commonn document and author= ship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two do= cuments are divided, and it is unlikely that progress on a merged document = can be reached based upon recent author feedback. I have also polled the ea= rlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the= issue at the present time.=A0 We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there = is consensus on its continued approach and also the desire to rename it to = AODVv2.
2. Replace the existing DYMO document effort with the LOADng rel= ated document effort, defusing ealier references to LLNs as recommended in = the last meeting minutes, and to focus more motivationally on general MANET= problem spaces (the authors seem to have agreed to this issue if its a WG = document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.=A0 We have= been some silent collecting initial feedback and waiting for author feedba= ck at this point.=A0 Stan and I are both on travel prior to Atlanta so our = responses may be sparse and we will also likely be in a "receive mode&= quot; for a few days.=A0 So send your opinions.

-Joe

_______________________________________________
manet mailing list
manet@= ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing = list
manet@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/manet




_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet




--
Dan He
---------= ------------
Tel: +44-788-686-3428

--0016e6d77da122790104cd71f444-- From Chris.Dearlove@baesystems.com Thu Nov 1 10:06:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B6121F905D for ; Thu, 1 Nov 2012 10:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.541 X-Spam-Level: X-Spam-Status: No, score=-10.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTFv9-6NToJh for ; Thu, 1 Nov 2012 10:06:22 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 02E1221F9043 for ; Thu, 1 Nov 2012 10:06:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,693,1344207600"; d="scan'208";a="282995942" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 01 Nov 2012 17:06:21 +0000 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qA1H6KEU018059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 17:06:20 GMT Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Thu, 1 Nov 2012 17:06:20 +0000 From: "Dearlove, Christopher (UK)" To: Philip Levis Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNt4/7KZyE8G8hv0Kl9ZhEgIu1eJfTvFeAgAA+IACAAAPVgIABLOgAgAAAZKCAAAXsAIAABHHA Date: Thu, 1 Nov 2012 17:06:19 +0000 Message-ID: References: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220465DF@xmb-rcd-x02.cisco.com> <3D320804-EE40-42FB-BF08-3F662B3F9542@axelcdv.com> <6C031880-6176-491E-B822-CCE6B8B586FC@cs.stanford.edu> In-Reply-To: <6C031880-6176-491E-B822-CCE6B8B586FC@cs.stanford.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 17:06:23 -0000 No, the implied statement is agreeing with you that simple disc models aren= 't enough, and highlighting a particularly key issue here. I have not even = hinted that I'm discussing RPL, this is the MANET WG where the subject of t= he day is DYMO and LOADng. And I most particularly haven't even hinted at h= aving anything to say about draft-clausen-lln-rpl-experiences. (As for asymmetric vs. unidirectional, oddly most of what I write here uses= asymmetric ;) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu]=20 Sent: 01 November 2012 16:46 To: Dearlove, Christopher (UK) Cc: Axel Colin de Verdi=E8re; List; Bo Berry (boberry) Subject: Re: [manet] Reactive Protocol Situation ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Nov 1, 2012, at 9:27 AM, Dearlove, Christopher (UK) wrote: > They can be good evidence of the failure of protocols ;) >=20 > But what is clear to me is that one important issue (and another of my po= sts is attempting to both be more precise, as well as going elsewhere) is t= he handling of unidirectional links. So any good evidence needs to consider= those. Since communication in wireless is rarely binary, I think the more common t= erm is asymmetric links. I'm confused; I don't believe that unit disc model= s capture asymmetric links. Is the implied statement that RPL doesn't prope= rly handle asymmetric links but LOADng does? I think this came up in draft-= clausen-lln-rpl-experiences and there was some discussion on the ROLL list = about it. The neighbor set in RPL is defined in 8.2.1: "First, the candidate neighbor set is a subset of the nodes that can be rea= ched via link-local multicast." then in DIO processing (8.2.3.1) it reads: "As DIO messages are received from candidate neighbors, the neighbors may b= e promoted to DODAG parents by following the rules of DODAG discovery as de= scribed in Section 8.2." I want to be clear here; I haven't read deeply about LOADng, thought about = it much, or experimented with it at all. So I have zero to say about LOADng= 's strengths and weaknesses.=20 But just because somebody publishes (and republishes) a draft saying someth= ing doesn't mean it's true. There are, in my opinion, some very valid point= s in draft-clausen-lln-rpl-experiences that relate to fundamental design de= cisions in RPL. For example, I think that the issues raised about the state= requirements of floating DODAGs and RPL message fragmentation are valid an= d reasonable and something we need to look at.=20 However, there are others that are the result of naive mistakes anyone can = make when implementing any wireless routing protocol, such as link asymmetr= y and protocol convergence. Unfortunately the draft doesn't distinguish the= two. Implementing a protocol poorly then saying it doesn't work isn't part= icularly meaningful. As I said in Paris, I thought the draft is valuable be= cause it outlines many of the basic mistakes one makes the first time you t= ry implementing a wireless routing protocol. Phil ******************************************************************** 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 drdanhe@gmail.com Thu Nov 1 10:12:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E426B21F90CC for ; Thu, 1 Nov 2012 10:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWDQwKYUl95M for ; Thu, 1 Nov 2012 10:12:23 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id F122821F909F for ; Thu, 1 Nov 2012 10:12:22 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1298438wgb.13 for ; Thu, 01 Nov 2012 10:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/52W+EQt2SD7kKBDEpBoxYlZCGl4ZqWJuu+/SCyt7oA=; b=SASNMoPpzFW58rA+txN8GMHtH1BHCyAAe9wzFZFzPRQwLjJv/EfBHzNbnYCUv9RI54 6J6jnwFAN67kiP9LdE0bbPLlQK+bNnGUVSviFHSvXXFkePPKfiwm05jBOA9L4PMLMkLO RbrE+CF4hRrgEKFPCvLQNb+JPqB/Et+6D9i3f+fS91BtaDptpwpCxpvTszTgdsIZsTOP edbtzLmfG9QccUda2ksO76KGG/0PcrCKKS8AiVyVoh8cRIsN8Wq1uIA1gAm2r10TL0Jw zlkO/yqXzc/X8nSKbMEb4t/lBphWnsF5WS5ap5mT0f2cQv/4kupVzcInwH9LUjg0QoLt LGZA== MIME-Version: 1.0 Received: by 10.180.80.100 with SMTP id q4mr2849878wix.20.1351789941981; Thu, 01 Nov 2012 10:12:21 -0700 (PDT) Received: by 10.194.59.71 with HTTP; Thu, 1 Nov 2012 10:12:21 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Nov 2012 17:12:21 +0000 Message-ID: From: Daniel He To: Don Sturek Content-Type: multipart/alternative; boundary=f46d044283544d80ba04cd721fe4 Cc: " List" Subject: Re: [manet] Reactive Protocol - LOADng vs. AODVv2 at Atlanta X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 17:12:24 -0000 --f46d044283544d80ba04cd721fe4 Content-Type: text/plain; charset=ISO-8859-1 Great suggestions! We need a comparison work of AODVv2 and LOADng. On 1 November 2012 14:47, Don Sturek wrote: > > Why not just have presentations from both prospective solutions in Atlanta > (LOADng and AODVv2) and let the WG decide between these options as a work > plan to address the reactive protocol requirement in MANET: > 1) Progress LOADng (which seems to be happening anyway) > 2) Progress AODVv2 (which seems to have stalled for 2+ years but now > there are promises to pick that up) > 3) Merge AODVv2 and LOADng (which I think is impractical given e-mail > reflector traffic....) > > Not working on a reactive protocol seems like the least desirable outcome. > While there have been inputs for each possible path, it is unclear from > the reflector what the consensus of the group is. > > Personally, it would be useful to hear in Atlanta about large scale > deployments (eg, working code) from each to help the WG decide. I think > all relevant technical information should be provided by Atlanta to help > the WG make the right decision. > > Don > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Dan He --------------------- Tel: +44-788-686-3428 --f46d044283544d80ba04cd721fe4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Great suggestions! We need a comparison work of AODVv2 and LOADng.

<= br>
On 1 November 2012 14:47, Don Sturek <d.sture= k@att.net> wrote:

Why not just have presentations from both prospective solutions in Atlanta<= br> (LOADng and AODVv2) and let the WG decide between these options as a work plan to address the reactive protocol requirement in MANET:
1) =A0Progress LOADng (which seems to be happening anyway)
2) =A0Progress AODVv2 (which seems to have stalled for 2+ years but now
there are promises to pick that up)
3) =A0Merge AODVv2 and LOADng (which I think is impractical given e-mail reflector traffic....)

Not working on a reactive protocol seems like the least desirable outcome.<= br> =A0 While there have been inputs for each possible path, it is unclear from=
the reflector what the consensus of the group is.

Personally, it would be useful to hear in Atlanta about large scale
deployments (eg, working code) from each to help the WG decide. =A0 I think=
all relevant technical information should be provided by Atlanta to help the WG make the right decision.

Don



_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



--
Dan He
-------------= --------
Tel: +44-788-686-3428

--f46d044283544d80ba04cd721fe4-- From ulrich@herberg.name Thu Nov 1 10:13:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DC721F8BD0 for ; Thu, 1 Nov 2012 10:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.851, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNZwHRpOYi2K for ; Thu, 1 Nov 2012 10:13:19 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1661821F8525 for ; Thu, 1 Nov 2012 10:12:46 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3261206vbb.31 for ; Thu, 01 Nov 2012 10:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TIM+UyqdNBG0ApQ+6/1A9q/Gbf6KDql5scvZg0VD+C0=; b=OKMCWEvx40/xOHxe79078nqZ7LgZRr2QJEWfMDSvgxJvAcamg2D9cm/5xCnegvM5F2 Kgy7Y0Peq3VQ03RwSvOsXauxoGNygK7iQHEPXZyADjdZCvS3KUPL8TpbQ+WPczkiVNJI NZlgnW6doFQxuibXT8T3Bi5OVpNva+KzkcHZ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=TIM+UyqdNBG0ApQ+6/1A9q/Gbf6KDql5scvZg0VD+C0=; b=M4ICRX7YjArzXXLbcSf5CIqwJ35RY+slC+TAu1PSV7JdFaY1ZLEt7AWBLDLoxgeBIr VCNbsdcI/h+IosiuZ+mtkV7iXRYYSSLJoNKa9pesqGHwphLN9i4Y2tblXmSGVXciatwD XdEUapDGKQPcQ/GT0qwPVoLBdiCYyEQZ7HhT1GAgYwyc2A/E5iHSW6/df8rqxm+lABfk +B1O71mlLOJWIRY1x4ha0bU4q0bvBjMcvk5md7mzN7fti+HutDoovhcHVo8S/rUT9Srz V/NRvODG97TSsNLc9J2sLmWP99TTn8QwldqNuZLMSX4AnQNK745GiKiUaOgnIuNGANdw sJyw== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr52432629vdv.20.1351789965528; Thu, 01 Nov 2012 10:12:45 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Thu, 1 Nov 2012 10:12:45 -0700 (PDT) In-Reply-To: <6C031880-6176-491E-B822-CCE6B8B586FC@cs.stanford.edu> References: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220465DF@xmb-rcd-x02.cisco.com> <3D320804-EE40-42FB-BF08-3F662B3F9542@axelcdv.com> <6C031880-6176-491E-B822-CCE6B8B586FC@cs.stanford.edu> Date: Thu, 1 Nov 2012 10:12:45 -0700 Message-ID: From: Ulrich Herberg To: Philip Levis Content-Type: multipart/alternative; boundary=bcaec50162bdb4ce6c04cd722081 X-Gm-Message-State: ALoCoQkL1IsoWmqufkRZogAyfDNEMa9QJZpmh0pDTwLKkTCl8X+sRMLk3EpOs75hQkbTFNzMZHYz Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 17:13:20 -0000 --bcaec50162bdb4ce6c04cd722081 Content-Type: text/plain; charset=ISO-8859-1 Hi Phil, maybe we should open a separate email thread about RPL and draft-clausen-lln-rpl-experiences (and probably not in this WG). Best Ulrich On Thu, Nov 1, 2012 at 9:45 AM, Philip Levis wrote: > On Nov 1, 2012, at 9:27 AM, Dearlove, Christopher (UK) wrote: > > > They can be good evidence of the failure of protocols ;) > > > > But what is clear to me is that one important issue (and another of my > posts is attempting to both be more precise, as well as going elsewhere) is > the handling of unidirectional links. So any good evidence needs to > consider those. > > Since communication in wireless is rarely binary, I think the more common > term is asymmetric links. I'm confused; I don't believe that unit disc > models capture asymmetric links. Is the implied statement that RPL doesn't > properly handle asymmetric links but LOADng does? I think this came up in > draft-clausen-lln-rpl-experiences and there was some discussion on the ROLL > list about it. The neighbor set in RPL is defined in 8.2.1: > > "First, the candidate neighbor set is a subset of the nodes that can be > reached via link-local multicast." > > then in DIO processing (8.2.3.1) it reads: > > "As DIO messages are received from candidate neighbors, the neighbors may > be promoted to DODAG parents by following the rules of DODAG discovery as > described in Section 8.2." > > I want to be clear here; I haven't read deeply about LOADng, thought about > it much, or experimented with it at all. So I have zero to say about > LOADng's strengths and weaknesses. > > But just because somebody publishes (and republishes) a draft saying > something doesn't mean it's true. There are, in my opinion, some very valid > points in draft-clausen-lln-rpl-experiences that relate to fundamental > design decisions in RPL. For example, I think that the issues raised about > the state requirements of floating DODAGs and RPL message fragmentation are > valid and reasonable and something we need to look at. > > However, there are others that are the result of naive mistakes anyone can > make when implementing any wireless routing protocol, such as link > asymmetry and protocol convergence. Unfortunately the draft doesn't > distinguish the two. Implementing a protocol poorly then saying it doesn't > work isn't particularly meaningful. As I said in Paris, I thought the draft > is valuable because it outlines many of the basic mistakes one makes the > first time you try implementing a wireless routing protocol. > > Phil > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --bcaec50162bdb4ce6c04cd722081 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Phil,

maybe we should open a separate email thread ab= out RPL and=A0draft-clausen-lln-rpl-experiences (and probably not in this W= G).

Best
Ulrich

On Thu, Nov 1, 2012 at 9:45 AM, Philip Levis <pal@cs.stanford.edu&g= t; wrote:
On Nov 1, 2012, at 9:27 AM, Dearlove, Christopher (UK) wr= ote:

> They can be good evidence of the failure of protocols ;)
>
> But what is clear to me is that one important issue (and another of my= posts is attempting to both be more precise, as well as going elsewhere) i= s the handling of unidirectional links. So any good evidence needs to consi= der those.

Since communication in wireless is rarely binary, I think the more co= mmon term is asymmetric links. I'm confused; I don't believe that u= nit disc models capture asymmetric links. Is the implied statement that RPL= doesn't properly handle asymmetric links but LOADng does? I think this= came up in draft-clausen-lln-rpl-experiences and there was some discussion= on the ROLL list about it. The neighbor set in RPL is defined in 8.2.1:
"First, the candidate neighbor set is a subset of the nodes that can b= e reached via link-local multicast."

then in DIO processing (8.2.3.1) it reads:

"As DIO messages are received from candidate neighbors, the neighbors = may be promoted to DODAG parents by following the rules of DODAG discovery = as described in Section 8.2."

I want to be clear here; I haven't read deeply about LOADng, thought ab= out it much, or experimented with it at all. So I have zero to say about LO= ADng's strengths and weaknesses.

But just because somebody publishes (and republishes) a draft saying someth= ing doesn't mean it's true. There are, in my opinion, some very val= id points in draft-clausen-lln-rpl-experiences that relate to fundamental d= esign decisions in RPL. For example, I think that the issues raised about t= he state requirements of floating DODAGs and RPL message fragmentation are = valid and reasonable and something we need to look at.

However, there are others that are the result of naive mistakes anyone can = make when implementing any wireless routing protocol, such as link asymmetr= y and protocol convergence. Unfortunately the draft doesn't distinguish= the two. Implementing a protocol poorly then saying it doesn't work is= n't particularly meaningful. As I said in Paris, I thought the draft is= valuable because it outlines many of the basic mistakes one makes the firs= t time you try implementing a wireless routing protocol.

Phil
___________________________________= ____________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--bcaec50162bdb4ce6c04cd722081-- From drdanhe@gmail.com Thu Nov 1 10:14:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D95C21F8C19 for ; Thu, 1 Nov 2012 10:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yCByg75Wbj5 for ; Thu, 1 Nov 2012 10:14:36 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E51221F8C0E for ; Thu, 1 Nov 2012 10:14:36 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1299370wgb.13 for ; Thu, 01 Nov 2012 10:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+pUFfjgbNnCsPwrSX/JA9OTUlwxU9cNdYmabBkrmcUw=; b=tpUeb9r3pXsG3Cucke6Y/LvTW/y1ihQAOnLXA1/4sKHY0c2k9rNCqVdALV1OTCtfSz rXsWpNLGgb5sN4Awj8nAkov/4qQ20dfRooqx+uCssOSD1Bzsvdr/auFJIQNlbBeeqO8Z XlqA0jRGgu79+QS92PZ32b9IHYf+477mkT/RGsVLBslWCqS7Dq7fbyNgDnjLwlMvulzV pwEh6Kh+ZBAfVd7s0JLYXfJ1VyC+q/kzglbKmu1PVeQn/9+k2H/3Fz7MTZGqlkLVJioG /i0yg3LDQP8z8s4MaUb6208yFJ8+IrYlwq+qDeYmdHwrWceLsLuloQDc+3CZXh65e0zm 6ECw== MIME-Version: 1.0 Received: by 10.216.204.101 with SMTP id g79mr19923068weo.65.1351790075352; Thu, 01 Nov 2012 10:14:35 -0700 (PDT) Received: by 10.194.59.71 with HTTP; Thu, 1 Nov 2012 10:14:35 -0700 (PDT) In-Reply-To: References: <5091D7A0.8090808@computer.org> Date: Thu, 1 Nov 2012 17:14:35 +0000 Message-ID: From: Daniel He To: Joseph Macker Content-Type: multipart/alternative; boundary=0016e6d77da140970304cd722717 Cc: "manet@ietf.org" Subject: Re: [manet] Slides please X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 17:14:37 -0000 --0016e6d77da140970304cd722717 Content-Type: text/plain; charset=ISO-8859-1 +1 On 1 November 2012 02:34, Joseph Macker wrote: > Yes slots for DYMO and LOADng authors were both requested and will be > accomodated. > We left ample time for reactive discussion on the schedule. > > -Joe > > > > On Wed, Oct 31, 2012 at 10:29 PM, Ulrich Herberg wrote: > >> Hello Charlie, >> >> I wrote this email in my function as WG secretary. It is up to the chairs >> to decide the slots and who presents. I simply upload the slides and assist >> the chairs with organizing the meeting. >> >> Best regards >> Ulrich >> >> >> On Wed, Oct 31, 2012 at 7:00 PM, Charles E. Perkins < >> charliep@computer.org> wrote: >> >>> >>> Hello Ulrich, >>> >>> If I can make a presentation about AODVv2, I would like to do that. >>> >>> Regards, >>> Charlie P. >>> >>> >>> >>> On 10/31/2012 4:00 PM, Ulrich Herberg wrote: >>> >>> Hello, >>> >>> for those who present at the MANET meeting: please send your slides >>> (in ppt or pdf) to the chairs and me. Please send them by this weekend, so >>> that I can upload the slides on Sunday. >>> >>> Thank you >>> Ulrich >>> >>> >>> _______________________________________________ >>> manet mailing listmanet@ietf.orghttps://www.ietf.org/mailman/listinfo/manet >>> >>> >>> >>> -- >>> Regards, >>> Charlie P. >>> >>> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > -- Dan He --------------------- Tel: +44-788-686-3428 --0016e6d77da140970304cd722717 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1


On 1 November 2012 02:34, Joseph M= acker <jpmacker@gmail.com> wrote:
Yes slots for DYMO and LOADng authors were both requested and will be accom= odated.
We left ample time for reactive discussion on the schedule.
<= br>-Joe



On Wed, Oct 31, 2012 at 10:29 PM, Ulrich= Herberg <ulrich@herberg.name> wrote:
Hello Charlie,

I wrote th= is email in my function as WG secretary. It is up to the chairs to decide t= he slots and who presents. I simply upload the slides and assist the chairs= with organizing the meeting.

Best regards
Ul= rich


On Wed, Oct = 31, 2012 at 7:00 PM, Charles E. Perkins <charliep@computer.org>= wrote:
=20 =20 =20

Hello Ulrich,

If I can make a presentation about AODVv2, I would like to do that.

Regards,
Charlie P.



On 10/31/2012 4:00 PM, Ulrich Herberg wrote:
Hello,

for those who present at the MANET meeting: please send your slides (in ppt or pdf) to the chairs and me. Please send them by this weekend, so that I can upload the slides on Sunday.

Thank you
Ulrich


_______________________________________________
manet mailing list
manet@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/manet



--=20
Regards,
Charlie P.


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet




--
Dan He
---------= ------------
Tel: +44-788-686-3428

--0016e6d77da140970304cd722717-- From prvs=6453cbe82=mukul@uwm.edu Thu Nov 1 10:25:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2983521F912A for ; Thu, 1 Nov 2012 10:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00AVPowRKr0q for ; Thu, 1 Nov 2012 10:25:53 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 67E1021F9125 for ; Thu, 1 Nov 2012 10:25:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EANSvklB/AAAB/2dsb2JhbABBA4YXwHwBAQEEAQEBIEsLDA8OAwQBAQMCDRkCIwYoCAYTG4dZAw8LqgOJJgUITIkEBIEgiXRnGoJ4ghaBEwOIWotJgVWLMoURgw2BRjU Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 854152A11B3; Thu, 1 Nov 2012 12:25:52 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fe2D7HBfcZ3; Thu, 1 Nov 2012 12:25:52 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 38E762A11AD; Thu, 1 Nov 2012 12:25:52 -0500 (CDT) Date: Thu, 1 Nov 2012 12:25:52 -0500 (CDT) From: Mukul Goyal To: Daniel He Message-ID: <1060782153.176608.1351790752151.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: List Subject: Re: [manet] Reactive Protocol - LOADng vs. AODVv2 at Atlanta X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 17:25:54 -0000 Those of us who wont be at Atlanta would greatly appreciate hearing from AO= DVv2/LOADng authors on the mailing list what they think are the similaritie= s and the differences between the two protocols. Thanks Mukul ----- Original Message ----- From: "Daniel He" To: "Don Sturek" Cc: " List" Sent: Thursday, November 1, 2012 12:12:21 PM Subject: Re: [manet] Reactive Protocol - LOADng vs. AODVv2 at Atlanta Great suggestions! We need a comparison work of AODVv2 and LOADng.=20 On 1 November 2012 14:47, Don Sturek < d.sturek@att.net > wrote:=20 Why not just have presentations from both prospective solutions in Atlanta= =20 (LOADng and AODVv2) and let the WG decide between these options as a work= =20 plan to address the reactive protocol requirement in MANET:=20 1) =C2=A0Progress LOADng (which seems to be happening anyway)=20 2) =C2=A0Progress AODVv2 (which seems to have stalled for 2+ years but now= =20 there are promises to pick that up)=20 3) =C2=A0Merge AODVv2 and LOADng (which I think is impractical given e-mail= =20 reflector traffic....)=20 Not working on a reactive protocol seems like the least desirable outcome.= =20 =C2=A0 While there have been inputs for each possible path, it is unclear f= rom=20 the reflector what the consensus of the group is.=20 Personally, it would be useful to hear in Atlanta about large scale=20 deployments (eg, working code) from each to help the WG decide. =C2=A0 I th= ink=20 all relevant technical information should be provided by Atlanta to help=20 the WG make the right decision.=20 Don=20 _______________________________________________=20 manet mailing list=20 manet@ietf.org=20 https://www.ietf.org/mailman/listinfo/manet=20 --=20 Dan He=20 ---------------------=20 Tel: +44-788-686-3428=20 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Thu Nov 1 10:26:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A6821F913D for ; Thu, 1 Nov 2012 10:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1wqfo9KRWWo for ; Thu, 1 Nov 2012 10:26:15 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 9A68721F9139 for ; Thu, 1 Nov 2012 10:26:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,693,1344207600"; d="scan'208,217";a="240350077" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 01 Nov 2012 17:26:13 +0000 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qA1HQDvb003678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 17:26:13 GMT Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Thu, 1 Nov 2012 17:26:13 +0000 From: "Dearlove, Christopher (UK)" To: Daniel He , Don Sturek Thread-Topic: [manet] Reactive Protocol - LOADng vs. AODVv2 at Atlanta Thread-Index: AQHNuD/sk9YkJECl10C8t6fMcfEhhJfVN5uAgAADnHA= Date: Thu, 1 Nov 2012 17:26:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB5DB1GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: " List" Subject: Re: [manet] Reactive Protocol - LOADng vs. AODVv2 at Atlanta X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 17:26:16 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB5DB1GLKXM0002VGREEN_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There's a more succinct way of saying what I said in several more lines. (The second sentence.) -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Daniel He Sent: 01 November 2012 17:12 To: Don Sturek Cc: List Subject: Re: [manet] Reactive Protocol - LOADng vs. AODVv2 at Atlanta *** WARNING *** This message originates from outside our organisation, either from an external partner or the internet. Keep this in mind if you answer this message. Please see this process on how to deal with suspicious emails. Great suggestions! We need a comparison work of AODVv2 and LOADng. On 1 November 2012 14:47, Don Sturek > wrote: Why not just have presentations from both prospective solutions in Atlanta (LOADng and AODVv2) and let the WG decide between these options as a work plan to address the reactive protocol requirement in MANET: 1) Progress LOADng (which seems to be happening anyway) 2) Progress AODVv2 (which seems to have stalled for 2+ years but now there are promises to pick that up) 3) Merge AODVv2 and LOADng (which I think is impractical given e-mail reflector traffic....) Not working on a reactive protocol seems like the least desirable outcome. While there have been inputs for each possible path, it is unclear from the reflector what the consensus of the group is. Personally, it would be useful to hear in Atlanta about large scale deployments (eg, working code) from each to help the WG decide. I think all relevant technical information should be provided by Atlanta to help the WG make the right decision. Don _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet -- Dan He --------------------- Tel: +44-788-686-3428 ******************************************************************** 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. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB5DB1GLKXM0002VGREEN_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

There's a more succinct way of saying what I said in several more lines. (The second sentence.)

 

--

Christopher Dearlove

Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Daniel He
Sent: 01 November 2012 17:12
To: Don Sturek
Cc: <manet@ietf.org> List
Subject: Re: [manet] Reactive Protocol - LOADng vs. AODVv2 at Atlanta

 

 

*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

Great suggestions! We need a comparison work of AODVv2 and LOADng.

On 1 November 2012 14:47, Don Sturek <d.sturek@att.net> wrote:


Why not just have presentations from both prospective solutions in Atlanta
(LOADng and AODVv2) and let the WG decide between these options as a work
plan to address the reactive protocol requirement in MANET:
1)  Progress LOADng (which seems to be happening anyway)
2)  Progress AODVv2 (which seems to have stalled for 2+ years but now
there are promises to pick that up)
3)  Merge AODVv2 and LOADng (which I think is impractical given e-mail
reflector traffic....)

Not working on a reactive protocol seems like the least desirable outcome.
  While there have been inputs for each possible path, it is unclear from
the reflector what the consensus of the group is.

Personally, it would be useful to hear in Atlanta about large scale
deployments (eg, working code) from each to help the WG decide.   I think
all relevant technical information should be provided by Atlanta to help
the WG make the right decision.

Don



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet




--
Dan He
---------------------
Tel: +44-788-686-3428


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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB5DB1GLKXM0002VGREEN_-- From abdussalambaryun@gmail.com Thu Nov 1 10:35:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3695F21F91B4 for ; Thu, 1 Nov 2012 10:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.415 X-Spam-Level: X-Spam-Status: No, score=-3.415 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO6b-y0LJqiJ for ; Thu, 1 Nov 2012 10:35:00 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 158A121F91B3 for ; Thu, 1 Nov 2012 10:34:59 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3287488vbb.31 for ; Thu, 01 Nov 2012 10:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AzM8XptHsVo6d3G2vPJotZIAvGCbe/HlOS3NcGlA6YY=; b=0Atrhzhe50pDxUAZZ15sQdOBo5/JyMMgPGMXMX4LG8bazN1dOLDOf9blesOZ4Pf9gS 5uEhpR+3Fa4zqPQLIbLQYp2hUOlkqZknZq0O7wkoVk9OT9NdhKR/sk4q42Y4/aqjdkDL CNta2diPY1vdNPygYXsMgS77rfcwXJr/bFN2kepFe1wk6Gm/5TfoU34xHgwsX87VhZMk 2HFjVV9+lBZOJgbZSLWbV/wFJsl63YPSENWHiGczbNDwySuFpol2reukHqs5iS9w7KE/ RDVIJF0PLzO07b558KXH6/vVkHiSckqP1sYYjiMPPniqaZXzynQe32lGdHuyQnZ2MwjV yx2A== MIME-Version: 1.0 Received: by 10.52.77.101 with SMTP id r5mr51755335vdw.25.1351791299446; Thu, 01 Nov 2012 10:34:59 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 10:34:59 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Nov 2012 17:34:59 +0000 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=20cf307abd9336c63b04cd727076 Cc: "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 17:35:01 -0000 --20cf307abd9336c63b04cd727076 Content-Type: text/plain; charset=ISO-8859-1 Hi Chris, I think that your suggestions and other discussions related to the subject MUST be done on the MANET list, and not within the f2f meetings. AB On Thu, Nov 1, 2012 at 4:22 PM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > The obviously best people to answer this should be document authors, but > anyone else may have useful additions and comments. Ideally the different > document authors could agree a list. (If they differ in that one has X and > the other doesn't, but one wants to say "we plan to add/remove X" then X > should be listed as a difference with that caveat, in at least my ideal > world.) > > If we set aside, for the moment (though these things matter): > - The presentational quality of the documents, > - Any issues of 5444 compliance and other formatting issues, > - Issues of internal data organisation, > - Minor details such as possible different timeout parameters etc. > then what are the technical (and I stress that word) differences between > DYMO and LOADng? (I'm withholding the term AODVv2 for reasons I may come > back to.) > > Note that it's a lot more useful to have direct differences than > differences of each from AODV (especially when both have the same > difference). And it would be useful to have the objective differences > separated from the "and now why this is better" discussion - though that > would be a next step. > > I'm not saying I don't see any of the differences. But I certainly haven't > worked out the complete list. In trying to form my view of how things > should go forward (a view that is coming together, and when it does, I'll > argue for it) and I hope for other people as well, it would be good to know > what the differences are. Regardless of views for or against each, we > should be able to objectively list the significant differences - if we > can't then something is wrong. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > ******************************************************************** > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf307abd9336c63b04cd727076 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Chris,
=A0
I think=A0that your suggestions and = other discussions related to the subject MUST be done on the MANET list, an= d=A0not within the f2f meetings.
=A0
AB
On Thu, Nov 1, 2012 at 4:22 PM, Dearlove, Christopher (UK) <Ch= ris.Dearlove@baesystems.com> wrote:
The obviously best people to answer this should be document authors, but an= yone else may have useful additions and comments. Ideally the different doc= ument authors could agree a list. (If they differ in that one has X and the= other doesn't, but one wants to say "we plan to add/remove X"= ; then X should be listed as a difference with that caveat, in at least my = ideal world.)

If we set aside, for the moment (though these things matter):
- The presentational quality of the documents,
- Any issues of 5444 compliance and other formatting issues,
- Issues of internal data organisation,
- Minor details such as possible different timeout parameters etc.
then what are the technical (and I stress that word) differences between DY= MO and LOADng? (I'm withholding the term AODVv2 for reasons I may come = back to.)

Note that it's a lot more useful to have direct differences than differ= ences of each from AODV (especially when both have the same difference). An= d it would be useful to have the objective differences separated from the &= quot;and now why this is better" discussion - though that would be a n= ext step.

I'm not saying I don't see any of the differences. But I certainly = haven't worked out the complete list. In trying to form my view of how = things should go forward (a view that is coming together, and when it does,= I'll argue for it) and I hope for other people as well, it would be go= od to know what the differences are. Regardless of views for or against eac= h, we should be able to objectively list the significant differences - if w= e can't then something is wrong.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245= 242194=A0| =A0Fax: +44 1245 242124
chris.dearlove@baesystems.= com | http://ww= w.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687



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

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf307abd9336c63b04cd727076-- From abdussalambaryun@gmail.com Thu Nov 1 10:39:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C728A21F8EFE for ; Thu, 1 Nov 2012 10:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUsWmk42Bd50 for ; Thu, 1 Nov 2012 10:39:16 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 055C021F8EFD for ; Thu, 1 Nov 2012 10:39:15 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3292528vbb.31 for ; Thu, 01 Nov 2012 10:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fbWTMaKWD9G5NMv1z+sSfjvHDj5nnhRGMXS5azXHk9k=; b=CdUmXAjXpBQ5iBwg0bchjn8w5jXkX5QNDtuWRgU3HbppjYsAxCkgSLTB181ORFGYup RtXOq4XytpabBaKvElHJ6Q34lrJ1+SY9Y67/LG1v04Q2A9xq/VaDdxNlwvsLp7hRBgS1 dfSiRjiS/RWtn9nQnov8hWkElOwArOJFQPegBj4gY0Rgkxnr9Q/Ba/N+ZPNQUFQ62MgS Hkq+8uiZnK/qqcoWGjiZBGQpNbi1n3luNs4i2P6ZztUdLVfqcXFJO6DIra9WgQ1EY1uo ET78UFPih/qEqU6FmmGsLi0X0IwUStQxF9a5mCRjAnuWI9+uN+/rQl497i41GnnOGRxD jv8A== MIME-Version: 1.0 Received: by 10.52.35.82 with SMTP id f18mr51501802vdj.99.1351791555162; Thu, 01 Nov 2012 10:39:15 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 10:39:15 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Nov 2012 17:39:15 +0000 Message-ID: From: Abdussalam Baryun To: Daniel He Content-Type: multipart/alternative; boundary=20cf307c9fbe74b27104cd727f27 Cc: " List" Subject: Re: [manet] Reactive Protocol - LOADng vs. AODVv2 at Atlanta X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 17:39:16 -0000 --20cf307c9fbe74b27104cd727f27 Content-Type: text/plain; charset=ISO-8859-1 I am interested to see your efforts on a comparison, but we don't forget to mention that LOADng is developed from LOAD and AODV RFC3561, AB On Thu, Nov 1, 2012 at 5:12 PM, Daniel He wrote: > Great suggestions! We need a comparison work of AODVv2 and LOADng. > > > > On 1 November 2012 14:47, Don Sturek wrote: > >> >> Why not just have presentations from both prospective solutions in Atlanta >> (LOADng and AODVv2) and let the WG decide between these options as a work >> plan to address the reactive protocol requirement in MANET: >> 1) Progress LOADng (which seems to be happening anyway) >> 2) Progress AODVv2 (which seems to have stalled for 2+ years but now >> there are promises to pick that up) >> 3) Merge AODVv2 and LOADng (which I think is impractical given e-mail >> reflector traffic....) >> >> Not working on a reactive protocol seems like the least desirable outcome. >> While there have been inputs for each possible path, it is unclear from >> the reflector what the consensus of the group is. >> >> Personally, it would be useful to hear in Atlanta about large scale >> deployments (eg, working code) from each to help the WG decide. I think >> all relevant technical information should be provided by Atlanta to help >> the WG make the right decision. >> >> Don >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > > -- > Dan He > --------------------- > Tel: +44-788-686-3428 > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --20cf307c9fbe74b27104cd727f27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am interested to see your efforts on=A0a comparison, but we don'= t forget to mention=A0that LOADng=A0is developed=A0from LOAD and AODV RFC35= 61,
=A0
AB

On T= hu, Nov 1, 2012 at 5:12 PM, Daniel He <drdanhe@gmail.com> wr= ote:
Great suggestions! We need a comparison work of AODVv2 and= LOADng.



On 1 November 2012= 14:47, Don Sturek <d.sturek@att.net> wrote:

Why not just have presentations from both prospective solutions in Atlanta<= br> (LOADng and AODVv2) and let the WG decide between these options as a work plan to address the reactive protocol requirement in MANET:
1) =A0Progress LOADng (which seems to be happening anyway)
2) =A0Progress AODVv2 (which seems to have stalled for 2+ years but now
there are promises to pick that up)
3) =A0Merge AODVv2 and LOADng (which I think is impractical given e-mail reflector traffic....)

Not working on a reactive protocol seems like the least desirable outcome.<= br> =A0 While there have been inputs for each possible path, it is unclear from=
the reflector what the consensus of the group is.

Personally, it would be useful to hear in Atlanta about large scale
deployments (eg, working code) from each to help the WG decide. =A0 I think=
all relevant technical information should be provided by Atlanta to help the WG make the right decision.

Don



_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



--
Dan He
---------------------
Tel:= +44-788-686-3428


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--20cf307c9fbe74b27104cd727f27-- From charliep@computer.org Thu Nov 1 10:44:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15ABC21F917C for ; Thu, 1 Nov 2012 10:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3So2gbJLdxT for ; Thu, 1 Nov 2012 10:44:02 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id D2A6621F9175 for ; Thu, 1 Nov 2012 10:43:59 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TTyoB-00024V-8l; Thu, 01 Nov 2012 13:43:59 -0400 Message-ID: <5092B4D6.3080206@computer.org> Date: Thu, 01 Nov 2012 10:43:51 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <061.dd96a35b96e4ad8b95c1f2b46c7199f8@trac.tools.ietf.org> <9FCCC536-EB92-4276-AC30-D92A4A9A9324@thomasclausen.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86284c7aee5bf2639bc50ef293b394648b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: "manet@ietf.org" Subject: Re: [manet] #3: Use msg-hop-count in RFC 5444 header to limit # of hops X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 17:44:03 -0000 Hello Chris, RFC 5444 has this: o field, if present, contains the number of hops on which the packet has traveled across the MANET. The is set to 0 by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should increase by 1 and should discard the message when reaches 255. From this, I conclude that the purpose of the field is to count the number of hops a message has traversed. Am I missing something? -- Regards, Charlie P. From hrogge@googlemail.com Thu Nov 1 10:46:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799ED21F91FC for ; Thu, 1 Nov 2012 10:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DC99YX23Fbxg for ; Thu, 1 Nov 2012 10:46:19 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 11EE221F91FB for ; Thu, 1 Nov 2012 10:46:19 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so1895423pbb.31 for ; Thu, 01 Nov 2012 10:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LjhtLEa3Ku4DBRliFmSPNpg9knmCKuyMJNYrfuJPLKc=; b=mfQBIUYvPWxrCI+sCNmyyQZ/BQfcaZkGiPum6lZ43We0H2WFo/eU/mJVcruPjL5kha /oTtwANyoOrfmsYPW5SY46dshpQrM8StIhswGjUIagh8p+Ie+/tDxC+70Vw957C7blj6 R3pCHZR0KJzFU23iAb7Qmeaz+XlM0KVz1vg92Dy4OQHSy5n51CM4K/7/jehV8mR4f6gz 6qHInrLX7ZsZtkZMqyXEzNzw6ibsu6ShZFklqsdaS8JDaLcli2CQ5uSZSzyfTc0XGrHG VhevcJFzLsfoawlHwRuBFERG4j5LOqL1xPvSYvyRHOUKK2Vce8Ljr8uEPHiBHSLGu8Qu QFGw== Received: by 10.68.233.196 with SMTP id ty4mr125557730pbc.23.1351791978810; Thu, 01 Nov 2012 10:46:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Thu, 1 Nov 2012 10:45:58 -0700 (PDT) In-Reply-To: <5092B4D6.3080206@computer.org> References: <061.dd96a35b96e4ad8b95c1f2b46c7199f8@trac.tools.ietf.org> <9FCCC536-EB92-4276-AC30-D92A4A9A9324@thomasclausen.org> <5092B4D6.3080206@computer.org> From: Henning Rogge Date: Thu, 1 Nov 2012 18:45:58 +0100 Message-ID: To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] #3: Use msg-hop-count in RFC 5444 header to limit # of hops X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 17:46:19 -0000 On Thu, Nov 1, 2012 at 6:43 PM, Charles E. Perkins wrote: > > Hello Chris, > > RFC 5444 has this: > > o field, if present, contains the number of hops on > which the packet has traveled across the MANET. The count> is set to 0 by the message originator and is used to > prevent messages from endlessly circulating in a MANET. When > forwarding a message, a MANET router should increase count> by 1 and should discard the message when > reaches 255. > > From this, I conclude that the purpose of the field is to count the > number of hops a message has traversed. > > Am I missing something? If DYMO changes the content of a message, its not the same message anymore. At least thats how I understand this field. You could not put a signature on it "end to end" for example. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ulrich@herberg.name Thu Nov 1 10:54:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3E621F9053 for ; Thu, 1 Nov 2012 10:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.766, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zadVwvKyPj+h for ; Thu, 1 Nov 2012 10:54:43 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F37521F8FD2 for ; Thu, 1 Nov 2012 10:54:43 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3290244vcb.31 for ; Thu, 01 Nov 2012 10:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fxe+E9kKprnmWQjOobR4jfHTPqQ/+U7bSYBeIs7yH0c=; b=JKiqUZBw1UD/+8CcqEu9HcvyDk+eXvJ0z9PX7twOmQIOkCt5pid8MxqezeeoWIVcvH 95QzHPWJ7e8Ju2TjC1a0iyweJKF51VQ3+DQH7xaLfPiIhbGFKMVmZ//7jqtBWFXi/fOo y/1dW8tVBkpNGTAnqB3REdYk+5PMTu9Wn73ig= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=fxe+E9kKprnmWQjOobR4jfHTPqQ/+U7bSYBeIs7yH0c=; b=U8Kq0yiBAKpNNyp/qBgP8J7JDwPJRIrwJ7ie3MthXo/qPTnUSaq45mm11XZS+c5Buo wLLCNkIcqjMs65yJh+FHQ7P7kjfOtC8ohwURsC4urvkB6ROEHqbDmo7w4zYmzq2P3442 CK6aNoig1u8+AFSvsQp2sW9ETK5QrUdWISXTG6VcQH6/BZFYnCETZtjhtSFNk/7PXgqU iFMFMMG0Cwf3umu+RTxkxxH2hf90lVYI0p3lvn/rcAH2+5f7TM+7kEAZWn+iddlVsIyV iv6KTBnOmtxayqQUgjkxNHzhNQHK9cghqmTe2UDHgngMXjC5gEuZ2c6eujgexTWoVMt1 TU8Q== MIME-Version: 1.0 Received: by 10.220.225.132 with SMTP id is4mr23714160vcb.47.1351792482717; Thu, 01 Nov 2012 10:54:42 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Thu, 1 Nov 2012 10:54:42 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Nov 2012 10:54:42 -0700 Message-ID: From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=14dae9ccd52cbe101704cd72b6ce X-Gm-Message-State: ALoCoQlzXOBEsIs6AwdL/vWZd+l0kpCohu3QucG7OzYacwcB72jUy/DJtJu3CCTLYzsedaVlN4ji Cc: "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 17:54:44 -0000 --14dae9ccd52cbe101704cd72b6ce Content-Type: text/plain; charset=ISO-8859-1 Chris, I think this is a good start to have a technical discussion. I hope that everyone could thoroughly *read* both documents and give a technical opinion. I will read the latest DYMO revision in detail and then answer to your email. Best regards Ulrich On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > The obviously best people to answer this should be document authors, but > anyone else may have useful additions and comments. Ideally the different > document authors could agree a list. (If they differ in that one has X and > the other doesn't, but one wants to say "we plan to add/remove X" then X > should be listed as a difference with that caveat, in at least my ideal > world.) > > If we set aside, for the moment (though these things matter): > - The presentational quality of the documents, > - Any issues of 5444 compliance and other formatting issues, > - Issues of internal data organisation, > - Minor details such as possible different timeout parameters etc. > then what are the technical (and I stress that word) differences between > DYMO and LOADng? (I'm withholding the term AODVv2 for reasons I may come > back to.) > > Note that it's a lot more useful to have direct differences than > differences of each from AODV (especially when both have the same > difference). And it would be useful to have the objective differences > separated from the "and now why this is better" discussion - though that > would be a next step. > > I'm not saying I don't see any of the differences. But I certainly haven't > worked out the complete list. In trying to form my view of how things > should go forward (a view that is coming together, and when it does, I'll > argue for it) and I hope for other people as well, it would be good to know > what the differences are. Regardless of views for or against each, we > should be able to objectively list the significant differences - if we > can't then something is wrong. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > ******************************************************************** > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --14dae9ccd52cbe101704cd72b6ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Chris,

I think this is a good start to have a technical = discussion. I hope that everyone could thoroughly *read* both documents and= give a technical opinion. I will read the latest DYMO revision in detail a= nd then answer to your email.

Best regards
Ulrich

On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:
The obviously best people to answer this sho= uld be document authors, but anyone else may have useful additions and comm= ents. Ideally the different document authors could agree a list. (If they d= iffer in that one has X and the other doesn't, but one wants to say &qu= ot;we plan to add/remove X" then X should be listed as a difference wi= th that caveat, in at least my ideal world.)

If we set aside, for the moment (though these things matter):
- The presentational quality of the documents,
- Any issues of 5444 compliance and other formatting issues,
- Issues of internal data organisation,
- Minor details such as possible different timeout parameters etc.
then what are the technical (and I stress that word) differences between DY= MO and LOADng? (I'm withholding the term AODVv2 for reasons I may come = back to.)

Note that it's a lot more useful to have direct differences than differ= ences of each from AODV (especially when both have the same difference). An= d it would be useful to have the objective differences separated from the &= quot;and now why this is better" discussion - though that would be a n= ext step.

I'm not saying I don't see any of the differences. But I certainly = haven't worked out the complete list. In trying to form my view of how = things should go forward (a view that is coming together, and when it does,= I'll argue for it) and I hope for other people as well, it would be go= od to know what the differences are. Regardless of views for or against eac= h, we should be able to objectively list the significant differences - if w= e can't then something is wrong.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245= 242194=A0| =A0Fax: +44 1245 242124
chris.dearlove@baesystems.= com | http://ww= w.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687



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

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--14dae9ccd52cbe101704cd72b6ce-- From charliep@computer.org Thu Nov 1 11:04:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A76221F9106 for ; Thu, 1 Nov 2012 11:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cebEy0Bbwtb for ; Thu, 1 Nov 2012 11:04:33 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id DD84921F90EC for ; Thu, 1 Nov 2012 11:04:24 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TTz7u-0004lo-VS; Thu, 01 Nov 2012 14:04:23 -0400 Message-ID: <5092B99D.4000609@computer.org> Date: Thu, 01 Nov 2012 11:04:13 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Henning Rogge References: <061.dd96a35b96e4ad8b95c1f2b46c7199f8@trac.tools.ietf.org> <9FCCC536-EB92-4276-AC30-D92A4A9A9324@thomasclausen.org> <5092B4D6.3080206@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8646cb78946c17176cef02d4ac089c0113350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] #3: Use msg-hop-count in RFC 5444 header to limit # of hops X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:04:33 -0000 Hello Henning, RFC 5444 also says this: o For forwarded messages where the message is unchanged by forwarding MANET routers, end-to-end authentication and integrity MAY be implemented, between MANET routers with an existing security association, by including a suitable Message TLV containing a cryptographic signature in the message. Since and are the only fields that should be modified when such a message is forwarded in this manner, this signature can be calculated based on the entire message, including the Message Header, with the and fields set to 0, if present. I think this means that the msg-hop-count can be incremented while the other content of the message remains the same. Regards, Charlie P. On 11/1/2012 10:45 AM, Henning Rogge wrote: > On Thu, Nov 1, 2012 at 6:43 PM, Charles E. Perkins > wrote: >> Hello Chris, >> >> RFC 5444 has this: >> >> o field, if present, contains the number of hops on >> which the packet has traveled across the MANET. The > count> is set to 0 by the message originator and is used to >> prevent messages from endlessly circulating in a MANET. When >> forwarding a message, a MANET router should increase > count> by 1 and should discard the message when >> reaches 255. >> >> From this, I conclude that the purpose of the field is to count the >> number of hops a message has traversed. >> >> Am I missing something? > If DYMO changes the content of a message, its not the same message > anymore. At least thats how I understand this field. > > You could not put a signature on it "end to end" for example. > > Henning Rogge -- Regards, Charlie P. From hrogge@googlemail.com Thu Nov 1 11:06:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8EA21F924B for ; Thu, 1 Nov 2012 11:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hTGaTp9WG+A for ; Thu, 1 Nov 2012 11:06:17 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2797521F91F2 for ; Thu, 1 Nov 2012 11:06:16 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so1276502dan.31 for ; Thu, 01 Nov 2012 11:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=00UMDnwnkKP1syfxVMguAJggpgPm84dmNmiUcoIhy7k=; b=UMiyobVLX93bXbMVhvHuV3+8SkckdNu9CUL+Y8wwEB2yQHhxnJmBrAaTpTDSYUDbPm diM9W9r05Vl/NxCheDnroGUADpTfNLIvGZZIo0KP+/ygxzbSkCwrRHgzN0kBbGuLOyMK /jOxGwO8Vc6LyBuXhwZtndgqZqh53uBigKiw6Ml5U1N7+UlitqOSU/7QMgR9MYrXcSxM AVFqeedeGKJdfFDXzY3fXJl8aenCxk7PAT9E/58AVUFYAx8p2pNTYDHhYog2hshhYOx1 qENu7ENIPvanmKWHWjN/PUGGKQ7m4Gv/d/XR/bSAQgDCzfo7S7tTDBxU9nX1offxG/+r kQ3w== Received: by 10.66.75.165 with SMTP id d5mr113300076paw.39.1351793176724; Thu, 01 Nov 2012 11:06:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Thu, 1 Nov 2012 11:05:56 -0700 (PDT) In-Reply-To: <5092B99D.4000609@computer.org> References: <061.dd96a35b96e4ad8b95c1f2b46c7199f8@trac.tools.ietf.org> <9FCCC536-EB92-4276-AC30-D92A4A9A9324@thomasclausen.org> <5092B4D6.3080206@computer.org> <5092B99D.4000609@computer.org> From: Henning Rogge Date: Thu, 1 Nov 2012 19:05:56 +0100 Message-ID: To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] #3: Use msg-hop-count in RFC 5444 header to limit # of hops X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:06:17 -0000 On Thu, Nov 1, 2012 at 7:04 PM, Charles E. Perkins wrote: > Hello Henning, > > RFC 5444 also says this: > > o For forwarded messages where the message is unchanged by > forwarding MANET routers, end-to-end authentication and integrity > MAY be implemented, between MANET routers with an existing > security association, by including a suitable Message TLV > containing a cryptographic signature in the message. Since hop-count> and are the only fields that should be > modified when such a message is forwarded in this manner, this > signature can be calculated based on the entire message, including > the Message Header, with the and > fields set to 0, if present. > > I think this means that the msg-hop-count can be incremented while > the other content of the message remains the same. Yes... similar to the IP TTL/Hopcount field. But nothing else. I think the issue was that DYMO is changing the content of the messages hop-by-hop (the metric value towards to originator). Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From jvasseur@cisco.com Thu Nov 1 11:22:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFC521F87A8 for ; Thu, 1 Nov 2012 11:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.969 X-Spam-Level: X-Spam-Status: No, score=-9.969 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKUwgUlM7bRh for ; Thu, 1 Nov 2012 11:22:55 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D5D4921F84A6 for ; Thu, 1 Nov 2012 11:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28156; q=dns/txt; s=iport; t=1351794173; x=1353003773; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FsUzCPyijuACrfmflJTWXtc2EYtxxsSlxmP7nzE4qfw=; b=MDqWahtOLvDYMRfHY3Dmmyg139x1IY9gJl01JYtVt3piihymh4AZxQ/2 e7ssye+36zFZbTlTHZUGjkcy+7zPWH5xB9fvrfZlP6+ReZd534Dlg1V0G MgoPHcKGQ3CrgLfBurwsCtkAAVM7HMuKQagr/pOrGJPtvP815Hg0Efu9E 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAPS8klCtJV2Y/2dsb2JhbABEgkm4QIhrgQiCHgEBAQICAQEBDwFCGQMIEAIBCBEEAQELFgEGBycLFAkIAgQOBQgTB4dkC5xMoDGLexQOhThhA5cTjT2Ba4JvgVsJFx4 X-IronPort-AV: E=Sophos;i="4.80,695,1344211200"; d="scan'208,217";a="137852567" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 01 Nov 2012 18:22:39 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA1IMc9V005751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 18:22:38 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 13:22:38 -0500 From: "JP Vasseur (jvasseur)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] (no subject) Thread-Index: AQHNt7RXxBNcBUy08k2NlcZzRgkbFg== Date: Thu, 1 Nov 2012 18:22:37 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77220494E0@xmb-rcd-x02.cisco.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.126.73] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--57.319500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77220494E0xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "thierry.lys@erdfdistribution.fr" , "manet@ietf.org" Subject: Re: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:22:56 -0000 --_000_03B78081B371D44390ED6E7BADBB4A77220494E0xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Chris, As I was mentioning in a previous email I will put together some results = =85. it would be nice to also get actual resultant from Load experiment too= . Thanks. JP. On Nov 1, 2012, at 11:10 AM, Dearlove, Christopher (UK) wrote: If I were in charge of requirements, that requirement would be now. Attempt= ing to sway a decision on the basis of "I have results" but not offering th= ose results until the decision is made is not helpful. And the most importa= nt thing is are there any comparisons between the two (or with base AODV)? = Without those, the issue is how do the two differ technically in a manner t= hat matters? -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of JP Vasseur (jvasseur) Sent: 31 October 2012 22:09 To: Jon Black Cc: thierry.lys@erdfdistribution.fr= ; manet@ietf.org Subject: Re: [manet] (no subject) *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. On Oct 31, 2012, at 6:57 PM, Jon Black wrote: On October 31, 2012 Thierry.Lys wrote: I speak in the name of EDF group. We started first to use LOAD as a routing algorithm and deployed 2000 PLC-m= eters for smart grid purposes in 2011. Taking advantage of this field test,= we have been actively participating to the working group to adopt enhancem= ents in the LOADng specification. We are now extremely pleased with what LOADng is capable of and are confide= nt that future deployements will be equipped with it. This would seem to indicate that LOADng does work and in a rather large dep= loyment. JP> No this means that LoadNG works in *a* network. But the major technical= difference here is that reactive routing is highly impacted by the user traffic =85 If you poll a meter every 24 hours, it may work per= fectly well. Now if you start having more frequent traffic flows you can either cache paths (ending up with more frequent broken paths consi= dering how flappy these networks are, thus leading to more floods =85 very undesirable =85 especially when you have hundreds of meters= sharing a few Kbits/s) or you use short cache timers and you keep flooding :-( If you take actual traces of these networks (both using 1= 5.4g and P1901.2) and you start adjusting the user traffic rate you immediately see the issues in terms of scalability. Yes you can try to miti= gate the undesirable flooding effect to some extends but showing the limits in terms of scalability is easy to show. Note that I MOT against= reactive routing by any means, this is IMO just not applicable to LLNs unless the traffic flows are deterministic and very well knows =85 Les= sons from the past show us how difficult it is to predict user applications. We all started with meter reading to continue with that examp= le and now many utilities wants to use these smart metering networks for a number of applications which different SLA, =85 Hope this helps. Once again, when/if required I would be happy to share man= y results. "We believe in rough consensus and running code" rough consensus : Don't you think we have a rough consensus on LOADng compa= red to DYMO ? 10 authors and major companies are supporters of LOADng. running code : interoperability has been checked with 4 sources and other i= mplementations are in progress. Obviously from the list we don't have rough consensus. We have two alterna= tives each with proponents. The WG should weigh the technical benefits (de= sign, implementation/running code, maturity) of each and the group should = choose a path forward. In my opinion option 3 is not an option - this is the working group shirkin= g its responsibility. This is an option =85 since listed by the chairs. I agree that we should av= oid it, especially when I think we have a very reasonable solution (option1). JP. Jon _______________________________________________ manet mailing list manet@ietf.org 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. ******************************************************************** --_000_03B78081B371D44390ED6E7BADBB4A77220494E0xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <45AA09CDAD211F4A9811EE8D3822BD6C@cisco.com> Content-Transfer-Encoding: quoted-printable Hi Chris,

As I was mentioning in a previous email I will put together some resul= ts =85. it would be nice to also get actual resultant from Load experiment = too.

Thanks.

JP.

On Nov 1, 2012, at 11:10 AM, Dearlove, Christopher (UK) wrote:

If I were in charge of requirements, that requirement wou= ld be now. Attempting to sway a decision on the basis of "I have resul= ts" but not offering those results until the decision is made is not helpful. And the most important thing is are t= here any comparisons between the two (or with base AODV)? Without those, th= e issue is how do the two differ technically in a manner that matters?=
 
--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com<= span class=3D"Apple-converted-space"> | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687
 
From:&nbs= p;manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of JP Vasseur= (jvasseur)
Sent: 31 October 2= 012 22:09
To: Jon Black
Cc: thierry.lys@erdfdistribution.fr; manet@ietf.org
Subject: Re: [mane= t] (no subject)
 
 <= /o:p>
*** WARNING ***

This message originates from outside our organisation= , either from an external partner or the internet.
Keep this in mind if y= ou answer this message.
Please see this process on how to de= al with suspicious emails.

 
On Oct 31, 2012, at 6:57 PM, Jon Black wrote:


On October 31, 2012 Thierry.Lys wrote:<= /o:p>
 
I speak in the name of EDF group. 

We started first to use LOAD as a routing algorithm and deploye= d 2000 PLC-meters for smart grid purposes in 2011. Taking advantage of this= field test, we have been actively participating to the working group to adopt enhancements in the LOADng spe= cification. 
We are now extremely pleased with what LOADng is capable of and= are confident that future deployements will be equipped with it. 
 
This would seem to indicate that LOADng does work and in a rather larg= e deployment.
 
JP> No this means that LoadNG works in *a* network. But the major techni= cal difference here is that reactive routing is highly impacted<= /div>
by the user traffic =85 If you poll a meter every 24 hours, it may work per= fectly well. Now if you start having more frequent traffic flows=
you can either cache paths (ending up with more frequent broken paths consi= dering how flappy these networks are, thus leading to more
floods =85 very undesirable =85 especially when you have hundreds of meters= sharing a few Kbits/s) or you use short cache timers and you
keep flooding :-( If you take actual traces of these networks (both using 1= 5.4g and P1901.2) and you start adjusting the user traffic rate you
immediately see the issues in terms of scalability. Yes you can try to miti= gate the undesirable flooding effect to some extends but showing =
the limits in terms of scalability is easy to show. Note that I MOT against= reactive routing by any means, this is IMO just not applicable to
LLNs unless the traffic flows are deterministic and very well knows =85 Les= sons from the past show us how difficult it is to predict user 
applications. We all started with meter reading to continue with that examp= le and now many utilities wants to use these smart metering 
networks for a number of applications which different SLA, =85 
 
Hope this helps. Once again, when/if required I would be happy to share man= y results.
 



"We believe in rough consensus and running code" 

rough consensus : Don't you think we have a rough consensus on LOADng compa= red to DYMO ? 10 authors and major companies are supporters of LOADng. 

running code : interoperability has been checked with 4 sources and other i= mplementations are in progress.

Obviously fr= om the list we don't have rough consensus.  We have two alternatives e= ach with proponents.  The WG should weigh the technical benefits (desi= gn, implementation/running code, maturity)  of each and the group should choose a path forward.

In my opinion option 3 is not an option - this is the working group shirkin= g its responsibility.
 
This is an option =85 since listed by the chairs. I agree that we should av= oid it, especially when I think we have a very reasonable solution
(option1).
 
JP.



Jon
 
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/mane= t
 

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


--_000_03B78081B371D44390ED6E7BADBB4A77220494E0xmbrcdx02ciscoc_-- From charliep@computer.org Thu Nov 1 11:32:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7579521F9289 for ; Thu, 1 Nov 2012 11:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5o9rWGJCVl0 for ; Thu, 1 Nov 2012 11:32:28 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 9E67F21F9288 for ; Thu, 1 Nov 2012 11:32:27 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TTzZ3-0005oK-6D; Thu, 01 Nov 2012 13:32:25 -0500 Message-ID: <5092C033.1030604@computer.org> Date: Thu, 01 Nov 2012 11:32:19 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Don Sturek References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010406050508010704050104" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad861b0fabc827e13e9dce2fbd15eac67049350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:32:36 -0000 This is a multi-part message in MIME format. --------------010406050508010704050104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Don, Your claim has been made several times, and I think it is highly misleading. The bottom line is that the editorship of the WG document is now in good hands, and given the time available in the past, good progress has been made. Also given my renewed emphasis, support from my job, and clear understanding of goals, I can confidently state that I can do the work, and can manage the editorship process to follow working group discussion to completion. Here is (some of) what happened. I hope you will read it. I was asked last fall to resume editorship of the DYMO document, and agreed to do so. Almost at the same time, I was invited to work with the LOADng authors to produce a merged document that incorporated the best features from DYMO and from LOADng. At that time, the general agreement was that the merged document would be renamed AODVv2. Because of various personal difficulties unfamiliar in my experience, I was surprised to find very late in the winter that the merge was not happening. In order to carry out my responsibility, which was clearly to submit a revised document for IETF 83 in Paris, I took the resource available to me and within less than a week I submitted the revised DYMO draft renamed to be AODVv2. People attending the meeting will remember what happened. I was quite unjustly attacked and called names for doing: a) what I said I would do b) what I was supposed to do, and c) changing the document to become more compatible with LOADng, as requested by those authors and according to my best understanding. After that, I still hoped that we could do the merge, but nothing happened until in Vancouver when the WG chairs gave us an ultimatum to make something happen by November. We went around and around, but I eventually determined that there was almost no chance that the LOADng authors would willingly help to produce the desired merge. So I did what the LOADng authors had asked me not to do: namely submit a revised document for consideration. This revised document was an attempt to respond to valid comments made during 2010 about problems with the document while it was under Ian's editorial responsibility. It needs further revision -- in fact I will submit a much more polished document on my website this week. The important point is that for the last year the document languished for all but a few weeks *at the request of the LOADng authors* -- in fact, I would even say at their *DEMAND*, and all the while they refused to help make the merge that (a) they had originally suggested and (b) I was supposed to do. This note is already too long. I have much, much more to say. But I will say one more thing: I have the ability and now the time to do an excellent job on this, and I am here on the job only for the benefit of the working group. Now that I can focus on it, and now that I do not feel constrained to abide by the demands for delay that were imposed by the LOADng author team, I can do it pretty expediently. Of course I will welcome their input as well, and to further reiterate it will be my intention to make the WG document compatible with the needs of LOADng. Oh -- and one more thing... Regardless of the poisoned atmosphere surrounding this debate, I have nothing but high regard for the work done by the LOADng team. I don't think their methods are right for this working group, and any statements to the effect that the DYMO editorial process has been deficient during the last year or more should be understood in light of the above narrative. Regards, Charlie P. PS. Oh, and one more thing... I am a peaceful man, and if I don't respond to all the invective and intransigence so clearly in evidence lately, you'll just have to excuse me for trying to remain so. On 11/1/2012 9:40 AM, Don Sturek wrote: > Hi Adbussalam, > > It is hard to consider a draft stalled 2+ years as the only way > forward in MANET as a reactive protocol. > > Don > > > > From: Abdussalam Baryun > > Date: Thursday, November 1, 2012 8:53 AM > To: Jon Black > > Cc: "manet@ietf.org " >, Stan Ratliff > > Subject: Re: [manet] Reactive Protocol Situation > > Yes LOADng is a reactive protocols, but not the MANET WG reactive > protocol (DYMO is already authorised). The WG is the only authorised > to make such decisions for its WG drafts, if WG decides to add any > LOADng ideas it can, or to accept such merge it can as well, > AB > On Thu, Nov 1, 2012 at 3:37 PM, Jon Black > wrote: > > Why would you think that LOADng is not reactive? If it is not a > reactive protocol, then what is it? > > As to merging the documents, this is what WGs do. If you have > multiple "competing" ideas you ask the authors to see if they can > merge their concepts and ideas. If they cannot or will not then > the WG must decide based on facts and not conjecture which is the > most prudent path to take. > > Jon > > > ------------------------------------------------------------------------ > *From:* Abdussalam Baryun > > *To:* Joseph Macker > > *Cc:* manet@ietf.org ; Stan Ratliff > > > *Sent:* Thursday, November 1, 2012 8:22 AM > > *Subject:* Re: [manet] Reactive Protocol Situation > > Dear Joseph Macker and Stan, > MANET WG Chairs > I disagree that the WG arranged/guided to merge the documents, I > never heard that there was a consensus on such activity. DYMO is a > reactive WG draft, but LOADng is not. Why did you guide to merge > documents, I recommend that you ment to merge the team drafts > co-authors to one WG draft (which is only DYMO so far). The > authority is for the WG to decide to merge individual drafts to > its WG draft. > Therefore, my vote is for option 1 only. Thanking you for updating > us with the status. > Regards > AB > > On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker > > wrote: > > Hello MANET working group (form Stan and Joe), > > As you are all probably aware, there has been WG activity > lately on competing drafts for a MANET reactive protocol - > DYMO (reviving the current working group document that was > parked due to inactivity), and LOADng. Many months ago there > was a somewhat authorship led movement towards a common > document effort and given positive feedback at the time we the > chairs thought this was the best approach given the authors > potential to come together and gain the best of both efforts. > Since that period, there has been some fairly strident and > rancorous "at times" debate between the authors of the two > documents. > > During IETF 84 in Vancouver, the co-chairs held a discussion > with some of the co-authors of the two documents. Our guidance > to the co-authors was to find a way to merge the two documents > into one, as it was perceived that are not technically far > apart and they both derive roughly from AODV concepts and > LOADng had fairly active authorship and implementation > efforts. We provided a co-editing proposal to the authors and > gave them the timeframe of the Atlanta to come up with an > answer back to us regarding this. As of this writing, those > discussions of a potential commonn document and authorship > merger have failed. > > Therefore, we find ourselves at a crossroads. The authors of > the two documents are divided, and it is unlikely that > progress on a merged document can be reached based upon recent > author feedback. I have also polled the earlier WG editor of > DYMO, Ian Chakeres, and he is somewhat disengaged on the issue > at the present time. We see only 3 possible paths forward: > > 1. Continue the work on the DYMO document, starting with > whether there is consensus on its continued approach and also > the desire to rename it to AODVv2. > 2. Replace the existing DYMO document effort with the LOADng > related document effort, defusing ealier references to LLNs as > recommended in the last meeting minutes, and to focus more > motivationally on general MANET problem spaces (the authors > seem to have agreed to this issue if its a WG document). > 3. Remove the working group charter for a reactive protocol, > effectively killing both documents, at least from a working > group (WG) standpoint. This would not be a reflection on the > technology in either case, just an admission that we are not > working together and reaching consensus. > > The co-chairs request and need your opinions on the options. > We have been some silent collecting initial feedback and > waiting for author feedback at this point. Stan and I are > both on travel prior to Atlanta so our responses may be sparse > and we will also likely be in a "receive mode" for a few > days. So send your opinions. > > -Joe > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Regards, Charlie P. --------------010406050508010704050104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello Don,

Your claim has been made several times, and I think it is highly misleading.

The bottom line is that the editorship of the WG document is now in good
hands, and given the time available in the past, good progress has been
made.  Also given my renewed emphasis, support from my job, and clear
understanding of goals, I can confidently state that I can do the work, and
can manage the editorship process to follow working group discussion to
completion.  Here is (some of) what happened.  I hope you will read it.

I was asked last fall to resume editorship of the DYMO document, and
agreed to do so.

Almost at the same time, I was invited to work with the LOADng authors
to produce a merged document that incorporated the best features from
DYMO and from LOADng.  At that time, the general agreement was that
the merged document would be renamed AODVv2.

Because of various personal difficulties unfamiliar in my experience, I was
surprised to find very late in the winter that the merge was not happening.
In order to carry out my responsibility, which was clearly to submit a
revised document for IETF 83 in Paris, I took the resource available to me
and within less than a week I submitted the revised DYMO draft renamed
to be AODVv2.

People attending the meeting will remember what happened.  I was quite
unjustly attacked and called names for doing:
a) what I said I would do
b) what I was supposed to do, and
c) changing the document to become more compatible with LOADng, as
    requested by those authors and according to my best understanding.

After that, I still hoped that we could do the merge, but nothing happened
until in Vancouver when the WG chairs gave us an ultimatum to make
something happen by November.

We went around and around, but I eventually determined that there
was almost no chance that the LOADng authors would willingly help to
produce the desired merge.  So I did what the LOADng authors had asked
me not to do: namely submit a revised document for consideration.
This revised document was an attempt to respond to valid comments
made during 2010 about problems with the document while it was
under Ian's editorial responsibility.  It needs further revision -- in fact
I will submit a much more polished document on my website this
week.

The important point is that for the last year the document languished
for all but a few weeks *at the request of the LOADng authors* --
in fact, I would even say at their *DEMAND*, and all the while they
refused to help make the merge that (a) they had originally suggested
and (b) I was supposed to do.

This note is already too long.  I have much, much more to say.
But I will say one more thing: I have the ability and now the time to
do an excellent job on this, and I am here on the job only for the
benefit of the working group.  Now that I can focus on it, and now
that I do not feel constrained to abide by the demands for delay
that were imposed by the LOADng author team, I can do it pretty
expediently.  Of course I will welcome their input as well, and to
further reiterate it will be my intention to make the WG document
compatible with the needs of LOADng.

Oh -- and one more thing...  Regardless of the poisoned atmosphere
surrounding this debate, I have nothing but high regard for the work
done by the LOADng team.  I don't think their methods are right for
this working group, and any statements to the effect that the DYMO
editorial process has been deficient during the last year or more
should be understood in light of the above narrative.

Regards,
Charlie P.

PS. Oh, and one more thing...  I am a peaceful man, and if I don't
        respond to all the invective and intransigence so clearly
        in evidence lately, you'll just have to excuse me for trying
        to remain so.


On 11/1/2012 9:40 AM, Don Sturek wrote:
Hi Adbussalam,

It is hard to consider a draft stalled 2+ years as the only way forward in MANET as a reactive protocol.

Don



From: Abdussalam Baryun <abdussalambaryun@gmail.com>
Date: Thursday, November 1, 2012 8:53 AM
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@ietf.org>, Stan Ratliff <sratliff@cisco.com>
Subject: Re: [manet] Reactive Protocol Situation

Yes LOADng is a reactive protocols, but not the MANET WG reactive protocol (DYMO is already authorised). The WG is the only authorised to make such decisions for its WG drafts, if WG decides to add any LOADng ideas it can, or to accept such merge it can as well,
AB
On Thu, Nov 1, 2012 at 3:37 PM, Jon Black <jblack.ietf@yahoo.com> wrote:
Why would you think that LOADng is not reactive?  If it is not a reactive protocol, then what is it?

As to merging the documents, this is what WGs do.  If you have multiple "competing" ideas you ask the authors to see if they can merge their concepts and ideas.  If they cannot or will not then the WG must decide based on facts and not conjecture which is the most prudent path to take.

Jon


From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: Joseph Macker <jpmacker@gmail.com>
Cc: manet@ietf.org; Stan Ratliff <sratliff@cisco.com>
Sent: Thursday, November 1, 2012 8:22 AM

Subject: Re: [manet] Reactive Protocol Situation

Dear Joseph Macker and Stan,
MANET WG Chairs
 
I disagree that the WG arranged/guided to merge the documents, I never heard that there was a consensus on such activity. DYMO is a reactive WG draft, but LOADng is not. Why did you guide to merge documents, I recommend that you ment to merge the team drafts co-authors to one WG draft (which is only DYMO so far). The authority is for the WG to decide to merge individual drafts to its WG draft.
 
Therefore, my vote is for option 1 only. Thanking you for updating us with the status.
 
Regards
AB

On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker <jpmacker@gmail.com> wrote:
Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competing drafts for a MANET reactive protocol - DYMO (reviving the current working group document that was parked due to inactivity), and LOADng. Many months ago there was a somewhat authorship led movement towards a common document effort and given positive feedback at the time we the chairs thought this was the best approach given the authors potential to come together and gain the best of both efforts.  Since that period, there has been some fairly strident and rancorous "at times" debate between the authors of the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of the co-authors of the two documents. Our guidance to the co-authors was to find a way to merge the two documents into one, as it was perceived that are not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active authorship and implementation efforts. We provided a co-editing proposal to the authors and gave them the timeframe of the Atlanta to come up with an answer back to us regarding this.  As of this writing, those discussions of a potential commonn document and authorship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two documents are divided, and it is unlikely that progress on a merged document can be reached based upon recent author feedback. I have also polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.  We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is consensus on its continued approach and also the desire to rename it to AODVv2.
2. Replace the existing DYMO document effort with the LOADng related document effort, defusing ealier references to LLNs as recommended in the last meeting minutes, and to focus more motivationally on general MANET problem spaces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively killing both documents, at least from a working group (WG) standpoint. This would not be a reflection on the technology in either case, just an admission that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have been some silent collecting initial feedback and waiting for author feedback at this point.  Stan and I are both on travel prior to Atlanta so our responses may be sparse and we will also likely be in a "receive mode" for a few days.  So send your opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet 

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



-- 
Regards,
Charlie P.
--------------010406050508010704050104-- From jvasseur@cisco.com Thu Nov 1 11:33:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF5E21F861E for ; Thu, 1 Nov 2012 11:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[AWL=0.551, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz55LoM3ZN63 for ; Thu, 1 Nov 2012 11:33:37 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5D53E21F8639 for ; Thu, 1 Nov 2012 11:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25700; q=dns/txt; s=iport; t=1351794800; x=1353004400; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=K83JKgdF+TiQNrb1AfvtVhwfNKgHpEOHc1Ix0XqYRdA=; b=b9ljWQiIE0aVEmwmGNmUwNZX/JL3g1MmOy6zQ7K3DQXHqGkKb8wyFfIH Dk03mKlvnIBVuLGKnGeK2vA/hn1DplpyPg7VCBnvwmQaAYDaTq9lbrLsm Av+V6j9bAzFvq/79D+rY3smFhyxpQQ1p57Lapg3ubVH6H57dnSzscpjiC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAF2/klCtJV2b/2dsb2JhbABEgkmvEJIbgQiCHgEBAQQBAQEPAVsLEAIBCA4DBAEBCxYHBycLEwEJCAIEDgUIEweHUgMPC5xOoCwEixRnhVphA5QnjQODJoFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,695,1344211200"; d="scan'208,217";a="137837092" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 01 Nov 2012 18:33:19 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA1IXJDT009938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 18:33:19 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 13:33:19 -0500 From: "JP Vasseur (jvasseur)" To: Jon Black Thread-Topic: [manet] LOADng works Thread-Index: AQHNuF9dW2UMul6sMEaXNf6TARakEQ== Date: Thu, 1 Nov 2012 18:33:19 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> In-Reply-To: <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.126.73] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--56.784100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722049540xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:33:38 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7722049540xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jon, In line - JP2> On Nov 1, 2012, at 4:32 PM, Jon Black wrote: ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: "manet@ietf.org" >; "thierry.lys@erdfdistribution.fr" > Sent: Thursday, November 1, 2012 3:41 AM Subject: Re: [manet] (no subject) Hi Jon, On Nov 1, 2012, at 12:39 AM, Jon Black wrote: Yes it shows that it does work in a rather large deployment. JP> This is not just a question of "how large" it is =85 but also how dynam= ic. I could show you few hundreds (if not less number of nodes) not working if the traffic pattern is too dynamic. This is a fundamental pr= oblem. [Jon] Are you saying that their AMI PLC deployment was not dynamic? JP2> We do not have any details so I cannot comment on *that* deployment; m= y point was that you can easily show why the number of nodes is NOT the only issues with reactive routing protocols in LLNs. Ta= ke actual traces (which I personally did with actual deployed networks) and simulate the control plane traffic with moderate use traffic = demand and you will see the issue with such routing approach. In other words, even with a relatively small number of nodes, in contrast w= ith other proactive routing protocols, if the user traffic is moderate (not even very high), you clearly see why this reactive routing is ill suit= ed to LLNs. I have heard others say that it works in other deployments as well - just t= he same as you say RPL works in some deployments. JP> I do not not think that we should go in a RPL versus Load-NG debate but= rather try to find a good solution for MANET. That being said, RPL *for* LLNs the the result of a 4-year work with a DT, weekly call= s, interim WG meetings to make it work in LLNs. [Jon] I did not cast this as a RPL vs LOADng debate - you just did. I am s= aying that LOADng works in some scenarios and proof is the EDF deployment i= n their AMI network. JP2> I would be happy to see detailed results and especially the user traff= ic profiles for the reason exposed above. Please share your results. You keeps saying you will and you we keep askin= g you to - where's the results so they can be reviewed. JP> Once again, I would first like to hear chair's decision. PLEASE note th= at I would be happy to see Load's results too. And just be patient, I just need to find a bit of time to compile results and you will = get many results backing up my claims. Please also refer to the number of discussions prior to designing RPL that took place on the ROLL ma= iling list. Believe me there was a reason not NOT choosing a reactive protocol for LLN (again I am NOT against reactive routing for ot= her use cases at all). Would you ignore the findings of a WG that worked for 4 years on the subject matter ? I guess not =85 Just trying= to raise my voice (as many others on this list) to protect the Internet. [Jon] As others have said - you have it backwards. If you have data that w= ould show that LOADng or a reactive protocol will not work in MANETs please= share it. JP2> Please reread what I wrote ten times =85 I said "LLNs" not "MANET" in = general. On top of that, I do prefer the option 1) for the reasons exposed before (this is the WG document, Charlie made it compatible + other technic= al reasons). That would be very insightful and would help guide this discussion and decision. It woul= d not be prudent to make a decision and then bring out data that would try = to suggest that the decision was incorrect. What findings are you referring to? Where is there a WG document that docu= ments these findings? Thanks. JP. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: "manet@ietf.org" >; "thierry.lys@erdfdistribution.fr" > Sent: Wednesday, October 31, 2012 4:09 PM Subject: Re: [manet] (no subject) On Oct 31, 2012, at 6:57 PM, Jon Black wrote: On October 31, 2012 Thierry.Lys wrote: I speak in the name of EDF group. We started first to use LOAD as a routing algorithm and deployed 2000 PLC-m= eters for smart grid purposes in 2011. Taking advantage of this field test,= we have been actively participating to the working group to adopt enhancem= ents in the LOADng specification. We are now extremely pleased with what LOADng is capable of and are confide= nt that future deployements will be equipped with it. This would seem to indicate that LOADng does work and in a rather large dep= loyment. JP> No this means that LoadNG works in *a* network. But the major technical= difference here is that reactive routing is highly impacted by the user traffic =85 If you poll a meter every 24 hours, it may work per= fectly well. Now if you start having more frequent traffic flows you can either cache paths (ending up with more frequent broken paths consi= dering how flappy these networks are, thus leading to more floods =85 very undesirable =85 especially when you have hundreds of meters= sharing a few Kbits/s) or you use short cache timers and you keep flooding :-( If you take actual traces of these networks (both using 1= 5.4g and P1901.2) and you start adjusting the user traffic rate you immediately see the issues in terms of scalability. Yes you can try to miti= gate the undesirable flooding effect to some extends but showing the limits in terms of scalability is easy to show. Note that I MOT against= reactive routing by any means, this is IMO just not applicable to LLNs unless the traffic flows are deterministic and very well knows =85 Les= sons from the past show us how difficult it is to predict user applications. We all started with meter reading to continue with that examp= le and now many utilities wants to use these smart metering networks for a number of applications which different SLA, =85 Hope this helps. Once again, when/if required I would be happy to share man= y results. "We believe in rough consensus and running code" rough consensus : Don't you think we have a rough consensus on LOADng compa= red to DYMO ? 10 authors and major companies are supporters of LOADng. running code : interoperability has been checked with 4 sources and other i= mplementations are in progress. Obviously from the list we don't have rough consensus. We have two alterna= tives each with proponents. The WG should weigh the technical benefits (de= sign, implementation/running code, maturity) of each and the group should = choose a path forward. In my opinion option 3 is not an option - this is the working group shirkin= g its responsibility. This is an option =85 since listed by the chairs. I agree that we should av= oid it, especially when I think we have a very reasonable solution (option1). JP. Jon _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7722049540xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3437373530BC2242B802466B088A7E18@cisco.com> Content-Transfer-Encoding: quoted-printable Hi Jon,

In line - JP2>

On Nov 1, 2012, at 4:32 PM, Jon Black wrote:



From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@ietf.org>; "thierry.lys@erdfdistribution.fr" <thierry.lys@erdfdistribution.fr>
Sent: Thursday, November 1= , 2012 3:41 AM
Subject: Re: [manet] (no s= ubject)

Hi Jon,

On Nov 1, 2012, at 12:39 AM, Jon Black wrote:

Yes it shows that it does work in a rather large deployment.&nbs= p;

JP> This is not just a question of "how large" it is =85 = but also how dynamic. I could show you few hundreds (if not less number of = nodes)
not working if the traffic pattern is too dynamic. This is a fundament= al problem.

[Jon] Are you saying that their AMI PLC deployment was not dynamic?

JP2> We do not have any details so I cannot comment on *that* deplo= yment; my point was that you can easily show why the number
of nodes is NOT the only issues with reactive routing protocols in LLN= s. Take actual traces (which I personally did with actual deployed
networks) and simulate the control plane traffic with moderate use tra= ffic demand and you will see the issue with such routing approach.
In other words, even with a relatively small number of nodes, in contr= ast with other proactive routing protocols, if the user traffic is moderate=
(not even very high), you clearly see why this reactive routing is ill= suited to LLNs.


I have heard others say that it works in other deployments as we= ll - just the same as you say RPL works in some deployments.


JP> I do not not think that we should go in a RPL versus Load-NG de= bate but rather try to find a good solution for MANET. That being
said, RPL *for* LLNs the the result of a 4-year work with a DT, weekly= calls, interim WG meetings to make it work in LLNs.

[Jon] I did not cast this as a RPL vs LOADng debate - you just did.  I= am saying that LOADng works in some scenarios and proof is the EDF deploym= ent in their AMI network.

JP2> I would be happy to see detailed results and especially the us= er traffic profiles for the reason exposed above.


Please share your results.  You keeps saying you will and you we= keep asking you to - where's the results so they can be reviewed.


JP> Once again, I would first like to hear chair's decision. PLEASE= note that I would be happy to see Load's results too. And just be
patient, I just need to find a bit of time to compile results and you = will get many results backing up my claims. Please also refer to the
number of discussions prior to designing RPL that took place on the RO= LL mailing list. Believe me there was a reason not NOT choosing
a reactive protocol for LLN (again I am NOT against reactive routing f= or other use cases at all). Would you ignore the findings of a WG
that worked for 4 years on the subject matter ? I guess not =85 Just t= rying to raise my voice (as many others on this list) to protect the
Internet.

[Jon] As others have said - you have it backwards.  If you have data t= hat would show that LOADng or a reactive protocol will not work in MANETs p= lease share it. 

JP2> Please reread what I wrote ten times =85 I said "LLNs&quo= t; not "MANET" in general. On top of that, I do prefer the option= 1) for the reasons exposed 
before (this is the WG document, Charlie made it compatible + othe= r technical reasons).

That would be
very insightful and would help guide this discussion and decision.  It= would not be prudent to make a decision and then bring out data that would= try to suggest that the decision was incorrect.

What findings are you referring to?  Where is there a WG document that= documents these findings?

Thanks.

JP.

Jon


From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@i= etf.org>; "thierr= y.lys@erdfdistribution.fr" <thierry.lys@erdfdistribution.fr>
Sent: Wednesday, October 31= , 2012 4:09 PM
Subject: Re: [manet] (no su= bject)


On Oct 31, 2012, at 6:57 PM, Jon Black wrote:

On October 31, 2012 Thierry.Lys wrote:

I speak in the name of EDF group.

We started first to use LOAD as a rout= ing algorithm and deployed 2000 PLC-meters for smart grid purposes in 2011.= Taking advantage of this field test, we have been actively participating t= o the working group to adopt enhancements in the LOADng specification.
We are now extremely pleased with what= LOADng is capable of and are confident that future deployements will be eq= uipped with it. 

This would seem to indicate that LOADng does work and in a rather large dep= loyment.

JP> No this means that LoadNG works in *a* network. But the major t= echnical difference here is that reactive routing is highly impacted
by the user traffic =85 If you poll a meter every 24 hours, it may wor= k perfectly well. Now if you start having more frequent traffic flows
you can either cache paths (ending up with more frequent broken paths = considering how flappy these networks are, thus leading to more
floods =85 very undesirable =85 especially when you have hundreds of m= eters sharing a few Kbits/s) or you use short cache timers and you
keep flooding :-( If you take actual traces of these networks (both us= ing 15.4g and P1901.2) and you start adjusting the user traffic rate you
immediately see the issues in terms of scalability. Yes you can try to= mitigate the undesirable flooding effect to some extends but showing =
the limits in terms of scalability is easy to show. Note that I MOT ag= ainst reactive routing by any means, this is IMO just not applicable to
LLNs unless the traffic flows are deterministic and very well knows = =85 Lessons from the past show us how difficult it is to predict user =
applications. We all started with meter reading to continue with that = example and now many utilities wants to use these smart metering 
networks for a number of applications which different SLA, =85 

Hope this helps. Once again, when/if required I would be happy to shar= e many results.



"We believe in rough consensus an= d running code"

rough consensus : Don't you think we h= ave a rough consensus on LOADng compared to DYMO ? 10 authors and major com= panies are supporters of LOADng.

running code : interoperability has be= en checked with 4 sources and other implementations are in progress.

Obviously from the list we don't ha= ve rough consensus.  We have two alternatives each with proponents.&nb= sp; The WG should weigh the technical benefits (design, implementation/runn= ing code, maturity)  of each and the group should choose a path forward.

In my opinion option 3 is not an option - this is the working group shirkin= g its responsibility.

This is an option =85 since listed by the chairs. I agree that we shou= ld avoid it, especially when I think we have a very reasonable solution
(option1).

JP.


Jon

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet






_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A7722049540xmbrcdx02ciscoc_-- From abdussalambaryun@gmail.com Thu Nov 1 11:33:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C9521F8E2C for ; Thu, 1 Nov 2012 11:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=-0.673, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7rLXKDu1ZS6 for ; Thu, 1 Nov 2012 11:33:51 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 779AB21F8E16 for ; Thu, 1 Nov 2012 11:33:51 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3356901vbb.31 for ; Thu, 01 Nov 2012 11:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Mfj4ZzntXqc+XAzfx2nN0eDLZe0o6k0zLTbt3Ag+VoI=; b=kUxLpO+541Y5Y1Z3lsktmKDqv6CuR7jRlyoUVTtSzgMymzPYf6IlWSzZdpLv3muSZ7 uAVybrNiQJStUgLCynVWrYmiOaae6yEGzgF5S6Pj4bwHlMMwOcCTKG703bIyxI+lkJu8 d7OvH5BY7WD8OJAD5DB8pQNYKGYMSbzc25AWscU0eeo/NRhZC/69Mz3jbMLIzJ06wbwm U2u11AJ/AbnJim92BY97o1Jo9749/t9Z2NTkcWVuMxs4AXAY8dc4jyoinKBLaSb/ENru pLvgUcXsM9mzGaas4Jkia4PqPgWTLiuer0lJbJbZfvNd+Dk6+8RktIIJDA9TsRXCA1Lo jIjA== MIME-Version: 1.0 Received: by 10.52.90.99 with SMTP id bv3mr51793684vdb.125.1351794830789; Thu, 01 Nov 2012 11:33:50 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 11:33:50 -0700 (PDT) In-Reply-To: References: <50902CF3.9070903@computer.org> Date: Thu, 1 Nov 2012 18:33:50 +0000 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=20cf307f3bccb2cdde04cd7342f5 Cc: manet Subject: Re: [manet] Flooding: how to make a normative reference? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:33:53 -0000 --20cf307f3bccb2cdde04cd7342f5 Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas, Ok, I understand your point, but I thought that RFC6621 is a routing protocol not a flooding. So we can consider multicast forwarding as a special flooding for OLSRv2-MPR, and AODVv2. I will look into it again. thanks, AB On Thu, Nov 1, 2012 at 4:20 PM, Thomas Heide Clausen wrote: > You know of RFC6621, yes? > > > -- > Thomas Heide Clausen > http://www.thomasclausen.org > > "Today's scientists have substituted mathematics for > experiments, and they wander off through equation > after equation, and eventually build a structure > which has no relation to reality." > - Nikola Tesla, > Modern Mechanics and Inventions, July, 1934 > > On 1 nov. 2012, at 16:41, Abdussalam Baryun > wrote: > > It will be interesting to have the flooding algorithm I-D as you mentioned > so we can refer by MANET protocols, but also I support that OLSRv2 has no > need to take out such technique (as chris mentioned). However, your > suggestion will give more flexibility to AODVv2 as a MANET protocol. > > I also agree that AODVv2 should not reference OLSRv2 as normative for your > mentioned reasons. > > AB > > On Tue, Oct 30, 2012 at 7:39 PM, Charles E. Perkins > wrote: > >> >> Hello folks, >> >> I think it is well recognized that brute force flooding often leads to >> poor performance in ad hoc networks with many nodes. Thus, we >> have RFC 6621 to describe various other approaches. Plus, we have >> MPR flooding as described in the OLSRv2 document. >> >> For reactive, it is quite important to enable "better" algorithms >> for flooding. AODVv2 could quite reasonable use a MPR-based >> flooding, or flooding based over any connected dominating set. >> >> It seems wrong to have AODVv2 cite OLSRv2 in any normative >> fashion, just to get access to the MPR flooding mechanism which >> can run independently of the routing protocol (and, perhaps, >> should do so). It also seems wrong to cite RFC 6621 in any >> normative fashion since that is an Experimental specification. >> >> Don't we need to have some Proposed Standard documents that >> specify more scalable approaches to flooding, that are independent >> of routing protocols? >> >> I guess it's too late to suggest that the MPR specification should >> be pulled out of OLSRv2 for this purpose... >> >> I looked back for some discussion about this on the list, but I >> didn't find it, but my search was hardly exhaustive. >> >> -- >> Regards, >> Charlie P. >> >> ______________________________**_________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/**listinfo/manet >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --20cf307f3bccb2cdde04cd7342f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,
=A0
Ok, I understand your point, but I = thought that RFC6621 is a=A0routing protocol not a flooding. So we can=A0co= nsider multicast forwarding as a special flooding for=A0OLSRv2-MPR, and AOD= Vv2.=A0I will look into it again.=A0 thanks,
=A0
AB

On Thu, Nov 1= , 2012 at 4:20 PM, Thomas Heide Clausen <ietf@thomasclausen.org&g= t; wrote:
You know of RFC6621, yes?


--=A0
Thomas Heide Clausen

=A0=A0experiments, and they wander off through equation=A0
= =A0=A0after equation, and eventually =A0build a structure=A0
=A0= =A0which has no relation to reality."
=A0- Nikola Tesla,=A0<= /div>
=A0=A0 =A0Modern Mechanics and Inventions, July, 1934
It will be interesting to have the flooding algorithm I-D as you = mentioned so we can refer by MANET protocols, but also I support that OLSRv= 2 has no need to take out such technique (as chris mentioned). However, you= r suggestion=A0will give more flexibility to AODVv2 as a MANET protocol.
=A0
I also agree that AODVv2 should not reference OLSRv2 as = normative for your mentioned reasons.
=A0
AB

On Tue, Oct 30, 2012 at 7:39 PM, Charles E. P= erkins <charliep@computer.org> wrote:

Hello folks,

I think it is well recognized that brute force flooding often leads to
poor performance in ad hoc networks with many nodes. =A0Thus, we
have RFC 6621 to describe various other approaches. =A0Plus, we have
MPR flooding as described in the OLSRv2 document.

For reactive, it is quite important to enable "better" algorithms=
for flooding. =A0AODVv2 could quite reasonable use a MPR-based
flooding, or flooding based over any connected dominating set.

It seems wrong to have AODVv2 cite OLSRv2 in any normative
fashion, just to get access to the MPR flooding mechanism which
can run independently of the routing protocol (and, perhaps,
should do so). =A0It also seems wrong to cite RFC 6621 in any
normative fashion since that is an Experimental specification.

Don't we need to have some Proposed Standard documents that
specify more scalable approaches to flooding, that are independent
of routing protocols?

I guess it's too late to suggest that the MPR specification should
be pulled out of OLSRv2 for this purpose...

I looked back for some discussion about this on the list, but I
didn't find it, but my search was hardly exhaustive.

--
Regards,
Charlie P.

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

___________________= ____________________________
manet mailing list
<= span>manet@ietf.org=
https://www.ietf.org/mailman/listinfo/manet

--20cf307f3bccb2cdde04cd7342f5-- From jvasseur@cisco.com Thu Nov 1 11:36:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7900D21F92DF for ; Thu, 1 Nov 2012 11:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.148 X-Spam-Level: X-Spam-Status: No, score=-10.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKrSzyM02J2X for ; Thu, 1 Nov 2012 11:36:27 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id ACD8221F92C4 for ; Thu, 1 Nov 2012 11:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26194; q=dns/txt; s=iport; t=1351794986; x=1353004586; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=e7VjnxDMtGN0i24kjn84BmlnSlZWmzaWKuT92t8vyXw=; b=P3C/EUKFl07aH2srksXr7LtsfL/SGQw33PbxvkUWcFbukLTbtcp4pWc/ WyfgixKnFw+ceXj2vXA0mbzi2Ekv/RNyv1tOsnvDR9lyhvcNDFtxHCJvI 9h1SXJVJwIJjbWBco6RWjVf3oKcY/oxAYZFiMw33htmQQ1cdE4lKZR11r U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFPAklCtJXG9/2dsb2JhbABEgknBK4EIgh4BAQECAgEBAQ8BQhcCAwUDEAIBCA4DBAEBCxYHByEGCxQJCAIEDgUIEweHUgMPC5xOlk0NiVSLFGcSAg6FOGEDiCWLfoJwiheDJoFrgm+BWwkXHg X-IronPort-AV: E=Sophos;i="4.80,695,1344211200"; d="scan'208,217";a="137640401" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 01 Nov 2012 18:36:26 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA1IaPne018604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 18:36:26 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 13:36:25 -0500 From: "JP Vasseur (jvasseur)" To: Jon Black Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNt0HGLPVi/cSo/ES1hdb7zda62w== Date: Thu, 1 Nov 2012 18:36:24 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722049577@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com> <1351784668.10346.YahooMailNeo@web160601.mail.bf1.yahoo.com> In-Reply-To: <1351784668.10346.YahooMailNeo@web160601.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.126.73] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--64.990400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722049577xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: manet Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:36:30 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7722049577xmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Nov 1, 2012, at 4:44 PM, Jon Black wrote: I disagree. The protocol has progressed. It appears that there are implem= entations. There is interoperability. There are deployments. This is all= progress. I'm not favoring LOADng over DYMO. I think the working group should look a= t both fairly and decide the best path forward - chose one over the other o= r find a way to merge the concepts even if the authors are hesitant. Right and I think that this was what the chairs asked us to do: express our= opinion on which option we prefer. Let's wait until everybody express an opinion and see what the chairs think= . Thanks. JP. Jon ________________________________ From: Abdussalam Baryun > To: manet > Sent: Thursday, November 1, 2012 8:28 AM Subject: Re: [manet] Reactive Protocol Situation On Wed, Oct 31, 2012 at 10:02 AM, Dearlove, Christopher (UK) > wrote: As someone who has not (yet) stated an opinion on the matter, except I also= think option 3 is not good, I would very much like to hear technical argum= ents, so if you have technical arguments against LOADng, I think we need to= hear them rather than just suggesting they exist. I haven't yet read LOADn= g carefully to form a view there. I have just recently read the AODVv2 draf= t carefully, and have some technical issues there (which overlap) regarding= asymmetric links, possible dependency on NHDP, and the compatibility of op= tions. If option 1 is followed, the draft needs work (which Charlie has ack= nowledged). I don't think we have time to waste with LOADng, it was presented twice and= no progress, the authors failed to discuss on MANET list, and failed to up= date the draft to match MANET reuirements. I agree that we focus our effort= s to submit AODVv2 as soon as possible, AB -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of JP Vasseur (jv= asseur) Sent: 31 October 2012 08:29 To: Joseph Macker Cc: > Subject: Re: [manet] Reactive Protocol Situation *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Dear chairs, Remembering that I am not a co-authors of either of these drafts. Not commenting on recent discussions but rather focussing on what I hope wi= ll be a good solution for the WG and the Internet at large. Option 3) is my opinion not desirable; I wish we could have a reactive rout= ing protocol for MANET Option 2) is an option I would be strongly opposed to for a number of techn= ical reasons that I would be happy to elaborate on the mailing list and/or in a new I-D (which I would, should option 2 be chosen)= . That being said, I am extremely supportive of option 1), especially in ligh= t of what Charlie said. First of all DYMO is the working group document and excellent progress has been made with recent revisions. But ev= en more importantly, Charlie managed to make it compatible with options, which is in my opinion the best of both worlds; calling it AO= DVv2 is only not very sensible but avoids useful sensitivity around names. Thus I would strongly support Option 1), continue the work that Charlie has= started, which by the way is not far from completion. And as WG,we need to remember that this had been the WG document, the result of= years of work. Still by making it compatible with other options, this is technically flexible and sound. Thanks. JP. On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote: Hello MANET working group (form Stan and Joe), As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common documen= t effort and given positive feedback at the time we the chairs thought this= was the best approach given the authors potential to come together and gai= n the best of both efforts. Since that period, there has been some fairly = strident and rancorous "at times" debate between the authors of the two doc= uments. During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts = and LOADng had fairly active authorship and implementation efforts. We prov= ided a co-editing proposal to the authors and gave them the timeframe of th= e Atlanta to come up with an answer back to us regarding this. As of this = writing, those discussions of a potential commonn document and authorship m= erger have failed. Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss= ue at the present time. We see only 3 possible paths forward: 1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2. 2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document). 3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus. The co-chairs request and need your opinions on the options. We have been = some silent collecting initial feedback and waiting for author feedback at = this point. Stan and I are both on travel prior to Atlanta so our response= s may be sparse and we will also likely be in a "receive mode" for a few da= ys. So send your opinions. -Joe _______________________________________________ manet mailing list manet@ietf.org 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. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7722049577xmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Nov 1, 2012, at 4:44 PM, Jon Black wrote:

I disagree.  The protocol has progressed.  It appears that there = are implementations.  There is interoperability.  There are deplo= yments.  This is all progress.

I'm not favoring LOADng over DYMO.  I think the working group should l= ook at both fairly and decide the best path forward - chose one over the ot= her or find a way to merge the concepts even if the authors are hesitant.

Right and I think that this was what the chairs asked us to do: expres= s our opinion on which option we prefer.
Let's wait until everybody express an opinion and see what the chairs = think.

Thanks.

JP.



Jon


From: Abdussalam Baryun <= ;abdussalambaryun@gmail.com>
To: manet <manet@ietf.org>
Sent: Thursday, November 1= , 2012 8:28 AM
Subject: Re: [manet] React= ive Protocol Situation

On Wed, Oct 31, 2012 at 10:02 AM, Dea= rlove, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:
As someone who has not (yet) stated an opinion on the matter,= except I also think option 3 is not good, I would very much like to hear t= echnical arguments, so if you have technical arguments against LOADng, I think we need to hear them rather than just su= ggesting they exist. I haven't yet read LOADng carefully to form a view the= re. I have just recently read the AODVv2 draft carefully, and have some tec= hnical issues there (which overlap) regarding asymmetric links, possible dependency on NHDP, and the compatibi= lity of options. If option 1 is followed, the draft needs work (which Charl= ie has acknowledged).
 
 
I don't think we have time to waste with LOADng, it was presented twic= e and no progress, the authors failed to discuss on MANET list, and failed = to update the draft to match MANET reuirements. I agree that we focus our e= fforts to submit AODVv2 as soon as possible,
 
AB
 
 
 
--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 = |  Fax: +44 1245 242124
chris.dearlove@baes= ystems.com | http://www.baesystems.com

BAE Systems (Op= erations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687
 
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur)
Sent: 31 October 2012 08:29
To: Joseph Macker
Cc: <manet@ietf.org>
Subject: Re: [manet] Reactive Protocol Situation
 
 
*** WARNING ***<= /u>
This message orig= inates from outside our organisation, either from an external partner or th= e internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.
Dear chairs,
 
Remembering that I am not a co-authors = of either of these drafts.
 
Not commenting on recent discussions= but rather focussing on what I hope will be a good solution for the WG and= the Internet at large.
 
Option 3) is my opinion not desirable; I wish we could have a reactive routing protocol for MANET=
 
Option 2) is an option I would be strongly opposed to for a number of technical reasons that I would= be happy to elaborate on the
mailing list and/or in a new I-D (which= I would, should option 2 be chosen).
 
That being said, I am extremely supp= ortive of option 1), especially in light of what Charlie said. First of all DYMO is the w= orking group
document and excellent progress has bee= n made with recent revisions. But even more importantly, Charlie managed to= make it compatible 
with options, which is in my opini= on the best of both worlds; calling it AODVv2 is only not very sensi= ble but avoids useful sensitivity around 
names.
 
Thus I would strongly support Option= 1), continue the work that Charlie has started, which by the way is no= t far from completion. And 
as WG,we need to remember that this had= been the WG document, the result of years of work. Still by making it comp= atible with other options, 
this is technically flexible and sound.=
 
Thanks.
 
JP.
 
On Oct 31, 2012, at 12:13 AM, Joseph Ma= cker wrote:


Hello MANET working group (form Stan an= d Joe),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.  Sin= ce that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active author= ship and implementation efforts. We provided a co-editing proposal to the a= uthors and gave them the timeframe of the Atlanta to come up with an answer= back to us regarding this.  As of this writing, those discussions of a potential commonn document and aut= horship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.  We s= ee only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have = been some silent collecting initial feedback and waiting for author feedbac= k at this point.  Stan and I are both on travel prior to Atlanta so ou= r responses may be sparse and we will also likely be in a "receive mode" for a few days.  So send your= opinions.

-Joe
_______________________________________________
manet mailing list
manet@ietf.org
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.
********************************************************************


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@i= etf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



--_000_03B78081B371D44390ED6E7BADBB4A7722049577xmbrcdx02ciscoc_-- From abdussalambaryun@gmail.com Thu Nov 1 11:37:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE4E21F8582 for ; Thu, 1 Nov 2012 11:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P++YBAuO62be for ; Thu, 1 Nov 2012 11:37:52 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2999D21F92EE for ; Thu, 1 Nov 2012 11:37:47 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3361397vbb.31 for ; Thu, 01 Nov 2012 11:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CoUCVZYlFqb4wmwdgWCTuCSEJHqVYNV2721Qa3b/enc=; b=yC86opQoRgTlZoszphVBuPgFSoWnjC7FgiJKTzfi32R7VrIyDGJILc5wBuFsHuByrJ JVKyf3BQad6tHCKApB9fWi+x+euj7S1RS+/GRebAv5MnWlkyEYypFHSAnJxUA/c68Yxb X7WGnS4/n0cC9bkanCEjbA3ECG2fMSoyGy0XGEvbiueixU7rw7mriI9hl7pXbdNanONK iRW8C4OvuEXKtxZaOC5cinAUOBh9q+UKULL0/dGiytvtIHFFtRTv+3DlE9gainf3ZPnA qyW8oZhZERViMuHZAoUeX4ECYW4N30mY7qrrZ1DEC8skjF428oNvwUpTzcVjJAgf4swf iprQ== MIME-Version: 1.0 Received: by 10.52.35.82 with SMTP id f18mr51701616vdj.99.1351795066700; Thu, 01 Nov 2012 11:37:46 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 11:37:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Nov 2012 18:37:46 +0000 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: multipart/alternative; boundary=20cf307c9fbec2820a04cd735058 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:37:53 -0000 --20cf307c9fbec2820a04cd735058 Content-Type: text/plain; charset=ISO-8859-1 Thanks Ulrich, I agree and would like to know your opinion on this subject and other co-authors so we can have a progress discussion on the manet-list. I will do the same. AB On Thu, Nov 1, 2012 at 5:54 PM, Ulrich Herberg wrote: > Chris, > > I think this is a good start to have a technical discussion. I hope that > everyone could thoroughly *read* both documents and give a technical > opinion. I will read the latest DYMO revision in detail and then answer to > your email. > > Best regards > Ulrich > > On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK) < > Chris.Dearlove@baesystems.com> wrote: > >> The obviously best people to answer this should be document authors, but >> anyone else may have useful additions and comments. Ideally the different >> document authors could agree a list. (If they differ in that one has X and >> the other doesn't, but one wants to say "we plan to add/remove X" then X >> should be listed as a difference with that caveat, in at least my ideal >> world.) >> >> If we set aside, for the moment (though these things matter): >> - The presentational quality of the documents, >> - Any issues of 5444 compliance and other formatting issues, >> - Issues of internal data organisation, >> - Minor details such as possible different timeout parameters etc. >> then what are the technical (and I stress that word) differences between >> DYMO and LOADng? (I'm withholding the term AODVv2 for reasons I may come >> back to.) >> >> Note that it's a lot more useful to have direct differences than >> differences of each from AODV (especially when both have the same >> difference). And it would be useful to have the objective differences >> separated from the "and now why this is better" discussion - though that >> would be a next step. >> >> I'm not saying I don't see any of the differences. But I certainly >> haven't worked out the complete list. In trying to form my view of how >> things should go forward (a view that is coming together, and when it does, >> I'll argue for it) and I hope for other people as well, it would be good to >> know what the differences are. Regardless of views for or against each, we >> should be able to objectively list the significant differences - if we >> can't then something is wrong. >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> >> ******************************************************************** >> 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. >> ******************************************************************** >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --20cf307c9fbec2820a04cd735058 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Ulrich, I agree and would like to know your opinion on this sub= ject and other co-authors so we can have a progress discussion on the manet= -list. I will do the same.
=A0
AB

On Thu, Nov 1, 2012 at 5:54 PM, Ulrich Herberg <ulrich@herberg.name&= gt; wrote:
Chris,

I think this is a good start to have a technical = discussion. I hope that everyone could thoroughly *read* both documents and= give a technical opinion. I will read the latest DYMO revision in detail a= nd then answer to your email.

Best regards
Ulrich

On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:
The obviously best people to = answer this should be document authors, but anyone else may have useful add= itions and comments. Ideally the different document authors could agree a l= ist. (If they differ in that one has X and the other doesn't, but one w= ants to say "we plan to add/remove X" then X should be listed as = a difference with that caveat, in at least my ideal world.)

If we set aside, for the moment (though these things matter):
- The presentational quality of the documents,
- Any issues of 5444 compliance and other formatting issues,
- Issues of internal data organisation,
- Minor details such as possible different timeout parameters etc.
then what are the technical (and I stress that word) differences between DY= MO and LOADng? (I'm withholding the term AODVv2 for reasons I may come = back to.)

Note that it's a lot more useful to have direct differences than differ= ences of each from AODV (especially when both have the same difference). An= d it would be useful to have the objective differences separated from the &= quot;and now why this is better" discussion - though that would be a n= ext step.

I'm not saying I don't see any of the differences. But I certainly = haven't worked out the complete list. In trying to form my view of how = things should go forward (a view that is coming together, and when it does,= I'll argue for it) and I hope for other people as well, it would be go= od to know what the differences are. Regardless of views for or against eac= h, we should be able to objectively list the significant differences - if w= e can't then something is wrong.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0| =A0Fax: +44 1245 242124
chris.de= arlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687



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

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--20cf307c9fbec2820a04cd735058-- From d.sturek@att.net Thu Nov 1 11:40:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14C721F9318 for ; Thu, 1 Nov 2012 11:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sL483Jnmwa7 for ; Thu, 1 Nov 2012 11:40:08 -0700 (PDT) Received: from nm17-vm0.access.bullet.mail.mud.yahoo.com (nm17-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.21]) by ietfa.amsl.com (Postfix) with ESMTP id F217821F9329 for ; Thu, 1 Nov 2012 11:40:07 -0700 (PDT) Received: from [66.94.237.201] by nm17.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Nov 2012 18:40:07 -0000 Received: from [98.139.221.50] by tm12.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Nov 2012 18:40:07 -0000 Received: from [127.0.0.1] by smtp103.sbc.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 18:40:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1351795207; bh=Vp+fifi4UuNmfDZHj0yajZ7951YFH0KX8h0vbwaMrjc=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=MJBHZmkwQ1GWPojYJ096AaIyg5IGHI49it7wQeo6xJhekIub4bepgL//2U2TGLthJ+QxJ6n0HX+cAvNbG8A+2/YxG4wq2Vg0MM8kK0/hw6KfgorZDWzZWn3TULyTnYWVjqg2npezwMz2RAX2jnRWvd0myT9icpzRtz6663vkddo= X-Yahoo-Newman-Id: 303626.31013.bm@smtp103.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: PSIacWUVM1lqHMMcDbznho3kft7iMzvVz9VgXG8pRC_kTpa 7IoQP6NJ7DvFSpOnZ8dXlgtA24nkBTG65RmjyrS9KgbCBNg_s292ZjKdUjUT O3QvH6bamnTfE6CheJhrS8LWNwOUpm3l6LYNqPqZIicZ2q1VlgDh7erWXArx FRz8V8dly9LpKe.KTk9zGIYOAWm8BmTU1NCkfeWujTeQVVWT2MR.iBiFTT.4 7ZxlYqzUAxKXy2jzVIDD9AUHdN.LWPYMgzemzWM_tVCT4__Wt0pCD1ar6dGD YQEUqAQ1UeGdPAIf8hpyjkgvkQ1O9pKhi_qu6KvdifM7WvoDgKNq4XFxKvL4 OcRA.JuZKOue0e0OzIz3.OnJHt_j_n2ShI0fIVKgcUf9UQcP51s8ux3ngCOx 019aLYr1LYdF7WjkeOjlSI5PrlXEQTtve74jxIAHURhPZvROG9WBEtgCmCPu XzlQ.qEAGYQ5sVgp4 X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.135] (d.sturek@66.27.60.174 with login) by smtp103.sbc.mail.bf1.yahoo.com with SMTP; 01 Nov 2012 11:40:07 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 01 Nov 2012 11:40:03 -0700 From: Don Sturek To: "Charles E. Perkins" Message-ID: Thread-Topic: [manet] Reactive Protocol Situation In-Reply-To: <5092C033.1030604@computer.org> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3434614806_482064" Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:40:13 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3434614806_482064 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Charlie, Apologies if I misrepresented the facts on DYMO/AODVv2=8A=8A I do think the facts as exist right now are: 1) We have a LOADng draft that claims support to address the MANET reactiv= e protocol requirements 2) Work has restarted (by yourself) on DYMO/AODVv2 3) There are two different views on the ability to merge LOADng with DYMO/AODVv2. One view is the merge can happen and another (unfortunately by some authors of LOADng) that such a merge is impractical. So, irrespective of how we got to where we are, the point is it is a good time to draw a conclusion on which of the 3 options above MANET should take to meet its requirement for a reactive routing protocol. Don From: "Charles E. Perkins" Organization: Saratoga Blue Skies Date: Thursday, November 1, 2012 11:32 AM To: Don Sturek Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation =20 =20 Hello Don, =20 Your claim has been made several times, and I think it is highly misleading. =20 The bottom line is that the editorship of the WG document is now in good hands, and given the time available in the past, good progress has been made. Also given my renewed emphasis, support from my job, and clear understanding of goals, I can confidently state that I can do the work, an= d can manage the editorship process to follow working group discussion to completion. Here is (some of) what happened. I hope you will read it. =20 I was asked last fall to resume editorship of the DYMO document, and agreed to do so. =20 Almost at the same time, I was invited to work with the LOADng authors to produce a merged document that incorporated the best features from DYMO and from LOADng. At that time, the general agreement was that the merged document would be renamed AODVv2. =20 Because of various personal difficulties unfamiliar in my experience, I wa= s surprised to find very late in the winter that the merge was not happening= . In order to carry out my responsibility, which was clearly to submit a revised document for IETF 83 in Paris, I took the resource available to me and within less than a week I submitted the revised DYMO draft renamed to be AODVv2. =20 People attending the meeting will remember what happened. I was quite unjustly attacked and called names for doing: a) what I said I would do b) what I was supposed to do, and c) changing the document to become more compatible with LOADng, as requested by those authors and according to my best understanding. =20 After that, I still hoped that we could do the merge, but nothing happened until in Vancouver when the WG chairs gave us an ultimatum to make something happen by November. =20 We went around and around, but I eventually determined that there was almost no chance that the LOADng authors would willingly help to produce the desired merge. So I did what the LOADng authors had asked me not to do: namely submit a revised document for consideration. This revised document was an attempt to respond to valid comments made during 2010 about problems with the document while it was under Ian's editorial responsibility. It needs further revision -- in fac= t I will submit a much more polished document on my website this week. =20 The important point is that for the last year the document languished for all but a few weeks *at the request of the LOADng authors* -- in fact, I would even say at their *DEMAND*, and all the while they refused to help make the merge that (a) they had originally suggested and (b) I was supposed to do. =20 This note is already too long. I have much, much more to say. But I will say one more thing: I have the ability and now the time to do an excellent job on this, and I am here on the job only for the benefit of the working group. Now that I can focus on it, and now that I do not feel constrained to abide by the demands for delay that were imposed by the LOADng author team, I can do it pretty expediently. Of course I will welcome their input as well, and to further reiterate it will be my intention to make the WG document compatible with the needs of LOADng. =20 Oh -- and one more thing... Regardless of the poisoned atmosphere surrounding this debate, I have nothing but high regard for the work done by the LOADng team. I don't think their methods are right for this working group, and any statements to the effect that the DYMO editorial process has been deficient during the last year or more should be understood in light of the above narrative. =20 Regards, Charlie P. =20 PS. Oh, and one more thing... I am a peaceful man, and if I don't respond to all the invective and intransigence so clearly in evidence lately, you'll just have to excuse me for trying to remain so. =20 =20 On 11/1/2012 9:40 AM, Don Sturek wrote: =20 =20 > =20 > Hi Adbussalam, > =20 >=20 > =20 > =20 > It is hard to consider a draft stalled 2+ years as the only way forward i= n > MANET as a reactive protocol. > =20 >=20 > =20 > =20 > Don > =20 >=20 > =20 > =20 >=20 > =20 > =20 >=20 > =20 > =20 > From: Abdussalam Baryun > Date: Thursday, November 1, 2012 8:53 AM > To: Jon Black > Cc: "manet@ietf.org" , Stan Ratliff > Subject: Re: [manet] Reactive Protocol Situation > =20 > =20 >=20 > =20 > =20 > Yes LOADng is a reactive protocols, but not the MANET WG reactive protoco= l > (DYMO is already authorised). The WG is the only authorised to make such > decisions for its WG drafts, if WG decides to add any LOADng ideas it can= , or > to accept such merge it can as well, > =20 > =20 > AB > =20 > =20 > On Thu, Nov 1, 2012 at 3:37 PM, Jon Black wrote: > =20 >> =20 >> =20 >> Why would you think that LOADng is not reactive? If it is not a reactiv= e >> protocol, then what is it? >> =20 >> As to merging the documents, this is what WGs do. If you have multiple >> "competing" ideas you ask the authors to see if they can merge their con= cepts >> and ideas. If they cannot or will not then the WG must decide based on = facts >> and not conjecture which is the most prudent path to take. >> =20 >> Jon >> =20 >>=20 >> =20 >> =20 >>=20 >> =20 >> =20 >> =20 >> =20 >> =20 >>=20 >> From: Abdussalam Baryun >> To: Joseph Macker >> Cc: manet@ietf.org; Stan Ratliff >> Sent: Thursday, November 1, 2012 8:22 AM >>=20 >> Subject: Re: [manet] Reactive Protocol Situation >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> Dear Joseph Macker and Stan, >> =20 >> MANET WG Chairs >> =20 >> =20 >> =20 >> I disagree that the WG arranged/guided to merge the documents, I never h= eard >> that there was a consensus on such activity. DYMO is a reactive WG draft= , but >> LOADng is not. Why did you guide to merge documents, I recommend that yo= u >> ment to merge the team drafts co-authors to one WG draft (which is only = DYMO >> so far). The authority is for the WG to decide to merge individual draft= s to >> its WG draft. >> =20 >> =20 >> =20 >> Therefore, my vote is for option 1 only. Thanking you for updating us wi= th >> the status. >> =20 >> =20 >> =20 >> Regards >> =20 >> AB >> =20 >> =20 >> =20 >> On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker wro= te: >> =20 >>> Hello MANET working group (form Stan and Joe), >>> =20 >>> As you are all probably aware, there has been WG activity lately on >>> competing drafts for a MANET reactive protocol - DYMO (reviving the cur= rent >>> working group document that was parked due to inactivity), and LOADng. = Many >>> months ago there was a somewhat authorship led movement towards a commo= n >>> document effort and given positive feedback at the time we the chairs >>> thought this was the best approach given the authors potential to come >>> together and gain the best of both efforts. Since that period, there h= as >>> been some fairly strident and rancorous "at times" debate between the >>> authors of the two documents. >>> =20 >>> During IETF 84 in Vancouver, the co-chairs held a discussion with some= of >>> the co-authors of the two documents. Our guidance to the co-authors was= to >>> find a way to merge the two documents into one, as it was perceived tha= t are >>> not technically far apart and they both derive roughly from AODV concep= ts >>> and LOADng had fairly active authorship and implementation efforts. We >>> provided a co-editing proposal to the authors and gave them the timefra= me of >>> the Atlanta to come up with an answer back to us regarding this. As of= this >>> writing, those discussions of a potential commonn document and authorsh= ip >>> merger have failed. >>> =20 >>> Therefore, we find ourselves at a crossroads. The authors of the two >>> documents are divided, and it is unlikely that progress on a merged doc= ument >>> can be reached based upon recent author feedback. I have also polled th= e >>> earlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged = on >>> the issue at the present time. We see only 3 possible paths forward: >>> =20 >>> 1. Continue the work on the DYMO document, starting with whether there= is >>> consensus on its continued approach and also the desire to rename it to >>> AODVv2. >>> 2. Replace the existing DYMO document effort with the LOADng related >>> document effort, defusing ealier references to LLNs as recommended in t= he >>> last meeting minutes, and to focus more motivationally on general MANET >>> problem spaces (the authors seem to have agreed to this issue if its a = WG >>> document). >>> 3. Remove the working group charter for a reactive protocol, effective= ly >>> killing both documents, at least from a working group (WG) standpoint. = This >>> would not be a reflection on the technology in either case, just an >>> admission that we are not working together and reaching consensus. >>> =20 >>> The co-chairs request and need your opinions on the options. We have = been >>> some silent collecting initial feedback and waiting for author feedback= at >>> this point. Stan and I are both on travel prior to Atlanta so our resp= onses >>> may be sparse and we will also likely be in a "receive mode" for a few = days. >>> So send your opinions. >>> =20 >>> -Joe >>> =20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> =20 >>> =20 >> =20 >> =20 >> =20 >> =20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 > =20 > =20 > _______________________________________________ manet mailing list > manet@ietf.org https://www.ietf.org/mailman/listinfo/manet > =20 > =20 > _______________________________________________ > manet mailing list > manet@ietf.orghttps://www.ietf.org/mailman/listinfo/manet > =20 =20 =20 =20 --=20 Regards, Charlie P. =20 --B_3434614806_482064 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Charlie,

=
Apologies if I misrepresented the facts on DYMO/AODVv2…R= 30;

I do think the facts as exist right now are:
1)  We have a LOADng draft that claims support to address the M= ANET reactive protocol requirements
2)  Work has restarted (b= y yourself) on DYMO/AODVv2
3)  There are two different views = on the ability to merge LOADng with DYMO/AODVv2. One view is the merge can h= appen and another (unfortunately by some authors of LOADng) that such a merg= e is impractical.

So, irrespective of how we got to= where we are, the point is it is a good time to draw a conclusion on which = of the 3 options above MANET should take to meet its requirement for a react= ive routing protocol.

Don

=
From: "Charles E. Perkins" <= ;charliep@computer.org>
Organization: Saratoga Blue Skies
Date: Thursday, November 1, 2012 11:32 A= M
To: Don Sturek <d.sturek@att.net>
Cc: "manet@ietf.org" <manet@ietf.org>
Subject: Re: [manet] Reactive Protocol Situation
=


Hello Don,

Your claim has been made several times, and I think it is highly misleading.

The bottom line is that the editorship of the WG document is now in good
hands, and given the time available in the past, good progress has been
made.  Also given my renewed emphasis, support from my job, and clear
understanding of goals, I can confidently state that I can do the work, and
can manage the editorship process to follow working group discussion to
completion.  Here is (some of) what happened.  I hope you w= ill read it.

I was asked last fall to resume editorship of the DYMO document, and
agreed to do so.

Almost at the same time, I was invited to work with the LOADng authors
to produce a merged document that incorporated the best features from
DYMO and from LOADng.  At that time, the general agreement was that
the merged document would be renamed AODVv2.

Because of various personal difficulties unfamiliar in my experience, I was
surprised to find very late in the winter that the merge was not happening.
In order to carry out my responsibility, which was clearly to submit a
revised document for IETF 83 in Paris, I took the resource available to me
and within less than a week I submitted the revised DYMO draft renamed
to be AODVv2.

People attending the meeting will remember what happened.  I was= quite
unjustly attacked and called names for doing:
a) what I said I would do
b) what I was supposed to do, and
c) changing the document to become more compatible with LOADng, as     requested by those authors and according to my bes= t understanding.

After that, I still hoped that we could do the merge, but nothing happened
until in Vancouver when the WG chairs gave us an ultimatum to make something happen by November.

We went around and around, but I eventually determined that there
= was almost no chance that the LOADng authors would willingly help to
produce the desired merge.  So I did what the LOADng authors had= asked
me not to do: namely submit a revised document for consideration.
= This revised document was an attempt to respond to valid comments
= made during 2010 about problems with the document while it was
under Ian's editorial responsibility.  It needs further revision= -- in fact
I will submit a much more polished document on my website this
week.

The important point is that for the last year the document languished
for all but a few weeks *at the request of the LOADng authors* --
= in fact, I would even say at their *DEMAND*, and all the while they
refused to help make the merge that (a) they had originally suggested
and (b) I was supposed to do.

This note is already too long.  I have much, much more to say. <= br> But I will say one more thing: I have the ability and now the time to
do an excellent job on this, and I am here on the job only for the benefit of the working group.  Now that I can focus on it, and n= ow
that I do not feel constrained to abide by the demands for delay
that were imposed by the LOADng author team, I can do it pretty
expediently.  Of course I will welcome their input as well, and = to
further reiterate it will be my intention to make the WG document
= compatible with the needs of LOADng.

Oh -- and one more thing...  Regardless of the poisoned atmosphe= re
surrounding this debate, I have nothing but high regard for the work
done by the LOADng team.  I don't think their methods are right for
this working group, and any statements to the effect that the DYMO editorial process has been deficient during the last year or more
= should be understood in light of the above narrative.

Regards,
Charlie P.

PS. Oh, and one more thing...  I am a peaceful man, and if I don= 't
        respond to all the invecti= ve and intransigence so clearly
        in evidence lately, you'll= just have to excuse me for trying
        to remain so.


On 11/1/2012 9:40 AM, Don Sturek wrote:
Hi Adbussalam,

It is hard to consider a draft stalled 2+ years as the only way forward in MANET as a reactive protocol.

Don



From: Abdussalam Baryun <abdussalambaryun@gmail.com>
Date: Thursday, November 1, 2012 8:53 AM
To: Jon Black <jblack.ietf@yahoo.com<= /a>>
Cc: "manet@ietf.org" <manet@= ietf.org>, Stan Ratliff <sratliff@cisco.com>
Subject: Re: [manet] Reactive Protocol Situation

Yes LOADng is a reactive protocols, but not the MANET WG reactive protocol (DYMO is already authorised). The WG is the only authorised to make such decisions for its WG drafts, if WG decides to add any LOADng ideas it can, or to accept such merge it can as well,
AB
On Thu, Nov 1, 2012 at 3:37 PM, Jon Black <jblack.ietf@yahoo.com> wrote:
Why would you think that LOADng is not reactive?  If it is not a reactive protocol, then what is it?

As to merging the documents, this is what WGs do.  If you have multiple "competing" ideas you ask the authors to see if they can merge their concepts and ideas.  If= they cannot or will not then the WG must decide based on facts and not conjecture which is the most prudent path to take.

Jon


Fro= m: Abdussalam Baryun <abdussalambaryun@gmail= .com>
To: Joseph Macker <jpmacker@gmail.com>
Cc: manet@ietf.org; Stan Ratliff <sratliff@cisco.com>
Sent: Thursday, November 1, 2012 8:22 AM

Subject:= Re: [manet] Reactive Protocol Situation

Dear Joseph Macker and Stan,
MANET WG Chairs
 
I disagree that the WG arranged/gu= ided to merge the documents, I never heard that there was a consensus on such activity. DYMO is a reactive WG draft, but LOADng is not. Why did you guide to merge documents, I recommend that you ment to merge the team drafts co-authors to one WG draft (which i= s only DYMO so far). The authority is for the WG to decide to merge individual drafts to its WG draft.
 
Therefore, my vote is for option 1 only. Thanking you for updating us with the status.
 
Regards
AB

On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker <jpmack= er@gmail.com> wrote:
Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competing drafts for a MANET reactive protocol - DYMO (reviving the current working group document that was parked due to inactivity), and LOADng. Many months ago there was a somewhat authorship led movement towards a common document effort and given positive feedback at the time we the chairs thought this was the best approach given the authors potential to come together and gain the best of both efforts.  Since that period, there has been some fairly strident and rancorous "at times" debate between the authors of the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of the co-authors of the two documents. Our guidance to the co-authors was to find a way to merge the two documents into one, as it was perceived that are not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active authorship and implementation efforts. We provided a co-editing proposal to the authors and gave them the timeframe of the Atlanta to come up with an answer back to us regarding this.  As of this writing, tho= se discussions of a potential commonn document and authorship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two documents are divided, and it is unlikely that progress on a merged document can be reached based upon recent author feedback. I have also polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.  We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is consensus on its continued approach and also the desire to rename it to AODVv2.
2. Replace the existing DYMO document effort with the LOADng related document effort, defusing ealier references to LLNs as recommended in the last meeting minutes, and to focus more motivationally on general MANET problem spaces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively killing both documents, at least from a working group (WG) standpoint. This would not be a reflection on the technology in either case, just an admission that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have been some silent collecting initial feedback and waiting for author feedback at this point.  Stan and I are both on travel prior to Atlanta so our responses may be sparse and we will also likely be in a "receive mode" for a few days.  So send your opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
https://www.i= etf.org/mailman/listinfo/manet



_______________________________________________
= manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listi= nfo/manet



_______________________________________________ manet mailing list manet@ietf.o= rg https://www.ietf.org/mailman/listinfo/manet 

_______________________________________________
manet mailing list
manet@ietf=
.orghttps://www.ietf.org/mailman/listinfo/manet


-- 
Regards,
Charlie P.
 --B_3434614806_482064-- From jau@coe.drexel.edu Thu Nov 1 11:54:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C030621F8D1D for ; Thu, 1 Nov 2012 11:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rr8vjyX4BKur for ; Thu, 1 Nov 2012 11:54:10 -0700 (PDT) Received: from mail.coe.drexel.edu (edge01.coe.drexel.edu [129.25.59.82]) by ietfa.amsl.com (Postfix) with ESMTP id A164521F8D1C for ; Thu, 1 Nov 2012 11:54:10 -0700 (PDT) Received: from ex.coe.drexel.edu ([169.254.1.82]) by edge01.coe.drexel.edu ([129.25.59.18]) with mapi; Thu, 1 Nov 2012 14:54:09 -0400 From: Jaudelice de Oliveira To: Joseph Macker Date: Thu, 1 Nov 2012 14:54:08 -0400 Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: Ac24YkZRRYP3AghHRmaMek1kj39dXA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:54:11 -0000 I recommend option 1.=20 In my opinion the author has shown his willingness to continue to work with= the WG to complete the original WG document and also to try to adhere to t= he chairs' suggestion, even if in the form of a compromise given that a mer= ged document was not feasible, by making it compatible.=20 BR,=20 Jau. Jaudelice de Oliveira Associate Professor ECE Dept, Drexel University On Oct 30, 2012, at 7:13 PM, Joseph Macker wrote: > Hello MANET working group (form Stan and Joe), >=20 > As you are all probably aware, there has been WG activity lately on compe= ting drafts for a MANET reactive protocol - DYMO (reviving the current work= ing group document that was parked due to inactivity), and LOADng. Many mon= ths ago there was a somewhat authorship led movement towards a common docum= ent effort and given positive feedback at the time we the chairs thought th= is was the best approach given the authors potential to come together and g= ain the best of both efforts. Since that period, there has been some fairl= y strident and rancorous "at times" debate between the authors of the two d= ocuments. >=20 > During IETF 84 in Vancouver, the co-chairs held a discussion with some of= the co-authors of the two documents. Our guidance to the co-authors was to= find a way to merge the two documents into one, as it was perceived that a= re not technically far apart and they both derive roughly from AODV concept= s and LOADng had fairly active authorship and implementation efforts. We pr= ovided a co-editing proposal to the authors and gave them the timeframe of = the Atlanta to come up with an answer back to us regarding this. As of thi= s writing, those discussions of a potential commonn document and authorship= merger have failed. >=20 > Therefore, we find ourselves at a crossroads. The authors of the two docu= ments are divided, and it is unlikely that progress on a merged document ca= n be reached based upon recent author feedback. I have also polled the earl= ier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the i= ssue at the present time. We see only 3 possible paths forward: >=20 > 1. Continue the work on the DYMO document, starting with whether there is= consensus on its continued approach and also the desire to rename it to AO= DVv2. > 2. Replace the existing DYMO document effort with the LOADng related docu= ment effort, defusing ealier references to LLNs as recommended in the last = meeting minutes, and to focus more motivationally on general MANET problem = spaces (the authors seem to have agreed to this issue if its a WG document)= . > 3. Remove the working group charter for a reactive protocol, effectively = killing both documents, at least from a working group (WG) standpoint. This= would not be a reflection on the technology in either case, just an admiss= ion that we are not working together and reaching consensus. >=20 > The co-chairs request and need your opinions on the options. We have bee= n some silent collecting initial feedback and waiting for author feedback a= t this point. Stan and I are both on travel prior to Atlanta so our respon= ses may be sparse and we will also likely be in a "receive mode" for a few = days. So send your opinions. >=20 > -Joe > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Thu Nov 1 12:04:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7CC21F921D for ; Thu, 1 Nov 2012 12:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3XzWQax-Rgv for ; Thu, 1 Nov 2012 12:04:51 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC3F021F921B for ; Thu, 1 Nov 2012 12:04:51 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3393165vbb.31 for ; Thu, 01 Nov 2012 12:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uC5u2Q+C4gNyEsBSvHONqEi0TzcM7Rc0N3flh745kXA=; b=q1eDa+hBDkTzZ+njbIUunAasd+U63/Y6wJiMb1V9Im0fW6ZQGXT8Na2fxBA4li01pD VId6q/Txf8PFCzTPxuBtOPEZMR/Bsar4FdC6amI+5ZkUDZnynwfCOEUguIdzSPFTMYMe Dv7GXM4JaUQLonvb8V4uorKjkTgmT1PztHcAw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=uC5u2Q+C4gNyEsBSvHONqEi0TzcM7Rc0N3flh745kXA=; b=oPvU62lLnN342WuKlCbKJo8ijTIPYkq1N/0RxzzDCbB4xPppDGcMcY8bHFZRtIutaM 2p+Ds1VuAJRkSErleCpVYenJT+VGD4gpVuFiiqRazeKlMuYZCF0j1qX/wGrDb5v+uf/9 IIfHbcEP0rQeKo6rE/fi/leZuSaRurmSUPR9/eH9TGfEMIh//ktgjtllovC9D26urEUP jVo5TpvMAc1EiKivEI0JKgo6sHWUDUbDi6BFuj1mJeO8zleEYYIH0GOYeNBItbu6+np4 4c+P0xJxArc5bUgMCVdZlSIkb1uNf3hjz1hnhGLGjhMrbEjw0eh5K5SkO7amDnsK47Xt pR4Q== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr52822368vdv.20.1351796690950; Thu, 01 Nov 2012 12:04:50 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Thu, 1 Nov 2012 12:04:50 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Nov 2012 12:04:50 -0700 Message-ID: From: Ulrich Herberg To: Jaudelice de Oliveira Content-Type: multipart/alternative; boundary=bcaec50162bd929a5904cd73b1c1 X-Gm-Message-State: ALoCoQmK875ELP99TPdGOVVSisqtGgguZWgOe9Jnn39rb/LtPCMcg61WiTVsc46Y3dF+trfccLRJ Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 19:04:53 -0000 --bcaec50162bd929a5904cd73b1c1 Content-Type: text/plain; charset=ISO-8859-1 It would really be more productive if you had some technical arguments. The LOADng authors are also more than willing to bring the work forward, so this is not really an argument for or against anything. Best Ulrich On Thu, Nov 1, 2012 at 11:54 AM, Jaudelice de Oliveira wrote: > > I recommend option 1. > > In my opinion the author has shown his willingness to continue to work > with the WG to complete the original WG document and also to try to adhere > to the chairs' suggestion, even if in the form of a compromise given that a > merged document was not feasible, by making it compatible. > > BR, > Jau. > > > > Jaudelice de Oliveira > Associate Professor > ECE Dept, Drexel University > > On Oct 30, 2012, at 7:13 PM, Joseph Macker wrote: > > > Hello MANET working group (form Stan and Joe), > > > > As you are all probably aware, there has been WG activity lately on > competing drafts for a MANET reactive protocol - DYMO (reviving the current > working group document that was parked due to inactivity), and LOADng. Many > months ago there was a somewhat authorship led movement towards a common > document effort and given positive feedback at the time we the chairs > thought this was the best approach given the authors potential to come > together and gain the best of both efforts. Since that period, there has > been some fairly strident and rancorous "at times" debate between the > authors of the two documents. > > > > During IETF 84 in Vancouver, the co-chairs held a discussion with some > of the co-authors of the two documents. Our guidance to the co-authors was > to find a way to merge the two documents into one, as it was perceived that > are not technically far apart and they both derive roughly from AODV > concepts and LOADng had fairly active authorship and implementation > efforts. We provided a co-editing proposal to the authors and gave them the > timeframe of the Atlanta to come up with an answer back to us regarding > this. As of this writing, those discussions of a potential commonn > document and authorship merger have failed. > > > > Therefore, we find ourselves at a crossroads. The authors of the two > documents are divided, and it is unlikely that progress on a merged > document can be reached based upon recent author feedback. I have also > polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat > disengaged on the issue at the present time. We see only 3 possible paths > forward: > > > > 1. Continue the work on the DYMO document, starting with whether there > is consensus on its continued approach and also the desire to rename it to > AODVv2. > > 2. Replace the existing DYMO document effort with the LOADng related > document effort, defusing ealier references to LLNs as recommended in the > last meeting minutes, and to focus more motivationally on general MANET > problem spaces (the authors seem to have agreed to this issue if its a WG > document). > > 3. Remove the working group charter for a reactive protocol, effectively > killing both documents, at least from a working group (WG) standpoint. This > would not be a reflection on the technology in either case, just an > admission that we are not working together and reaching consensus. > > > > The co-chairs request and need your opinions on the options. We have > been some silent collecting initial feedback and waiting for author > feedback at this point. Stan and I are both on travel prior to Atlanta so > our responses may be sparse and we will also likely be in a "receive mode" > for a few days. So send your opinions. > > > > -Joe > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --bcaec50162bd929a5904cd73b1c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It would really be more productive if you had some technical arguments. The= LOADng authors are also more than willing to bring the work forward, so th= is is not really an argument for or against anything.

Best
Ulrich

On Thu, Nov 1, 2012= at 11:54 AM, Jaudelice de Oliveira <jau@coe.drexel.edu> wr= ote:

I recommend option 1.

In my opinion the author has shown his willingness to continue to work with= the WG to complete the original WG document and also to try to adhere to t= he chairs' suggestion, even if in the form of a compromise given that a= merged document was not feasible, by making it compatible.

BR,
Jau.



Jaudelice de Oliveira
Associate Professor
ECE Dept, Drexel University

On Oct 30, 2012, at 7:13 PM, Joseph Macker <jpmacker@gmail.com> wrote:

> Hello MANET working group (form Stan and Joe),
>
> As you are all probably aware, there has been WG activity lately on co= mpeting drafts for a MANET reactive protocol - DYMO (reviving the current w= orking group document that was parked due to inactivity), and LOADng. Many = months ago there was a somewhat authorship led movement towards a common do= cument effort and given positive feedback at the time we the chairs thought= this was the best approach given the authors potential to come together an= d gain the best of both efforts. =A0Since that period, there has been some = fairly strident and rancorous "at times" debate between the autho= rs of the two documents.
>
> During IETF 84 in Vancouver, the co-chairs held a discussion with some= of the co-authors of the two documents. Our guidance to the co-authors was= to find a way to merge the two documents into one, as it was perceived tha= t are not technically far apart and they both derive roughly from AODV conc= epts and LOADng had fairly active authorship and implementation efforts. We= provided a co-editing proposal to the authors and gave them the timeframe = of the Atlanta to come up with an answer back to us regarding this. =A0As o= f this writing, those discussions of a potential commonn document and autho= rship merger have failed.
>
> Therefore, we find ourselves at a crossroads. The authors of the two d= ocuments are divided, and it is unlikely that progress on a merged document= can be reached based upon recent author feedback. I have also polled the e= arlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on th= e issue at the present time. =A0We see only 3 possible paths forward:
>
> 1. Continue the work on the DYMO document, starting with whether there= is consensus on its continued approach and also the desire to rename it to= AODVv2.
> 2. Replace the existing DYMO document effort with the LOADng related d= ocument effort, defusing ealier references to LLNs as recommended in the la= st meeting minutes, and to focus more motivationally on general MANET probl= em spaces (the authors seem to have agreed to this issue if its a WG docume= nt).
> 3. Remove the working group charter for a reactive protocol, effective= ly killing both documents, at least from a working group (WG) standpoint. T= his would not be a reflection on the technology in either case, just an adm= ission that we are not working together and reaching consensus.
>
> The co-chairs request and need your opinions on the options. =A0We hav= e been some silent collecting initial feedback and waiting for author feedb= ack at this point. =A0Stan and I are both on travel prior to Atlanta so our= responses may be sparse and we will also likely be in a "receive mode= " for a few days. =A0So send your opinions.
>
> -Joe
> __________________= _____________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--bcaec50162bd929a5904cd73b1c1-- From jpmacker@gmail.com Thu Nov 1 12:11:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4375B21F9440 for ; Thu, 1 Nov 2012 12:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBK+6EWM64S0 for ; Thu, 1 Nov 2012 12:11:07 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id DA1BE21F9430 for ; Thu, 1 Nov 2012 12:11:06 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so3148073oag.31 for ; Thu, 01 Nov 2012 12:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=DzDyv95qjODGUIP4wqylUpi2eQXdFbYLTqgFd640jhw=; b=KOrRPWD9NPOsmC0VUNRuQ72jIY3/fE+0wdQTOKKTb6Hks9dqC00G8cBoO7gC7SZm2p 1zcXLA3ZLL7u2/AK/ADxO1FwwSYs/6UKj2KCdDfhFe+nYddkBmrPDv5GkTDq1rpJnQiG NZiwTqblUTi0sNifOzeHH+eAKuPJHPN5m6MUvdzxXZ0okx7C7bA6it3d41XTPzBUi6lg JIhK38Iuv+twNdnIJQbYcJfUHuQ05bwlRmwxG6Y6SXU8f3zsxkmaRtbU+YPSvmqPdZSd 0TXbFmD6IkKiZWZNtcoF3+n7gbwdS9yfWOH9M7auRI1U8JejGTZy7emRHpPyULfC7pZK ahng== Received: by 10.182.190.19 with SMTP id gm19mr34138535obc.47.1351797066400; Thu, 01 Nov 2012 12:11:06 -0700 (PDT) Received: from [10.137.140.11] ([32.170.229.133]) by mx.google.com with ESMTPS id bd5sm7038553obb.5.2012.11.01.12.11.02 (version=SSLv3 cipher=OTHER); Thu, 01 Nov 2012 12:11:05 -0700 (PDT) References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <2CF862E3-F417-4442-B597-6DCBA035D4B9@cisco.com> <1351784420.69738.YahooMailNeo@web160603.mail.bf1.yahoo.com> <50929A47.1000600@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <50929A47.1000600@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A403) From: Joe Macker Date: Thu, 1 Nov 2012 14:54:39 -0400 To: Alexandru Petrescu Cc: "manet@ietf.org" Subject: Re: [manet] Mobility and eMeters (was: no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 19:11:08 -0000 Sent from my iPhone On Nov 1, 2012, at 11:50 AM, Alexandru Petrescu wrote: > Le 01/11/2012 16:40, Jon Black a =C3=A9crit : >> Mobility in a wireless sense means a changing connectivity. A >> wireless device does not need to physically move to appear mobile - >> the connectivity path changes. >=20 > I agree that mobility in a wireless sense means changing connectivity. > And that devices do not need to physically move to appear mobile in that > sense. The charter directly includes static networks and topology dynamics due to o= ther factors >=20 >> Now if you live in a mobile home maybe your meter may also >> physically move. Maybe your mobile home doesn't have wheels. >=20 > Or does it? >=20 > A mobile home is an challenging concept with respect to connectivity of > electricity Meters. >=20 > Many mobile Homes plug on electricity lines either without any Meter, or > with a Meter that is fixed outside the mobile home and that is somebody > else's. >=20 > 'Mobility' and electricity distributors is mentioned also as the > mobility of an operator walking around fixed consumer householdings and > reading the Meter data wirelessly, instead of entering the various > places where Meters are stored. >=20 > For these cases, I do not know whether a routing protocol in MANET is > adapted, or not, or so and so. >=20 > Alex >=20 >=20 >>=20 >> Jon >>=20 >>=20 >> ------------------------------------------------------------------------ > *From:* Bo Berry >> *To:* "Dearlove, Christopher (UK)" >> *Cc:* JP Vasseur (jvasseur) ; Jon Black >> ; "manet@ietf.org" ; >> "thierry.lys@erdfdistribution.fr" >> *Sent:* Thursday, November 1, 2012 4:22 AM *Subject:* Re: [manet] >> (no subject) >>=20 >> And to be fair, I've not seen results on Loadng wrt to mobility. >> The smart meter attached to my house has not moved sense it was >> installed. >>=20 >>=20 >> On Nov 1, 2012, at 6:10 AM, Dearlove, Christopher (UK) wrote: >>=20 >>> If I were in charge of requirements, that requirement would be >>> now. >> Attempting to sway a decision on the basis of "I have results" but >> not offering those results until the decision is made is not >> helpful. And the most important thing is are there any comparisons >> between the two (or with base AODV)? Without those, the issue is how >> do the two differ technically in a manner that matters? >>>=20 >>> -- Christopher Dearlove Senior Principal Engineer, Communications >>> Group Communications, Networks and Image Analysis Capability BAE >>> Systems Advanced Technology Centre West Hanningfield Road, Great >>> Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 >>> 1245 242124 chris.dearlove@baesystems.com >>> >> | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited Registered Office: Warwick House, >>> PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>> From: manet-bounces@ietf.org >> [mailto:manet-bounces@ietf.org ] On >> Behalf Of JP Vasseur (jvasseur) >>> Sent: 31 October 2012 22:09 To: Jon Black Cc: >>> thierry.lys@erdfdistribution.fr >> ; manet@ietf.org >> >>> Subject: Re: [manet] (no subject) >>>=20 >>>=20 >>> *** WARNING *** This message originates from outside our >>> organisation, either from an >> external partner or the internet. >>> Keep this in mind if you answer this message. Please see this >>> process on how to deal with suspicious emails. >>>=20 >>>=20 >>> On Oct 31, 2012, at 6:57 PM, Jon Black wrote: >>>=20 >>>=20 >>> On October 31, 2012 Thierry.Lys wrote: >>>=20 >>> I speak in the name of EDF group. >>>=20 >>> We started first to use LOAD as a routing algorithm and deployed >>> 2000 >> PLC-meters for smart grid purposes in 2011. Taking advantage of this >> field test, we have been actively participating to the working group >> to adopt enhancements in the LOADng specification. >>> We are now extremely pleased with what LOADng is capable of and >>> are >> confident that future deployements will be equipped with it. >>>=20 >>> This would seem to indicate that LOADng does work and in a rather >> large deployment. >>>=20 >>> JP> No this means that LoadNG works in *a* network. But the major >> technical difference here is that reactive routing is highly >> impacted >>> by the user traffic =E2=80=A6 If you poll a meter every 24 hours, it may= >>> work >> perfectly well. Now if you start having more frequent traffic flows >>> you can either cache paths (ending up with more frequent broken >>> paths >> considering how flappy these networks are, thus leading to more >>> floods =E2=80=A6 very undesirable =E2=80=A6 especially when you have hun= dreds of >> meters sharing a few Kbits/s) or you use short cache timers and you >>> keep flooding :-( If you take actual traces of these networks >>> (both >> using 15.4g and P1901.2) and you start adjusting the user traffic >> rate you >>> immediately see the issues in terms of scalability. Yes you can >>> try >> to mitigate the undesirable flooding effect to some extends but >> showing >>> the limits in terms of scalability is easy to show. Note that I >>> MOT >> against reactive routing by any means, this is IMO just not >> applicable to >>> LLNs unless the traffic flows are deterministic and very well >>> knows =E2=80=A6 >> Lessons from the past show us how difficult it is to predict user >>> applications. We all started with meter reading to continue with >>> that >> example and now many utilities wants to use these smart metering >>> networks for a number of applications which different SLA, =E2=80=A6 >>>=20 >>> Hope this helps. Once again, when/if required I would be happy to >> share many results. >>>=20 >>>=20 >>>=20 >>>=20 >>> "We believe in rough consensus and running code" >>>=20 >>> rough consensus : Don't you think we have a rough consensus on >>> LOADng >> compared to DYMO ? 10 authors and major companies are supporters of >> LOADng. >>>=20 >>> running code : interoperability has been checked with 4 sources >>> and >> other implementations are in progress. >>>=20 >>> Obviously from the list we don't have rough consensus. We have >>> two >> alternatives each with proponents. The WG should weigh the >> technical benefits (design, implementation/running code, maturity) >> of each and the group should choose a path forward. >>>=20 >>> In my opinion option 3 is not an option - this is the working >>> group >> shirking its responsibility. >>>=20 >>> This is an option =E2=80=A6 since listed by the chairs. I agree that we >> should avoid it, especially when I think we have a very reasonable >> solution >>> (option1). >>>=20 >>> JP. >>>=20 >>>=20 >>>=20 >>> Jon >>>=20 >>> _______________________________________________ manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>> ******************************************************************** >>=20 >> 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. >>> ******************************************************************** >>=20 >>=20 >>> _______________________________________________ manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ manet mailing list >> manet@ietf.org https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Thu Nov 1 12:17:35 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D7221F9426 for ; Thu, 1 Nov 2012 12:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dlv+uts990iS for ; Thu, 1 Nov 2012 12:17:34 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 48E9C21F9421 for ; Thu, 1 Nov 2012 12:17:34 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3384349vcb.31 for ; Thu, 01 Nov 2012 12:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s7MlgEGkpMHDuDZtAgK0ocJhPb3xfwJHlgn3/V/ClhQ=; b=g74e6LA5B7UZtMj+rJM/tO7HCkkLsJmoqiOD5fvm+ltCtEeB8cuVMvSlXe4Dm6zCv2 pYApXs5StZvOwc+NktQchuBU0ypskKES0RJms5E8dPIWSYX9NiVdHfNJ8dHBVq0CIMro YQYc6HFleuXofPjL1IbTjbZayUyfrji91pCzAvzBrVYMquDYPOHpZMSKJTa4/264uNMr CNpH8RVQhJXPn0CneKFCC6N5RAskOVzIU9YdrAbCf++eLywzmcrKXIMtwbltyxSlHcw8 HAWJDaiKTi8ochSCoVZh38o2fidtrgjCKfrTdbGKNePhJmWysX7fYPt2pHfgYtcSk0va aVMQ== MIME-Version: 1.0 Received: by 10.58.189.72 with SMTP id gg8mr69766830vec.20.1351797453601; Thu, 01 Nov 2012 12:17:33 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 12:17:33 -0700 (PDT) In-Reply-To: <061.dd96a35b96e4ad8b95c1f2b46c7199f8@trac.tools.ietf.org> References: <061.dd96a35b96e4ad8b95c1f2b46c7199f8@trac.tools.ietf.org> Date: Thu, 1 Nov 2012 19:17:33 +0000 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: multipart/alternative; boundary=047d7b6727d207bd6304cd73dfe8 Subject: Re: [manet] #3: Use msg-hop-count in RFC 5444 header to limit # of hops X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 19:17:35 -0000 --047d7b6727d207bd6304cd73dfe8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree with the proposal, it seems with advantages, but there maybe disadvantages (i.e. violation to rfc5444) that need to be fixed. I don't think it is flexible to use only the hop-limit for rfc5444 messages for better dissimination, using other fields will give advantages. It may be considered to modify RFC5444 in future to accomodate reactive protocols advantages. AB On Tue, Oct 30, 2012 at 6:07 PM, manet issue tracker < trac+manet@trac.tools.ietf.org> wrote: > #3: Use msg-hop-count in RFC 5444 header to limit # of hops > > The current AODVv2 specification uses msg-hop-limit to control the > dissemination of routing messages. It is proposed instead to use msg-ho= p- > count to have a direct hop count for disseminated routing messages, and = to > use a protocol constant to limit the number of hops (e.g., MAX_HOP_COUNT > =3D=3D 64). Even 64 is too much for practically any foreseeable ad hoc > network. For networks that need to have finer-grained control (e.g., > controlling dissemination to be less than the manifest constant), msg-ho= p- > limit could be used for just those messages needing it. The specificati= on > can (independently) still specify TTL=3D255 according to RFC 5082. > > -- > --------------------------------+---------------------------------- > Reporter: charliep@=85 | Owner: Charlie Perkins > Type: enhancement | Status: new > Priority: major | Milestone: > Component: dymo | Version: > Severity: Active WG Document | Keywords: hop count, hop limit > --------------------------------+---------------------------------- > > Ticket URL: > manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7b6727d207bd6304cd73dfe8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I agree with the proposal, it seems with advantages, but there maybe d= isadvantages (i.e. violation to rfc5444) that need to be fixed. I don't= think it is flexible=A0to=A0use only the=A0hop-limit for rfc5444 messages = for better dissimination, using other fields will give advantages. It may b= e considered to modify RFC5444 in future to accomodate reactive protocols= =A0advantages.
=A0
AB

On Tue, Oct 3= 0, 2012 at 6:07 PM, manet issue tracker <trac+manet@trac.tool= s.ietf.org> wrote:
#3: Use msg-hop-count in RFC 5444 header to limit # of hop= s

=A0The current AODVv2 specification uses msg-hop-limit to control the
=A0dissemination of routing messages. =A0It is proposed instead to use msg-= hop-
=A0count to have a direct hop count for disseminated routing messages, and = to
=A0use a protocol constant to limit the number of hops (e.g., MAX_HOP_COUNT=
=A0=3D=3D 64). =A0Even 64 is too much for practically any foreseeable ad ho= c
=A0network. =A0For networks that need to have finer-grained control (e.g.,<= br> =A0controlling dissemination to be less than the manifest constant), msg-ho= p-
=A0limit could be used for just those messages needing it. =A0The specifica= tion
=A0can (independently) still specify TTL=3D255 according to RFC 5082.

--
--------------------------------+----------------------------------
=A0Reporter: =A0charliep@=85 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Owner: =A0Char= lie Perkins
=A0 =A0 =A0Type: =A0enhancement =A0 =A0 =A0 =A0 | =A0 =A0 Status: =A0new =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0Milestone:
Component: =A0dymo =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Version:
=A0Severity: =A0Active WG Document =A0| =A0 Keywords: =A0hop count, hop lim= it
--------------------------------+----------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/3&= gt;
manet <http:/= /tools.ietf.org/manet/>

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--047d7b6727d207bd6304cd73dfe8-- From jvasseur@cisco.com Thu Nov 1 12:24:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5B521F9250 for ; Thu, 1 Nov 2012 12:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.109 X-Spam-Level: X-Spam-Status: No, score=-10.109 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vThjpoISPHz5 for ; Thu, 1 Nov 2012 12:24:41 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3E63121F9267 for ; Thu, 1 Nov 2012 12:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7265; q=dns/txt; s=iport; t=1351797881; x=1353007481; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4JDzKbSQ4CnqGQbgwspZtCijImbBuoOeFnhLo8wCKuY=; b=PafCysb5o1rJn8fdIh5FlyclarbIlzlNT65OWdAD0XelmqO9Txn6j1k8 aa/BMVlNkB329hTPbn+x+Fl2wEzDzF9CbLkspWzBp4zzvcCkUi9og/ijE 2D+Y0NI2J2xaL+l1xAReoGaUL1YhypeHic2lAGYQR+xjJrLMU22PP55Aa 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD/LklCtJXHA/2dsb2JhbABEw3GBCIIeAQEBAgEBAQEBDwFCGQMIBQcEAgEIEQQBAQEKHQcnCxQJCAIEDgUIGodeBgucU6Avi3sUBweFOGEDiCWObo09gWuCb4FbCRce X-IronPort-AV: E=Sophos;i="4.80,695,1344211200"; d="scan'208";a="137873503" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 01 Nov 2012 19:24:40 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA1JOeBa032343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 19:24:40 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 14:24:40 -0500 From: "JP Vasseur (jvasseur)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNt7TLLPVi/cSo/ES1hdb7zda62w== Date: Thu, 1 Nov 2012 19:24:39 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722049AE3@xmb-rcd-x02.cisco.com> References: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220465DF@xmb-rcd-x02.cisco.com> <3D320804-EE40-42FB-BF08-3F662B3F9542@axelcdv.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.90.251] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--55.093500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <56C9E5C33F7FA24B9C86E97A4052BF53@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 19:24:42 -0000 On Nov 1, 2012, at 5:27 PM, Dearlove, Christopher (UK) wrote: > They can be good evidence of the failure of protocols ;) Indeed ! This is usually when I found simulations quite interesting especia= lly when using actual traces as opposed to hard-to-model PHY/MAC models. >=20 > But what is clear to me is that one important issue (and another of my po= sts is attempting to both be more precise, as well as going elsewhere) is t= he handling of unidirectional links. So any good evidence needs to consider= those. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Philip Levis > Sent: 01 November 2012 16:23 > To: Axel Colin de Verdi=E8re > Cc: List; Bo Berry (boberry) > Subject: Re: [manet] Reactive Protocol Situation >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Simulations of wireless networks using unit disc, time invariant models h= ave zero relevance to reality. Any results from such simulations MUST NOT b= e used as evidence of the performance of protocols. :) >=20 > Phil >=20 > On Oct 31, 2012, at 3:26 PM, Axel Colin de Verdi=E8re wrote: >=20 >> Hi JP, >>=20 >> As usual, there isn't just one situation, be it in MANETs in general or = in LLNs in particular. The simulations shown did make some assumptions on t= he traffic, and some other assumptions might show different results, but th= at's true of any protocol. Which is why I would also be interested in your = results concerning LOADng in LLNs. >>=20 >> Best, >>=20 >> Axel >>=20 >> Le 31 oct. 2012 =E0 15:12, JP Vasseur (jvasseur) a = =E9crit : >>=20 >>> Hi Bo, >>>=20 >>> We need to be very careful there . these documents provide results that= CANNOT be generalized to say the least. >>> Hypothesis made on traffic flows are such that you get the results that= you would like to see . >>>=20 >>> Thanks >>>=20 >>> JP. >>>=20 >>> On Oct 31, 2012, at 7:29 PM, Bo Berry wrote: >>>=20 >>>>=20 >>>> For background and perspective, ran across these two docs on the origi= n=20 >>>> and performance of Loadng. The WG may find helpful. >>>>=20 >>>> -Bo >>>>=20 >>>>=20 >>>> The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Gener= ation (LOADng)=09 >>>> By T. Clausen. A. Colin de Verdiere.=20 >>>> Published in INRIA Research Report 7692 on 2011-07-25. >>>> http://hipercom.thomasclausen.net/resteam/data/publications/414efa79c4= c772e5af46f426e77ca581.pdf >>>>=20 >>>>=20 >>>> A Comparative Performance Study of the Routing Protocols LOAD and RPL = with Bi-Directional Traffic in Low-power and Lossy Networks (LLN)=09 >>>> By T. Clausen, U. Herberg.=20 >>>> Published in INRIA Research Report 7637 on 2011-06-01. >>>> http://hipercom.thomasclausen.net/resteam/data/publications/49eaae3228= cf686a462108aef8332ceb.pdf >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Oct 31, 2012, at 1:48 PM, Jon Black wrote: >>>>=20 >>>>> Certainly smart meters are one of the types of networks that are MANE= Ts. Just because houses do not move it does not mean that the connectivity= between those meters isn't changing. A smart meter network is most certai= nly a MANET. [One could argue that it is not an LLN since at least from th= e electrical power there is no lack of power.] >>>>>=20 >>>>> Totally agree that one size does not fit all. >>>>>=20 >>>>> Jon >>>>>=20 >>>>> On October 31, 2012 John.Dowdell wrote: >>>>>=20 >>>>> While I am very pleased for you and your co-authors that the LOADng w= ork has been so fruitful, I am not really sure that smart meters are really= the kind of MANET devices that the working group was intended to address. = I have been party to the conversations for only a year or two, so I am very= happy to be corrected by those with longer histories, but MANET to me mean= s dynamically moving nodes, with links being established and broken often a= nd without prior warning. Examples may be communications networks built out= of nodes contained in cars, trucks and aircraft of all sizes. I appreciate= a comment on the list a while back that the RF environment for smart meter= ing is actually more difficult than one would think, but I would suggest to= the chairs that unless LOADng has applications in this dynamically mobile = environment (and I have to admit I have not read the spec in enough detail = to determine if this is the case), then we come to the conclusion that the = DYMO/AODVv2 path sh >>>> ould be followed unless we collectively feel that such a direction is = not worth pursuing (and note I am definitely not proposing that view). >>>>>=20 >>>>> In the two years or so that I have been working with MANETs, the only= conclusion I have come to is that very many use cases exist, and that one = size does not fit all. >>>>>=20 >>>>> Regards >>>>>=20 >>>>> John >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > 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. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Thu Nov 1 12:27:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461C621F94BB for ; Thu, 1 Nov 2012 12:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.411 X-Spam-Level: X-Spam-Status: No, score=-10.411 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7hYB2XQbXS1 for ; Thu, 1 Nov 2012 12:27:12 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E645621F94B4 for ; Thu, 1 Nov 2012 12:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7475; q=dns/txt; s=iport; t=1351798032; x=1353007632; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kbhp40WkGo3d/Jta2hiQFhv/EjZpcYG30Vt9l+aOrfs=; b=bYJfY4oukaXgYQ1ldl5eXxQpHOxhNWdvq4SbXdw6rcmk4uTcvCZbClpr JjyjuX09mPHcSISc3VZgNm0doqD5hMwFP5k3VqEioHr2RgsIkeKRyCm4x +qhvv6pO7CFd3aEAATgsVmqRxhpff9+uTw9c+x557HQa5F7PXEGEW4m2P A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAH7MklCtJXG9/2dsb2JhbABEw3GBCIIeAQEBAwEBAQEPAVsLBQsCAQgiHQcnCxQRAgQOBQgah14GC5xToCsEi3uFWmEDiCWcK4Frgm+BZBce X-IronPort-AV: E=Sophos;i="4.80,695,1344211200"; d="scan'208,217";a="137919738" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 01 Nov 2012 19:27:11 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA1JRBja001053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 19:27:11 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 14:27:11 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNt7TLLPVi/cSo/ES1hdb7zda62w== Date: Thu, 1 Nov 2012 19:27:10 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722049B35@xmb-rcd-x02.cisco.com> References: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220465DF@xmb-rcd-x02.cisco.com> <3D320804-EE40-42FB-BF08-3F662B3F9542@axelcdv.com> <6C031880-6176-491E-B822-CCE6B8B586FC@cs.stanford.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.90.251] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--48.845000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722049B35xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 19:27:13 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7722049B35xmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Indeed - we're diverging from the original question. On Nov 1, 2012, at 6:12 PM, Ulrich Herberg wrote: Hi Phil, maybe we should open a separate email thread about RPL and draft-clausen-ll= n-rpl-experiences (and probably not in this WG). Best Ulrich On Thu, Nov 1, 2012 at 9:45 AM, Philip Levis > wrote: On Nov 1, 2012, at 9:27 AM, Dearlove, Christopher (UK) wrote: > They can be good evidence of the failure of protocols ;) > > But what is clear to me is that one important issue (and another of my po= sts is attempting to both be more precise, as well as going elsewhere) is t= he handling of unidirectional links. So any good evidence needs to consider= those. Since communication in wireless is rarely binary, I think the more common t= erm is asymmetric links. I'm confused; I don't believe that unit disc model= s capture asymmetric links. Is the implied statement that RPL doesn't prope= rly handle asymmetric links but LOADng does? I think this came up in draft-= clausen-lln-rpl-experiences and there was some discussion on the ROLL list = about it. The neighbor set in RPL is defined in 8.2.1: "First, the candidate neighbor set is a subset of the nodes that can be rea= ched via link-local multicast." then in DIO processing (8.2.3.1) it reads: "As DIO messages are received from candidate neighbors, the neighbors may b= e promoted to DODAG parents by following the rules of DODAG discovery as de= scribed in Section 8.2." I want to be clear here; I haven't read deeply about LOADng, thought about = it much, or experimented with it at all. So I have zero to say about LOADng= 's strengths and weaknesses. But just because somebody publishes (and republishes) a draft saying someth= ing doesn't mean it's true. There are, in my opinion, some very valid point= s in draft-clausen-lln-rpl-experiences that relate to fundamental design de= cisions in RPL. For example, I think that the issues raised about the state= requirements of floating DODAGs and RPL message fragmentation are valid an= d reasonable and something we need to look at. However, there are others that are the result of naive mistakes anyone can = make when implementing any wireless routing protocol, such as link asymmetr= y and protocol convergence. Unfortunately the draft doesn't distinguish the= two. Implementing a protocol poorly then saying it doesn't work isn't part= icularly meaningful. As I said in Paris, I thought the draft is valuable be= cause it outlines many of the basic mistakes one makes the first time you t= ry implementing a wireless routing protocol. Phil _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7722049B35xmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <09B4E4D7F056CA4EADFBE60B4D6E95AF@cisco.com> Content-Transfer-Encoding: quoted-printable Indeed - we're diverging from the original question.

On Nov 1, 2012, at 6:12 PM, Ulrich Herberg wrote:

Hi Phil,

maybe we should open a separate email thread about RPL and draft-= clausen-lln-rpl-experiences (and probably not in this WG).

Best
Ulrich

On Thu, Nov 1, 2012 at 9:45 AM, Philip Levis <pal@cs.stanfor= d.edu> wrote:
On Nov 1, 2012, at 9:27 AM, Dearlove, Christopher (UK) wr= ote:

> They can be good evidence of the failure of protocols ;)
>
> But what is clear to me is that one important issue (and another of my= posts is attempting to both be more precise, as well as going elsewhere) i= s the handling of unidirectional links. So any good evidence needs to consi= der those.

Since communication in wireless is rarely binary, I think the more common t= erm is asymmetric links. I'm confused; I don't believe that unit disc model= s capture asymmetric links. Is the implied statement that RPL doesn't prope= rly handle asymmetric links but LOADng does? I think this came up in draft-clausen-lln-rpl-experiences and= there was some discussion on the ROLL list about it. The neighbor set in R= PL is defined in 8.2.1:

"First, the candidate neighbor set is a subset of the nodes that can b= e reached via link-local multicast."

then in DIO processing (8.2.3.1) it reads:

"As DIO messages are received from candidate neighbors, the neighbors = may be promoted to DODAG parents by following the rules of DODAG discovery = as described in Section 8.2."

I want to be clear here; I haven't read deeply about LOADng, thought about = it much, or experimented with it at all. So I have zero to say about LOADng= 's strengths and weaknesses.

But just because somebody publishes (and republishes) a draft saying someth= ing doesn't mean it's true. There are, in my opinion, some very valid point= s in draft-clausen-lln-rpl-experiences that relate to fundamental design de= cisions in RPL. For example, I think that the issues raised about the state requirements of floating DODAGs and= RPL message fragmentation are valid and reasonable and something we need t= o look at.

However, there are others that are the result of naive mistakes anyone can = make when implementing any wireless routing protocol, such as link asymmetr= y and protocol convergence. Unfortunately the draft doesn't distinguish the= two. Implementing a protocol poorly then saying it doesn't work isn't particularly meaningful. As I said in Pa= ris, I thought the draft is valuable because it outlines many of the basic = mistakes one makes the first time you try implementing a wireless routing p= rotocol.

Phil
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A7722049B35xmbrcdx02ciscoc_-- From abdussalambaryun@gmail.com Thu Nov 1 12:30:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1373F21F94BF for ; Thu, 1 Nov 2012 12:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiTSalsk5F12 for ; Thu, 1 Nov 2012 12:30:02 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 97CA821F939D for ; Thu, 1 Nov 2012 12:29:16 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3420529vbb.31 for ; Thu, 01 Nov 2012 12:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ld9C3fLD9OoGgLXmwIakjjRLeF2zRd5XN7TUdTxw7uw=; b=xBWiVfR1MNc84Gxom/CRg828Qc3xJtW/yOm4qQd4IUNibk31crcA3QL9Y0QiTmNzZC Q3dUwxfXfb8Ek8MyFBfrr6NCQcR18IVu7o4rWle8R8dV0rlMLASrGXJlLMmVnisou+Sn Z1k4F3q80/xSiqQNXb0IciP77ZOIyw5L+dZXN9y/AwTZ9QtCqtB3oePwZobz50N/YDHy wk8UkJue4OrydAp2opDt4XiLWchRq+YRzX7s7BywVKjCutDMVsGLNx7yl0cmkD+gcmK9 WDWxrtJfIk+2EIut5WFdBhG98kGJJoCalvUEH9QbieTA9ujpaP4mCxKZXPTEN++ttj7d I7hg== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr52901083vdv.20.1351798155847; Thu, 01 Nov 2012 12:29:15 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 12:29:15 -0700 (PDT) In-Reply-To: References: <061.dd96a35b96e4ad8b95c1f2b46c7199f8@trac.tools.ietf.org> <9FCCC536-EB92-4276-AC30-D92A4A9A9324@thomasclausen.org> Date: Thu, 1 Nov 2012 19:29:15 +0000 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=bcaec50162bde326ae04cd74080a Cc: "manet@ietf.org" Subject: Re: [manet] #3: Use msg-hop-count in RFC 5444 header to limit # of hops X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 19:30:03 -0000 --bcaec50162bde326ae04cd74080a Content-Type: text/plain; charset=ISO-8859-1 Hi Chris A RREQ as rfc5444 message controlling its dissimination by using hop-count with hop-limit. OLSRv2 messages SHOULD be handled differently than AODVv2 messages, even if they are both rfc5444 messages, because the protocol that uses RFC5444 format is the only one that can specify its messages types and handlings. I do agree to use of signatures for rfc5444 packets only in AODVv2, AB On Thu, Nov 1, 2012 at 1:50 PM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > I must be missing something here. I think I have an idea what it is, but > let's confirm. > > Let's consider an RREQ message, which is flooded. The issue is, does it > mutate on its travels? If not, I don't see why we can't use the 5444 hop > limit. If it does, then that is not technically an issue for 5444, but does > have two bad effects: > - There is a general processing/forwarding engine described in OLSRv2. In > an ideal world this is another thing that should be in a separate draft. It > is designed for wider use (hence its inclusion of message type). There are > reasons I would find that a good model for what I'm going to call > son-of-AODV, whatever that ends up being based on and called. > - Unmutated (other than hop count/limit) messages work well with message > signatures described in 6622 for end to end verification. Mutating messages > are a bigger headache. They need either new signatures each hop, in which > case let's just not bother signing messages, but let's sign packets - a > valid choice, but loses a tool - or some sort of difference collecting and > aggregating signature that I know nothing about, and may not even exist. > > I'm guessing Thomas is against this case. But more details needed. (The IP > TTL being a separate issue is I think common ground.) > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > --bcaec50162bde326ae04cd74080a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Chris
=A0
A RREQ as rfc5444 message controlling= its dissimination by using hop-count with hop-limit. OLSRv2 messages SHOUL= D be handled differently than AODVv2 messages, even if they are both rfc544= 4 messages, because the protocol that uses RFC5444 format=A0is the only one= that can specify its messages types and handlings.
=A0
I do agree to use of signatures for rfc5444 packets only= in AODVv2,
=A0
AB

On Thu, Nov 1, 2012 at 1:50 PM, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:
I must be missing something here. I think I have an idea w= hat it is, but let's confirm.

Let's consider an RREQ message, which is flooded. The issue is, does it= mutate on its travels? If not, I don't see why we can't use the 54= 44 hop limit. If it does, then that is not technically an issue for 5444, b= ut does have two bad effects:
- There is a general processing/forwarding engine described in OLSRv2. In a= n ideal world this is another thing that should be in a separate draft. It = is designed for wider use (hence its inclusion of message type). There are = reasons I would find that a good model for what I'm going to call son-o= f-AODV, whatever that ends up being based on and called.
- Unmutated (other than hop count/limit) messages work well with message si= gnatures described in 6622 for end to end verification. Mutating messages a= re a bigger headache. They need either new signatures each hop, in which ca= se let's just not bother signing messages, but let's sign packets -= a valid choice, but loses a tool - or some sort of difference collecting a= nd aggregating signature that I know nothing about, and may not even exist.=

I'm guessing Thomas is against this case. But more details needed. (The= IP TTL being a separate issue is I think common ground.)

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245= 242194=A0| =A0Fax: +44 1245 242124
chris.dearlove@baesystems.= com | http://ww= w.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687
--bcaec50162bde326ae04cd74080a-- From jvasseur@cisco.com Thu Nov 1 12:33:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B394E21F93D0 for ; Thu, 1 Nov 2012 12:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.158 X-Spam-Level: X-Spam-Status: No, score=-10.158 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6C2ymnKCxFyN for ; Thu, 1 Nov 2012 12:33:47 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A8B3C21F93CA for ; Thu, 1 Nov 2012 12:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27454; q=dns/txt; s=iport; t=1351798426; x=1353008026; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DACjOqLOWmiFccSJ6ORinhJnibt29o4QnwBAFcw2ecQ=; b=dLmhPhORBjk9QNNv487pUMXQHUypMqHWoh3fwr4BgSstyCk3o6Pif0Vd EjZjq+ACxYnie0H1cAyAo2r4cGHyK64D3O8mo8TbKAuYqMaIrprlm3LPH AWDAXeiwgl0/Tj+awRVa4mPZtsxbFaW8oOsG4yCJ0NeTXzL+53KLxTpTY 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAJfNklCtJXG8/2dsb2JhbABEgkmvDJIbgQiCHgEBAQQBAQEPAVkCCAMQAgEIDgMDAQEBCxYHByEGCxMBCQgCBAENBQgTB4dSAw8LnFKWTg2JUASLFGcShUhhA5JGgV0EjQODJoFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,695,1344211200"; d="scan'208,217";a="137876564" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 01 Nov 2012 19:33:46 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA1JXjjc005391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 19:33:45 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 14:33:45 -0500 From: "JP Vasseur (jvasseur)" To: Don Sturek , "Charles E. Perkins" Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuGfOLPVi/cSo/ES1hdb7zda62w== Date: Thu, 1 Nov 2012 19:33:44 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722049C43@xmb-rcd-x02.cisco.com> References: <5092C033.1030604@computer.org> In-Reply-To: <5092C033.1030604@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.90.251] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--44.363500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722049C43xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: " List" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 19:33:48 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7722049C43xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable And if I may, =85 As Charlie pointed it out: "But I will say one more thing: I have the ability and now the time to do an excellent job on this, and I am here on the job only for the benefit of the working group. Now that I can focus on it, and now that I do not feel constrained to abide by the demands for delay that were imposed by the LOADng author team, I can do it pretty expediently. Of course I will welcome their input as well, and to further reiterate it will be my intention to make the WG document compatible with the needs of LOADng." As many of us, I truly believe that Charlie can make it happen and come up with the best solution for the reactive protocol in MANET, incorporating id= eas coming up from the WG, and close on this pretty quickly in a more peaceful atmosphere. Thanks. JP. On Nov 1, 2012, at 7:32 PM, Charles E. Perkins wrote: Hello Don, Your claim has been made several times, and I think it is highly misleading= . The bottom line is that the editorship of the WG document is now in good hands, and given the time available in the past, good progress has been made. Also given my renewed emphasis, support from my job, and clear understanding of goals, I can confidently state that I can do the work, and can manage the editorship process to follow working group discussion to completion. Here is (some of) what happened. I hope you will read it. I was asked last fall to resume editorship of the DYMO document, and agreed to do so. Almost at the same time, I was invited to work with the LOADng authors to produce a merged document that incorporated the best features from DYMO and from LOADng. At that time, the general agreement was that the merged document would be renamed AODVv2. Because of various personal difficulties unfamiliar in my experience, I was surprised to find very late in the winter that the merge was not happening. In order to carry out my responsibility, which was clearly to submit a revised document for IETF 83 in Paris, I took the resource available to me and within less than a week I submitted the revised DYMO draft renamed to be AODVv2. People attending the meeting will remember what happened. I was quite unjustly attacked and called names for doing: a) what I said I would do b) what I was supposed to do, and c) changing the document to become more compatible with LOADng, as requested by those authors and according to my best understanding. After that, I still hoped that we could do the merge, but nothing happened until in Vancouver when the WG chairs gave us an ultimatum to make something happen by November. We went around and around, but I eventually determined that there was almost no chance that the LOADng authors would willingly help to produce the desired merge. So I did what the LOADng authors had asked me not to do: namely submit a revised document for consideration. This revised document was an attempt to respond to valid comments made during 2010 about problems with the document while it was under Ian's editorial responsibility. It needs further revision -- in fact I will submit a much more polished document on my website this week. The important point is that for the last year the document languished for all but a few weeks *at the request of the LOADng authors* -- in fact, I would even say at their *DEMAND*, and all the while they refused to help make the merge that (a) they had originally suggested and (b) I was supposed to do. This note is already too long. I have much, much more to say. But I will say one more thing: I have the ability and now the time to do an excellent job on this, and I am here on the job only for the benefit of the working group. Now that I can focus on it, and now that I do not feel constrained to abide by the demands for delay that were imposed by the LOADng author team, I can do it pretty expediently. Of course I will welcome their input as well, and to further reiterate it will be my intention to make the WG document compatible with the needs of LOADng. Oh -- and one more thing... Regardless of the poisoned atmosphere surrounding this debate, I have nothing but high regard for the work done by the LOADng team. I don't think their methods are right for this working group, and any statements to the effect that the DYMO editorial process has been deficient during the last year or more should be understood in light of the above narrative. Regards, Charlie P. PS. Oh, and one more thing... I am a peaceful man, and if I don't respond to all the invective and intransigence so clearly in evidence lately, you'll just have to excuse me for trying to remain so. On 11/1/2012 9:40 AM, Don Sturek wrote: Hi Adbussalam, It is hard to consider a draft stalled 2+ years as the only way forward in = MANET as a reactive protocol. Don From: Abdussalam Baryun > Date: Thursday, November 1, 2012 8:53 AM To: Jon Black > Cc: "manet@ietf.org" >, Stan Ratliff > Subject: Re: [manet] Reactive Protocol Situation Yes LOADng is a reactive protocols, but not the MANET WG reactive protocol = (DYMO is already authorised). The WG is the only authorised to make such de= cisions for its WG drafts, if WG decides to add any LOADng ideas it can, or= to accept such merge it can as well, AB On Thu, Nov 1, 2012 at 3:37 PM, Jon Black > wrote: Why would you think that LOADng is not reactive? If it is not a reactive p= rotocol, then what is it? As to merging the documents, this is what WGs do. If you have multiple "co= mpeting" ideas you ask the authors to see if they can merge their concepts = and ideas. If they cannot or will not then the WG must decide based on fac= ts and not conjecture which is the most prudent path to take. Jon ________________________________ From: Abdussalam Baryun > To: Joseph Macker > Cc: manet@ietf.org; Stan Ratliff > Sent: Thursday, November 1, 2012 8:22 AM Subject: Re: [manet] Reactive Protocol Situation Dear Joseph Macker and Stan, MANET WG Chairs I disagree that the WG arranged/guided to merge the documents, I never hear= d that there was a consensus on such activity. DYMO is a reactive WG draft,= but LOADng is not. Why did you guide to merge documents, I recommend that = you ment to merge the team drafts co-authors to one WG draft (which is only= DYMO so far). The authority is for the WG to decide to merge individual dr= afts to its WG draft. Therefore, my vote is for option 1 only. Thanking you for updating us with = the status. Regards AB On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker > wrote: Hello MANET working group (form Stan and Joe), As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common documen= t effort and given positive feedback at the time we the chairs thought this= was the best approach given the authors potential to come together and gai= n the best of both efforts. Since that period, there has been some fairly = strident and rancorous "at times" debate between the authors of the two doc= uments. During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts = and LOADng had fairly active authorship and implementation efforts. We prov= ided a co-editing proposal to the authors and gave them the timeframe of th= e Atlanta to come up with an answer back to us regarding this. As of this = writing, those discussions of a potential commonn document and authorship m= erger have failed. Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss= ue at the present time. We see only 3 possible paths forward: 1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2. 2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document). 3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus. The co-chairs request and need your opinions on the options. We have been = some silent collecting initial feedback and waiting for author feedback at = this point. Stan and I are both on travel prior to Atlanta so our response= s may be sparse and we will also likely be in a "receive mode" for a few da= ys. So send your opinions. -Joe _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ie= tf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet -- Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7722049C43xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable And if I may, =85 

As Charlie pointed it out:

"But I will say one more thing: I have the ability and now the= time to
do an excellent job on this, and I am here on the job only for the
benefit of the working group.  Now that I can focus on it, and now
that I do not feel constrained to abide by the demands for delay
that were imposed by the LOADng author team, I can do it pretty
expediently.  Of course I will welcome their input as well, and to
further reiterate it will be my intention to make the WG document
compatible with the needs of LOADng."

As many of us, I truly believe that Charlie can make it happen and com= e up
with the best solution for the reactive protocol in MANET, incorporati= ng ideas
coming up from the WG, and close on this pretty quickly in a more peac= eful 
atmosphere.

Thanks.

JP.

On Nov 1, 2012, at 7:32 PM, Charles E. Perkins wrote:


Hello Don,

Your claim has been made several times, and I think it is highly misleading= .

The bottom line is that the editorship of the WG document is now in good hands, and given the time available in the past, good progress has been
made.  Also given my renewed emphasis, support from my job, and clear<= br> understanding of goals, I can confidently state that I can do the work, and=
can manage the editorship process to follow working group discussion to
completion.  Here is (some of) what happened.  I hope you will re= ad it.

I was asked last fall to resume editorship of the DYMO document, and
agreed to do so.

Almost at the same time, I was invited to work with the LOADng authors
to produce a merged document that incorporated the best features from
DYMO and from LOADng.  At that time, the general agreement was that the merged document would be renamed AODVv2.

Because of various personal difficulties unfamiliar in my experience, I was=
surprised to find very late in the winter that the merge was not happening.=
In order to carry out my responsibility, which was clearly to submit a
revised document for IETF 83 in Paris, I took the resource available to me<= br> and within less than a week I submitted the revised DYMO draft renamed
to be AODVv2.

People attending the meeting will remember what happened.  I was quite=
unjustly attacked and called names for doing:
a) what I said I would do
b) what I was supposed to do, and
c) changing the document to become more compatible with LOADng, as
    requested by those authors and according to my best unde= rstanding.

After that, I still hoped that we could do the merge, but nothing happened<= br> until in Vancouver when the WG chairs gave us an ultimatum to make
something happen by November.

We went around and around, but I eventually determined that there
was almost no chance that the LOADng authors would willingly help to
produce the desired merge.  So I did what the LOADng authors had asked=
me not to do: namely submit a revised document for consideration.
This revised document was an attempt to respond to valid comments
made during 2010 about problems with the document while it was
under Ian's editorial responsibility.  It needs further revision -- in= fact
I will submit a much more polished document on my website this
week.

The important point is that for the last year the document languished
for all but a few weeks *at the request of the LOADng authors* --
in fact, I would even say at their *DEMAND*, and all the while they
refused to help make the merge that (a) they had originally suggested
and (b) I was supposed to do.

This note is already too long.  I have much, much more to say.
But I will say one more thing: I have the ability and now the time to
do an excellent job on this, and I am here on the job only for the
benefit of the working group.  Now that I can focus on it, and now
that I do not feel constrained to abide by the demands for delay
that were imposed by the LOADng author team, I can do it pretty
expediently.  Of course I will welcome their input as well, and to
further reiterate it will be my intention to make the WG document
compatible with the needs of LOADng.

Oh -- and one more thing...  Regardless of the poisoned atmosphere
surrounding this debate, I have nothing but high regard for the work
done by the LOADng team.  I don't think their methods are right for this working group, and any statements to the effect that the DYMO
editorial process has been deficient during the last year or more
should be understood in light of the above narrative.

Regards,
Charlie P.

PS. Oh, and one more thing...  I am a peaceful man, and if I don't
        respond to all the invective and= intransigence so clearly
        in evidence lately, you'll just = have to excuse me for trying
        to remain so.


On 11/1/2012 9:40 AM, Don Sturek wrote:
Hi Adbussalam,

It is hard to consider a draft stalled 2+ years as the only way fo= rward in MANET as a reactive protocol.

Don



From: Abdussalam Baryun <abdussalamb= aryun@gmail.com>
Date: Thursday, November 1, 2012 8:= 53 AM
To: Jon Black <jblack.ietf@yahoo.com&= gt;
Cc: "manet@ietf.org" <manet@ietf.org>, Stan= Ratliff <sratliff@cisco.com>
Subject: Re: [manet] Reactive Proto= col Situation

Yes LOADng is a reactive protocols, but not the MANET WG reactive= protocol (DYMO is already authorised). The WG is the only authorised to ma= ke such decisions for its WG drafts, if WG decides to add any LOADng ideas = it can, or to accept such merge it can as well,
AB
On Thu, Nov 1, 2012 at 3:37 PM, Jon Black <jblack.ietf@yahoo.com> wrote:
Why would you think that LOADng is not reactive?  If it is not a react= ive protocol, then what is it?

As to merging the documents, this is what WGs do.  If you have multipl= e "competing" ideas you ask the authors to see if they can merge = their concepts and ideas.  If they cannot or will not then the WG must= decide based on facts and not conjecture which is the most prudent path to take.

Jon


From: Abdussalam Baryun <= abdussalambaryun@gmail.com>
To: Joseph Macker <= jpmacker@gmail.com>
Cc: manet@ietf.org; Stan Ratliff <sratliff@cisco.com>
Sent: Thursday, November 1, = 2012 8:22 AM

Subject: Re: [manet] Reactiv= e Protocol Situation

Dear Joseph Macker and Stan,
MANET WG Chairs
 
I disagree that the WG arranged/guided to merge the document= s, I never heard that there was a consensus on such activity. DYMO is a rea= ctive WG draft, but LOADng is not. Why did you guide to merge documents, I = recommend that you ment to merge the team drafts co-authors to one WG draft (which is only DYMO so far). The au= thority is for the WG to decide to merge individual drafts to its WG draft.=
 
Therefore, my vote is for option 1 only. Thanking you for updating us = with the status.
 
Regards
AB

On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker <= jpmacker@gmail.com> wrote:
Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.  Sin= ce that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active author= ship and implementation efforts. We provided a co-editing proposal to the a= uthors and gave them the timeframe of the Atlanta to come up with an answer= back to us regarding this.  As of this writing, those discussions of a potential commonn document and aut= horship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.  We s= ee only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have = been some silent collecting initial feedback and waiting for author feedbac= k at this point.  Stan and I are both on travel prior to Atlanta so ou= r responses may be sparse and we will also likely be in a "receive mode" for a few days.  So send your= opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listi= nfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet 

_______________________________________________
manet mailing list
manet@=
ietf.org
https://www.ietf.org/mailman/listinfo/manet



--=20
Regards,
Charlie P.
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A7722049C43xmbrcdx02ciscoc_-- From jvasseur@cisco.com Thu Nov 1 12:37:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C1621F9522 for ; Thu, 1 Nov 2012 12:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLvGO2-fuhB9 for ; Thu, 1 Nov 2012 12:36:58 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D861A21F8746 for ; Thu, 1 Nov 2012 12:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29391; q=dns/txt; s=iport; t=1351798618; x=1353008218; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2Hv6sip7SVResjlBadDa1I9y1Rsf7ck8jJcXR7vwUCU=; b=O8izPO/Z4IqEaMHcTXc+fvhmGZYwtzxbdHjaewwLYUaCupRi+ECnNFiG 0batieGoxoZCql0U7T8nAHLisKju4YjXKGH95cnZ5GEhTtXoJhW2AAvnH ju4y1yQCOfzmBiA1VQ9er8OJ4Eq5RIZTvwMAt/QDLAhkC1RY+X6mRq1gn 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAFzOklCtJV2c/2dsb2JhbABEgkmvDJIbgQiCHgEBAQQBAQEPAQdSAggDEAIBCA4DAwEBAQsWBwchBgsTAQkIAgQBDQUIARmHUgMPC5xUlk4FCIlUixRnCgiFSGEDkkaBXQSNA4MmgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,695,1344211200"; d="scan'208,217";a="134878282" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 01 Nov 2012 19:36:57 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA1JavAg027302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 19:36:57 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 14:36:56 -0500 From: "JP Vasseur (jvasseur)" To: Joe Macker , "Stan Ratliff (sratliff)" Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuGhALPVi/cSo/ES1hdb7zda62w== Date: Thu, 1 Nov 2012 19:36:55 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722049CC0@xmb-rcd-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.90.251] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--39.876900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722049CC0xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: " List" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 19:37:00 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7722049CC0xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Agree with you Don. Since discussions are going in many directions =85 would the chairs help us= organize these discussions ? Are you indeed asking us to express our preference for one of these options= , pick one and start from there ? On Nov 1, 2012, at 7:40 PM, Don Sturek wrote: Hi Charlie, Apologies if I misrepresented the facts on DYMO/AODVv2=85=85 I do think the facts as exist right now are: 1) We have a LOADng draft that claims support to address the MANET reactiv= e protocol requirements 2) Work has restarted (by yourself) on DYMO/AODVv2 3) There are two different views on the ability to merge LOADng with DYMO/= AODVv2. One view is the merge can happen and another (unfortunately by some= authors of LOADng) that such a merge is impractical. So, irrespective of how we got to where we are, the point is it is a good t= ime to draw a conclusion on which of the 3 options above MANET should take = to meet its requirement for a reactive routing protocol. Don From: "Charles E. Perkins" > Organization: Saratoga Blue Skies Date: Thursday, November 1, 2012 11:32 AM To: Don Sturek > Cc: "manet@ietf.org" > Subject: Re: [manet] Reactive Protocol Situation Hello Don, Your claim has been made several times, and I think it is highly misleading= . The bottom line is that the editorship of the WG document is now in good hands, and given the time available in the past, good progress has been made. Also given my renewed emphasis, support from my job, and clear understanding of goals, I can confidently state that I can do the work, and can manage the editorship process to follow working group discussion to completion. Here is (some of) what happened. I hope you will read it. I was asked last fall to resume editorship of the DYMO document, and agreed to do so. Almost at the same time, I was invited to work with the LOADng authors to produce a merged document that incorporated the best features from DYMO and from LOADng. At that time, the general agreement was that the merged document would be renamed AODVv2. Because of various personal difficulties unfamiliar in my experience, I was surprised to find very late in the winter that the merge was not happening. In order to carry out my responsibility, which was clearly to submit a revised document for IETF 83 in Paris, I took the resource available to me and within less than a week I submitted the revised DYMO draft renamed to be AODVv2. People attending the meeting will remember what happened. I was quite unjustly attacked and called names for doing: a) what I said I would do b) what I was supposed to do, and c) changing the document to become more compatible with LOADng, as requested by those authors and according to my best understanding. After that, I still hoped that we could do the merge, but nothing happened until in Vancouver when the WG chairs gave us an ultimatum to make something happen by November. We went around and around, but I eventually determined that there was almost no chance that the LOADng authors would willingly help to produce the desired merge. So I did what the LOADng authors had asked me not to do: namely submit a revised document for consideration. This revised document was an attempt to respond to valid comments made during 2010 about problems with the document while it was under Ian's editorial responsibility. It needs further revision -- in fact I will submit a much more polished document on my website this week. The important point is that for the last year the document languished for all but a few weeks *at the request of the LOADng authors* -- in fact, I would even say at their *DEMAND*, and all the while they refused to help make the merge that (a) they had originally suggested and (b) I was supposed to do. This note is already too long. I have much, much more to say. But I will say one more thing: I have the ability and now the time to do an excellent job on this, and I am here on the job only for the benefit of the working group. Now that I can focus on it, and now that I do not feel constrained to abide by the demands for delay that were imposed by the LOADng author team, I can do it pretty expediently. Of course I will welcome their input as well, and to further reiterate it will be my intention to make the WG document compatible with the needs of LOADng. Oh -- and one more thing... Regardless of the poisoned atmosphere surrounding this debate, I have nothing but high regard for the work done by the LOADng team. I don't think their methods are right for this working group, and any statements to the effect that the DYMO editorial process has been deficient during the last year or more should be understood in light of the above narrative. Regards, Charlie P. PS. Oh, and one more thing... I am a peaceful man, and if I don't respond to all the invective and intransigence so clearly in evidence lately, you'll just have to excuse me for trying to remain so. On 11/1/2012 9:40 AM, Don Sturek wrote: Hi Adbussalam, It is hard to consider a draft stalled 2+ years as the only way forward in = MANET as a reactive protocol. Don From: Abdussalam Baryun > Date: Thursday, November 1, 2012 8:53 AM To: Jon Black > Cc: "manet@ietf.org" >, Stan Ratliff > Subject: Re: [manet] Reactive Protocol Situation Yes LOADng is a reactive protocols, but not the MANET WG reactive protocol = (DYMO is already authorised). The WG is the only authorised to make such de= cisions for its WG drafts, if WG decides to add any LOADng ideas it can, or= to accept such merge it can as well, AB On Thu, Nov 1, 2012 at 3:37 PM, Jon Black > wrote: Why would you think that LOADng is not reactive? If it is not a reactive p= rotocol, then what is it? As to merging the documents, this is what WGs do. If you have multiple "co= mpeting" ideas you ask the authors to see if they can merge their concepts = and ideas. If they cannot or will not then the WG must decide based on fac= ts and not conjecture which is the most prudent path to take. Jon ________________________________ From: Abdussalam Baryun > To: Joseph Macker > Cc: manet@ietf.org; Stan Ratliff > Sent: Thursday, November 1, 2012 8:22 AM Subject: Re: [manet] Reactive Protocol Situation Dear Joseph Macker and Stan, MANET WG Chairs I disagree that the WG arranged/guided to merge the documents, I never hear= d that there was a consensus on such activity. DYMO is a reactive WG draft,= but LOADng is not. Why did you guide to merge documents, I recommend that = you ment to merge the team drafts co-authors to one WG draft (which is only= DYMO so far). The authority is for the WG to decide to merge individual dr= afts to its WG draft. Therefore, my vote is for option 1 only. Thanking you for updating us with = the status. Regards AB On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker > wrote: Hello MANET working group (form Stan and Joe), As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common documen= t effort and given positive feedback at the time we the chairs thought this= was the best approach given the authors potential to come together and gai= n the best of both efforts. Since that period, there has been some fairly = strident and rancorous "at times" debate between the authors of the two doc= uments. During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts = and LOADng had fairly active authorship and implementation efforts. We prov= ided a co-editing proposal to the authors and gave them the timeframe of th= e Atlanta to come up with an answer back to us regarding this. As of this = writing, those discussions of a potential commonn document and authorship m= erger have failed. Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss= ue at the present time. We see only 3 possible paths forward: 1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2. 2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document). 3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus. The co-chairs request and need your opinions on the options. We have been = some silent collecting initial feedback and waiting for author feedback at = this point. Stan and I are both on travel prior to Atlanta so our response= s may be sparse and we will also likely be in a "receive mode" for a few da= ys. So send your opinions. -Joe _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ie= tf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.orghttps://www.ietf.org/mailman/listinfo/= manet -- Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7722049CC0xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <56B741E286B9DD439EB1D2BDB1BFC143@cisco.com> Content-Transfer-Encoding: quoted-printable Agree with you Don.

Since discussions are going in many directions =85 would the chairs he= lp us organize these discussions ?

Are you indeed asking us to express our preference for one of these op= tions, pick one and start from there ?

On Nov 1, 2012, at 7:40 PM, Don Sturek wrote:

Hi Charlie,

Apologies if I misrepresented the facts on DYMO/AODVv2=85=85

I do think the facts as exist right now are:
1)  We have a LOADng draft that claims support to address the MAN= ET reactive protocol requirements
2)  Work has restarted (by yourself) on DYMO/AODVv2
3)  There are two different views on the ability to merge LOADng = with DYMO/AODVv2. One view is the merge can happen and another (unfortunate= ly by some authors of LOADng) that such a merge is impractical.

So, irrespective of how we got to where we are, the point is it is a g= ood time to draw a conclusion on which of the 3 options above MANET should = take to meet its requirement for a reactive routing protocol.

Don


From: "Charles E. Perkins"= ; <charliep@computer.org>= ;
Organization: Saratoga Blue Skies Date: Thursday, November 1, 2012 11= :32 AM
To: Don Sturek <d.sturek@att.net>
Cc: "manet@ietf.org" <man= et@ietf.org>
Subject: Re: [manet] Reactive Proto= col Situation


Hello Don,

Your claim has been made several times, and I think it is highly misleading= .

The bottom line is that the editorship of the WG document is now in good hands, and given the time available in the past, good progress has been
made.  Also given my renewed emphasis, support from my job, and clear<= br> understanding of goals, I can confidently state that I can do the work, and=
can manage the editorship process to follow working group discussion to
completion.  Here is (some of) what happened.  I hope you will re= ad it.

I was asked last fall to resume editorship of the DYMO document, and
agreed to do so.

Almost at the same time, I was invited to work with the LOADng authors
to produce a merged document that incorporated the best features from
DYMO and from LOADng.  At that time, the general agreement was that the merged document would be renamed AODVv2.

Because of various personal difficulties unfamiliar in my experience, I was=
surprised to find very late in the winter that the merge was not happening.=
In order to carry out my responsibility, which was clearly to submit a
revised document for IETF 83 in Paris, I took the resource available to me<= br> and within less than a week I submitted the revised DYMO draft renamed
to be AODVv2.

People attending the meeting will remember what happened.  I was quite=
unjustly attacked and called names for doing:
a) what I said I would do
b) what I was supposed to do, and
c) changing the document to become more compatible with LOADng, as
    requested by those authors and according to my best unde= rstanding.

After that, I still hoped that we could do the merge, but nothing happened<= br> until in Vancouver when the WG chairs gave us an ultimatum to make
something happen by November.

We went around and around, but I eventually determined that there
was almost no chance that the LOADng authors would willingly help to
produce the desired merge.  So I did what the LOADng authors had asked=
me not to do: namely submit a revised document for consideration.
This revised document was an attempt to respond to valid comments
made during 2010 about problems with the document while it was
under Ian's editorial responsibility.  It needs further revision -- in= fact
I will submit a much more polished document on my website this
week.

The important point is that for the last year the document languished
for all but a few weeks *at the request of the LOADng authors* --
in fact, I would even say at their *DEMAND*, and all the while they
refused to help make the merge that (a) they had originally suggested
and (b) I was supposed to do.

This note is already too long.  I have much, much more to say.
But I will say one more thing: I have the ability and now the time to
do an excellent job on this, and I am here on the job only for the
benefit of the working group.  Now that I can focus on it, and now
that I do not feel constrained to abide by the demands for delay
that were imposed by the LOADng author team, I can do it pretty
expediently.  Of course I will welcome their input as well, and to
further reiterate it will be my intention to make the WG document
compatible with the needs of LOADng.

Oh -- and one more thing...  Regardless of the poisoned atmosphere
surrounding this debate, I have nothing but high regard for the work
done by the LOADng team.  I don't think their methods are right for this working group, and any statements to the effect that the DYMO
editorial process has been deficient during the last year or more
should be understood in light of the above narrative.

Regards,
Charlie P.

PS. Oh, and one more thing...  I am a peaceful man, and if I don't
        respond to all the invective and= intransigence so clearly
        in evidence lately, you'll just = have to excuse me for trying
        to remain so.


On 11/1/2012 9:40 AM, Don Sturek wrote:
Hi Adbussalam,

It is hard to consider a draft stalled 2+ years as the only way fo= rward in MANET as a reactive protocol.

Don



From: Abdussalam Baryun <abdussalamb= aryun@gmail.com>
Date: Thursday, November 1, 2012 8:= 53 AM
To: Jon Black <jblack.ietf@yahoo.com&= gt;
Cc: "manet@ietf.org" <manet@ietf.org>, Stan= Ratliff <sratliff@cisco.com>
Subject: Re: [manet] Reactive Proto= col Situation

Yes LOADng is a reactive protocols, but not the MANET WG reactive= protocol (DYMO is already authorised). The WG is the only authorised to ma= ke such decisions for its WG drafts, if WG decides to add any LOADng ideas = it can, or to accept such merge it can as well,
AB
On Thu, Nov 1, 2012 at 3:37 PM, Jon Black <jblack.ietf@yahoo.com> wrote:
Why would you think that LOADng is not reactive?  If it is not a react= ive protocol, then what is it?

As to merging the documents, this is what WGs do.  If you have multipl= e "competing" ideas you ask the authors to see if they can merge = their concepts and ideas.  If they cannot or will not then the WG must= decide based on facts and not conjecture which is the most prudent path to take.

Jon


From: Abdussalam Baryun <= abdussalambaryun@gmail.com>
To: Joseph Macker <= jpmacker@gmail.com>
Cc: manet@ietf.org; Stan Ratliff <sratliff@cisco.com>
Sent: Thursday, November 1, = 2012 8:22 AM

Subject: Re: [manet] Reactiv= e Protocol Situation

Dear Joseph Macker and Stan,
MANET WG Chairs
 
I disagree that the WG arranged/guided to merge the document= s, I never heard that there was a consensus on such activity. DYMO is a rea= ctive WG draft, but LOADng is not. Why did you guide to merge documents, I = recommend that you ment to merge the team drafts co-authors to one WG draft (which is only DYMO so far). The au= thority is for the WG to decide to merge individual drafts to its WG draft.=
 
Therefore, my vote is for option 1 only. Thanking you for updating us = with the status.
 
Regards
AB

On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker <= jpmacker@gmail.com> wrote:
Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.  Sin= ce that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active author= ship and implementation efforts. We provided a co-editing proposal to the a= uthors and gave them the timeframe of the Atlanta to come up with an answer= back to us regarding this.  As of this writing, those discussions of a potential commonn document and aut= horship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.  We s= ee only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have = been some silent collecting initial feedback and waiting for author feedbac= k at this point.  Stan and I are both on travel prior to Atlanta so ou= r responses may be sparse and we will also likely be in a "receive mode" for a few days.  So send your= opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listi= nfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet 

_______________________________________________
manet mailing list
manet@=
ietf.orghttps://www.ietf.org/mailman/listinfo/manet



--=20
Regards,
Charlie P.
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A7722049CC0xmbrcdx02ciscoc_-- From abdussalambaryun@gmail.com Thu Nov 1 12:43:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0E921F94D3 for ; Thu, 1 Nov 2012 12:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tFhRlZltqTj for ; Thu, 1 Nov 2012 12:43:47 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B81121F9439 for ; Thu, 1 Nov 2012 12:43:47 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3413039vcb.31 for ; Thu, 01 Nov 2012 12:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gg1SpBvF9eAMKLy7a1noU8epBy1T6pHXW9Hm55iPxeg=; b=Si3TCcBtJY4qNq+1Y94gJmKEPfq/M7bgorD6O0OLWe2r/4Wd/1ZJyaY3WRwmcga+tJ b12tVI6yDj9srJPyh2G/JCcrmrf7fp72Dpszr4WiHI1+zW3dNFgPDkso/gHIKL3Zcn5n C/SIoD3/Q16/h7JUs7VKOzvWRMbD6sFhQbKuSrMfntk+/DT2ozTWT5TQHVuI/1HBhgVC Z6WjoNUbP15vdnZmW1tauQdEFjw2/E5jNrrLuVVbMgFjl5hwQoF2PLftGK5CEF0XYOQN 3U+gLAsYeM6/BEuqApB2DA0EvpSPleQlrzZE9kJU2pbD6sf1k/66rCqQaKi2iOPg9Phu Kq2A== MIME-Version: 1.0 Received: by 10.52.35.82 with SMTP id f18mr51913725vdj.99.1351799026937; Thu, 01 Nov 2012 12:43:46 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 12:43:46 -0700 (PDT) In-Reply-To: <061.9ade0aa6aa05287725babd1e29bd3153@trac.tools.ietf.org> References: <061.9ade0aa6aa05287725babd1e29bd3153@trac.tools.ietf.org> Date: Thu, 1 Nov 2012 19:43:46 +0000 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: multipart/alternative; boundary=20cf307c9fbeceef1f04cd743c10 Subject: Re: [manet] #2: Terminology for reactive protocol document X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 19:43:48 -0000 --20cf307c9fbeceef1f04cd743c10 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I always supported that terminology documents SHOULD be considered in all IETF WGs, and also I noted in my input the reasons for unclear issues, because of terms and some detail information which I got to understand after DYMO authors reply. However, I do encourge using similar terms within all MANET WG documents, however, terms definitions should relate to such specifications. AB On Tue, Oct 30, 2012 at 5:42 PM, manet issue tracker < trac+manet@trac.tools.ietf.org> wrote: > #2: Terminology for reactive protocol document > > Several people have commented that the DYMO/AODVv2 specification is hard > to understand. Part of the problem is that the terminology is not alway= s > consistent with the terminology used in other documents (e.g., OLSRv2). > Also, some of the language used in the document is not very natural. > Finally, important datasets within the reactive protocol document should > be identified and used consistently within the specification. As one > example, the fields of a Route Table Entry are already listed in section > 4.1. Other such datasets should be identified and made more precise (fo= r > instance, as may be needed for blacklisted neighbors). Another possible > source of confusion is that some terms (e.g., OrigNode) might be thought > to mean different things in different parts of the document. > > The proposal is to use terminology from OLSRv2 where appropriate, and to > change the names of other important concepts within the reactive protoco= l > wherever they may be unclear, and to attempt to use terms that mean the > same thing throughout the document. > > -- > --------------------------------+--------------------------------- > Reporter: charliep@=85 | Owner: Charlie Perkins > Type: enhancement | Status: new > Priority: major | Milestone: > Component: dymo | Version: > Severity: Active WG Document | Keywords: terminology clarity > --------------------------------+--------------------------------- > > Ticket URL: > manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf307c9fbeceef1f04cd743c10 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I always supported that terminology documents=A0SHOULD be considered i= n all IETF=A0WGs, and also I noted in my input the reasons for unclear issu= es,=A0because of terms and some detail information which I got to understan= d after DYMO authors reply. However, I do encourge using similar=A0terms wi= thin all MANET WG documents, however, terms definitions should relate to su= ch specifications.
=A0
AB

On Tue, Oct 3= 0, 2012 at 5:42 PM, manet issue tracker <trac+manet@trac.tool= s.ietf.org> wrote:
#2: Terminology for reactive protocol document

=A0Several people have commented that the DYMO/AODVv2 specification is hard=
=A0to understand. =A0Part of the problem is that the terminology is not alw= ays
=A0consistent with the terminology used in other documents (e.g., OLSRv2).<= br> =A0Also, some of the language used in the document is not very natural.
=A0Finally, important datasets within the reactive protocol document should=
=A0be identified and used consistently within the specification. =A0As one<= br> =A0example, the fields of a Route Table Entry are already listed in section=
=A04.1. =A0Other such datasets should be identified and made more precise (= for
=A0instance, as may be needed for blacklisted neighbors). =A0Another possib= le
=A0source of confusion is that some terms (e.g., OrigNode) might be thought=
=A0to mean different things in different parts of the document.

=A0The proposal is to use terminology from OLSRv2 where appropriate, and to=
=A0change the names of other important concepts within the reactive protoco= l
=A0wherever they may be unclear, and to attempt to use terms that mean the<= br> =A0same thing throughout the document.

--
--------------------------------+---------------------------------
=A0Reporter: =A0charliep@=85 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Owner: =A0Char= lie Perkins
=A0 =A0 =A0Type: =A0enhancement =A0 =A0 =A0 =A0 | =A0 =A0 Status: =A0new =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0Milestone:
Component: =A0dymo =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Version:
=A0Severity: =A0Active WG Document =A0| =A0 Keywords: =A0terminology clarit= y
--------------------------------+---------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/2&= gt;
manet <http:/= /tools.ietf.org/manet/>

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf307c9fbeceef1f04cd743c10-- From yi.jiazi@gmail.com Thu Nov 1 13:02:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB09F21F95D8 for ; Thu, 1 Nov 2012 13:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qd7Soets4qd4 for ; Thu, 1 Nov 2012 13:02:18 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0266A21F914A for ; Thu, 1 Nov 2012 13:02:17 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1372879wgb.13 for ; Thu, 01 Nov 2012 13:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=poPRzBKl/36pWfi49F0ujCCmiph/tgeZue1B975CJSc=; b=sumr2K7qqn6N88eGfbbwEzDOr+DP5OwC/l6jWW36BPndkjbZPbKdiJ7isxUtkIHCkn I/sxotQtTO18V+zFt9sP/A5WWGxpYbsKieS3/XywpCfyUuPt/BhnWquwuYitJfIdoiId U4HpWZ5MRkSukBZry3Qe3WbJoX4TSyw3zOagLjE8zd4KK+hqp8frf9eJREM0cedm26Qf 6UeQfEVXT/cTpCcevxUquGOqVXLpvh3KVJ/x2nyLCEwKsY+u/HvmoQ50QZPIkz2QLexl DXwU/W7jdtLCRufDu/lh5NW+UY0BFwjshs4Cf6F1+L0JRydkpdv4Exe9yAcGftidbvPp +04w== Received: by 10.180.99.194 with SMTP id es2mr3421789wib.15.1351800136365; Thu, 01 Nov 2012 13:02:16 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id bn7sm364292wib.8.2012.11.01.13.02.12 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Nov 2012 13:02:15 -0700 (PDT) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_E3261044-DE14-4A69-A713-DB3686F27569" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi YI In-Reply-To: <5092C033.1030604@computer.org> Date: Thu, 1 Nov 2012 21:02:11 +0100 Message-Id: <7A45F5D9-F2CC-4459-9AFB-299101A7CBE7@jiaziyi.com> References: <5092C033.1030604@computer.org> To: "Charles E. Perkins" X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 20:02:24 -0000 --Apple-Mail=_E3261044-DE14-4A69-A713-DB3686F27569 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dear Charlie, Don, and all, The LOADng authors never said that the merge can't come, and always = welcome good ideas from DYMO. However, having LOADng to fit in DYMO text = is rolling back to 2 years ago and is totally inappropriate because of = the quality of the current dymo document. =20 There was a long discussion on this in the last three months, but it's = unconstructive to repeat the history here.=20 Charlie, I really don't want to talk about the editorial process and = authorship issue in the mailing list, so please, let's stop this topic = here.=20 I think for the moment, the constructive way is to go back to the = technical discussion and check the status of those two drafts, as = suggested by Chris and a lot of the others.=20 I would appreciate all the WG participants reading those two drafts, and = I'm looking forward to your comments. Personally, I have reviewed the = latest dymo revision, but I would like to keep my comments and hear the = opinions from other non-LOADng authors first.=20 best Jiazi On Nov 1, 2012, at 7:32 PM, "Charles E. Perkins" = wrote: >=20 > Hello Don, >=20 > Your claim has been made several times, and I think it is highly = misleading. >=20 > The bottom line is that the editorship of the WG document is now in = good > hands, and given the time available in the past, good progress has = been > made. Also given my renewed emphasis, support from my job, and clear > understanding of goals, I can confidently state that I can do the = work, and > can manage the editorship process to follow working group discussion = to > completion. Here is (some of) what happened. I hope you will read = it. >=20 > I was asked last fall to resume editorship of the DYMO document, and > agreed to do so. >=20 > Almost at the same time, I was invited to work with the LOADng authors > to produce a merged document that incorporated the best features from > DYMO and from LOADng. At that time, the general agreement was that > the merged document would be renamed AODVv2. >=20 > Because of various personal difficulties unfamiliar in my experience, = I was > surprised to find very late in the winter that the merge was not = happening. > In order to carry out my responsibility, which was clearly to submit a > revised document for IETF 83 in Paris, I took the resource available = to me > and within less than a week I submitted the revised DYMO draft renamed > to be AODVv2. >=20 > People attending the meeting will remember what happened. I was quite > unjustly attacked and called names for doing: > a) what I said I would do > b) what I was supposed to do, and > c) changing the document to become more compatible with LOADng, as > requested by those authors and according to my best understanding. >=20 > After that, I still hoped that we could do the merge, but nothing = happened > until in Vancouver when the WG chairs gave us an ultimatum to make > something happen by November. >=20 > We went around and around, but I eventually determined that there > was almost no chance that the LOADng authors would willingly help to > produce the desired merge. So I did what the LOADng authors had asked > me not to do: namely submit a revised document for consideration. > This revised document was an attempt to respond to valid comments > made during 2010 about problems with the document while it was > under Ian's editorial responsibility. It needs further revision -- in = fact > I will submit a much more polished document on my website this > week. >=20 > The important point is that for the last year the document languished > for all but a few weeks *at the request of the LOADng authors* -- > in fact, I would even say at their *DEMAND*, and all the while they > refused to help make the merge that (a) they had originally suggested > and (b) I was supposed to do. >=20 > This note is already too long. I have much, much more to say.=20 > But I will say one more thing: I have the ability and now the time to > do an excellent job on this, and I am here on the job only for the > benefit of the working group. Now that I can focus on it, and now > that I do not feel constrained to abide by the demands for delay > that were imposed by the LOADng author team, I can do it pretty > expediently. Of course I will welcome their input as well, and to > further reiterate it will be my intention to make the WG document > compatible with the needs of LOADng. >=20 > Oh -- and one more thing... Regardless of the poisoned atmosphere > surrounding this debate, I have nothing but high regard for the work > done by the LOADng team. I don't think their methods are right for > this working group, and any statements to the effect that the DYMO > editorial process has been deficient during the last year or more > should be understood in light of the above narrative. >=20 > Regards, > Charlie P. >=20 > PS. Oh, and one more thing... I am a peaceful man, and if I don't > respond to all the invective and intransigence so clearly > in evidence lately, you'll just have to excuse me for trying > to remain so. >=20 >=20 > On 11/1/2012 9:40 AM, Don Sturek wrote: >> Hi Adbussalam, >>=20 >> It is hard to consider a draft stalled 2+ years as the only way = forward in MANET as a reactive protocol. >>=20 >> Don >>=20 >>=20 >>=20 >> From: Abdussalam Baryun >> Date: Thursday, November 1, 2012 8:53 AM >> To: Jon Black >> Cc: "manet@ietf.org" , Stan Ratliff = >> Subject: Re: [manet] Reactive Protocol Situation >>=20 >> Yes LOADng is a reactive protocols, but not the MANET WG reactive = protocol (DYMO is already authorised). The WG is the only authorised to = make such decisions for its WG drafts, if WG decides to add any LOADng = ideas it can, or to accept such merge it can as well, >> AB >> On Thu, Nov 1, 2012 at 3:37 PM, Jon Black = wrote: >> Why would you think that LOADng is not reactive? If it is not a = reactive protocol, then what is it? >>=20 >> As to merging the documents, this is what WGs do. If you have = multiple "competing" ideas you ask the authors to see if they can merge = their concepts and ideas. If they cannot or will not then the WG must = decide based on facts and not conjecture which is the most prudent path = to take. >>=20 >> Jon >>=20 >>=20 >> From: Abdussalam Baryun >> To: Joseph Macker =20 >> Cc: manet@ietf.org; Stan Ratliff =20 >> Sent: Thursday, November 1, 2012 8:22 AM >>=20 >> Subject: Re: [manet] Reactive Protocol Situation >>=20 >> Dear Joseph Macker and Stan, >> MANET WG Chairs >> =20 >> I disagree that the WG arranged/guided to merge the documents, I = never heard that there was a consensus on such activity. DYMO is a = reactive WG draft, but LOADng is not. Why did you guide to merge = documents, I recommend that you ment to merge the team drafts co-authors = to one WG draft (which is only DYMO so far). The authority is for the WG = to decide to merge individual drafts to its WG draft. >> =20 >> Therefore, my vote is for option 1 only. Thanking you for updating us = with the status. >> =20 >> Regards >> AB >>=20 >> On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker = wrote: >> Hello MANET working group (form Stan and Joe), >>=20 >> As you are all probably aware, there has been WG activity lately on = competing drafts for a MANET reactive protocol - DYMO (reviving the = current working group document that was parked due to inactivity), and = LOADng. Many months ago there was a somewhat authorship led movement = towards a common document effort and given positive feedback at the time = we the chairs thought this was the best approach given the authors = potential to come together and gain the best of both efforts. Since = that period, there has been some fairly strident and rancorous "at = times" debate between the authors of the two documents. >>=20 >> During IETF 84 in Vancouver, the co-chairs held a discussion with = some of the co-authors of the two documents. Our guidance to the = co-authors was to find a way to merge the two documents into one, as it = was perceived that are not technically far apart and they both derive = roughly from AODV concepts and LOADng had fairly active authorship and = implementation efforts. We provided a co-editing proposal to the authors = and gave them the timeframe of the Atlanta to come up with an answer = back to us regarding this. As of this writing, those discussions of a = potential commonn document and authorship merger have failed. >>=20 >> Therefore, we find ourselves at a crossroads. The authors of the two = documents are divided, and it is unlikely that progress on a merged = document can be reached based upon recent author feedback. I have also = polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat = disengaged on the issue at the present time. We see only 3 possible = paths forward: >>=20 >> 1. Continue the work on the DYMO document, starting with whether = there is consensus on its continued approach and also the desire to = rename it to AODVv2. >> 2. Replace the existing DYMO document effort with the LOADng related = document effort, defusing ealier references to LLNs as recommended in = the last meeting minutes, and to focus more motivationally on general = MANET problem spaces (the authors seem to have agreed to this issue if = its a WG document). >> 3. Remove the working group charter for a reactive protocol, = effectively killing both documents, at least from a working group (WG) = standpoint. This would not be a reflection on the technology in either = case, just an admission that we are not working together and reaching = consensus. >>=20 >> The co-chairs request and need your opinions on the options. We have = been some silent collecting initial feedback and waiting for author = feedback at this point. Stan and I are both on travel prior to Atlanta = so our responses may be sparse and we will also likely be in a "receive = mode" for a few days. So send your opinions. >>=20 >> -Joe >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >> _______________________________________________ manet mailing list = manet@ietf.org https://www.ietf.org/mailman/listinfo/manet=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > --=20 > Regards, > Charlie P. > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_E3261044-DE14-4A69-A713-DB3686F27569 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Dear Charlie, Don, and = all,

The LOADng authors never said = that the merge can't come, and always welcome good ideas from DYMO. = However, having LOADng to fit in DYMO text is rolling back to 2 years = ago and is totally inappropriate because of the quality of the current = dymo document.  
There = was a long discussion on this in the last three months, but it's = unconstructive to repeat the history here. 

Charlie, I really don't want to = talk about the editorial process and authorship issue in the mailing = list, so please, let's stop this topic here. 

I think for the moment, the = constructive way is to go back to the technical discussion and check the = status of those two drafts, as suggested by Chris and a lot of the = others. 
I = would appreciate all the WG participants reading those two drafts, and = I'm looking forward to your comments. Personally, I have reviewed the = latest dymo revision, but I would like to keep my comments and hear the = opinions from other non-LOADng authors first. 

best

Jiazi


On Nov 1, 2012, at 7:32 PM, "Charles E. Perkins" <charliep@computer.org> = wrote:

=20 =20

Hello Don,

Your claim has been made several times, and I think it is highly misleading.

The bottom line is that the editorship of the WG document is now in good
hands, and given the time available in the past, good progress has been
made.  Also given my renewed emphasis, support from my job, = and clear
understanding of goals, I can confidently state that I can do the work, and
can manage the editorship process to follow working group discussion to
completion.  Here is (some of) what happened.  I hope = you will read it.

I was asked last fall to resume editorship of the DYMO document, and
agreed to do so.

Almost at the same time, I was invited to work with the LOADng authors
to produce a merged document that incorporated the best features from
DYMO and from LOADng.  At that time, the general agreement = was that
the merged document would be renamed AODVv2.

Because of various personal difficulties unfamiliar in my experience, I was
surprised to find very late in the winter that the merge was not happening.
In order to carry out my responsibility, which was clearly to submit a
revised document for IETF 83 in Paris, I took the resource available to me
and within less than a week I submitted the revised DYMO draft renamed
to be AODVv2.

People attending the meeting will remember what happened.  I = was quite
unjustly attacked and called names for doing:
a) what I said I would do
b) what I was supposed to do, and
c) changing the document to become more compatible with LOADng, = as
    requested by those authors and according to my = best understanding.

After that, I still hoped that we could do the merge, but nothing happened
until in Vancouver when the WG chairs gave us an ultimatum to = make
something happen by November.

We went around and around, but I eventually determined that = there
was almost no chance that the LOADng authors would willingly help to
produce the desired merge.  So I did what the LOADng authors = had asked
me not to do: namely submit a revised document for = consideration.
This revised document was an attempt to respond to valid = comments
made during 2010 about problems with the document while it was
under Ian's editorial responsibility.  It needs further = revision -- in fact
I will submit a much more polished document on my website this
week.

The important point is that for the last year the document languished
for all but a few weeks *at the request of the LOADng authors* = --
in fact, I would even say at their *DEMAND*, and all the while they
refused to help make the merge that (a) they had originally suggested
and (b) I was supposed to do.

This note is already too long.  I have much, much more to = say.
But I will say one more thing: I have the ability and now the time to
do an excellent job on this, and I am here on the job only for = the
benefit of the working group.  Now that I can focus on it, = and now
that I do not feel constrained to abide by the demands for = delay
that were imposed by the LOADng author team, I can do it = pretty
expediently.  Of course I will welcome their input as well, = and to
further reiterate it will be my intention to make the WG = document
compatible with the needs of LOADng.

Oh -- and one more thing...  Regardless of the poisoned = atmosphere
surrounding this debate, I have nothing but high regard for the work
done by the LOADng team.  I don't think their methods are = right for
this working group, and any statements to the effect that the = DYMO
editorial process has been deficient during the last year or = more
should be understood in light of the above narrative.

Regards,
Charlie P.

PS. Oh, and one more thing...  I am a peaceful man, and if I = don't
        respond to all the = invective and intransigence so clearly
        in evidence lately, = you'll just have to excuse me for trying
        to remain so.


On 11/1/2012 9:40 AM, Don Sturek wrote:
Hi Adbussalam,

It is hard to consider a draft stalled 2+ years as the only way forward in MANET as a reactive protocol.

Don



From: Abdussalam Baryun <abdussalambaryun@gmail.com&= gt;
Date: Thursday, November 1, 2012 8:53 AM
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@ietf.org>, Stan Ratliff <sratliff@cisco.com>
Subject: Re: [manet] Reactive Protocol Situation

Yes LOADng is a reactive protocols, but not the = MANET WG reactive protocol (DYMO is already authorised). The WG is the only authorised to make such decisions for its WG drafts, if WG decides to add any LOADng ideas it can, or to accept such merge it can as well,
AB
On Thu, Nov 1, 2012 at 3:37 PM, Jon Black <jblack.ietf@yahoo.com> wrote:
Why would you think that LOADng is not reactive?  If it is not a = reactive protocol, then what is it?

As to merging the documents, this is what WGs do.  = If you have multiple "competing" ideas you ask the authors to see if they can merge their concepts and ideas.  = If they cannot or will not then the WG must decide based on facts and not conjecture which is the most prudent path to take.

Jon


From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To:= Joseph Macker <jpmacker@gmail.com>
Cc:= manet@ietf.org; Stan Ratliff <sratliff@cisco.com>
Sent: Thursday, November 1, 2012 8:22 AM

Subject: Re: [manet] Reactive Protocol Situation

Dear Joseph Macker and Stan,
MANET WG Chairs
 
I disagree that = the WG arranged/guided to merge the documents, I never heard that there was a consensus on such activity. DYMO is a reactive WG draft, but LOADng is not. Why did you guide to merge documents, I recommend that you ment to merge the team drafts co-authors to one WG draft = (which is only DYMO so far). The authority is for the WG to decide to merge individual drafts to its WG draft.
 
Therefore, my vote is for option 1 only. Thanking you for updating us with the status.
 
Regards
AB

On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker <jpmacker@gmail.com> wrote:
Hello MANET working group (form Stan and = Joe),

As you are all probably aware, there has been WG activity lately on competing drafts for a MANET reactive protocol - DYMO (reviving the current working group document that was parked due to inactivity), and LOADng. Many months ago there was a somewhat authorship led movement towards a common document effort and given positive feedback at the time we the chairs thought this was the best approach given the authors potential to come together and gain the best of both efforts.  Since that period, there = has been some fairly strident and rancorous "at times" debate between the authors of the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of the co-authors of the two documents. Our guidance to the co-authors was to find a way to merge the two documents into one, as it was perceived that are not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active authorship and implementation efforts. We provided a co-editing proposal to the authors and gave them the timeframe of the Atlanta to come up with an answer back to us regarding this.  As of this writing, = those discussions of a potential commonn document and authorship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two documents are divided, and it is unlikely that progress on a merged document can be reached based upon recent author feedback. I have also polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.  We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is consensus on its continued approach and also the desire to rename it to AODVv2.
2. Replace the existing DYMO document effort with the LOADng related document effort, defusing ealier references to LLNs as recommended in the last meeting minutes, and to focus more motivationally on general MANET problem spaces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively killing both documents, at least from a working group (WG) standpoint. This would not be a reflection on the technology in either case, just an admission that we are not working together and reaching = consensus.

The co-chairs request and need your opinions on the options.  We have = been some silent collecting initial feedback and waiting for author feedback at this point.  Stan and I are both on travel prior to Atlanta so our responses may be sparse and we will also likely be in a "receive mode" for a few days.  So = send your opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



= _______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/= mailman/listinfo/manet 

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/=
mailman/listinfo/manet



--=20
Regards,
Charlie P.
_______________________________________________
manet mailing = list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= --Apple-Mail=_E3261044-DE14-4A69-A713-DB3686F27569-- From abdussalambaryun@gmail.com Thu Nov 1 13:02:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861FA21F95D0 for ; Thu, 1 Nov 2012 13:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPcpRo13WCGe for ; Thu, 1 Nov 2012 13:02:43 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A41221F959C for ; Thu, 1 Nov 2012 13:02:42 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3432814vcb.31 for ; Thu, 01 Nov 2012 13:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=eNOPjZFyNLvYOg4/ghVj0IFw5Ybs3lG/iQYJlGmkz+4=; b=bMirSPPGPGu/eScuZHfvnPaIZ86bQRLyCG1Dgx/uuQlX9ZFWfnPyLCRVIYXmddel+C jZLWXNWGrtpTkOJpRGYGAC3wqRJyXKmzEHDey3ejQSd1YaGWfMQP92LGF0gCl8NWj8iT FowCnXLcnZLYl5rEj7czNXLmeWxExwZxQNeN5Pdxl3rVu/pgU2TWYFLwF5NimEyGXgrs lYB4neDbXQaCqutOU2oRHXhrU985Ewso8Pr9HfK3V9vrMej7xxIhrazWUrMF73K+3H3K bI9MK6qNvaskQeiwGgdkueeoxN38UgVYXM2KDDG21HxNug5gpqVTtHtfX0h6+ABEviz7 GOQg== MIME-Version: 1.0 Received: by 10.52.77.101 with SMTP id r5mr52236898vdw.25.1351800162083; Thu, 01 Nov 2012 13:02:42 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 13:02:40 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722049CC0@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A7722049CC0@xmb-rcd-x02.cisco.com> Date: Thu, 1 Nov 2012 20:02:40 +0000 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=20cf307abd9377e18504cd7480eb Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 20:02:43 -0000 --20cf307abd9377e18504cd7480eb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In IETF F2F meetings: I RECOMMEND the chairs and ADs to organise forces/efforts discuss WG's I-Ds for progress. New proposals should be presented once and discussed on the list if rejected. On the IETF WG lists: I RECOMMEMD the WG participants to discuss all related technical issues in good faith, detail and reason, to avoid politics and interrupts in IETF from others. AB On Thu, Nov 1, 2012 at 7:36 PM, JP Vasseur (jvasseur) w= rote: > Agree with you Don. > > Since discussions are going in many directions =85 would the chairs help > us organize these discussions ? > > Are you indeed asking us to express our preference for one of these > options, pick one and start from there ? > > On Nov 1, 2012, at 7:40 PM, Don Sturek wrote: > > Hi Charlie, > > Apologies if I misrepresented the facts on DYMO/AODVv2=85=85 > > I do think the facts as exist right now are: > 1) We have a LOADng draft that claims support to address the MANET > reactive protocol requirements > 2) Work has restarted (by yourself) on DYMO/AODVv2 > 3) There are two different views on the ability to merge LOADng with > DYMO/AODVv2. One view is the merge can happen and another (unfortunately = by > some authors of LOADng) that such a merge is impractical. > > So, irrespective of how we got to where we are, the point is it is a > good time to draw a conclusion on which of the 3 options above MANET shou= ld > take to meet its requirement for a reactive routing protocol. > > Don > > --20cf307abd9377e18504cd7480eb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
In=A0IETF F2F meetings: I RECOMMEND the chairs and ADs to organise for= ces/efforts discuss=A0WG's =A0I-Ds for progress. New proposals should b= e presented once and discussed on the list if rejected.

On th= e IETF WG lists: I RECOMMEMD the WG participants to discuss all related tec= hnical issues in good faith, detail and reason, to avoid politics and inter= rupts in IETF from=A0others.
=A0
AB
On Thu, Nov 1, 20= 12 at 7:36 PM, JP Vasseur (jvasseur) <jvasseur@cisco.com> w= rote:
Agree with you Don.

Since discussions are going in many directions =85 would the chairs he= lp us organize these discussions ?

Are you indeed asking us to express our preference for one of these op= tions, pick one and start from there ?

On Nov 1, 2012, at 7:40 PM, Don Sturek wrote:

Hi Charlie,

Apologies if I misrepresented the facts on DYMO/AODVv2=85=85

I do think the facts as exist right now are:
1) =A0We have a LOADng draft that claims support to address the MANET = reactive protocol requirements
2) =A0Work has restarted (by yourself) on DYMO/AODVv2
3) =A0There are two different views on the ability to merge LOADng wit= h DYMO/AODVv2. One view is the merge can happen and another (unfortunately = by some authors of LOADng) that such a merge is impractical.

So, irrespective of how we got to where we are, the point is it is a g= ood time to draw a conclusion on which of the 3 options above MANET should = take to meet its requirement for a reactive routing protocol.

Don

--20cf307abd9377e18504cd7480eb-- From abdussalambaryun@gmail.com Thu Nov 1 13:09:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5BD21F962F for ; Thu, 1 Nov 2012 13:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKyHr3qg7mqF for ; Thu, 1 Nov 2012 13:09:16 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3FBD21F9637 for ; Thu, 1 Nov 2012 13:09:15 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3440012vcb.31 for ; Thu, 01 Nov 2012 13:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ut+AYV0jwbfczavt+fU0Lq8LGJiGhXcf/k0h8Dvji4Q=; b=WWQ3eWaubjxBHf7CkrXGawmcm9PCF3hIi3MPVNbgB8Y0Erq9AJAXOCF4XR288ORl/q ZuDa1mj1VAW2Vsdc8ow3Ysh7XgAE9+XGlLamx6I8mqeCb4mrR/DUFchYWaBtQi4AeSGm dwXTViALlXBIGFdWTaw35Noc0G6tvERv0jKbQU16azJlrHkoj+ZpT4W4rI+SiX4hszcb mps1zK36y2v2ikErEF2eo8/5nS9Cqwi3qJA+lHXau2twsiTZ9fxWBlQnzMXeaIoNaMYX vAxHvomlrgMj1xU0MDwwTF7WIkP3OH5jtnCLCZWN76hy+4CouFmr5uVJkKlPGlZlQZY1 77Jg== MIME-Version: 1.0 Received: by 10.52.90.99 with SMTP id bv3mr52095410vdb.125.1351800554313; Thu, 01 Nov 2012 13:09:14 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 13:09:13 -0700 (PDT) In-Reply-To: <7A45F5D9-F2CC-4459-9AFB-299101A7CBE7@jiaziyi.com> References: <5092C033.1030604@computer.org> <7A45F5D9-F2CC-4459-9AFB-299101A7CBE7@jiaziyi.com> Date: Thu, 1 Nov 2012 20:09:13 +0000 Message-ID: From: Abdussalam Baryun To: Jiazi YI Content-Type: multipart/alternative; boundary=20cf307f3bccd8d84d04cd749701 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 20:09:18 -0000 --20cf307f3bccd8d84d04cd749701 Content-Type: text/plain; charset=ISO-8859-1 I disagree with you of the process to handle such WORK flow. I RECOMMEND the work flow for the MANET WG is to focus on the WG I-Ds only and try to target the Milestones without any interrupt of other organisations than IETF participants. I think the procedure and best practice is to give more time/efforts to DYMO/AODVv2, because we had RFC3561 and we are getting to complete the AODVv2 standard. I agree to make comparison of both drafts *only* to make LOADng authors to respond to the MANET WG requests and mine to discuss on the MANET list. AB On Thu, Nov 1, 2012 at 8:02 PM, Jiazi YI wrote: > Dear Charlie, Don, and all, > > The LOADng authors never said that the merge can't come, and always > welcome good ideas from DYMO. However, having LOADng to fit in DYMO text is > rolling back to 2 years ago and is totally inappropriate because of the > quality of the current dymo document. > There was a long discussion on this in the last three months, but it's > unconstructive to repeat the history here. > > Charlie, I really don't want to talk about the editorial process and > authorship issue in the mailing list, so please, let's stop this topic > here. > > I think for the moment, the constructive way is to go back to the > technical discussion and check the status of those two drafts, as suggested > by Chris and a lot of the others. > I would appreciate all the WG participants reading those two drafts, and > I'm looking forward to your comments. Personally, I have reviewed the > latest dymo revision, but I would like to keep my comments and hear the > opinions from other non-LOADng authors first. > > best > > Jiazi > > > > On Nov 1, 2012, at 7:32 PM, "Charles E. Perkins" > wrote: > > > Hello Don, > > Your claim has been made several times, and I think it is highly > misleading. > > The bottom line is that the editorship of the WG document is now in good > hands, and given the time available in the past, good progress has been > made. Also given my renewed emphasis, support from my job, and clear > understanding of goals, I can confidently state that I can do the work, and > can manage the editorship process to follow working group discussion to > completion. Here is (some of) what happened. I hope you will read it. > > I was asked last fall to resume editorship of the DYMO document, and > agreed to do so. > > Almost at the same time, I was invited to work with the LOADng authors > to produce a merged document that incorporated the best features from > DYMO and from LOADng. At that time, the general agreement was that > the merged document would be renamed AODVv2. > > Because of various personal difficulties unfamiliar in my experience, I was > surprised to find very late in the winter that the merge was not happening. > In order to carry out my responsibility, which was clearly to submit a > revised document for IETF 83 in Paris, I took the resource available to me > and within less than a week I submitted the revised DYMO draft renamed > to be AODVv2. > > People attending the meeting will remember what happened. I was quite > unjustly attacked and called names for doing: > a) what I said I would do > b) what I was supposed to do, and > c) changing the document to become more compatible with LOADng, as > requested by those authors and according to my best understanding. > > After that, I still hoped that we could do the merge, but nothing happened > until in Vancouver when the WG chairs gave us an ultimatum to make > something happen by November. > > We went around and around, but I eventually determined that there > was almost no chance that the LOADng authors would willingly help to > produce the desired merge. So I did what the LOADng authors had asked > me not to do: namely submit a revised document for consideration. > This revised document was an attempt to respond to valid comments > made during 2010 about problems with the document while it was > under Ian's editorial responsibility. It needs further revision -- in fact > I will submit a much more polished document on my website this > week. > > The important point is that for the last year the document languished > for all but a few weeks *at the request of the LOADng authors* -- > in fact, I would even say at their *DEMAND*, and all the while they > refused to help make the merge that (a) they had originally suggested > and (b) I was supposed to do. > > This note is already too long. I have much, much more to say. > But I will say one more thing: I have the ability and now the time to > do an excellent job on this, and I am here on the job only for the > benefit of the working group. Now that I can focus on it, and now > that I do not feel constrained to abide by the demands for delay > that were imposed by the LOADng author team, I can do it pretty > expediently. Of course I will welcome their input as well, and to > further reiterate it will be my intention to make the WG document > compatible with the needs of LOADng. > > Oh -- and one more thing... Regardless of the poisoned atmosphere > surrounding this debate, I have nothing but high regard for the work > done by the LOADng team. I don't think their methods are right for > this working group, and any statements to the effect that the DYMO > editorial process has been deficient during the last year or more > should be understood in light of the above narrative. > > Regards, > Charlie P. > > PS. Oh, and one more thing... I am a peaceful man, and if I don't > respond to all the invective and intransigence so clearly > in evidence lately, you'll just have to excuse me for trying > to remain so. > > > On 11/1/2012 9:40 AM, Don Sturek wrote: > > Hi Adbussalam, > > It is hard to consider a draft stalled 2+ years as the only way forward > in MANET as a reactive protocol. > > Don > > > > From: Abdussalam Baryun > Date: Thursday, November 1, 2012 8:53 AM > To: Jon Black > Cc: "manet@ietf.org" , Stan Ratliff > Subject: Re: [manet] Reactive Protocol Situation > > Yes LOADng is a reactive protocols, but not the MANET WG reactive > protocol (DYMO is already authorised). The WG is the only authorised to > make such decisions for its WG drafts, if WG decides to add any LOADng > ideas it can, or to accept such merge it can as well, > AB > On Thu, Nov 1, 2012 at 3:37 PM, Jon Black wrote: > >> Why would you think that LOADng is not reactive? If it is not a >> reactive protocol, then what is it? >> >> As to merging the documents, this is what WGs do. If you have multiple >> "competing" ideas you ask the authors to see if they can merge their >> concepts and ideas. If they cannot or will not then the WG must decide >> based on facts and not conjecture which is the most prudent path to take. >> >> Jon >> >> >> ------------------------------ >> *From:* Abdussalam Baryun >> *To:* Joseph Macker >> *Cc:* manet@ietf.org; Stan Ratliff >> *Sent:* Thursday, November 1, 2012 8:22 AM >> >> *Subject:* Re: [manet] Reactive Protocol Situation >> >> Dear Joseph Macker and Stan, >> MANET WG Chairs >> >> I disagree that the WG arranged/guided to merge the documents, I never >> heard that there was a consensus on such activity. DYMO is a reactive WG >> draft, but LOADng is not. Why did you guide to merge documents, I recommend >> that you ment to merge the team drafts co-authors to one WG draft (which is >> only DYMO so far). The authority is for the WG to decide to merge >> individual drafts to its WG draft. >> >> Therefore, my vote is for option 1 only. Thanking you for updating us >> with the status. >> >> Regards >> AB >> >> On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker wrote: >> >> Hello MANET working group (form Stan and Joe), >> >> As you are all probably aware, there has been WG activity lately on >> competing drafts for a MANET reactive protocol - DYMO (reviving the current >> working group document that was parked due to inactivity), and LOADng. Many >> months ago there was a somewhat authorship led movement towards a common >> document effort and given positive feedback at the time we the chairs >> thought this was the best approach given the authors potential to come >> together and gain the best of both efforts. Since that period, there has >> been some fairly strident and rancorous "at times" debate between the >> authors of the two documents. >> >> During IETF 84 in Vancouver, the co-chairs held a discussion with some of >> the co-authors of the two documents. Our guidance to the co-authors was to >> find a way to merge the two documents into one, as it was perceived that >> are not technically far apart and they both derive roughly from AODV >> concepts and LOADng had fairly active authorship and implementation >> efforts. We provided a co-editing proposal to the authors and gave them the >> timeframe of the Atlanta to come up with an answer back to us regarding >> this. As of this writing, those discussions of a potential commonn >> document and authorship merger have failed. >> >> Therefore, we find ourselves at a crossroads. The authors of the two >> documents are divided, and it is unlikely that progress on a merged >> document can be reached based upon recent author feedback. I have also >> polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat >> disengaged on the issue at the present time. We see only 3 possible paths >> forward: >> >> 1. Continue the work on the DYMO document, starting with whether there is >> consensus on its continued approach and also the desire to rename it to >> AODVv2. >> 2. Replace the existing DYMO document effort with the LOADng related >> document effort, defusing ealier references to LLNs as recommended in the >> last meeting minutes, and to focus more motivationally on general MANET >> problem spaces (the authors seem to have agreed to this issue if its a WG >> document). >> 3. Remove the working group charter for a reactive protocol, effectively >> killing both documents, at least from a working group (WG) standpoint. This >> would not be a reflection on the technology in either case, just an >> admission that we are not working together and reaching consensus. >> >> The co-chairs request and need your opinions on the options. We have >> been some silent collecting initial feedback and waiting for author >> feedback at this point. Stan and I are both on travel prior to Atlanta so >> our responses may be sparse and we will also likely be in a "receive mode" >> for a few days. So send your opinions. >> >> -Joe >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> > _______________________________________________ manet mailing list > manet@ietf.org https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing listmanet@ietf.orghttps://www.ietf.org/mailman/listinfo/manet > > > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --20cf307f3bccd8d84d04cd749701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I disagree with you of the process to handle such WORK flow. I RECOMME= ND the work flow for the MANET WG is to focus on the WG I-Ds only and try t= o target the Milestones without any interrupt of other organisations than I= ETF participants. I think the procedure and best practice is to give more t= ime/efforts to DYMO/AODVv2, because we had RFC3561 and we are getting to co= mplete the AODVv2 standard.
=A0
I agree to make comparison of both drafts *only* to make= LOADng authors to respond to the MANET WG requests and mine=A0to discuss o= n the MANET list.
=A0
AB

On Thu, Nov 1, 2012 at 8:02 PM, Jiazi YI <ietf@jiaziyi.com> w= rote:
Dear Charlie, Don, and all,

The LOADng authors never said that = the merge can't come, and always welcome good ideas from DYMO. However,= having LOADng to fit in DYMO text is rolling back to 2 years ago and is to= tally inappropriate because of the quality of the current dymo document. = =A0
There was a long discussion on this in = the last three months, but it's unconstructive to repeat the history he= re.=A0

Charlie, I really don't want to talk about the editorial process and au= thorship issue in the mailing list, so please, let's stop this topic he= re.=A0

I think for the moment, the constructive way is to go back to the technical= discussion and check the status of those two drafts, as suggested by Chris= and a lot of the others.=A0
I wou= ld appreciate all the WG participants reading those two drafts, and I'm= looking forward to your comments. Personally, I have reviewed the latest d= ymo revision, but I would like to keep my comments and hear the opinions fr= om other non-LOADng authors first.=A0

best

Jia= zi


On Nov 1, 2012, at 7:32 PM, "Charles E. Perkins" &l= t;charliep@compu= ter.org> wrote:

=20 =20 =20

Hello Don,

Your claim has been made several times, and I think it is highly misleading.

The bottom line is that the editorship of the WG document is now in good
hands, and given the time available in the past, good progress has been
made.=A0 Also given my renewed emphasis, support from my job, and clear
understanding of goals, I can confidently state that I can do the work, and
can manage the editorship process to follow working group discussion to
completion.=A0 Here is (some of) what happened.=A0 I hope you will read it.

I was asked last fall to resume editorship of the DYMO document, and
agreed to do so.

Almost at the same time, I was invited to work with the LOADng authors
to produce a merged document that incorporated the best features from
DYMO and from LOADng.=A0 At that time, the general agreement was that
the merged document would be renamed AODVv2.

Because of various personal difficulties unfamiliar in my experience, I was
surprised to find very late in the winter that the merge was not happening.
In order to carry out my responsibility, which was clearly to submit a
revised document for IETF 83 in Paris, I took the resource available to me
and within less than a week I submitted the revised DYMO draft renamed
to be AODVv2.

People attending the meeting will remember what happened.=A0 I was quite
unjustly attacked and called names for doing:
a) what I said I would do
b) what I was supposed to do, and
c) changing the document to become more compatible with LOADng, as =A0=A0=A0 requested by those authors and according to my best understanding.

After that, I still hoped that we could do the merge, but nothing happened
until in Vancouver when the WG chairs gave us an ultimatum to make something happen by November.

We went around and around, but I eventually determined that there
was almost no chance that the LOADng authors would willingly help to
produce the desired merge.=A0 So I did what the LOADng authors had asked
me not to do: namely submit a revised document for consideration.
This revised document was an attempt to respond to valid comments
made during 2010 about problems with the document while it was
under Ian's editorial responsibility.=A0 It needs further revisio= n -- in fact
I will submit a much more polished document on my website this
week.

The important point is that for the last year the document languished
for all but a few weeks *at the request of the LOADng authors* --
in fact, I would even say at their *DEMAND*, and all the while they
refused to help make the merge that (a) they had originally suggested
and (b) I was supposed to do.

This note is already too long.=A0 I have much, much more to say.
But I will say one more thing: I have the ability and now the time to
do an excellent job on this, and I am here on the job only for the benefit of the working group.=A0 Now that I can focus on it, and now<= br> that I do not feel constrained to abide by the demands for delay
that were imposed by the LOADng author team, I can do it pretty
expediently.=A0 Of course I will welcome their input as well, and to<= br> further reiterate it will be my intention to make the WG document
compatible with the needs of LOADng.

Oh -- and one more thing...=A0 Regardless of the poisoned atmosphere<= br> surrounding this debate, I have nothing but high regard for the work
done by the LOADng team.=A0 I don't think their methods are right for
this working group, and any statements to the effect that the DYMO editorial process has been deficient during the last year or more
should be understood in light of the above narrative.

Regards,
Charlie P.

PS. Oh, and one more thing...=A0 I am a peaceful man, and if I don= 9;t
=A0=A0=A0=A0=A0=A0=A0 respond to all the invective and intransigence = so clearly
=A0=A0=A0=A0=A0=A0=A0 in evidence lately, you'll just have to exc= use me for trying
=A0=A0=A0=A0=A0=A0=A0 to remain so.


On 11/1/2012 9:40 AM, Don Sturek wrote:
Hi Adbussalam,

It is hard to consider a draft stalled 2+ years as the only way forward in MANET as a reactive protocol.

Don



From= : Abdussalam Baryun <abdussalambaryun@gmail.com>
Date: Thursday, November 1, 2012 8:53 AM
To: Jon Black <jblack.ietf@yahoo.com<= /a>>
Cc: "manet@ietf.org" <manet@iet= f.org>, Stan Ratliff <sratliff@cisco.com>
Subject: Re: [manet] Reactive Protocol Situation

Yes LOADng is a reactive protocols, but not the MANET=A0WG reactive protocol (DYMO is already authorised). The WG is the only authorised to make such decisions for its WG drafts, if WG decides to add any LOADng ideas it can, or to accept such merge it can as well,
AB
On Thu, Nov 1, 2012 at 3:37 PM, Jon Black <jblack.ietf@yahoo.com> wrote:
Why would you think that LOADng is not reactive?=A0 If it is not a reactive protocol, then what is it?

As to merging the documents, this is what WGs do.=A0 If you have multiple "competing" ideas you ask the a= uthors to see if they can merge their concepts and ideas.=A0 If they cannot or will not then the WG must decide based on facts and not conjecture which is the most prudent path to take.

Jon


From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: Joseph Macker <jpmacker@gmail.com>
Cc: manet@ietf.org; Stan Ratliff <sratliff@cisco.com>
Sent: Thursday, November 1, 2012 8:22 AM

Subject: Re: [manet] Reactive Protocol Situation

Dear Joseph Macker and Stan,
MANET WG Chairs
=A0
I disagree that the=A0WG=A0arranged/guided t= o merge the documents, I never heard that there was a consensus on such activity. DYMO is a reactive WG draft, but LOADng is not. Why did you guide to merge documents, I recommend that you ment to merge the team drafts co-authors to one=A0WG draft (which is only DYMO so far). The authority is for the WG to decide to merge individual drafts to its WG draft.
=A0
Therefore, my vote is for option 1 only. Thanking you for updating us with the status.
=A0
Regards
AB

On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker <jpmacker@gmail.com> wrote:
Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competing drafts for a MANET reactive protocol - DYMO (reviving the current working group document that was parked due to inactivity), and LOADng. Many months ago there was a somewhat authorship led movement towards a common document effort and given positive feedback at the time we the chairs thought this was the best approach given the authors potential to come together and gain the best of both efforts.=A0 Since that period, there has been some fairly strident and rancorous "at times" debate between the autho= rs of the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of the co-authors of the two documents. Our guidance to the co-authors was to find a way to merge the two documents into one, as it was perceived that are not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active authorship and implementation efforts. We provided a co-editing proposal to the authors and gave them the timeframe of the Atlanta to come up with an answer back to us regarding this.=A0 As of this writing, those discussions of a potential commonn document and authorship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two documents are divided, and it is unlikely that progress on a merged document can be reached based upon recent author feedback. I have also polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.=A0 We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is consensus on its continued approach and also the desire to rename it to AODVv2.
2. Replace the existing DYMO document effort with the LOADng related document effort, defusing ealier references to LLNs as recommended in the last meeting minutes, and to focus more motivationally on general MANET problem spaces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively killing both documents, at least from a working group (WG) standpoint. This would not be a reflection on the technology in either case, just an admission that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.=A0 We have been some silent collecting initial feedback and waiting for author feedback at this point.=A0 Stan and I are both on travel prior to Atlanta so our responses may be sparse and we will also likely be in a "receive mode" for a few days.=A0 S= o send your opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/= listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________ manet mailing list manet@ietf.org<= /a> https://www.ietf.org/mailman/listinfo/manet 

_______________________________________________
manet mailing list
manet@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/manet



--=20
Regards,
Charlie P.
_______________________________________________
manet mailing list
manet@ietf.org
http= s://www.ietf.org/mailman/listinfo/manet


______________________________= _________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--20cf307f3bccd8d84d04cd749701-- From stanratliff3@gmail.com Thu Nov 1 13:11:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D9321F960E for ; Thu, 1 Nov 2012 13:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-yDwepxL42a for ; Thu, 1 Nov 2012 13:11:34 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB63521F9613 for ; Thu, 1 Nov 2012 13:11:33 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so3181533obq.31 for ; Thu, 01 Nov 2012 13:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eDVa/ORMDfjeLiDqP33kzDJ7dXm8KKYjCLXVjSJ4CUg=; b=QtZnS0LIQ5K8zsjXQBiz1c7441jgc+UUDsV+5cMr02JRKP9zXR8BDPeDMkLszCwT6E zAEkrtfFZMNKBB/h4d6KM5tl6KK6Ug17aNhCf0vlLkC9/OCTo6hibCHvhpE6lgPMFE0C egt7kIHA5b+ODW9/0tW2Mj4FjycgbzgCPXV1UnzzC2HKKO6spJO/gau2gP8PxpJMpJog 1tBKrZKIxW9LoUoaHWR3KvEsHR2jFblj9u3YXcwCFCvCLHm7EE/61UGmqi8NPZ4Iwx3C YjsxHCvR31mgQJkoL8VlgSdDF5aZtFNdOblfcTBRyyjtOBjVULO7l1qJ7Kunw1VVlmgE SEkA== MIME-Version: 1.0 Received: by 10.182.157.45 with SMTP id wj13mr34541847obb.58.1351800693362; Thu, 01 Nov 2012 13:11:33 -0700 (PDT) Received: by 10.76.28.37 with HTTP; Thu, 1 Nov 2012 13:11:33 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722049CC0@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A7722049CC0@xmb-rcd-x02.cisco.com> Date: Thu, 1 Nov 2012 16:11:33 -0400 Message-ID: From: Stan Ratliff To: "JP Vasseur (jvasseur)" Content-Type: multipart/alternative; boundary=f46d044269dc22910c04cd74a031 Cc: " List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 20:11:45 -0000 --f46d044269dc22910c04cd74a031 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable JP, Speaking for myself (not necessarily for Joe, as I haven't discussed with him a couple of days), my intent with the email was to bring the situation vis-a-vis reactive protocols to the WG's attention, and to see if the group coalesces around any of the three options. To be frank, based on the last 3 months of discussion, and the current email storm (including references to the "toxic environment"), I believe that the situation has passed to point of no return. I do not think the respective authors, or the WG as a whole, will ever (or at least for the foreseeable future) be able to reach consensus on a reactive protocol. Therefore, my preference is to remove the work item from the charter. Let's see how the discussion progresses. Regards, Stan On Thu, Nov 1, 2012 at 3:36 PM, JP Vasseur (jvasseur) w= rote: > Agree with you Don. > > Since discussions are going in many directions =85 would the chairs help > us organize these discussions ? > > Are you indeed asking us to express our preference for one of these > options, pick one and start from there ? > > On Nov 1, 2012, at 7:40 PM, Don Sturek wrote: > > Hi Charlie, > > Apologies if I misrepresented the facts on DYMO/AODVv2=85=85 > > I do think the facts as exist right now are: > 1) We have a LOADng draft that claims support to address the MANET > reactive protocol requirements > 2) Work has restarted (by yourself) on DYMO/AODVv2 > 3) There are two different views on the ability to merge LOADng with > DYMO/AODVv2. One view is the merge can happen and another (unfortunately = by > some authors of LOADng) that such a merge is impractical. > > So, irrespective of how we got to where we are, the point is it is a > good time to draw a conclusion on which of the 3 options above MANET shou= ld > take to meet its requirement for a reactive routing protocol. > > Don > > > From: "Charles E. Perkins" > Organization: Saratoga Blue Skies > Date: Thursday, November 1, 2012 11:32 AM > To: Don Sturek > Cc: "manet@ietf.org" > Subject: Re: [manet] Reactive Protocol Situation > > > Hello Don, > > Your claim has been made several times, and I think it is highly > misleading. > > The bottom line is that the editorship of the WG document is now in good > hands, and given the time available in the past, good progress has been > made. Also given my renewed emphasis, support from my job, and clear > understanding of goals, I can confidently state that I can do the work, a= nd > can manage the editorship process to follow working group discussion to > completion. Here is (some of) what happened. I hope you will read it. > > I was asked last fall to resume editorship of the DYMO document, and > agreed to do so. > > Almost at the same time, I was invited to work with the LOADng authors > to produce a merged document that incorporated the best features from > DYMO and from LOADng. At that time, the general agreement was that > the merged document would be renamed AODVv2. > > Because of various personal difficulties unfamiliar in my experience, I w= as > surprised to find very late in the winter that the merge was not happenin= g. > In order to carry out my responsibility, which was clearly to submit a > revised document for IETF 83 in Paris, I took the resource available to m= e > and within less than a week I submitted the revised DYMO draft renamed > to be AODVv2. > > People attending the meeting will remember what happened. I was quite > unjustly attacked and called names for doing: > a) what I said I would do > b) what I was supposed to do, and > c) changing the document to become more compatible with LOADng, as > requested by those authors and according to my best understanding. > > After that, I still hoped that we could do the merge, but nothing happene= d > until in Vancouver when the WG chairs gave us an ultimatum to make > something happen by November. > > We went around and around, but I eventually determined that there > was almost no chance that the LOADng authors would willingly help to > produce the desired merge. So I did what the LOADng authors had asked > me not to do: namely submit a revised document for consideration. > This revised document was an attempt to respond to valid comments > made during 2010 about problems with the document while it was > under Ian's editorial responsibility. It needs further revision -- in fa= ct > I will submit a much more polished document on my website this > week. > > The important point is that for the last year the document languished > for all but a few weeks *at the request of the LOADng authors* -- > in fact, I would even say at their *DEMAND*, and all the while they > refused to help make the merge that (a) they had originally suggested > and (b) I was supposed to do. > > This note is already too long. I have much, much more to say. > But I will say one more thing: I have the ability and now the time to > do an excellent job on this, and I am here on the job only for the > benefit of the working group. Now that I can focus on it, and now > that I do not feel constrained to abide by the demands for delay > that were imposed by the LOADng author team, I can do it pretty > expediently. Of course I will welcome their input as well, and to > further reiterate it will be my intention to make the WG document > compatible with the needs of LOADng. > > Oh -- and one more thing... Regardless of the poisoned atmosphere > surrounding this debate, I have nothing but high regard for the work > done by the LOADng team. I don't think their methods are right for > this working group, and any statements to the effect that the DYMO > editorial process has been deficient during the last year or more > should be understood in light of the above narrative. > > Regards, > Charlie P. > > PS. Oh, and one more thing... I am a peaceful man, and if I don't > respond to all the invective and intransigence so clearly > in evidence lately, you'll just have to excuse me for trying > to remain so. > > > On 11/1/2012 9:40 AM, Don Sturek wrote: > > Hi Adbussalam, > > It is hard to consider a draft stalled 2+ years as the only way forward > in MANET as a reactive protocol. > > Don > > > > From: Abdussalam Baryun > Date: Thursday, November 1, 2012 8:53 AM > To: Jon Black > Cc: "manet@ietf.org" , Stan Ratliff > Subject: Re: [manet] Reactive Protocol Situation > > Yes LOADng is a reactive protocols, but not the MANET WG reactive > protocol (DYMO is already authorised). The WG is the only authorised to > make such decisions for its WG drafts, if WG decides to add any LOADng > ideas it can, or to accept such merge it can as well, > AB > On Thu, Nov 1, 2012 at 3:37 PM, Jon Black wrote: > >> Why would you think that LOADng is not reactive? If it is not a >> reactive protocol, then what is it? >> >> As to merging the documents, this is what WGs do. If you have multiple >> "competing" ideas you ask the authors to see if they can merge their >> concepts and ideas. If they cannot or will not then the WG must decide >> based on facts and not conjecture which is the most prudent path to take= . >> >> Jon >> >> >> ------------------------------ >> *From:* Abdussalam Baryun >> *To:* Joseph Macker >> *Cc:* manet@ietf.org; Stan Ratliff >> *Sent:* Thursday, November 1, 2012 8:22 AM >> >> *Subject:* Re: [manet] Reactive Protocol Situation >> >> Dear Joseph Macker and Stan, >> MANET WG Chairs >> >> I disagree that the WG arranged/guided to merge the documents, I never >> heard that there was a consensus on such activity. DYMO is a reactive WG >> draft, but LOADng is not. Why did you guide to merge documents, I recomm= end >> that you ment to merge the team drafts co-authors to one WG draft (which= is >> only DYMO so far). The authority is for the WG to decide to merge >> individual drafts to its WG draft. >> >> Therefore, my vote is for option 1 only. Thanking you for updating us >> with the status. >> >> Regards >> AB >> >> On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker wro= te: >> >> Hello MANET working group (form Stan and Joe), >> >> As you are all probably aware, there has been WG activity lately on >> competing drafts for a MANET reactive protocol - DYMO (reviving the curr= ent >> working group document that was parked due to inactivity), and LOADng. M= any >> months ago there was a somewhat authorship led movement towards a common >> document effort and given positive feedback at the time we the chairs >> thought this was the best approach given the authors potential to come >> together and gain the best of both efforts. Since that period, there ha= s >> been some fairly strident and rancorous "at times" debate between the >> authors of the two documents. >> >> During IETF 84 in Vancouver, the co-chairs held a discussion with some o= f >> the co-authors of the two documents. Our guidance to the co-authors was = to >> find a way to merge the two documents into one, as it was perceived that >> are not technically far apart and they both derive roughly from AODV >> concepts and LOADng had fairly active authorship and implementation >> efforts. We provided a co-editing proposal to the authors and gave them = the >> timeframe of the Atlanta to come up with an answer back to us regarding >> this. As of this writing, those discussions of a potential commonn >> document and authorship merger have failed. >> >> Therefore, we find ourselves at a crossroads. The authors of the two >> documents are divided, and it is unlikely that progress on a merged >> document can be reached based upon recent author feedback. I have also >> polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat >> disengaged on the issue at the present time. We see only 3 possible pat= hs >> forward: >> >> 1. Continue the work on the DYMO document, starting with whether there i= s >> consensus on its continued approach and also the desire to rename it to >> AODVv2. >> 2. Replace the existing DYMO document effort with the LOADng related >> document effort, defusing ealier references to LLNs as recommended in th= e >> last meeting minutes, and to focus more motivationally on general MANET >> problem spaces (the authors seem to have agreed to this issue if its a W= G >> document). >> 3. Remove the working group charter for a reactive protocol, effectively >> killing both documents, at least from a working group (WG) standpoint. T= his >> would not be a reflection on the technology in either case, just an >> admission that we are not working together and reaching consensus. >> >> The co-chairs request and need your opinions on the options. We have >> been some silent collecting initial feedback and waiting for author >> feedback at this point. Stan and I are both on travel prior to Atlanta = so >> our responses may be sparse and we will also likely be in a "receive mod= e" >> for a few days. So send your opinions. >> >> -Joe >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> > _______________________________________________ manet mailing list > manet@ietf.org https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing listmanet@ietf.orghttps://www.ietf.org/mailman/listinfo/man= et > > > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --=20 Regards, Stan --f46d044269dc22910c04cd74a031 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable JP,

Speaking for myself (not necessarily for Joe, as I haven't = discussed with him a couple of days), my intent with the email was to bring= the situation vis-a-vis reactive protocols to the WG's attention, and = to see if the group coalesces around any of the three options.

To be frank, based on the last 3 months of discussion, and the current = email storm (including references to the "toxic environment"), I = believe that the situation has passed to point of no return. I do not think= the respective authors, or the WG as a whole, will ever (or at least for t= he foreseeable future) be able to reach consensus on a reactive protocol. T= herefore, my preference is to remove the work item from the charter.

Let's see how the discussion progresses.

Regards,
Stan
On Thu, Nov 1, 2012 at 3:36 PM, JP Vasseur= (jvasseur) <jvasseur@cisco.com> wrote:
Agree with you Don.

Since discussions are going in many directions =85 would the chairs he= lp us organize these discussions ?

Are you indeed asking us to express our preference for one of these op= tions, pick one and start from there ?

On Nov 1, 2012, at 7:40 PM, Don Sturek wrote:

Hi Charlie,

Apologies if I misrepresented the facts on DYMO/AODVv2=85=85

I do think the facts as exist right now are:
1) =A0We have a LOADng draft that claims support to address the MANET = reactive protocol requirements
2) =A0Work has restarted (by yourself) on DYMO/AODVv2
3) =A0There are two different views on the ability to merge LOADng wit= h DYMO/AODVv2. One view is the merge can happen and another (unfortunately = by some authors of LOADng) that such a merge is impractical.

So, irrespective of how we got to where we are, the point is it is a g= ood time to draw a conclusion on which of the 3 options above MANET should = take to meet its requirement for a reactive routing protocol.

Don


From: "Charles E. Perkins"= ; <charliep@c= omputer.org>
Organization: Saratoga Blue Skies Date: Thursday, November 1, 2012 11= :32 AM
To: Don Sturek <d.sturek@att.net>
Cc: "manet@ietf.org" <manet@ietf.org>
Subject: Re: [manet] Reactive Proto= col Situation


Hello Don,

Your claim has been made several times, and I think it is highly misleading= .

The bottom line is that the editorship of the WG document is now in good hands, and given the time available in the past, good progress has been
made.=A0 Also given my renewed emphasis, support from my job, and clear
understanding of goals, I can confidently state that I can do the work, and=
can manage the editorship process to follow working group discussion to
completion.=A0 Here is (some of) what happened.=A0 I hope you will read it.=

I was asked last fall to resume editorship of the DYMO document, and
agreed to do so.

Almost at the same time, I was invited to work with the LOADng authors
to produce a merged document that incorporated the best features from
DYMO and from LOADng.=A0 At that time, the general agreement was that
the merged document would be renamed AODVv2.

Because of various personal difficulties unfamiliar in my experience, I was=
surprised to find very late in the winter that the merge was not happening.=
In order to carry out my responsibility, which was clearly to submit a
revised document for IETF 83 in Paris, I took the resource available to me<= br> and within less than a week I submitted the revised DYMO draft renamed
to be AODVv2.

People attending the meeting will remember what happened.=A0 I was quite unjustly attacked and called names for doing:
a) what I said I would do
b) what I was supposed to do, and
c) changing the document to become more compatible with LOADng, as
=A0=A0=A0 requested by those authors and according to my best understanding= .

After that, I still hoped that we could do the merge, but nothing happened<= br> until in Vancouver when the WG chairs gave us an ultimatum to make
something happen by November.

We went around and around, but I eventually determined that there
was almost no chance that the LOADng authors would willingly help to
produce the desired merge.=A0 So I did what the LOADng authors had asked me not to do: namely submit a revised document for consideration.
This revised document was an attempt to respond to valid comments
made during 2010 about problems with the document while it was
under Ian's editorial responsibility.=A0 It needs further revision -- i= n fact
I will submit a much more polished document on my website this
week.

The important point is that for the last year the document languished
for all but a few weeks *at the request of the LOADng authors* --
in fact, I would even say at their *DEMAND*, and all the while they
refused to help make the merge that (a) they had originally suggested
and (b) I was supposed to do.

This note is already too long.=A0 I have much, much more to say.
But I will say one more thing: I have the ability and now the time to
do an excellent job on this, and I am here on the job only for the
benefit of the working group.=A0 Now that I can focus on it, and now
that I do not feel constrained to abide by the demands for delay
that were imposed by the LOADng author team, I can do it pretty
expediently.=A0 Of course I will welcome their input as well, and to
further reiterate it will be my intention to make the WG document
compatible with the needs of LOADng.

Oh -- and one more thing...=A0 Regardless of the poisoned atmosphere
surrounding this debate, I have nothing but high regard for the work
done by the LOADng team.=A0 I don't think their methods are right for this working group, and any statements to the effect that the DYMO
editorial process has been deficient during the last year or more
should be understood in light of the above narrative.

Regards,
Charlie P.

PS. Oh, and one more thing...=A0 I am a peaceful man, and if I don't =A0=A0=A0=A0=A0=A0=A0 respond to all the invective and intransigence so cle= arly
=A0=A0=A0=A0=A0=A0=A0 in evidence lately, you'll just have to excuse me= for trying
=A0=A0=A0=A0=A0=A0=A0 to remain so.


On 11/1/2012 9:40 AM, Don Sturek wrote:
Hi Adbussalam,

It is hard to consider a draft stalled 2+ years as the only way forwar= d in MANET as a reactive protocol.

Don



From: Abdussalam Baryun <abdussalambaryun@g= mail.com>
Date: Thursday, November 1, 2012 8:= 53 AM
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@ietf.org>, Stan Ratliff <<= a href=3D"mailto:sratliff@cisco.com" target=3D"_blank">sratliff@cisco.com>
Subject: Re: [manet] Reactive Proto= col Situation

Yes LOADng is a reactive protocols, but not the MANET=A0WG reactive pr= otocol (DYMO is already authorised). The WG is the only authorised to make = such decisions for its WG drafts, if WG decides to add any LOADng ideas it = can, or to accept such merge it can as well,
AB
On Thu, Nov 1, 2012 at 3:37 PM, Jon Black <jblack.ietf@= yahoo.com> wrote:
Why would you think that LOADng is not reactive?=A0 If it is not a reactive= protocol, then what is it?

As to merging the documents, this is what WGs do.=A0 If you have multiple &= quot;competing" ideas you ask the authors to see if they can merge the= ir concepts and ideas.=A0 If they cannot or will not then the WG must decid= e based on facts and not conjecture which is the most prudent path to take.

Jon


From: Abdussalam Baryun <= abdussalamb= aryun@gmail.com>
To: Joseph Macker <jpmacker@gmail.com>= ;
Cc: manet@ietf.org; Stan Ratliff <sratliff@cisco.com>
Sent: Thursday, November 1, = 2012 8:22 AM

Subject: Re: [manet] Reactiv= e Protocol Situation

Dear Joseph Macker and Stan,
MANET WG Chairs
=A0
I disagree that the=A0WG=A0arranged/guided to merge the documents, I n= ever heard that there was a consensus on such activity. DYMO is a reactive = WG draft, but LOADng is not. Why did you guide to merge documents, I recomm= end that you ment to merge the team drafts co-authors to one=A0WG draft (which is only DYMO so far). The autho= rity is for the WG to decide to merge individual drafts to its WG draft.
=A0
Therefore, my vote is for option 1 only. Thanking you for updating us = with the status.
=A0
Regards
AB

On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker <= jp= macker@gmail.com> wrote:
Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.=A0 Since = that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active author= ship and implementation efforts. We provided a co-editing proposal to the a= uthors and gave them the timeframe of the Atlanta to come up with an answer= back to us regarding this.=A0 As of this writing, those discussions of a potential commonn document and aut= horship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.=A0 We see = only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.=A0 We have bee= n some silent collecting initial feedback and waiting for author feedback a= t this point.=A0 Stan and I are both on travel prior to Atlanta so our resp= onses may be sparse and we will also likely be in a "receive mode" for a few days.=A0 So send your op= inions.

-Joe

_______________________________________________
manet mailing list
manet@= ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



_______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet 

_______________________________________________
manet mailing list
manet@ietf.orghttps:=
//www.ietf.org/mailman/listinfo/manet


--=20
Regards,
Charlie P.
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet




--
Regards,
Stan
--f46d044269dc22910c04cd74a031-- From jvasseur@cisco.com Thu Nov 1 13:19:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A55921F9680 for ; Thu, 1 Nov 2012 13:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.473 X-Spam-Level: X-Spam-Status: No, score=-10.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvI-dJgnVdRX for ; Thu, 1 Nov 2012 13:19:52 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 123A721F92DD for ; Thu, 1 Nov 2012 13:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34267; q=dns/txt; s=iport; t=1351801192; x=1353010792; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=F0tQXBBGDsHsJout+SU7jXpkJi49CnJ1Kusx2iF/8fM=; b=Z420KCvQOOvobbbHMN7MZiFe55QeArs893rcyQEhd7OK5weyjshIYVvu OxYDN1MVLg7aWeykV37fmMRYubg8SWztYh1fwJmpcPu8lrYr/I4phSPcx 9A7mHP87ScyrxKE5+msOtykGbLHx5fa6tqn2yvqKPKqkOTdxbJbVkhbJJ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAZAHbYklCtJV2c/2dsb2JhbABEgXQGAU6vC5IbgQiCHgEBAQQBAQEPAQdSAggDEAIBCBEDAQEBCxYBBgchBgsTAQkIAgQOBQgah1IDDwucWJZNDYlQBIsUZxKFSGEDiCWKIYFdBI0DgyaBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,695,1344211200"; d="scan'208,217";a="137937657" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 01 Nov 2012 20:19:51 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA1KJpIA027325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 20:19:51 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 15:19:50 -0500 From: "JP Vasseur (jvasseur)" To: Jiazi YI Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuG4+LPVi/cSo/ES1hdb7zda62w== Date: Thu, 1 Nov 2012 20:19:50 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204A2F3@xmb-rcd-x02.cisco.com> References: <5092C033.1030604@computer.org> <7A45F5D9-F2CC-4459-9AFB-299101A7CBE7@jiaziyi.com> In-Reply-To: <7A45F5D9-F2CC-4459-9AFB-299101A7CBE7@jiaziyi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.90.251] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--29.039300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204A2F3xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 20:19:54 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204A2F3xmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Nov 1, 2012, at 4:02 PM, Jiazi YI wrote: Dear Charlie, Don, and all, The LOADng authors never said that the merge can't come, and always welcome= good ideas from DYMO. However, having LOADng to fit in DYMO text is rollin= g back to 2 years ago JP> Not sure that this argument is terribly important and is totally inappropriate because of the quality of the current dymo doc= ument. JP> I would certainly not agree on this. There was a long discussion on this in the last three months, but it's unco= nstructive to repeat the history here. Charlie, I really don't want to talk about the editorial process and author= ship issue in the mailing list, so please, let's stop this topic here. I think for the moment, the constructive way is to go back to the technical= discussion and check the status of those two drafts, as suggested by Chris= and a lot of the others. I would appreciate all the WG participants reading those two drafts, and I'= m looking forward to your comments. Personally, I have reviewed the latest = dymo revision, but I would like to keep my comments and hear the opinions f= rom other non-LOADng authors first. best Jiazi On Nov 1, 2012, at 7:32 PM, "Charles E. Perkins" > wrote: Hello Don, Your claim has been made several times, and I think it is highly misleading= . The bottom line is that the editorship of the WG document is now in good hands, and given the time available in the past, good progress has been made. Also given my renewed emphasis, support from my job, and clear understanding of goals, I can confidently state that I can do the work, and can manage the editorship process to follow working group discussion to completion. Here is (some of) what happened. I hope you will read it. I was asked last fall to resume editorship of the DYMO document, and agreed to do so. Almost at the same time, I was invited to work with the LOADng authors to produce a merged document that incorporated the best features from DYMO and from LOADng. At that time, the general agreement was that the merged document would be renamed AODVv2. Because of various personal difficulties unfamiliar in my experience, I was surprised to find very late in the winter that the merge was not happening. In order to carry out my responsibility, which was clearly to submit a revised document for IETF 83 in Paris, I took the resource available to me and within less than a week I submitted the revised DYMO draft renamed to be AODVv2. People attending the meeting will remember what happened. I was quite unjustly attacked and called names for doing: a) what I said I would do b) what I was supposed to do, and c) changing the document to become more compatible with LOADng, as requested by those authors and according to my best understanding. After that, I still hoped that we could do the merge, but nothing happened until in Vancouver when the WG chairs gave us an ultimatum to make something happen by November. We went around and around, but I eventually determined that there was almost no chance that the LOADng authors would willingly help to produce the desired merge. So I did what the LOADng authors had asked me not to do: namely submit a revised document for consideration. This revised document was an attempt to respond to valid comments made during 2010 about problems with the document while it was under Ian's editorial responsibility. It needs further revision -- in fact I will submit a much more polished document on my website this week. The important point is that for the last year the document languished for all but a few weeks *at the request of the LOADng authors* -- in fact, I would even say at their *DEMAND*, and all the while they refused to help make the merge that (a) they had originally suggested and (b) I was supposed to do. This note is already too long. I have much, much more to say. But I will say one more thing: I have the ability and now the time to do an excellent job on this, and I am here on the job only for the benefit of the working group. Now that I can focus on it, and now that I do not feel constrained to abide by the demands for delay that were imposed by the LOADng author team, I can do it pretty expediently. Of course I will welcome their input as well, and to further reiterate it will be my intention to make the WG document compatible with the needs of LOADng. Oh -- and one more thing... Regardless of the poisoned atmosphere surrounding this debate, I have nothing but high regard for the work done by the LOADng team. I don't think their methods are right for this working group, and any statements to the effect that the DYMO editorial process has been deficient during the last year or more should be understood in light of the above narrative. Regards, Charlie P. PS. Oh, and one more thing... I am a peaceful man, and if I don't respond to all the invective and intransigence so clearly in evidence lately, you'll just have to excuse me for trying to remain so. On 11/1/2012 9:40 AM, Don Sturek wrote: Hi Adbussalam, It is hard to consider a draft stalled 2+ years as the only way forward in = MANET as a reactive protocol. Don From: Abdussalam Baryun > Date: Thursday, November 1, 2012 8:53 AM To: Jon Black > Cc: "manet@ietf.org" >, Stan Ratliff > Subject: Re: [manet] Reactive Protocol Situation Yes LOADng is a reactive protocols, but not the MANET WG reactive protocol = (DYMO is already authorised). The WG is the only authorised to make such de= cisions for its WG drafts, if WG decides to add any LOADng ideas it can, or= to accept such merge it can as well, AB On Thu, Nov 1, 2012 at 3:37 PM, Jon Black > wrote: Why would you think that LOADng is not reactive? If it is not a reactive p= rotocol, then what is it? As to merging the documents, this is what WGs do. If you have multiple "co= mpeting" ideas you ask the authors to see if they can merge their concepts = and ideas. If they cannot or will not then the WG must decide based on fac= ts and not conjecture which is the most prudent path to take. Jon ________________________________ From: Abdussalam Baryun > To: Joseph Macker > Cc: manet@ietf.org; Stan Ratliff > Sent: Thursday, November 1, 2012 8:22 AM Subject: Re: [manet] Reactive Protocol Situation Dear Joseph Macker and Stan, MANET WG Chairs I disagree that the WG arranged/guided to merge the documents, I never hear= d that there was a consensus on such activity. DYMO is a reactive WG draft,= but LOADng is not. Why did you guide to merge documents, I recommend that = you ment to merge the team drafts co-authors to one WG draft (which is only= DYMO so far). The authority is for the WG to decide to merge individual dr= afts to its WG draft. Therefore, my vote is for option 1 only. Thanking you for updating us with = the status. Regards AB On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker > wrote: Hello MANET working group (form Stan and Joe), As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common documen= t effort and given positive feedback at the time we the chairs thought this= was the best approach given the authors potential to come together and gai= n the best of both efforts. Since that period, there has been some fairly = strident and rancorous "at times" debate between the authors of the two doc= uments. During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts = and LOADng had fairly active authorship and implementation efforts. We prov= ided a co-editing proposal to the authors and gave them the timeframe of th= e Atlanta to come up with an answer back to us regarding this. As of this = writing, those discussions of a potential commonn document and authorship m= erger have failed. Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss= ue at the present time. We see only 3 possible paths forward: 1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2. 2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document). 3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus. The co-chairs request and need your opinions on the options. We have been = some silent collecting initial feedback and waiting for author feedback at = this point. Stan and I are both on travel prior to Atlanta so our response= s may be sparse and we will also likely be in a "receive mode" for a few da= ys. So send your opinions. -Joe _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ie= tf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet -- Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204A2F3xmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Nov 1, 2012, at 4:02 PM, Jiazi YI wrote:

Dear Charlie, Don, and all,

The LOADng authors never said that the merge can't come, and always welcome= good ideas from DYMO. However, having LOADng to fit in DYMO text is rollin= g back to 2 years ago

JP> Not sure that this argument is terribly important

and is totally inappropriate because of the quality of the current dymo doc= ument.  

JP> I would certainly not agree on this.

There was a long discussion on this in the last three months, but it's unco= nstructive to repeat the history here. 

Charlie, I really don't want to talk about the editorial process and author= ship issue in the mailing list, so please, let's stop this topic here. = ;

I think for the moment, the constructive way is to go back to the technical= discussion and check the status of those two drafts, as suggested by Chris= and a lot of the others. 
I would appreciate all the WG participants reading those two drafts, and I'= m looking forward to your comments. Personally, I have reviewed the latest = dymo revision, but I would like to keep my comments and hear the opinions f= rom other non-LOADng authors first. 

best

Jiazi



On Nov 1, 2012, at 7:32 PM, "Charles E. Perkins" <charliep@computer.org> wrote:

Hello Don,

Your claim has been made several times, and I think it is highly misleading= .

The bottom line is that the editorship of the WG document is now in good hands, and given the time available in the past, good progress has been
made.  Also given my renewed emphasis, support from my job, and clear<= br> understanding of goals, I can confidently state that I can do the work, and=
can manage the editorship process to follow working group discussion to
completion.  Here is (some of) what happened.  I hope you will re= ad it.

I was asked last fall to resume editorship of the DYMO document, and
agreed to do so.

Almost at the same time, I was invited to work with the LOADng authors
to produce a merged document that incorporated the best features from
DYMO and from LOADng.  At that time, the general agreement was that the merged document would be renamed AODVv2.

Because of various personal difficulties unfamiliar in my experience, I was=
surprised to find very late in the winter that the merge was not happening.=
In order to carry out my responsibility, which was clearly to submit a
revised document for IETF 83 in Paris, I took the resource available to me<= br> and within less than a week I submitted the revised DYMO draft renamed
to be AODVv2.

People attending the meeting will remember what happened.  I was quite=
unjustly attacked and called names for doing:
a) what I said I would do
b) what I was supposed to do, and
c) changing the document to become more compatible with LOADng, as
    requested by those authors and according to my best unde= rstanding.

After that, I still hoped that we could do the merge, but nothing happened<= br> until in Vancouver when the WG chairs gave us an ultimatum to make
something happen by November.

We went around and around, but I eventually determined that there
was almost no chance that the LOADng authors would willingly help to
produce the desired merge.  So I did what the LOADng authors had asked=
me not to do: namely submit a revised document for consideration.
This revised document was an attempt to respond to valid comments
made during 2010 about problems with the document while it was
under Ian's editorial responsibility.  It needs further revision -- in= fact
I will submit a much more polished document on my website this
week.

The important point is that for the last year the document languished
for all but a few weeks *at the request of the LOADng authors* --
in fact, I would even say at their *DEMAND*, and all the while they
refused to help make the merge that (a) they had originally suggested
and (b) I was supposed to do.

This note is already too long.  I have much, much more to say.
But I will say one more thing: I have the ability and now the time to
do an excellent job on this, and I am here on the job only for the
benefit of the working group.  Now that I can focus on it, and now
that I do not feel constrained to abide by the demands for delay
that were imposed by the LOADng author team, I can do it pretty
expediently.  Of course I will welcome their input as well, and to
further reiterate it will be my intention to make the WG document
compatible with the needs of LOADng.

Oh -- and one more thing...  Regardless of the poisoned atmosphere
surrounding this debate, I have nothing but high regard for the work
done by the LOADng team.  I don't think their methods are right for this working group, and any statements to the effect that the DYMO
editorial process has been deficient during the last year or more
should be understood in light of the above narrative.

Regards,
Charlie P.

PS. Oh, and one more thing...  I am a peaceful man, and if I don't
        respond to all the invective and= intransigence so clearly
        in evidence lately, you'll just = have to excuse me for trying
        to remain so.


On 11/1/2012 9:40 AM, Don Sturek wrote:
Hi Adbussalam,

It is hard to consider a draft stalled 2+ years as the only way fo= rward in MANET as a reactive protocol.

Don



From: Abdussalam Baryun <abdussalamb= aryun@gmail.com>
Date: Thursday, November 1, 2012 8:= 53 AM
To: Jon Black <jblack.ietf@yahoo.com&= gt;
Cc: "manet@ietf.org" <manet@ietf.org>, Stan= Ratliff <sratliff@cisco.com>
Subject: Re: [manet] Reactive Proto= col Situation

Yes LOADng is a reactive protocols, but not the MANET WG reactive= protocol (DYMO is already authorised). The WG is the only authorised to ma= ke such decisions for its WG drafts, if WG decides to add any LOADng ideas = it can, or to accept such merge it can as well,
AB
On Thu, Nov 1, 2012 at 3:37 PM, Jon Black <jblack.ietf@yahoo.com> wrote:
Why would you think that LOADng is not reactive?  If it is not a react= ive protocol, then what is it?

As to merging the documents, this is what WGs do.  If you have multipl= e "competing" ideas you ask the authors to see if they can merge = their concepts and ideas.  If they cannot or will not then the WG must= decide based on facts and not conjecture which is the most prudent path to take.

Jon


From: Abdussalam Baryun <= abdussalambaryun@gmail.com>
To: Joseph Macker <= jpmacker@gmail.com>
Cc: manet@ietf.org; Stan Ratliff <sratliff@cisco.com>
Sent: Thursday, November 1, = 2012 8:22 AM

Subject: Re: [manet] Reactiv= e Protocol Situation

Dear Joseph Macker and Stan,
MANET WG Chairs
 
I disagree that the WG arranged/guided to merge the document= s, I never heard that there was a consensus on such activity. DYMO is a rea= ctive WG draft, but LOADng is not. Why did you guide to merge documents, I = recommend that you ment to merge the team drafts co-authors to one WG draft (which is only DYMO so far). The au= thority is for the WG to decide to merge individual drafts to its WG draft.=
 
Therefore, my vote is for option 1 only. Thanking you for updating us = with the status.
 
Regards
AB

On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker <= jpmacker@gmail.com> wrote:
Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.  Sin= ce that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active author= ship and implementation efforts. We provided a co-editing proposal to the a= uthors and gave them the timeframe of the Atlanta to come up with an answer= back to us regarding this.  As of this writing, those discussions of a potential commonn document and aut= horship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.  We s= ee only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have = been some silent collecting initial feedback and waiting for author feedbac= k at this point.  Stan and I are both on travel prior to Atlanta so ou= r responses may be sparse and we will also likely be in a "receive mode" for a few days.  So send your= opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listi= nfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet 

_______________________________________________
manet mailing list
manet@=
ietf.org
https://www.ietf.org/mailman/listinfo/manet



--=20
Regards,
Charlie P.
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A772204A2F3xmbrcdx02ciscoc_-- From abdussalambaryun@gmail.com Thu Nov 1 13:20:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0E921F8835 for ; Thu, 1 Nov 2012 13:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.15 X-Spam-Level: X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3uTXGI9+fKa for ; Thu, 1 Nov 2012 13:20:14 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EBB6121F9688 for ; Thu, 1 Nov 2012 13:20:10 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3450849vcb.31 for ; Thu, 01 Nov 2012 13:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FXTpaF/Gi3+PYY5PEh1P1CQp7yIaG2kIAprEyHbrK7A=; b=j6krFgwOD08p3RbZlXtpYXG9DXhK0Vb7xGtVp1GwnYHLkbnTe6MZG+x511F085ipS/ 4G3xqxEt68yL91HLtKzPkFi44wi7q7xEmXyUfNjdUhgVKObsyUzPEksqWoscnWcT0rOX 5io+3TdCNWa3wXuTLDh+wSouyFWude6wySnVNEy899VstAa7eVtQ9ZV6cczqkGCot/DM ehh71QkIayCwDGWXflCK/OmMTnwd6oOOfqbUdTLYeZt0LshQpU58mFsnlQ5Nq5ZtAgBU r/K83POfMEWzWruZJazFYcI5RD0Rys27Q48bHcenqSMR4g/JQ5hc6KmTqSMK77BuEc3l +uGQ== MIME-Version: 1.0 Received: by 10.220.16.12 with SMTP id m12mr46256536vca.14.1351801210310; Thu, 01 Nov 2012 13:20:10 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 13:20:09 -0700 (PDT) In-Reply-To: References: <03B78081B371D44390ED6E7BADBB4A7722049CC0@xmb-rcd-x02.cisco.com> Date: Thu, 1 Nov 2012 20:20:09 +0000 Message-ID: From: Abdussalam Baryun To: Stan Ratliff Content-Type: multipart/alternative; boundary=bcaec54b46c4f28e6104cd74be35 Cc: " List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 20:20:17 -0000 --bcaec54b46c4f28e6104cd74be35 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think to remove reactive from charter there SHOULD be a good reason for that, just because there was no consensus on merging LOADng (i.e. individual draft) and DYMO (ietf-wg draft)is not enough. I noticed that no one wanted the merge from the first place, and usually merging is the most difficult thing to get. The reasonable is to continue with the WG I-D ietf-manet-dymo-23, because no good reason to remove the item so far. AB On Thu, Nov 1, 2012 at 8:11 PM, Stan Ratliff wrote= : > JP, > > Speaking for myself (not necessarily for Joe, as I haven't discussed with > him a couple of days), my intent with the email was to bring the situatio= n > vis-a-vis reactive protocols to the WG's attention, and to see if the gro= up > coalesces around any of the three options. > > To be frank, based on the last 3 months of discussion, and the current > email storm (including references to the "toxic environment"), I believe > that the situation has passed to point of no return. I do not think the > respective authors, or the WG as a whole, will ever (or at least for the > foreseeable future) be able to reach consensus on a reactive protocol. > Therefore, my preference is to remove the work item from the charter. > > Let's see how the discussion progresses. > > Regards, > Stan > > On Thu, Nov 1, 2012 at 3:36 PM, JP Vasseur (jvasseur) wrote: > >> Agree with you Don. >> >> Since discussions are going in many directions =85 would the chairs hel= p >> us organize these discussions ? >> >> Are you indeed asking us to express our preference for one of these >> options, pick one and start from there ? >> >> On Nov 1, 2012, at 7:40 PM, Don Sturek wrote: >> >> Hi Charlie, >> >> Apologies if I misrepresented the facts on DYMO/AODVv2=85=85 >> >> I do think the facts as exist right now are: >> 1) We have a LOADng draft that claims support to address the MANET >> reactive protocol requirements >> 2) Work has restarted (by yourself) on DYMO/AODVv2 >> 3) There are two different views on the ability to merge LOADng with >> DYMO/AODVv2. One view is the merge can happen and another (unfortunately= by >> some authors of LOADng) that such a merge is impractical. >> >> So, irrespective of how we got to where we are, the point is it is a >> good time to draw a conclusion on which of the 3 options above MANET sho= uld >> take to meet its requirement for a reactive routing protocol. >> >> Don >> >> >> From: "Charles E. Perkins" >> Organization: Saratoga Blue Skies >> Date: Thursday, November 1, 2012 11:32 AM >> To: Don Sturek >> Cc: "manet@ietf.org" >> Subject: Re: [manet] Reactive Protocol Situation >> >> >> Hello Don, >> >> Your claim has been made several times, and I think it is highly >> misleading. >> >> The bottom line is that the editorship of the WG document is now in good >> hands, and given the time available in the past, good progress has been >> made. Also given my renewed emphasis, support from my job, and clear >> understanding of goals, I can confidently state that I can do the work, >> and >> can manage the editorship process to follow working group discussion to >> completion. Here is (some of) what happened. I hope you will read it. >> >> I was asked last fall to resume editorship of the DYMO document, and >> agreed to do so. >> >> Almost at the same time, I was invited to work with the LOADng authors >> to produce a merged document that incorporated the best features from >> DYMO and from LOADng. At that time, the general agreement was that >> the merged document would be renamed AODVv2. >> >> Because of various personal difficulties unfamiliar in my experience, I >> was >> surprised to find very late in the winter that the merge was not >> happening. >> In order to carry out my responsibility, which was clearly to submit a >> revised document for IETF 83 in Paris, I took the resource available to = me >> and within less than a week I submitted the revised DYMO draft renamed >> to be AODVv2. >> >> People attending the meeting will remember what happened. I was quite >> unjustly attacked and called names for doing: >> a) what I said I would do >> b) what I was supposed to do, and >> c) changing the document to become more compatible with LOADng, as >> requested by those authors and according to my best understanding. >> >> After that, I still hoped that we could do the merge, but nothing happen= ed >> until in Vancouver when the WG chairs gave us an ultimatum to make >> something happen by November. >> >> We went around and around, but I eventually determined that there >> was almost no chance that the LOADng authors would willingly help to >> produce the desired merge. So I did what the LOADng authors had asked >> me not to do: namely submit a revised document for consideration. >> This revised document was an attempt to respond to valid comments >> made during 2010 about problems with the document while it was >> under Ian's editorial responsibility. It needs further revision -- in >> fact >> I will submit a much more polished document on my website this >> week. >> >> The important point is that for the last year the document languished >> for all but a few weeks *at the request of the LOADng authors* -- >> in fact, I would even say at their *DEMAND*, and all the while they >> refused to help make the merge that (a) they had originally suggested >> and (b) I was supposed to do. >> >> This note is already too long. I have much, much more to say. >> But I will say one more thing: I have the ability and now the time to >> do an excellent job on this, and I am here on the job only for the >> benefit of the working group. Now that I can focus on it, and now >> that I do not feel constrained to abide by the demands for delay >> that were imposed by the LOADng author team, I can do it pretty >> expediently. Of course I will welcome their input as well, and to >> further reiterate it will be my intention to make the WG document >> compatible with the needs of LOADng. >> >> Oh -- and one more thing... Regardless of the poisoned atmosphere >> surrounding this debate, I have nothing but high regard for the work >> done by the LOADng team. I don't think their methods are right for >> this working group, and any statements to the effect that the DYMO >> editorial process has been deficient during the last year or more >> should be understood in light of the above narrative. >> >> Regards, >> Charlie P. >> >> PS. Oh, and one more thing... I am a peaceful man, and if I don't >> respond to all the invective and intransigence so clearly >> in evidence lately, you'll just have to excuse me for trying >> to remain so. >> >> >> On 11/1/2012 9:40 AM, Don Sturek wrote: >> >> Hi Adbussalam, >> >> It is hard to consider a draft stalled 2+ years as the only way forward >> in MANET as a reactive protocol. >> >> Don >> >> >> >> From: Abdussalam Baryun >> Date: Thursday, November 1, 2012 8:53 AM >> To: Jon Black >> Cc: "manet@ietf.org" , Stan Ratliff >> Subject: Re: [manet] Reactive Protocol Situation >> >> Yes LOADng is a reactive protocols, but not the MANET WG reactive >> protocol (DYMO is already authorised). The WG is the only authorised to >> make such decisions for its WG drafts, if WG decides to add any LOADng >> ideas it can, or to accept such merge it can as well, >> AB >> On Thu, Nov 1, 2012 at 3:37 PM, Jon Black wrote= : >> >>> Why would you think that LOADng is not reactive? If it is not a >>> reactive protocol, then what is it? >>> >>> As to merging the documents, this is what WGs do. If you have multiple >>> "competing" ideas you ask the authors to see if they can merge their >>> concepts and ideas. If they cannot or will not then the WG must decide >>> based on facts and not conjecture which is the most prudent path to tak= e. >>> >>> Jon >>> >>> >>> ------------------------------ >>> *From:* Abdussalam Baryun >>> *To:* Joseph Macker >>> *Cc:* manet@ietf.org; Stan Ratliff >>> *Sent:* Thursday, November 1, 2012 8:22 AM >>> >>> *Subject:* Re: [manet] Reactive Protocol Situation >>> >>> Dear Joseph Macker and Stan, >>> MANET WG Chairs >>> >>> I disagree that the WG arranged/guided to merge the documents, I never >>> heard that there was a consensus on such activity. DYMO is a reactive W= G >>> draft, but LOADng is not. Why did you guide to merge documents, I recom= mend >>> that you ment to merge the team drafts co-authors to one WG draft (whic= h is >>> only DYMO so far). The authority is for the WG to decide to merge >>> individual drafts to its WG draft. >>> >>> Therefore, my vote is for option 1 only. Thanking you for updating us >>> with the status. >>> >>> Regards >>> AB >>> >>> On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker wr= ote: >>> >>> Hello MANET working group (form Stan and Joe), >>> >>> As you are all probably aware, there has been WG activity lately on >>> competing drafts for a MANET reactive protocol - DYMO (reviving the cur= rent >>> working group document that was parked due to inactivity), and LOADng. = Many >>> months ago there was a somewhat authorship led movement towards a commo= n >>> document effort and given positive feedback at the time we the chairs >>> thought this was the best approach given the authors potential to come >>> together and gain the best of both efforts. Since that period, there h= as >>> been some fairly strident and rancorous "at times" debate between the >>> authors of the two documents. >>> >>> During IETF 84 in Vancouver, the co-chairs held a discussion with some >>> of the co-authors of the two documents. Our guidance to the co-authors = was >>> to find a way to merge the two documents into one, as it was perceived = that >>> are not technically far apart and they both derive roughly from AODV >>> concepts and LOADng had fairly active authorship and implementation >>> efforts. We provided a co-editing proposal to the authors and gave them= the >>> timeframe of the Atlanta to come up with an answer back to us regarding >>> this. As of this writing, those discussions of a potential commonn >>> document and authorship merger have failed. >>> >>> Therefore, we find ourselves at a crossroads. The authors of the two >>> documents are divided, and it is unlikely that progress on a merged >>> document can be reached based upon recent author feedback. I have also >>> polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat >>> disengaged on the issue at the present time. We see only 3 possible pa= ths >>> forward: >>> >>> 1. Continue the work on the DYMO document, starting with whether there >>> is consensus on its continued approach and also the desire to rename it= to >>> AODVv2. >>> 2. Replace the existing DYMO document effort with the LOADng related >>> document effort, defusing ealier references to LLNs as recommended in t= he >>> last meeting minutes, and to focus more motivationally on general MANET >>> problem spaces (the authors seem to have agreed to this issue if its a = WG >>> document). >>> 3. Remove the working group charter for a reactive protocol, effectivel= y >>> killing both documents, at least from a working group (WG) standpoint. = This >>> would not be a reflection on the technology in either case, just an >>> admission that we are not working together and reaching consensus. >>> >>> The co-chairs request and need your opinions on the options. We have >>> been some silent collecting initial feedback and waiting for author >>> feedback at this point. Stan and I are both on travel prior to Atlanta= so >>> our responses may be sparse and we will also likely be in a "receive mo= de" >>> for a few days. So send your opinions. >>> >>> -Joe >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> >> _______________________________________________ manet mailing list >> manet@ietf.org https://www.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> manet mailing listmanet@ietf.orghttps://www.ietf.org/mailman/listinfo/ma= net >> >> >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > > > -- > Regards, > Stan > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --bcaec54b46c4f28e6104cd74be35 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I think to remove reactive from charter there SHOULD be a good reason = for that, just because there was no consensus on merging LOADng (i.e. indiv= idual draft)=A0and DYMO (ietf-wg draft)is not enough. I noticed that no one= wanted the merge from the first place, and usually merging is the most dif= ficult thing to get. The reasonable is to continue with=A0the WG=A0I-D ietf= -manet-dymo-23, because no good reason to remove the item so far.
AB
On Thu, Nov 1, 2012 at 8:= 11 PM, Stan Ratliff <stanratliff3@gmail.com> wrote:
=
JP,

Speaking for myself (not necessarily for Joe, as I haven't = discussed with him a couple of days), my intent with the email was to bring= the situation vis-a-vis reactive protocols to the WG's attention, and = to see if the group coalesces around any of the three options.

To be frank, based on the last 3 months of discussion, and the current = email storm (including references to the "toxic environment"), I = believe that the situation has passed to point of no return. I do not think= the respective authors, or the WG as a whole, will ever (or at least for t= he foreseeable future) be able to reach consensus on a reactive protocol. T= herefore, my preference is to remove the work item from the charter.

Let's see how the discussion progresses.

Regards,
Stan
On Thu, Nov 1, 2012 at 3= :36 PM, JP Vasseur (jvasseur) <jvasseur@cisco.com> wrote:
Agree with you Don.

Since discussions are going in many directions =85 would the chairs he= lp us organize these discussions ?

Are you indeed asking us to express our preference for one of these op= tions, pick one and start from there ?

On Nov 1, 2012, at 7:40 PM, Don Sturek wrote:

Hi Charlie,

Apologies if I misrepresented the facts on DYMO/AODVv2=85=85

I do think the facts as exist right now are:
1) =A0We have a LOADng draft that claims support to address the MANET = reactive protocol requirements
2) =A0Work has restarted (by yourself) on DYMO/AODVv2
3) =A0There are two different views on the ability to merge LOADng wit= h DYMO/AODVv2. One view is the merge can happen and another (unfortunately = by some authors of LOADng) that such a merge is impractical.

So, irrespective of how we got to where we are, the point is it is a g= ood time to draw a conclusion on which of the 3 options above MANET should = take to meet its requirement for a reactive routing protocol.

Don


From: "Charles E. Perkins"= ; <charliep@c= omputer.org>
Organization: Saratoga Blue Skies Date: Thursday, November 1, 2012 11= :32 AM
To: Don Sturek <d.sturek@att.net>
Cc: "manet@ietf.org" <manet@ietf.org>
Subject: Re: [manet] Reactive Proto= col Situation


Hello Don,

Your claim has been made several times, and I think it is highly misleading= .

The bottom line is that the editorship of the WG document is now in good hands, and given the time available in the past, good progress has been
made.=A0 Also given my renewed emphasis, support from my job, and clear
understanding of goals, I can confidently state that I can do the work, and=
can manage the editorship process to follow working group discussion to
completion.=A0 Here is (some of) what happened.=A0 I hope you will read it.=

I was asked last fall to resume editorship of the DYMO document, and
agreed to do so.

Almost at the same time, I was invited to work with the LOADng authors
to produce a merged document that incorporated the best features from
DYMO and from LOADng.=A0 At that time, the general agreement was that
the merged document would be renamed AODVv2.

Because of various personal difficulties unfamiliar in my experience, I was=
surprised to find very late in the winter that the merge was not happening.=
In order to carry out my responsibility, which was clearly to submit a
revised document for IETF 83 in Paris, I took the resource available to me<= br> and within less than a week I submitted the revised DYMO draft renamed
to be AODVv2.

People attending the meeting will remember what happened.=A0 I was quite unjustly attacked and called names for doing:
a) what I said I would do
b) what I was supposed to do, and
c) changing the document to become more compatible with LOADng, as
=A0=A0=A0 requested by those authors and according to my best understanding= .

After that, I still hoped that we could do the merge, but nothing happened<= br> until in Vancouver when the WG chairs gave us an ultimatum to make
something happen by November.

We went around and around, but I eventually determined that there
was almost no chance that the LOADng authors would willingly help to
produce the desired merge.=A0 So I did what the LOADng authors had asked me not to do: namely submit a revised document for consideration.
This revised document was an attempt to respond to valid comments
made during 2010 about problems with the document while it was
under Ian's editorial responsibility.=A0 It needs further revision -- i= n fact
I will submit a much more polished document on my website this
week.

The important point is that for the last year the document languished
for all but a few weeks *at the request of the LOADng authors* --
in fact, I would even say at their *DEMAND*, and all the while they
refused to help make the merge that (a) they had originally suggested
and (b) I was supposed to do.

This note is already too long.=A0 I have much, much more to say.
But I will say one more thing: I have the ability and now the time to
do an excellent job on this, and I am here on the job only for the
benefit of the working group.=A0 Now that I can focus on it, and now
that I do not feel constrained to abide by the demands for delay
that were imposed by the LOADng author team, I can do it pretty
expediently.=A0 Of course I will welcome their input as well, and to
further reiterate it will be my intention to make the WG document
compatible with the needs of LOADng.

Oh -- and one more thing...=A0 Regardless of the poisoned atmosphere
surrounding this debate, I have nothing but high regard for the work
done by the LOADng team.=A0 I don't think their methods are right for this working group, and any statements to the effect that the DYMO
editorial process has been deficient during the last year or more
should be understood in light of the above narrative.

Regards,
Charlie P.

PS. Oh, and one more thing...=A0 I am a peaceful man, and if I don't =A0=A0=A0=A0=A0=A0=A0 respond to all the invective and intransigence so cle= arly
=A0=A0=A0=A0=A0=A0=A0 in evidence lately, you'll just have to excuse me= for trying
=A0=A0=A0=A0=A0=A0=A0 to remain so.


On 11/1/2012 9:40 AM, Don Sturek wrote:
Hi Adbussalam,

It is hard to consider a draft stalled 2+ years as the only way forwar= d in MANET as a reactive protocol.

Don



From: Abdussalam Baryun <abdussalambaryun@g= mail.com>
Date: Thursday, November 1, 2012 8:= 53 AM
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@ietf.org>, Stan Ratliff <<= a href=3D"mailto:sratliff@cisco.com" target=3D"_blank">sratliff@cisco.com>
Subject: Re: [manet] Reactive Proto= col Situation

Yes LOADng is a reactive protocols, but not the MANET=A0WG reactive pr= otocol (DYMO is already authorised). The WG is the only authorised to make = such decisions for its WG drafts, if WG decides to add any LOADng ideas it = can, or to accept such merge it can as well,
AB
On Thu, Nov 1, 2012 at 3:37 PM, Jon Black <jblack.ietf@= yahoo.com> wrote:
Why would you think that LOADng is not reactive?=A0 If it is not a reactive= protocol, then what is it?

As to merging the documents, this is what WGs do.=A0 If you have multiple &= quot;competing" ideas you ask the authors to see if they can merge the= ir concepts and ideas.=A0 If they cannot or will not then the WG must decid= e based on facts and not conjecture which is the most prudent path to take.

Jon


From: Abdussalam Baryun <= abdussalamb= aryun@gmail.com>
To: Joseph Macker <jpmacker@gmail.com>= ;
Cc: manet@ietf.org; Stan Ratliff <sratliff@cisco.com>
Sent: Thursday, November 1, = 2012 8:22 AM

Subject: Re: [manet] Reactiv= e Protocol Situation

Dear Joseph Macker and Stan,
MANET WG Chairs
=A0
I disagree that the=A0WG=A0arranged/guided to merge the documents, I n= ever heard that there was a consensus on such activity. DYMO is a reactive = WG draft, but LOADng is not. Why did you guide to merge documents, I recomm= end that you ment to merge the team drafts co-authors to one=A0WG draft (which is only DYMO so far). The autho= rity is for the WG to decide to merge individual drafts to its WG draft.
=A0
Therefore, my vote is for option 1 only. Thanking you for updating us = with the status.
=A0
Regards
AB

On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker <= jp= macker@gmail.com> wrote:
Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.=A0 Since = that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active author= ship and implementation efforts. We provided a co-editing proposal to the a= uthors and gave them the timeframe of the Atlanta to come up with an answer= back to us regarding this.=A0 As of this writing, those discussions of a potential commonn document and aut= horship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.=A0 We see = only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.=A0 We have bee= n some silent collecting initial feedback and waiting for author feedback a= t this point.=A0 Stan and I are both on travel prior to Atlanta so our resp= onses may be sparse and we will also likely be in a "receive mode" for a few days.=A0 So send your op= inions.

-Joe

_______________________________________________
manet mailing list
manet@= ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



_______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet 

_______________________________________________
manet mailing list
manet@ietf.orghttps:=
//www.ietf.org/mailman/listinfo/manet


--=20
Regards,
Charlie P.
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet




--
Regards,
Stan


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--bcaec54b46c4f28e6104cd74be35-- From jvasseur@cisco.com Thu Nov 1 13:20:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2882E21F96A8 for ; Thu, 1 Nov 2012 13:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.198 X-Spam-Level: X-Spam-Status: No, score=-10.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F31xbGOS4BMF for ; Thu, 1 Nov 2012 13:20:53 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2218121F96B2 for ; Thu, 1 Nov 2012 13:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31931; q=dns/txt; s=iport; t=1351801247; x=1353010847; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZEgcUPYnsm+O0TbdZ51pItp5CRCQPw3TybBAx3VoVb8=; b=HIp+VKLDTooSubyuYg8Z93yGdWb/mtXU6z/hf+zF0hygQS9Q0XLwq9TP 60Iy8pZCL8TUIaHxCHYnkDhWl6LQRVx5zVkjSgDQ0s6LhWYjwKM8TuFF1 vZ9xrc+RX/ZUWX36ibbZZZ1vFP9YVB0ATrALUHuWvCG0xT4387lmZqCli 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAZAHbYklCtJXG9/2dsb2JhbABEgXQGAU6vC5IbgQiCHgEBAQQBAQEPAQdSAggDEAIBCBEDAQEBCxYHByEGCxMBCQgCBA4FCAEZh1IDDwucWJZNBQiJVIsUZwoIhUhhA5JGgV0EjQODJoFrgm+BZBce X-IronPort-AV: E=Sophos;i="4.80,695,1344211200"; d="scan'208,217";a="137937968" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 01 Nov 2012 20:20:46 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA1KKk1d019151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 20:20:46 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 15:20:45 -0500 From: "JP Vasseur (jvasseur)" To: Stan Ratliff Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuGhALPVi/cSo/ES1hdb7zda62w== Date: Thu, 1 Nov 2012 20:20:45 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204A31D@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A7722049CC0@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.90.251] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--41.360600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204A31Dxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: " List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 20:20:55 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204A31Dxmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Stan. On Nov 1, 2012, at 4:11 PM, Stan Ratliff wrote: JP, Speaking for myself (not necessarily for Joe, as I haven't discussed with h= im a couple of days), my intent with the email was to bring the situation v= is-a-vis reactive protocols to the WG's attention, and to see if the group = coalesces around any of the three options. To be frank, based on the last 3 months of discussion, and the current emai= l storm (including references to the "toxic environment"), I believe that t= he situation has passed to point of no return. I do not think the respectiv= e authors, or the WG as a whole, will ever (or at least for the foreseeable= future) be able to reach consensus on a reactive protocol. Therefore, my p= reference is to remove the work item from the charter. Let's see how the discussion progresses. Regards, Stan On Thu, Nov 1, 2012 at 3:36 PM, JP Vasseur (jvasseur) > wrote: Agree with you Don. Since discussions are going in many directions =85 would the chairs help us= organize these discussions ? Are you indeed asking us to express our preference for one of these options= , pick one and start from there ? On Nov 1, 2012, at 7:40 PM, Don Sturek wrote: Hi Charlie, Apologies if I misrepresented the facts on DYMO/AODVv2=85=85 I do think the facts as exist right now are: 1) We have a LOADng draft that claims support to address the MANET reactiv= e protocol requirements 2) Work has restarted (by yourself) on DYMO/AODVv2 3) There are two different views on the ability to merge LOADng with DYMO/= AODVv2. One view is the merge can happen and another (unfortunately by some= authors of LOADng) that such a merge is impractical. So, irrespective of how we got to where we are, the point is it is a good t= ime to draw a conclusion on which of the 3 options above MANET should take = to meet its requirement for a reactive routing protocol. Don From: "Charles E. Perkins" > Organization: Saratoga Blue Skies Date: Thursday, November 1, 2012 11:32 AM To: Don Sturek > Cc: "manet@ietf.org" > Subject: Re: [manet] Reactive Protocol Situation Hello Don, Your claim has been made several times, and I think it is highly misleading= . The bottom line is that the editorship of the WG document is now in good hands, and given the time available in the past, good progress has been made. Also given my renewed emphasis, support from my job, and clear understanding of goals, I can confidently state that I can do the work, and can manage the editorship process to follow working group discussion to completion. Here is (some of) what happened. I hope you will read it. I was asked last fall to resume editorship of the DYMO document, and agreed to do so. Almost at the same time, I was invited to work with the LOADng authors to produce a merged document that incorporated the best features from DYMO and from LOADng. At that time, the general agreement was that the merged document would be renamed AODVv2. Because of various personal difficulties unfamiliar in my experience, I was surprised to find very late in the winter that the merge was not happening. In order to carry out my responsibility, which was clearly to submit a revised document for IETF 83 in Paris, I took the resource available to me and within less than a week I submitted the revised DYMO draft renamed to be AODVv2. People attending the meeting will remember what happened. I was quite unjustly attacked and called names for doing: a) what I said I would do b) what I was supposed to do, and c) changing the document to become more compatible with LOADng, as requested by those authors and according to my best understanding. After that, I still hoped that we could do the merge, but nothing happened until in Vancouver when the WG chairs gave us an ultimatum to make something happen by November. We went around and around, but I eventually determined that there was almost no chance that the LOADng authors would willingly help to produce the desired merge. So I did what the LOADng authors had asked me not to do: namely submit a revised document for consideration. This revised document was an attempt to respond to valid comments made during 2010 about problems with the document while it was under Ian's editorial responsibility. It needs further revision -- in fact I will submit a much more polished document on my website this week. The important point is that for the last year the document languished for all but a few weeks *at the request of the LOADng authors* -- in fact, I would even say at their *DEMAND*, and all the while they refused to help make the merge that (a) they had originally suggested and (b) I was supposed to do. This note is already too long. I have much, much more to say. But I will say one more thing: I have the ability and now the time to do an excellent job on this, and I am here on the job only for the benefit of the working group. Now that I can focus on it, and now that I do not feel constrained to abide by the demands for delay that were imposed by the LOADng author team, I can do it pretty expediently. Of course I will welcome their input as well, and to further reiterate it will be my intention to make the WG document compatible with the needs of LOADng. Oh -- and one more thing... Regardless of the poisoned atmosphere surrounding this debate, I have nothing but high regard for the work done by the LOADng team. I don't think their methods are right for this working group, and any statements to the effect that the DYMO editorial process has been deficient during the last year or more should be understood in light of the above narrative. Regards, Charlie P. PS. Oh, and one more thing... I am a peaceful man, and if I don't respond to all the invective and intransigence so clearly in evidence lately, you'll just have to excuse me for trying to remain so. On 11/1/2012 9:40 AM, Don Sturek wrote: Hi Adbussalam, It is hard to consider a draft stalled 2+ years as the only way forward in = MANET as a reactive protocol. Don From: Abdussalam Baryun > Date: Thursday, November 1, 2012 8:53 AM To: Jon Black > Cc: "manet@ietf.org" >, Stan Ratliff > Subject: Re: [manet] Reactive Protocol Situation Yes LOADng is a reactive protocols, but not the MANET WG reactive protocol = (DYMO is already authorised). The WG is the only authorised to make such de= cisions for its WG drafts, if WG decides to add any LOADng ideas it can, or= to accept such merge it can as well, AB On Thu, Nov 1, 2012 at 3:37 PM, Jon Black > wrote: Why would you think that LOADng is not reactive? If it is not a reactive p= rotocol, then what is it? As to merging the documents, this is what WGs do. If you have multiple "co= mpeting" ideas you ask the authors to see if they can merge their concepts = and ideas. If they cannot or will not then the WG must decide based on fac= ts and not conjecture which is the most prudent path to take. Jon ________________________________ From: Abdussalam Baryun > To: Joseph Macker > Cc: manet@ietf.org; Stan Ratliff > Sent: Thursday, November 1, 2012 8:22 AM Subject: Re: [manet] Reactive Protocol Situation Dear Joseph Macker and Stan, MANET WG Chairs I disagree that the WG arranged/guided to merge the documents, I never hear= d that there was a consensus on such activity. DYMO is a reactive WG draft,= but LOADng is not. Why did you guide to merge documents, I recommend that = you ment to merge the team drafts co-authors to one WG draft (which is only= DYMO so far). The authority is for the WG to decide to merge individual dr= afts to its WG draft. Therefore, my vote is for option 1 only. Thanking you for updating us with = the status. Regards AB On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker > wrote: Hello MANET working group (form Stan and Joe), As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common documen= t effort and given positive feedback at the time we the chairs thought this= was the best approach given the authors potential to come together and gai= n the best of both efforts. Since that period, there has been some fairly = strident and rancorous "at times" debate between the authors of the two doc= uments. During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts = and LOADng had fairly active authorship and implementation efforts. We prov= ided a co-editing proposal to the authors and gave them the timeframe of th= e Atlanta to come up with an answer back to us regarding this. As of this = writing, those discussions of a potential commonn document and authorship m= erger have failed. Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss= ue at the present time. We see only 3 possible paths forward: 1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2. 2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document). 3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus. The co-chairs request and need your opinions on the options. We have been = some silent collecting initial feedback and waiting for author feedback at = this point. Stan and I are both on travel prior to Atlanta so our response= s may be sparse and we will also likely be in a "receive mode" for a few da= ys. So send your opinions. -Joe _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ie= tf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.orghttps://www.ietf.org/mailman/listinfo/= manet -- Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet -- Regards, Stan --_000_03B78081B371D44390ED6E7BADBB4A772204A31Dxmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Thanks Stan.

On Nov 1, 2012, at 4:11 PM, Stan Ratliff wrote:

JP,

Speaking for myself (not necessarily for Joe, as I haven't discussed with h= im a couple of days), my intent with the email was to bring the situation v= is-a-vis reactive protocols to the WG's attention, and to see if the group = coalesces around any of the three options.

To be frank, based on the last 3 months of discussion, and the current emai= l storm (including references to the "toxic environment"), I beli= eve that the situation has passed to point of no return. I do not think the= respective authors, or the WG as a whole, will ever (or at least for the foreseeable future) be able to reach consen= sus on a reactive protocol. Therefore, my preference is to remove the work = item from the charter.

Let's see how the discussion progresses.

Regards,
Stan

On Thu, Nov 1, 2012 at 3:36 PM, JP Vasseur (jvas= seur) <jvasseur@cisco.= com> wrote:
Agree with you Don.

Since discussions are going in many directions =85 would the chairs he= lp us organize these discussions ?

Are you indeed asking us to express our preference for one of these op= tions, pick one and start from there ?

On Nov 1, 2012, at 7:40 PM, Don Sturek wrote:

Hi Charlie,

Apologies if I misrepresented the facts on DYMO/AODVv2=85=85

I do think the facts as exist right now are:
1)  We have a LOADng draft that claims support to address the MAN= ET reactive protocol requirements
2)  Work has restarted (by yourself) on DYMO/AODVv2
3)  There are two different views on the ability to merge LOADng = with DYMO/AODVv2. One view is the merge can happen and another (unfortunate= ly by some authors of LOADng) that such a merge is impractical.

So, irrespective of how we got to where we are, the point is it is a g= ood time to draw a conclusion on which of the 3 options above MANET should = take to meet its requirement for a reactive routing protocol.

Don


From: "Charles E. Perkins"= ; <charliep@c= omputer.org>
Organization: Saratoga Blue Skies Date: Thursday, November 1, 2012 11= :32 AM
To: Don Sturek <d.sturek@att.net>
Cc: "manet@ietf.org" <manet@ietf.org>
Subject: Re: [manet] Reactive Proto= col Situation


Hello Don,

Your claim has been made several times, and I think it is highly misleading= .

The bottom line is that the editorship of the WG document is now in good hands, and given the time available in the past, good progress has been
made.  Also given my renewed emphasis, support from my job, and clear<= br> understanding of goals, I can confidently state that I can do the work, and=
can manage the editorship process to follow working group discussion to
completion.  Here is (some of) what happened.  I hope you will re= ad it.

I was asked last fall to resume editorship of the DYMO document, and
agreed to do so.

Almost at the same time, I was invited to work with the LOADng authors
to produce a merged document that incorporated the best features from
DYMO and from LOADng.  At that time, the general agreement was that the merged document would be renamed AODVv2.

Because of various personal difficulties unfamiliar in my experience, I was=
surprised to find very late in the winter that the merge was not happening.=
In order to carry out my responsibility, which was clearly to submit a
revised document for IETF 83 in Paris, I took the resource available to me<= br> and within less than a week I submitted the revised DYMO draft renamed
to be AODVv2.

People attending the meeting will remember what happened.  I was quite=
unjustly attacked and called names for doing:
a) what I said I would do
b) what I was supposed to do, and
c) changing the document to become more compatible with LOADng, as
    requested by those authors and according to my best unde= rstanding.

After that, I still hoped that we could do the merge, but nothing happened<= br> until in Vancouver when the WG chairs gave us an ultimatum to make
something happen by November.

We went around and around, but I eventually determined that there
was almost no chance that the LOADng authors would willingly help to
produce the desired merge.  So I did what the LOADng authors had asked=
me not to do: namely submit a revised document for consideration.
This revised document was an attempt to respond to valid comments
made during 2010 about problems with the document while it was
under Ian's editorial responsibility.  It needs further revision -- in= fact
I will submit a much more polished document on my website this
week.

The important point is that for the last year the document languished
for all but a few weeks *at the request of the LOADng authors* --
in fact, I would even say at their *DEMAND*, and all the while they
refused to help make the merge that (a) they had originally suggested
and (b) I was supposed to do.

This note is already too long.  I have much, much more to say.
But I will say one more thing: I have the ability and now the time to
do an excellent job on this, and I am here on the job only for the
benefit of the working group.  Now that I can focus on it, and now
that I do not feel constrained to abide by the demands for delay
that were imposed by the LOADng author team, I can do it pretty
expediently.  Of course I will welcome their input as well, and to
further reiterate it will be my intention to make the WG document
compatible with the needs of LOADng.

Oh -- and one more thing...  Regardless of the poisoned atmosphere
surrounding this debate, I have nothing but high regard for the work
done by the LOADng team.  I don't think their methods are right for this working group, and any statements to the effect that the DYMO
editorial process has been deficient during the last year or more
should be understood in light of the above narrative.

Regards,
Charlie P.

PS. Oh, and one more thing...  I am a peaceful man, and if I don't
        respond to all the invective and= intransigence so clearly
        in evidence lately, you'll just = have to excuse me for trying
        to remain so.


On 11/1/2012 9:40 AM, Don Sturek wrote:
Hi Adbussalam,

It is hard to consider a draft stalled 2+ years as the only way fo= rward in MANET as a reactive protocol.

Don



From: Abdussalam Baryun <abdussalambaryun@g= mail.com>
Date: Thursday, November 1, 2012 8:= 53 AM
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@ietf.org>, Stan Ratliff <<= a href=3D"mailto:sratliff@cisco.com" target=3D"_blank">sratliff@cisco.com>
Subject: Re: [manet] Reactive Proto= col Situation

Yes LOADng is a reactive protocols, but not the MANET WG reactive= protocol (DYMO is already authorised). The WG is the only authorised to ma= ke such decisions for its WG drafts, if WG decides to add any LOADng ideas = it can, or to accept such merge it can as well,
AB
On Thu, Nov 1, 2012 at 3:37 PM, Jon Black <jblack.ietf@= yahoo.com> wrote:
Why would you think that LOADng is not reactive?  If it is not a r= eactive protocol, then what is it?

As to merging the documents, this is what WGs do.  If you have multipl= e "competing" ideas you ask the authors to see if they can merge = their concepts and ideas.  If they cannot or will not then the WG must= decide based on facts and not conjecture which is the most prudent path to take.

Jon


From: Abdussalam Baryun <= abdussalamb= aryun@gmail.com>
To: Joseph Macker <jpmacker@gmail.com>= ;
Cc: manet@ietf.org; Stan Ratliff <sratliff@cisco.com>
Sent: Thursday, November 1, = 2012 8:22 AM

Subject: Re: [manet] Reactiv= e Protocol Situation

Dear Joseph Macker and Stan,
MANET WG Chairs
 
I disagree that the WG arranged/guided to merge the document= s, I never heard that there was a consensus on such activity. DYMO is a rea= ctive WG draft, but LOADng is not. Why did you guide to merge documents, I = recommend that you ment to merge the team drafts co-authors to one WG draft (which is only DYMO so far). The au= thority is for the WG to decide to merge individual drafts to its WG draft.=
 
Therefore, my vote is for option 1 only. Thanking you for updating us = with the status.
 
Regards
AB

On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker <= jp= macker@gmail.com> wrote:
Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.  Sin= ce that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active author= ship and implementation efforts. We provided a co-editing proposal to the a= uthors and gave them the timeframe of the Atlanta to come up with an answer= back to us regarding this.  As of this writing, those discussions of a potential commonn document and aut= horship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.  We s= ee only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have = been some silent collecting initial feedback and waiting for author feedbac= k at this point.  Stan and I are both on travel prior to Atlanta so ou= r responses may be sparse and we will also likely be in a "receive mode" for a few days.  So send your= opinions.

-Joe

_______________________________________________
manet mailing list
manet@= ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



_______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet 

_______________________________________________
manet mailing list
manet@ietf.orghttps:=
//www.ietf.org/mailman/listinfo/manet


--=20
Regards,
Charlie P.
____________________________= ___________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet




--
Regards,
Stan


--_000_03B78081B371D44390ED6E7BADBB4A772204A31Dxmbrcdx02ciscoc_-- From abdussalambaryun@gmail.com Thu Nov 1 13:57:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3360621F96BB for ; Thu, 1 Nov 2012 13:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8y4rBdIv5VK for ; Thu, 1 Nov 2012 13:57:48 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 109EB21F9630 for ; Thu, 1 Nov 2012 13:57:47 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3487616vcb.31 for ; Thu, 01 Nov 2012 13:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=P2J8f9xoYGk+a1/xVoEMiHuAiJTNc5/MKRsFTW/K7T4=; b=OoVdIbAM4XVqoTuYzeE2j/SiV1mYRsyO0rWeX+H8Sy6P7dUBoSG+H/4kkGAw8P3mXB EEpQWaLBTO7BzXOqlsd30C4DbVSALDvQCVgXSoKzPriv393eskUgd1KIXU43g059R5ng FA9qsdhSLlwoWBeImi9QUH9X/4VjjRgTzXfBvl2YakV5Y7bBIwwTsy5yW6LSmvlonQi3 9DQVBtWMZXFS6QIzn9VTQtcn6GyJKePB5q6cgA/ZkwNVK6Y8TlvRUr5qw/uTclrLOFkm C1q6/2Ai11kK485LLboNcfzUvxzxNLSHl9JR514KGH0KYNNTdQkiwuJpRhxQgcmE9w9g Um1w== MIME-Version: 1.0 Received: by 10.52.77.101 with SMTP id r5mr52402692vdw.25.1351803467457; Thu, 01 Nov 2012 13:57:47 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 13:57:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Nov 2012 20:57:46 +0000 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: multipart/alternative; boundary=20cf307abd937be30904cd75451c Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 20:57:49 -0000 --20cf307abd937be30904cd75451c Content-Type: text/plain; charset=ISO-8859-1 Dear MANET WG Chairs, I recommend we base our choices and options on our present ietf Charter and milestones we got so far, so we can follow in our choices the best practice. I recommend that we look into the following three options which can be based on the MANET Charter and the WG-I-Ds' work-flow-progress: 1- DYMO/AODVv2 to be completed and prepared by the WG to be submitted. 2- The WG chairs and participants to work together in one team work of authoring one reactive protocol (a merge solution, with both draft authors including WG chair). 3- Accept the individual LOADng draft as a second reactive protocol, then, to decide in the future how to merge both AODVv2 ideas into LOADng depending on comparing specifications. My Comments on the mentioned drafts history and your recommended options, in line in below message, AB ++++++++++++++ On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker wrote: > Hello MANET working group (form Stan and Joe), > > As you are all probably aware, there has been WG activity lately on > competing drafts for a MANET reactive protocol - DYMO (reviving the current > working group document that was parked due to inactivity), and LOADng. Many > months ago there was a somewhat authorship led movement towards a common > document effort and given positive feedback at the time we the chairs > thought this was the best approach given the authors potential to come > together and gain the best of both efforts. Since that period, there has > been some fairly strident and rancorous "at times" debate between the > authors of the two documents. > There was never any announcement of such merge movement, however, there was a suggestion for that by one DYMO author but was refused by one LOADng author. > > During IETF 84 in Vancouver, the co-chairs held a discussion with some of > the co-authors of the two documents. Our guidance to the co-authors was to > find a way to merge the two documents into one, as it was perceived that > are not technically far apart and they both derive roughly from AODV > concepts and LOADng had fairly active authorship and implementation > efforts. We provided a co-editing proposal to the authors and gave them the > timeframe of the Atlanta to come up with an answer back to us regarding > this. As of this writing, those discussions of a potential commonn > document and authorship merger have failed. > Again in the 84 meeting there was no such announcement of any merge between DYMO's I-D and the LOADng I-D. We only seen an author added to LOADng I-D which was an author of DYMO I-D, but does not meen merging drafts and not announced to WG such suggestions. > > Therefore, we find ourselves at a crossroads. The authors of the two > documents are divided, and it is unlikely that progress on a merged > document can be reached based upon recent author feedback. I have also > polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat > disengaged on the issue at the present time. We see only 3 possible paths > forward: > > 1. Continue the work on the DYMO document, starting with whether there is > consensus on its continued approach and also the desire to rename it to > AODVv2. > There is no reason why we need to ignore this option, is it because DYMO authors did not do any work for some time and the WG as well did not do any, or is it because an individual draft came up to interrupt the WG work in progress. > 2. Replace the existing DYMO document effort with the LOADng related > document effort, defusing ealier references to LLNs as recommended in the > last meeting minutes, and to focus more motivationally on general MANET > problem spaces (the authors seem to have agreed to this issue if its a WG > document). > We need to accept the LOADng as a WG item first then we decide if we can take option 2 > 3. Remove the working group charter for a reactive protocol, effectively > killing both documents, at least from a working group (WG) standpoint. This > would not be a reflection on the technology in either case, just an > admission that we are not working together and reaching consensus. > The reactive protocol is a must protocol for MANETs, killing it will not really kill it but will give chance to other competitor organisations to standard reactive protocol before IETF. > > The co-chairs request and need your opinions on the options. We have been > some silent collecting initial feedback and waiting for author feedback at > this point. Stan and I are both on travel prior to Atlanta so our > responses may be sparse and we will also likely be in a "receive mode" for > a few days. So send your opinions. > > -Joe > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --20cf307abd937be30904cd75451c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear MANET WG Chairs,
=A0
I recommend we base our = choices and options on our present ietf Charter and milestones we got so fa= r, so we can follow in our choices the best practice.
=A0
<= div> I recommend that we look into=A0the following three options which can be ba= sed on the MANET Charter and the WG-I-Ds' work-flow-progress:
=A0
1- DYMO/AODVv2 to be completed and prepared by the WG to be = submitted.
2- The WG chairs and participants to work together in one team work of= authoring one reactive protocol (a merge solution, with both draft authors= including WG chair).
3- Accept the individual LOADng draft as a = second reactive protocol, then,=A0to decide in the future how to merge both= AODVv2 ideas into=A0LOADng depending on comparing specifications.
My Comments on the mentioned drafts=A0history and your recommend= ed options, in line in below message,
=A0
AB
+++++++= +++++++
On Tue, Oct 30, 2012 at 11:13 PM, J= oseph Macker <jpmacker@gmail.com> wrote:
Hello MANET working group (form Stan and Joe),

As y= ou are all probably aware, there has been WG activity lately on competing d= rafts for a MANET reactive protocol - DYMO (reviving the current working gr= oup document that was parked due to inactivity), and LOADng. Many months ag= o there was a somewhat authorship led movement towards a common document ef= fort and given positive feedback at the time we the chairs thought this was= the best approach given the authors potential to come together and gain th= e best of both efforts.=A0 Since that period, there has been some fairly st= rident and rancorous "at times" debate between the authors of the= two documents.
=A0
There was never any announcement of such me= rge movement, however, there was a suggestion for that by one DYMO author= =A0but was refused by=A0one LOADng author.

During IETF 84 in Vancouver, the co-chairs held a discussion with some = of the co-authors of the two documents. Our guidance to the co-authors was = to find a way to merge the two documents into one, as it was perceived that= are not technically far apart and they both derive roughly from AODV conce= pts and LOADng had fairly active authorship and implementation efforts. We = provided a co-editing proposal to the authors and gave them the timeframe o= f the Atlanta to come up with an answer back to us regarding this.=A0 As of= this writing, those discussions of a potential commonn document and author= ship merger have failed.
=A0
Again in the 84 meeting there was no such a= nnouncement of any merge between DYMO's I-D and the LOADng I-D. We only= seen an author added to LOADng I-D which was an author of DYMO I-D, but do= es not meen merging drafts and not announced to WG such suggestions.=A0

Therefore, we find ourselves at a crossroads. The authors of the two do= cuments are divided, and it is unlikely that progress on a merged document = can be reached based upon recent author feedback. I have also polled the ea= rlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the= issue at the present time.=A0 We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there = is consensus on its continued approach and also the desire to rename it to = AODVv2.
There is no reason why we need to ignore this = option, is it because DYMO authors did not do any work for some time and th= e WG as well did not do any, or is it because an individual draft came up t= o interrupt the WG work in progress.
=A0
2. Replace the existing DYMO document effort= with the LOADng related document effort, defusing ealier references to LLN= s as recommended in the last meeting minutes, and to focus more motivationa= lly on general MANET problem spaces (the authors seem to have agreed to thi= s issue if its a WG document).
=A0
We need to accept the LOADng as a WG item f= irst then we decide if we can take option 2
=A0
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.
=A0
The reactive protocol is a must protocol fo= r MANETs, killing it will not really kill it but will give chance to other = competitor organisations to standard reactive protocol before IETF.

The co-chairs request and need your opinions on the options.=A0 We have= been some silent collecting initial feedback and waiting for author feedba= ck at this point.=A0 Stan and I are both on travel prior to Atlanta so our = responses may be sparse and we will also likely be in a "receive mode&= quot; for a few days.=A0 So send your opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--20cf307abd937be30904cd75451c-- From abdussalambaryun@gmail.com Thu Nov 1 14:15:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C96721F9711 for ; Thu, 1 Nov 2012 14:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PS4NylhkPfxZ for ; Thu, 1 Nov 2012 14:15:32 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 51BE921F96F8 for ; Thu, 1 Nov 2012 14:15:32 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3504929vcb.31 for ; Thu, 01 Nov 2012 14:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QzfAogT2z6/5j7bgawDBQF4yAKAlSBKGaKdHiTsJcLY=; b=ht/A4m1syVij3cUMmNhR/+TitI9H18pPKHu6g2TTJ0ltV+hpzhVBIn/acMK4SgyypL M+MrbwRUX2lpVKYOPEia1AmbhkgVQeWpOxkeDnYZK2YNFu3L5RrS1w2r6lhSYJRomhWg AM/0XIqSntvJi0P+2a1XsNSo89+d+i/MTxv65cFDCot8OpcmpoUoFJ5x0yhGKoc/yOYa IdSI7GoTC6rT14l/EpbI8DzQ0l1aQjdvMawEh3TWxaSJQhduxBGOdOcsm1ZciBbb9HGm W3fmCHxIncWAa/W/ZzMdQtS0a9M4jfm59X/TUl+BmavAYCCzeOCNWzjDGIL6schgto+b lkdg== MIME-Version: 1.0 Received: by 10.52.33.165 with SMTP id s5mr53282615vdi.55.1351804531760; Thu, 01 Nov 2012 14:15:31 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 1 Nov 2012 14:15:31 -0700 (PDT) In-Reply-To: <50916CC0.7010900@computer.org> References: <50916CC0.7010900@computer.org> Date: Thu, 1 Nov 2012 21:15:31 +0000 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=20cf3079bc70ebdf7904cd75848e Cc: manet Subject: Re: [manet] Reactive protocol terminology proposal X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 21:15:34 -0000 --20cf3079bc70ebdf7904cd75848e Content-Type: text/plain; charset=ISO-8859-1 +1, thanks, On Wed, Oct 31, 2012 at 6:24 PM, Charles E. Perkins wrote: > > Hello folks, > > As mentioned previously, several people have expressed the opinion > that the DYMO language needs a bit of improvement. One way to do > that is to use terminology that is consistent, intuitive, and conforms > with other terminology in common use. > > With that in mind, I would like to suggest the following terminology > changes for AODVv2. Comments are welcome as always. There are > some other changes in the document organization that would also > be very helpful, but I will cover those in another message to the list. > > ==============================**============================ > > - A Route Table is a collection of Route Table Entries > - Each Route Table Entry has the following data: > * Destination Address > * Prefix > * Cost / Distance / Metric > * Metric Type > * Route Timeout (ROUTE_DELETE_TIMEOUT) > * Next Hop > * Sequence Number > * Sequence Number Timeout (ROUTE_SEQNUM_AGE_MAX_TIMEOUT) > > - Each router keeps track of which neighbors have been blacklisted; > each blacklist entry has the following data: > * blacklisted neighbor IP address > * blacklist entry timeout > > - Number of RREQs sent for a required destination > - Own Sequence Number > > Terminology proposal: > - Fields in incoming RREQs: IncomingRREQ. > - Fields in outgoing RREQs: OutgoingRREQ. > - Fields in incoming RREPs: IncomingRREP. > - Fields in outgoing RREPs: OutgoingRREP. > - Fields in incoming routing messages: IncomingRteMsg. > - Fields in outgoing routing messages: OutgoingRteMsg. > - Fields in incoming RERRs: IncomingRERR. > - Fields in outgoing RERRs: OutgoingRERR. > > RREQs are sent by an Discovering Router to discover a route for a Target > Node. > RREPs are sent by a Target Router to a Discovering Router. > RERRs are sent to Upstream Routers when a router discovers a broken next > hop. > > If abbreviations are to be used, the following seem natural: > TargRtr, DiscRtr, UpstRtr, TargNode > ==============================**==============================**== > > -- > Regards, > Charlie P. > > ______________________________**_________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/**listinfo/manet > --20cf3079bc70ebdf7904cd75848e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1, thanks,

On Wed, Oct 31, 2012 at 6:24 = PM, Charles E. Perkins <charliep@computer.org> wrote:

Hello folks,

As mentioned previously, several people have expressed the opinion
that the DYMO language needs a bit of improvement. =A0One way to do
that is to use terminology that is consistent, intuitive, and conforms
with other terminology in common use.

With that in mind, I would like to suggest the following terminology
changes for AODVv2. =A0Comments are welcome as always. =A0There are
some other changes in the document organization that would also
be very helpful, but I will cover those in another message to the list.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

- A Route Table is a collection of Route Table Entries
- Each Route Table Entry has the following data:
=A0 =A0 * Destination Address
=A0 =A0 * Prefix
=A0 =A0 * Cost / Distance / Metric
=A0 =A0 * Metric Type
=A0 =A0 * Route Timeout =A0 =A0 =A0 =A0(ROUTE_DELETE_TIMEOUT)
=A0 =A0 * Next Hop
=A0 =A0 * Sequence Number
=A0 =A0 * Sequence Number Timeout =A0(ROUTE_SEQNUM_AGE_MAX_TIMEOUT)

- Each router keeps track of which neighbors have been blacklisted;
=A0 =A0 each blacklist entry has the following data:
=A0 =A0 * blacklisted neighbor IP address
=A0 =A0 * blacklist entry timeout

- Number of RREQs sent for a required destination
- Own Sequence Number

Terminology proposal:
- Fields in incoming RREQs: IncomingRREQ.<field>
- Fields in outgoing RREQs: OutgoingRREQ.<field>
- Fields in incoming RREPs: IncomingRREP.<field>
- Fields in outgoing RREPs: OutgoingRREP.<field>
- Fields in incoming routing messages: IncomingRteMsg.<field>
- Fields in outgoing routing messages: OutgoingRteMsg.<field>
- Fields in incoming RERRs: IncomingRERR.<field>
- Fields in outgoing RERRs: OutgoingRERR.<field>

RREQs are sent by an Discovering Router to discover a route for a Target No= de.
RREPs are sent by a Target Router to a Discovering Router.
RERRs are sent to Upstream Routers when a router discovers a broken next ho= p.

If abbreviations are to be used, the following seem natural:
=A0 =A0 TargRtr, DiscRtr, UpstRtr, TargNode
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

--
Regards,
Charlie P.

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf3079bc70ebdf7904cd75848e-- From ulrich@herberg.name Thu Nov 1 14:38:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B51521F8A50 for ; Thu, 1 Nov 2012 14:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.438 X-Spam-Level: X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZhZ+w-+YsL0 for ; Thu, 1 Nov 2012 14:38:32 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A038021F89A0 for ; Thu, 1 Nov 2012 14:38:07 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3549962vbb.31 for ; Thu, 01 Nov 2012 14:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=CxBlRFbsTKELSAXADEp8ScSRIYBlJlYI+isOHQGUl9c=; b=gqvoblHw71aOWQ8edPATchgG6IuMGs19XnK2OylDH3Avlmx81keg28W7YacFFtGPpQ ZHwY5SC0NQrfBEs9HGi6vMK+1vtOW92KWI+xilS5koc3AVTrse+usOSRuJGIGsd7WpKS uE5hIKc3ctCsHTl2UJMT5a/n2a9BOYRi4OKfU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding:x-gm-message-state; bh=CxBlRFbsTKELSAXADEp8ScSRIYBlJlYI+isOHQGUl9c=; b=hy/VeXlw6uY4K5X1z4fDsYfq7rKRGmQhhPXeetvwveJaFAWAPWQvt2yBFXR1XPXbHQ DwKGyDLbCBWLsmLazhVR8NFP4SsMSMVjW7lM2H1U+7rcvgZaD+zG4L4PWi4ylIqEhs7g NIJaTN6VDkAcxuMIioXl7TG2cw6dmz4xdvU1lUWHDUk2omn8ulh9eoHQdfVUzIYE9nqW 37j84JuqykxA72IRoAVfUqpN8OFugpLCUGoi7c44poLUchypIWSMH8SDocwJQzHckFAW 4/sYeGKUQwcV+sUp12TfwAVdH7D00C6XAt7Ey9z0Wl7kDIvaR30PpmUHh0SJBb2GywFW +zzA== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr53295556vdv.20.1351805886423; Thu, 01 Nov 2012 14:38:06 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Thu, 1 Nov 2012 14:38:06 -0700 (PDT) Date: Thu, 1 Nov 2012 14:38:06 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmWKUrNiGG3teHFd2neb5Y0xAwaA+t8uWwwH7iuFRlQPeoJqyAoCKSwFfxSuC45r9XPBxdl Subject: [manet] DYMO-23 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 21:38:39 -0000 Hi, during the discussion, I noticed that many just say "I like protocol foo1 better than foo2", without any technical argument. That is not very productive. Here is my review of the latest DYMO 23 draft. The main comments (as shown in detail below) are: - The draft is still very difficult to read and is underspecified in many occasions. For example, it is unclear how the blacklisting works, how metrics are used, how the TLVs are associated with certain addresses. Some of the parameters and TLVs specified in the IANA section are not used. There are at least four timers for each route entry, and it is unclear how they may affect each other. It is not clearly specified how to update forward/reverse routes + the route to the previous hop - The use of metrics is not well defined; there is an optional distance field. It is unclear how metrics are created, whether they are additive, how they are formatted etc. What happens if some routers now the Distance field, others don't use it. - There are several extensions specified, but too few details to assure interoperability. Some of them violate end-to-end security. - As messages are modified in transit, end-to-end security is not possible. The security considerations section does not fulfill the requirements in RFC3552. - Extensions, such as for security, cannot be hooked into AODVv2, as there is no section to allow an external mechanism to provide additional reasons to reject a message as invalid, such as done in RFC6130. - The IANA section is not correct. There are no requests, no new registries or code points in existing registries, no allocation policy is provided. - There are some layer violations where tasks that are to be done by the RFC5444 (de)multiplexer are handled in AODVv2. - There is a mandated order of addresses in RFC5444 messages; I think this is a bad idea if extensions want to add addresses. - Originator address and sequence number are contained in address block and address block TLV, instead of the message header, so there is additional overhead. - There is no RREP_ACK or other mechanism to verify bidirectionality of links. - It is unclear to me how the destination sequence number is used in RREQ and what it serves for. - Intermediate route replies are hard to secure with signatures Best regards Ulrich Mobile Ad hoc Networks Working Group C. Perkins Internet-Draft Futurewei Intended status: Standards Track I. Chakeres Expires: April 26, 2013 CenGen October 23, 2012 Dynamic MANET On-demand (AODVv2) Routing draft-ietf-manet-dymo-23 Abstract The Dynamic MANET On-demand (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. UH> It is really about dynamic topology, not "mobile routers". AODVv2 may be used in non-mobile mesh networks with a dynamic topology. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering on-demand convergence in dynamic topologies. UH> What is on-demand convergence? Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 26, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Perkins & Chakeres Expires April 26, 2013 [Page 1] =0C Internet-Draft AODVv2 October 2012 described in the Simplified BSD License. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 8 4.2. AODVv2 Message Structure and Information Elements . . . . 9 4.3. RteMsg-specific Protocol Elements . . . . . . . . . . . . 11 4.4. Route Error (RERR)-specific Protocol Elements . . . . . . 12 5. Detailed Operation for the Base Protocol . . . . . . . . . . . 13 5.1. AODVv2 Sequence Numbers . . . . . . . . . . . . . . . . . 13 5.1.1. Maintaining A Node's Own Sequence Number . . . . . . . 13 5.1.2. Actions After OwnSeqNum Loss . . . . . . . . . . . . . 13 5.2. AODVv2 Routing Table Operations . . . . . . . . . . . . . 13 5.2.1. Judging Routing Information's Usefulness . . . . . . . 13 5.2.2. Creating or Updating Route Table Entries . . . . . . . 15 5.2.3. Route Table Entry Timeouts . . . . . . . . . . . . . . 15 5.3. Routing Messages . . . . . . . . . . . . . . . . . . . . . 16 5.3.1. RREQ Creation . . . . . . . . . . . . . . . . . . . . 16 5.3.2. RREP Creation . . . . . . . . . . . . . . . . . . . . 17 5.3.3. RteMsg Handling . . . . . . . . . . . . . . . . . . . 18 5.4. Route Discovery . . . . . . . . . . . . . . . . . . . . . 20 5.5. Route Maintenance . . . . . . . . . . . . . . . . . . . . 21 5.5.1. Active Next-hop Router Adjacency Monitoring . . . . . 21 5.5.2. Updating Route Lifetimes During Packet Forwarding . . 22 5.5.3. RERR Generation . . . . . . . . . . . . . . . . . . . 22 5.5.4. RERR Handling . . . . . . . . . . . . . . . . . . . . 23 5.6. Unknown Message and TLV Types . . . . . . . . . . . . . . 24 5.7. Advertising Network Addresses . . . . . . . . . . . . . . 24 5.8. Simple Internet Attachment . . . . . . . . . . . . . . . . 24 5.9. Multiple Interfaces . . . . . . . . . . . . . . . . . . . 25 5.10. AODVv2 Control Packet/Message Generation Limits . . . . . 26 5.11. Optional Features . . . . . . . . . . . . . . . . . . . . 26 5.11.1. Expanding Rings Multicast . . . . . . . . . . . . . . 26 5.11.2. Intermediate RREP . . . . . . . . . . . . . . . . . . 27 5.11.3. Precursor Notification . . . . . . . . . . . . . . . . 27 5.11.4. Reporting Multiple Unreachable Nodes . . . . . . . . . 28 5.11.5. Message Aggregation . . . . . . . . . . . . . . . . . 28 5.11.6. Adding Additional Routing Information to a RteMsg . . 29 5.12. Administratively Configured Parameters and Timer Values . 30 5.13. IANA Considerations . . . . . . . . . . . . . . . . . . . 33 5.13.1. AODVv2 Message Types Specification . . . . . . . . . . 33 5.13.2. Message and Address Block TLV Type Specification . . . 33 5.13.3. Address Block TLV Specification . . . . . . . . . . . 34 Perkins & Chakeres Expires April 26, 2013 [Page 2] =0C Internet-Draft AODVv2 October 2012 5.14. Security Considerations . . . . . . . . . . . . . . . . . 34 5.15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 36 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.1. Normative References . . . . . . . . . . . . . . . . . . . 36 6.2. Informative References . . . . . . . . . . . . . . . . . . 37 Appendix A. Changes since the Previous Version . . . . . . . . . 38 Appendix B. Shifting Network Prefix Advertisement Between AODVv2 Routers . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Perkins & Chakeres Expires April 26, 2013 [Page 3] =0C Internet-Draft AODVv2 October 2012 1. Overview The Dynamic MANET On-demand (AODVv2) routing protocol [formerly named DYMO] enables on-demand, multihop unicast routing among AODVv2 routers in mobile ad hod networks [MANETs][RFC2119]. UH> Why is RFC2119 cited here? The basic operations of the AODVv2 protocol are route discovery and route maintenance. Route discovery is performed when an AODVv2 router must transmit a packet towards a destination for which it does not have a route. Route maintenance is performed to avoid dropping packets, when a route being used to forward packets from the source to a destination breaks, UH> That is something that is unclear in the draft. Would data packets be buffered on intermediate routers along their way? Would a new RREQ be issed from intermediate routers? If not, packets would be dropped. and to avoid prematurely expunging routes from the route table. During route discovery, an AODVv2 router initiates flooding of a Route Request message (RREQ) throughout the network to find a route to a particular destination, via the AODVv2 router responsible for this destination. During this hop-by-hop flooding process, each intermediate AODVv2 router receiving the RREQ message records a route to the originator. When the target's AODVv2 router receives the RREQ, it records a route to the originator and responds with a Route Reply (RREP) unicast hop-by-hop toward the originating AODVv2 router. Each intermediate AODVv2 router that receives the RREP creates a route to the target, and then the RREP is unicast hop-by-hop toward the originator. When the originator's AODVv2 router receives the RREP, routes have then been established between the originating AODVv2 router and the target AODVv2 router in both directions. Route maintenance consists of two operations. In order to preserve routes in use, AODVv2 routers extend route lifetimes upon successfully forwarding a packet. In order to react to changes in the network topology, AODVv2 routers monitor traffic being forwarded. When a data packet is received for forwarding and a route for the destination is not known or the route is broken, then the AODVv2 router of the source of the packet is notified. A Route Error (RERR) is transmitted to indicate the route to one or more affected destination addresses is Broken UH> s/Broken/broken/ or missing. When the source's AODVv2 router receives the RERR, it marks the route as broken. Before the AODVv2 router can forward a packet to the same destination, it has to perform route discovery again for that destination. Similarly to AODV, AODVv2 uses sequence numbers to ensure loop freedom [Perkins99]. UH> Citation to AODV missing. Is AODVv2 updating or obsoleting AODV? Sequence numbers enable AODVv2 routers to determine the temporal order of AODVv2 route discovery messages, thereby avoiding use of stale routing information. Also, AODVv2 uses RFC 5444 message and TLV formats. UH> As this is the successor to AODV, it would help to point out what has been improved/changed compared to AODV. Perkins & Chakeres Expires April 26, 2013 [Page 4] =0C Internet-Draft AODVv2 October 2012 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Additionally, this document uses some terminology from [RFC5444]. UH> Which one? This document defines the following terminology: Adjacency A relationship between selected bi-directional neighboring routers for the purpose of exchanging routing information. Not every pair of neighboring routers will necessarily form an adjacency. Neighboring routers may form an adjacency based on various information or other protocols; for example, exchange of AODVv2 routing messages, other protocols (e.g. NDP [RFC4861] or NHDP [RFC6130]), or manual configuration. Loss of a routing adjacency may also be based upon similar information; monitoring of adjacencies where packets are being forwarded is required (see Section 5.5.1). Distance (Dist) An unsigned integer which measures the distance a message or information element has traversed. The minimum value of distance is the number of IP hops traversed, 0 for local information. The maximum value is 254. The value 255 is reserved to indicate that the distance is unknown. UH> Is this a metrics? Why integer and not float? Is this additive? Why is it optional in the draft. Are there different metric types supported in the same network? AODVv2 Sequence Number (SeqNum) An AODVv2 Sequence Number is an unsigned integer maintained by each AODVv2 router. This sequence number guarantees the temporal order of routing information to maintain loop-free routes. The value zero (0) is reserved to indicate that the SeqNum for a destination address is unknown. UH> The last sentence is unclear. The first sentence said there is one seq. number per router. The last sentence talks about sequence numbers for destinations, which is a different thing. reactive A protocol operation is said to be "reactive" if it is performed only in reaction to specific events. As used in this document, "reactive" is essentially synonymous with "on-demand". Router Client An AODVv2 router may be configured with a list of other IP addresses and networks which correspond to other non-router nodes which require the services of the AODVv2 router for route discovery and maintenance. An AODVv2 is always its own client, so that the list of client IP addresses is never empty. corresponds UH> s/corresponds/Corresponds/ Perkins & Chakeres Expires April 26, 2013 [Page 5] =0C Internet-Draft AODVv2 October 2012 to the AODVv2 router process currently performing a calculation or processing a message. UH> I don't think it is a good idea to introduce that terminology. It seems to be conflicting with the IP architecture of hosts and routers. Is a Router Client a host? Flooding In this document, flooding a message refers to the process of delivering the message to every AODVv2 router in the network. This may be done according to methods specified in [RFC5148]. UH> RFC5148 describes jitter in MANETs, not flooding methods. Routable Unicast IP Address A routable unicast IP address is a unicast IP address that when put into the IP.SourceAddress or IP.DestinationAddress field is UH> Notation not defined: "IP.x" scoped sufficiently to be forwarded by a router. UH> I am not quite sure what that means. Can you cite an RFC, maybe RFC4007= ? Globally-scoped unicast IP addresses and Unique Local Addresses (ULAs) [RFC6130] are examples of routable unicast IP addresses. UH> RFC6130 is NHDP, not ULA. ULA's are not globally routable and cannot be accessed from outside a "site". Originating Node (OrigNode) The originating node is the data source node; if it is not itself an AODVv2 router, its AODVv2 router creates a AODVv2 RREQ message on its behalf in an effort to flood some routing information. The originating node is also referred to as a particular message's originator. Target Node (TargetNode) The TargetNode denotes the ultimate destination of a message. UH> Is this for control packets only or for data traffic? Is that an IP add= ress? This Node (ThisNode) ThisNode denotes the AODVv2 router currently processing an AODVv2 message. Route Error (RERR) A RERR message is used to indicate that an AODVv2 router no longer has a route to one or more particular destinations. UH> Or it may have one, and data traffic was lost when sending it to the next hop Route Reply (RREP) A RREP message is used to supply routing information about the RREQ TargetNode to the RREQ OrigNode and the AODVv2 routers between them. Route Request (RREQ) An AODVv2 router uses a RREQ message to discover a valid route to a particular destination address, called the RREQ TargetNode. When an AODVv2 router processes a RREQ, it learns routing information on how to reach the RREQ OrigNode. Type-Length-Value structure (TLV) A generic way to represent information as specified in [RFC5444]. Perkins & Chakeres Expires April 26, 2013 [Page 6] =0C Internet-Draft AODVv2 October 2012 Unreachable Node (UnreachableNode) An UnreachableNode is a node for which a forwarding route is unknown. UH> Or to which data traffic has been lost while forwarding to the next hop= . 3. Applicability Statement The AODVv2 routing protocol is designed for stub (i.e., non-transit) or disconnected (i.e., from the Internet) mobile ad hoc networks (MANETs). AODVv2 handles a wide variety of mobility patterns by dynamically determining routes on-demand. AODVv2 also handles a wide variety of traffic patterns. In networks with a large number of routers, AODVv2 is best suited for sparse traffic scenarios where any particular router forwards packets to only a small percentage of the AODVv2 routers in the network, due to the on-demand nature of route discovery and route maintenance. AODVv2 is applicable to memory constrained devices, since little routing state is maintained in each AODVv2 router. Only routing information related to routes between active sources and destinations is maintained, in contrast to proactive routing protocols that require routing information to all routers within the routing region be maintained. AODVv2 supports routers with multiple interfaces. In addition to routing for their local processes, AODVv2 routers can also route on behalf of other non-routing nodes (i.e., "hosts"), reachable via those interfaces. Any such node which is not itself an AODVv2 router SHOULD NOT be served by more than one AODVv2 router. UH> I would rather not use RFC2119 in an applicability statement. This is not normative. Although AODVv2 is closely related to AODV [RFC3561], and has some of the features of DSR [RFC4728], AODVv2 is not interoperable with either of those other two protocols. AODVv2 routers perform route discovery to find a route to a particular destination. Therefore, AODVv2 routers MUST must be configured to respond to RREQs for a certain set of addresses. When AODVv2 is the only protocol interacting with the forwarding table, AODVv2 MAY be configured to perform route discovery for all unknown unicast destinations. At all times within an AODVv2 routing region, only one AODVv2 router SHOULD be serve any routing client. The coordination among multiple AODVv2 routers to distribute routing information correctly for a shared address (i.e. an address that is advertised and can be reached via multiple AODVv2 routers) is not described in this document. The AODVv2 router operation of shifting responsibility for a routing client from one AODVv2 router to another is mentioned in Appendix B UH> I am not sure that it is a good idea to include multi-homing in a short paragraph in Appendix B. I think this whole section can be removed. Each AODVv2 router, if serving router clients other than itself, is Perkins & Chakeres Expires April 26, 2013 [Page 7] =0C Internet-Draft AODVv2 October 2012 configured with information about the IP addresses of its clients. There is no requirement that an AODVv2 router have information about the router clients of other AODVv2 routers. Address assignment procedures are entirely out of scope for AODVv2. AODVv2 only utilizes bidirectional links. In the case of possible unidirectional links, either blacklists (see Section 5.13.2) or other means (e.g. adjacency establishment with only neighboring routers that have bidirectional communication as indicated by NHDP [RFC6130]) UH> The blacklisting is not specified in this document. of ensuring and monitoring bi-directionality is recommended. Otherwise, persistent packet loss could occur. The routing algorithm in AODVv2 may be operated at layers other than the network layer, using layer-appropriate addresses. UH> Yes, but the whole document is limited to IP. It is tied to IP headers, UDP etc at multiple places. The routing algorithm makes UH> + "use" of some persistent state; if there is no persistent storage available for this state, recovery can exact a performance penalty in case of AODVv2 router reboots. 4. Data Structures UH> There is a mixture between information bases and message formats. I would rather have two seperate sections for that. UH> There are no other information sets that I believe are required for AODV: blacklisted set, set of local interfaces, and a set of the hosts that this router is responsible. 4.1. Route Table Entry The route table entry is a conceptual data structure. Implementations may use any internal representation so long as it provides access to the same information as specified below. Conceptually, a route table entry has the following fields: Route.Address The (host or network) destination address of the node(s) associated with the routing table entry. Route.Prefix The value is the length of the netmask/prefix. UH> in octets? If the value of the Route.Prefix is different than the length of addresses in the address family used by the AODVv2 routers, the associated address is a routing prefix, rather than a host address. Route.SeqNum The AODVv2 SeqNum associated with a route table entry. Route.NextHopAddress An IP address of the adjacent AODVv2 router on the path toward the Route.Address. Perkins & Chakeres Expires April 26, 2013 [Page 8] =0C Internet-Draft AODVv2 October 2012 Route.NextHopInterface The interface used to send packets toward the Route.Address. Route.Broken A flag indicating whether this Route is broken. This flag is set to true if the next-hop becomes unreachable or in response to processing to a RERR (see Section 5.5.4). The following field is optional: Route.Dist A dimensionless metric indicating the distance traversed before reaching the Route.Address node. UH> Why is this optional? It makes the whole specification more complicated, in particular interoperability. I cannot imagine cases where you are not interested in the distance. UH> Is this metric additive? is it only integer? is it used in addition to hop-count or instead? Not including optional information may cause performance degradation, but it will not prohibit the protocol from discovering valid routes. In addition to a route table data structure, each route table entry may have several timers associated with the information. Timers and timeouts are discussed in Section 5.2.3. UH> That forward link makes it difficult. Why not include the expiration timers here, similar to OLSRv2? 4.2. AODVv2 Message Structure and Information Elements IP Protocol Number 138 (manet) has been reserved for MANET protocols [RFC5498]. In addition to using this IP protocol number, AODVv2 may use UDP at destination port 269 (manet) [RFC5498]. UH> may or MAY? AODVv2 messages are transmitted in packets that conform to the generalized packet and message format as described in [RFC5444]. Here is a brief description of the format. A packet formatted according to RFC5444 contains zero or more messages. A message contains a message header, message TLV block, and zero or more address blocks. Each of the address blocks may also have an associated address TLV block. UH> Each address block *must* have a TLV block (it may be empty though). All AODVv2 messages SHOULD be sent using the IP protocol number (138) reserved for manet protocols [RFC5498]; or the UDP destination port (269) reserved for manet protocols [RFC5498] and IP protocol number for UDP. UH> That is redundant to the first paragraph of this section. Perkins & Chakeres Expires April 26, 2013 [Page 9] =0C Internet-Draft AODVv2 October 2012 Most AODVv2 messages are sent with the IP destination address set to the link-local multicast address LL-MANET-Routers [RFC5498] unless otherwise specified. Therefore, all AODVv2 routers SHOULD subscribe to LL-MANET-Routers [RFC5498] to receiving AODVv2 messages. Note that multicast packets MAY be sent via unicast. UH> That sounds confusing: multicast packets MAY be sent via unicast. First, what is a multicast packet? (you mean an IP packet with a multicast destination address>). Why MAY? For example, this may occur for certain link-types (non broadcast mediums), for manually configured router adjacencies, or in order to improve robustness. UH> How would one manually configure a router adjacency? When describing AODVv2 protocol messages, it is necessary to refer to fields in several distinct parts of the overall packet. UH> Since there is an RFC5444 demultiplexer, AODVv2 would never see the packet. So I think it's better not to use that term here. These locations include the IP header, the UDP header, and fields from [RFC5444]. This document uses the notational conventions found in table 1. +---------------------------+-------------------+ | Information Location | Notational Prefix | +---------------------------+-------------------+ | IP header | IP. | | RFC5444 message header | MsgHdr. | | RFC5444 message TLV | MsgTLV. | | RFC5444 address blocks | AddBlk. | | RFC5444 address block TLV | AddTLV. | +---------------------------+-------------------+ Table 1 The IPv4 TTL (IPv6 Hop Limit) field for all packets containing AODVv2 messages is set to 255. UH> I think that's the job of the RFC5444 multiplexer. If a packet is received with a value other than 255, any AODVv2 message contained in the packet MUST be ignored by AODVv2. UH> No, the packet would never be received by AODVv2. Only a message would. This mechanism, known as "The Generalized TTL Security Mechanism" (GTSM) [RFC5082] helps to ensure that packets have not traversed any intermediate routers. UH> Again, part of the RFC5444 multiplexer. The length of an address (32 bits for IPv4 and 128 bits for IPv6) inside an AODVv2 message depends on the msg-addr-length (MAL) in the msg-header, as specified in [RFC5444]. UH> Limitation of AODVv2 to IP addresses. It could also be used for compressed (lowpan) addresses or MAC addresses. IP packets containing AODVv2 protocol messages SHOULD be given priority queuing and channel access. UH> Not the task of AODVv2, but the RFC5444 multiplexer AODVv2 messages require the following information: IP.SourceAddress The IP address of the node currently sending this packet. This field is generally filled automatically by the operating system and should not require special handling. UH> An AODVv2 message cannot have an IP address. That's a different layer. The IP packet that contains an RFC5444 packet (which the IP layer received from the RFC5444 multiplexer) has that address. Also, it is not necessarily the node currently sending this "packet"; ThisNode could receive a message, then it is not sending this packet. Perkins & Chakeres Expires April 26, 2013 [Page 10] =0C Internet-Draft AODVv2 October 2012 IP.DestinationAddress The IP address of the packet destination. For multicast messages the IP.DestinationAddress is set to LL-MANET-Routers [RFC5498]. For unicast messages the IP.DestinationAddress is set to the NextHopAddress toward the TargetNode. MsgHdr.HopLimit The remaining number of hops this message is allowed to traverse. If an AODVv2 message within a RFC 5444 packet has exhausted its hop limit, then it should be removed from the packet. UH> This seems to be mixing normative protocol behavior with field definitions. 4.3. RteMsg-specific Protocol Elements AODVv2 message types RREQ and RREP are denoted as Routing Messages (RteMsgs) and used to flood routing information. UH> RREPs are not flooded. RREQ and RREP have similar information and function, but have slightly different handling rules. The main difference between the two messages is that RREQ messages are generally broadcast to solicit a RREP, and conversely a RREP is the unicast response to RREQ. RteMsg creation and handling are described in Section 5.3. Unicast AODVv2 RteMsgs (e.g. RREP) unless otherwise specified are sent with the IP destination set to the Route.NextHopAddress of the route to the TargetNode. A RteMsg REQUIRES the following information in addition to the fields indicated in Section 4.2: UH> REQUIRES is not RFC2110, it's REQUIRED AddBlk.TargetNode.Address The IP address of the message TargetNode. In a RREQ the IP address of the message TargetNode is the destination address for which route discovery is being performed. In a RREP the TargetNode is the RREQ OrigNode address. The TargetNode address is the first address in a routing message. UH> I don't think it's a good idea to mandate order of addresses. Other extensions to the protocol may add addresses before. It would be better to associate with an address block TLV. AddBlk.OrigNode.Address The IP address of the originator and its associated prefix length. In a RREQ the OrigNode is the source's address and prefix. In a RREP the OrigNode is the RREQ TargetNode's address and prefix for which a RREP is being generated. This address is the second address in the message for RREQ. UH> Again, mandating address order is dangerous. OrigNode.AddTLV.SeqNum The AODVv2 sequence number of the originator's AODVv2 router. UH> Why not use the message sequence number? This will save several bytes. Or at least a message TLV. A RteMsg may optionally include the following information: Perkins & Chakeres Expires April 26, 2013 [Page 11] =0C Internet-Draft AODVv2 October 2012 TargetNode.AddTLV.SeqNum The last known AODVv2 sequence number of the TargetNode. UH> Using which TLV type? (reference to IANA section) AddBlk.AdditionalNode.Address The IP address of an additional node that can be reached via the AODVv2 router adding this information. Each AdditionalNode.Address MUST include its prefix. Each AdditionalNode.Address MUST also have an associated Node.SeqNum in the address TLV block. UH> Is Node.foo defined before? AdditionalNode.AddTLV.SeqNum The AODVv2 sequence number associated with this routing information. UH> What is AdditionalNode? OrigNode.AddTLV.Dist A metric of the distance to reach the associated OrigNode.Address. This field is incremented by at least one at each intermediate AODVv2 router. UH> Why not use a message TLV? AdditionalNode.AddTLV.Dist A metric of the distance to reach the associated AdditionalNode.Address. This field is incremented by at least one at each intermediate AODVv2 router. 4.4. Route Error (RERR)-specific Protocol Elements A RERR message is used to flood the information that a route is not available for one or more particular addresses. UH> RERR are mostly sent unicast, not flooded. RERR creation and handling are described in Section 5.5. A RERR requires the following information in addition to the field indicated in Section 4.2: AddBlk.UnreachableNode.Address The address of an UnreachableNode and its associated prefix length. Multiple unreachable addresses may be included in a RERR. A Route Error may optionally include the following information: UnreachableNode.AddTLV.SeqNum The last known AODVv2 sequence number of the unreachable node. If a SeqNum for an address is zero (0) or not included, it is assumed to be unknown. This case occurs when a node receives a message to forward to a destination for which it does not have any information in its routing table. Perkins & Chakeres Expires April 26, 2013 [Page 12] =0C Internet-Draft AODVv2 October 2012 5. Detailed Operation for the Base Protocol 5.1. AODVv2 Sequence Numbers AODVv2 sequence numbers allow AODVv2 routers to judge the freshness of routing information and consequently ensure loop freedom. 5.1.1. Maintaining A Node's Own Sequence Number AODVv2 requires that each AODVv2 router in the network maintain its own AODVv2 sequence number (OwnSeqNum). OwnSeqNum a 16-bit unsigned integer. An AODVv2 router increments its OwnSeqNum under the circumstances described in Section 5.3. Incrementing an OwnSeqNum whose value is the largest largest possible number representable as a 16-bit unsigned integer (i.e., 65,535), MUST be set to one (1). In other words, the sequence number after 65,535 is 1. 5.1.2. Actions After OwnSeqNum Loss An AODVv2 router SHOULD maintain its own sequence number in persistent storage. If an AODVv2 router's OwnSeqNum is lost, it MUST take certain actions to avoid creating routing loops. To prevent this possibility after OwnSeqNum loss an AODVv2 router MUST wait for at least ROUTE_DELETE_TIMEOUT before fully participating in the AODVv2 routing protocol. If an AODVv2 protocol message is received during this waiting period, the AODVv2 router SHOULD perform normal route table entry updates but MUST NOT transmit or retransmit any AODVv2 RREQ or RREP messages. If a data packet is received for forwarding to another destination during this waiting period, the AODVv2 router MUST transmit a RERR message indicating that this route is not available and reset its waiting timeout. At the end of the waiting period the AODVv2 router sets its OwnSeqNum to one (1) and begin participating. The longest a node need wait is ROUTE_SEQNUM_AGE_MAX_TIMEOUT. At the end of the maximum waiting period a node SHOULD set its OwnSeqNum to one (1) and begins participating. 5.2. AODVv2 Routing Table Operations UH> This whole structure is unclear. Where do we come to this? Wouldn't it be better to start of with message generation/processing before saying how to update the routing tuples as a consequence to received messages? 5.2.1. Judging Routing Information's Usefulness Given a route table entry (Route.SeqNum, Route.Dist, and Route.Broken) UH> A route table entry has more fields in section 4.1 and incoming routing information for a particular Perkins & Chakeres Expires April 26, 2013 [Page 13] =0C Internet-Draft AODVv2 October 2012 destination in a RteMsg (Node.SeqNum, Node.Dist, and RteMsg message type - RREQ/RREP), the incoming routing information is classified as follows: 1. Stale (Node.SeqNum < Route.SeqNum) If Node.SeqNum < Route.SeqNum (using signed 16-bit arithmetic) the incoming information is stale. Using stale routing information is not allowed, since that might result in routing loops. UH> So what should my implementation then? Continue with the next step? Discard the message? 2. Not safe against loops If Node.SeqNum =3D=3D Route.SeqNum, additional information MUST be examined. If Route.Dist or Node.Dist is unknown or zero (0), or if Node.Dist > Route.Dist + 1, then the incoming information is not guaranteed to prevent routing loops. Using such incoming routing information is not allowed. The following pseudocode is offered to indicate the logical condition under which the incoming information is not guaranteed to protect against loops. (Node.SeqNum =3D=3D Route.SeqNum) AND ((Node.Dist > Route.Dist + 1) OR UH> Would cause a null-pointer exception in my implementation if Dist is not contained in the message. (Route.Dist is unknown) OR (Node.Dist is unknown)) 3. Offers no improvement In case of known equal SeqNum, the information is considered worse than the existing route table information in multiple cases: (case i) if Node.Dist > Route.Dist (it is a more expensive route) AND Route.Broken =3D=3D false; (case ii) if Node.Dist =3D=3D Route.Dist (= equal distance route) AND Route.Broken =3D=3D false AND this RteMsg is a RREQ. Such RREQs offer no improvement and SHOULD NOT be retransmitted. Updating route table entries using such incoming routing information is not allowed. ((Node.SeqNum =3D=3D Route.SeqNum) AND (((Node.Dist > Route.Dist) AND (Route.Broken =3D=3D false)) OR ((Node.Dist =3D=3D Route.Dist) AND (RteMsg is RREQ) AND (Route.Broken =3D=3D false)))) 4. Offers improvement Incoming routing information that does not match any of the above criteria is loop-free and better than the existing routing table information. We provide the following pseudo-code to determine whether incoming routing information should be used to update an existing route table entry. (/* signed 16-bit arithmetic */ Node.SeqNum - Route.SeqNum > 0) OR ((Node.SeqNum =3D=3D Route.SeqNum) AND [(Node.Dist < Route.Dist) OR ((Route.Broken =3D=3D true) AND (Node.Dist <=3D Route.Dist + 1)) = OR Perkins & Chakeres Expires April 26, 2013 [Page 14] =0C Internet-Draft AODVv2 October 2012 ((RteMsg is RREP) AND (Node.Dist =3D=3D Route.Dist)] 5.2.2. Creating or Updating Route Table Entries Each route table entry is populated with the following information: UH> Why "each" entry? When does this happen? It seems this only sets the route to the previous hop; what happens with a route to the originator? What happens if a route already exists and is only updated? How are both forward and reverse routes updated? 1. the Route.Address is set to Node.Address, 2. the Route.Prefix is set to the Node.Prefix. 3. the Route.SeqNum is set to the Node.SeqNum, 4. the Route.NextHopAddress is set to the IP.SourceAddress (i.e., an address of the node that last transmitted the RteMsg packet) 5. the Route.NextHopInterface is set to the interface on which the incoming AODVv2 packet was received, 6. the Route.Broken flag is set to false, 7. if known, the Route.Dist is set to the Node.Dist, The timer for the minimum delete timeout (ROUTE_AGE_MIN) is set to ROUTE_AGE_MIN_TIMEOUT. The timer for the maximum delete timeout (ROUTE_SEQNUM_AGE_MAX) is set to Node.AddTLV.VALIDITY_TIME [RFC5497] if included; otherwise, ROUTE_SEQNUM_AGE_MAX is set to ROUTE_SEQNUM_AGE_MAX_TIMEOUT. The usage of these timers and others are described in Section 5.2.3. UH> I don't understand how a sequence number can expire. Also, in section 4.1 there was no mention of the VALIDITY_TIME Tlv in a message. What happens if it is not contained? With these assignments to the route table entry, a route has been created and the Route.Forwarding flag set. Afterward, the route can be used to send any buffered data packets and to forward any incoming data packets for Route.Address. This route also fulfills any outstanding route discovery (RREQ) attempts for Node.Address. 5.2.3. Route Table Entry Timeouts 5.2.3.1. Minimum Delete Timeout (ROUTE_AGE_MIN) When an AODVv2 router transmits a RteMsg, other AODVv2 routers expect the transmitting AODVv2 router to have a forwarding route to the RteMsg originator. A route table entry SHOULD be kept in the route table for at least ROUTE_AGE_MIN after it has been updated. Failure to maintain the route table entry might result in lost messages/ packets, or several duplicate messages. After the ROUTE_AGE_MIN timeout a route can safely be deleted. Perkins & Chakeres Expires April 26, 2013 [Page 15] =0C Internet-Draft AODVv2 October 2012 5.2.3.2. Maximum Sequence Number Delete Timeout (ROUTE_SEQNUM_AGE_MAX) Sequence number information for route table entries is time sensitive, and MUST be deleted after a time in order to ensure loop- free routing. After the ROUTE_SEQNUM_AGE_MAX timeout a route's sequence number information MUST be discarded. UH> What does it mean to discard a sequence number information? To set it to zero in the route entry? What are the relationships between ROUTE_SEQNUM_AGE_MUX and ROUTE_AGE_MIN? (can one be smaller than the other) 5.2.3.3. Recently Used Timeout (ROUTE_USED) When a route is used to forward data packets, this timer is set to expire after ROUTE_USED_TIMEOUT, as discussed in Section 5.5.2. If a route has not been used recently, then a timer for ROUTE_DELETE is set to ROUTE_DELETE_TIMEOUT. 5.2.3.4. Delete Information Timeout (ROUTE_DELETE) As time progresses the likelihood that old routing information is useful decreases, especially if the network nodes are mobile. Therefore, old information SHOULD be deleted. After the ROUTE_DELETE timeout if a forwarding route exists it SHOULD be removed, and the routing table entry SHOULD also be deleted. UH> There are quite a few timers, which is confusing. What happens if one timer fires before the other? Do we really need that many timers? 5.3. Routing Messages 5.3.1. RREQ Creation Before an AODVv2 router creates a RREQ it SHOULD increment its OwnSeqNum by one (1) according to the rules specified in Section 5.1. UH> Why not MUST? What happens if one does not increase it. In general, there are many SHOULDs in the document, which probably should be MUSTs. Incrementing OwnSeqNum will ensure that all nodes with existing routing information will consider this new information preferable to existing routing table information. If the sequence number is not incremented, certain AODVv2 routers might not consider this information preferable, if they have existing better routing information. First, ThisNode adds the AddBlk.TargetNode.Address to the RREQ; the unicast IP Destination Address for which a forwarding route does not exist. If a previous value of the TargetNode.SeqNum is known (from a routing table entry using longest-prefix matching), it SHOULD be placed in TargetNode.AddTLV.SeqNum in all but the last RREQ attempt. If a TargetNode.SeqNum is not included, it is assumed to be unknown by handling nodes. This operation ensures that no intermediate AODVv2 Perkins & Chakeres Expires April 26, 2013 [Page 16] =0C Internet-Draft AODVv2 October 2012 routers reply, and ensures that the TargetNode's AODVv2 router increments its sequence number. Next, ThisNode adds AddBlk.OrigNode.Address, its prefix, and the OrigNode.AddTLV.SeqNum (OwnSeqNum) to the RteMsg. The OrigNode.Address is the address of the source for which this AODVv2 router is initiating this route discovery. The OrigNode.Address MUST be a unicast address. This information will be used by nodes to create a route toward the OrigNode, enabling delivery of a RREP, and eventually used for proper forwarding of data packets. If OrigNode.Dist is included it is set to a number, greater than zero (0), representing the distance between OrigNode and ThisNode. The MsgHdr.HopLimit SHOULD be set to MSG_HOPLIMIT. UH> Why SHOULD? 5.3.2. RREP Creation First, the AddBlk.TargetNode.Address is added to the RREP. The TargetNode is the ultimate destination of this RREP; the RREQ OrigNode.Address. Next, AddBlk.OrigNode.Address and prefix are added to the RREP. The AddBlk.OrigNode.Address is the RREQ TargetNode.Address. The AddBlk.OrigNode.Address MUST be a unicast IP address. ThisNode SHOULD advertise the largest known prefix containing AddBlk.OrigNode.Address. When the RteMsg TargetNode's AODVv2 router creates a RREP, if the TargetNode.SeqNum was not included in the RREQ, ThisNode MUST increment its OwnSeqNum by one (1) according to the rules specified in Section 5.1. If TargetNode.SeqNum was included in the RteMsg and TargetNode.SeqNum - OwnSeqNum < 0 (using signed 16-bit arithmetic), OwnSeqNum SHOULD be incremented by one (1) according to the rules specified in Section 5.1. If TargetNode.SeqNum is included in the RteMsg and TargetNode.SeqNum =3D=3D OwnSeqNum (using signed 16-bit arithmetic) and OrigNode.Dist will not be included in the RREP being generated, OwnSeqNum SHOULD be incremented by one (1) according to the rules specified in Section 5.1. If OwnSeqNum is not incremented the routing information might be considered stale. In this case, the RREP might not reach the RREP Perkins & Chakeres Expires April 26, 2013 [Page 17] =0C Internet-Draft AODVv2 October 2012 Target. After any of the sequence number operations above, the RREP OrigNode.AddTLV.SeqNum (OwnSeqNum) MUST also be added to the RREP. Other AddTLVs in the RREP for the OrigNode and TargetNode SHOULD be included and set accordingly. If OrigNode.Dist is included it is set to a number greater than zero (0) and less than or equal to 254. The Distance value will influence judgment of the routing information (Section 5.2.1) against known information at other AODVv2 routers that handle this RteMsg. The MsgHdr.HopLimit is set to MSG_HOPLIMIT. The IP.DestinationAddress for RREP is set to the IP address of the Route.NextHopAddress for the route to the RREP TargetNode. 5.3.3. RteMsg Handling UH> Very difficult to parse this section. Not much RFC2119 language. UH> Is there any check for invalid messages (similar to OLSRv2/NHDP?) External mechanisms should be allowed to add reasons to reject a message as invalid, e.g. a security mechanism. First, ThisNode examines the RteMsg to ensure that it contains the required information: MsgHdr.HopLimit, AddBlk.TargetNode.Address, AddBlk.OrigNode.Address, and OrigNode.AddTLV.SeqNum. If the required information does not exist, the message is discarded and further processing stopped. ThisNode MUST only handle AODVv2 messages from adjacent routers. UH> What does that mean? ThisNode checks if the AddBlk.OrigNode.Address is a valid routable unicast address. UH> How? If not, the message is ignored and further processing stopped. ThisNode also checks whether AddBlk.OrigNode.Address is an address handled by this AODVv2 router. UH> How? If this node is the originating AODVv2 router, the RteMsg is dropped. UH> Why not do this further above, before doing all the other checks? ThisNode checks if the AddBlk.TargetNode.Address is a valid routable unicast address. If the address is not a valid unicast address, the message is discarded and further processing stopped. Next, ThisNode checks whether its routing table has an entry to the AddBlk.OrigNode.Address using longest-prefix matching [RFC1812]. UH> RFC1812 is IPv4 only. If a route with a valid Route.SeqNum does not exist, UH> What is a "valid" sequence number? then the new routing information is used to create a new route table entry is created UH> to "create" ... is "created" and updated as described in Section 5.2.2. UH> This jumping back is difficult to parse. If a route table entry does exists and it has a known Route.SeqNum, the incoming routing information is compared with the route table entry following the procedure described in Section 5.2.1. If the incoming routing information is considered preferable, the route table entry is Perkins & Chakeres Expires April 26, 2013 [Page 18] =0C Internet-Draft AODVv2 October 2012 updated as described in Section 5.2.2. At this point, if the routing information for the OrigNode was not preferable then this RteMsg SHOULD be discarded and no further processing of this message SHOULD be performed. UH> Why SHOULD? Why not MUST? If the TargetNode is a router client of ThisNode this RteMsg is a RREQ, then ThisNode responds with a RREP to the RREQ OrigNode (the new RREP's TargetNode). The procedure for issuing a new RREP is described in Section 5.3.2. Afterwards, ThisNode need not perform any more operations for the RteMsg being processed. As an alternative to issuing a RREP, ThisNode MAY choose to distribute routing information about ThisNode (the RREQ TargetNode) more widely. That is, ThisNode MAY optionally perform a route discovery by issuing a RREQ with ThisNode listed as the TargetNode, using the procedure in Section 5.3.1. At this point, ThisNode need not perform any more operations for the RteMsg being processed. UH> I don't understand the last paragraph. Is this some remainder of intermediate route reply? In which conditions should a router send a RREQ instead of a RREP? For each address (except the TargetNode) in the RteMsg that includes AddTLV.Dist information, the AddTLV.Dist information is incremented by at least one (1). UH> By how much then? The updated Distance value will influence judgment of the routing information (Section 5.2.1) against known information at other AODVv2 routers that handle this RteMsg. If the resulting Distance value for the OrigNode is greater than 254, the message is discarded. If the resulting Distance value for another node is greater than 254, UH> Which other node? the associated address and its information are removed from the RteMsg. UH> That makes end-to-end security impossible. If the MsgHdr.HopLimit is equal to one (1), then the message is discarded. Otherwise, the MsgHdr.HopLimit is decremented by one (1). If ThisNode is not the TargetNode, AND this RteMsg is a RREQ, then the current RteMsg (as altered by the procedure defined above) SHOULD be sent to the IP multicast address LL-MANET-Routers [RFC5498]. If the RREQ is unicast, the IP.DestinationAddress is set to the NextHopAddress. UH> The unicast RREQ mechanism is not really explained anywhere. Where is the nexthopaddress acquired from? If ThisNode is not the TargetNode, AND this RteMsg is a RREP, then the current RteMsg is sent to the Route.NextHopAddress for the RREP's TargetNode.Address. If no forwarding route exists to TargetNode.Address, then a RERR SHOULD be issued to the OrigNode of the RREP. By sending the updated RteMsg, ThisNode advertises that it will route for addresses contained in the outgoing RteMsg based on the information enclosed. ThisNode MAY choose not to send the RteMsg, though not resending this RteMsg could decrease connectivity in the Perkins & Chakeres Expires April 26, 2013 [Page 19] =0C Internet-Draft AODVv2 October 2012 network or result in a non-shortest distance path. The circumstances under which ThisNode might choose to not re-issue a RteMsg are not specified in this document. Some examples might include the following: o if ThisNode does not want to advertise routing for the contained addresses because it is already heavily loaded o if ThisNode has already issued identical routing information (e.g. ThisNode had recently issued a RteMsg with the same distance) o if ThisNode is low on energy and does not want to expend energy for protocol message sending or packet forwarding 5.4. Route Discovery When an AODVv2 router needs to forward a data packet and it does not have a forwarding route to the destination address, it sends a RREQ (described in Section 5.3.1) to discover a route to the particular destination (TargetNode). After issuing a RREQ, the AODVv2 router (OrigNode) waits for a RREP indicating the next hop for a route to the TargetNode. If a route is not created within RREQ_WAIT_TIME, OrigNode may again try to discover a route by issuing another RREQ using the procedure defined in Section 5.3.1 again. Route discovery SHOULD be considered to have failed after DISCOVERY_ATTEMPTS_MAX and the corresponding wait time for a response to the final RREQ. To reduce congestion in a network, repeated attempts at route discovery for a particular TargetNode SHOULD utilize an binary exponential backoff. Data packets awaiting a route SHOULD be buffered by the source's AODVv2 router. This buffer SHOULD have a fixed limited size (BUFFER_SIZE_PACKETS or BUFFER_SIZE_BYTES). Determining which packets to discard first is a matter of policy at each AODVv2 router; in the absence of policy constraints, by default older data packets SHOULD be discarded first. Buffering of data packets can have both positive and negative effects, and therefore settings for buffering (BUFFER_DURING_DISCOVERY) SHOULD be administratively configurable. Nodes without sufficient memory available for buffering may be configured with BUFFER_DURING_DISCOVERY =3D FALSE; this will affect the latency required for launching TCP applications to new destinations. UH> I am against including this buffering mechanism in this document. This is a mixture of the routing plane and the data plane. There are other forwarding mechanisms that would be affected by this specification. If a route discovery attempt has failed (i.e. an attempt or multiple attempts have been made without receiving a RREP) to find a route to Perkins & Chakeres Expires April 26, 2013 [Page 20] =0C Internet-Draft AODVv2 October 2012 the TargetNode, any data packets buffered for the corresponding TargetNode MUST BE dropped and a Destination Unreachable ICMP message (Type 3) SHOULD be delivered to the source of the data packet. The code for the ICMP message is 1 (Host unreachable error). If the AODVv2 router is not the source (OrigNode), then the ICMP is sent over the interface from which the source sent the packet to the AODVv2 router. 5.5. Route Maintenance A RERR SHOULD be issued if a data packet is to be forwarded and it cannot be delivered to the next-hop because no forwarding route for the IP.DestinationAddress exists; RERR generation is described in Section 5.5.3. Upon this condition, an ICMP Destination Unreachable message SHOULD NOT be generated unless this router is responsible for the IP.DestinationAddress and that IP.DestinationAddress is known to be unreachable. UH> How is that generated (with which content)? In addition to inability to forward a data packet, a RERR SHOULD be issued immediately after detecting a broken link (see Section 5.5.1) of a forwarding route to quickly notify AODVv2 routers that certain routes are no longer available. If a newly unavailable route has not been used recently (indicated by ROUTE_USED), the RERR SHOULD NOT be generated. UH> SHOULD NOT or MUST NOT? What are the consequences of doing so when using SHOULD NOT? 5.5.1. Active Next-hop Router Adjacency Monitoring Nodes SHOULD monitor connectivity to adjacent next-hop AODVv2 routers on forwarding routes. This monitoring can be accomplished by one or several mechanisms, including: o Neighborhood discovery [RFC6130] o Route timeout o Lower layer trigger that a neighboring router is no longer reachable o Other monitoring mechanisms or heuristics Upon determining that a next-hop AODVv2 router has become unreachable, ThisNode MUST remove the affected forwarding routes (those using the unreachable next-hop) and unset the Route.Forwarding flag. ThisNode also flags the associated routes in AODVv2's routing table as Broken. For each broken route the timer for ROUTE_DELETE is set to ROUTE_DELETE_TIMEOUT. UH> How can the flags be set if the routes are removed before? Perkins & Chakeres Expires April 26, 2013 [Page 21] =0C Internet-Draft AODVv2 October 2012 5.5.2. Updating Route Lifetimes During Packet Forwarding To avoid removing the forwarding route to reach an IP.SourceAddress, ThisNode SHOULD set the "ROUTE_USED" timeout to the value ROUTE_USED_TIMEOUT for the route to that IP.SourceAddress upon receiving a data packet or an AODVv2 message. If the timer for ROUTE_DELETE is set, that timer is removed. The Route.Broken flag is unset. To avoid removing the forwarding route to the IP.DestinationAddress that is being used, ThisNode SHOULD set the "ROUTE_USED" timeout to the value ROUTE_USED_TIMEOUT for the route to the IP.DestinationAddress upon sending a data packet or an AODVv2 message. If the timer for ROUTE_DELETE is set, it is removed. The Route.Broken flag is unset. 5.5.3. RERR Generation When an AODVv2 router receives a packet (from PrevHopAddress), and the router (ThisNode) does not have a route available for the destination of the packet, ThisNode uses an RERR message is used to UH> "uses".. ."is used" inform one or more neighboring AODVv2 routers that its route to the packet destination is no longer available. When ThisNode creates a new RERR, the address of the first UnreachableNode (IP.DestinationAddress from a data packet or RREP.TargetNode.Address) is inserted into an Address Block AddBlk.UnreachableNode.Address. If a prefix is known for the UnreachableNode.Address, it SHOULD be included. Otherwise, the UnreachableNode.Address is assumed to be a host address with a full length prefix. If a value for the UnreachableNode's SeqNum (UnreachableNode.AddTLV.SeqNum) is known, it SHOULD be placed in the RERR. The MsgHdr.HopLimit SHOULD be set to MSG_HOPLIMIT. If SeqNum information is not known or not included in the RERR, all nodes handling the RERR will assume their routing information associated with the UnreachableNode is no longer valid and flag those routes as broken. A RERR MAY be sent to the multicast address LL-MANET-Routers [RFC5498], thus notifying all nearby AODVv2 routers that might depend on the now broken link. If the RERR is unicast, the IP.DestinationAddress is set to the PrevHopAddress. After sending the RERR, ThisNode SHOULD discard the packet or message UH> Why packet or message? Is this data traffic or control traffic? that triggered generation of the RERR. Perkins & Chakeres Expires April 26, 2013 [Page 22] =0C Internet-Draft AODVv2 October 2012 5.5.4. RERR Handling First, ThisNode examines the incoming RERR to ensure that it contains MsgHdr.HopLimit and AddBlk.UnreachableNode.Address. If the required information does not exist, the incoming RERR message is discarded and further processing stopped. When an AODVv2 router handles a RERR, it examines the information for each UnreachableNode. UH> How exactly does it do that? Which information is used, and how? The AODVv2 router removes the forwarding route, unsets the Route.Forwarding flag, sets the Route.Broken flag, and the timer for ROUTE_DELETE is set to ROUTE_DELETE_TIMEOUT for each UnreachableNode.Address found using longest prefix matching that meets all of the following conditions: 1. The UnreachableNode.Address is a routable unicast address. 2. The Route.NextHopAddress is the same as the RERR IP.SourceAddress. 3. The Route.NextHopInterface is the same as the interface on which the RERR was received. 4. The Route.SeqNum is zero (0), unknown, OR the UnreachableNode.SeqNum is zero (0), unknown, OR Route.SeqNum - UnreachableNode.SeqNum <=3D 0 (using signed 16-bit arithmetic). If Route.SeqNum is zero (0) or unknown and UnreachableNode.SeqNum exists in the RERR and is not zero (0), then Route.SeqNum SHOULD be set to UnreachableNode.SeqNum. Setting Route.SeqNum can reduce future RERR handling and forwarding. UH> How? Each UnreachableNode that did not result in marking a route table entry as broken route is removed from the RERR, since propagation of such information will not result in any benefit. UH> Makes end-to-end security impossible. Each UnreachableNode that did indicate a broken route SHOULD remain in the RERR. If any UnreachableNode was removed, all other information (AddTLVs) associated with the UnreachableNode address(es) MUST also be removed. If Route.SeqNum is known and an UnreachableNode.SeqNum is not included in the RERR, then Route.SeqNum (i.e. UnreachableNode.SeqNum) MAY be included with the RERR. Including UnreachableNode.SeqNum can reduce future RERR handling and forwarding. If no UnreachableNode addresses remain in the RERR, or if the Perkins & Chakeres Expires April 26, 2013 [Page 23] =0C Internet-Draft AODVv2 October 2012 MsgHdr.HopLimit is equal to one (1), then the RERR MUST be discarded. Otherwise, the MsgHdr.HopLimit is decremented by one (1). The RERR SHOULD be sent to the multicast address LL-MANET-Routers [RFC5498]. Alternatively, if the RERR is unicast, the IP.DestinationAddress is set to the PrevHopAddress. 5.6. Unknown Message and TLV Types If a message with an unknown type is received, the message is ignored. For handling of messages that contain unknown TLV types, ignore the information for processing, preserve it unmodified for forwarding. 5.7. Advertising Network Addresses AODVv2 routers MAY specify a prefix length for each advertised address. Any nodes (other than the advertising AODVv2 router) within the advertised prefix MUST NOT participate in the AODVv2 protocol directly. For example, advertising 192.0.2.1 with a prefix length of 24 indicates that all nodes with the matching 192.0.2.X are reachable through this AODVv2 router. An AODVv2 router MUST NOT advertise network addresses unless it can guarantee its ability for forwarding packets to any host address within the address range of the corresponding network. 5.8. Simple Internet Attachment Simple Internet attachment consists of a stub (i.e., non-transit) network of AODVv2 routers connected to the Internet via a single Internet AODVv2 router (IAR). UH> Why a new defition? Is that not just a border router? Also, it does not matter if it's connected to the "Internet", just if it's a border gateway with two interfaces, connecting two different routing domains (which could still not be connected to the Internet). As in any Internet-attached network, UH> What's an Internet-attached network? Is that defined in an IP architecture RFC? AODVv2 routers, and hosts behind these routers, wishing to be reachable from hosts on the Internet MUST have IP addresses within the IAR's routable and topologically correct prefix (e.g. 192.0.2.0/24). The IAR is responsible for generating RREQ to find nodes within the AODVv2 Region on behalf of nodes on the Internet, as well as responding to route requests from the AODVv2 region on behalf of the nodes on the Internet. Perkins & Chakeres Expires April 26, 2013 [Page 24] =0C Internet-Draft AODVv2 October 2012 /--------------------------\ / Internet \ \ / \------------+-------------/ | Routable & | Topologically | Correct | Prefix | +-----+--------+ | Internet | /------| AODVv2 |-------\ / | Router | \ / |192.0.2.1/32 | \ | |Responsible | | | | for | | | |AODVv2 Region | | | |192.0.2.0/24 | | | +--------------+ | | +----------------+ | | | AODVv2 Router | | | | 192.0.2.2/32 | | | +----------------+ | | +----------------+ | | | AODVv2 Router | | | | 192.0.2.3/32 | | \ +----------------+ / \ / \-----------------------------/ Figure 1: Simple Internet Attachment Example When an AODVv2 router within the AODVv2 Region wants to discover a route to a node on the Internet, it uses the normal AODVv2 route discovery for that IP Destination Address. The IAR MUST respond to RREQ on behalf of the Internet destination. UH> How? Where is that specified? When a packet from a node on the Internet destined for a node in the AODVv2 region reaches the IAR, if the IAR does not have a route to that destination it will perform normal AODVv2 route discovery for that destination. UH> How? With which originator address, target etc? Where are RERRs / ICMP unreachable sent to in case of a broken data traffic? 5.9. Multiple Interfaces AODVv2 may be used with multiple interfaces; therefore, the particular interface over which packets arrive MUST be known whenever a packet is received. Whenever a new route is created, the interface through which the Route.Address can be reached is also recorded in Perkins & Chakeres Expires April 26, 2013 [Page 25] =0C Internet-Draft AODVv2 October 2012 the route table entry. When multiple interfaces are available, a node transmitting a multicast packet with IP.DestinationAddress set to LL-MANET-Routers SHOULD send the packet on all interfaces that have been configured for AODVv2 operation. Similarly, AODVv2 routers SHOULD subscribe to LL-MANET-Routers on all their AODVv2 interfaces. 5.10. AODVv2 Control Packet/Message Generation Limits UH> There is no AODVv2 Control Packet. To ensure predictable messaging overhead, AODVv2 router's rate of packet/message generation SHOULD be limited. The rate and algorithm for limiting messages (CONTROL_TRAFFIC_LIMITS) is left to the implementor and should be administratively configurable. AODVv2 messages SHOULD be discarded in the following order of preference: RREQ, RREP, and finally RERR. 5.11. Optional Features Several optional features of AODVv2, and associated with AODV, are not required by minimal implementations. These features are expected to be useful in networks with greater mobility, or larger node populations, or requiring shorter latency for application launches. The optional features are as follows: o Expanding Rings Multicast o Intermediate RREPs (iRREPs): Without iRREP, only the destination can respond to a RREQ. o Precursor lists. o Reporting Multiple Unreachable Nodes. An RERR message can carry more than one Unreachable Destination node for cases when a single link breakage causes multiple destinations to become unreachable from an intermediate router. UH> This seems to be different from section 5.11.6, which talks about adding additional information to a RREQ. UH> None of the extensions is sufficiently specified, and it is unclear how it would affect interoperability if some nodes support the extension and others don't. 5.11.1. Expanding Rings Multicast For multicast RREQ, the MsgHdr.HopLimit MAY be set in accordance with an expanding ring search as described in [RFC3561] to limit the RREQ propagation to a subset of the local network and possibly reduce route discovery overhead. Perkins & Chakeres Expires April 26, 2013 [Page 26] =0C Internet-Draft AODVv2 October 2012 5.11.2. Intermediate RREP This specification has been published as a separate Internet Draft . 5.11.3. Precursor Notification The Dynamic MANET On-demand (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering on-demand convergence in dynamic topologies. This document specifies a simple modification to AODVv2 (and possibly other reactive routing protocols) enabling faster notifications to known sources of traffic upon determination that a route for such traffic's destination has become Broken. 5.11.3.1. Overview If an AODVv2 router, while attempting to forward a packet to a particular destination, determines that the next hop (one of its neighbors) is no longer reachable, AODVv2 specifies that the router notify the source of that packet that the route to the destination has become Broken. In the existing specification, the notification to the source is a unicast RERR message. However, in many cases there will be several sources of of traffic for that particular destination. In fact, the broken link for the next hop in question may be a path component of numerous other routes for other destinations, and in that case the node detecting the broken link must mark as Broken multiple routes, one for each of the newly unreachable destinations. Each route that uses the newly broken link is no longer valid. For each such route, every node along the way from the source using that route, to the node detecting the broken link, is known as a "precursor" for the broken next hop. All the precursors for a particular next hop should be notified about the change in status of their route to a destination downstream from the broken next hop. 5.11.3.2. Precursor Notification During normal operation, each node wishing to enable the improved notification for precursors of any links to its next hop neighbors has to keep track of the precursors. This is done by maintaining a precursor table and updating the table whenever the node initiates or relays a RREP message back to a node originating a RREQ message. When the node transmits the RREP message, it is implicitly agreeing to forward traffic from the RREQ originator towards the RREP originator (i.e., along the next hop link to the neighbor from which the RREP was received). The "other" next hop, which is the neighbor Perkins & Chakeres Expires April 26, 2013 [Page 27] =0C Internet-Draft AODVv2 October 2012 along the way towards the originator of the RREQ message, is then the next precursor for the route towards the destination requested by the RREQ. Each such precursor should then be recorded as a precursor for a route along the next hop. The same next hop may be in service for routes to multiple destinations, but for precursor list management it is only important to keep track of precursors for a particular next hop; the exact destination does not matter, only the particular next hop towards the destination(s). When a node observes that one of its neighbors is no longer reachable, the node first checks to see whether the link to that neighbor is a next hop for any more distant destination in its route table. If not, then the node simply updates any relevant neighorhood information and takes no further action. Otherwise, for all destinations no longer reachable because of the changed status of the next hop, the node first checks to see whether the link to that neighbor is a next hop for any more distant destination in its route table. If not, then the node simply updates any relevant neighorhood information and takes no further action. For each precursor of the next hop, the node MAY notify the precursor in one of three ways: o unicast RERR o broadcast RERR o multicast RERR to multicast group PRECURSOR_RERR_RECEIVERS UH> I don't see an allocation request in the IANA section. Each precursor then MAY execute the same procedure until all affected traffic sources have received the RERR route maintenance information. When a precursor receives a unicast RERR, the precursor MUST further unicast the RERR message towards the affected traffic source. If a precursor receives a broadcast or multicast RERR, the precursor MAY further retransmit the RERR towards the traffic source. 5.11.4. Reporting Multiple Unreachable Nodes 5.11.5. Message Aggregation The aggregation of multiple messages into a packet is not specified in this document, but if aggregation does occur the IP.SourceAddress and IP.DestinationAddress of all contained messages MUST be the same. UH> That is part of the RFC5444 multiplexer and not of AODVv2. Perkins & Chakeres Expires April 26, 2013 [Page 28] =0C Internet-Draft AODVv2 October 2012 Implementations MAY choose to temporarily delay transmission of messages for the purpose of aggregation (into a single packet) or to improve performance by using jitter [RFC5148]. 5.11.6. Adding Additional Routing Information to a RteMsg UH> This section is unclear to me. What is the purpose? What kind of information would you add? How can this interoperate? By adding information en-route, end-to-end security is not possible. DSR [RFC4728] includes source routes as part of the data of its RREPs and RREQs. Doign so allows additional topology information to be flooded along with the RteMsg, and potentially allows updating for stale routing information at MANET routers along new paths between source and destination. To maintain this functionality, AODVv2 has defined a somewhat more general method that enables inclusion of source routes in RteMsgs. Appending routing information can alleviate route discovery attempts to the nodes whose information is included, if other AODVv2 routers use this information to update their routing tables. Note that, since the initial merger of DSR with AODV to create this protocol, further experimentation has shown that including the additional routing information is not always helpful. Sometimes it seems to help, and other times it seems to reduct overall performance. AODVv2 routers can append routing information to a RteMsg. This is controllable by an option (APPEND_INFORMATION) which SHOULD be administratively configurable or controlled according to the traffic characteristics of the network. Prior to appending an address controlled by this AODVv2 router to a RteMsg, ThisNode MAY increment its OwnSeqNum as defined in Section 5.1. If OwnSeqNum is not incremented the appended routing information might not be considered preferable, when received by nodes with existing routing information. Incrementation of the sequence number when appending information to a RteMsg in transit (APPEND_INFORMATION_SEQNUM) SHOULD be administratively configurable. Note that, during handling of this RteMsg OwnSeqNum may have already been incremented; and in this case OwnSeqNum need not be incremented again. If an address controlled by this AODVv2 router includes ThisNode.Dist, it is set to a number greater than zero (0). For added addresses (and their prefixes) not controlled by this AODVv2 router, Route.Dist can be included if known. The VALIDITY_TIME of routing information for appended address(es) MUST be included, to inform routers about when to delete this Perkins & Chakeres Expires April 26, 2013 [Page 29] =0C Internet-Draft AODVv2 October 2012 information. The VALIDITY_TIME TLV is defined in Section 5.13.3. Additional information (e.g. SeqNum and Dist) about any appended address(es) SHOULD be included. Note that the routing information about the TargetNode MUST NOT be added. Also, duplicate address entries SHOULD NOT be added. Instead, only the best routing information (Section 5.2.1) for a particular address SHOULD be included. Intermediate nodes obey the following procedures when processing AddBlk.AdditionalNode.Address information and other associated TLVs that are included with a RteMsg. For each address (except the TargetNode) in the RteMsg that includes AddTLV.Dist information, the AddTLV.Dist information MUST be incremented. If the resulting Distance value for the OrigNode is greater than 254, the message is discarded. If the resulting Distance value for another node is greater than 254, the associated address and its information are removed from the RteMsg. After handling the OrigNode's routing information, then each address that is not the TargetNode MAY be considered for creating and updating routes. Creating and updating routes to other nodes can eliminate RREQ for those IP destinations, in the event that data needs to be forwarded to the IP destination(s) now or in the near future. For each of the additional addresses considered, ThisNode first checks that the address is a routable unicast address. If the address is not a unicast address, then the address and all related information MUST be removed. If the routing table does not have a matching route with a known Route.SeqNum for this additional address using longest-prefix matching, then a route MAY be created and updated as described in Section 5.2.2. If a route table entry exists with a known Route.SeqNum, the incoming routing information is compared with the route table entry following the procedure described in Section 5.2.1. If the incoming routing information is used, the route table entry SHOULD be updated as described in Section 5.2.2. If the routing information for an AdditionalNode.Address is not used, then it is removed from the RteMsg. 5.12. Administratively Configured Parameters and Timer Values AODVv2 contains several parameters which MUST be administratively configured. The list of these follows: Perkins & Chakeres Expires April 26, 2013 [Page 30] =0C Internet-Draft AODVv2 October 2012 Required Administratively Configured Parameters +------------------------+------------------------------------------+ | Name | Description | +------------------------+------------------------------------------+ | RESPONSIBLE_ADDRESSES | List of addresses or routing prefixes, | | | for which this AODVv2 router is | | | responsible. If, RESPONSIBLE_ADDRESSES | | | is zero, this AODVv2 router is only | | | responsible for its own addresses. | | AODVv2_INTERFACES | List of the interfaces participating in | | | AODVv2 routing protocol. | +------------------------+------------------------------------------+ Table 2 AODVv2 contains a number of timers. The default timing parameter values follow: Default Timing Parameter Values +------------------------------+-------------------+ | Name | Value | +------------------------------+-------------------+ | ROUTE_TIMEOUT | 5 seconds | | ROUTE_AGE_MIN_TIMEOUT | 1 second | | ROUTE_SEQNUM_AGE_MAX_TIMEOUT | 600 seconds | | ROUTE_USED_TIMEOUT | ROUTE_TIMEOUT | | ROUTE_DELETE_TIMEOUT | 2 * ROUTE_TIMEOUT | | ROUTE_RREQ_WAIT_TIME | 2 seconds | | UNICAST_MESSAGE_SENT_TIMEOUT | 1 second | UH> UNICAST_MESSAGE_SENT_TIMEOUT is never used in this specification +------------------------------+-------------------+ Table 3 The above timing parameter values work well for small and medium well-connected networks with moderate topology changes. UH> That also depends on the traffic patterns, on the lossy-ness of the links, on the density of the routers etc. The timing parameters SHOULD be administratively configurable for the network where AODVv2 is used. Ideally, for networks with frequent topology changes the AODVv2 parameters should be adjusted using either experimentally determined values or dynamic adaptation. For example, in networks with infrequent topology changes ROUTE_USED_TIMEOUT may be set to a much larger value. Perkins & Chakeres Expires April 26, 2013 [Page 31] =0C Internet-Draft AODVv2 October 2012 Default Parameter Values +------------------------+-------+----------------------------------+ | Name | Value | Description | +------------------------+-------+----------------------------------+ | MSG_HOPLIMIT | 20 | This value MUST be larger than | | | hops | the AODVv2 network diameter. | UH> How would the network diameter be determined? | | | Otherwise, routing messages may | | | | not reach their intended | | | | destinations. | | DISCOVERY_ATTEMPTS_MAX | 3 | The number of route discovery | | | | attempts to make before | | | | indicating that a particular | | | | address is not reachable. | +------------------------+-------+----------------------------------+ Table 4 In addition to the above parameters and timing values, several administrative options exist. These options have no influence on correct routing behavior, although they may potentially reduce AODVv2 protocol messaging in certain situations. The default behavior is to NOT enable any of these options; and although many of these options can be administratively controlled, they may be better served by intelligent control. The following table enumerates several of the options. Administratively Controlled Options +--------------------------+----------------------------------------+ | Name | Description | +--------------------------+----------------------------------------+ | BUFFER_DURING_DISCOVERY | Whether and how much data to buffer | | | during route discovery. | UH> Whether and how much? Is it a boolean flag or a number? | APPEND_EXTRA_UNREACHABLE | Whether to append additional | | | Unreachable information to RERR. | | CONTROL_TRAFFIC_LIMITS | AODVv2 messaging SHOULD be limited to | | | avoid consuming all the network | | | bandwidth. | UH> What is the unit or the meaning of this? Bytes per second? +--------------------------+----------------------------------------+ Table 5 Note: several fields have limited size (bits or bytes) these sizes and their encoding may place specific limitations on the values that can be set. For example, MsgHdr.HopLimit is a 8-bit field and therefore MSG_HOPLIMIT cannot be larger than 255. Perkins & Chakeres Expires April 26, 2013 [Page 32] =0C Internet-Draft AODVv2 October 2012 5.13. IANA Considerations UH> This is not a valid IANA section. There are no requests for registries or for TLV code points. There is no allocation policy. Refer to RFC5526. In its default mode of operation, AODVv2 uses the UDP port 269 [RFC5498] to carry protocol packets. AODVv2 also uses the link-local multicast address LL-MANET-Routers [RFC5498]. This section specifies several message types, message tlv-types, and address tlv-types. 5.13.1. AODVv2 Message Types Specification AODVv2 Message Types +------------------------+----------+ | Name | Type | +------------------------+----------+ | Route Request (RREQ) | 10 - TBD | | Route Reply (RREP) | 11 - TBD | | Route Error (RERR) | 12 - TBD | +------------------------+----------+ Table 6 5.13.2. Message and Address Block TLV Type Specification Message TLV Types +-------------------+------+--------+-------------------------------+ | Name | Type | Length | Value | +-------------------+------+--------+-------------------------------+ | Unicast Response | 10 - | 0 | Indicates to the processing | | Request | TBD | octets | node that the previous hop | | | | | (IP.SourceAddress) expects a | | | | | unicast reply message within | | | | | UNICAST_MESSAGE_SENT_TIMEOUT. | | | | | Any unicast packet will serve | | | | | this purpose, and it MAY be | | | | | an ICMP REPLY message. If | | | | | the reply is not received, | | | | | then the previous hop can | | | | | assume that the link is | | | | | unidirectional and MAY | | | | | blacklist the link to this | | | | | node. | +-------------------+------+--------+-------------------------------+ UH> It is never specified where and how to use this TLV? Is it a message-specifid TLV? To which registry do you want to add it? What is the allocation policy? What are the registered type extensions? Table 7 Perkins & Chakeres Expires April 26, 2013 [Page 33] =0C Internet-Draft AODVv2 October 2012 5.13.3. Address Block TLV Specification Address Block TLV Types +----------------+------------+----------+--------------------------+ | Name | Type | Length | Value | +----------------+------------+----------+--------------------------+ | AODVv2 | 10 - TBD | up to 2 | The AODVv2 sequence num | | Sequence | | octets | associated with this | | Number | | | address. The sequence | | (AODVv2SeqNum) | | | number may be the last | | | | | known sequence number. | | Distance | 11 - TBD | up to 2 | A metric of the distance | | | | octets | traversed by the | | | | | information associated | | | | | with this address. | UH> How is the distance formatted? | VALIDITY_TIME | 1[RFC5497] | | The maximum amount of | | | | | time that information | | | | | can be maintained before | | | | | being deleted. The | | | | | VALIDITY_TIME TLV is | | | | | defined in [RFC5497]. | +----------------+------------+----------+--------------------------+ Table 8 5.14. Security Considerations UH> This will not suffice; see RFC3552 for guidelines how to write security considerations. UH> Notably, there is no mention of possible threats to AODVv2. Also, there is some text to protect messages; but it is impossible to do so, as messages are changed in transit. Also, since there is no way to hook in security extensions (such as done in RFC6130) for rejecting messages, there is currently no security possible for DYMO. The objective of the AODVv2 protocol is for each router to communicate reachability information to addresses for which it is responsible. Positive routing information (i.e. a route exists) is distributed via RteMsgs and negative routing information (i.e. a route does not exist) via RERRs. AODVv2 routers that handle these messages store the contained information to properly forward data packets, and they generally provide this information to other AODVv2 routers. This section does not mandate any specific security measures. Instead, this section describes various security considerations and potential avenues to secure AODVv2 routing. The most important security mechanisms for AODVv2 routing are integrity/authentication and confidentiality. In situations where routing information or router identity are suspect, integrity and authentication techniques SHOULD be applied to AODVv2 messages. UH> How? Messages change in transit (addresses added or removed etc). In these situations, routing information that is distributed over multiple hops SHOULD also verify the integrity and Perkins & Chakeres Expires April 26, 2013 [Page 34] =0C Internet-Draft AODVv2 October 2012 identity of information based on originator of the routing information. UH> How? A digital signature could be used to identify the source of AODVv2 messages and information, along with its authenticity. A nonce or timestamp SHOULD also be used to protect against replay attacks. S/MIME and OpenPGP are two authentication/integrity protocols that could be adapted for this purpose. In situations where confidentiality of AODVv2 messages is important, cryptographic techniques can be applied. In certain situations, for example sending a RREP or RERR, an AODVv2 router could include proof that it has previously received valid routing information to reach the destination, at one point of time in the past. In situations where routers are suspected of transmitting maliciously erroneous information, the original routing information along with its security credentials SHOULD be included. Note that if multicast is used, any confidentiality and integrity algorithms used MUST permit multiple receivers to handle the message. Routing protocols, however, are prime targets for impersonation attacks. In networks where the node membership is not known, it is difficult to determine the occurrence of impersonation attacks, and security prevention techniques are difficult at best. However, when the network membership is known and there is a danger of such attacks, AODVv2 messages must be protected by the use of authentication techniques, such as those involving generation of unforgeable and cryptographically strong message digests or digital signatures. While AODVv2 does not place restrictions on the authentication mechanism used for this purpose, IPsec Authentication Message (AH) is an appropriate choice for cases where the nodes share an appropriate security association that enables the use of AH. UH> That only works for a single hop, not end-to-end, as the IP packets are not forwarded. In particular, routing messages SHOULD be authenticated to avoid creation of spurious routes to a destination. Otherwise, an attacker could masquerade as that destination and maliciously deny service to the destination and/or maliciously inspect and consume traffic intended for delivery to the destination. RERR messages SHOULD be authenticated in order to prevent malicious nodes from disrupting active routes between communicating nodes. If the mobile nodes in the ad hoc network have pre-established security associations, the purposes for which the security associations are created should include that of authorizing the processing of AODVv2 control packets. Given this understanding, the mobile nodes should be able to use the same authentication mechanisms Perkins & Chakeres Expires April 26, 2013 [Page 35] =0C Internet-Draft AODVv2 October 2012 based on their IP addresses as they would have used otherwise. 5.15. Acknowledgments AODVv2 is a descendant of the design of previous MANET on-demand protocols, especially AODV [RFC3561] and DSR [RFC4728]. Changes to previous MANET on-demand protocols stem from research and implementation experiences. Thanks to Elizabeth Belding-Royer for her long time authorship of AODV. Additional thanks to Luke Klein- Berndt, Pedro Ruiz, Fransisco Ros, Koojana Kuladinithi, Ramon Caceres, Thomas Clausen, Christopher Dearlove, Seung Yi, Romain Thouvenin, Tronje Krop, Henner Jakob, Alexandru Petrescu, Christoph Sommer, Cong Yuan, Lars Kristensen, and Derek Atkins for reviewing of AODVv2, as well as several specification suggestions. This revision of AODVv2 isolates the minimal base specification and other optional features to simplify the process of ensuring compatibility with the existing LOADng specification [I-D.clausen-lln-loadng] (minimal reactive routing protocol specification). Thanks are due to T. Clausen, A. Colin de Verdiere, J. Yi, A. Niktash, Y. Igarashi, Satoh. H., and U. Herberg for their development of LOADng and sharing details for ensuring appropriateness of AODVv2 for LLNs. 6. References 6.1. Normative References [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007. [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009. [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March 2009. [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network Perkins & Chakeres Expires April 26, 2013 [Page 36] =0C Internet-Draft AODVv2 October 2012 (MANET) Protocols", RFC 5498, March 2009. 6.2. Informative References [I-D.clausen-lln-loadng] Clausen, T., Verdiere, A., Yi, J., Niktash, A., Igarashi, Y., Satoh, H., Herberg, U., Lavenu, C., Lys, T., and C. Perkins, "The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng)", draft-clausen-lln-loadng-05 (work in progress), July 2012. [Perkins99] Perkins, C. and E. Belding-Royer, "Ad hoc On-Demand Distance Vector (AODV) Routing", Proceedings of the 2nd IEEE Workshop on Mobile Computing Systems and Applications, New Orleans, LA, pp. 90-100, February 1999. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4", RFC 4728, February 2007. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter Considerations in Mobile Ad Hoc Networks (MANETs)", RFC 5148, February 2008. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011. Perkins & Chakeres Expires April 26, 2013 [Page 37] =0C Internet-Draft AODVv2 October 2012 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- Instance Extensions", RFC 6549, March 2012. [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, May 2012. Appendix A. Changes since the Previous Version o Internet-Facing AODVv2 router renamed to be IAR o "Optional Features" section created to contain features not required within base specification, including: o * Intermediate RREPs (iRREPs): Without iRREP, only the destination can respond to a RREQ. * Precursor lists. * An RERR may reporting multiple unreachable nodes. * Message Aggregation. o Sequence number MUST (instead of SHOULD) be set to 1 after rollover. o ThisNode MUST (instead of SHOULD) only handle AODVv2 messages from adjacent routers. o Clarification that Additional Routing information in RteMsgs is optional (MAY) to use. o Clarification that if Additional Routing information in RteMsgs is used, then the Route Table Entry SHOULD be updated using normal procedures as described in Section 5.2.2. o Clarification in Section 5.4 that nodes may be configured to buffer zero packets. o Clarification in Section 5.4 that buffered packets MUST be dropped if route discovery fails. o In Section 5.5.1, relax mandate for monitoring connectivity to next-hop AODVv2 neighbors (from MUST to SHOULD), in order to allow for minimal implementations Perkins & Chakeres Expires April 26, 2013 [Page 38] =0C Internet-Draft AODVv2 October 2012 o Remove Route.Forwarding flag; identical to "NOT" Route.Broken. o Routing Messages MUST be originated with the MsgHdr.HopLimit set to MSG_HOPLIMIT. Previously, this was not mandated. o Maximum hop count set to 254, with 255 reserved for "unknown". Since the current draft only uses hop-count as distance, this is also the current maximum distance. Appendix B. Shifting Network Prefix Advertisement Between AODVv2 Routers Only one AODVv2 router within a routing region SHOULD be responsible for a particular address at any time. If two AODVv2 routers dynamically shift the advertisement of a network prefix, correct AODVv2 routing behavior must be observed. The AODVv2 router adding the new network prefix must wait for any existing routing information about this network prefix to be purged from the network. Therefore, it must wait at least ROUTER_SEQNUM_AGE_MAX_TIMEOUT after the previous AODVv2 router for this address stopped advertising routing information on its behalf. Authors' Addresses Charles E. Perkins Futurewei Inc. 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1-408-330-5305 Email: charliep@computer.org Ian D Chakeres CenGen 9250 Bendix Road North Columbia, Maryland 21045 USA Email: ian.chakeres@gmail.com URI: http://www.ianchak.com/ Perkins & Chakeres Expires April 26, 2013 [Page 39] From ulrich@herberg.name Thu Nov 1 15:02:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8F121F97D5 for ; Thu, 1 Nov 2012 15:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.659, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUIE5QSmrO-1 for ; Thu, 1 Nov 2012 15:02:06 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 68D0621F97D3 for ; Thu, 1 Nov 2012 15:02:06 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3543505vcb.31 for ; Thu, 01 Nov 2012 15:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zBCGU8PPB6/r6dKDlQInE9Niok2Es4GvSbLt1NdsVU0=; b=LTybUQoHGvFkLYNUF3Ud9OsDLP2iaVfSGtQDBgb2NpKPvXC6dwxp8WDEwTEy1lhvLA ChMfScDUREu3xq9GQq82IR+Fohy8s5fGUSUMCg/ancYONcrOXRDVDhsipH+p+17y97wj 6c5HVrL4oLC05ZqZPv27GTEUvvGWDVPfoI/+s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=zBCGU8PPB6/r6dKDlQInE9Niok2Es4GvSbLt1NdsVU0=; b=Ok0Qmdp8OvHwQ6Lhahc3DlN6d1CiAYwrfGoj18hosHIDfB9/9YhYqN6cemysi8Lfg9 PHCi3XopQt6lS4d1OXiKive2Wew1KHTil/5uqshiwnl9FOg5N5LOS447CKt2adc7TEH0 zHAXY+biDxF17qn1Y+rMC1vGoOj6dXk1at4bvTkTtW67wWoyNVtTSuiBfiA+kU3dQyOR u8JtTp3btlWbfd+5Oo6Eeg7NfXK0IZwEvDQqjqmv1/qmpT6LiUlXXWzpz7mRluuIgOat lmA2Zwyh74eyAcLRVMsoI4bJstJephH/iPT1tvqIrYjtj2q/iZAvx7nf5XWSt0KZQ4P8 /nAA== MIME-Version: 1.0 Received: by 10.52.67.44 with SMTP id k12mr52395962vdt.15.1351807325564; Thu, 01 Nov 2012 15:02:05 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Thu, 1 Nov 2012 15:02:05 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Nov 2012 15:02:05 -0700 Message-ID: From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl8ci2LSY/nTkrfCij3YtBXyu6b79poWv46HOvfHw7xMRqFXlX+Z1z7mJf20BezBHWuaqZK Cc: "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 22:02:07 -0000 Hi Chris, you have seen my review on DYMO. I will try to answer to your question, and focus on the technical differences, not presentation. On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK) wrote: > The obviously best people to answer this should be document authors, but = anyone else may have useful additions and comments. Ideally the different d= ocument authors could agree a list. (If they differ in that one has X and t= he other doesn't, but one wants to say "we plan to add/remove X" then X sho= uld be listed as a difference with that caveat, in at least my ideal world.= ) > > If we set aside, for the moment (though these things matter): > - The presentational quality of the documents, > - Any issues of 5444 compliance and other formatting issues, > - Issues of internal data organisation, > - Minor details such as possible different timeout parameters etc. > then what are the technical (and I stress that word) differences between = DYMO and LOADng? (I'm withholding the term AODVv2 for reasons I may come ba= ck to.) First, let's see what is common. Both are reactive protocols, using RREQ, RREP and RERR. So if someone claims that DYMO performs great and LOADng badly in the same scenario, I cannot understand that. MANET has understood the scenarios where reactive protocols are useful and where not. Now, to the differences: - DYMO cannot be end-to-end secured. Messages are changed in transit (and not just hop-limit or the metric), but rather addresses can be removed from RERRs and RREQs. There is also no provision to allow external mechanisms to add additional reasons to reject messages as invalid. - DYMO uses the originator address in an address block, LOADng in the message header. The sequence number is a TLV value in DYMO, and LOADng uses the message sequence number. DYMO requires the originator address to be the first one in the address block, the destination must be the second one. LOADng uses a TLV to determine the target address. - DYMO can advertise multiple addresses in an RERR; they can be removed in transit of the message. - DYMO allows intermediate routers to reply (as an option). That makes end-to-end security difficult. In the core DYMO, there is a destination sequence number that may be contained in RREQs in DYMO. - DYMO allows for unicast RREQ, but does not specify in detail how to use t= hat. - There are four timers for each route entry in DYMO, only one in LOADng. - LOADng can be used on other layers; DYMO is tied to IP. - LOADng provides a bidirectionality verification using RREP_ACK, a time-out of these, a blacklisted set and a Pending Acknowledgment Set to verify bidirectional links. DYMO says that other mechanisms can be used, but does not specify these. - DYMO has several options for expanding ring RREQ, precursor list, adding route information in transit, message aggregation in RFC5444 packets and reporting multiple unreachable addresses in a RERR. LOADng takes the approach to have a slim core of a basic mechanism that is applicable in all MANET use cases, and companion documents with extensions. In DYMO, it is not clearly specified what happens if some routers support an option, and others don't. - LOADng uses a Metric message TLV, and it is clearly defined how to update the metric under way. If a router in transit does not recognize a route metric type, it is reset to a "hop count" tlv extension type of the Metric TLV and the value set to 0xFFFFF... (for the full TLV length). It is specified that security mechanism must ignore the content of the metric TLV value and that the length cannot be changed under way, so that end-to-end security is possible. DYMO uses an optional "distance" field for the metric, which is not clearly specified how it is updated. Also, since this is optional, it is unclear if routers receiving a message and forwarding it, update the distance field or not. - LOADng allows for (optionally) waiting to reply with a RREP, in case a "better" RREQ comes a little later. In DYMO, a RREP is always sent immediately. There are probably more differences, but I let other chime in. Best regards Ulrich > Note that it's a lot more useful to have direct differences than differen= ces of each from AODV (especially when both have the same difference). And = it would be useful to have the objective differences separated from the "an= d now why this is better" discussion - though that would be a next step. > > I'm not saying I don't see any of the differences. But I certainly haven'= t worked out the complete list. In trying to form my view of how things sho= uld go forward (a view that is coming together, and when it does, I'll argu= e for it) and I hope for other people as well, it would be good to know wha= t the differences are. Regardless of views for or against each, we should b= e able to objectively list the significant differences - if we can't then s= omething is wrong. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > ******************************************************************** > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Thu Nov 1 15:21:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B5421F9638 for ; Thu, 1 Nov 2012 15:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXUlNbAzwUhx for ; Thu, 1 Nov 2012 15:21:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEA621F974D for ; Thu, 1 Nov 2012 15:21:30 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3583811vbb.31 for ; Thu, 01 Nov 2012 15:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type; bh=80euFgxghaZrW2ZHZGchSwoY1E4C7Op1syMSkWLJuNY=; b=StDzMybdtqPEy2aPdr/xq81tAdY8DF5lfpqs3A8N1i55NjBMDFV8YDHFNIo5nX5uSQ CzjMv+OalaoyKEeLI//0h5NN+UEypIDW3buDsJP4MWYN+eX9tJ0fl1BV/UOnhmgDCeBf 7KWIPeNgfyBTzzLhl8kept9ztt38zXPW9R4l4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=80euFgxghaZrW2ZHZGchSwoY1E4C7Op1syMSkWLJuNY=; b=Q2fH0X6T17d2Q/GkvKChEcXWnGekXaLqZKhpk5ADa3aO7AX0canobviSCnpTT10n5Y 7NgGgJzwda2CILpaitNGWkdBzdrkRlCn5cin4olSYRzs0qJD6NZwBaeEUj7GcD4FjmdR EnPtE2MgGV0P6xPmgNUwMo2yD8hzEynSNcgohtZjGMvFuqwiYkpdVqfLf5weKZJzXm9E ZJqajC2ugUayGypy3aiD/XE2E/COkhYyh7cBT72bEo+i9oiyNeqap7cEmUqYk7B7KjD5 TtxSQ9Ujo0JNLtOlg7z4BxWw44LrrA5BLGP3dZCnClfMiqoMcQMdvYN087XNg+uThawJ +aiQ== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr53415495vdv.20.1351808489974; Thu, 01 Nov 2012 15:21:29 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Thu, 1 Nov 2012 15:21:29 -0700 (PDT) Date: Thu, 1 Nov 2012 15:21:29 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk3VjfyEh4cWPM5WeTTMgmGHCKeP6BQQ7WsNWRaXg01D7zFsTHMZbpDODc6Hio/uz2EBNaz Subject: [manet] Scribe / minutes takers? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 22:21:34 -0000 Hi, anyone volunteering for any of the jobs listed in the subject? :-) Please contact me in that case. Thanks for your support! Ulrich From c.chauvenet@watteco.com Thu Nov 1 16:35:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7010121F97BD for ; Thu, 1 Nov 2012 16:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niCLR--ZGEFQ for ; Thu, 1 Nov 2012 16:35:10 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id EF54B21F95DE for ; Thu, 1 Nov 2012 16:35:09 -0700 (PDT) Received: from mail13-co1-R.bigfish.com (10.243.78.253) by CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id 14.1.225.23; Thu, 1 Nov 2012 23:35:08 +0000 Received: from mail13-co1 (localhost [127.0.0.1]) by mail13-co1-R.bigfish.com (Postfix) with ESMTP id AE4AC9001F3; Thu, 1 Nov 2012 23:35:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT002.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz98dI9371Ic89bhc85dhzz1de0h1202h1d1ah1d2ahz8dhz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received: from mail13-co1 (localhost.localdomain [127.0.0.1]) by mail13-co1 (MessageSwitch) id 1351812905795837_29304; Thu, 1 Nov 2012 23:35:05 +0000 (UTC) Received: from CO1EHSMHS032.bigfish.com (unknown [10.243.78.248]) by mail13-co1.bigfish.com (Postfix) with ESMTP id C0735D800AB; Thu, 1 Nov 2012 23:35:05 +0000 (UTC) Received: from DBXPRD0510HT002.eurprd05.prod.outlook.com (157.56.252.165) by CO1EHSMHS032.bigfish.com (10.243.66.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 1 Nov 2012 23:35:05 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT002.eurprd05.prod.outlook.com ([10.255.67.165]) with mapi id 14.16.0233.002; Thu, 1 Nov 2012 23:35:03 +0000 From: C Chauvenet To: Abdussalam Baryun Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNtvRAV6TKZOGU0EeXjdQ8Uxmd8pfVeS0AgAAr8IA= Date: Thu, 1 Nov 2012 23:35:02 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D215712C9@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.42.4] Content-Type: multipart/alternative; boundary="_000_97B69B30E0EF244B940B65EA541E3F2D215712C9DBXPRD0510MB395_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 23:35:11 -0000 --_000_97B69B30E0EF244B940B65EA541E3F2D215712C9DBXPRD0510MB395_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi AB, MANET chairs already propose 3 options, and poll the WG to get opinions. I think we should stick to it. Thank you for your comments though. C=E9dric. Le 1 nov. 2012 =E0 21:57, Abdussalam Baryun a =E9crit : Dear MANET WG Chairs, I recommend we base our choices and options on our present ietf Charter and= milestones we got so far, so we can follow in our choices the best practic= e. I recommend that we look into the following three options which can be base= d on the MANET Charter and the WG-I-Ds' work-flow-progress: 1- DYMO/AODVv2 to be completed and prepared by the WG to be submitted. 2- The WG chairs and participants to work together in one team work of auth= oring one reactive protocol (a merge solution, with both draft authors incl= uding WG chair). 3- Accept the individual LOADng draft as a second reactive protocol, then, = to decide in the future how to merge both AODVv2 ideas into LOADng dependin= g on comparing specifications. My Comments on the mentioned drafts history and your recommended options, i= n line in below message, AB ++++++++++++++ On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker > wrote: Hello MANET working group (form Stan and Joe), As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common documen= t effort and given positive feedback at the time we the chairs thought this= was the best approach given the authors potential to come together and gai= n the best of both efforts. Since that period, there has been some fairly = strident and rancorous "at times" debate between the authors of the two doc= uments. There was never any announcement of such merge movement, however, there was= a suggestion for that by one DYMO author but was refused by one LOADng aut= hor. During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts = and LOADng had fairly active authorship and implementation efforts. We prov= ided a co-editing proposal to the authors and gave them the timeframe of th= e Atlanta to come up with an answer back to us regarding this. As of this = writing, those discussions of a potential commonn document and authorship m= erger have failed. Again in the 84 meeting there was no such announcement of any merge between= DYMO's I-D and the LOADng I-D. We only seen an author added to LOADng I-D = which was an author of DYMO I-D, but does not meen merging drafts and not a= nnounced to WG such suggestions. Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss= ue at the present time. We see only 3 possible paths forward: 1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2. There is no reason why we need to ignore this option, is it because DYMO au= thors did not do any work for some time and the WG as well did not do any, = or is it because an individual draft came up to interrupt the WG work in pr= ogress. 2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document). We need to accept the LOADng as a WG item first then we decide if we can ta= ke option 2 3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus. The reactive protocol is a must protocol for MANETs, killing it will not re= ally kill it but will give chance to other competitor organisations to stan= dard reactive protocol before IETF. The co-chairs request and need your opinions on the options. We have been = some silent collecting initial feedback and waiting for author feedback at = this point. Stan and I are both on travel prior to Atlanta so our response= s may be sparse and we will also likely be in a "receive mode" for a few da= ys. So send your opinions. -Joe _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_97B69B30E0EF244B940B65EA541E3F2D215712C9DBXPRD0510MB395_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Hi AB, 

MANET chairs already propose 3 options, and poll the WG to get opinion= s.
I think we should stick to it. 

Thank you for your comments though.

C=E9dric.

Le 1 nov. 2012 =E0 21:57, Abdussalam Baryun a =E9crit :

Dear MANET WG Chairs,
 
I recommend we base our choices and options on our present ietf Charte= r and milestones we got so far, so we can follow in our choices the best pr= actice.
 
I recommend that we look into the following three options which c= an be based on the MANET Charter and the WG-I-Ds' work-flow-progress:
 
1- DYMO/AODVv2 to be completed and prepared by the WG to be submitted.=
2- The WG chairs and participants to work together in one team work of= authoring one reactive protocol (a merge solution, with both draft authors= including WG chair).
3- Accept the individual LOADng draft as a second reactive protocol, t= hen, to decide in the future how to merge both AODVv2 ideas into = LOADng depending on comparing specifications.
My Comments on the mentioned drafts history and your recommended = options, in line in below message,
 
AB
++++++++++++++
On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker = <jpmacker@gmail.= com> wrote:
Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.  Sin= ce that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.
 
There was never any announcement of such merge movement, however, ther= e was a suggestion for that by one DYMO author but was refused by = ;one LOADng author.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active author= ship and implementation efforts. We provided a co-editing proposal to the a= uthors and gave them the timeframe of the Atlanta to come up with an answer= back to us regarding this.  As of this writing, those discussions of a potential commonn document and aut= horship merger have failed.
 
Again in the 84 meeting there was no such announcement of any merge be= tween DYMO's I-D and the LOADng I-D. We only seen an author added to LOADng= I-D which was an author of DYMO I-D, but does not meen merging drafts and = not announced to WG such suggestions. 

Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.  We s= ee only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
There is no reason why we need to ignore this option, is it because DY= MO authors did not do any work for some time and the WG as well did not do = any, or is it because an individual draft came up to interrupt the WG work = in progress.
 
2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document).
 
We need to accept the LOADng as a WG item first then we decide if we c= an take option 2
 
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.
 
The reactive protocol is a must protocol for MANETs, killing it will n= ot really kill it but will give chance to other competitor organisations to= standard reactive protocol before IETF.

The co-chairs request and need your opinions on the options.  We have = been some silent collecting initial feedback and waiting for author feedbac= k at this point.  Stan and I are both on travel prior to Atlanta so ou= r responses may be sparse and we will also likely be in a "receive mode" for a few days.  So send your= opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_97B69B30E0EF244B940B65EA541E3F2D215712C9DBXPRD0510MB395_-- From c.chauvenet@watteco.com Thu Nov 1 16:43:27 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F19D21F8A77 for ; Thu, 1 Nov 2012 16:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIAgemVvpNXk for ; Thu, 1 Nov 2012 16:43:21 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 06DDA21F8A70 for ; Thu, 1 Nov 2012 16:43:20 -0700 (PDT) Received: from mail49-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 1 Nov 2012 23:43:20 +0000 Received: from mail49-tx2 (localhost [127.0.0.1]) by mail49-tx2-R.bigfish.com (Postfix) with ESMTP id 4B1602203A8; Thu, 1 Nov 2012 23:43:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT002.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzc89bh601I7f52h1432I1418I62a3Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received: from mail49-tx2 (localhost.localdomain [127.0.0.1]) by mail49-tx2 (MessageSwitch) id 1351813394388319_7586; Thu, 1 Nov 2012 23:43:14 +0000 (UTC) Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.253]) by mail49-tx2.bigfish.com (Postfix) with ESMTP id 5A3E24E0046; Thu, 1 Nov 2012 23:43:14 +0000 (UTC) Received: from DBXPRD0510HT002.eurprd05.prod.outlook.com (157.56.252.165) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 1 Nov 2012 23:43:13 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT002.eurprd05.prod.outlook.com ([10.255.67.165]) with mapi id 14.16.0233.002; Thu, 1 Nov 2012 23:43:01 +0000 From: C Chauvenet To: Ulrich Herberg Thread-Topic: [manet] DYMO-23 review Thread-Index: AQHNuHlU21InLanRTku0Vy47XHrsgpfVpEcA Date: Thu, 1 Nov 2012 23:43:00 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D21571353@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.42.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "" Subject: Re: [manet] DYMO-23 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 23:43:27 -0000 Hi,=20 Le 1 nov. 2012 =E0 22:38, Ulrich Herberg a =E9crit : > Hi, >=20 > during the discussion, I noticed that many just say "I like protocol > foo1 better than foo2", without any technical argument. That is not > very productive. I think it is because chairs proposed 3 options and ask WG to give their op= inion on these 3 solutions. Of course, we could have very deep technical discussions, and expand the me= ssage storm on the list but from what I understood chairs are mostly waiti= ng for opinions on these 3 choices. C=E9dric. >=20 > Here is my review of the latest DYMO 23 draft. >=20 > The main comments (as shown in detail below) are: > - The draft is still very difficult to read and is underspecified in > many occasions. For example, it is unclear how the blacklisting works, > how metrics are used, how the TLVs are associated with certain > addresses. Some of the parameters and TLVs specified in the IANA > section are not used. There are at least four timers for each route > entry, and it is unclear how they may affect each other. It is not > clearly specified how to update forward/reverse routes + the route to > the previous hop > - The use of metrics is not well defined; there is an optional > distance field. It is unclear how metrics are created, whether they > are additive, how they are formatted etc. What happens if some routers > now the Distance field, others don't use it. > - There are several extensions specified, but too few details to > assure interoperability. Some of them violate end-to-end security. > - As messages are modified in transit, end-to-end security is not > possible. The security considerations section does not fulfill the > requirements in RFC3552. > - Extensions, such as for security, cannot be hooked into AODVv2, as > there is no section to allow an external mechanism to provide > additional reasons to reject a message as invalid, such as done in > RFC6130. > - The IANA section is not correct. There are no requests, no new > registries or code points in existing registries, no allocation policy > is provided. > - There are some layer violations where tasks that are to be done by > the RFC5444 (de)multiplexer are handled in AODVv2. > - There is a mandated order of addresses in RFC5444 messages; I > think this is a bad idea if extensions want to add addresses. > - Originator address and sequence number are contained in address > block and address block TLV, instead of the message header, so there > is additional overhead. > - There is no RREP_ACK or other mechanism to verify bidirectionality > of links. > - It is unclear to me how the destination sequence number is used in > RREQ and what it serves for. > - Intermediate route replies are hard to secure with signatures >=20 > Best regards > Ulrich >=20 >=20 >=20 > Mobile Ad hoc Networks Working Group C. Perkins > Internet-Draft Futurewei > Intended status: Standards Track I. Chakeres > Expires: April 26, 2013 CenGen > October 23, 2012 >=20 >=20 > Dynamic MANET On-demand (AODVv2) Routing > draft-ietf-manet-dymo-23 >=20 > Abstract >=20 > The Dynamic MANET On-demand (AODVv2) routing protocol is intended for > use by mobile routers in wireless, multihop networks. >=20 > UH> It is really about dynamic topology, not "mobile routers". AODVv2 > may be used in non-mobile mesh networks with a dynamic topology. >=20 > AODVv2 > determines unicast routes among AODVv2 routers within the network in > an on-demand fashion, offering on-demand convergence in dynamic > topologies. >=20 > UH> What is on-demand convergence? >=20 > Status of this Memo >=20 > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. >=20 > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > This Internet-Draft will expire on April 26, 2013. >=20 > Copyright Notice >=20 > Copyright (c) 2012 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 1] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > described in the Simplified BSD License. >=20 >=20 > Table of Contents >=20 > 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 > 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 8 > 4.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 8 > 4.2. AODVv2 Message Structure and Information Elements . . . . 9 > 4.3. RteMsg-specific Protocol Elements . . . . . . . . . . . . 11 > 4.4. Route Error (RERR)-specific Protocol Elements . . . . . . 12 > 5. Detailed Operation for the Base Protocol . . . . . . . . . . . 13 > 5.1. AODVv2 Sequence Numbers . . . . . . . . . . . . . . . . . 13 > 5.1.1. Maintaining A Node's Own Sequence Number . . . . . . . 13 > 5.1.2. Actions After OwnSeqNum Loss . . . . . . . . . . . . . 13 > 5.2. AODVv2 Routing Table Operations . . . . . . . . . . . . . 13 > 5.2.1. Judging Routing Information's Usefulness . . . . . . . 13 > 5.2.2. Creating or Updating Route Table Entries . . . . . . . 15 > 5.2.3. Route Table Entry Timeouts . . . . . . . . . . . . . . 15 > 5.3. Routing Messages . . . . . . . . . . . . . . . . . . . . . 16 > 5.3.1. RREQ Creation . . . . . . . . . . . . . . . . . . . . 16 > 5.3.2. RREP Creation . . . . . . . . . . . . . . . . . . . . 17 > 5.3.3. RteMsg Handling . . . . . . . . . . . . . . . . . . . 18 > 5.4. Route Discovery . . . . . . . . . . . . . . . . . . . . . 20 > 5.5. Route Maintenance . . . . . . . . . . . . . . . . . . . . 21 > 5.5.1. Active Next-hop Router Adjacency Monitoring . . . . . 21 > 5.5.2. Updating Route Lifetimes During Packet Forwarding . . 22 > 5.5.3. RERR Generation . . . . . . . . . . . . . . . . . . . 22 > 5.5.4. RERR Handling . . . . . . . . . . . . . . . . . . . . 23 > 5.6. Unknown Message and TLV Types . . . . . . . . . . . . . . 24 > 5.7. Advertising Network Addresses . . . . . . . . . . . . . . 24 > 5.8. Simple Internet Attachment . . . . . . . . . . . . . . . . 24 > 5.9. Multiple Interfaces . . . . . . . . . . . . . . . . . . . 25 > 5.10. AODVv2 Control Packet/Message Generation Limits . . . . . 26 > 5.11. Optional Features . . . . . . . . . . . . . . . . . . . . 26 > 5.11.1. Expanding Rings Multicast . . . . . . . . . . . . . . 26 > 5.11.2. Intermediate RREP . . . . . . . . . . . . . . . . . . 27 > 5.11.3. Precursor Notification . . . . . . . . . . . . . . . . 27 > 5.11.4. Reporting Multiple Unreachable Nodes . . . . . . . . . 28 > 5.11.5. Message Aggregation . . . . . . . . . . . . . . . . . 28 > 5.11.6. Adding Additional Routing Information to a RteMsg . . 29 > 5.12. Administratively Configured Parameters and Timer Values . 30 > 5.13. IANA Considerations . . . . . . . . . . . . . . . . . . . 33 > 5.13.1. AODVv2 Message Types Specification . . . . . . . . . . 33 > 5.13.2. Message and Address Block TLV Type Specification . . . 33 > 5.13.3. Address Block TLV Specification . . . . . . . . . . . 34 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 2] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 5.14. Security Considerations . . . . . . . . . . . . . . . . . 34 > 5.15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 36 > 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 > 6.1. Normative References . . . . . . . . . . . . . . . . . . . 36 > 6.2. Informative References . . . . . . . . . . . . . . . . . . 37 > Appendix A. Changes since the Previous Version . . . . . . . . . 38 > Appendix B. Shifting Network Prefix Advertisement Between > AODVv2 Routers . . . . . . . . . . . . . . . . . . . 39 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 3] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 1. Overview >=20 > The Dynamic MANET On-demand (AODVv2) routing protocol [formerly named > DYMO] enables on-demand, multihop unicast routing among AODVv2 > routers in mobile ad hod networks [MANETs][RFC2119]. >=20 > UH> Why is RFC2119 cited here? >=20 > The basic > operations of the AODVv2 protocol are route discovery and route > maintenance. Route discovery is performed when an AODVv2 router must > transmit a packet towards a destination for which it does not have a > route. Route maintenance is performed to avoid dropping packets, > when a route being used to forward packets from the source to a > destination breaks, >=20 > UH> That is something that is unclear in the draft. Would data packets > be buffered on intermediate routers along their way? Would a new RREQ > be issed from intermediate routers? If not, packets would be dropped. >=20 > and to avoid prematurely expunging routes from > the route table. >=20 > During route discovery, an AODVv2 router initiates flooding of a > Route Request message (RREQ) throughout the network to find a route > to a particular destination, via the AODVv2 router responsible for > this destination. During this hop-by-hop flooding process, each > intermediate AODVv2 router receiving the RREQ message records a route > to the originator. When the target's AODVv2 router receives the > RREQ, it records a route to the originator and responds with a Route > Reply (RREP) unicast hop-by-hop toward the originating AODVv2 router. > Each intermediate AODVv2 router that receives the RREP creates a > route to the target, and then the RREP is unicast hop-by-hop toward > the originator. When the originator's AODVv2 router receives the > RREP, routes have then been established between the originating > AODVv2 router and the target AODVv2 router in both directions. >=20 > Route maintenance consists of two operations. In order to preserve > routes in use, AODVv2 routers extend route lifetimes upon > successfully forwarding a packet. In order to react to changes in > the network topology, AODVv2 routers monitor traffic being forwarded. > When a data packet is received for forwarding and a route for the > destination is not known or the route is broken, then the AODVv2 > router of the source of the packet is notified. A Route Error (RERR) > is transmitted to indicate the route to one or more affected > destination addresses is Broken >=20 > UH> s/Broken/broken/ >=20 > or missing. When the source's AODVv2 > router receives the RERR, it marks the route as broken. Before the > AODVv2 router can forward a packet to the same destination, it has to > perform route discovery again for that destination. >=20 > Similarly to AODV, AODVv2 uses sequence numbers to ensure loop > freedom [Perkins99]. >=20 > UH> Citation to AODV missing. Is AODVv2 updating or obsoleting AODV? >=20 > Sequence numbers enable AODVv2 routers to > determine the temporal order of AODVv2 route discovery messages, > thereby avoiding use of stale routing information. Also, AODVv2 uses > RFC 5444 message and TLV formats. >=20 > UH> As this is the successor to AODV, it would help to point out what > has been improved/changed compared to AODV. >=20 >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 4] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 2. Terminology >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > [RFC2119]. >=20 > Additionally, this document uses some terminology from [RFC5444]. >=20 > UH> Which one? >=20 > This document defines the following terminology: >=20 > Adjacency > A relationship between selected bi-directional neighboring routers > for the purpose of exchanging routing information. Not every pair > of neighboring routers will necessarily form an adjacency. > Neighboring routers may form an adjacency based on various > information or other protocols; for example, exchange of AODVv2 > routing messages, other protocols (e.g. NDP [RFC4861] or NHDP > [RFC6130]), or manual configuration. Loss of a routing adjacency > may also be based upon similar information; monitoring of > adjacencies where packets are being forwarded is required (see > Section 5.5.1). >=20 > Distance (Dist) > An unsigned integer which measures the distance a message or > information element has traversed. The minimum value of distance > is the number of IP hops traversed, 0 for local information. The > maximum value is 254. The value 255 is reserved to indicate that > the distance is unknown. >=20 > UH> Is this a metrics? Why integer and not float? Is this additive? > Why is it optional in the draft. Are there different metric types > supported in the same network? >=20 >=20 > AODVv2 Sequence Number (SeqNum) > An AODVv2 Sequence Number is an unsigned integer maintained by > each AODVv2 router. This sequence number guarantees the temporal > order of routing information to maintain loop-free routes. The > value zero (0) is reserved to indicate that the SeqNum for a > destination address is unknown. >=20 > UH> The last sentence is unclear. The first sentence said there is one > seq. number per router. The last sentence talks about sequence numbers > for destinations, which is a different thing. >=20 > reactive > A protocol operation is said to be "reactive" if it is performed > only in reaction to specific events. As used in this document, > "reactive" is essentially synonymous with "on-demand". >=20 > Router Client > An AODVv2 router may be configured with a list of other IP > addresses and networks which correspond to other non-router nodes > which require the services of the AODVv2 router for route > discovery and maintenance. An AODVv2 is always its own client, so > that the list of client IP addresses is never empty. corresponds >=20 > UH> s/corresponds/Corresponds/ >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 5] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > to the AODVv2 router process currently performing a calculation or > processing a message. >=20 > UH> I don't think it is a good idea to introduce that terminology. It > seems to be conflicting with the IP architecture of hosts and routers. > Is a Router Client a host? >=20 > Flooding > In this document, flooding a message refers to the process of > delivering the message to every AODVv2 router in the network. > This may be done according to methods specified in [RFC5148]. >=20 > UH> RFC5148 describes jitter in MANETs, not flooding methods. >=20 > Routable Unicast IP Address > A routable unicast IP address is a unicast IP address that when > put into the IP.SourceAddress or IP.DestinationAddress field is >=20 > UH> Notation not defined: "IP.x" >=20 > scoped sufficiently to be forwarded by a router. >=20 > UH> I am not quite sure what that means. Can you cite an RFC, maybe RFC40= 07? >=20 > Globally-scoped > unicast IP addresses and Unique Local Addresses (ULAs) [RFC6130] > are examples of routable unicast IP addresses. >=20 > UH> RFC6130 is NHDP, not ULA. ULA's are not globally routable and > cannot be accessed from outside a "site". >=20 > Originating Node (OrigNode) > The originating node is the data source node; if it is not itself > an AODVv2 router, its AODVv2 router creates a AODVv2 RREQ message > on its behalf in an effort to flood some routing information. The > originating node is also referred to as a particular message's > originator. >=20 > Target Node (TargetNode) > The TargetNode denotes the ultimate destination of a message. >=20 > UH> Is this for control packets only or for data traffic? Is that an IP a= ddress? >=20 > This Node (ThisNode) > ThisNode denotes the AODVv2 router currently processing an AODVv2 > message. >=20 > Route Error (RERR) > A RERR message is used to indicate that an AODVv2 router no longer > has a route to one or more particular destinations. >=20 > UH> Or it may have one, and data traffic was lost when sending it to > the next hop >=20 > Route Reply (RREP) > A RREP message is used to supply routing information about the > RREQ TargetNode to the RREQ OrigNode and the AODVv2 routers > between them. >=20 > Route Request (RREQ) > An AODVv2 router uses a RREQ message to discover a valid route to > a particular destination address, called the RREQ TargetNode. > When an AODVv2 router processes a RREQ, it learns routing > information on how to reach the RREQ OrigNode. >=20 > Type-Length-Value structure (TLV) > A generic way to represent information as specified in [RFC5444]. >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 6] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > Unreachable Node (UnreachableNode) > An UnreachableNode is a node for which a forwarding route is > unknown. >=20 > UH> Or to which data traffic has been lost while forwarding to the next h= op. >=20 >=20 > 3. Applicability Statement >=20 > The AODVv2 routing protocol is designed for stub (i.e., non-transit) > or disconnected (i.e., from the Internet) mobile ad hoc networks > (MANETs). AODVv2 handles a wide variety of mobility patterns by > dynamically determining routes on-demand. AODVv2 also handles a wide > variety of traffic patterns. In networks with a large number of > routers, AODVv2 is best suited for sparse traffic scenarios where any > particular router forwards packets to only a small percentage of the > AODVv2 routers in the network, due to the on-demand nature of route > discovery and route maintenance. >=20 > AODVv2 is applicable to memory constrained devices, since little > routing state is maintained in each AODVv2 router. Only routing > information related to routes between active sources and destinations > is maintained, in contrast to proactive routing protocols that > require routing information to all routers within the routing region > be maintained. >=20 > AODVv2 supports routers with multiple interfaces. In addition to > routing for their local processes, AODVv2 routers can also route on > behalf of other non-routing nodes (i.e., "hosts"), reachable via > those interfaces. Any such node which is not itself an AODVv2 router > SHOULD NOT be served by more than one AODVv2 router. >=20 > UH> I would rather not use RFC2119 in an applicability statement. This > is not normative. >=20 > Although AODVv2 > is closely related to AODV [RFC3561], and has some of the features of > DSR [RFC4728], AODVv2 is not interoperable with either of those other > two protocols. >=20 > AODVv2 routers perform route discovery to find a route to a > particular destination. Therefore, AODVv2 routers MUST must be > configured to respond to RREQs for a certain set of addresses. When > AODVv2 is the only protocol interacting with the forwarding table, > AODVv2 MAY be configured to perform route discovery for all unknown > unicast destinations. >=20 > At all times within an AODVv2 routing region, only one AODVv2 router > SHOULD be serve any routing client. The coordination among multiple > AODVv2 routers to distribute routing information correctly for a > shared address (i.e. an address that is advertised and can be reached > via multiple AODVv2 routers) is not described in this document. The > AODVv2 router operation of shifting responsibility for a routing > client from one AODVv2 router to another is mentioned in Appendix B >=20 > UH> I am not sure that it is a good idea to include multi-homing in a > short paragraph in Appendix B. I think this whole section can be > removed. >=20 >=20 > Each AODVv2 router, if serving router clients other than itself, is >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 7] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > configured with information about the IP addresses of its clients. > There is no requirement that an AODVv2 router have information about > the router clients of other AODVv2 routers. Address assignment > procedures are entirely out of scope for AODVv2. >=20 > AODVv2 only utilizes bidirectional links. In the case of possible > unidirectional links, either blacklists (see Section 5.13.2) or other > means (e.g. adjacency establishment with only neighboring routers > that have bidirectional communication as indicated by NHDP [RFC6130]) >=20 > UH> The blacklisting is not specified in this document. >=20 > of ensuring and monitoring bi-directionality is recommended. > Otherwise, persistent packet loss could occur. >=20 > The routing algorithm in AODVv2 may be operated at layers other than > the network layer, using layer-appropriate addresses. >=20 > UH> Yes, but the whole document is limited to IP. It is tied to IP > headers, UDP etc at multiple places. >=20 > The routing > algorithm makes >=20 > UH> + "use" >=20 > of some persistent state; if there is no persistent > storage available for this state, recovery can exact a performance > penalty in case of AODVv2 router reboots. >=20 >=20 > 4. Data Structures >=20 > UH> There is a mixture between information bases and message formats. > I would rather have two seperate sections for that. > UH> There are no other information sets that I believe are required > for AODV: blacklisted set, set of local interfaces, and a set of the > hosts that this router is responsible. >=20 > 4.1. Route Table Entry >=20 > The route table entry is a conceptual data structure. > Implementations may use any internal representation so long as it > provides access to the same information as specified below. >=20 > Conceptually, a route table entry has the following fields: >=20 > Route.Address > The (host or network) destination address of the node(s) > associated with the routing table entry. >=20 > Route.Prefix > The value is the length of the netmask/prefix. >=20 > UH> in octets? >=20 > If the value of > the Route.Prefix is different than the length of addresses in the > address family used by the AODVv2 routers, the associated address > is a routing prefix, rather than a host address. >=20 > Route.SeqNum > The AODVv2 SeqNum associated with a route table entry. >=20 > Route.NextHopAddress > An IP address of the adjacent AODVv2 router on the path toward the > Route.Address. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 8] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > Route.NextHopInterface > The interface used to send packets toward the Route.Address. >=20 > Route.Broken > A flag indicating whether this Route is broken. This flag is set > to true if the next-hop becomes unreachable or in response to > processing to a RERR (see Section 5.5.4). >=20 > The following field is optional: >=20 > Route.Dist > A dimensionless metric indicating the distance traversed before > reaching the Route.Address node. >=20 > UH> Why is this optional? It makes the whole specification more > complicated, in particular interoperability. I cannot imagine cases > where you are not interested in the distance. > UH> Is this metric additive? is it only integer? is it used in > addition to hop-count or instead? >=20 > Not including optional information may cause performance degradation, > but it will not prohibit the protocol from discovering valid routes. >=20 > In addition to a route table data structure, each route table entry > may have several timers associated with the information. Timers and > timeouts are discussed in Section 5.2.3. >=20 > UH> That forward link makes it difficult. Why not include the > expiration timers here, similar to OLSRv2? >=20 > 4.2. AODVv2 Message Structure and Information Elements >=20 > IP Protocol Number 138 (manet) has been reserved for MANET protocols > [RFC5498]. In addition to using this IP protocol number, AODVv2 may > use UDP at destination port 269 (manet) [RFC5498]. >=20 > UH> may or MAY? >=20 > AODVv2 messages are transmitted in packets that conform to the > generalized packet and message format as described in [RFC5444]. > Here is a brief description of the format. >=20 >=20 > A packet formatted according to RFC5444 contains zero or more > messages. >=20 >=20 > A message contains a message header, message TLV block, and zero > or more address blocks. >=20 >=20 > Each of the address blocks may also have an associated address TLV > block. >=20 > UH> Each address block *must* have a TLV block (it may be empty though). >=20 > All AODVv2 messages SHOULD be sent using the IP protocol number (138) > reserved for manet protocols [RFC5498]; or the UDP destination port > (269) reserved for manet protocols [RFC5498] and IP protocol number > for UDP. >=20 > UH> That is redundant to the first paragraph of this section. >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 9] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > Most AODVv2 messages are sent with the IP destination address set to > the link-local multicast address LL-MANET-Routers [RFC5498] unless > otherwise specified. Therefore, all AODVv2 routers SHOULD subscribe > to LL-MANET-Routers [RFC5498] to receiving AODVv2 messages. Note > that multicast packets MAY be sent via unicast. >=20 > UH> That sounds confusing: multicast packets MAY be sent via unicast. > First, what is a multicast packet? (you mean an IP packet with a > multicast destination address>). Why MAY? >=20 > For example, this > may occur for certain link-types (non broadcast mediums), for > manually configured router adjacencies, or in order to improve > robustness. >=20 > UH> How would one manually configure a router adjacency? >=20 > When describing AODVv2 protocol messages, it is necessary to refer to > fields in several distinct parts of the overall packet. >=20 > UH> Since there is an RFC5444 demultiplexer, AODVv2 would never see > the packet. So I think it's better not to use that term here. >=20 > These > locations include the IP header, the UDP header, and fields from > [RFC5444]. This document uses the notational conventions found in > table 1. >=20 > +---------------------------+-------------------+ > | Information Location | Notational Prefix | > +---------------------------+-------------------+ > | IP header | IP. | > | RFC5444 message header | MsgHdr. | > | RFC5444 message TLV | MsgTLV. | > | RFC5444 address blocks | AddBlk. | > | RFC5444 address block TLV | AddTLV. | > +---------------------------+-------------------+ >=20 > Table 1 >=20 > The IPv4 TTL (IPv6 Hop Limit) field for all packets containing AODVv2 > messages is set to 255. >=20 > UH> I think that's the job of the RFC5444 multiplexer. >=20 > If a packet is received with a value other > than 255, any AODVv2 message contained in the packet MUST be ignored > by AODVv2. >=20 > UH> No, the packet would never be received by AODVv2. Only a message woul= d. >=20 > This mechanism, known as "The Generalized TTL Security > Mechanism" (GTSM) [RFC5082] helps to ensure that packets have not > traversed any intermediate routers. >=20 > UH> Again, part of the RFC5444 multiplexer. >=20 > The length of an address (32 bits for IPv4 and 128 bits for IPv6) > inside an AODVv2 message depends on the msg-addr-length (MAL) in the > msg-header, as specified in [RFC5444]. >=20 > UH> Limitation of AODVv2 to IP addresses. It could also be used for > compressed (lowpan) addresses or MAC addresses. >=20 > IP packets containing AODVv2 protocol messages SHOULD be given > priority queuing and channel access. >=20 > UH> Not the task of AODVv2, but the RFC5444 multiplexer >=20 > AODVv2 messages require the following information: >=20 > IP.SourceAddress > The IP address of the node currently sending this packet. This > field is generally filled automatically by the operating system > and should not require special handling. >=20 > UH> An AODVv2 message cannot have an IP address. That's a different > layer. The IP packet that contains an RFC5444 packet (which the IP > layer received from the RFC5444 multiplexer) has that address. > Also, it is not necessarily the node currently sending this "packet"; > ThisNode could receive a message, then it is not sending this packet. >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 10] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > IP.DestinationAddress > The IP address of the packet destination. For multicast messages > the IP.DestinationAddress is set to LL-MANET-Routers [RFC5498]. > For unicast messages the IP.DestinationAddress is set to the > NextHopAddress toward the TargetNode. >=20 > MsgHdr.HopLimit > The remaining number of hops this message is allowed to traverse. > If an AODVv2 message within a RFC 5444 packet has exhausted its > hop limit, then it should be removed from the packet. >=20 > UH> This seems to be mixing normative protocol behavior with field > definitions. >=20 > 4.3. RteMsg-specific Protocol Elements >=20 > AODVv2 message types RREQ and RREP are denoted as Routing Messages > (RteMsgs) and used to flood routing information. >=20 > UH> RREPs are not flooded. >=20 > RREQ and RREP have > similar information and function, but have slightly different > handling rules. The main difference between the two messages is that > RREQ messages are generally broadcast to solicit a RREP, and > conversely a RREP is the unicast response to RREQ. RteMsg creation > and handling are described in Section 5.3. >=20 > Unicast AODVv2 RteMsgs (e.g. RREP) unless otherwise specified are > sent with the IP destination set to the Route.NextHopAddress of the > route to the TargetNode. >=20 > A RteMsg REQUIRES the following information in addition to the fields > indicated in Section 4.2: >=20 > UH> REQUIRES is not RFC2110, it's REQUIRED >=20 > AddBlk.TargetNode.Address > The IP address of the message TargetNode. In a RREQ the IP > address of the message TargetNode is the destination address for > which route discovery is being performed. In a RREP the > TargetNode is the RREQ OrigNode address. The TargetNode address > is the first address in a routing message. >=20 > UH> I don't think it's a good idea to mandate order of addresses. > Other extensions to the protocol may add addresses before. It would be > better to associate with an address block TLV. >=20 > AddBlk.OrigNode.Address > The IP address of the originator and its associated prefix length. > In a RREQ the OrigNode is the source's address and prefix. In a > RREP the OrigNode is the RREQ TargetNode's address and prefix for > which a RREP is being generated. This address is the second > address in the message for RREQ. >=20 > UH> Again, mandating address order is dangerous. >=20 > OrigNode.AddTLV.SeqNum > The AODVv2 sequence number of the originator's AODVv2 router. >=20 > UH> Why not use the message sequence number? This will save several > bytes. Or at least a message TLV. >=20 > A RteMsg may optionally include the following information: >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 11] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > TargetNode.AddTLV.SeqNum > The last known AODVv2 sequence number of the TargetNode. >=20 > UH> Using which TLV type? (reference to IANA section) >=20 > AddBlk.AdditionalNode.Address > The IP address of an additional node that can be reached via the > AODVv2 router adding this information. Each > AdditionalNode.Address MUST include its prefix. Each > AdditionalNode.Address MUST also have an associated Node.SeqNum in > the address TLV block. >=20 > UH> Is Node.foo defined before? >=20 > AdditionalNode.AddTLV.SeqNum > The AODVv2 sequence number associated with this routing > information. >=20 > UH> What is AdditionalNode? >=20 > OrigNode.AddTLV.Dist > A metric of the distance to reach the associated OrigNode.Address. > This field is incremented by at least one at each intermediate > AODVv2 router. >=20 > UH> Why not use a message TLV? >=20 > AdditionalNode.AddTLV.Dist > A metric of the distance to reach the associated > AdditionalNode.Address. This field is incremented by at least one > at each intermediate AODVv2 router. >=20 > 4.4. Route Error (RERR)-specific Protocol Elements >=20 > A RERR message is used to flood the information that a route is not > available for one or more particular addresses. >=20 > UH> RERR are mostly sent unicast, not flooded. >=20 > RERR creation and handling are described in Section 5.5. >=20 > A RERR requires the following information in addition to the field > indicated in Section 4.2: >=20 > AddBlk.UnreachableNode.Address > The address of an UnreachableNode and its associated prefix > length. Multiple unreachable addresses may be included in a RERR. >=20 > A Route Error may optionally include the following information: >=20 > UnreachableNode.AddTLV.SeqNum > The last known AODVv2 sequence number of the unreachable node. If > a SeqNum for an address is zero (0) or not included, it is assumed > to be unknown. This case occurs when a node receives a message to > forward to a destination for which it does not have any > information in its routing table. >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 12] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 5. Detailed Operation for the Base Protocol >=20 > 5.1. AODVv2 Sequence Numbers >=20 > AODVv2 sequence numbers allow AODVv2 routers to judge the freshness > of routing information and consequently ensure loop freedom. >=20 > 5.1.1. Maintaining A Node's Own Sequence Number >=20 > AODVv2 requires that each AODVv2 router in the network maintain its > own AODVv2 sequence number (OwnSeqNum). OwnSeqNum a 16-bit unsigned > integer. An AODVv2 router increments its OwnSeqNum under the > circumstances described in Section 5.3. >=20 > Incrementing an OwnSeqNum whose value is the largest largest possible > number representable as a 16-bit unsigned integer (i.e., 65,535), > MUST be set to one (1). In other words, the sequence number after > 65,535 is 1. >=20 > 5.1.2. Actions After OwnSeqNum Loss >=20 > An AODVv2 router SHOULD maintain its own sequence number in > persistent storage. >=20 > If an AODVv2 router's OwnSeqNum is lost, it MUST take certain actions > to avoid creating routing loops. To prevent this possibility after > OwnSeqNum loss an AODVv2 router MUST wait for at least > ROUTE_DELETE_TIMEOUT before fully participating in the AODVv2 routing > protocol. If an AODVv2 protocol message is received during this > waiting period, the AODVv2 router SHOULD perform normal route table > entry updates but MUST NOT transmit or retransmit any AODVv2 RREQ or > RREP messages. If a data packet is received for forwarding to > another destination during this waiting period, the AODVv2 router > MUST transmit a RERR message indicating that this route is not > available and reset its waiting timeout. At the end of the waiting > period the AODVv2 router sets its OwnSeqNum to one (1) and begin > participating. >=20 > The longest a node need wait is ROUTE_SEQNUM_AGE_MAX_TIMEOUT. At the > end of the maximum waiting period a node SHOULD set its OwnSeqNum to > one (1) and begins participating. >=20 > 5.2. AODVv2 Routing Table Operations >=20 > UH> This whole structure is unclear. Where do we come to this? > Wouldn't it be better to start of with message generation/processing > before saying how to update the routing tuples as a consequence to > received messages? >=20 > 5.2.1. Judging Routing Information's Usefulness >=20 > Given a route table entry (Route.SeqNum, Route.Dist, and > Route.Broken) >=20 > UH> A route table entry has more fields in section 4.1 >=20 > and incoming routing information for a particular >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 13] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > destination in a RteMsg (Node.SeqNum, Node.Dist, and RteMsg message > type - RREQ/RREP), the incoming routing information is classified as > follows: >=20 > 1. Stale (Node.SeqNum < Route.SeqNum) > If Node.SeqNum < Route.SeqNum (using signed 16-bit arithmetic) the > incoming information is stale. Using stale routing information is > not allowed, since that might result in routing loops. >=20 > UH> So what should my implementation then? Continue with the next > step? Discard the message? >=20 > 2. Not safe against loops > If Node.SeqNum =3D=3D Route.SeqNum, additional information MUST be > examined. If Route.Dist or Node.Dist is unknown or zero (0), or > if Node.Dist > Route.Dist + 1, then the incoming information is > not guaranteed to prevent routing loops. Using such incoming > routing information is not allowed. The following pseudocode is > offered to indicate the logical condition under which the incoming > information is not guaranteed to protect against loops. >=20 > (Node.SeqNum =3D=3D Route.SeqNum) AND > ((Node.Dist > Route.Dist + 1) OR >=20 > UH> Would cause a null-pointer exception in my implementation if Dist > is not contained in the message. >=20 > (Route.Dist is unknown) OR (Node.Dist is unknown)) >=20 > 3. Offers no improvement > In case of known equal SeqNum, the information is considered worse > than the existing route table information in multiple cases: (case > i) if Node.Dist > Route.Dist (it is a more expensive route) AND > Route.Broken =3D=3D false; (case ii) if Node.Dist =3D=3D Route.Dist = (equal > distance route) AND Route.Broken =3D=3D false AND this RteMsg is a > RREQ. Such RREQs offer no improvement and SHOULD NOT be > retransmitted. Updating route table entries using such incoming > routing information is not allowed. >=20 > ((Node.SeqNum =3D=3D Route.SeqNum) AND > (((Node.Dist > Route.Dist) AND (Route.Broken =3D=3D false)) OR > ((Node.Dist =3D=3D Route.Dist) AND > (RteMsg is RREQ) AND (Route.Broken =3D=3D false)))) >=20 > 4. Offers improvement > Incoming routing information that does not match any of the above > criteria is loop-free and better than the existing routing table > information. We provide the following pseudo-code to determine > whether incoming routing information should be used to update an > existing route table entry. >=20 > (/* signed 16-bit arithmetic */ Node.SeqNum - Route.SeqNum > 0) OR > ((Node.SeqNum =3D=3D Route.SeqNum) AND > [(Node.Dist < Route.Dist) OR > ((Route.Broken =3D=3D true) AND (Node.Dist <=3D Route.Dist + 1))= OR >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 14] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > ((RteMsg is RREP) AND (Node.Dist =3D=3D Route.Dist)] >=20 > 5.2.2. Creating or Updating Route Table Entries >=20 > Each route table entry is populated with the following information: >=20 > UH> Why "each" entry? When does this happen? It seems this only sets > the route to the previous hop; what happens with a route to the > originator? What happens if a route already exists and is only > updated? How are both forward and reverse routes updated? >=20 > 1. the Route.Address is set to Node.Address, >=20 > 2. the Route.Prefix is set to the Node.Prefix. >=20 > 3. the Route.SeqNum is set to the Node.SeqNum, >=20 > 4. the Route.NextHopAddress is set to the IP.SourceAddress (i.e., an > address of the node that last transmitted the RteMsg packet) >=20 > 5. the Route.NextHopInterface is set to the interface on which the > incoming AODVv2 packet was received, >=20 > 6. the Route.Broken flag is set to false, >=20 > 7. if known, the Route.Dist is set to the Node.Dist, >=20 > The timer for the minimum delete timeout (ROUTE_AGE_MIN) is set to > ROUTE_AGE_MIN_TIMEOUT. The timer for the maximum delete timeout > (ROUTE_SEQNUM_AGE_MAX) is set to Node.AddTLV.VALIDITY_TIME [RFC5497] > if included; otherwise, ROUTE_SEQNUM_AGE_MAX is set to > ROUTE_SEQNUM_AGE_MAX_TIMEOUT. The usage of these timers and others > are described in Section 5.2.3. >=20 > UH> I don't understand how a sequence number can expire. Also, in > section 4.1 there was no mention of the VALIDITY_TIME Tlv in a > message. What happens if it is not contained? >=20 > With these assignments to the route table entry, a route has been > created and the Route.Forwarding flag set. Afterward, the route can > be used to send any buffered data packets and to forward any incoming > data packets for Route.Address. This route also fulfills any > outstanding route discovery (RREQ) attempts for Node.Address. >=20 > 5.2.3. Route Table Entry Timeouts >=20 > 5.2.3.1. Minimum Delete Timeout (ROUTE_AGE_MIN) >=20 > When an AODVv2 router transmits a RteMsg, other AODVv2 routers expect > the transmitting AODVv2 router to have a forwarding route to the > RteMsg originator. A route table entry SHOULD be kept in the route > table for at least ROUTE_AGE_MIN after it has been updated. Failure > to maintain the route table entry might result in lost messages/ > packets, or several duplicate messages. >=20 > After the ROUTE_AGE_MIN timeout a route can safely be deleted. >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 15] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 5.2.3.2. Maximum Sequence Number Delete Timeout (ROUTE_SEQNUM_AGE_MAX) >=20 > Sequence number information for route table entries is time > sensitive, and MUST be deleted after a time in order to ensure loop- > free routing. >=20 > After the ROUTE_SEQNUM_AGE_MAX timeout a route's sequence number > information MUST be discarded. >=20 > UH> What does it mean to discard a sequence number information? To set > it to zero in the route entry? What are the relationships between > ROUTE_SEQNUM_AGE_MUX and ROUTE_AGE_MIN? (can one be smaller than the > other) >=20 > 5.2.3.3. Recently Used Timeout (ROUTE_USED) >=20 > When a route is used to forward data packets, this timer is set to > expire after ROUTE_USED_TIMEOUT, as discussed in Section 5.5.2. >=20 > If a route has not been used recently, then a timer for ROUTE_DELETE > is set to ROUTE_DELETE_TIMEOUT. >=20 > 5.2.3.4. Delete Information Timeout (ROUTE_DELETE) >=20 > As time progresses the likelihood that old routing information is > useful decreases, especially if the network nodes are mobile. > Therefore, old information SHOULD be deleted. >=20 > After the ROUTE_DELETE timeout if a forwarding route exists it SHOULD > be removed, and the routing table entry SHOULD also be deleted. >=20 > UH> There are quite a few timers, which is confusing. What happens if > one timer fires before the other? Do we really need that many timers? >=20 > 5.3. Routing Messages >=20 > 5.3.1. RREQ Creation >=20 > Before an AODVv2 router creates a RREQ it SHOULD increment its > OwnSeqNum by one (1) according to the rules specified in Section 5.1. >=20 > UH> Why not MUST? What happens if one does not increase it. In > general, there are many SHOULDs in the document, which probably should > be MUSTs. >=20 > Incrementing OwnSeqNum will ensure that all nodes with existing > routing information will consider this new information preferable to > existing routing table information. If the sequence number is not > incremented, certain AODVv2 routers might not consider this > information preferable, if they have existing better routing > information. >=20 > First, ThisNode adds the AddBlk.TargetNode.Address to the RREQ; the > unicast IP Destination Address for which a forwarding route does not > exist. >=20 > If a previous value of the TargetNode.SeqNum is known (from a routing > table entry using longest-prefix matching), it SHOULD be placed in > TargetNode.AddTLV.SeqNum in all but the last RREQ attempt. If a > TargetNode.SeqNum is not included, it is assumed to be unknown by > handling nodes. This operation ensures that no intermediate AODVv2 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 16] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > routers reply, and ensures that the TargetNode's AODVv2 router > increments its sequence number. >=20 > Next, ThisNode adds AddBlk.OrigNode.Address, its prefix, and the > OrigNode.AddTLV.SeqNum (OwnSeqNum) to the RteMsg. >=20 > The OrigNode.Address is the address of the source for which this > AODVv2 router is initiating this route discovery. The > OrigNode.Address MUST be a unicast address. This information will be > used by nodes to create a route toward the OrigNode, enabling > delivery of a RREP, and eventually used for proper forwarding of data > packets. >=20 > If OrigNode.Dist is included it is set to a number, greater than zero > (0), representing the distance between OrigNode and ThisNode. >=20 > The MsgHdr.HopLimit SHOULD be set to MSG_HOPLIMIT. >=20 > UH> Why SHOULD? >=20 > 5.3.2. RREP Creation >=20 > First, the AddBlk.TargetNode.Address is added to the RREP. The > TargetNode is the ultimate destination of this RREP; the RREQ > OrigNode.Address. >=20 > Next, AddBlk.OrigNode.Address and prefix are added to the RREP. The > AddBlk.OrigNode.Address is the RREQ TargetNode.Address. The > AddBlk.OrigNode.Address MUST be a unicast IP address. ThisNode > SHOULD advertise the largest known prefix containing > AddBlk.OrigNode.Address. >=20 > When the RteMsg TargetNode's AODVv2 router creates a RREP, if the > TargetNode.SeqNum was not included in the RREQ, ThisNode MUST > increment its OwnSeqNum by one (1) according to the rules specified > in Section 5.1. >=20 > If TargetNode.SeqNum was included in the RteMsg and TargetNode.SeqNum > - OwnSeqNum < 0 (using signed 16-bit arithmetic), OwnSeqNum SHOULD be > incremented by one (1) according to the rules specified in > Section 5.1. >=20 > If TargetNode.SeqNum is included in the RteMsg and TargetNode.SeqNum > =3D=3D OwnSeqNum (using signed 16-bit arithmetic) and OrigNode.Dist wil= l > not be included in the RREP being generated, OwnSeqNum SHOULD be > incremented by one (1) according to the rules specified in > Section 5.1. >=20 > If OwnSeqNum is not incremented the routing information might be > considered stale. In this case, the RREP might not reach the RREP >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 17] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > Target. >=20 > After any of the sequence number operations above, the RREP > OrigNode.AddTLV.SeqNum (OwnSeqNum) MUST also be added to the RREP. >=20 > Other AddTLVs in the RREP for the OrigNode and TargetNode SHOULD be > included and set accordingly. If OrigNode.Dist is included it is set > to a number greater than zero (0) and less than or equal to 254. The > Distance value will influence judgment of the routing information > (Section 5.2.1) against known information at other AODVv2 routers > that handle this RteMsg. >=20 > The MsgHdr.HopLimit is set to MSG_HOPLIMIT. >=20 > The IP.DestinationAddress for RREP is set to the IP address of the > Route.NextHopAddress for the route to the RREP TargetNode. >=20 > 5.3.3. RteMsg Handling >=20 > UH> Very difficult to parse this section. Not much RFC2119 language. >=20 > UH> Is there any check for invalid messages (similar to OLSRv2/NHDP?) > External mechanisms should be allowed to add reasons to reject a > message as invalid, e.g. a security mechanism. >=20 > First, ThisNode examines the RteMsg to ensure that it contains the > required information: MsgHdr.HopLimit, AddBlk.TargetNode.Address, > AddBlk.OrigNode.Address, and OrigNode.AddTLV.SeqNum. If the required > information does not exist, the message is discarded and further > processing stopped. >=20 > ThisNode MUST only handle AODVv2 messages from adjacent routers. >=20 > UH> What does that mean? >=20 > ThisNode checks if the AddBlk.OrigNode.Address is a valid routable > unicast address. >=20 > UH> How? >=20 > If not, the message is ignored and further > processing stopped. >=20 > ThisNode also checks whether AddBlk.OrigNode.Address is an address > handled by this AODVv2 router. >=20 > UH> How? >=20 > If this node is the originating > AODVv2 router, the RteMsg is dropped. >=20 > UH> Why not do this further above, before doing all the other checks? >=20 > ThisNode checks if the AddBlk.TargetNode.Address is a valid routable > unicast address. If the address is not a valid unicast address, the > message is discarded and further processing stopped. >=20 > Next, ThisNode checks whether its routing table has an entry to the > AddBlk.OrigNode.Address using longest-prefix matching [RFC1812]. >=20 > UH> RFC1812 is IPv4 only. >=20 > If > a route with a valid Route.SeqNum does not exist, >=20 > UH> What is a "valid" sequence number? >=20 > then the new > routing information is used to create a new route table entry is > created >=20 > UH> to "create" ... is "created" >=20 > and updated as described in Section 5.2.2. >=20 > UH> This jumping back is difficult to parse. >=20 > If a route table > entry does exists and it has a known Route.SeqNum, the incoming > routing information is compared with the route table entry following > the procedure described in Section 5.2.1. If the incoming routing > information is considered preferable, the route table entry is >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 18] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > updated as described in Section 5.2.2. >=20 > At this point, if the routing information for the OrigNode was not > preferable then this RteMsg SHOULD be discarded and no further > processing of this message SHOULD be performed. >=20 > UH> Why SHOULD? Why not MUST? >=20 > If the TargetNode is a router client of ThisNode this RteMsg is a > RREQ, then ThisNode responds with a RREP to the RREQ OrigNode (the > new RREP's TargetNode). The procedure for issuing a new RREP is > described in Section 5.3.2. Afterwards, ThisNode need not perform > any more operations for the RteMsg being processed. >=20 > As an alternative to issuing a RREP, ThisNode MAY choose to > distribute routing information about ThisNode (the RREQ TargetNode) > more widely. That is, ThisNode MAY optionally perform a route > discovery by issuing a RREQ with ThisNode listed as the TargetNode, > using the procedure in Section 5.3.1. At this point, ThisNode need > not perform any more operations for the RteMsg being processed. >=20 > UH> I don't understand the last paragraph. Is this some remainder of > intermediate route reply? In which conditions should a router send a > RREQ instead of a RREP? >=20 >=20 > For each address (except the TargetNode) in the RteMsg that includes > AddTLV.Dist information, the AddTLV.Dist information is incremented > by at least one (1). >=20 > UH> By how much then? >=20 > The updated Distance value will influence > judgment of the routing information (Section 5.2.1) against known > information at other AODVv2 routers that handle this RteMsg. >=20 > If the resulting Distance value for the OrigNode is greater than 254, > the message is discarded. If the resulting Distance value for > another node is greater than 254, >=20 > UH> Which other node? >=20 > the associated address and its > information are removed from the RteMsg. >=20 > UH> That makes end-to-end security impossible. >=20 > If the MsgHdr.HopLimit is > equal to one (1), then the message is discarded. Otherwise, the > MsgHdr.HopLimit is decremented by one (1). >=20 > If ThisNode is not the TargetNode, AND this RteMsg is a RREQ, then > the current RteMsg (as altered by the procedure defined above) SHOULD > be sent to the IP multicast address LL-MANET-Routers [RFC5498]. If > the RREQ is unicast, the IP.DestinationAddress is set to the > NextHopAddress. >=20 > UH> The unicast RREQ mechanism is not really explained anywhere. Where > is the nexthopaddress acquired from? >=20 >=20 > If ThisNode is not the TargetNode, AND this RteMsg is a RREP, then > the current RteMsg is sent to the Route.NextHopAddress for the RREP's > TargetNode.Address. If no forwarding route exists to > TargetNode.Address, then a RERR SHOULD be issued to the OrigNode of > the RREP. >=20 > By sending the updated RteMsg, ThisNode advertises that it will route > for addresses contained in the outgoing RteMsg based on the > information enclosed. ThisNode MAY choose not to send the RteMsg, > though not resending this RteMsg could decrease connectivity in the >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 19] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > network or result in a non-shortest distance path. >=20 > The circumstances under which ThisNode might choose to not re-issue a > RteMsg are not specified in this document. Some examples might > include the following: >=20 > o if ThisNode does not want to advertise routing for the contained > addresses because it is already heavily loaded >=20 > o if ThisNode has already issued identical routing information (e.g. > ThisNode had recently issued a RteMsg with the same distance) >=20 > o if ThisNode is low on energy and does not want to expend energy > for protocol message sending or packet forwarding >=20 > 5.4. Route Discovery >=20 > When an AODVv2 router needs to forward a data packet and it does not > have a forwarding route to the destination address, it sends a RREQ > (described in Section 5.3.1) to discover a route to the particular > destination (TargetNode). >=20 > After issuing a RREQ, the AODVv2 router (OrigNode) waits for a RREP > indicating the next hop for a route to the TargetNode. If a route is > not created within RREQ_WAIT_TIME, OrigNode may again try to discover > a route by issuing another RREQ using the procedure defined in > Section 5.3.1 again. Route discovery SHOULD be considered to have > failed after DISCOVERY_ATTEMPTS_MAX and the corresponding wait time > for a response to the final RREQ. >=20 > To reduce congestion in a network, repeated attempts at route > discovery for a particular TargetNode SHOULD utilize an binary > exponential backoff. >=20 > Data packets awaiting a route SHOULD be buffered by the source's > AODVv2 router. This buffer SHOULD have a fixed limited size > (BUFFER_SIZE_PACKETS or BUFFER_SIZE_BYTES). Determining which > packets to discard first is a matter of policy at each AODVv2 router; > in the absence of policy constraints, by default older data packets > SHOULD be discarded first. Buffering of data packets can have both > positive and negative effects, and therefore settings for buffering > (BUFFER_DURING_DISCOVERY) SHOULD be administratively configurable. > Nodes without sufficient memory available for buffering may be > configured with BUFFER_DURING_DISCOVERY =3D FALSE; this will affect the > latency required for launching TCP applications to new destinations. >=20 > UH> I am against including this buffering mechanism in this document. > This is a mixture of the routing plane and the data plane. There are > other forwarding mechanisms that would be affected by this > specification. >=20 > If a route discovery attempt has failed (i.e. an attempt or multiple > attempts have been made without receiving a RREP) to find a route to >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 20] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > the TargetNode, any data packets buffered for the corresponding > TargetNode MUST BE dropped and a Destination Unreachable ICMP message > (Type 3) SHOULD be delivered to the source of the data packet. The > code for the ICMP message is 1 (Host unreachable error). If the > AODVv2 router is not the source (OrigNode), then the ICMP is sent > over the interface from which the source sent the packet to the > AODVv2 router. >=20 > 5.5. Route Maintenance >=20 > A RERR SHOULD be issued if a data packet is to be forwarded and it > cannot be delivered to the next-hop because no forwarding route for > the IP.DestinationAddress exists; RERR generation is described in > Section 5.5.3. >=20 > Upon this condition, an ICMP Destination Unreachable message SHOULD > NOT be generated unless this router is responsible for the > IP.DestinationAddress and that IP.DestinationAddress is known to be > unreachable. >=20 > UH> How is that generated (with which content)? >=20 > In addition to inability to forward a data packet, a RERR SHOULD be > issued immediately after detecting a broken link (see Section 5.5.1) > of a forwarding route to quickly notify AODVv2 routers that certain > routes are no longer available. If a newly unavailable route has not > been used recently (indicated by ROUTE_USED), the RERR SHOULD NOT be > generated. >=20 > UH> SHOULD NOT or MUST NOT? What are the consequences of doing so when > using SHOULD NOT? >=20 > 5.5.1. Active Next-hop Router Adjacency Monitoring >=20 > Nodes SHOULD monitor connectivity to adjacent next-hop AODVv2 routers > on forwarding routes. This monitoring can be accomplished by one or > several mechanisms, including: >=20 > o Neighborhood discovery [RFC6130] >=20 > o Route timeout >=20 > o Lower layer trigger that a neighboring router is no longer > reachable >=20 > o Other monitoring mechanisms or heuristics >=20 > Upon determining that a next-hop AODVv2 router has become > unreachable, ThisNode MUST remove the affected forwarding routes > (those using the unreachable next-hop) and unset the Route.Forwarding > flag. ThisNode also flags the associated routes in AODVv2's routing > table as Broken. For each broken route the timer for ROUTE_DELETE is > set to ROUTE_DELETE_TIMEOUT. >=20 > UH> How can the flags be set if the routes are removed before? >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 21] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 5.5.2. Updating Route Lifetimes During Packet Forwarding >=20 > To avoid removing the forwarding route to reach an IP.SourceAddress, > ThisNode SHOULD set the "ROUTE_USED" timeout to the value > ROUTE_USED_TIMEOUT for the route to that IP.SourceAddress upon > receiving a data packet or an AODVv2 message. If the timer for > ROUTE_DELETE is set, that timer is removed. The Route.Broken flag is > unset. >=20 > To avoid removing the forwarding route to the IP.DestinationAddress > that is being used, ThisNode SHOULD set the "ROUTE_USED" timeout to > the value ROUTE_USED_TIMEOUT for the route to the > IP.DestinationAddress upon sending a data packet or an AODVv2 > message. If the timer for ROUTE_DELETE is set, it is removed. The > Route.Broken flag is unset. >=20 > 5.5.3. RERR Generation >=20 > When an AODVv2 router receives a packet (from PrevHopAddress), and > the router (ThisNode) does not have a route available for the > destination of the packet, ThisNode uses an RERR message is used to >=20 > UH> "uses".. ."is used" >=20 > inform one or more neighboring AODVv2 routers that its route to the > packet destination is no longer available. >=20 > When ThisNode creates a new RERR, the address of the first > UnreachableNode (IP.DestinationAddress from a data packet or > RREP.TargetNode.Address) is inserted into an Address Block > AddBlk.UnreachableNode.Address. If a prefix is known for the > UnreachableNode.Address, it SHOULD be included. Otherwise, the > UnreachableNode.Address is assumed to be a host address with a full > length prefix. If a value for the UnreachableNode's SeqNum > (UnreachableNode.AddTLV.SeqNum) is known, it SHOULD be placed in the > RERR. The MsgHdr.HopLimit SHOULD be set to MSG_HOPLIMIT. >=20 > If SeqNum information is not known or not included in the RERR, all > nodes handling the RERR will assume their routing information > associated with the UnreachableNode is no longer valid and flag those > routes as broken. >=20 > A RERR MAY be sent to the multicast address LL-MANET-Routers > [RFC5498], thus notifying all nearby AODVv2 routers that might depend > on the now broken link. If the RERR is unicast, the > IP.DestinationAddress is set to the PrevHopAddress. >=20 > After sending the RERR, ThisNode SHOULD discard the packet or message >=20 > UH> Why packet or message? Is this data traffic or control traffic? >=20 > that triggered generation of the RERR. >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 22] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 5.5.4. RERR Handling >=20 > First, ThisNode examines the incoming RERR to ensure that it contains > MsgHdr.HopLimit and AddBlk.UnreachableNode.Address. If the required > information does not exist, the incoming RERR message is discarded > and further processing stopped. >=20 > When an AODVv2 router handles a RERR, it examines the information for > each UnreachableNode. >=20 > UH> How exactly does it do that? Which information is used, and how? >=20 > The AODVv2 router removes the forwarding > route, unsets the Route.Forwarding flag, sets the Route.Broken flag, > and the timer for ROUTE_DELETE is set to ROUTE_DELETE_TIMEOUT for > each UnreachableNode.Address found using longest prefix matching that > meets all of the following conditions: >=20 > 1. The UnreachableNode.Address is a routable unicast address. >=20 > 2. The Route.NextHopAddress is the same as the RERR > IP.SourceAddress. >=20 > 3. The Route.NextHopInterface is the same as the interface on which > the RERR was received. >=20 > 4. The Route.SeqNum is zero (0), unknown, OR the > UnreachableNode.SeqNum is zero (0), unknown, OR Route.SeqNum - > UnreachableNode.SeqNum <=3D 0 (using signed 16-bit arithmetic). >=20 > If Route.SeqNum is zero (0) or unknown and UnreachableNode.SeqNum > exists in the RERR and is not zero (0), then Route.SeqNum SHOULD be > set to UnreachableNode.SeqNum. Setting Route.SeqNum can reduce > future RERR handling and forwarding. >=20 > UH> How? >=20 > Each UnreachableNode that did not result in marking a route table > entry as broken route is removed from the RERR, since propagation of > such information will not result in any benefit. >=20 > UH> Makes end-to-end security impossible. >=20 > Each UnreachableNode that did indicate a broken route SHOULD remain > in the RERR. >=20 > If any UnreachableNode was removed, all other information (AddTLVs) > associated with the UnreachableNode address(es) MUST also be removed. >=20 > If Route.SeqNum is known and an UnreachableNode.SeqNum is not > included in the RERR, then Route.SeqNum (i.e. > UnreachableNode.SeqNum) MAY be included with the RERR. Including > UnreachableNode.SeqNum can reduce future RERR handling and > forwarding. >=20 > If no UnreachableNode addresses remain in the RERR, or if the >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 23] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > MsgHdr.HopLimit is equal to one (1), then the RERR MUST be discarded. >=20 > Otherwise, the MsgHdr.HopLimit is decremented by one (1). The RERR > SHOULD be sent to the multicast address LL-MANET-Routers [RFC5498]. > Alternatively, if the RERR is unicast, the IP.DestinationAddress is > set to the PrevHopAddress. >=20 > 5.6. Unknown Message and TLV Types >=20 > If a message with an unknown type is received, the message is > ignored. >=20 > For handling of messages that contain unknown TLV types, ignore the > information for processing, preserve it unmodified for forwarding. >=20 > 5.7. Advertising Network Addresses >=20 > AODVv2 routers MAY specify a prefix length for each advertised > address. Any nodes (other than the advertising AODVv2 router) within > the advertised prefix MUST NOT participate in the AODVv2 protocol > directly. For example, advertising 192.0.2.1 with a prefix length of > 24 indicates that all nodes with the matching 192.0.2.X are reachable > through this AODVv2 router. An AODVv2 router MUST NOT advertise > network addresses unless it can guarantee its ability for forwarding > packets to any host address within the address range of the > corresponding network. >=20 > 5.8. Simple Internet Attachment >=20 > Simple Internet attachment consists of a stub (i.e., non-transit) > network of AODVv2 routers connected to the Internet via a single > Internet AODVv2 router (IAR). >=20 > UH> Why a new defition? Is that not just a border router? Also, it > does not matter if it's connected to the "Internet", just if it's a > border gateway with two interfaces, connecting two different routing > domains (which could still not be connected to the Internet). >=20 > As in any Internet-attached network, >=20 > UH> What's an Internet-attached network? Is that defined in an IP > architecture RFC? >=20 > AODVv2 routers, and hosts behind > these routers, wishing to be reachable from hosts on the Internet > MUST have IP addresses within the IAR's routable and topologically > correct prefix (e.g. 192.0.2.0/24). >=20 > The IAR is responsible for generating RREQ to find nodes within the > AODVv2 Region on behalf of nodes on the Internet, as well as > responding to route requests from the AODVv2 region on behalf of the > nodes on the Internet. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 24] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > /--------------------------\ > / Internet \ > \ / > \------------+-------------/ > | > Routable & | > Topologically | > Correct | > Prefix | > +-----+--------+ > | Internet | > /------| AODVv2 |-------\ > / | Router | \ > / |192.0.2.1/32 | \ > | |Responsible | | > | | for | | > | |AODVv2 Region | | > | |192.0.2.0/24 | | > | +--------------+ | > | +----------------+ | > | | AODVv2 Router | | > | | 192.0.2.2/32 | | > | +----------------+ | > | +----------------+ | > | | AODVv2 Router | | > | | 192.0.2.3/32 | | > \ +----------------+ / > \ / > \-----------------------------/ >=20 > Figure 1: Simple Internet Attachment Example >=20 > When an AODVv2 router within the AODVv2 Region wants to discover a > route to a node on the Internet, it uses the normal AODVv2 route > discovery for that IP Destination Address. The IAR MUST respond to > RREQ on behalf of the Internet destination. >=20 > UH> How? Where is that specified? >=20 > When a packet from a node on the Internet destined for a node in the > AODVv2 region reaches the IAR, if the IAR does not have a route to > that destination it will perform normal AODVv2 route discovery for > that destination. >=20 > UH> How? With which originator address, target etc? Where are RERRs / > ICMP unreachable sent to in case of a broken data traffic? >=20 > 5.9. Multiple Interfaces >=20 > AODVv2 may be used with multiple interfaces; therefore, the > particular interface over which packets arrive MUST be known whenever > a packet is received. Whenever a new route is created, the interface > through which the Route.Address can be reached is also recorded in >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 25] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > the route table entry. >=20 > When multiple interfaces are available, a node transmitting a > multicast packet with IP.DestinationAddress set to LL-MANET-Routers > SHOULD send the packet on all interfaces that have been configured > for AODVv2 operation. >=20 > Similarly, AODVv2 routers SHOULD subscribe to LL-MANET-Routers on all > their AODVv2 interfaces. >=20 > 5.10. AODVv2 Control Packet/Message Generation Limits >=20 > UH> There is no AODVv2 Control Packet. >=20 >=20 > To ensure predictable messaging overhead, AODVv2 router's rate of > packet/message generation SHOULD be limited. The rate and algorithm > for limiting messages (CONTROL_TRAFFIC_LIMITS) is left to the > implementor and should be administratively configurable. AODVv2 > messages SHOULD be discarded in the following order of preference: > RREQ, RREP, and finally RERR. >=20 > 5.11. Optional Features >=20 > Several optional features of AODVv2, and associated with AODV, are > not required by minimal implementations. These features are expected > to be useful in networks with greater mobility, or larger node > populations, or requiring shorter latency for application launches. > The optional features are as follows: >=20 > o Expanding Rings Multicast >=20 > o Intermediate RREPs (iRREPs): Without iRREP, only the destination > can respond to a RREQ. >=20 > o Precursor lists. >=20 > o Reporting Multiple Unreachable Nodes. An RERR message can carry > more than one Unreachable Destination node for cases when a single > link breakage causes multiple destinations to become unreachable > from an intermediate router. >=20 > UH> This seems to be different from section 5.11.6, which talks about > adding additional information to a RREQ. >=20 > UH> None of the extensions is sufficiently specified, and it is > unclear how it would affect interoperability if some nodes support the > extension and others don't. >=20 > 5.11.1. Expanding Rings Multicast >=20 > For multicast RREQ, the MsgHdr.HopLimit MAY be set in accordance with > an expanding ring search as described in [RFC3561] to limit the RREQ > propagation to a subset of the local network and possibly reduce > route discovery overhead. >=20 >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 26] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 5.11.2. Intermediate RREP >=20 > This specification has been published as a separate Internet Draft . >=20 > 5.11.3. Precursor Notification >=20 > The Dynamic MANET On-demand (AODVv2) routing protocol is intended for > use by mobile routers in wireless, multihop networks. AODVv2 > determines unicast routes among AODVv2 routers within the network in > an on-demand fashion, offering on-demand convergence in dynamic > topologies. This document specifies a simple modification to AODVv2 > (and possibly other reactive routing protocols) enabling faster > notifications to known sources of traffic upon determination that a > route for such traffic's destination has become Broken. >=20 > 5.11.3.1. Overview >=20 > If an AODVv2 router, while attempting to forward a packet to a > particular destination, determines that the next hop (one of its > neighbors) is no longer reachable, AODVv2 specifies that the router > notify the source of that packet that the route to the destination > has become Broken. In the existing specification, the notification > to the source is a unicast RERR message. >=20 > However, in many cases there will be several sources of of traffic > for that particular destination. In fact, the broken link for the > next hop in question may be a path component of numerous other routes > for other destinations, and in that case the node detecting the > broken link must mark as Broken multiple routes, one for each of the > newly unreachable destinations. Each route that uses the newly > broken link is no longer valid. For each such route, every node > along the way from the source using that route, to the node detecting > the broken link, is known as a "precursor" for the broken next hop. > All the precursors for a particular next hop should be notified about > the change in status of their route to a destination downstream from > the broken next hop. >=20 > 5.11.3.2. Precursor Notification >=20 > During normal operation, each node wishing to enable the improved > notification for precursors of any links to its next hop neighbors > has to keep track of the precursors. This is done by maintaining a > precursor table and updating the table whenever the node initiates or > relays a RREP message back to a node originating a RREQ message. > When the node transmits the RREP message, it is implicitly agreeing > to forward traffic from the RREQ originator towards the RREP > originator (i.e., along the next hop link to the neighbor from which > the RREP was received). The "other" next hop, which is the neighbor >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 27] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > along the way towards the originator of the RREQ message, is then the > next precursor for the route towards the destination requested by the > RREQ. >=20 > Each such precursor should then be recorded as a precursor for a > route along the next hop. The same next hop may be in service for > routes to multiple destinations, but for precursor list management it > is only important to keep track of precursors for a particular next > hop; the exact destination does not matter, only the particular next > hop towards the destination(s). >=20 > When a node observes that one of its neighbors is no longer > reachable, the node first checks to see whether the link to that > neighbor is a next hop for any more distant destination in its route > table. If not, then the node simply updates any relevant neighorhood > information and takes no further action. >=20 > Otherwise, for all destinations no longer reachable because of the > changed status of the next hop, the node first checks to see whether > the link to that neighbor is a next hop for any more distant > destination in its route table. If not, then the node simply updates > any relevant neighorhood information and takes no further action. >=20 > For each precursor of the next hop, the node MAY notify the precursor > in one of three ways: >=20 > o unicast RERR >=20 > o broadcast RERR >=20 > o multicast RERR to multicast group PRECURSOR_RERR_RECEIVERS >=20 > UH> I don't see an allocation request in the IANA section. >=20 >=20 > Each precursor then MAY execute the same procedure until all affected > traffic sources have received the RERR route maintenance information. >=20 > When a precursor receives a unicast RERR, the precursor MUST further > unicast the RERR message towards the affected traffic source. If a > precursor receives a broadcast or multicast RERR, the precursor MAY > further retransmit the RERR towards the traffic source. >=20 > 5.11.4. Reporting Multiple Unreachable Nodes >=20 > 5.11.5. Message Aggregation >=20 > The aggregation of multiple messages into a packet is not specified > in this document, but if aggregation does occur the IP.SourceAddress > and IP.DestinationAddress of all contained messages MUST be the same. >=20 > UH> That is part of the RFC5444 multiplexer and not of AODVv2. >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 28] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > Implementations MAY choose to temporarily delay transmission of > messages for the purpose of aggregation (into a single packet) or to > improve performance by using jitter [RFC5148]. >=20 > 5.11.6. Adding Additional Routing Information to a RteMsg >=20 > UH> This section is unclear to me. What is the purpose? What kind of > information would you add? How can this interoperate? By adding > information en-route, end-to-end security is not possible. >=20 > DSR [RFC4728] includes source routes as part of the data of its RREPs > and RREQs. Doign so allows additional topology information to be > flooded along with the RteMsg, and potentially allows updating for > stale routing information at MANET routers along new paths between > source and destination. To maintain this functionality, AODVv2 has > defined a somewhat more general method that enables inclusion of > source routes in RteMsgs. >=20 > Appending routing information can alleviate route discovery attempts > to the nodes whose information is included, if other AODVv2 routers > use this information to update their routing tables. >=20 > Note that, since the initial merger of DSR with AODV to create this > protocol, further experimentation has shown that including the > additional routing information is not always helpful. Sometimes it > seems to help, and other times it seems to reduct overall > performance. >=20 > AODVv2 routers can append routing information to a RteMsg. This is > controllable by an option (APPEND_INFORMATION) which SHOULD be > administratively configurable or controlled according to the traffic > characteristics of the network. >=20 > Prior to appending an address controlled by this AODVv2 router to a > RteMsg, ThisNode MAY increment its OwnSeqNum as defined in > Section 5.1. If OwnSeqNum is not incremented the appended routing > information might not be considered preferable, when received by > nodes with existing routing information. Incrementation of the > sequence number when appending information to a RteMsg in transit > (APPEND_INFORMATION_SEQNUM) SHOULD be administratively configurable. > Note that, during handling of this RteMsg OwnSeqNum may have already > been incremented; and in this case OwnSeqNum need not be incremented > again. >=20 > If an address controlled by this AODVv2 router includes > ThisNode.Dist, it is set to a number greater than zero (0). >=20 > For added addresses (and their prefixes) not controlled by this > AODVv2 router, Route.Dist can be included if known. >=20 > The VALIDITY_TIME of routing information for appended address(es) > MUST be included, to inform routers about when to delete this >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 29] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > information. The VALIDITY_TIME TLV is defined in Section 5.13.3. >=20 > Additional information (e.g. SeqNum and Dist) about any appended > address(es) SHOULD be included. >=20 > Note that the routing information about the TargetNode MUST NOT be > added. Also, duplicate address entries SHOULD NOT be added. > Instead, only the best routing information (Section 5.2.1) for a > particular address SHOULD be included. >=20 > Intermediate nodes obey the following procedures when processing > AddBlk.AdditionalNode.Address information and other associated TLVs > that are included with a RteMsg. For each address (except the > TargetNode) in the RteMsg that includes AddTLV.Dist information, the > AddTLV.Dist information MUST be incremented. If the resulting > Distance value for the OrigNode is greater than 254, the message is > discarded. If the resulting Distance value for another node is > greater than 254, the associated address and its information are > removed from the RteMsg. >=20 > After handling the OrigNode's routing information, then each address > that is not the TargetNode MAY be considered for creating and > updating routes. Creating and updating routes to other nodes can > eliminate RREQ for those IP destinations, in the event that data > needs to be forwarded to the IP destination(s) now or in the near > future. >=20 > For each of the additional addresses considered, ThisNode first > checks that the address is a routable unicast address. If the > address is not a unicast address, then the address and all related > information MUST be removed. >=20 > If the routing table does not have a matching route with a known > Route.SeqNum for this additional address using longest-prefix > matching, then a route MAY be created and updated as described in > Section 5.2.2. If a route table entry exists with a known > Route.SeqNum, the incoming routing information is compared with the > route table entry following the procedure described in Section 5.2.1. > If the incoming routing information is used, the route table entry > SHOULD be updated as described in Section 5.2.2. >=20 > If the routing information for an AdditionalNode.Address is not used, > then it is removed from the RteMsg. >=20 > 5.12. Administratively Configured Parameters and Timer Values >=20 > AODVv2 contains several parameters which MUST be administratively > configured. The list of these follows: >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 30] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > Required Administratively Configured Parameters >=20 > +------------------------+------------------------------------------+ > | Name | Description | > +------------------------+------------------------------------------+ > | RESPONSIBLE_ADDRESSES | List of addresses or routing prefixes, | > | | for which this AODVv2 router is | > | | responsible. If, RESPONSIBLE_ADDRESSES | > | | is zero, this AODVv2 router is only | > | | responsible for its own addresses. | > | AODVv2_INTERFACES | List of the interfaces participating in | > | | AODVv2 routing protocol. | > +------------------------+------------------------------------------+ >=20 > Table 2 >=20 > AODVv2 contains a number of timers. The default timing parameter > values follow: >=20 > Default Timing Parameter Values >=20 > +------------------------------+-------------------+ > | Name | Value | > +------------------------------+-------------------+ > | ROUTE_TIMEOUT | 5 seconds | > | ROUTE_AGE_MIN_TIMEOUT | 1 second | > | ROUTE_SEQNUM_AGE_MAX_TIMEOUT | 600 seconds | > | ROUTE_USED_TIMEOUT | ROUTE_TIMEOUT | > | ROUTE_DELETE_TIMEOUT | 2 * ROUTE_TIMEOUT | > | ROUTE_RREQ_WAIT_TIME | 2 seconds | > | UNICAST_MESSAGE_SENT_TIMEOUT | 1 second | >=20 > UH> UNICAST_MESSAGE_SENT_TIMEOUT is never used in this specification >=20 > +------------------------------+-------------------+ >=20 > Table 3 >=20 > The above timing parameter values work well for small and medium > well-connected networks with moderate topology changes. >=20 > UH> That also depends on the traffic patterns, on the lossy-ness of > the links, on the density of the routers etc. >=20 > The timing parameters SHOULD be administratively configurable for the > network where AODVv2 is used. Ideally, for networks with frequent > topology changes the AODVv2 parameters should be adjusted using > either experimentally determined values or dynamic adaptation. For > example, in networks with infrequent topology changes > ROUTE_USED_TIMEOUT may be set to a much larger value. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 31] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > Default Parameter Values >=20 > +------------------------+-------+----------------------------------+ > | Name | Value | Description | > +------------------------+-------+----------------------------------+ > | MSG_HOPLIMIT | 20 | This value MUST be larger than | > | | hops | the AODVv2 network diameter. | >=20 > UH> How would the network diameter be determined? >=20 > | | | Otherwise, routing messages may | > | | | not reach their intended | > | | | destinations. | > | DISCOVERY_ATTEMPTS_MAX | 3 | The number of route discovery | > | | | attempts to make before | > | | | indicating that a particular | > | | | address is not reachable. | > +------------------------+-------+----------------------------------+ >=20 > Table 4 >=20 > In addition to the above parameters and timing values, several > administrative options exist. These options have no influence on > correct routing behavior, although they may potentially reduce AODVv2 > protocol messaging in certain situations. The default behavior is to > NOT enable any of these options; and although many of these options > can be administratively controlled, they may be better served by > intelligent control. The following table enumerates several of the > options. >=20 > Administratively Controlled Options >=20 > +--------------------------+----------------------------------------+ > | Name | Description | > +--------------------------+----------------------------------------+ > | BUFFER_DURING_DISCOVERY | Whether and how much data to buffer | > | | during route discovery. | >=20 > UH> Whether and how much? Is it a boolean flag or a number? >=20 >=20 > | APPEND_EXTRA_UNREACHABLE | Whether to append additional | > | | Unreachable information to RERR. | > | CONTROL_TRAFFIC_LIMITS | AODVv2 messaging SHOULD be limited to | > | | avoid consuming all the network | > | | bandwidth. | >=20 > UH> What is the unit or the meaning of this? Bytes per second? >=20 > +--------------------------+----------------------------------------+ >=20 > Table 5 >=20 > Note: several fields have limited size (bits or bytes) these sizes > and their encoding may place specific limitations on the values that > can be set. For example, MsgHdr.HopLimit is a 8-bit field and > therefore MSG_HOPLIMIT cannot be larger than 255. >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 32] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 5.13. IANA Considerations >=20 > UH> This is not a valid IANA section. There are no requests for > registries or for TLV code points. There is no allocation policy. > Refer to RFC5526. >=20 >=20 > In its default mode of operation, AODVv2 uses the UDP port 269 > [RFC5498] to carry protocol packets. AODVv2 also uses the link-local > multicast address LL-MANET-Routers [RFC5498]. >=20 > This section specifies several message types, message tlv-types, and > address tlv-types. >=20 > 5.13.1. AODVv2 Message Types Specification >=20 > AODVv2 Message Types >=20 > +------------------------+----------+ > | Name | Type | > +------------------------+----------+ > | Route Request (RREQ) | 10 - TBD | > | Route Reply (RREP) | 11 - TBD | > | Route Error (RERR) | 12 - TBD | > +------------------------+----------+ >=20 > Table 6 >=20 > 5.13.2. Message and Address Block TLV Type Specification >=20 > Message TLV Types >=20 > +-------------------+------+--------+-------------------------------+ > | Name | Type | Length | Value | > +-------------------+------+--------+-------------------------------+ > | Unicast Response | 10 - | 0 | Indicates to the processing | > | Request | TBD | octets | node that the previous hop | > | | | | (IP.SourceAddress) expects a | > | | | | unicast reply message within | > | | | | UNICAST_MESSAGE_SENT_TIMEOUT. | > | | | | Any unicast packet will serve | > | | | | this purpose, and it MAY be | > | | | | an ICMP REPLY message. If | > | | | | the reply is not received, | > | | | | then the previous hop can | > | | | | assume that the link is | > | | | | unidirectional and MAY | > | | | | blacklist the link to this | > | | | | node. | > +-------------------+------+--------+-------------------------------+ >=20 > UH> It is never specified where and how to use this TLV? Is it a > message-specifid TLV? To which registry do you want to add it? What is > the allocation policy? What are the registered type extensions? >=20 > Table 7 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 33] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 5.13.3. Address Block TLV Specification >=20 > Address Block TLV Types >=20 > +----------------+------------+----------+--------------------------+ > | Name | Type | Length | Value | > +----------------+------------+----------+--------------------------+ > | AODVv2 | 10 - TBD | up to 2 | The AODVv2 sequence num | > | Sequence | | octets | associated with this | > | Number | | | address. The sequence | > | (AODVv2SeqNum) | | | number may be the last | > | | | | known sequence number. | > | Distance | 11 - TBD | up to 2 | A metric of the distance | > | | | octets | traversed by the | > | | | | information associated | > | | | | with this address. | >=20 > UH> How is the distance formatted? >=20 > | VALIDITY_TIME | 1[RFC5497] | | The maximum amount of | > | | | | time that information | > | | | | can be maintained before | > | | | | being deleted. The | > | | | | VALIDITY_TIME TLV is | > | | | | defined in [RFC5497]. | > +----------------+------------+----------+--------------------------+ >=20 > Table 8 >=20 > 5.14. Security Considerations >=20 > UH> This will not suffice; see RFC3552 for guidelines how to write > security considerations. >=20 > UH> Notably, there is no mention of possible threats to AODVv2. Also, > there is some text to protect messages; but it is impossible to do so, > as messages are changed in transit. Also, since there is no way to > hook in security extensions (such as done in RFC6130) for rejecting > messages, there is currently no security possible for DYMO. >=20 >=20 > The objective of the AODVv2 protocol is for each router to > communicate reachability information to addresses for which it is > responsible. Positive routing information (i.e. a route exists) is > distributed via RteMsgs and negative routing information (i.e. a > route does not exist) via RERRs. AODVv2 routers that handle these > messages store the contained information to properly forward data > packets, and they generally provide this information to other AODVv2 > routers. >=20 > This section does not mandate any specific security measures. > Instead, this section describes various security considerations and > potential avenues to secure AODVv2 routing. >=20 > The most important security mechanisms for AODVv2 routing are > integrity/authentication and confidentiality. >=20 > In situations where routing information or router identity are > suspect, integrity and authentication techniques SHOULD be applied to > AODVv2 messages. >=20 > UH> How? Messages change in transit (addresses added or removed etc). >=20 > In these situations, routing information that is > distributed over multiple hops SHOULD also verify the integrity and >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 34] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > identity of information based on originator of the routing > information. >=20 > UH> How? >=20 > A digital signature could be used to identify the source of AODVv2 > messages and information, along with its authenticity. A nonce or > timestamp SHOULD also be used to protect against replay attacks. > S/MIME and OpenPGP are two authentication/integrity protocols that > could be adapted for this purpose. >=20 > In situations where confidentiality of AODVv2 messages is important, > cryptographic techniques can be applied. >=20 > In certain situations, for example sending a RREP or RERR, an AODVv2 > router could include proof that it has previously received valid > routing information to reach the destination, at one point of time in > the past. In situations where routers are suspected of transmitting > maliciously erroneous information, the original routing information > along with its security credentials SHOULD be included. >=20 > Note that if multicast is used, any confidentiality and integrity > algorithms used MUST permit multiple receivers to handle the message. >=20 > Routing protocols, however, are prime targets for impersonation > attacks. In networks where the node membership is not known, it is > difficult to determine the occurrence of impersonation attacks, and > security prevention techniques are difficult at best. However, when > the network membership is known and there is a danger of such > attacks, AODVv2 messages must be protected by the use of > authentication techniques, such as those involving generation of > unforgeable and cryptographically strong message digests or digital > signatures. While AODVv2 does not place restrictions on the > authentication mechanism used for this purpose, IPsec Authentication > Message (AH) is an appropriate choice for cases where the nodes share > an appropriate security association that enables the use of AH. >=20 > UH> That only works for a single hop, not end-to-end, as the IP > packets are not forwarded. >=20 > In particular, routing messages SHOULD be authenticated to avoid > creation of spurious routes to a destination. Otherwise, an attacker > could masquerade as that destination and maliciously deny service to > the destination and/or maliciously inspect and consume traffic > intended for delivery to the destination. RERR messages SHOULD be > authenticated in order to prevent malicious nodes from disrupting > active routes between communicating nodes. >=20 > If the mobile nodes in the ad hoc network have pre-established > security associations, the purposes for which the security > associations are created should include that of authorizing the > processing of AODVv2 control packets. Given this understanding, the > mobile nodes should be able to use the same authentication mechanisms >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 35] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > based on their IP addresses as they would have used otherwise. >=20 > 5.15. Acknowledgments >=20 > AODVv2 is a descendant of the design of previous MANET on-demand > protocols, especially AODV [RFC3561] and DSR [RFC4728]. Changes to > previous MANET on-demand protocols stem from research and > implementation experiences. Thanks to Elizabeth Belding-Royer for > her long time authorship of AODV. Additional thanks to Luke Klein- > Berndt, Pedro Ruiz, Fransisco Ros, Koojana Kuladinithi, Ramon > Caceres, Thomas Clausen, Christopher Dearlove, Seung Yi, Romain > Thouvenin, Tronje Krop, Henner Jakob, Alexandru Petrescu, Christoph > Sommer, Cong Yuan, Lars Kristensen, and Derek Atkins for reviewing of > AODVv2, as well as several specification suggestions. >=20 > This revision of AODVv2 isolates the minimal base specification and > other optional features to simplify the process of ensuring > compatibility with the existing LOADng specification > [I-D.clausen-lln-loadng] (minimal reactive routing protocol > specification). Thanks are due to T. Clausen, A. Colin de Verdiere, > J. Yi, A. Niktash, Y. Igarashi, Satoh. H., and U. Herberg for their > development of LOADng and sharing details for ensuring > appropriateness of AODVv2 for LLNs. >=20 >=20 > 6. References >=20 > 6.1. Normative References >=20 > [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", > RFC 1812, June 1995. >=20 > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. >=20 > [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. > Pignataro, "The Generalized TTL Security Mechanism > (GTSM)", RFC 5082, October 2007. >=20 > [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, > "Generalized Mobile Ad Hoc Network (MANET) Packet/Message > Format", RFC 5444, February 2009. >=20 > [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value > Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, > March 2009. >=20 > [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 36] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > (MANET) Protocols", RFC 5498, March 2009. >=20 > 6.2. Informative References >=20 > [I-D.clausen-lln-loadng] > Clausen, T., Verdiere, A., Yi, J., Niktash, A., Igarashi, > Y., Satoh, H., Herberg, U., Lavenu, C., Lys, T., and C. > Perkins, "The LLN On-demand Ad hoc Distance-vector Routing > Protocol - Next Generation (LOADng)", > draft-clausen-lln-loadng-05 (work in progress), July 2012. >=20 > [Perkins99] > Perkins, C. and E. Belding-Royer, "Ad hoc On-Demand > Distance Vector (AODV) Routing", Proceedings of the 2nd > IEEE Workshop on Mobile Computing Systems and > Applications, New Orleans, LA, pp. 90-100, February 1999. >=20 > [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. >=20 > [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking > (MANET): Routing Protocol Performance Issues and > Evaluation Considerations", RFC 2501, January 1999. >=20 > [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- > Demand Distance Vector (AODV) Routing", RFC 3561, > July 2003. >=20 > [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast > Addresses", RFC 4193, October 2005. >=20 > [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source > Routing Protocol (DSR) for Mobile Ad Hoc Networks for > IPv4", RFC 4728, February 2007. >=20 > [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, > "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, > September 2007. >=20 > [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter > Considerations in Mobile Ad Hoc Networks (MANETs)", > RFC 5148, February 2008. >=20 > [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF > for IPv6", RFC 5340, July 2008. >=20 > [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc > Network (MANET) Neighborhood Discovery Protocol (NHDP)", > RFC 6130, April 2011. >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 37] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- > Instance Extensions", RFC 6549, March 2012. >=20 > [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, > May 2012. >=20 >=20 > Appendix A. Changes since the Previous Version >=20 > o Internet-Facing AODVv2 router renamed to be IAR >=20 > o "Optional Features" section created to contain features not > required within base specification, including: >=20 > o >=20 > * Intermediate RREPs (iRREPs): Without iRREP, only the > destination can respond to a RREQ. >=20 > * Precursor lists. >=20 > * An RERR may reporting multiple unreachable nodes. >=20 > * Message Aggregation. >=20 > o Sequence number MUST (instead of SHOULD) be set to 1 after > rollover. >=20 > o ThisNode MUST (instead of SHOULD) only handle AODVv2 messages from > adjacent routers. >=20 > o Clarification that Additional Routing information in RteMsgs is > optional (MAY) to use. >=20 > o Clarification that if Additional Routing information in RteMsgs is > used, then the Route Table Entry SHOULD be updated using normal > procedures as described in Section 5.2.2. >=20 > o Clarification in Section 5.4 that nodes may be configured to > buffer zero packets. >=20 > o Clarification in Section 5.4 that buffered packets MUST be dropped > if route discovery fails. >=20 > o In Section 5.5.1, relax mandate for monitoring connectivity to > next-hop AODVv2 neighbors (from MUST to SHOULD), in order to allow > for minimal implementations >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 38] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > o Remove Route.Forwarding flag; identical to "NOT" Route.Broken. >=20 > o Routing Messages MUST be originated with the MsgHdr.HopLimit set > to MSG_HOPLIMIT. Previously, this was not mandated. >=20 > o Maximum hop count set to 254, with 255 reserved for "unknown". > Since the current draft only uses hop-count as distance, this is > also the current maximum distance. >=20 >=20 > Appendix B. Shifting Network Prefix Advertisement Between AODVv2 > Routers >=20 > Only one AODVv2 router within a routing region SHOULD be responsible > for a particular address at any time. If two AODVv2 routers > dynamically shift the advertisement of a network prefix, correct > AODVv2 routing behavior must be observed. The AODVv2 router adding > the new network prefix must wait for any existing routing information > about this network prefix to be purged from the network. Therefore, > it must wait at least ROUTER_SEQNUM_AGE_MAX_TIMEOUT after the > previous AODVv2 router for this address stopped advertising routing > information on its behalf. >=20 >=20 > Authors' Addresses >=20 > Charles E. Perkins > Futurewei Inc. > 2330 Central Expressway > Santa Clara, CA 95050 > USA >=20 > Phone: +1-408-330-5305 > Email: charliep@computer.org >=20 >=20 > Ian D Chakeres > CenGen > 9250 Bendix Road North > Columbia, Maryland 21045 > USA >=20 > Email: ian.chakeres@gmail.com > URI: http://www.ianchak.com/ >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 39] > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 From ulrich@herberg.name Thu Nov 1 16:55:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8AF321F981B for ; Thu, 1 Nov 2012 16:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SvoJMCNx0Jr for ; Thu, 1 Nov 2012 16:55:48 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B461D21F987A for ; Thu, 1 Nov 2012 16:55:48 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3649023vbb.31 for ; Thu, 01 Nov 2012 16:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jLLFMo4E0KpN//6mo5NoZqCdmF0lKgJtEArmKFtz0hM=; b=oq3UPyB7AlWpkOX+XfHNFiQHOl2Px8b9rCfqEBmyJ5poN1qP+18Jaz3UMaPwJNxm9V HeBpV+/I83pF2ujnKb9lpHzm03hfGVvu4BVVAn2m0oRylRv8zTuG48QGzkVptzT2fXsY ad3syL82+ienvJcEHe5KbyxoqjJYfys4w973g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=jLLFMo4E0KpN//6mo5NoZqCdmF0lKgJtEArmKFtz0hM=; b=WzTslfiK0Xixjs2lB5BnoTcVEF2sxGTB01WZQEtonr8lmmpr8pu1NBAe7lxUzMT+RT HT1ZROK4cLr6C6Jclrna5GTT2yu1XwA8choCDNhHMwx6vVSRmw3chJBoikht34n+sCK1 kjpszaaggcgJg5A1V/1O/wMgjir7RstQ1babpeXXX15hJu0aFAVIoYrASLNR4JqqflzZ 5ALWxNo6Zs2oCJv9s/v5QKC97/egvp2WSs6k2ASdXTyjNu5slWAHCjpf3uvGJ4egLmWG 2GTxePYW/KippZEA+tdPSJDCPuBHYmGk/XZuERLuNLQX6543Pv56o5Ue7WVyeYY8Wpd5 eRqw== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr80372vdv.20.1351814147847; Thu, 01 Nov 2012 16:55:47 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Thu, 1 Nov 2012 16:55:47 -0700 (PDT) In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D21571353@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <97B69B30E0EF244B940B65EA541E3F2D21571353@DBXPRD0510MB395.eurprd05.prod.outlook.com> Date: Thu, 1 Nov 2012 16:55:47 -0700 Message-ID: From: Ulrich Herberg To: C Chauvenet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQntOBzgViWhnVNzscxA1oAqEa86y1JPGObVv2NuYYrBwG1BTH/AQJ08PlygVBeyV46HjzCI Cc: "" Subject: Re: [manet] DYMO-23 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 23:55:49 -0000 C=E9dric, On Thu, Nov 1, 2012 at 4:43 PM, C Chauvenet wrote= : [...] >> >> during the discussion, I noticed that many just say "I like protocol >> foo1 better than foo2", without any technical argument. That is not >> very productive. > > I think it is because chairs proposed 3 options and ask WG to give their = opinion on these 3 solutions. > Of course, we could have very deep technical discussions, and expand the = message storm on the list but from what I understood chairs are mostly wai= ting for opinions on these 3 choices. Well, I think we need the technical discussions. Otherwise, it's not productive to say "I prefer option A over B" without stating technical reasons (and maybe without even having read both drafts). There may be political rather than technical reasons for such a choice, and we should absolutely avoid that. Best regards Ulrich From jt369@drexel.edu Thu Nov 1 17:59:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49EFC21F97F8 for ; Thu, 1 Nov 2012 17:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1e1hRY03SpMr for ; Thu, 1 Nov 2012 17:59:00 -0700 (PDT) Received: from smtp.mail.drexel.edu (pm1.irt.drexel.edu [144.118.29.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAB221F9795 for ; Thu, 1 Nov 2012 17:59:00 -0700 (PDT) Received: from smtp.mail.drexel.edu (localhost.localdomain [127.0.0.1]) by smtp.mail.drexel.edu (Postfix) with SMTP id CDE2C5C87B9 for ; Thu, 1 Nov 2012 20:58:58 -0400 (EDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (Authenticated sender: jt369) by smtp.mail.drexel.edu (Postfix) with ESMTP id 6D0075C8A3C for ; Thu, 1 Nov 2012 20:58:58 -0400 (EDT) Received: by mail-la0-f44.google.com with SMTP id b11so2445091lam.31 for ; Thu, 01 Nov 2012 17:58:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.39.233 with SMTP id s9mr119333lbk.71.1351817937283; Thu, 01 Nov 2012 17:58:57 -0700 (PDT) Received: by 10.114.57.36 with HTTP; Thu, 1 Nov 2012 17:58:57 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Nov 2012 20:58:57 -0400 Message-ID: From: Joydeep Tripathi To: Joseph Macker Content-Type: multipart/alternative; boundary=e0cb4efe3070f3ea4704cd78a3e7 X-PerlMx-Authed: User SMTP Authed Cc: manet@ietf.org Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 00:59:02 -0000 --e0cb4efe3070f3ea4704cd78a3e7 Content-Type: text/plain; charset=ISO-8859-1 Hi Joe and MANET WG, I was following the discussion on which route to take for a reactive protocol standard very closely, and I think I should post my opinion also. I champion for *Option 1*, and here is why : I have read both AODVv2 (DYMO) and LOAD-ng drafts, and I have simulated LOAD-ng myself as well. This experience, I believe, puts me in a position to form an opinion comparing these two protocols. I certainly agree, option 3 is *not* an option I would like to be chosen. Reactive protocols, though very much unsuitable for LLNs and Smart Grid AMI meter networks, may have some usefulness in certain networks for certain sparse traffic scenario, and the WG should have a standard for the same. Firstly, LOAD-ng is backed up by the argument that it has implementations and interop documents. However, I have seen in the mailing list, that certain question on details of the 'practical' implementation of LOAD-ng has been avoided. A reactive protocol may do well in a 2000 nodes smart meter network, if the data traffic to the base station or collector is 1-2 times a day. This kind of implementations, in my opinion, say nothing about usefulness of LOAD-ng in Smart Grid networks or LLNs. Again, whether LLN may be considered as a subset of MANET or not is a different question. But even then, deployed LOAD-ng in a 2000 node network may (and in my opinion, will) fail if traffic is increased. Agreed, one size does not fit all. However, once we have multicast traffic in a smart grid or multiple meters generating alert packets in a region at the same time, a reactive protocol like LOAD-ng will lead to the break-down of the network. Anyone can say multicast traffic or several meters reporting emergency at the same time to the same station, is a very much likely situation in smart grid. Were these situations considered during deployment? Please note, I am NOT saying that AODVv2 / DYMO will be better in this case than LOAD-ng. IMHO, any protocol can be shown 'working perfectly', if we provide a favorable atmosphere only for it to work. Looking at that perspective, I don't think, *LOAD-ng working in one network under one particular scenario should be considered a vital argument to discuss whether to go with AODVv2 or LOAD-ng*. One can write a working code of AODVv2 in 2 days. The real question we should be asking, which protocol is better suited for general MANET overall, and if there really is a *necessity* of discarding a working group document. Secondly, LOAD-ng was devised keeping LLN scenario in mind. It was intended for ROLL WG, and since it had not been adopted in the ROLL WG, it popped up in the MANET WG. The change that has been done to LOAD-ng after dragging it to MANET WG, was really to change the message format to adhere to RFC 5444, and do a "find and replace" of the term LLN with 'MANET' along with changing the first 'L' of LOAD ng from 'LLN' to 'Lightweight'. Since the protocol was designed for LLN at first, I do not think it would be able to cover the broad spectrum that MANET includes. Since we already have a WG document for a reactive protocol, I do not see any strong reason to discard the current one in favor of an individual draft, especially when even LOAD-ng authors agreed that this protocol will not offer any notable performance difference compared to AODVv2. At the same time, since I have read both drafts, I figured out that AODVv2 is more generic to MANET than LOAD-ng. It offers the developer or the deployment authority to chose form more than one options. For example, AODVv2 has the option (but it is not mandated) to use a precursor list or have an intermediate node to reply an RREQ. LOAD-ng does not support either. I can understand that for an LLN it may be beneficial for not maintaining a precursor list or having only the destination reply t o a RREQ, there can be (and are) other instances of MANETs where having the option of precursor list will come handy. This can save on control overhead, using some storage space in the node. LOAD-ng, in most cases does not provide this flexibility to the developer to chose between options for specific deployment. Some MANET deployment may be less harsh than others in nature. Hence, AODVv2 having more open options than LOAD-ng, in most cases, seem beneficial to me. Of course, there are other technical differences between these protocols. But I believe there is a separate thread created for that. I will wait for the draft authors to reply there first, and will reply with my points if all those differences are not covered. There, I will re-iterate the necessity of a protocol to be suited for MANET in general, not only 'some' kind of MANETs. Lastly, I do not come from any industry, neither I have any company road-map of deliverable here. Being a PhD candidate in a university, I tried to fairly judge the two options. So I read both drafts, and did not find a strong enough reason to discard a current working group document. Whether a few companies backing up a protocol over the other can be a decisive criteria to chose a standard protocol or not, is in the WG and its chairs most capable hands. Also, I did not, very clearly understand how LOAD-ng, operating properly in a 2-5 routers test-bed may be considered as proof of valid interoperability. I would very much appreciate feedback if I am wrong, since I am in my learning phase :-) . I have my 2 cents here - a) AODVv2 offers more flexibility, b) LOAD-ng does not offer enough advantage over AODVv2 to discard the later, c) LOAD-ng was not initially designed for MANET, and d) there are other technical differences that make AODVv2 more suitable for MANETs over LOAD-ng (To be covered in separate thread). My opinion - We should stick to current WG document (AODVv2) and improve it and finish it as soon as possible. I hereby stand for *Option 1*. Thanks and Regards, Joydeep Tripathi PhD Candidate, Drexel University. On Tue, Oct 30, 2012 at 7:13 PM, Joseph Macker wrote: > Hello MANET working group (form Stan and Joe), > > As you are all probably aware, there has been WG activity lately on > competing drafts for a MANET reactive protocol - DYMO (reviving the current > working group document that was parked due to inactivity), and LOADng. Many > months ago there was a somewhat authorship led movement towards a common > document effort and given positive feedback at the time we the chairs > thought this was the best approach given the authors potential to come > together and gain the best of both efforts. Since that period, there has > been some fairly strident and rancorous "at times" debate between the > authors of the two documents. > > During IETF 84 in Vancouver, the co-chairs held a discussion with some of > the co-authors of the two documents. Our guidance to the co-authors was to > find a way to merge the two documents into one, as it was perceived that > are not technically far apart and they both derive roughly from AODV > concepts and LOADng had fairly active authorship and implementation > efforts. We provided a co-editing proposal to the authors and gave them the > timeframe of the Atlanta to come up with an answer back to us regarding > this. As of this writing, those discussions of a potential commonn > document and authorship merger have failed. > > Therefore, we find ourselves at a crossroads. The authors of the two > documents are divided, and it is unlikely that progress on a merged > document can be reached based upon recent author feedback. I have also > polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat > disengaged on the issue at the present time. We see only 3 possible paths > forward: > > 1. Continue the work on the DYMO document, starting with whether there is > consensus on its continued approach and also the desire to rename it to > AODVv2. > 2. Replace the existing DYMO document effort with the LOADng related > document effort, defusing ealier references to LLNs as recommended in the > last meeting minutes, and to focus more motivationally on general MANET > problem spaces (the authors seem to have agreed to this issue if its a WG > document). > 3. Remove the working group charter for a reactive protocol, effectively > killing both documents, at least from a working group (WG) standpoint. This > would not be a reflection on the technology in either case, just an > admission that we are not working together and reaching consensus. > > The co-chairs request and need your opinions on the options. We have been > some silent collecting initial feedback and waiting for author feedback at > this point. Stan and I are both on travel prior to Atlanta so our > responses may be sparse and we will also likely be in a "receive mode" for > a few days. So send your opinions. > > -Joe > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --e0cb4efe3070f3ea4704cd78a3e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Joe and MANET WG,

I was following the discussion on w= hich route to take for a reactive protocol standard very closely, and I thi= nk I should post my opinion also. I champion for Option 1, and here = is why :=A0

I have read both AODVv2 (DYMO) and LOAD-ng drafts, and = I have simulated LOAD-ng myself as well. This experience, I believe, puts m= e in a position to form an opinion comparing these two protocols. I certain= ly agree, option 3 is *not* an option I would like to be chosen. Reactive p= rotocols, though very much unsuitable for LLNs and Smart Grid AMI meter net= works, may have some usefulness in certain networks for certain sparse traf= fic scenario, and the WG should have a standard for the same.

Firstly, LOAD-ng is backed up by the argument that it h= as implementations and interop documents. However, I have seen in the maili= ng list, that certain question on details of the 'practical' implem= entation of LOAD-ng has been avoided. A reactive protocol may do well in a = 2000 nodes smart meter network, if the data traffic to the base station or = collector is 1-2 times a day. This kind of implementations, in my opinion, = say nothing about usefulness of LOAD-ng in Smart Grid networks or LLNs. Aga= in, whether LLN may be considered as a subset of MANET or not is a differen= t question. But even then, deployed LOAD-ng in a 2000 node network may (and= in my opinion, will) fail if traffic is increased. Agreed, one size does n= ot fit all. However, once we have multicast traffic in a smart grid or mult= iple meters generating alert packets in a region at the same time, a reacti= ve protocol like LOAD-ng will lead to the break-down of the network. Anyone= can say multicast traffic or several meters reporting emergency at the sam= e time to the same station, is a very much likely situation in smart grid. = Were these situations considered during deployment? Please note, I am NOT s= aying that=A0AODVv2 / DYMO will be better in this case than LOAD-ng. IMHO, = any protocol can be shown 'working perfectly', if we provide a favo= rable atmosphere only for it to work. Looking at that perspective, I don= 9;t think, LOAD-ng working in one network under one particular scenario = should be considered a vital argument to discuss whether to go with AODVv2 = or LOAD-ng. One can write a working code of AODVv2 in 2 days. The real = question we should be asking, which protocol is better suited for general M= ANET overall, and if there really is a *necessity* of discarding a working = group document.

Secondly, LOAD-ng was devised keeping LLN scenario in m= ind. It was intended for ROLL WG, and since it had not been adopted in the = ROLL WG, it popped up in the MANET WG. The change that has been done to LOA= D-ng after dragging it to MANET WG, was really to change the message format= to adhere to RFC 5444, and do a "find and replace" of the term L= LN with 'MANET' along with changing the first 'L' of LOAD n= g from 'LLN' to 'Lightweight'. Since the protocol was desig= ned for LLN at first, I do not think it would be able to cover the broad sp= ectrum that MANET includes. Since we already have a WG document for a react= ive protocol, I do not see any strong reason to discard the current one in = favor of an individual draft, especially when even LOAD-ng authors agreed t= hat this protocol will not offer any notable performance difference compare= d to AODVv2.=A0

At the same time, since I have read both drafts, I figu= red out that AODVv2 is more generic to MANET than LOAD-ng. It offers the de= veloper or the deployment authority to chose form more than one options. Fo= r example, AODVv2 has the option (but it is not mandated) to use a precurso= r list or have an intermediate node to reply an RREQ. LOAD-ng does not supp= ort either. I can understand that for an LLN it may be beneficial for not m= aintaining a precursor list or having only the destination reply t o a RREQ= , there can be (and are) other instances of MANETs where having the option = of precursor list will come handy. This can save on control overhead, using= some storage space in the node. LOAD-ng, in most cases does not provide th= is flexibility to the developer to chose between options for specific deplo= yment. Some MANET deployment may be less harsh than others in nature. Hence= , AODVv2 having more open options than LOAD-ng, in most cases, seem benefic= ial to me. Of course, there are other technical differences between these p= rotocols. But I believe there is a separate thread created for that. I will= wait for the draft authors to reply there first, and will reply with my po= ints if all those differences are not covered. There, I will re-iterate the= necessity of a protocol to be suited for MANET in general, not only 's= ome' kind of MANETs.

Lastly, I do not come from any industry, neither I have= any company road-map of=A0deliverable=A0here. Being a PhD candidate in a u= niversity, I tried to fairly judge the two options. So I read both drafts, = and did not find a strong enough reason to discard a current working group = document. Whether a few companies backing up a protocol over the other can = be a decisive criteria to chose a standard protocol or not, is in the WG an= d its chairs most capable hands. Also, I did not, very clearly understand h= ow LOAD-ng, operating properly in a 2-5 routers=A0test-bed=A0may be conside= red as proof of valid interoperability.=A0I would very much appreciate feed= back if I am wrong, since I am in my learning phase :-) . I have my 2 cents= here - a) AODVv2 offers more flexibility, b) LOAD-ng does not offer enough= advantage over AODVv2 to discard the later, c) LOAD-ng was not initially d= esigned for MANET, and d) there are other technical differences that make A= ODVv2 more suitable for MANETs over LOAD-ng (To be covered in separate thre= ad). =A0My opinion - We should stick to current WG document (AODVv2) and im= prove it and finish it as soon as possible. I hereby stand for Option 1<= /b>.=A0

Thanks and Regards,

Joydeep Tr= ipathi
PhD Candidate,=A0
Drexel University.


On Tue, Oct 3= 0, 2012 at 7:13 PM, Joseph Macker <jpmacker@gmail.com> wrot= e:
Hello MANET working group (form Stan and Joe= ),

As you are all probably aware, there has been WG activity lately = on competing drafts for a MANET reactive protocol - DYMO (reviving the curr= ent working group document that was parked due to inactivity), and LOADng. = Many months ago there was a somewhat authorship led movement towards a comm= on document effort and given positive feedback at the time we the chairs th= ought this was the best approach given the authors potential to come togeth= er and gain the best of both efforts.=A0 Since that period, there has been = some fairly strident and rancorous "at times" debate between the = authors of the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some = of the co-authors of the two documents. Our guidance to the co-authors was = to find a way to merge the two documents into one, as it was perceived that= are not technically far apart and they both derive roughly from AODV conce= pts and LOADng had fairly active authorship and implementation efforts. We = provided a co-editing proposal to the authors and gave them the timeframe o= f the Atlanta to come up with an answer back to us regarding this.=A0 As of= this writing, those discussions of a potential commonn document and author= ship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two do= cuments are divided, and it is unlikely that progress on a merged document = can be reached based upon recent author feedback. I have also polled the ea= rlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the= issue at the present time.=A0 We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there = is consensus on its continued approach and also the desire to rename it to = AODVv2.
2. Replace the existing DYMO document effort with the LOADng rel= ated document effort, defusing ealier references to LLNs as recommended in = the last meeting minutes, and to focus more motivationally on general MANET= problem spaces (the authors seem to have agreed to this issue if its a WG = document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.=A0 We have= been some silent collecting initial feedback and waiting for author feedba= ck at this point.=A0 Stan and I are both on travel prior to Atlanta so our = responses may be sparse and we will also likely be in a "receive mode&= quot; for a few days.=A0 So send your opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--e0cb4efe3070f3ea4704cd78a3e7-- From ulrich@herberg.name Thu Nov 1 18:39:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442A321F95F8 for ; Thu, 1 Nov 2012 18:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xw76HxpxYLuw for ; Thu, 1 Nov 2012 18:39:03 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DFBEB21F95EE for ; Thu, 1 Nov 2012 18:39:02 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3689576vcb.31 for ; Thu, 01 Nov 2012 18:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OSDahlYr/90X0KMMZWmVzBOjiRVfcCtjDTxO/tz/wX4=; b=nj/MLKOAhUGv6jfePGCJ5ZcYjguLMQ6UcDjlBESwl2gmozITaCUwnsr7/6628PmR5m i283TtKXJ+ICp1ZGR9m0hxwYwBUYxACZyvlAzJCVnJVQmNCFfbcVkoWkzsVeGT/bO+VJ r9Qh2I1e7Mzkzb0Y09W9/WsutNZSQqyu7SOeA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=OSDahlYr/90X0KMMZWmVzBOjiRVfcCtjDTxO/tz/wX4=; b=bzyLy4SlVzatAST1Q6mJ8m2vLqzJNr5IZeMFeZMbcocjofuB5OYEaJ7N1+KlXSiCzM a7Ezfm9+Fj/w+r3JaZ06NZRzeVYCVgHk6rnGb9ss/qQE9QbtJQJPyziXwJd0wM37P+s7 VQsGyIKSqjtaFe+dazgAnbt9yW7C9VO2UQEr2SEwfXQKYhDR9ngarVSzCr/tAJyu6jAP jDqbKKMzvnkVdGj6MYadXlNaLwIi2xU2Oo+xfAgccngZtFmZMHfUJ6XSM+hvIijMfXF+ Vb7gmV+NeHHvDPd6QiFALjqLbupCRHkaB4H13SDaWshYPwkaeClxYY/40y5583KmqPfy D+wg== MIME-Version: 1.0 Received: by 10.58.132.229 with SMTP id ox5mr285456veb.46.1351820342261; Thu, 01 Nov 2012 18:39:02 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Thu, 1 Nov 2012 18:39:02 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Nov 2012 18:39:02 -0700 Message-ID: From: Ulrich Herberg To: Joydeep Tripathi Content-Type: multipart/alternative; boundary=047d7b6da1884cf87004cd7933e5 X-Gm-Message-State: ALoCoQnKYFwGQcaoeXtodlOu8t3+r7wIPTeyxkDvu9yeSJ1yhBY5cyoJychlYX9eEkl0+L2INiQS Cc: manet@ietf.org Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 01:39:05 -0000 --047d7b6da1884cf87004cd7933e5 Content-Type: text/plain; charset=ISO-8859-1 Hi Joydeep, On Thu, Nov 1, 2012 at 5:58 PM, Joydeep Tripathi wrote: > Hi Joe and MANET WG, > > I was following the discussion on which route to take for a reactive > protocol standard very closely, and I think I should post my opinion also. > I champion for *Option 1*, and here is why : > > I have read both AODVv2 (DYMO) and LOAD-ng drafts, and I have simulated > LOAD-ng myself as well. This experience, I believe, puts me in a position > to form an opinion comparing these two protocols. > That is valuable. Have you also implemented DYMO and compared it to LOADng? > I certainly agree, option 3 is *not* an option I would like to be chosen. > Reactive protocols, though very much unsuitable for LLNs and Smart Grid AMI > meter networks, > I differ on that, and so do some of the LOADng authors that work in that area. But that's not the point of the discussion here. > may have some usefulness in certain networks for certain sparse traffic > scenario, and the WG should have a standard for the same. > I agree. > > Firstly, LOAD-ng is backed up by the argument that it has implementations > and interop documents. However, I have seen in the mailing list, that > certain question on details of the 'practical' implementation of LOAD-ng > has been avoided. > I don't see how. There was a description of the deployment and about the suitability for LOADng in that. Note that for DYMO, there is no such deployment (to my knowledge), which is why I think your conclusion for option 1 instead of option 3 is surprising to me. > A reactive protocol may do well in a 2000 nodes smart meter network, if > the data traffic to the base station or collector is 1-2 times a day. This > kind of implementations, in my opinion, say nothing about usefulness of > LOAD-ng in Smart Grid networks or LLNs. > It is well known (and also spelled out in DYMO), that reactive protocols are more suitable for sparse traffic scenarios with few concurrent communication streams. That is well-known and understood in MANET, and a reasons to work on a proactive protocol as well. Reactive protocols have their limitations, but in certain MANET use cases are useful, which is why we are chartered to work on a reactive protocol. > Again, whether LLN may be considered as a subset of MANET or not is a > different question. But even then, deployed LOAD-ng in a 2000 node network > may (and in my opinion, will) fail if traffic is increased. > That is possible. Both in DYMO and LOADng. > Agreed, one size does not fit all. However, once we have multicast traffic > in a smart grid or multiple meters generating alert packets in a region at > the same time, a reactive protocol like LOAD-ng will lead to the break-down > of the network. Anyone can say multicast traffic or several meters > reporting emergency at the same time to the same station, is a very much > likely situation in smart grid. Were these situations considered during > deployment? Please note, I am NOT saying that AODVv2 / DYMO will be better > in this case than LOAD-ng. > But why are you opting for option 1 then? That seems not logical. You argue against reactive protocols in general. All what you say above is known to MANET, long before ROLL and LLN even existed. > IMHO, any protocol can be shown 'working perfectly', if we provide a > favorable atmosphere only for it to work. > Yes, I agree. You say yourself, no-one-size-fits all, which is why MANET works on both reactive and proactive protocol. > Looking at that perspective, I don't think, *LOAD-ng working in one > network under one particular scenario should be considered a vital argument > to discuss whether to go with AODVv2 or LOAD-ng*. > LOADng has one large-scale deployment, DYMO does not. LOADng has multiple recent interoperable implementations, DYMO has not. LOADng is based on the same mechanism of AODV that is known to work in certain MANET scenarios. So why do you opt for 1) and not 3)? > > One can write a working code of AODVv2 in 2 days. The real question we > should be asking, which protocol is better suited for general MANET > overall, and if there really is a *necessity* of discarding a working group > document. > > > Secondly, LOAD-ng was devised keeping LLN scenario in mind. It was > intended for ROLL WG, and since it had not been adopted in the ROLL WG, it > popped up in the MANET WG. The change that has been done to LOAD-ng after > dragging it to MANET WG, was really to change the message format to adhere > to RFC 5444, > That is true, the work was initiated from LLNs. However, as you say yourself, it has adopted RFC5444 and other MANET requirements. Note that amongst the authors, there are a large part of the previous RFC editors of MANET presented. We know MANETs and their requirements. Can you point out a specific requirement that LOADng would not fulfill but DYMO would? > and do a "find and replace" of the term LLN with 'MANET' along with > changing the first 'L' of LOAD ng from 'LLN' to 'Lightweight'. Since the > protocol was designed for LLN at first, I do not think it would be able to > cover the broad spectrum that MANET includes. > Why? And why does DYMO? I don't see a technical argument. > Since we already have a WG document for a reactive protocol, I do not see > any strong reason to discard the current one in favor of an individual > draft, especially when even LOAD-ng authors agreed that this protocol will > not offer any notable performance difference compared to AODVv2. > Yes, but the document is not aligned with the RFC5444 architecture, it is not possible to secure, and it would be a lot more work to come to an RFC, in my opinion (lots of unclear and underspecified text, incomplete IANA section, unclear metrics, underspecified bidirectionality detection). > > At the same time, since I have read both drafts, I figured out that AODVv2 > is more generic to MANET than LOAD-ng. It offers the developer or the > deployment authority to chose form more than one options. > Options may be fine, but they also affect interoperability if not carefully designed. And they may, as for some of the options like iRREP, make it very difficult or impossible to provide end-to-end security. > For example, AODVv2 has the option (but it is not mandated) to use a > precursor list or have an intermediate node to reply an RREQ. LOAD-ng does > not support either. > That is not true. We opted to move these in companion document, as we have not seen proof that these options would bring benefit in a general MANET case. I can understand that for an LLN it may be beneficial for not maintaining a > precursor list or having only the destination reply t o a RREQ, there can > be (and are) other instances of MANETs where having the option of precursor > list will come handy. > Which? Can you show results that this is beneficial in a general use case? > This can save on control overhead, using some storage space in the node. > LOAD-ng, in most cases does not provide this flexibility to the developer > to chose between options for specific deployment. > Again, not true. We provide TLVs, and extensions are possible in companion documents. We have very carefully designed each RFC2119 word to make sure extensions are allowed. Multiple options always carry a great risk of non-interoperability. > Some MANET deployment may be less harsh than others in nature. Hence, > AODVv2 having more open options than LOAD-ng, in most cases, seem > beneficial to me. > "seems beneficial"? Have you proof for the use of the options? > Of course, there are other technical differences between these protocols. > But I believe there is a separate thread created for that. I will wait for > the draft authors to reply there first, and will reply with my points if > all those differences are not covered. There, I will re-iterate the > necessity of a protocol to be suited for MANET in general, not only 'some' > kind of MANETs > > Lastly, I do not come from any industry, neither I have any company > road-map of deliverable here. Being a PhD candidate in a university, I > tried to fairly judge the two options. > > So I read both drafts, and did not find a strong enough reason to discard > a current working group document. Whether a few companies backing up a > protocol over the other can be a decisive criteria to chose a standard > protocol or not, is in the WG and its chairs most capable hands. Also, I > did not, very clearly understand how LOAD-ng, operating properly in a 2-5 > routers test-bed may be considered as proof of valid interoperability. > Why not? What would it change to add 100 nodes? I have never seen any interop tests with more than a handful nodes. Again: interop tests are not performance tests. By the way, I have not seen any such open interoperability tests during the development of DYMO . > I would very much appreciate feedback if I am wrong, since I am in my > learning phase :-) . I have my 2 cents here - a) AODVv2 offers more > flexibility, > As said, LOADng offers the same flexibility. Flexibility is nice, but one has to be very careful with interoperability. If LOADng were to be a WG document, of course the WG can discuss if certain options bring a general benefit and don't harm interoperability, then we can include it. > b) LOAD-ng does not offer enough advantage over AODVv2 to discard the > later, > One major advantage is that it could be an RFC far quicker. In the current shape, the SEC AD would certainly not accept DYMO, and it would require a lot more work to bring to a level that is acceptable for a standards track RFC. > c) LOAD-ng was not initially designed for MANET, > I don't see the argument here (see above) > and d) there are other technical differences that make AODVv2 more > suitable for MANETs over LOAD-ng (To be covered in separate thread). > I am curious to see that. Best Ulrich > My opinion - We should stick to current WG document (AODVv2) and improve > it and finish it as soon as possible. I hereby stand for *Option 1*. > > Thanks and Regards, > > Joydeep Tripathi > PhD Candidate, > Drexel University. > > > On Tue, Oct 30, 2012 at 7:13 PM, Joseph Macker wrote: > >> Hello MANET working group (form Stan and Joe), >> >> As you are all probably aware, there has been WG activity lately on >> competing drafts for a MANET reactive protocol - DYMO (reviving the current >> working group document that was parked due to inactivity), and LOADng. Many >> months ago there was a somewhat authorship led movement towards a common >> document effort and given positive feedback at the time we the chairs >> thought this was the best approach given the authors potential to come >> together and gain the best of both efforts. Since that period, there has >> been some fairly strident and rancorous "at times" debate between the >> authors of the two documents. >> >> During IETF 84 in Vancouver, the co-chairs held a discussion with some of >> the co-authors of the two documents. Our guidance to the co-authors was to >> find a way to merge the two documents into one, as it was perceived that >> are not technically far apart and they both derive roughly from AODV >> concepts and LOADng had fairly active authorship and implementation >> efforts. We provided a co-editing proposal to the authors and gave them the >> timeframe of the Atlanta to come up with an answer back to us regarding >> this. As of this writing, those discussions of a potential commonn >> document and authorship merger have failed. >> >> Therefore, we find ourselves at a crossroads. The authors of the two >> documents are divided, and it is unlikely that progress on a merged >> document can be reached based upon recent author feedback. I have also >> polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat >> disengaged on the issue at the present time. We see only 3 possible paths >> forward: >> >> 1. Continue the work on the DYMO document, starting with whether there is >> consensus on its continued approach and also the desire to rename it to >> AODVv2. >> 2. Replace the existing DYMO document effort with the LOADng related >> document effort, defusing ealier references to LLNs as recommended in the >> last meeting minutes, and to focus more motivationally on general MANET >> problem spaces (the authors seem to have agreed to this issue if its a WG >> document). >> 3. Remove the working group charter for a reactive protocol, effectively >> killing both documents, at least from a working group (WG) standpoint. This >> would not be a reflection on the technology in either case, just an >> admission that we are not working together and reaching consensus. >> >> The co-chairs request and need your opinions on the options. We have >> been some silent collecting initial feedback and waiting for author >> feedback at this point. Stan and I are both on travel prior to Atlanta so >> our responses may be sparse and we will also likely be in a "receive mode" >> for a few days. So send your opinions. >> >> -Joe >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --047d7b6da1884cf87004cd7933e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Joydeep,

On Thu, Nov 1, 2012 at 5:58 P= M, Joydeep Tripathi <jt369@drexel.edu> wrote:
Hi Joe and MANET WG,

I was following the discussion on w= hich route to take for a reactive protocol standard very closely, and I thi= nk I should post my opinion also. I champion for Option 1, and here = is why :=A0

I have read both AODVv2 (DYMO) and LOAD-ng drafts, and = I have simulated LOAD-ng myself as well. This experience, I believe, puts m= e in a position to form an opinion comparing these two protocols.

That is valuable. Have you also implemente= d DYMO and compared it to LOADng?

=A0
I certainly agree, option 3 is *not* an option I would like to be chos= en. Reactive protocols, though very much unsuitable for LLNs and Smart Grid= AMI meter networks,

I differ on tha= t, and so do some of the LOADng authors that work in that area. But that= 9;s not the point of the discussion here.

=A0
may have s= ome usefulness in certain networks for certain sparse traffic scenario, and= the WG should have a standard for the same.

I agree.
=A0

Firstly, LOAD-ng is backed up by the argument that it h= as implementations and interop documents. However, I have seen in the maili= ng list, that certain question on details of the 'practical' implem= entation of LOAD-ng has been avoided.

I don't see how. There was a descripti= on of the deployment and about the suitability for LOADng in that. Note tha= t for DYMO, there is no such deployment (to my knowledge), which is why I t= hink your conclusion for option 1 instead of option 3 is surprising to me.<= /div>

=A0
A reactive= protocol may do well in a 2000 nodes smart meter network, if the data traf= fic to the base station or collector is 1-2 times a day. This kind of imple= mentations, in my opinion, say nothing about usefulness of LOAD-ng in Smart= Grid networks or LLNs.

It is well known (and also spelled out in = DYMO), that reactive protocols are more suitable for sparse traffic scenari= os with few concurrent communication streams. That is well-known and unders= tood in MANET, and a reasons to work on a proactive protocol as well. React= ive protocols have their limitations, but in certain MANET use cases are us= eful, which is why we are chartered to work on a reactive protocol.
=A0
Again, whether LLN may be= considered as a subset of MANET or not is a different question. But even t= hen, deployed LOAD-ng in a 2000 node network may (and in my opinion, will) = fail if traffic is increased.

That is possible. Both in DYMO and LOADng.=
=A0
Agreed, one size d= oes not fit all. However, once we have multicast traffic in a smart grid or= multiple meters generating alert packets in a region at the same time, a r= eactive protocol like LOAD-ng will lead to the break-down of the network. A= nyone can say multicast traffic or several meters reporting emergency at th= e same time to the same station, is a very much likely situation in smart g= rid. Were these situations considered during deployment? Please note, I am = NOT saying that=A0AODVv2 / DYMO will be better in this case than LOAD-ng.

But why are you opting for option 1 then? = That seems not logical. You argue against reactive protocols in general.=A0= All what you say above is known to MANET, long before ROLL and LLN even exi= sted.

=A0
IMHO, any= protocol can be shown 'working perfectly', if we provide a favorab= le atmosphere only for it to work.

Yes, I agree. You say yourself, no-one-siz= e-fits all, which is why MANET works on both reactive and proactive protoco= l.
=A0
Looking at that perspective, I don't think, LOAD-ng working in= one network under one particular scenario should be considered a vital arg= ument to discuss whether to go with AODVv2 or LOAD-ng.

LOADng has one large-scale deployment, DYMO does not. L= OADng has multiple recent interoperable implementations, DYMO has not. LOAD= ng is based on the same mechanism of AODV that is known to work in certain = MANET scenarios. So why do you opt for 1) and not 3)?

=A0
=A0
<= /blockquote>
One can write a working code of AODVv2 in 2 days. The real question we= should be asking, which protocol is better suited for general MANET overal= l, and if there really is a *necessity* of discarding a working group docum= ent.
=A0

Secondly, LOAD-ng was devised keeping LLN scenario in m= ind. It was intended for ROLL WG, and since it had not been adopted in the = ROLL WG, it popped up in the MANET WG. The change that has been done to LOA= D-ng after dragging it to MANET WG, was really to change the message format= to adhere to RFC 5444,

That is true, the work was initiated from = LLNs. However, as you say yourself, it has adopted RFC5444 and other MANET = requirements. Note that amongst the authors, there are a large part of the = previous RFC editors of MANET presented. We know MANETs and their requireme= nts. Can you point out a specific requirement that LOADng would not fulfill= but DYMO would?

=A0
and do a = "find and replace" of the term LLN with 'MANET' along wit= h changing the first 'L' of LOAD ng from 'LLN' to 'Ligh= tweight'. Since the protocol was designed for LLN at first, I do not th= ink it would be able to cover the broad spectrum that MANET includes.

Why? And why does DYMO? I don't see a = technical argument.

=A0
Since we already have a WG document for a reactive protocol, I do not = see any strong reason to discard the current one in favor of an individual = draft, especially when even LOAD-ng authors agreed that this protocol will = not offer any notable performance difference compared to AODVv2.=A0

Yes, but the document is not aligned with = the RFC5444 architecture, it is not possible to secure, and it would be a l= ot more work to come to an RFC, in my opinion (lots of unclear and underspe= cified text, incomplete IANA section, unclear metrics, underspecified bidir= ectionality detection).

=A0

At the same time, since I have read both drafts, I figu= red out that AODVv2 is more generic to MANET than LOAD-ng. It offers the de= veloper or the deployment authority to chose form more than one options.

Options may be fine, but they also affect = interoperability if not carefully designed. And they may, as for some of th= e options like iRREP, make it very difficult or impossible to provide end-t= o-end security.

=A0
For examp= le, AODVv2 has the option (but it is not mandated) to use a precursor list = or have an intermediate node to reply an RREQ. LOAD-ng does not support eit= her.

That is not true. We opted to move these i= n companion document, as we have not seen proof that these options would br= ing benefit in a general MANET case.=A0
=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
I can understand that for an LLN it may be beneficial for not maintai= ning a precursor list or having only the destination reply t o a RREQ, ther= e can be (and are) other instances of MANETs where having the option of pre= cursor list will come handy.

Which? Can you show results that this is b= eneficial in a general use case?

=A0
This can save on control overhead, using some storage space in the nod= e. LOAD-ng, in most cases does not provide this flexibility to the develope= r to chose between options for specific deployment.

Again, not true. We provide TLVs, and extensions are po= ssible in companion documents. We have very carefully designed each RFC2119= word to make sure extensions are allowed. Multiple options always carry a = great risk of non-interoperability.

=A0
Some MANET= deployment may be less harsh than others in nature. Hence, AODVv2 having m= ore open options than LOAD-ng, in most cases, seem beneficial to me.

"seems beneficial"? Have you pro= of for the use of the options?

=A0
Of course, there are other technical differences between these protoco= ls. But I believe there is a separate thread created for that. I will wait = for the draft authors to reply there first, and will reply with my points i= f all those differences are not covered. There, I will re-iterate the neces= sity of a protocol to be suited for MANET in general, not only 'some= 9; kind of MANETs=A0

Lastly, I do not come from any industry, neither I have= any company road-map of=A0deliverable=A0here. Being a PhD candidate in a u= niversity, I tried to fairly judge the two options.=A0

So I read both drafts= , and did not find a strong enough reason to discard a current working grou= p document. Whether a few companies backing up a protocol over the other ca= n be a decisive criteria to chose a standard protocol or not, is in the WG = and its chairs most capable hands. Also, I did not, very clearly understand= how LOAD-ng, operating properly in a 2-5 routers=A0test-bed=A0may be consi= dered as proof of valid interoperability.=A0

Why not? What would it change to add 100 n= odes? I have never seen any interop tests with more than a handful nodes. A= gain: interop tests are not performance tests.=A0
By the way, I h= ave not seen any such open interoperability tests during the development of= DYMO .

=A0
I would ve= ry much appreciate feedback if I am wrong, since I am in my learning phase = :-) . I have my 2 cents here - a) AODVv2 offers more flexibility,

As said, LOADng offers the same flexibilit= y. Flexibility is nice, but one has to be very careful with interoperabilit= y.=A0If LOADng were to be a WG document, of course the WG can discuss if ce= rtain options bring a general benefit and don't harm interoperability, = then we can include it.

=A0
b) LOAD-ng= does not offer enough advantage over AODVv2 to discard the later,

One major advantage is that it could be an RFC far quic= ker. In the current shape, the SEC AD would certainly not accept DYMO, and = it would require a lot more work to bring to a level that is acceptable for= a standards track RFC.=A0

=A0
c) LOAD-n= g was not initially designed for MANET,

I don't see the argument here (see above)
=A0
and d) there are other technical differences tha= t make AODVv2 more suitable for MANETs over LOAD-ng (To be covered in separ= ate thread). =A0

I am curious to see that.

Best
Ulrich
=A0
My opinion - We should stick to current WG document (AODVv2) and impro= ve it and finish it as soon as possible. I hereby stand for Option 1= .=A0

Thanks and Regards,

Joydeep Tr= ipathi
PhD Candidate,=A0
Drexel University.


On Tue, Oct 30, 2012 at 7:13 PM, Joseph Macker <<= a href=3D"mailto:jpmacker@gmail.com" target=3D"_blank">jpmacker@gmail.com> wrote:
Hello MANET working = group (form Stan and Joe),

As you are all probably aware, there has = been WG activity lately on competing drafts for a MANET reactive protocol -= DYMO (reviving the current working group document that was parked due to i= nactivity), and LOADng. Many months ago there was a somewhat authorship led= movement towards a common document effort and given positive feedback at t= he time we the chairs thought this was the best approach given the authors = potential to come together and gain the best of both efforts.=A0 Since that= period, there has been some fairly strident and rancorous "at times&q= uot; debate between the authors of the two documents.

During IETF 84 in Vancouver, the co-chairs held= a discussion with some of the co-authors of the two documents. Our guidanc= e to the co-authors was to find a way to merge the two documents into one, = as it was perceived that are not technically far apart and they both derive= roughly from AODV concepts and LOADng had fairly active authorship and imp= lementation efforts. We provided a co-editing proposal to the authors and g= ave them the timeframe of the Atlanta to come up with an answer back to us = regarding this.=A0 As of this writing, those discussions of a potential com= monn document and authorship merger have failed.

Therefore, we find ourselves at a crossroads. T= he authors of the two documents are divided, and it is unlikely that progre= ss on a merged document can be reached based upon recent author feedback. I= have also polled the earlier WG editor of DYMO, Ian Chakeres, and he is so= mewhat disengaged on the issue at the present time.=A0 We see only 3 possib= le paths forward:

1. Continue the work on the DYMO document, starting with whether there = is consensus on its continued approach and also the desire to rename it to = AODVv2.
2. Replace the existing DYMO document ef= fort with the LOADng related document effort, defusing ealier references to= LLNs as recommended in the last meeting minutes, and to focus more motivat= ionally on general MANET problem spaces (the authors seem to have agreed to= this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on= the options.=A0 We have been some silent collecting initial feedback and w= aiting for author feedback at this point.=A0 Stan and I are both on travel = prior to Atlanta so our responses may be sparse and we will also likely be = in a "receive mode" for a few days.=A0 So send your opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--047d7b6da1884cf87004cd7933e5-- From pal@cs.stanford.edu Thu Nov 1 19:20:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DFE21F96DD for ; Thu, 1 Nov 2012 19:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.297 X-Spam-Level: X-Spam-Status: No, score=-4.297 tagged_above=-999 required=5 tests=[AWL=2.302, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3DSnVpxY5EJ for ; Thu, 1 Nov 2012 19:20:43 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDE421F96BD for ; Thu, 1 Nov 2012 19:20:43 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TU6sE-0000Dg-6O; Thu, 01 Nov 2012 19:20:42 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722049B35@xmb-rcd-x02.cisco.com> Date: Thu, 1 Nov 2012 17:53:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <140565C6-B4AB-4EE1-844C-81B9F1633013@cs.stanford.edu> References: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220465DF@xmb-rcd-x02.cisco.com> <3D320804-EE40-42FB-BF08-3F662B3F9542@axelcdv.com> <6C031880-6176-491E-B822-CCE6B8B586FC@cs.stanford.edu> <03B78081B371D44390ED6E7BADBB4A7722049B35@xmb-rcd-x02.cisco.com> To: JP Vasseur (jvasseur) X-Mailer: Apple Mail (2.1283) X-Scan-Signature: 3912120d3a1bcf28d29a6770933a4e79 Cc: "Dearlove, Christopher \(UK\)" , " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 02:20:43 -0000 100% agree -- totally misinterpreted Christopher's comment, my mistake. = I apologize for the (thankfully nipped) digression. Phil On Nov 1, 2012, at 12:27 PM, JP Vasseur (jvasseur) wrote: > Indeed - we're diverging from the original question. >=20 > On Nov 1, 2012, at 6:12 PM, Ulrich Herberg wrote: >=20 >> Hi Phil, >>=20 >> maybe we should open a separate email thread about RPL and = draft-clausen-lln-rpl-experiences (and probably not in this WG). >>=20 >> Best >> Ulrich >>=20 >> On Thu, Nov 1, 2012 at 9:45 AM, Philip Levis = wrote: >> On Nov 1, 2012, at 9:27 AM, Dearlove, Christopher (UK) wrote: >>=20 >>> They can be good evidence of the failure of protocols ;) >>>=20 >>> But what is clear to me is that one important issue (and another of = my posts is attempting to both be more precise, as well as going = elsewhere) is the handling of unidirectional links. So any good evidence = needs to consider those. >>=20 >> Since communication in wireless is rarely binary, I think the more = common term is asymmetric links. I'm confused; I don't believe that unit = disc models capture asymmetric links. Is the implied statement that RPL = doesn't properly handle asymmetric links but LOADng does? I think this = came up in draft-clausen-lln-rpl-experiences and there was some = discussion on the ROLL list about it. The neighbor set in RPL is defined = in 8.2.1: >>=20 >> "First, the candidate neighbor set is a subset of the nodes that can = be reached via link-local multicast." >>=20 >> then in DIO processing (8.2.3.1) it reads: >>=20 >> "As DIO messages are received from candidate neighbors, the neighbors = may be promoted to DODAG parents by following the rules of DODAG = discovery as described in Section 8.2." >>=20 >> I want to be clear here; I haven't read deeply about LOADng, thought = about it much, or experimented with it at all. So I have zero to say = about LOADng's strengths and weaknesses. >>=20 >> But just because somebody publishes (and republishes) a draft saying = something doesn't mean it's true. There are, in my opinion, some very = valid points in draft-clausen-lln-rpl-experiences that relate to = fundamental design decisions in RPL. For example, I think that the = issues raised about the state requirements of floating DODAGs and RPL = message fragmentation are valid and reasonable and something we need to = look at. >>=20 >> However, there are others that are the result of naive mistakes = anyone can make when implementing any wireless routing protocol, such as = link asymmetry and protocol convergence. Unfortunately the draft doesn't = distinguish the two. Implementing a protocol poorly then saying it = doesn't work isn't particularly meaningful. As I said in Paris, I = thought the draft is valuable because it outlines many of the basic = mistakes one makes the first time you try implementing a wireless = routing protocol. >>=20 >> Phil >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From jblack.ietf@yahoo.com Thu Nov 1 20:40:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C925921F97E9 for ; Thu, 1 Nov 2012 20:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV2MUj9uGcir for ; Thu, 1 Nov 2012 20:40:09 -0700 (PDT) Received: from nm21-vm0.bullet.mail.bf1.yahoo.com (nm21-vm0.bullet.mail.bf1.yahoo.com [98.139.213.137]) by ietfa.amsl.com (Postfix) with ESMTP id C92B921F95CC for ; Thu, 1 Nov 2012 20:40:08 -0700 (PDT) Received: from [98.139.215.143] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 03:40:08 -0000 Received: from [98.139.212.239] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 03:40:07 -0000 Received: from [127.0.0.1] by omp1048.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 03:40:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 985385.71845.bm@omp1048.mail.bf1.yahoo.com Received: (qmail 25926 invoked by uid 60001); 2 Nov 2012 03:40:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351827607; bh=putQJQx/s7WGl8xMfRlycbrIgW1n9gKJxJp9bbXTNwU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RalKvWd8lXXFUPhUxX9fJKZHnSv5Wbyji6Uu751X4hjBGrWwQ9NRIhAtRHpExtqIDmOKhNKPpPc7HCW5OBMbMbIk/ZdR/pH4pETlQCqSoAaaTxJq0C1lcCythmCgLhh9pn75NnB/oAjl8fMix+VE5iN8qAom9UBwv2ysV7sVA7A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=h7enAW7qDNq7AHNqV5Vkecj5jwTJrl8/bzmO5aUid4zxrR90WeVdmPrkX6KcLge7CI5t2AuWtzZvXPWu0FGkmAjtOIFwWgud3Y1pfLOe/ATIARUAECtk+YPR4I/mgAHKavj376zCg9rhiZURRTOeOPnLc7EBJf0NDSGYPy9020g=; X-YMail-OSG: NUY0_PsVM1lMv_6pnI4jisj6tXGYc42d4jcSsPyzSE5somK 79I3RYhHR7EW6.Tcl5J0o69VGqbgWLdlCRpP686DcGl.6mU8GB0sY7AYNTu3 T5boYfrMMthHyGh7A7q4sp35qMk6zW7rQLIg1qnoJhgYL5bmYFGQ0oOG9Spf KnoZW3JMWX_P37OriVcHk8hHgi66E7YZt.wBaRBkscWVc_XXF.kqXaqhRmAC AYJcPlJ14KmL.g9ap9FXbVphlFzDApaQyi70sB315Ed2rDvZa8czd5nYsNG0 Y11kx1l__qLm1yPDXpRVbIqgkL5XETA4x1x9wodl8T7R_OTmHrHRbyY235th cJV0.Dvv3llFlfHU6DwqWankeWsLokZgk78Ebj_TqvMh_o0Jd1dTs.nmoqRA F.3fuVk9Hy0.X99sL1A79.LJp93T5kQgIpYXgf6cUiQFjGwgECgbD0rG_Udr Ndio4EU_2hG49k5n5YIydgJWmX4NmbRsa_FfWph5zOp_A25qvb9xs0tc31it CTgxcAoy3ZqDnxSLKOTpYNQ-- Received: from [67.213.218.74] by web160605.mail.bf1.yahoo.com via HTTP; Thu, 01 Nov 2012 20:40:07 PDT X-Rocket-MIMEInfo: 001.001, QnV0IG9waW5pb25zIHdpdGhvdXQgc29tZSB0ZWNobmljYWwgZGV0YWlscyB0dXJucyBpbnRvIGEgYmVhdXR5IGNvbnRlc3QgYW5kIEkgZG9uJ3QgdGhpbmsgdGhhdCBpcyB3aGF0IHRoZSBjaGFpcnMgd2VyZSBhZnRlci4KCkpvbgoKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBKUCBWYXNzZXVyIChqdmFzc2V1cikgPGp2YXNzZXVyQGNpc2NvLmNvbT4KVG86IEpvbiBCbGFjayA8amJsYWNrLmlldGZAeWFob28uY29tPiAKQ2M6IEFiZHVzc2FsYW0gQmFyeXVuIDxhYmR1c3NhbGEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com> <1351784668.10346.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049577@xmb-rcd-x02.cisco.com> Message-ID: <1351827607.38598.YahooMailNeo@web160605.mail.bf1.yahoo.com> Date: Thu, 1 Nov 2012 20:40:07 -0700 (PDT) From: Jon Black To: "JP Vasseur \(jvasseur\)" In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722049577@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1933122451-1098527176-1351827607=:38598" Cc: manet Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 03:40:15 -0000 ---1933122451-1098527176-1351827607=:38598 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable But opinions without some technical details turns into a beauty contest and= I don't think that is what the chairs were after.=0A=0AJon=0A=0A=0A=0A=0A= =0A________________________________=0A From: JP Vasseur (jvasseur) =0ATo: Jon Black =0ACc: Abdussalam Bary= un ; manet =0ASent: Thursday, = November 1, 2012 12:36 PM=0ASubject: Re: [manet] Reactive Protocol Situatio= n=0A =0A=0A=0A=0AOn Nov 1, 2012, at 4:44 PM, Jon Black wrote:=0A=0AI disagr= ee.=A0 The protocol has progressed.=A0 It appears that there are implementa= tions.=A0 There is interoperability.=A0 There are deployments.=A0 This is a= ll progress.=0A>=0A>I'm not favoring LOADng over DYMO.=A0 I think the worki= ng group should look at both fairly and decide the best path forward - chos= e one over the other or find a way to merge the concepts even if the author= s are hesitant.=0A>=0A=0ARight and I think that this was what the chairs as= ked us to do: express our opinion on which option we prefer.=0ALet's wait u= ntil everybody express an opinion and see what the chairs think.=0A=0AThank= s.=0A=0AJP.=0A=0A=0A=0A>Jon=0A>=0A>=0A>=0A>=0A>=0A>=0A>____________________= ____________=0A> From: Abdussalam Baryun =0A>To= : manet =0A>Sent: Thursday, November 1, 2012 8:28 AM=0A>Su= bject: Re: [manet] Reactive Protocol Situation=0A>=0A>=0A>On Wed, Oct 31, 2= 012 at 10:02 AM, Dearlove, Christopher (UK) = wrote:=0A>=0A>As someone who has not (yet) stated an opinion on the matter= , except I also think option 3 is not good, I would very much like to hear = technical arguments, so if you have technical arguments against LOADng, I t= hink we need to hear them rather than just suggesting they exist. I haven't= yet read LOADng carefully to form a view there. I have just recently read = the AODVv2 draft carefully, and have some technical issues there (which ove= rlap) regarding asymmetric links, possible dependency on NHDP, and the comp= atibility of options. If option 1 is followed, the draft needs work (which = Charlie has acknowledged).=0A>>=A0=0A>>=A0=0A>I don't think we have time to= waste with LOADng, it was presented twice and no progress, the authors fai= led to discuss on MANET list, and failed to update the draft to match MANET= reuirements. I agree that we focus our efforts to submit AODVv2 as soon as= possible,=0A>=A0=0A>AB=0A>=A0=0A>=A0=0A>=A0=0A>>-- =0A>>Christopher Dearlo= ve=0A>>Senior Principal Engineer, Communications Group=0A>>Communications, = Networks and Image Analysis Capability=0A>>BAE Systems Advanced Technology = Centre=0A>>West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK=0A= >>Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124=0A>>chris.dearlove@baesy= stems.com | http://www.baesystems.com=0A>>=0A>>BAE Systems (Operations) Lim= ited=0A>>Registered Office: Warwick House, PO Box 87, Farnborough Aerospace= Centre, Farnborough, Hants, GU14 6YU, UK=0A>>Registered in England & Wales= No: 1996687=0A>>=A0=0A>>From:manet-bounces@ietf.org [mailto:manet-bounces@= ietf.org] On Behalf Of JP Vasseur (jvasseur)=0A>>Sent: 31 October 2012 08:2= 9=0A>>To: Joseph Macker=0A>>Cc: =0A>>Subject: Re: [manet] R= eactive Protocol Situation=0A>>=A0=0A>>=A0=0A>>*** WARNING ***=0A>>This mes= sage originates from outside our organisation, either from an external part= ner or the internet.=0A>>Keep this in mind if you answer this message.=0A>>= Please see this process on how to deal with suspicious emails.=0A>>Dear cha= irs, =0A>>=A0=0A>>Remembering that I am not a co-authors of either of these= drafts.=0A>>=A0=0A>>Not commenting on recent discussions but rather focuss= ing on what I hope will be a good solution for the WG and the Internet at l= arge.=0A>>=A0=0A>>Option 3) is my opinion not desirable; I wish we could ha= ve a reactive routing protocol for MANET=0A>>=A0=0A>>Option 2) is an option= I would be strongly opposed to for a number of technical reasons that I wo= uld be happy to elaborate on the=0A>>mailing list and/or in a new I-D (whic= h I would, should option 2 be chosen).=0A>>=A0=0A>>That being said, I am ex= tremely supportive of option 1), especially in light of what Charlie said. = First of all DYMO is the working group=0A>>document and excellent progress = has been made with recent revisions. But even more importantly, Charlie man= aged to make it compatible=A0=0A>>with options, which is in=A0my opinion th= e best of both worlds; calling it AODVv2 is only not very sensible but avoi= ds useful sensitivity around=A0=0A>>names.=0A>>=A0=0A>>Thus I would strongl= y support Option 1), continue the work that Charlie has started, which by t= he way is not far from completion. And=A0=0A>>as WG,we need to remember tha= t this had been the WG document, the result of years of work. Still by maki= ng it compatible with other options,=A0=0A>>this is technically flexible an= d sound.=0A>>=A0=0A>>Thanks.=0A>>=A0=0A>>JP.=0A>>=A0=0A>>On Oct 31, 2012, a= t 12:13 AM, Joseph Macker wrote:=0A>>=0A>>=0A>>=0A>>Hello MANET working gro= up (form Stan and Joe),=0A>>=0A>>As you are all probably aware, there has b= een WG activity lately on competing drafts for a MANET reactive protocol - = DYMO (reviving the current working group document that was parked due to in= activity), and LOADng. Many months ago there was a somewhat authorship=0A l= ed movement towards a common document effort and given positive feedback at= the time we the chairs thought this was the best approach given the author= s potential to come together and gain the best of both efforts.=A0 Since th= at period, there has been some fairly=0A strident and rancorous "at times" = debate between the authors of the two documents.=0A>>=0A>>During IETF 84 in= Vancouver, the co-chairs held a discussion with some of the co-authors of = the two documents. Our guidance to the co-authors was to find a way to merg= e the two documents into one, as it was perceived that are not technically = far apart and they=0A both derive roughly from AODV concepts and LOADng had= fairly active authorship and implementation efforts. We provided a co-edit= ing proposal to the authors and gave them the timeframe of the Atlanta to c= ome up with an answer back to us regarding this.=A0 As=0A of this writing, = those discussions of a potential commonn document and authorship merger hav= e failed.=0A>>=0A>>Therefore, we find ourselves at a crossroads. The author= s of the two documents are divided, and it is unlikely that progress on a m= erged document can be reached based upon recent author feedback. I have als= o polled the earlier WG editor of DYMO, Ian Chakeres,=0A and he is somewhat= disengaged on the issue at the present time.=A0 We see only 3 possible pat= hs forward:=0A>>=0A>>1. Continue the work on the DYMO document, starting wi= th whether there is consensus on its continued approach and also the desire= to rename it to AODVv2.=0A>>2. Replace the existing DYMO document effort w= ith the LOADng related document effort, defusing ealier references to LLNs = as recommended in the last meeting minutes, and to focus more motivationall= y on general MANET problem spaces (the authors seem to have agreed=0A to th= is issue if its a WG document).=0A>>3. Remove the working group charter for= a reactive protocol, effectively killing both documents, at least from a w= orking group (WG) standpoint. This would not be a reflection on the technol= ogy in either case, just an admission that we are not working together=0A a= nd reaching consensus.=0A>>=0A>>The co-chairs request and need your opinion= s on the options.=A0 We have been some silent collecting initial feedback a= nd waiting for author feedback at this point.=A0 Stan and I are both on tra= vel prior to Atlanta so our responses may be sparse and we will also=0A lik= ely be in a "receive mode" for a few days.=A0 So send your opinions.=0A>>= =0A>>-Joe=0A>>_______________________________________________=0A>>manet mai= ling list=0A>>manet@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/mane= t=0A>>=A0=0A>>*************************************************************= *******=0A>>This email and any attachments are confidential to the intended= =0A>>recipient and may also be privileged. If you are not the intended=0A>>= recipient please delete it from your system and notify the sender.=0A>>You = should not copy it or use it for any purpose nor disclose or=0A>>distribute= its contents to any other person.=0A>>************************************= ********************************=0A>>=0A>>=0A>>____________________________= ___________________=0A>>manet mailing list=0A>>manet@ietf.org=0A>>https://w= ww.ietf.org/mailman/listinfo/manet=0A>>=0A>>=0A>=0A>_______________________= ________________________=0A>manet mailing list=0A>manet@ietf.org=0A>https:/= /www.ietf.org/mailman/listinfo/manet=0A>=0A>=0A>=0A________________________= _______________________=0A>manet mailing list=0A>manet@ietf.org=0A>https://= www.ietf.org/mailman/listinfo/manet=0A> ---1933122451-1098527176-1351827607=:38598 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
But opinions without = some technical details turns into a beauty contest and I don't think that i= s what the chairs were after.

Jon


From: JP Vasseur (jvasseur) <jvasseur@cisco.= com>
To: Jon Black = <jblack.ietf@yahoo.com>
Cc:= Abdussalam Baryun <abdussalambaryun@gmail.com>; manet <= ;manet@ietf.org>
Sent:= Thursday, November 1, 2012 12:36 PM
Subjec= t: Re: [manet] Reactive Protocol Situation
=0A
=0A=0A =0A=0A
=0A
=0A
=0A
On Nov 1, 2012, at= 4:44 PM, Jon Black wrote:
=0A
=0A
=0A
=0A
=0AI disagree.  The proto= col has progressed.  It appears that there are implementations.  = There is interoperability.  There are deployments.  This is all p= rogress.
=0A
=0AI'm not favoring LOADng over DYMO.  I think the = working group should look at both fairly and decide the best path forward -= chose one over the other or find a way to merge the concepts even if the a= uthors are hesitant.
=0A
=0A
=0A
=0A

=0A=0A
Right and I think that this was what the chairs asked us to do:= express our opinion on which option we prefer.
=0A
Let's wait unt= il everybody express an opinion and see what the chairs think.
=0A
=0A
=0A
Thanks.
=0A

=0A
=0A
JP.
= =0A

=0A
=0A
=0A
=0A
=0A
=0A
=0AJon=0A

=0A
=0A

=0A
=0A
=0A=0A
=0A
= =0AFrom: Abdussalam Baryun = <abdussalambaryun@gm= ail.com>
=0ATo: m= anet <manet@ietf.org>=0A
=0ASent: Thursday, November 1, 2012 = 8:28 AM
=0ASubject: Re: = [manet] Reactive Protocol Situation
=0A
=0A
=0A =0A
=0A
On Wed, Oct = 31, 2012 at 10:02 AM, Dearlove, Christopher (UK)=0A<Chris.Dearlove@ba= esystems.com> wrote:
=0A
=0A=
=0A
=0A
As someone who has not (yet)= stated an opinion on the matter, except I also think option 3 is not good,= I would very much like to hear technical arguments, so if you have technic= al=0A arguments against LOADng, I think we need to hear them rather than ju= st suggesting they exist. I haven't yet read LOADng carefully to form a vie= w there. I have just recently read the AODVv2 draft carefully, and have som= e technical issues there (which overlap)=0A regarding asymmetric links, pos= sible dependency on NHDP, and the compatibility of options. If option 1 is = followed, the draft needs work (which Charlie has acknowledged).<= /u>
=0A
 
=0A
 
=0A
=0A
=0A
=0A
I don't = think we have time to waste with LOADng, it was presented twice and no prog= ress, the authors failed to discuss on MANET list, and failed to update the= draft to match MANET reuirements. I agree that we focus our efforts to sub= mit AODVv2 as soon=0A as possible,
=0A
 
=0A
AB=0A
 
=0A
 
=0A
= =0A
=0A
=0A
 
=0A=0A
--=0A
=0A
Chr= istopher Dearlove
=0A
Senior Princ= ipal Engineer, Communications Group
=0ACommunications, Networks and Imag= e Analysis Capability
=0ABAE Systems Advanced Technology Centre
=0AWe= st Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
=0ATel: +44 1245 242194 |  Fax: =0A+44 1245 242124
=0Achris.dearlove@baesys= tems.com=0A | http://www.baesystems.com
=0A
=0ABAE Systems (Operations) L= imited
=0ARegistered Office: Warwick House, PO Box 87, Farnborough Aeros= pace Centre, Farnborough, Hants, GU14 6YU, UK
=0ARegistered in England &= amp; Wales No: 1996687
=0A
=0A
 
=0A
=0A
=0A
From:=0A=0Amanet-bounces@ietf.org [mailto:manet-bounces@ietf.org]=0AOn Behalf O= f JP Vasseur (jvasseur)
=0ASent: 31 October 2012 08:29
=0A= To: Joseph Macker
=0ACc: <manet@ietf.org>
=0ASubject: Re: [manet] Reactive Protocol= Situation
=0A
=0A
=0A
 
=0A
=0A
=0A=  
=0A
=0A
=0A*** WARNING ***
=0A
=0A
=0A
=0AThis message originates from outside our organisation, either from an exte= rnal partner or the internet.
=0AKeep this in mind if you = answer this message.
=0APlease see =0Athis process on how to deal with suspicious emails.<= u>
=0A
=0A
=0A
=0A
=0A
Dear chairs, =0A
=0A
 =0A
=0A
=0A
Remembering th= at I am not a co-authors of either of these drafts.
=0A<= div>=0A
 
=0A<= /div>=0A
=0A
Not commenting on = recent discussions but rather focussing on what I hope will be a good solut= ion for the WG and the Internet at large.
=0A
= =0A
=0A
 
= =0A
=0A
=0A
Option 3) is my o= pinion not desirable; I wish we could have a reactive routing= protocol for MANET
=0A
=0A
=0A
 
=0A
=0A
=0A
Option 2) is an option I would be stro= ngly opposed to for a number of technical reasons that I would be h= appy to elaborate on the
=0A
=0A
=0A
mailing list and/or in a new I-D (which I would= , should option 2 be chosen).
=0A
=0A
=0A
 
=0A
=0A
= =0A
That being said, I am extremely= supportive of option 1),=0Aespecially in light of what Charlie said= . First of all DYMO is the working group
=0A
= =0A
=0A
document and excellent pro= gress has been made with recent revisions. But even more importantly, Charl= ie managed to make it compatible 
=0A
=0A
= =0A
with options, which is in my = opinion the best of both worlds; calling it AODVv2 is only not very = sensible but avoids useful sensitivity around 
=0A<= /div>=0A
=0A
names.<= /div>=0A
=0A
=0A
 = ;
=0A
=0A
=0A
= Thus I would strongly support Option 1), continue the work that Charlie has= started, which by the way is not far from completion. And =
=0A
=0A
=0A
as W= G,we need to remember that this had been the WG document, the result of yea= rs of work. Still by making it compatible with other options, <= u>
=0A
=0A
=0A
this = is technically flexible and sound.
=0A
=0A
=0A<= div class=3D"yiv1116695338MsoNormal"> 
=0A
=0A=
=0A
Thanks.
= =0A
=0A
=0A
 <= /u>
=0A
=0A
=0A
JP.
=0A
=0A
=0A
 
=0A
=0A
=0A
On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:=0A
=0A

=0A
=0A=
=0A
Hello MANET working grou= p (form Stan and Joe),
=0A
=0AAs you are all probably aware, there ha= s been WG activity lately on competing drafts for a MANET reactive protocol= - DYMO (reviving the current working group document that was parked due to= inactivity), and LOADng. Many months ago there was a somewhat authorship= =0A led movement towards a common document effort and given positive feedba= ck at the time we the chairs thought this was the best approach given the a= uthors potential to come together and gain the best of both efforts.  = Since that period, there has been some fairly=0A strident and rancorous "at= times" debate between the authors of the two documents.
=0A
=0ADurin= g IETF 84 in Vancouver, the co-chairs held a discussion with some of the co= -authors of the two documents. Our guidance to the co-authors was to find a= way to merge the two documents into one, as it was perceived that are not = technically far apart and they=0A both derive roughly from AODV concepts an= d LOADng had fairly active authorship and implementation efforts. We provid= ed a co-editing proposal to the authors and gave them the timeframe of the = Atlanta to come up with an answer back to us regarding this.  As=0A of= this writing, those discussions of a potential commonn document and author= ship merger have failed.
=0A
=0ATherefore, we find ourselves at a cro= ssroads. The authors of the two documents are divided, and it is unlikely t= hat progress on a merged document can be reached based upon recent author f= eedback. I have also polled the earlier WG editor of DYMO, Ian Chakeres,=0A= and he is somewhat disengaged on the issue at the present time.  We s= ee only 3 possible paths forward:
=0A
=0A1. Continue the work on the = DYMO document, starting with whether there is consensus on its continued ap= proach and also the desire to rename it to AODVv2.
=0A2. Replace the exi= sting DYMO document effort with the LOADng related document effort, defusin= g ealier references to LLNs as recommended in the last meeting minutes, and= to focus more motivationally on general MANET problem spaces (the authors = seem to have agreed=0A to this issue if its a WG document).
=0A3. Remove= the working group charter for a reactive protocol, effectively killing bot= h documents, at least from a working group (WG) standpoint. This would not = be a reflection on the technology in either case, just an admission that we= are not working together=0A and reaching consensus.
=0A
=0AThe co-ch= airs request and need your opinions on the options.  We have been some= silent collecting initial feedback and waiting for author feedback at this= point.  Stan and I are both on travel prior to Atlanta so our respons= es may be sparse and we will also=0A likely be in a "receive mode" for a fe= w days.  So send your opinions.
=0A
=0A-Joe
=0A______________= _________________________________
=0Amanet mailing list
=0Amanet@ietf.org
=0Ahttps://www.ietf= .org/mailman/listinfo/manet
=0A
=0A
 
=0A
=0A
=0A=
=0A
=0A
=0A
=0A*****************************************= ***************************
=0AThis email and any attachments are confid= ential to the intended
=0Arecipient and may also be privileged. If you a= re not the intended
=0Arecipient please delete it from your system and n= otify the sender.
=0AYou should not copy it or use it for any purpose no= r disclose or
=0Adistribute its contents to any other person.
=0A****= ****************************************************************
=0A
= =0A
=0A
=0A_______________________________________________
=0Ama= net mailing list
=0Amanet@ietf.org
= =0Ahttps://www.ietf.org/mailman/listinfo/manet
=0A=0A
=0A
=0A
=0A
=0A =0A
=0A__________________= _____________________________
=0Amanet mailing list
=0Amanet@ietf.org
=0Ahttps://www.ietf.org= /mailman/listinfo/manet
=0A
=0A
=0A
=0A
=0A
=0A=
=0A_______________________________________________
=0Amanet mailin= g list
=0Amanet@ietf.org
=0Ahttps:/= /www.ietf.org/mailman/listinfo/manet
=0A
=0A
=0A
=0A=
=0A=0A


---1933122451-1098527176-1351827607=:38598-- From prvs=64690afaf=mukul@uwm.edu Thu Nov 1 20:46:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C60121F9900 for ; Thu, 1 Nov 2012 20:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCiJb21Ka1Dm for ; Thu, 1 Nov 2012 20:46:46 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id E41A721F98FF for ; Thu, 1 Nov 2012 20:46:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAN1Bk1B/AAAB/2dsb2JhbABEhhfAQQEBAQMBAQEBIDIZCwUHDxEEAQEBAgINGQIpKAgGE4gABguqKolgiQiBIIpbFAGFE4ETA4hagm6KMIZYiWuDDYE9AQgXHg Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 50EAF2A16F5; Thu, 1 Nov 2012 22:46:43 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sScuACELWNIK; Thu, 1 Nov 2012 22:46:42 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id BB4092A16D4; Thu, 1 Nov 2012 22:46:42 -0500 (CDT) Date: Thu, 1 Nov 2012 22:46:42 -0500 (CDT) From: Mukul Goyal To: Ulrich Herberg Message-ID: <2040745028.185576.1351828002677.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: "Christopher Dearlove \(UK\)" , manet@ietf.org, "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 03:46:47 -0000 Hi Ulrich Thanks for pointing out the key differences between the two protocols. Going over this list and having read both drafts, I have the following opinion: 1) It seems to me that there are no technical reasons why the two drafts cannot be merged. The fact that it was not possible to merge the two proposals is unfortunate. 2) Perceived strengths of LOADng, such as facilitating end-to-end security, can easily be adopted in DYMO/AODV2. Bidirectionality verification can be done either inside the protocol or in an independent manner. 3) It seems to me that, functionality wise, LOADng is a restricted version of DYMO/AODVv2. In other words, it is possible to configure a DYMO deployment to behave like a LOADng deployment. Charlie made the same point in an earlier message. If LOADng is chosen in place of DYMO/AODVv2, we will lose nice features you pointed out: "- DYMO has several options for expanding ring RREQ, precursor list, adding route information in transit, message aggregation in RFC5444 packets and reporting multiple unreachable addresses in a RERR." These features seem useful in general MANET scenarios. Just my $0.02. Thanks Mukul ----- Original Message ----- From: "Ulrich Herberg" To: "Christopher Dearlove (UK)" Cc: manet@ietf.org, "Thomas Heide Clausen (thomas@thomasclausen.org)" Sent: Thursday, November 1, 2012 5:02:05 PM Subject: Re: [manet] Reactive routing protocols, what are the differences? Hi Chris, you have seen my review on DYMO. I will try to answer to your question, and focus on the technical differences, not presentation. On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK) wrote: > The obviously best people to answer this should be document authors, but anyone else may have useful additions and comments. Ideally the different document authors could agree a list. (If they differ in that one has X and the other doesn't, but one wants to say "we plan to add/remove X" then X should be listed as a difference with that caveat, in at least my ideal world.) > > If we set aside, for the moment (though these things matter): > - The presentational quality of the documents, > - Any issues of 5444 compliance and other formatting issues, > - Issues of internal data organisation, > - Minor details such as possible different timeout parameters etc. > then what are the technical (and I stress that word) differences between DYMO and LOADng? (I'm withholding the term AODVv2 for reasons I may come back to.) First, let's see what is common. Both are reactive protocols, using RREQ, RREP and RERR. So if someone claims that DYMO performs great and LOADng badly in the same scenario, I cannot understand that. MANET has understood the scenarios where reactive protocols are useful and where not. Now, to the differences: - DYMO cannot be end-to-end secured. Messages are changed in transit (and not just hop-limit or the metric), but rather addresses can be removed from RERRs and RREQs. There is also no provision to allow external mechanisms to add additional reasons to reject messages as invalid. - DYMO uses the originator address in an address block, LOADng in the message header. The sequence number is a TLV value in DYMO, and LOADng uses the message sequence number. DYMO requires the originator address to be the first one in the address block, the destination must be the second one. LOADng uses a TLV to determine the target address. - DYMO can advertise multiple addresses in an RERR; they can be removed in transit of the message. - DYMO allows intermediate routers to reply (as an option). That makes end-to-end security difficult. In the core DYMO, there is a destination sequence number that may be contained in RREQs in DYMO. - DYMO allows for unicast RREQ, but does not specify in detail how to use that. - There are four timers for each route entry in DYMO, only one in LOADng. - LOADng can be used on other layers; DYMO is tied to IP. - LOADng provides a bidirectionality verification using RREP_ACK, a time-out of these, a blacklisted set and a Pending Acknowledgment Set to verify bidirectional links. DYMO says that other mechanisms can be used, but does not specify these. - DYMO has several options for expanding ring RREQ, precursor list, adding route information in transit, message aggregation in RFC5444 packets and reporting multiple unreachable addresses in a RERR. LOADng takes the approach to have a slim core of a basic mechanism that is applicable in all MANET use cases, and companion documents with extensions. In DYMO, it is not clearly specified what happens if some routers support an option, and others don't. - LOADng uses a Metric message TLV, and it is clearly defined how to update the metric under way. If a router in transit does not recognize a route metric type, it is reset to a "hop count" tlv extension type of the Metric TLV and the value set to 0xFFFFF... (for the full TLV length). It is specified that security mechanism must ignore the content of the metric TLV value and that the length cannot be changed under way, so that end-to-end security is possible. DYMO uses an optional "distance" field for the metric, which is not clearly specified how it is updated. Also, since this is optional, it is unclear if routers receiving a message and forwarding it, update the distance field or not. - LOADng allows for (optionally) waiting to reply with a RREP, in case a "better" RREQ comes a little later. In DYMO, a RREP is always sent immediately. There are probably more differences, but I let other chime in. Best regards Ulrich > Note that it's a lot more useful to have direct differences than differences of each from AODV (especially when both have the same difference). And it would be useful to have the objective differences separated from the "and now why this is better" discussion - though that would be a next step. > > I'm not saying I don't see any of the differences. But I certainly haven't worked out the complete list. In trying to form my view of how things should go forward (a view that is coming together, and when it does, I'll argue for it) and I hope for other people as well, it would be good to know what the differences are. Regardless of views for or against each, we should be able to objectively list the significant differences - if we can't then something is wrong. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > ******************************************************************** > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From jblack.ietf@yahoo.com Thu Nov 1 20:51:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BDD21F98EC for ; Thu, 1 Nov 2012 20:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeiUgaI+jYs3 for ; Thu, 1 Nov 2012 20:51:50 -0700 (PDT) Received: from nm16-vm0.bullet.mail.bf1.yahoo.com (nm16-vm0.bullet.mail.bf1.yahoo.com [98.139.212.253]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8E421F98EB for ; Thu, 1 Nov 2012 20:51:49 -0700 (PDT) Received: from [98.139.212.148] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 03:51:48 -0000 Received: from [98.139.212.233] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 03:51:48 -0000 Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 03:51:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 530180.68482.bm@omp1042.mail.bf1.yahoo.com Received: (qmail 3898 invoked by uid 60001); 2 Nov 2012 03:51:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351828308; bh=p8uaa/52acfD0LpTM1mSjGC1iab+cy2/4BwEGt1lbME=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=K1bp1X+tACZDbh9oxgsvYS3mO24r3Pyk7Q5srTEoBefLyhRQY50QG+MngsyiO1rYxNaJxUPdLC1nyQJpYH6eNKYsqTQgeJX+/2atId55SGjS+wGpe27i7ArmYD011GbCi7Y0tbSUH7WNJqUCqIuXuvCogE9zFe4h1D1cqkGrulw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=2J0JeCP4k4T0OtC7iKEKF6ARmiw2RfKPSsPtxellCM+sgPCZwG4GqlIUfcj5FwLpEhflUInHynHvuejhY+pLiMloWXr0mcCoUdvJO6fou1IGayLenyWq4dRfQAAQom0aCm4F1sAFRSKi55RbPbzD3sceuUhHOF1WBXrGTvFh1rw=; X-YMail-OSG: d2RtvBIVM1niFZkQIHNOma56DhXsEsQXJXmkQ1LWuy1z.mj qHwAzMt_wyhyH8oSIe6KFGm5OqbPv1tyMulDhHJDlX0ZXGQt0PBl0et5qSr8 3lKxKBD3pYXyLVeyi.dsIcG5XS9E5_qr7NcGDGAdhi4VUAgWKTqiafZrU_Tg dums5YrUkZRrDZ3jwp4l.oNR0xoyaDC4ew1XhygySc3cdDX.mbLXj.uni0vi yhOSVPccQI6xYLp8WnrskseitwoiXQSTGGMNre7bR_BOAOnx4UYwq647ww6E GO5JA6kWEu1RfZYdReW6IIoK30KZz618UZPS8sOHa27g5Sa.amow0hRW8c4t e5teuFwfFNNZ8ba5BFVqGGUuVSAAX.08DSBG_zE0yMjCOun55jwu89eFND38 O5jUYOHlh4QT.0HgGYeMFl6Lu0ud6PdgVYlvwxLC1Z_liwmcdJKZtJk2214j D4665vdA- Received: from [67.213.218.74] by web160601.mail.bf1.yahoo.com via HTTP; Thu, 01 Nov 2012 20:51:48 PDT X-Rocket-MIMEInfo: 001.001, SW4gbGluZSBbSm9uMl0KCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBKUCBWYXNzZXVyIChqdmFzc2V1cikgPGp2YXNzZXVyQGNpc2NvLmNvbT4KVG86IEpvbiBCbGFjayA8amJsYWNrLmlldGZAeWFob28uY29tPiAKQ2M6ICJtYW5ldEBpZXRmLm9yZyIgPG1hbmV0QGlldGYub3JnPiAKU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDEsIDIwMTIgMTI6MzMgUE0KU3ViamVjdDogUmU6IFttYW5ldF0gTE9BRG5nIHdvcmtzCiAKCkhpIEpvbiwgCgpJbiBsaW5lIC0gSlAyPgoKCk9uIE4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> Message-ID: <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> Date: Thu, 1 Nov 2012 20:51:48 -0700 (PDT) From: Jon Black To: "JP Vasseur \(jvasseur\)" In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1737431079-350681489-1351828308=:94489" Cc: "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 03:51:56 -0000 --1737431079-350681489-1351828308=:94489 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In line [Jon2]=0A=0A=0A=0A=0A________________________________=0A From: JP V= asseur (jvasseur) =0ATo: Jon Black =0ACc: "manet@ietf.org" =0ASent: Thursday, November 1,= 2012 12:33 PM=0ASubject: Re: [manet] LOADng works=0A =0A=0AHi Jon, =0A=0AI= n line - JP2>=0A=0A=0AOn Nov 1, 2012, at 4:32 PM, Jon Black wrote:=0A=0A=0A= >=0A>=0A>=0A>=0A>________________________________=0A> From: JP Vasseur (jva= sseur) =0A>To: Jon Black =0A>Cc= : "manet@ietf.org" ; "thierry.lys@erdfdistribution.fr" =0A>Sent: Thursday, November 1, 2012 3:41 AM= =0A>Subject: Re: [manet] (no subject)=0A>=0A>=0A>Hi Jon, =0A>=0A>=0A>On Nov= 1, 2012, at 12:39 AM, Jon Black wrote:=0A>=0A>Yes it shows that it does wo= rk in a rather large deployment.=C2=A0 =0A>=0A>=0A>JP> This is not just a q= uestion of "how large" it is =E2=80=A6 but also how dynamic. I could show y= ou few hundreds (if not less number of nodes)=0A>not working if the traffic= pattern is too dynamic. This is a fundamental problem.=0A>=0A>[Jon] Are yo= u saying that their AMI PLC deployment was not dynamic?=0A>=0A=0AJP2> We do= not have any details so I cannot comment on *that* deployment; my point wa= s that you can easily show why the number=0Aof nodes is NOT the only issues= with reactive routing protocols in LLNs. Take actual traces (which I perso= nally did with actual deployed=0Anetworks) and simulate the control plane t= raffic with moderate use traffic demand and you will see the issue with suc= h routing approach.=0AIn other words, even with a relatively small number o= f nodes, in contrast with other proactive routing protocols, if the user tr= affic is moderate=0A(not even very high), you clearly see why this reactive= routing is ill suited to LLNs.=0A=0A[Jon2] There are plenty of well workin= g LLNs that use reactive protocols such as AODV.=C2=A0 I've built and deplo= yed them so perhaps you can't but I can and the protocol and network work w= ell.=C2=A0 It depends on the type of traffic, nodes, radio, ...=C2=A0 To sa= y that you can only build a working LLN using a proactive protocol is just = plain foolish.=0A=0A=0A=0A>=0A>I have heard others say that it works in oth= er deployments as well - just the same as you say RPL works in some deploym= ents.=0A>>=0A>>=0A>=0A>=0A>JP> I do not not think that we should go in a RP= L versus Load-NG debate but rather try to find a good solution for MANET. T= hat being=0A>said, RPL *for* LLNs the the result of a 4-year work with a DT= , weekly calls, interim WG meetings to make it work in LLNs.=0A>=0A>[Jon] I= did not cast this as a RPL vs LOADng debate - you just did.=C2=A0 I am say= ing that LOADng works in some scenarios and proof is the EDF deployment in = their AMI network.=0A>=0A=0AJP2> I would be happy to see detailed results a= nd especially the user traffic profiles for the reason exposed above.=0A=0A= [Jon2] JP actually it doesn't matter!=C2=A0 You say that you CANNOT build a= working LLN using a reactive protocol.=C2=A0 EDF has proved that wrong.=C2= =A0 They built one.=C2=A0 You can continue to claim that you can't, but the= re is an existence proof.=0A=0A=0A=0A>=0A>Please share your results.=C2=A0 = You keeps saying you will and you we keep asking you to - where's the resul= ts so they can be reviewed.=0A>>=0A>>=0A>>=0A>=0A>=0A>JP> Once again, I wou= ld first like to hear chair's decision. PLEASE note that I would be happy t= o see Load's results too. And just be=0A>patient, I just need to find a bit= of time to compile results and you will get many results backing up my cla= ims. Please also refer to the=0A>number of discussions prior to designing R= PL that took place on the ROLL mailing list. Believe me there was a reason = not NOT choosing=0A>a reactive protocol for LLN (again I am NOT against rea= ctive routing for other use cases at all). Would you ignore the findings of= a WG=0A>that worked for 4 years on the subject matter ? I guess not =E2=80= =A6 Just trying to raise my voice (as many others on this list) to protect = the=0A>Internet.=0A>=0A>[Jon] As others have said - you have it backwards.= =C2=A0 If you have data that would show that LOADng or a reactive protocol = will not work in MANETs please share it.=C2=A0=0A=0AJP2> Please reread what= I wrote ten times =E2=80=A6 I said "LLNs" not "MANET" in general. On top o= f that, I do prefer the option 1) for the reasons exposed=C2=A0=0Abefore (t= his is the WG document, Charlie made it compatible + other technical reason= s).=0A=0AYou did say LLNs but again you are wrong.=C2=A0 There are plenty o= f LLNS that have been built using reactive (and proactive) protocols and wi= ll continue to be built using reactive (and proactive protocols).=C2=A0 The= re is no one size fits all.=0A=0AI prefer to have a debate based on facts a= nd not conjecture and based on technical arguments. =0A=0A=0AThat would be= =0A>very insightful and would help guide this discussion and decision.=C2= =A0 It would not be prudent to make a decision and then bring out data that= would try to suggest that the decision was incorrect.=0A>=0A>What findings= are you referring to?=C2=A0 Where is there a WG document that documents th= ese findings?=0A>=0A>[Jon2] I noticed you skipped this.=C2=A0 =0A=0A=C2=A0= =0A=0A=0A>=0A>Thanks.=0A>=0A>=0A>JP.=0A>=0A>Jon=0A>>=0A>>=0A>>=0A>>=0A>>=0A= >>________________________________=0A>> From: JP Vasseur (jvasseur) =0A>>To: Jon Black =0A>>Cc: "manet@iet= f.org" ; "thierry.lys@erdfdistribution.fr" =0A>>Sent: Wednesday, October 31, 2012 4:09 PM=0A>>Subjec= t: Re: [manet] (no subject)=0A>>=0A>>=0A>>=0A>>=0A>>On Oct 31, 2012, at 6:5= 7 PM, Jon Black wrote:=0A>>=0A>>On October 31, 2012 Thierry.Lys wrote:=0A>>= >=0A>>>=0A>>>I speak in the name of EDF group. =0A>>>=0A>>>We started first= to use LOAD as a routing algorithm and deployed 2000 PLC-meters for smart = grid purposes in 2011. Taking advantage of this field test, we have been ac= tively participating to the working group to adopt enhancements in the LOAD= ng specification. =0A>>>We are now extremely pleased with what LOADng is ca= pable of and are confident that future deployements will be equipped with i= t.=C2=A0=0A>>>=0A>>>=0A>>>This would seem to indicate that LOADng does work= and in a rather large deployment.=0A>>>=0A>>=0A>>=0A>>JP> No this means th= at LoadNG works in *a* network. But the major technical difference here is = that reactive routing is highly impacted=0A>>by the user traffic =E2=80=A6 = If you poll a meter every 24 hours, it may work perfectly well. Now if you = start having more frequent traffic flows=0A>>you can either cache paths (en= ding up with more frequent broken paths considering how flappy these networ= ks are, thus leading to more=0A>>floods =E2=80=A6 very undesirable =E2=80= =A6 especially when you have hundreds of meters sharing a few Kbits/s) or y= ou use short cache timers and you=0A>>keep flooding :-( If you take actual = traces of these networks (both using 15.4g and P1901.2) and you start adjus= ting the user traffic rate you=0A>>immediately see the issues in terms of s= calability. Yes you can try to mitigate the undesirable flooding effect to = some extends but showing=C2=A0=0A>>the limits in terms of scalability is ea= sy to show. Note that I MOT against reactive routing by any means, this is = IMO just not applicable to=0A>>LLNs unless the traffic flows are determinis= tic and very well knows =E2=80=A6 Lessons from the past show us how difficu= lt it is to predict user=C2=A0=0A>>applications. We all started with meter = reading to continue with that example and now many utilities wants to use t= hese smart metering=C2=A0=0A>>networks for a number of applications which d= ifferent SLA, =E2=80=A6=C2=A0=0A>>=0A>>=0A>>Hope this helps. Once again, wh= en/if required I would be happy to share many results.=0A>>=0A>>=0A>>=0A>>= =0A>>>"We believe in rough consensus and running code" =0A>>>=0A>>>rough co= nsensus : Don't you think we have a rough consensus on LOADng compared to D= YMO ? 10 authors and major companies are supporters of LOADng. =0A>>>=0A>>>= running code : interoperability has been checked with 4 sources and other i= mplementations are in progress. =0A>>>=0A>>>Obviously from the list we don'= t have rough consensus.=C2=A0 We have two alternatives each with proponents= .=C2=A0 The WG should weigh the technical benefits (design, implementation/= running code, maturity)=C2=A0 of each and the group should choose a path fo= rward.=0A>>>=0A>>>In my opinion option 3 is not an option - this is the wor= king group shirking its responsibility.=0A>>>=0A>>=0A>>=0A>>This is an opti= on =E2=80=A6 since listed by the chairs. I agree that we should avoid it, e= specially when I think we have a very reasonable solution=0A>>(option1).=0A= >>=0A>>=0A>>JP.=0A>>=0A>>=0A>>>Jon=0A>>> =0A>>>=0A>>>=0A___________________= ____________________________=0A>>>manet mailing list=0A>>>manet@ietf.org=0A= >>>https://www.ietf.org/mailman/listinfo/manet=0A>>>=0A>>=0A>>=0A>>=0A>=0A>= =0A>=0A_______________________________________________=0A>manet mailing lis= t=0A>manet@ietf.org=0A>https://www.ietf.org/mailman/listinfo/manet=0A> --1737431079-350681489-1351828308=:94489 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
In line [Jon2]


From: JP Vasseur (jvasseur) <jvasseur@= cisco.com>
To: Jon = Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@ietf.org>
Sent: Thursday, November 1, 2012 12:33= PM
Subject: Re: [mane= t] LOADng works

=0A
=0A=0A =0A=0A
=0AH= i Jon,=0A

=0A
=0A
In line - JP2>
=0A

=0A=0A
On Nov 1, 2012, at 4:32 PM, Jon Black wrote:
=0A
=0A
= =0A
=0A
=0A

=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0AFrom: JP Vasseur (jvasseur) <jvas= seur@cisco.com>
=0ATo: Jon Black <jblack.ietf@y= ahoo.com>=0A
=0ACc: "manet@ietf.org" <manet@ietf.org>; "thierry.lys@erdfdistribution.fr" <thierry.lys@erdfdistributi= on.fr>=0A
=0ASent: Thursday, November 1, 2012 3:41 AM
=0ASubject: Re: [manet] (no subject)
=0A
=0A=0A =0A
=0A
Hi Jon,=0A

=0A
=0AOn Nov 1, 2012, at 12:39 AM, Jon Black wrote:
=0A
=0A
=0A
=0A<= div style=3D"color:rgb(0, 0, 0);background-color:rgb(255, 255, 255);font-fa= mily:'times new roman', 'new york', times, serif;font-size:12pt;">=0A
<= span>Yes it shows that it does work in a rather large deployment. 
=0A
=0A
=0A
=0A

=0A
=0A
JP= > This is not just a question of "how large" it is =E2=80=A6 but also ho= w dynamic. I could show you few hundreds (if not less number of nodes)=0A
not working if the traffic pattern is too dynamic. This is a funda= mental problem.
=0A
=0A[Jon] Are you saying that their AMI PLC deploy= ment was not dynamic?
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A=0A

=0A
=0AJP2> We do not have any details so I cannot comment on *that* deploymen= t; my point was that you can easily show why the number=0A
of nod= es is NOT the only issues with reactive routing protocols in LLNs. Take act= ual traces (which I personally did with actual deployed
=0A
networ= ks) and simulate the control plane traffic with moderate use traffic demand= and you will see the issue with such routing approach.
=0A
In oth= er words, even with a relatively small number of nodes, in contrast with ot= her proactive routing protocols, if the user traffic is moderate
=0A(not even very high), you clearly see why this reactive routing is ill s= uited to LLNs.

[Jon2] There are plenty of well working LLNs that use= reactive protocols such as AODV.  I've built and deployed them so per= haps you can't but I can and the protocol and network work well.  It d= epends on the type of traffic, nodes, radio, ...  To say that you can = only build a working LLN using a proactive protocol is just plain foolish.<= br>=0A
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A

=0A
=0A
=0A
=0A
I have heard others say that it works in other deplo= yments as well - just the same as you say RPL works in some deployments.
=0A
=0A
=0A
=0A
=0A
=0A
=0A

= =0A
=0A
JP> I do not not think that we should go in a RPL versu= s Load-NG debate but rather try to find a good solution for MANET. That bei= ng
=0A
said, RPL *for* LLNs the the result of a 4-year work with a= DT, weekly calls, interim WG meetings to make it work in LLNs.
=0A
= =0A[Jon] I did not cast this as a RPL vs LOADng debate - you just did. = ; I am saying that LOADng works in some scenarios and proof is the EDF depl= oyment in their AMI network.
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A
=0A

=0A
= =0A
JP2> I would be happy to see detailed results and especially the= user traffic profiles for the reason exposed above.

[Jon2] JP actua= lly it doesn't matter!  You say that you CANNOT build a working LLN us= ing a reactive protocol.  EDF has proved that wrong.  They built = one.  You can continue to claim that you can't, but there is an existe= nce proof.
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A

=0A=0A
=0A
=0A
=0A
=0A
=0APlease share your re= sults.  You keeps saying you will and you we keep asking you to - wher= e's the results so they can be reviewed.
=0A
=0A
=0A
=0A<= /div>=0A
=0A
=0A
=0A

=0A
=0A
JP> = Once again, I would first like to hear chair's decision. PLEASE note that I= would be happy to see Load's results too. And just be
=0A
patient= , I just need to find a bit of time to compile results and you will get man= y results backing up my claims. Please also refer to the
=0A
numbe= r of discussions prior to designing RPL that took place on the ROLL mailing= list. Believe me there was a reason not NOT choosing
=0A
a reacti= ve protocol for LLN (again I am NOT against reactive routing for other use = cases at all). Would you ignore the findings of a WG
=0A
that work= ed for 4 years on the subject matter ? I guess not =E2=80=A6 Just trying to= raise my voice (as many others on this list) to protect the
=0A
I= nternet.
=0A
=0A[Jon] As others have said - you have it backwards.&nb= sp; If you have data that would show that LOADng or a reactive protocol wil= l not work in MANETs please share it. 
=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A

= =0A
=0A
JP2> Please reread what I wrote ten times =E2=80=A6 I s= aid "LLNs" not "MANET" in general. On top of that, I do prefer the option 1= ) for the reasons exposed 
=0A
before (this is the WG documen= t, Charlie made it compatible + other technical reasons).

You did sa= y LLNs but again you are wrong.  There are plenty of LLNS that have be= en built using reactive (and proactive) protocols and will continue to be b= uilt using reactive (and proactive protocols).  There is no one size f= its all.

I prefer to have a debate based on facts and not conjecture= and based on technical arguments.
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
That would be=
=0Avery insightful and would help guide this discussion and decision.&n= bsp; It would not be prudent to make a decision and then bring out data tha= t would try to suggest that the decision was incorrect.
=0A
=0AWhat f= indings are you referring to?  Where is there a WG document that docum= ents these findings?

[Jon2] I noticed you skipped this. 
=
<= div>
 
=0A
<= /div>
=0A

=0A
=0A
Thanks.
=0A

=0A=0A
JP.
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0AJon
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0AFro= m: JP Vasseur (jvasseur) <jvasseur@cisco.com>
=0ATo:<= /span> Jon Black <jblack.i= etf@yahoo.com>=0A
=0ACc: "manet@ietf.org" <manet@ietf.org>;=0A "thierry.lys@erdfdistribution.fr" <thierry.lys@erdfdi= stribution.fr>=0A
=0ASent: Wednesday, October 31, 2012 4:09 PM
=0ASubject: Re: [manet] (no subject)
=0A=0A
=0A
=0A

=0A
=0A
On Oct 3= 1, 2012, at 6:57 PM, Jon Black wrote:
=0A
=0A
=0A
=0A
=0A
On October= 31, 2012 Thierry.Lys wrote:
=0A

=0A
=0A
= =0AI speak in the name of EDF group. <= /font>
=0A
=0AWe started first t= o use LOAD as a routing algorithm and deployed 2000 PLC-meters for smart gr= id purposes in 2011. Taking advantage of this field test, we have been acti= vely participating to the working group to adopt enhancements=0A in the LOA= Dng specification.
=0AWe ar= e now extremely pleased with what LOADng is capable of and are confident th= at future deployements will be equipped with it. 
=0A
=0A
=0A
= =0A
=0AThis would seem to indic= ate that LOADng does work and in a rather large deployment.
=0A
=0A=
=0A
=0A
=0A

=0A
=0A
JP> No this = means that LoadNG works in *a* network. But the major technical difference = here is that reactive routing is highly impacted
=0A
by the user t= raffic =E2=80=A6 If you poll a meter every 24 hours, it may work perfectly = well. Now if you start having more frequent traffic flows
=0A
you = can either cache paths (ending up with more frequent broken paths consideri= ng how flappy these networks are, thus leading to more
=0A
floods = =E2=80=A6 very undesirable =E2=80=A6 especially when you have hundreds of m= eters sharing a few Kbits/s) or you use short cache timers and you
=0A=
keep flooding :-( If you take actual traces of these networks (both us= ing 15.4g and P1901.2) and you start adjusting the user traffic rate you=0A
immediately see the issues in terms of scalability. Yes you can = try to mitigate the undesirable flooding effect to some extends but showing=  
=0A
the limits in terms of scalability is easy to show. Not= e that I MOT against reactive routing by any means, this is IMO just not ap= plicable to
=0A
LLNs unless the traffic flows are deterministic an= d very well knows =E2=80=A6 Lessons from the past show us how difficult it = is to predict user 
=0A
applications. We all started with met= er reading to continue with that example and now many utilities wants to us= e these smart metering 
=0A
networks for a number of applicat= ions which different SLA, =E2=80=A6 
=0A

=0A
=0AHope this helps. Once again, when/if required I would be happy to share ma= ny results.
=0A

=0A
=0A
=0A
= =0A
=0A
=0A
=0A
= =0A"We believe in rough consensus and = running code"=0A
=0A
=0Ar= ough consensus : Don't you think we have a rough consensus on LOADng compar= ed to DYMO ? 10 authors and major companies are supporters of LOADng.=0A
=0A
=0Arunning code : inter= operability has been checked with 4 sources and other implementations are i= n progress.=0A
=0A
=0A
=0AObviously from the list we don't have rough consensus.  We ha= ve two alternatives each with proponents.  The WG should weigh the tec= hnical benefits (design, implementation/running code, maturity)  of ea= ch and the group should=0A choose a path forward.
=0A
=0AIn my opinio= n option 3 is not an option - this is the working group shirking its respon= sibility.
=0A
=0A
=0A
=0A

=0A
= =0A
This is an option =E2=80=A6 since listed by the chairs. I agree tha= t we should avoid it, especially when I think we have a very reasonable sol= ution
=0A
(option1).
=0A

=0A
=0A
JP.
= =0A
=0A
=0A
=0A
=0A
=0AJon
=0A=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A___________________________________= ____________
=0Amanet mailing list
=0Aman= et@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo= /manet
=0A
=0A
=0A
=0A
=0A
=0A
=0A<= br>=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A<= /div>=0A
=0A
=0A =0A
=0A
=0A
=0A
=0A
=0A=0A_______________________________________________
=0Amanet mailing li= st
=0Amanet@ietf.org
=0Ahttps://www.i= etf.org/mailman/listinfo/manet
=0A
=0A=0A
=0A= =0A=0A=0A

--1737431079-350681489-1351828308=:94489-- From ssakane@cisco.com Thu Nov 1 21:17:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FAA21F992C for ; Thu, 1 Nov 2012 21:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPN05KRcqHWI for ; Thu, 1 Nov 2012 21:17:23 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id AB9B821F9930 for ; Thu, 1 Nov 2012 21:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1612; q=dns/txt; s=iport; t=1351829842; x=1353039442; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=FwLSruXS73/GDFPECR+xrtxUv5JfwZ8v2v4ShIGk+aY=; b=VmrmC7p7eE/hsAYo1bi5h5gpWBe/VVUCoaWXtb7b2DnPbdEdBmDCDwzU k1DRe0sbjbQtmdxzMSk137ybP7OBoDMa1ePOtG9WJTDyRBq7A4UL2I0Ue 3mkF5m7NbEd1Y+uywzoOEi6l6r03Um1pADlv77jkQGTg10tTnmp2hI8YW I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAORIk1CrRDoH/2dsb2JhbABEhhe9G4EIgh4BAQEDEwEOAVwWGQMFIAMRAiwtCAEBHodeBZtdgSyNJAGSa4EdjXWCDoEWA4hYjSCOWIFrgn4 X-IronPort-AV: E=Sophos;i="4.80,696,1344211200"; d="scan'208";a="59828734" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 02 Nov 2012 04:17:21 +0000 Received: from mactanu.local (tky-vpn-client-230-208.cisco.com [10.70.230.208]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA24HLZg012017 for ; Fri, 2 Nov 2012 04:17:21 GMT Message-ID: <5093494B.60202@cisco.com> Date: Fri, 02 Nov 2012 13:17:15 +0900 From: Shoichi Sakane User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Nov 2012 21:19:58 -0700 Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 04:17:23 -0000 Hi, > 1. Continue the work on the DYMO document, starting with whether there is consensus on its continued approach and also the desire to rename it to AODVv2. > 2. Replace the existing DYMO document effort with the LOADng related document effort, defusing ealier references to LLNs as recommended in the last meeting minutes, and to focus more motivationally on general MANET problem spaces (the authors seem to have agreed to this issue if its a WG document). > 3. Remove the working group charter for a reactive protocol, effectively killing both documents, at least from a working group (WG) standpoint. This would not be a reflection on the technology in either case, just an admission that we are not working together and reaching consensus. I would bet to option 1. My sense is close to the Pascal's one. Option 3 might be overstatement because a reactive protocol is obviously useful for some kind of mobility scenarios. We could say that "make it to a clean state and restart to standardize reactive protocols as Pascal mentioned. I would think that a missing piece is that we don't have concrete use cases and its requirements. And, we don't have explicit criteria whether a protocol is suitable for a certain use case or not. I agree with that DYMO tends to be large specification. It makes interoperability be complex. The relative people could make a subset of DYMO as a lightweight reactive protocol so that the nodes supported it can be interoperable with a full-set DYMO gateway or router. I think that LOADng should be so. Of coure, it depends on a use case. Shoichi From jvasseur@cisco.com Fri Nov 2 01:01:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CA021F9375 for ; Fri, 2 Nov 2012 01:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.231 X-Spam-Level: X-Spam-Status: No, score=-10.231 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsrbBF5O+LKD for ; Fri, 2 Nov 2012 01:01:45 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 622B721F936A for ; Fri, 2 Nov 2012 01:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13753; q=dns/txt; s=iport; t=1351843305; x=1353052905; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8RP5ewYpu8/b8TT3zSjMmr6wX8WU+nt893aUt4RPxAI=; b=QP5tP2YJIVufF3yx2/ByNx+RiffAVnPe2jqE39osG5nrbpiYJl7UE7PO 1ESYfUwPL5JLTfgXX7w2yv1/X0/pF2XTZmwdZvVGoCA8r9Ys6fgKLTylK fRJCvURcqiw+jsAdGDVJE17n+7dcR/Hr08slovA5ktsdD5N+OZSsL6mKI o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocFAI59k1CtJXHA/2dsb2JhbABEuyQEiAyBCIIfAQEEAQEBDwFZAggDEAIBCCIdByEGCxQRAgQOBQgTB4dSAw8LnGaWKg2JUASLFGcShUhhA4gli36NB4MmgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,697,1344211200"; d="scan'208,217";a="138093493" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 02 Nov 2012 08:01:44 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA281ikO001388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 08:01:44 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 03:01:44 -0500 From: "JP Vasseur (jvasseur)" To: Abdussalam Baryun Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuNBMLPVi/cSo/ES1hdb7zda62w== Date: Fri, 2 Nov 2012 08:01:44 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204A960@xmb-rcd-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.149.112] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--38.311700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204A960xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 08:01:46 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204A960xmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Nov 1, 2012, at 4:57 PM, Abdussalam Baryun wrote: Dear MANET WG Chairs, I recommend we base our choices and options on our present ietf Charter and= milestones we got so far, so we can follow in our choices the best practic= e. I recommend that we look into the following three options which can be base= d on the MANET Charter and the WG-I-Ds' work-flow-progress: 1- DYMO/AODVv2 to be completed and prepared by the WG to be submitted. 2- The WG chairs and participants to work together in one team work of auth= oring one reactive protocol (a merge solution, with both draft authors incl= uding WG chair). JP> agreeing so far, and include in AODVv2 all features that the WG would c= onsider useful, this is what is proposed by Charlie. 3- Accept the individual LOADng draft as a second reactive protocol, then, = to decide in the future how to merge both AODVv2 ideas into LOADng dependin= g on comparing specifications. JP> Not sure that we can have 2 though, charter is for ONE. Thanks. JP. My Comments on the mentioned drafts history and your recommended options, i= n line in below message, AB ++++++++++++++ On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker > wrote: Hello MANET working group (form Stan and Joe), As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common documen= t effort and given positive feedback at the time we the chairs thought this= was the best approach given the authors potential to come together and gai= n the best of both efforts. Since that period, there has been some fairly = strident and rancorous "at times" debate between the authors of the two doc= uments. There was never any announcement of such merge movement, however, there was= a suggestion for that by one DYMO author but was refused by one LOADng aut= hor. During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts = and LOADng had fairly active authorship and implementation efforts. We prov= ided a co-editing proposal to the authors and gave them the timeframe of th= e Atlanta to come up with an answer back to us regarding this. As of this = writing, those discussions of a potential commonn document and authorship m= erger have failed. Again in the 84 meeting there was no such announcement of any merge between= DYMO's I-D and the LOADng I-D. We only seen an author added to LOADng I-D = which was an author of DYMO I-D, but does not meen merging drafts and not a= nnounced to WG such suggestions. Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss= ue at the present time. We see only 3 possible paths forward: 1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2. There is no reason why we need to ignore this option, is it because DYMO au= thors did not do any work for some time and the WG as well did not do any, = or is it because an individual draft came up to interrupt the WG work in pr= ogress. 2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document). We need to accept the LOADng as a WG item first then we decide if we can ta= ke option 2 3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus. The reactive protocol is a must protocol for MANETs, killing it will not re= ally kill it but will give chance to other competitor organisations to stan= dard reactive protocol before IETF. The co-chairs request and need your opinions on the options. We have been = some silent collecting initial feedback and waiting for author feedback at = this point. Stan and I are both on travel prior to Atlanta so our response= s may be sparse and we will also likely be in a "receive mode" for a few da= ys. So send your opinions. -Joe _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204A960xmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Nov 1, 2012, at 4:57 PM, Abdussalam Baryun wrote:

Dear MANET WG Chairs,
 
I recommend we base our choices and options on our present ietf Charte= r and milestones we got so far, so we can follow in our choices the best pr= actice.
 
I recommend that we look into the following three options which c= an be based on the MANET Charter and the WG-I-Ds' work-flow-progress:
 
1- DYMO/AODVv2 to be completed and prepared by the WG to be submitted.=
2- The WG chairs and participants to work together in one team work of= authoring one reactive protocol (a merge solution, with both draft authors= including WG chair).

JP> agreeing so far, and include in AODVv2 all features that the WG= would consider useful, this is what is proposed by Charlie.

3- Accept the individual LOADng draft as a second reactive protocol, t= hen, to decide in the future how to merge both AODVv2 ideas into = LOADng depending on comparing specifications.

JP> Not sure that we can have 2 though, charter is for ONE.

Thanks.

JP.


My Comments on the mentioned drafts history and your recommended = options, in line in below message,
 
AB
++++++++++++++
On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker = <jpmacker@gmail.= com> wrote:
Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.  Sin= ce that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.
 
There was never any announcement of such merge movement, however, ther= e was a suggestion for that by one DYMO author but was refused by = ;one LOADng author.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active author= ship and implementation efforts. We provided a co-editing proposal to the a= uthors and gave them the timeframe of the Atlanta to come up with an answer= back to us regarding this.  As of this writing, those discussions of a potential commonn document and aut= horship merger have failed.
 
Again in the 84 meeting there was no such announcement of any merge be= tween DYMO's I-D and the LOADng I-D. We only seen an author added to LOADng= I-D which was an author of DYMO I-D, but does not meen merging drafts and = not announced to WG such suggestions. 

Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.  We s= ee only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
There is no reason why we need to ignore this option, is it because DY= MO authors did not do any work for some time and the WG as well did not do = any, or is it because an individual draft came up to interrupt the WG work = in progress.
 
2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document).
 
We need to accept the LOADng as a WG item first then we decide if we c= an take option 2
 
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.
 
The reactive protocol is a must protocol for MANETs, killing it will n= ot really kill it but will give chance to other competitor organisations to= standard reactive protocol before IETF.

The co-chairs request and need your opinions on the options.  We have = been some silent collecting initial feedback and waiting for author feedbac= k at this point.  Stan and I are both on travel prior to Atlanta so ou= r responses may be sparse and we will also likely be in a "receive mode" for a few days.  So send your= opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A772204A960xmbrcdx02ciscoc_-- From jvasseur@cisco.com Fri Nov 2 01:04:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9439B21F976A for ; Fri, 2 Nov 2012 01:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.492 X-Spam-Level: X-Spam-Status: No, score=-10.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlKGGjgf6rQi for ; Fri, 2 Nov 2012 01:04:23 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0E90621F93A0 for ; Fri, 2 Nov 2012 01:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1233; q=dns/txt; s=iport; t=1351843463; x=1353053063; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=N/na189jaf0ukgZYVDpdyn1E7+0kENZ0XJtkb24JUP8=; b=Vm3GBjiAnyBkXzx9puO5jJPRug2Gw75NxzODAY7mkQqzF7gtz2e6F4yA hYl8mtPqb36D/THNGzUUwCRnFiD6hHI9fxu6XoYyGFjOOcHLkujmjLYCu Xk7xrhApvIgEhWTkxvfBY0kvMooWla+EC/WbR6nxbtmhcpvuKgF1cUKCv M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAI59k1CtJXHB/2dsb2JhbABEwzSBCIIeAQEBAwEBAQEPAVsLBQsCAQgYCiQnCyUCBA4FCBMHh14GC5xmoAcEi3uFWmEDpFCBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,697,1344211200"; d="scan'208";a="138094354" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 02 Nov 2012 08:04:22 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA284MfY030104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 08:04:22 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 03:04:22 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] DYMO-23 review Thread-Index: AQHNuNCqWAnc9xz2TE+ovpDBRY+6iQ== Date: Fri, 2 Nov 2012 08:04:22 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204A9B9@xmb-rcd-x02.cisco.com> References: <97B69B30E0EF244B940B65EA541E3F2D21571353@DBXPRD0510MB395.eurprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.149.112] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--42.060500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <4FA1F873B168AF4FB58C778B2301AD3C@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] DYMO-23 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 08:04:23 -0000 On Nov 1, 2012, at 7:55 PM, Ulrich Herberg wrote: > C=E9dric, >=20 > On Thu, Nov 1, 2012 at 4:43 PM, C Chauvenet wro= te: > [...] >>>=20 >>> during the discussion, I noticed that many just say "I like protocol >>> foo1 better than foo2", without any technical argument. That is not >>> very productive. >>=20 >> I think it is because chairs proposed 3 options and ask WG to give their= opinion on these 3 solutions. >> Of course, we could have very deep technical discussions, and expand the= message storm on the list but from what I understood chairs are mostly wa= iting for opinions on these 3 choices. >=20 > Well, I think we need the technical discussions. Otherwise, it's not > productive to say "I prefer option A over B" without stating technical > reasons (and maybe without even having read both drafts). There may be > political rather than technical reasons for such a choice, and we > should absolutely avoid that. JP> Indeed. But =85 that was the questions the chairs asked us to answer. >=20 > Best regards > Ulrich > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Fri Nov 2 01:10:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FF721F976D for ; Fri, 2 Nov 2012 01:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.204 X-Spam-Level: X-Spam-Status: No, score=-10.204 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHAbTcZ+p-YU for ; Fri, 2 Nov 2012 01:10:20 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id ADD5521F9790 for ; Fri, 2 Nov 2012 01:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29342; q=dns/txt; s=iport; t=1351843819; x=1353053419; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7DSVieKCiTdzTCOFvpna9k1jWpVjbFcLZbMIRqh6/2w=; b=K4ATv+YHKJxs+FY+UY8vCzAZ1iVUuCyKCM5/gyzlsQcd9C1MWMTjoJl5 kkeQe7jb31maO//vJOgg8FkYB+a+fs3HK8KiQa1anzD3VZ15W3B8aOjoI pgbSvyCtk4YsUqME4osEa9jiA4fxhOB/I/KNB2SUp/Vq95OhFgUKv9Mz0 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFADp/k1CtJXG+/2dsb2JhbABEgkmuUZIagQiCHgEBAQICAQEBDwFCFwIDBQMQAgEIDgMEAQELFgcHIQYLEwEJCAIEDgUIEweHUgMPC5xdlioNiVSLFGcSAg6FOGEDlCMEgmyKF4MmgWuCb4FbCRce X-IronPort-AV: E=Sophos;i="4.80,697,1344211200"; d="scan'208,217";a="138087421" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 02 Nov 2012 08:10:18 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA28AIN2027541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 08:10:18 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 03:10:18 -0500 From: "JP Vasseur (jvasseur)" To: Jon Black Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNt0HGLPVi/cSo/ES1hdb7zda62w== Date: Fri, 2 Nov 2012 08:10:18 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204AA30@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com> <1351784668.10346.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049577@xmb-rcd-x02.cisco.com> <1351827607.38598.YahooMailNeo@web160605.mail.bf1.yahoo.com> In-Reply-To: <1351827607.38598.YahooMailNeo@web160605.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.149.112] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--64.914600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204AA30xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: manet Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 08:10:23 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204AA30xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable You keep ignoring what I wrote =85 I think that I explained why reactive ro= uting was a major issue for LLN at least twice and I will provide numbers too. I also explained why I would strongly favor Option 1 (which wa= s THE question asked by the chair). On Nov 1, 2012, at 11:40 PM, Jon Black wrote: But opinions without some technical details turns into a beauty contest and= I don't think that is what the chairs were after. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: Abdussalam Baryun >; manet > Sent: Thursday, November 1, 2012 12:36 PM Subject: Re: [manet] Reactive Protocol Situation On Nov 1, 2012, at 4:44 PM, Jon Black wrote: I disagree. The protocol has progressed. It appears that there are implem= entations. There is interoperability. There are deployments. This is all= progress. I'm not favoring LOADng over DYMO. I think the working group should look a= t both fairly and decide the best path forward - chose one over the other o= r find a way to merge the concepts even if the authors are hesitant. Right and I think that this was what the chairs asked us to do: express our= opinion on which option we prefer. Let's wait until everybody express an opinion and see what the chairs think= . Thanks. JP. Jon ________________________________ From: Abdussalam Baryun > To: manet > Sent: Thursday, November 1, 2012 8:28 AM Subject: Re: [manet] Reactive Protocol Situation On Wed, Oct 31, 2012 at 10:02 AM, Dearlove, Christopher (UK) > wrote: As someone who has not (yet) stated an opinion on the matter, except I also= think option 3 is not good, I would very much like to hear technical argum= ents, so if you have technical arguments against LOADng, I think we need to= hear them rather than just suggesting they exist. I haven't yet read LOADn= g carefully to form a view there. I have just recently read the AODVv2 draf= t carefully, and have some technical issues there (which overlap) regarding= asymmetric links, possible dependency on NHDP, and the compatibility of op= tions. If option 1 is followed, the draft needs work (which Charlie has ack= nowledged). I don't think we have time to waste with LOADng, it was presented twice and= no progress, the authors failed to discuss on MANET list, and failed to up= date the draft to match MANET reuirements. I agree that we focus our effort= s to submit AODVv2 as soon as possible, AB -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of JP Vasseur (jv= asseur) Sent: 31 October 2012 08:29 To: Joseph Macker Cc: > Subject: Re: [manet] Reactive Protocol Situation *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Dear chairs, Remembering that I am not a co-authors of either of these drafts. Not commenting on recent discussions but rather focussing on what I hope wi= ll be a good solution for the WG and the Internet at large. Option 3) is my opinion not desirable; I wish we could have a reactive rout= ing protocol for MANET Option 2) is an option I would be strongly opposed to for a number of techn= ical reasons that I would be happy to elaborate on the mailing list and/or in a new I-D (which I would, should option 2 be chosen)= . That being said, I am extremely supportive of option 1), especially in ligh= t of what Charlie said. First of all DYMO is the working group document and excellent progress has been made with recent revisions. But ev= en more importantly, Charlie managed to make it compatible with options, which is in my opinion the best of both worlds; calling it AO= DVv2 is only not very sensible but avoids useful sensitivity around names. Thus I would strongly support Option 1), continue the work that Charlie has= started, which by the way is not far from completion. And as WG,we need to remember that this had been the WG document, the result of= years of work. Still by making it compatible with other options, this is technically flexible and sound. Thanks. JP. On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote: Hello MANET working group (form Stan and Joe), As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common documen= t effort and given positive feedback at the time we the chairs thought this= was the best approach given the authors potential to come together and gai= n the best of both efforts. Since that period, there has been some fairly = strident and rancorous "at times" debate between the authors of the two doc= uments. During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts = and LOADng had fairly active authorship and implementation efforts. We prov= ided a co-editing proposal to the authors and gave them the timeframe of th= e Atlanta to come up with an answer back to us regarding this. As of this = writing, those discussions of a potential commonn document and authorship m= erger have failed. Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss= ue at the present time. We see only 3 possible paths forward: 1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2. 2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document). 3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus. The co-chairs request and need your opinions on the options. We have been = some silent collecting initial feedback and waiting for author feedback at = this point. Stan and I are both on travel prior to Atlanta so our response= s may be sparse and we will also likely be in a "receive mode" for a few da= ys. So send your opinions. -Joe _______________________________________________ manet mailing list manet@ietf.org 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. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204AA30xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <640858C5157A034E8A224D5F47AC4546@cisco.com> Content-Transfer-Encoding: quoted-printable You keep ignoring what I wrote =85 I think that I explained why reactive ro= uting was a major issue for LLN at least twice and I will provide
numbers too. I also explained why I would strongly favor Option 1 (whi= ch was THE question asked by the chair).

On Nov 1, 2012, at 11:40 PM, Jon Black wrote:

But opinions without some technical details turns into a beauty contest and= I don't think that is what the chairs were after.

Jon


From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: Abdussalam Baryun <= abdussalambaryun@gmail.com>; manet <manet@ietf.org>
Sent: Thursday, November 1= , 2012 12:36 PM
Subject: Re: [manet] React= ive Protocol Situation


On Nov 1, 2012, at 4:44 PM, Jon Black wrote:

I disagree.  The protocol has progressed.  It appears that there = are implementations.  There is interoperability.  There are deplo= yments.  This is all progress.

I'm not favoring LOADng over DYMO.  I think the working group should l= ook at both fairly and decide the best path forward - chose one over the ot= her or find a way to merge the concepts even if the authors are hesitant.

Right and I think that this was what the chairs asked us to do: expres= s our opinion on which option we prefer.
Let's wait until everybody express an opinion and see what the chairs = think.

Thanks.

JP.



Jon


From: Abdussalam Baryun <= ;abdussalambaryun@gma= il.com>
To: manet <manet@ietf.org>
Sent: Thursday, November 1,= 2012 8:28 AM
Subject: Re: [manet] Reacti= ve Protocol Situation

On Wed, Oct 31, 2012 at 10:02 AM, D= earlove, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:
As someone who has not (yet) stated an opinion on the matte= r, except I also think option 3 is not good, I would very much like to hear= technical arguments, so if you have technical arguments against LOADng, I think we need to hear them rather th= an just suggesting they exist. I haven't yet read LOADng carefully to form = a view there. I have just recently read the AODVv2 draft carefully, and hav= e some technical issues there (which overlap) regarding asymmetric links, possible dependency on NHDP, and the = compatibility of options. If option 1 is followed, the draft needs work (wh= ich Charlie has acknowledged).
 
 
I don't think we have time to waste with LOADng, it was presented twic= e and no progress, the authors failed to discuss on MANET list, and failed = to update the draft to match MANET reuirements. I agree that we focus our e= fforts to submit AODVv2 as soon as possible,
 
AB
 
 
 
--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 = |  Fax: +44 1245 242124
<= span style=3D"color:rgb(31,73,125);text-decoration:none;">chris.dearlove@ba= esystems.com | http://www.baesystems.com

BAE Systems (Op= erations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687
 
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur)
Sent: 31 October 2012 08:29
To: Joseph Macker
Cc: <manet@ietf.org>
Subject: Re: [manet] Reactive Protocol Situation
 
 
*** WARNING ***<= /u>
This message orig= inates from outside our organisation, either from an external partner or th= e internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.
Dear chairs,
 
Remembering that I am not a co-author= s of either of these drafts.
 
Not commenting on recent discussio= ns but rather focussing on what I hope will be a good solution for the WG a= nd the Internet at large.
 
Option 3) is my opinion not= desirable; I wish we could have a reactive routing protocol for MANET<= u>
 
Option 2) is an option I would be = strongly opposed to for a number of technical reasons that I wou= ld be happy to elaborate on the
mailing list and/or in a new I-D (whi= ch I would, should option 2 be chosen).
 
That being said, I am extremely su= pportive of option 1), especially in light of what Charlie said. First of all DYMO is the w= orking group
document and excellent progress has b= een made with recent revisions. But even more importantly, Charlie managed = to make it compatible 
with options, which is in my opi= nion the best of both worlds; calling it AODVv2 is only not very sen= sible but avoids useful sensitivity around 
names.
 
Thus I would strongly support Opti= on 1), continue the work that Charlie has started, which by the way is = not far from completion. And 
as WG,we need to remember that this h= ad been the WG document, the result of years of work. Still by making it co= mpatible with other options, 
this is technically flexible and soun= d.
 
Thanks.
 
JP.
 
On Oct 31, 2012, at 12:13 AM, Joseph = Macker wrote:


Hello MANET working group (form Stan = and Joe),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.  Sin= ce that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active author= ship and implementation efforts. We provided a co-editing proposal to the a= uthors and gave them the timeframe of the Atlanta to come up with an answer= back to us regarding this.  As of this writing, those discussions of a potential commonn document and aut= horship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.  We s= ee only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have = been some silent collecting initial feedback and waiting for author feedbac= k at this point.  Stan and I are both on travel prior to Atlanta so ou= r responses may be sparse and we will also likely be in a "receive mode" for a few days.  So send your= opinions.

-Joe
_______________________________________________
manet mailing list
manet@ietf.org
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.
********************************************************************


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet




--_000_03B78081B371D44390ED6E7BADBB4A772204AA30xmbrcdx02ciscoc_-- From jvasseur@cisco.com Fri Nov 2 01:12:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92F521F9790 for ; Fri, 2 Nov 2012 01:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.26 X-Spam-Level: X-Spam-Status: No, score=-10.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksqej7o+YOtD for ; Fri, 2 Nov 2012 01:12:34 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E06D221F98D1 for ; Fri, 2 Nov 2012 01:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8669; q=dns/txt; s=iport; t=1351843954; x=1353053554; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1UDfTVZt3EQSRfzZI8GG4Gq4o+7gMKK1V7YoO+3oqZU=; b=LtlNurqESidFpDN+8nDp2BG01nWOA/taSaRuNN1aZDwEBX7kDcuBULAg EVKscLEgb5ylPMxTk9+Ov3pUhZt+kDHBpLDTQG/p9O+HFtszw3QFHD/22 7/gXh836ChYQAm5ULOYzpJJZABsUOlByosQ9H/N4OloIbold5kwrKY9nf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADp/k1CtJV2b/2dsb2JhbABEDsMmgQiCHgEBAQMBAQEBDwEnGxkLBQcEAgEIEQQBAQEKFBAnCx0IAgQOBQgah14GC5xdoAuLexQBhUVhA4tIkQiIAIFrgjI9gVsBCBce X-IronPort-AV: E=Sophos;i="4.80,697,1344211200"; d="scan'208";a="138050030" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 02 Nov 2012 08:12:33 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA28CWMP012268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 08:12:32 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 03:12:32 -0500 From: "JP Vasseur (jvasseur)" To: Mukul Goyal Thread-Topic: [manet] Reactive routing protocols, what are the differences? Thread-Index: AQHNuNHOl2E4qtkFWke3jvlbxbxIOg== Date: Fri, 2 Nov 2012 08:12:31 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204AA8F@xmb-rcd-x02.cisco.com> References: <2040745028.185576.1351828002677.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <2040745028.185576.1351828002677.JavaMail.root@mail17.pantherlink.uwm.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.149.112] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--53.822000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <1A32286CCD905741BBFF4EF1F89A482C@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Christopher Dearlove \(UK\)" , "" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 08:12:36 -0000 Hi Mukul, On Nov 1, 2012, at 11:46 PM, Mukul Goyal wrote: > Hi Ulrich >=20 > Thanks for pointing out the key differences between the two protocols. Go= ing over this list and having read both drafts, I have the following opinio= n: >=20 > 1) It seems to me that there are no technical reasons why the two drafts = cannot be merged. The fact that it was not possible to merge the two propos= als is unfortunate. > 2) Perceived strengths of LOADng, such as facilitating end-to-end securit= y, can easily be adopted in DYMO/AODV2. Bidirectionality verification can b= e done either inside the protocol or in an independent manner.=20 > 3) It seems to me that, functionality wise, LOADng is a restricted versio= n of DYMO/AODVv2. In other words, it is possible to configure a DYMO deploy= ment to behave like a LOADng deployment. Charlie made the same point in an = earlier message. If LOADng is chosen in place of DYMO/AODVv2, we will lose = nice features you pointed out: JP> This is exactly the point that I made "several" emails ago. Charlie pro= posed to include in DYMO/AODVv2 functionalities of LOAD-ng, with options. This is the option 1. Fully agreeing with your analysis. Thanks. JP. >=20 > "- DYMO has several options for expanding ring RREQ, precursor list, > adding route information in transit, message aggregation in RFC5444 > packets and reporting multiple unreachable addresses in a RERR." >=20 > These features seem useful in general MANET scenarios. >=20 > Just my $0.02. >=20 > Thanks > Mukul >=20 >=20 > ----- Original Message ----- > From: "Ulrich Herberg" > To: "Christopher Dearlove (UK)" > Cc: manet@ietf.org, "Thomas Heide Clausen (thomas@thomasclausen.org)" > Sent: Thursday, November 1, 2012 5:02:05 PM > Subject: Re: [manet] Reactive routing protocols, what are the differences= ? >=20 > Hi Chris, >=20 > you have seen my review on DYMO. I will try to answer to your > question, and focus on the technical differences, not presentation. >=20 >=20 > On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK) > wrote: >> The obviously best people to answer this should be document authors, but= anyone else may have useful additions and comments. Ideally the different = document authors could agree a list. (If they differ in that one has X and = the other doesn't, but one wants to say "we plan to add/remove X" then X sh= ould be listed as a difference with that caveat, in at least my ideal world= .) >>=20 >> If we set aside, for the moment (though these things matter): >> - The presentational quality of the documents, >> - Any issues of 5444 compliance and other formatting issues, >> - Issues of internal data organisation, >> - Minor details such as possible different timeout parameters etc. >> then what are the technical (and I stress that word) differences between= DYMO and LOADng? (I'm withholding the term AODVv2 for reasons I may come b= ack to.) >=20 >=20 > First, let's see what is common. Both are reactive protocols, using > RREQ, RREP and RERR. So if someone claims that DYMO performs great and > LOADng badly in the same scenario, I cannot understand that. MANET has > understood the scenarios where reactive protocols are useful and where > not. >=20 > Now, to the differences: >=20 > - DYMO cannot be end-to-end secured. Messages are changed in transit > (and not just hop-limit or the metric), but rather addresses can be > removed from RERRs and RREQs. There is also no provision to allow > external mechanisms to add additional reasons to reject messages as > invalid. > - DYMO uses the originator address in an address block, LOADng in the > message header. The sequence number is a TLV value in DYMO, and LOADng > uses the message sequence number. DYMO requires the originator address > to be the first one in the address block, the destination must be the > second one. LOADng uses a TLV to determine the target address. > - DYMO can advertise multiple addresses in an RERR; they can be > removed in transit of the message. > - DYMO allows intermediate routers to reply (as an option). That makes > end-to-end security difficult. In the core DYMO, there is a > destination sequence number that may be contained in RREQs in DYMO. > - DYMO allows for unicast RREQ, but does not specify in detail how to use= that. > - There are four timers for each route entry in DYMO, only one in LOADng. > - LOADng can be used on other layers; DYMO is tied to IP. > - LOADng provides a bidirectionality verification using RREP_ACK, a > time-out of these, a blacklisted set and a Pending Acknowledgment Set > to verify bidirectional links. DYMO says that other mechanisms can be > used, but does not specify these. > - DYMO has several options for expanding ring RREQ, precursor list, > adding route information in transit, message aggregation in RFC5444 > packets and reporting multiple unreachable addresses in a RERR. LOADng > takes the approach to have a slim core of a basic mechanism that is > applicable in all MANET use cases, and companion documents with > extensions. In DYMO, it is not clearly specified what happens if some > routers support an option, and others don't. > - LOADng uses a Metric message TLV, and it is clearly defined how to > update the metric under way. If a router in transit does not recognize > a route metric type, it is reset to a "hop count" tlv extension type > of the Metric TLV and the value set to 0xFFFFF... (for the full TLV > length). It is specified that security mechanism must ignore the > content of the metric TLV value and that the length cannot be changed > under way, so that end-to-end security is possible. DYMO uses an > optional "distance" field for the metric, which is not clearly > specified how it is updated. Also, since this is optional, it is > unclear if routers receiving a message and forwarding it, update the > distance field or not. > - LOADng allows for (optionally) waiting to reply with a RREP, in case > a "better" RREQ comes a little later. In DYMO, a RREP is always sent > immediately. >=20 > There are probably more differences, but I let other chime in. >=20 > Best regards > Ulrich >=20 >=20 >> Note that it's a lot more useful to have direct differences than differe= nces of each from AODV (especially when both have the same difference). And= it would be useful to have the objective differences separated from the "a= nd now why this is better" discussion - though that would be a next step. >>=20 >> I'm not saying I don't see any of the differences. But I certainly haven= 't worked out the complete list. In trying to form my view of how things sh= ould go forward (a view that is coming together, and when it does, I'll arg= ue for it) and I hope for other people as well, it would be good to know wh= at the differences are. Regardless of views for or against each, we should = be able to objectively list the significant differences - if we can't then = something is wrong. >>=20 >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >>=20 >> ******************************************************************** >> 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. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Fri Nov 2 01:17:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272D821F93BC for ; Fri, 2 Nov 2012 01:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.481 X-Spam-Level: X-Spam-Status: No, score=-10.481 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yzQnSSj98ei for ; Fri, 2 Nov 2012 01:17:35 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6853321F94A4 for ; Fri, 2 Nov 2012 01:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34632; q=dns/txt; s=iport; t=1351844255; x=1353053855; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Qm1tA7X0byDd+JQ46m1G6Oqn9KnnYvYbATcozHaAWi0=; b=FH4W4T4ik5Jy7w0cKh6N8q4oAqfWL+Juhz8DGcuqWx68Two5XT5Ql92Y 6td+DCpD52EYbWD1pgbtYMmbq76/OTuA0yjbGrCKGRMOF5jlwVdrZKPyA wVEfVDpMpbtcIraYOzoSczVdMRInuuD9Pbe9IbMvLWUqbzTou8GZzh9jz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAF6Ak1CtJXG+/2dsb2JhbABEgkmuUZIagQiCHgEBAQQBAQEPAVsLEAIBCA4DBAEBCxYBBgcnCxMBCQgCBA4FCBMHh1IDDwucUaAHBIsUZ4VaYQOUJ40DgyaBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,697,1344211200"; d="scan'208,217";a="138088933" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 02 Nov 2012 08:17:34 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA28HYPe031387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 08:17:34 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 03:17:34 -0500 From: "JP Vasseur (jvasseur)" To: Jon Black Thread-Topic: [manet] LOADng works Thread-Index: AQHNuF9dW2UMul6sMEaXNf6TARakEQ== Date: Fri, 2 Nov 2012 08:17:33 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> In-Reply-To: <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.149.112] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--52.257600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204AAEDxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 08:17:38 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204AAEDxmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jon, On Nov 1, 2012, at 11:51 PM, Jon Black wrote: In line [Jon2] ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: "manet@ietf.org" > Sent: Thursday, November 1, 2012 12:33 PM Subject: Re: [manet] LOADng works Hi Jon, In line - JP2> On Nov 1, 2012, at 4:32 PM, Jon Black wrote: ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: "manet@ietf.org" >; "thierry.lys@erdfdistribution.fr" > Sent: Thursday, November 1, 2012 3:41 AM Subject: Re: [manet] (no subject) Hi Jon, On Nov 1, 2012, at 12:39 AM, Jon Black wrote: Yes it shows that it does work in a rather large deployment. JP> This is not just a question of "how large" it is =85 but also how dynam= ic. I could show you few hundreds (if not less number of nodes) not working if the traffic pattern is too dynamic. This is a fundamental pr= oblem. [Jon] Are you saying that their AMI PLC deployment was not dynamic? JP2> We do not have any details so I cannot comment on *that* deployment; m= y point was that you can easily show why the number of nodes is NOT the only issues with reactive routing protocols in LLNs. Ta= ke actual traces (which I personally did with actual deployed networks) and simulate the control plane traffic with moderate use traffic = demand and you will see the issue with such routing approach. In other words, even with a relatively small number of nodes, in contrast w= ith other proactive routing protocols, if the user traffic is moderate (not even very high), you clearly see why this reactive routing is ill suit= ed to LLNs. [Jon2] There are plenty of well working LLNs that use reactive protocols su= ch as AODV. I've built and deployed them so perhaps you can't but I can an= d the protocol and network work well. It depends on the type of traffic, n= odes, radio, ... To say that you can only build a working LLN using a proa= ctive protocol is just plain foolish. JP2> Let's try to be gentle and respectful. If you have built such networks= , feel free to share; But this is certainly not the conclusion the ROLL WG shared after 4 years of work. I have heard others say that it works in other deployments as well - just t= he same as you say RPL works in some deployments. JP> I do not not think that we should go in a RPL versus Load-NG debate but= rather try to find a good solution for MANET. That being said, RPL *for* LLNs the the result of a 4-year work with a DT, weekly call= s, interim WG meetings to make it work in LLNs. [Jon] I did not cast this as a RPL vs LOADng debate - you just did. I am s= aying that LOADng works in some scenarios and proof is the EDF deployment i= n their AMI network. JP2> I would be happy to see detailed results and especially the user traff= ic profiles for the reason exposed above. [Jon2] JP actually it doesn't matter! You say that you CANNOT build a work= ing LLN using a reactive protocol. EDF has proved that wrong. They built = one. You can continue to claim that you can't, but there is an existence p= roof. JP3> You keep ignoring my point. Of it matters. I would even make it work w= ith BGP-4. Would you recommend the use of BGP in LLN ? If you deploy a protocol in very specific conditions that do not apply to m= ost LLNs, then you may want to know it before making it an RFC. Please share your results. You keeps saying you will and you we keep askin= g you to - where's the results so they can be reviewed. JP> Once again, I would first like to hear chair's decision. PLEASE note th= at I would be happy to see Load's results too. And just be patient, I just need to find a bit of time to compile results and you will = get many results backing up my claims. Please also refer to the number of discussions prior to designing RPL that took place on the ROLL ma= iling list. Believe me there was a reason not NOT choosing a reactive protocol for LLN (again I am NOT against reactive routing for ot= her use cases at all). Would you ignore the findings of a WG that worked for 4 years on the subject matter ? I guess not =85 Just trying= to raise my voice (as many others on this list) to protect the Internet. [Jon] As others have said - you have it backwards. If you have data that w= ould show that LOADng or a reactive protocol will not work in MANETs please= share it. JP2> Please reread what I wrote ten times =85 I said "LLNs" not "MANET" in = general. On top of that, I do prefer the option 1) for the reasons exposed before (this is the WG document, Charlie made it compatible + other technic= al reasons). You did say LLNs but again you are wrong. There are plenty of LLNS that ha= ve been built using reactive (and proactive) protocols and will continue to= be built using reactive (and proactive protocols). There is no one size f= its all. I prefer to have a debate based on facts and not conjecture and based on te= chnical arguments. That would be very insightful and would help guide this discussion and decision. It woul= d not be prudent to make a decision and then bring out data that would try = to suggest that the decision was incorrect. What findings are you referring to? Where is there a WG document that docu= ments these findings? [Jon2] I noticed you skipped this. JP3> I do not skip anything. I am respectful of the question asked by the c= hair, knowing that their task is to say the least not easy. As soon as required, I will provide lots of data, at least the ones that ca= n be shared, if authorization is given by the owners of these networks. Thanks. JP. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: "manet@ietf.org" >; "thierry.lys@erdfdistribution.fr" > Sent: Wednesday, October 31, 2012 4:09 PM Subject: Re: [manet] (no subject) On Oct 31, 2012, at 6:57 PM, Jon Black wrote: On October 31, 2012 Thierry.Lys wrote: I speak in the name of EDF group. We started first to use LOAD as a routing algorithm and deployed 2000 PLC-m= eters for smart grid purposes in 2011. Taking advantage of this field test,= we have been actively participating to the working group to adopt enhancem= ents in the LOADng specification. We are now extremely pleased with what LOADng is capable of and are confide= nt that future deployements will be equipped with it. This would seem to indicate that LOADng does work and in a rather large dep= loyment. JP> No this means that LoadNG works in *a* network. But the major technical= difference here is that reactive routing is highly impacted by the user traffic =85 If you poll a meter every 24 hours, it may work per= fectly well. Now if you start having more frequent traffic flows you can either cache paths (ending up with more frequent broken paths consi= dering how flappy these networks are, thus leading to more floods =85 very undesirable =85 especially when you have hundreds of meters= sharing a few Kbits/s) or you use short cache timers and you keep flooding :-( If you take actual traces of these networks (both using 1= 5.4g and P1901.2) and you start adjusting the user traffic rate you immediately see the issues in terms of scalability. Yes you can try to miti= gate the undesirable flooding effect to some extends but showing the limits in terms of scalability is easy to show. Note that I MOT against= reactive routing by any means, this is IMO just not applicable to LLNs unless the traffic flows are deterministic and very well knows =85 Les= sons from the past show us how difficult it is to predict user applications. We all started with meter reading to continue with that examp= le and now many utilities wants to use these smart metering networks for a number of applications which different SLA, =85 Hope this helps. Once again, when/if required I would be happy to share man= y results. "We believe in rough consensus and running code" rough consensus : Don't you think we have a rough consensus on LOADng compa= red to DYMO ? 10 authors and major companies are supporters of LOADng. running code : interoperability has been checked with 4 sources and other i= mplementations are in progress. Obviously from the list we don't have rough consensus. We have two alterna= tives each with proponents. The WG should weigh the technical benefits (de= sign, implementation/running code, maturity) of each and the group should = choose a path forward. In my opinion option 3 is not an option - this is the working group shirkin= g its responsibility. This is an option =85 since listed by the chairs. I agree that we should av= oid it, especially when I think we have a very reasonable solution (option1). JP. Jon _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204AAEDxmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Jon,

On Nov 1, 2012, at 11:51 PM, Jon Black wrote:

In line [Jon2]


From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@ietf.org>
Sent: Thursday, November 1= , 2012 12:33 PM
Subject: Re: [manet] LOADn= g works

Hi Jon,

In line - JP2>

On Nov 1, 2012, at 4:32 PM, Jon Black wrote:



From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@i= etf.org>; "thierr= y.lys@erdfdistribution.fr" <thierry.lys@erdfdistribution.fr>
Sent: Thursday, November 1,= 2012 3:41 AM
Subject: Re: [manet] (no su= bject)

Hi Jon,

On Nov 1, 2012, at 12:39 AM, Jon Black wrote:

Yes it shows that it does work in a rather large deployment.&nbs= p;

JP> This is not just a question of "how large" it is =85 = but also how dynamic. I could show you few hundreds (if not less number of = nodes)
not working if the traffic pattern is too dynamic. This is a fundament= al problem.

[Jon] Are you saying that their AMI PLC deployment was not dynamic?

JP2> We do not have any details so I cannot comment on *that* deplo= yment; my point was that you can easily show why the number
of nodes is NOT the only issues with reactive routing protocols in LLN= s. Take actual traces (which I personally did with actual deployed
networks) and simulate the control plane traffic with moderate use tra= ffic demand and you will see the issue with such routing approach.
In other words, even with a relatively small number of nodes, in contr= ast with other proactive routing protocols, if the user traffic is moderate=
(not even very high), you clearly see why this reactive routing is ill= suited to LLNs.

[Jon2] There are plenty of well working LLNs that use reactive protocols su= ch as AODV.  I've built and deployed them so perhaps you can't but I c= an and the protocol and network work well.  It depends on the type of = traffic, nodes, radio, ...  To say that you can only build a working LLN using a proactive protocol is just plain fool= ish.

JP2> Let's try to be gentle and respectful. If you have built such = networks, feel free to share; But this is certainly not the conclusion the = ROLL
WG shared after 4 years of work.



I have heard others say that it works in other deployments as we= ll - just the same as you say RPL works in some deployments.


JP> I do not not think that we should go in a RPL versus Load-NG de= bate but rather try to find a good solution for MANET. That being
said, RPL *for* LLNs the the result of a 4-year work with a DT, weekly= calls, interim WG meetings to make it work in LLNs.

[Jon] I did not cast this as a RPL vs LOADng debate - you just did.  I= am saying that LOADng works in some scenarios and proof is the EDF deploym= ent in their AMI network.

JP2> I would be happy to see detailed results and especially the us= er traffic profiles for the reason exposed above.

[Jon2] JP actually it doesn't matter!  You say that you CANNOT build a= working LLN using a reactive protocol.  EDF has proved that wrong.&nb= sp; They built one.  You can continue to claim that you can't, but the= re is an existence proof.

JP3> You keep ignoring my point. Of it matters. I would even make i= t work with BGP-4. Would you recommend the use of BGP in LLN ?
If you deploy a protocol in very specific conditions that do not apply= to most LLNs, then you may want to know it before making it an RFC.



Please share your results.  You keeps saying you will and you we= keep asking you to - where's the results so they can be reviewed.


JP> Once again, I would first like to hear chair's decision. PLEASE= note that I would be happy to see Load's results too. And just be
patient, I just need to find a bit of time to compile results and you = will get many results backing up my claims. Please also refer to the
number of discussions prior to designing RPL that took place on the RO= LL mailing list. Believe me there was a reason not NOT choosing
a reactive protocol for LLN (again I am NOT against reactive routing f= or other use cases at all). Would you ignore the findings of a WG
that worked for 4 years on the subject matter ? I guess not =85 Just t= rying to raise my voice (as many others on this list) to protect the
Internet.

[Jon] As others have said - you have it backwards.  If you have data t= hat would show that LOADng or a reactive protocol will not work in MANETs p= lease share it. 

JP2> Please reread what I wrote ten times =85 I said "LLNs&quo= t; not "MANET" in general. On top of that, I do prefer the option= 1) for the reasons exposed 
before (this is the WG document, Charlie made it compatible + othe= r technical reasons).

You did say LLNs but again you are wrong.  There are plenty of LLNS th= at have been built using reactive (and proactive) protocols and will contin= ue to be built using reactive (and proactive protocols).  There is no = one size fits all.

I prefer to have a debate based on facts and not conjecture and based on te= chnical arguments.

That would be
very insightful and would help guide this discussion and decision.  It= would not be prudent to make a decision and then bring out data that would= try to suggest that the decision was incorrect.

What findings are you referring to?  Where is there a WG document that= documents these findings?

[Jon2] I noticed you skipped this. 

JP3> I do not skip anything. I am respectful of the question asked = by the chair, knowing that their task is to say the least not easy.
As soon as required, I will provide lots of data, at least the ones th= at can be shared, if authorization is given by the owners of these
networks.

 

Thanks.

JP.

Jon


From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@i= etf.org>; "thierr= y.lys@erdfdistribution.fr" <thierry.lys@erdfdistribution.fr>
Sent: Wednesday, October 31= , 2012 4:09 PM
Subject: Re: [manet] (no su= bject)


On Oct 31, 2012, at 6:57 PM, Jon Black wrote:

On October 31, 2012 Thierry.Lys wrote:

I speak in the name of EDF group.

We started first to use LOAD as a rout= ing algorithm and deployed 2000 PLC-meters for smart grid purposes in 2011.= Taking advantage of this field test, we have been actively participating t= o the working group to adopt enhancements in the LOADng specification.
We are now extremely pleased with what= LOADng is capable of and are confident that future deployements will be eq= uipped with it. 

This would seem to indicate that LOADng does work and in a rather large dep= loyment.

JP> No this means that LoadNG works in *a* network. But the major t= echnical difference here is that reactive routing is highly impacted
by the user traffic =85 If you poll a meter every 24 hours, it may wor= k perfectly well. Now if you start having more frequent traffic flows
you can either cache paths (ending up with more frequent broken paths = considering how flappy these networks are, thus leading to more
floods =85 very undesirable =85 especially when you have hundreds of m= eters sharing a few Kbits/s) or you use short cache timers and you
keep flooding :-( If you take actual traces of these networks (both us= ing 15.4g and P1901.2) and you start adjusting the user traffic rate you
immediately see the issues in terms of scalability. Yes you can try to= mitigate the undesirable flooding effect to some extends but showing =
the limits in terms of scalability is easy to show. Note that I MOT ag= ainst reactive routing by any means, this is IMO just not applicable to
LLNs unless the traffic flows are deterministic and very well knows = =85 Lessons from the past show us how difficult it is to predict user =
applications. We all started with meter reading to continue with that = example and now many utilities wants to use these smart metering 
networks for a number of applications which different SLA, =85 

Hope this helps. Once again, when/if required I would be happy to shar= e many results.



"We believe in rough consensus an= d running code"

rough consensus : Don't you think we h= ave a rough consensus on LOADng compared to DYMO ? 10 authors and major com= panies are supporters of LOADng.

running code : interoperability has be= en checked with 4 sources and other implementations are in progress.

Obviously from the list we don't ha= ve rough consensus.  We have two alternatives each with proponents.&nb= sp; The WG should weigh the technical benefits (design, implementation/runn= ing code, maturity)  of each and the group should choose a path forward.

In my opinion option 3 is not an option - this is the working group shirkin= g its responsibility.

This is an option =85 since listed by the chairs. I agree that we shou= ld avoid it, especially when I think we have a very reasonable solution
(option1).

JP.


Jon

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet






_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet




--_000_03B78081B371D44390ED6E7BADBB4A772204AAEDxmbrcdx02ciscoc_-- From jvasseur@cisco.com Fri Nov 2 01:47:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F8E21F87FD for ; Fri, 2 Nov 2012 01:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.283 X-Spam-Level: X-Spam-Status: No, score=-10.283 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vj3mbteTviTj for ; Fri, 2 Nov 2012 01:47:57 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0998021F99A9 for ; Fri, 2 Nov 2012 01:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35701; q=dns/txt; s=iport; t=1351846074; x=1353055674; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dO1o7pV088znWWrmMXhUFIgTjdZxo2Qa+GPGIyMR0gc=; b=IuB5qhl8gMalwAgvwB3i+MQdWNfxP4B/uXSPtkXqjwnCN2XAs2t5LfIH rvyudUy2CBv1Paj+7uoEM1A6IjtUcu4QMSzp39wQnlRrRbJHZHTEEHZmY R298Mf9mYiZqVl+Tqa58l3F9AiunuV5o8wNCSV99hqVF3cCFnl7lCxW7Q c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPKHk1CtJV2Y/2dsb2JhbABEgkmuUZIagQiCHgEBAQQBAQEPAVsLEAIBCA4DBAEBCxYBBgcnCxMBCQgCBA4FCBMHh1IDDwucMaAFBIsUZ4VaYQOUJ40DgyaBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,697,1344211200"; d="scan'208,217";a="138059027" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 02 Nov 2012 08:47:53 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA28lq29030510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 08:47:52 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 03:47:52 -0500 From: "JP Vasseur (jvasseur)" To: Jon Black Thread-Topic: [manet] LOADng works Thread-Index: AQHNuF9dW2UMul6sMEaXNf6TARakEZfWkIyA Date: Fri, 2 Nov 2012 08:47:51 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204AED7@xmb-rcd-x02.cisco.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.149.112] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--57.352000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204AED7xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 08:47:59 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204AED7xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear Jon, will you be at the next IETF meeting in MANET WG so that we can have a tech= nical discussion ? Thanks. JP. On Nov 2, 2012, at 4:17 AM, JP Vasseur (jvasseur) wrote: Hi Jon, On Nov 1, 2012, at 11:51 PM, Jon Black wrote: In line [Jon2] ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: "manet@ietf.org" > Sent: Thursday, November 1, 2012 12:33 PM Subject: Re: [manet] LOADng works Hi Jon, In line - JP2> On Nov 1, 2012, at 4:32 PM, Jon Black wrote: ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: "manet@ietf.org" >; "thierry.lys@erdfdistribution.fr" > Sent: Thursday, November 1, 2012 3:41 AM Subject: Re: [manet] (no subject) Hi Jon, On Nov 1, 2012, at 12:39 AM, Jon Black wrote: Yes it shows that it does work in a rather large deployment. JP> This is not just a question of "how large" it is =85 but also how dynam= ic. I could show you few hundreds (if not less number of nodes) not working if the traffic pattern is too dynamic. This is a fundamental pr= oblem. [Jon] Are you saying that their AMI PLC deployment was not dynamic? JP2> We do not have any details so I cannot comment on *that* deployment; m= y point was that you can easily show why the number of nodes is NOT the only issues with reactive routing protocols in LLNs. Ta= ke actual traces (which I personally did with actual deployed networks) and simulate the control plane traffic with moderate use traffic = demand and you will see the issue with such routing approach. In other words, even with a relatively small number of nodes, in contrast w= ith other proactive routing protocols, if the user traffic is moderate (not even very high), you clearly see why this reactive routing is ill suit= ed to LLNs. [Jon2] There are plenty of well working LLNs that use reactive protocols su= ch as AODV. I've built and deployed them so perhaps you can't but I can an= d the protocol and network work well. It depends on the type of traffic, n= odes, radio, ... To say that you can only build a working LLN using a proa= ctive protocol is just plain foolish. JP2> Let's try to be gentle and respectful. If you have built such networks= , feel free to share; But this is certainly not the conclusion the ROLL WG shared after 4 years of work. I have heard others say that it works in other deployments as well - just t= he same as you say RPL works in some deployments. JP> I do not not think that we should go in a RPL versus Load-NG debate but= rather try to find a good solution for MANET. That being said, RPL *for* LLNs the the result of a 4-year work with a DT, weekly call= s, interim WG meetings to make it work in LLNs. [Jon] I did not cast this as a RPL vs LOADng debate - you just did. I am s= aying that LOADng works in some scenarios and proof is the EDF deployment i= n their AMI network. JP2> I would be happy to see detailed results and especially the user traff= ic profiles for the reason exposed above. [Jon2] JP actually it doesn't matter! You say that you CANNOT build a work= ing LLN using a reactive protocol. EDF has proved that wrong. They built = one. You can continue to claim that you can't, but there is an existence p= roof. JP3> You keep ignoring my point. Of it matters. I would even make it work w= ith BGP-4. Would you recommend the use of BGP in LLN ? If you deploy a protocol in very specific conditions that do not apply to m= ost LLNs, then you may want to know it before making it an RFC. Please share your results. You keeps saying you will and you we keep askin= g you to - where's the results so they can be reviewed. JP> Once again, I would first like to hear chair's decision. PLEASE note th= at I would be happy to see Load's results too. And just be patient, I just need to find a bit of time to compile results and you will = get many results backing up my claims. Please also refer to the number of discussions prior to designing RPL that took place on the ROLL ma= iling list. Believe me there was a reason not NOT choosing a reactive protocol for LLN (again I am NOT against reactive routing for ot= her use cases at all). Would you ignore the findings of a WG that worked for 4 years on the subject matter ? I guess not =85 Just trying= to raise my voice (as many others on this list) to protect the Internet. [Jon] As others have said - you have it backwards. If you have data that w= ould show that LOADng or a reactive protocol will not work in MANETs please= share it. JP2> Please reread what I wrote ten times =85 I said "LLNs" not "MANET" in = general. On top of that, I do prefer the option 1) for the reasons exposed before (this is the WG document, Charlie made it compatible + other technic= al reasons). You did say LLNs but again you are wrong. There are plenty of LLNS that ha= ve been built using reactive (and proactive) protocols and will continue to= be built using reactive (and proactive protocols). There is no one size f= its all. I prefer to have a debate based on facts and not conjecture and based on te= chnical arguments. That would be very insightful and would help guide this discussion and decision. It woul= d not be prudent to make a decision and then bring out data that would try = to suggest that the decision was incorrect. What findings are you referring to? Where is there a WG document that docu= ments these findings? [Jon2] I noticed you skipped this. JP3> I do not skip anything. I am respectful of the question asked by the c= hair, knowing that their task is to say the least not easy. As soon as required, I will provide lots of data, at least the ones that ca= n be shared, if authorization is given by the owners of these networks. Thanks. JP. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: "manet@ietf.org" >; "thierry.lys@erdfdistribution.fr" > Sent: Wednesday, October 31, 2012 4:09 PM Subject: Re: [manet] (no subject) On Oct 31, 2012, at 6:57 PM, Jon Black wrote: On October 31, 2012 Thierry.Lys wrote: I speak in the name of EDF group. We started first to use LOAD as a routing algorithm and deployed 2000 PLC-m= eters for smart grid purposes in 2011. Taking advantage of this field test,= we have been actively participating to the working group to adopt enhancem= ents in the LOADng specification. We are now extremely pleased with what LOADng is capable of and are confide= nt that future deployements will be equipped with it. This would seem to indicate that LOADng does work and in a rather large dep= loyment. JP> No this means that LoadNG works in *a* network. But the major technical= difference here is that reactive routing is highly impacted by the user traffic =85 If you poll a meter every 24 hours, it may work per= fectly well. Now if you start having more frequent traffic flows you can either cache paths (ending up with more frequent broken paths consi= dering how flappy these networks are, thus leading to more floods =85 very undesirable =85 especially when you have hundreds of meters= sharing a few Kbits/s) or you use short cache timers and you keep flooding :-( If you take actual traces of these networks (both using 1= 5.4g and P1901.2) and you start adjusting the user traffic rate you immediately see the issues in terms of scalability. Yes you can try to miti= gate the undesirable flooding effect to some extends but showing the limits in terms of scalability is easy to show. Note that I MOT against= reactive routing by any means, this is IMO just not applicable to LLNs unless the traffic flows are deterministic and very well knows =85 Les= sons from the past show us how difficult it is to predict user applications. We all started with meter reading to continue with that examp= le and now many utilities wants to use these smart metering networks for a number of applications which different SLA, =85 Hope this helps. Once again, when/if required I would be happy to share man= y results. "We believe in rough consensus and running code" rough consensus : Don't you think we have a rough consensus on LOADng compa= red to DYMO ? 10 authors and major companies are supporters of LOADng. running code : interoperability has been checked with 4 sources and other i= mplementations are in progress. Obviously from the list we don't have rough consensus. We have two alterna= tives each with proponents. The WG should weigh the technical benefits (de= sign, implementation/running code, maturity) of each and the group should = choose a path forward. In my opinion option 3 is not an option - this is the working group shirkin= g its responsibility. This is an option =85 since listed by the chairs. I agree that we should av= oid it, especially when I think we have a very reasonable solution (option1). JP. Jon _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204AED7xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Dear Jon,

will you be at the next IETF meeting in MANET WG so that we can have a= technical discussion ?

Thanks.

JP.

On Nov 2, 2012, at 4:17 AM, JP Vasseur (jvasseur) wrote:

Hi Jon,

On Nov 1, 2012, at 11:51 PM, Jon Black wrote:

In line [Jon2]


From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@ietf.org>
Sent: Thursday, November 1= , 2012 12:33 PM
Subject: Re: [manet] LOADn= g works

Hi Jon,

In line - JP2>

On Nov 1, 2012, at 4:32 PM, Jon Black wrote:



From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@i= etf.org>; "thierr= y.lys@erdfdistribution.fr" <thierry.lys@erdfdistribution.fr>
Sent: Thursday, November 1,= 2012 3:41 AM
Subject: Re: [manet] (no su= bject)

Hi Jon,

On Nov 1, 2012, at 12:39 AM, Jon Black wrote:

Yes it shows that it does work in a rather large deployment.&nbs= p;

JP> This is not just a question of "how large" it is =85 = but also how dynamic. I could show you few hundreds (if not less number of = nodes)
not working if the traffic pattern is too dynamic. This is a fundament= al problem.

[Jon] Are you saying that their AMI PLC deployment was not dynamic?

JP2> We do not have any details so I cannot comment on *that* deplo= yment; my point was that you can easily show why the number
of nodes is NOT the only issues with reactive routing protocols in LLN= s. Take actual traces (which I personally did with actual deployed
networks) and simulate the control plane traffic with moderate use tra= ffic demand and you will see the issue with such routing approach.
In other words, even with a relatively small number of nodes, in contr= ast with other proactive routing protocols, if the user traffic is moderate=
(not even very high), you clearly see why this reactive routing is ill= suited to LLNs.

[Jon2] There are plenty of well working LLNs that use reactive protocols su= ch as AODV.  I've built and deployed them so perhaps you can't but I c= an and the protocol and network work well.  It depends on the type of = traffic, nodes, radio, ...  To say that you can only build a working LLN using a proactive protocol is just plain fool= ish.

JP2> Let's try to be gentle and respectful. If you have built such = networks, feel free to share; But this is certainly not the conclusion the = ROLL
WG shared after 4 years of work.



I have heard others say that it works in other deployments as we= ll - just the same as you say RPL works in some deployments.


JP> I do not not think that we should go in a RPL versus Load-NG de= bate but rather try to find a good solution for MANET. That being
said, RPL *for* LLNs the the result of a 4-year work with a DT, weekly= calls, interim WG meetings to make it work in LLNs.

[Jon] I did not cast this as a RPL vs LOADng debate - you just did.  I= am saying that LOADng works in some scenarios and proof is the EDF deploym= ent in their AMI network.

JP2> I would be happy to see detailed results and especially the us= er traffic profiles for the reason exposed above.

[Jon2] JP actually it doesn't matter!  You say that you CANNOT build a= working LLN using a reactive protocol.  EDF has proved that wrong.&nb= sp; They built one.  You can continue to claim that you can't, but the= re is an existence proof.

JP3> You keep ignoring my point. Of it matters. I would even make i= t work with BGP-4. Would you recommend the use of BGP in LLN ?
If you deploy a protocol in very specific conditions that do not apply= to most LLNs, then you may want to know it before making it an RFC.



Please share your results.  You keeps saying you will and you we= keep asking you to - where's the results so they can be reviewed.


JP> Once again, I would first like to hear chair's decision. PLEASE= note that I would be happy to see Load's results too. And just be
patient, I just need to find a bit of time to compile results and you = will get many results backing up my claims. Please also refer to the
number of discussions prior to designing RPL that took place on the RO= LL mailing list. Believe me there was a reason not NOT choosing
a reactive protocol for LLN (again I am NOT against reactive routing f= or other use cases at all). Would you ignore the findings of a WG
that worked for 4 years on the subject matter ? I guess not =85 Just t= rying to raise my voice (as many others on this list) to protect the
Internet.

[Jon] As others have said - you have it backwards.  If you have data t= hat would show that LOADng or a reactive protocol will not work in MANETs p= lease share it. 

JP2> Please reread what I wrote ten times =85 I said "LLNs&quo= t; not "MANET" in general. On top of that, I do prefer the option= 1) for the reasons exposed 
before (this is the WG document, Charlie made it compatible + othe= r technical reasons).

You did say LLNs but again you are wrong.  There are plenty of LLNS th= at have been built using reactive (and proactive) protocols and will contin= ue to be built using reactive (and proactive protocols).  There is no = one size fits all.

I prefer to have a debate based on facts and not conjecture and based on te= chnical arguments.

That would be
very insightful and would help guide this discussion and decision.  It= would not be prudent to make a decision and then bring out data that would= try to suggest that the decision was incorrect.

What findings are you referring to?  Where is there a WG document that= documents these findings?

[Jon2] I noticed you skipped this. 

JP3> I do not skip anything. I am respectful of the question asked = by the chair, knowing that their task is to say the least not easy.
As soon as required, I will provide lots of data, at least the ones th= at can be shared, if authorization is given by the owners of these
networks.

 

Thanks.

JP.

Jon


From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@i= etf.org>; "thierr= y.lys@erdfdistribution.fr" <thierry.lys@erdfdistribution.fr>
Sent: Wednesday, October 31= , 2012 4:09 PM
Subject: Re: [manet] (no su= bject)


On Oct 31, 2012, at 6:57 PM, Jon Black wrote:

On October 31, 2012 Thierry.Lys wrote:

I speak in the name of EDF group.

We started first to use LOAD as a rout= ing algorithm and deployed 2000 PLC-meters for smart grid purposes in 2011.= Taking advantage of this field test, we have been actively participating t= o the working group to adopt enhancements in the LOADng specification.
We are now extremely pleased with what= LOADng is capable of and are confident that future deployements will be eq= uipped with it. 

This would seem to indicate that LOADng does work and in a rather large dep= loyment.

JP> No this means that LoadNG works in *a* network. But the major t= echnical difference here is that reactive routing is highly impacted
by the user traffic =85 If you poll a meter every 24 hours, it may wor= k perfectly well. Now if you start having more frequent traffic flows
you can either cache paths (ending up with more frequent broken paths = considering how flappy these networks are, thus leading to more
floods =85 very undesirable =85 especially when you have hundreds of m= eters sharing a few Kbits/s) or you use short cache timers and you
keep flooding :-( If you take actual traces of these networks (both us= ing 15.4g and P1901.2) and you start adjusting the user traffic rate you
immediately see the issues in terms of scalability. Yes you can try to= mitigate the undesirable flooding effect to some extends but showing =
the limits in terms of scalability is easy to show. Note that I MOT ag= ainst reactive routing by any means, this is IMO just not applicable to
LLNs unless the traffic flows are deterministic and very well knows = =85 Lessons from the past show us how difficult it is to predict user =
applications. We all started with meter reading to continue with that = example and now many utilities wants to use these smart metering 
networks for a number of applications which different SLA, =85 

Hope this helps. Once again, when/if required I would be happy to shar= e many results.



"We believe in rough consensus an= d running code"

rough consensus : Don't you think we h= ave a rough consensus on LOADng compared to DYMO ? 10 authors and major com= panies are supporters of LOADng.

running code : interoperability has be= en checked with 4 sources and other implementations are in progress.

Obviously from the list we don't ha= ve rough consensus.  We have two alternatives each with proponents.&nb= sp; The WG should weigh the technical benefits (design, implementation/runn= ing code, maturity)  of each and the group should choose a path forward.

In my opinion option 3 is not an option - this is the working group shirkin= g its responsibility.

This is an option =85 since listed by the chairs. I agree that we shou= ld avoid it, especially when I think we have a very reasonable solution
(option1).

JP.


Jon

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet






_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet




_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A772204AED7xmbrcdx02ciscoc_-- From yi.jiazi@gmail.com Fri Nov 2 02:42:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9753C21F9972 for ; Fri, 2 Nov 2012 02:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IU1fCPj5VPFs for ; Fri, 2 Nov 2012 02:42:32 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 245E821F9971 for ; Fri, 2 Nov 2012 02:42:31 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1609632wgb.13 for ; Fri, 02 Nov 2012 02:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=AECLqNj/XKYtLahTV1cPujWt6/HXnirlECUTB55frIE=; b=eLfeGOZsPJLgxVEsiIJOfSLGMcMPlnXoOBhcVF1wtXzlhxR1ohr7PBwcflNVOVs6MM stbfHDB5mIc1HnCmw6FxhcKO60UIaY/i/tsKJZ2smGgAKzKWX6p5I89mxBVOmDzmfPJL SA4VBXCxo0clL68EWnUzmq9qlYi3Pvrpr8uelzFVGyHJ9R+RxZF0MlDzvfQGP1vru11n fhotUp8hoWjFQx1uhwSLEecrEj4bnPeM472KifU0yp4bYK1dgRjyiyWa6REB/2+7XGWM pDTaNATk+k1wdBgHJeSCReDf3jzBZx09COLIacU5WgRLHKeMdAVhrAJ3kHeBfu/SMikv 10zw== Received: by 10.180.93.163 with SMTP id cv3mr1512667wib.21.1351849351242; Fri, 02 Nov 2012 02:42:31 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id dq6sm1519912wib.5.2012.11.02.02.42.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 02:42:29 -0700 (PDT) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_5C522514-92A8-4B08-9905-C75E5CF69F28" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi YI In-Reply-To: Date: Fri, 2 Nov 2012 10:42:26 +0100 Message-Id: References: To: Joydeep Tripathi X-Mailer: Apple Mail (2.1499) Cc: manet@ietf.org Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 09:42:34 -0000 --Apple-Mail=_5C522514-92A8-4B08-9905-C75E5CF69F28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dear Joydeep,=20 Thanks for you comments. Ulrich has already given a detailed reply, so I = would be brief. Please check inline.=20 On Nov 2, 2012, at 1:58 AM, Joydeep Tripathi wrote: > Hi Joe and MANET WG, >=20 > I was following the discussion on which route to take for a reactive = protocol standard very closely, and I think I should post my opinion = also. I champion for Option 1, and here is why :=20 >=20 > I have read both AODVv2 (DYMO) and LOAD-ng drafts, and I have = simulated LOAD-ng myself as well. This experience, I believe, puts me in = a position to form an opinion comparing these two protocols. I certainly = agree, option 3 is *not* an option I would like to be chosen. Reactive = protocols, though very much unsuitable for LLNs and Smart Grid AMI meter = networks, may have some usefulness in certain networks for certain = sparse traffic scenario, and the WG should have a standard for the same. JY>I can't agree here. There have been large deployments of LOADng. But = this is not related to this discussion.=20 >=20 > Firstly, LOAD-ng is backed up by the argument that it has = implementations and interop documents. However, I have seen in the = mailing list, that certain question on details of the 'practical' = implementation of LOAD-ng has been avoided. A reactive protocol may do = well in a 2000 nodes smart meter network, if the data traffic to the = base station or collector is 1-2 times a day. This kind of = implementations, in my opinion, say nothing about usefulness of LOAD-ng = in Smart Grid networks or LLNs. Again, whether LLN may be considered as = a subset of MANET or not is a different question. But even then, = deployed LOAD-ng in a 2000 node network may (and in my opinion, will) = fail if traffic is increased. Agreed, one size does not fit all. = However, once we have multicast traffic in a smart grid or multiple = meters generating alert packets in a region at the same time, a reactive = protocol like LOAD-ng will lead to the break-down of the network. Anyone = can say multicast traffic or several meters reporting emergency at the = same time to the same station, is a very much likely situation in smart = grid. Were these situations considered during deployment? Please note, I = am NOT saying that AODVv2 / DYMO will be better in this case than = LOAD-ng. IMHO, any protocol can be shown 'working perfectly', if we = provide a favorable atmosphere only for it to work. Looking at that = perspective, I don't think, LOAD-ng working in one network under one = particular scenario should be considered a vital argument to discuss = whether to go with AODVv2 or LOAD-ng. One can write a working code of = AODVv2 in 2 days. The real question we should be asking, which protocol = is better suited for general MANET overall, and if there really is a = *necessity* of discarding a working group document. >=20 > Secondly, LOAD-ng was devised keeping LLN scenario in mind. It was = intended for ROLL WG, and since it had not been adopted in the ROLL WG, = it popped up in the MANET WG. The change that has been done to LOAD-ng = after dragging it to MANET WG, was really to change the message format = to adhere to RFC 5444, and do a "find and replace" of the term LLN with = 'MANET' along with changing the first 'L' of LOAD ng from 'LLN' to = 'Lightweight'. Since the protocol was designed for LLN at first, I do = not think it would be able to cover the broad spectrum that MANET = includes. Since we already have a WG document for a reactive protocol, I = do not see any strong reason to discard the current one in favor of an = individual draft, especially when even LOAD-ng authors agreed that this = protocol will not offer any notable performance difference compared to = AODVv2.=20 JY>Your first two arguments are self-contradictory. You are saying = "LOADng doesn't fit all", and in the same time, citing "those two will = not offer any notable performance difference". So my point is: 1. If LOADng can't meet the requirement of MANET, then either do = DYMO. I agree that they share the main mechanisms. 2. The reason why LOADng is much more mature than DYMO is that = it has much clearer specification, operation experience, interop test, = running code --- that matters most in IETF.=20 >=20 > At the same time, since I have read both drafts, I figured out that = AODVv2 is more generic to MANET than LOAD-ng. It offers the developer or = the deployment authority to chose form more than one options. For = example, AODVv2 has the option (but it is not mandated) to use a = precursor list or have an intermediate node to reply an RREQ. LOAD-ng = does not support either. I can understand that for an LLN it may be = beneficial for not maintaining a precursor list or having only the = destination reply t o a RREQ, there can be (and are) other instances of = MANETs where having the option of precursor list will come handy. This = can save on control overhead, using some storage space in the node. = LOAD-ng, in most cases does not provide this flexibility to the = developer to chose between options for specific deployment. Some MANET = deployment may be less harsh than others in nature. Hence, AODVv2 having = more open options than LOAD-ng, in most cases, seem beneficial to me. Of = course, there are other technical differences between these protocols. = But I believe there is a separate thread created for that. I will wait = for the draft authors to reply there first, and will reply with my = points if all those differences are not covered. There, I will = re-iterate the necessity of a protocol to be suited for MANET in = general, not only 'some' kind of MANETs. JY>Being "more generic" is not necessarily a good thing for standard = track protocol. In fact, DYMO gives a lot of options without specifying = them. This gives a lot of problems in interoperability and security = (please check Ulrich's comment to dymo-23. I will post my comments to = DYMO-23 later). I have no doubt that giving how smart you are, you can = implement DYMO in several days with your understanding, but I don't = believe with dymo-23, one can have independent interoperable = implementations.=20 JY>In fact, LOADng offers great flexibility by conforming to rfc5444, = and can be extended with other options. But this would appear as = separate documents with the considerations of interoperability and = security.=20 >=20 > Lastly, I do not come from any industry, neither I have any company = road-map of deliverable here. Being a PhD candidate in a university, I = tried to fairly judge the two options. So I read both drafts, and did = not find a strong enough reason to discard a current working group = document. Whether a few companies backing up a protocol over the other = can be a decisive criteria to chose a standard protocol or not, is in = the WG and its chairs most capable hands. Also, I did not, very clearly = understand how LOAD-ng, operating properly in a 2-5 routers test-bed may = be considered as proof of valid interoperability. I would very much = appreciate feedback if I am wrong, since I am in my learning phase :-) . = I have my 2 cents here - a) AODVv2 offers more flexibility, b) LOAD-ng = does not offer enough advantage over AODVv2 to discard the later, c) = LOAD-ng was not initially designed for MANET, and d) there are other = technical differences that make AODVv2 more suitable for MANETs over = LOAD-ng (To be covered in separate thread). My opinion - We should = stick to current WG document (AODVv2) and improve it and finish it as = soon as possible. I hereby stand for Option 1.=20 JY> I think I don't need to repeat my preferred option as one of the = LOADng authors. I'm not surprised by your position as researchers around = RPL either.=20 But I'm still vey appreciate your detailed comments as your first post = to manet mailing list (at least with my short memory). I'm glad to see = all those discussions are attracting more and more RPLers' attention. = Your experience can surely help us improving reactive protocol's = application to LLNs (as a subset of MANET), which makes the LOADng = authors can more focus on more general MANET applications.=20 best Jiazi >=20 > Thanks and Regards, >=20 > Joydeep Tripathi > PhD Candidate,=20 > Drexel University. >=20 >=20 > On Tue, Oct 30, 2012 at 7:13 PM, Joseph Macker = wrote: > Hello MANET working group (form Stan and Joe), >=20 > As you are all probably aware, there has been WG activity lately on = competing drafts for a MANET reactive protocol - DYMO (reviving the = current working group document that was parked due to inactivity), and = LOADng. Many months ago there was a somewhat authorship led movement = towards a common document effort and given positive feedback at the time = we the chairs thought this was the best approach given the authors = potential to come together and gain the best of both efforts. Since = that period, there has been some fairly strident and rancorous "at = times" debate between the authors of the two documents. >=20 > During IETF 84 in Vancouver, the co-chairs held a discussion with some = of the co-authors of the two documents. Our guidance to the co-authors = was to find a way to merge the two documents into one, as it was = perceived that are not technically far apart and they both derive = roughly from AODV concepts and LOADng had fairly active authorship and = implementation efforts. We provided a co-editing proposal to the authors = and gave them the timeframe of the Atlanta to come up with an answer = back to us regarding this. As of this writing, those discussions of a = potential commonn document and authorship merger have failed. >=20 > Therefore, we find ourselves at a crossroads. The authors of the two = documents are divided, and it is unlikely that progress on a merged = document can be reached based upon recent author feedback. I have also = polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat = disengaged on the issue at the present time. We see only 3 possible = paths forward: >=20 > 1. Continue the work on the DYMO document, starting with whether there = is consensus on its continued approach and also the desire to rename it = to AODVv2. > 2. Replace the existing DYMO document effort with the LOADng related = document effort, defusing ealier references to LLNs as recommended in = the last meeting minutes, and to focus more motivationally on general = MANET problem spaces (the authors seem to have agreed to this issue if = its a WG document). > 3. Remove the working group charter for a reactive protocol, = effectively killing both documents, at least from a working group (WG) = standpoint. This would not be a reflection on the technology in either = case, just an admission that we are not working together and reaching = consensus. >=20 > The co-chairs request and need your opinions on the options. We have = been some silent collecting initial feedback and waiting for author = feedback at this point. Stan and I are both on travel prior to Atlanta = so our responses may be sparse and we will also likely be in a "receive = mode" for a few days. So send your opinions. >=20 > -Joe >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_5C522514-92A8-4B08-9905-C75E5CF69F28 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 jt369@drexel.edu> = wrote:
Hi Joe and MANET WG,

I was following = the discussion on which route to take for a reactive protocol standard = very closely, and I think I should post my opinion also. I champion for = Option 1, and here is why : 

I have read both AODVv2 (DYMO) and LOAD-ng drafts, = and I have simulated LOAD-ng myself as well. This experience, I believe, = puts me in a position to form an opinion comparing these two protocols. = I certainly agree, option 3 is *not* an option I would like to be = chosen. Reactive protocols, though very much unsuitable for LLNs and = Smart Grid AMI meter networks, may have some usefulness in certain = networks for certain sparse traffic scenario, and the WG should have a = standard for the same.

JY>I = can't agree here. There have been large deployments of LOADng. But this = is not related to this discussion. 


Firstly, LOAD-ng is backed up by the argument that = it has implementations and interop documents. However, I have seen in = the mailing list, that certain question on details of the 'practical' = implementation of LOAD-ng has been avoided. A reactive protocol may do = well in a 2000 nodes smart meter network, if the data traffic to the = base station or collector is 1-2 times a day. This kind of = implementations, in my opinion, say nothing about usefulness of LOAD-ng = in Smart Grid networks or LLNs. Again, whether LLN may be considered as = a subset of MANET or not is a different question. But even then, = deployed LOAD-ng in a 2000 node network may (and in my opinion, will) = fail if traffic is increased. Agreed, one size does not fit all. = However, once we have multicast traffic in a smart grid or multiple = meters generating alert packets in a region at the same time, a reactive = protocol like LOAD-ng will lead to the break-down of the network. Anyone = can say multicast traffic or several meters reporting emergency at the = same time to the same station, is a very much likely situation in smart = grid. Were these situations considered during deployment? Please note, I = am NOT saying that AODVv2 / DYMO will be better in this case than = LOAD-ng. IMHO, any protocol can be shown 'working perfectly', if we = provide a favorable atmosphere only for it to work. Looking at that = perspective, I don't think, LOAD-ng working in one network under one = particular scenario should be considered a vital argument to discuss = whether to go with AODVv2 or LOAD-ng. One can write a working code = of AODVv2 in 2 days. The real question we should be asking, which = protocol is better suited for general MANET overall, and if there really = is a *necessity* of discarding a working group = document.

Secondly, LOAD-ng was devised keeping LLN scenario = in mind. It was intended for ROLL WG, and since it had not been adopted = in the ROLL WG, it popped up in the MANET WG. The change that has been = done to LOAD-ng after dragging it to MANET WG, was really to change the = message format to adhere to RFC 5444, and do a "find and replace" of the = term LLN with 'MANET' along with changing the first 'L' of LOAD ng from = 'LLN' to 'Lightweight'. Since the protocol was designed for LLN at = first, I do not think it would be able to cover the broad spectrum that = MANET includes. Since we already have a WG document for a reactive = protocol, I do not see any strong reason to discard the current one in = favor of an individual draft, especially when even LOAD-ng authors = agreed that this protocol will not offer any notable performance = difference compared to = AODVv2. 

JY>Your first two = arguments are self-contradictory. You are saying "LOADng doesn't fit = all", and in the same time, citing "those two will not offer any notable = performance difference". So my point is:
1. If = LOADng can't meet the requirement of MANET, then either do DYMO. I agree = that they share the main mechanisms.
2. The = reason why LOADng is much more mature than DYMO is that it has much = clearer specification, operation experience, interop test, running code = --- that matters most in IETF. 


At the same time, since I have read both drafts, I = figured out that AODVv2 is more generic to MANET than LOAD-ng. It offers = the developer or the deployment authority to chose form more than one = options. For example, AODVv2 has the option (but it is not mandated) to = use a precursor list or have an intermediate node to reply an RREQ. = LOAD-ng does not support either. I can understand that for an LLN it may = be beneficial for not maintaining a precursor list or having only the = destination reply t o a RREQ, there can be (and are) other instances of = MANETs where having the option of precursor list will come handy. This = can save on control overhead, using some storage space in the node. = LOAD-ng, in most cases does not provide this flexibility to the = developer to chose between options for specific deployment. Some MANET = deployment may be less harsh than others in nature. Hence, AODVv2 having = more open options than LOAD-ng, in most cases, seem beneficial to me. Of = course, there are other technical differences between these protocols. = But I believe there is a separate thread created for that. I will wait = for the draft authors to reply there first, and will reply with my = points if all those differences are not covered. There, I will = re-iterate the necessity of a protocol to be suited for MANET in = general, not only 'some' kind of = MANETs.

JY>Being "more generic" = is not necessarily a good thing for standard track protocol. In fact, = DYMO gives a lot of options without specifying them. This gives a lot of = problems in interoperability and security  (please check = Ulrich's comment to dymo-23. I will post my comments to DYMO-23 later). = I have no doubt that giving how smart you are, you can implement DYMO in = several days with your understanding, but I don't believe with dymo-23, = one can have independent interoperable = implementations. 

JY>In fact, LOADng = offers great flexibility by conforming to rfc5444, and can be extended = with other options. But this would appear as separate documents with the = considerations of interoperability and = security. 



Lastly, I do not come from any industry, neither I = have any company road-map of deliverable here. Being a PhD = candidate in a university, I tried to fairly judge the two options. So I = read both drafts, and did not find a strong enough reason to discard a = current working group document. Whether a few companies backing up a = protocol over the other can be a decisive criteria to chose a standard = protocol or not, is in the WG and its chairs most capable hands. Also, I = did not, very clearly understand how LOAD-ng, operating properly in a = 2-5 routers test-bed may be considered as proof of valid = interoperability. I would very much appreciate feedback if I am = wrong, since I am in my learning phase :-) . I have my 2 cents here - a) = AODVv2 offers more flexibility, b) LOAD-ng does not offer enough = advantage over AODVv2 to discard the later, c) LOAD-ng was not initially = designed for MANET, and d) there are other technical differences that = make AODVv2 more suitable for MANETs over LOAD-ng (To be covered in = separate thread).  My opinion - We should stick to current WG = document (AODVv2) and improve it and finish it as soon as possible. I = hereby stand for Option = 1. 


JY> = I think I don't need to repeat my preferred option as one of the LOADng = authors. I'm not surprised by your position as researchers around RPL = either. 
But I'm still vey appreciate your detailed = comments as your first post to manet mailing list (at least with my = short memory). I'm glad to see all those discussions are attracting more = and more RPLers' attention. Your experience can surely help us improving = reactive protocol's application to LLNs (as a subset of MANET), which = makes the LOADng authors can more focus on more general MANET = applications. 

best

Jiazi



Thanks and Regards,

Joydeep = Tripathi
PhD Candidate, 
Drexel = University.


On Tue, = Oct 30, 2012 at 7:13 PM, Joseph Macker <jpmacker@gmail.com> wrote:
Hello MANET working = group (form Stan and Joe),

As you are all probably aware, there = has been WG activity lately on competing drafts for a MANET reactive = protocol - DYMO (reviving the current working group document that was = parked due to inactivity), and LOADng. Many months ago there was a = somewhat authorship led movement towards a common document effort and = given positive feedback at the time we the chairs thought this was the = best approach given the authors potential to come together and gain the = best of both efforts.  Since that period, there has been some = fairly strident and rancorous "at times" debate between the authors of = the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with = some of the co-authors of the two documents. Our guidance to the = co-authors was to find a way to merge the two documents into one, as it = was perceived that are not technically far apart and they both derive = roughly from AODV concepts and LOADng had fairly active authorship and = implementation efforts. We provided a co-editing proposal to the authors = and gave them the timeframe of the Atlanta to come up with an answer = back to us regarding this.  As of this writing, those discussions = of a potential commonn document and authorship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two = documents are divided, and it is unlikely that progress on a merged = document can be reached based upon recent author feedback. I have also = polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat = disengaged on the issue at the present time.  We see only 3 = possible paths forward:

1. Continue the work on the DYMO document, starting with whether = there is consensus on its continued approach and also the desire to = rename it to AODVv2.
2. Replace the existing DYMO document effort = with the LOADng related document effort, defusing ealier references to = LLNs as recommended in the last meeting minutes, and to focus more = motivationally on general MANET problem spaces (the authors seem to have = agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively = killing both documents, at least from a working group (WG) standpoint. = This would not be a reflection on the technology in either case, just an = admission that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  = We have been some silent collecting initial feedback and waiting for = author feedback at this point.  Stan and I are both on travel prior = to Atlanta so our responses may be sparse and we will also likely be in = a "receive mode" for a few days.  So send your opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing = list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= --Apple-Mail=_5C522514-92A8-4B08-9905-C75E5CF69F28-- From c.chauvenet@watteco.com Fri Nov 2 03:10:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6096A21F99B3 for ; Fri, 2 Nov 2012 03:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3xV1MTCIEIf for ; Fri, 2 Nov 2012 03:10:29 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id A3DF721F86B9 for ; Fri, 2 Nov 2012 03:10:27 -0700 (PDT) Received: from mail213-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Fri, 2 Nov 2012 10:10:26 +0000 Received: from mail213-tx2 (localhost [127.0.0.1]) by mail213-tx2-R.bigfish.com (Postfix) with ESMTP id 718FAC801B0; Fri, 2 Nov 2012 10:10:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT005.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VPS-19(zz98dI9371Ic89bhc85dhzz1de0h1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bhbe3k1155h) Received: from mail213-tx2 (localhost.localdomain [127.0.0.1]) by mail213-tx2 (MessageSwitch) id 1351851022888963_355; Fri, 2 Nov 2012 10:10:22 +0000 (UTC) Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.238]) by mail213-tx2.bigfish.com (Postfix) with ESMTP id D4A85140048; Fri, 2 Nov 2012 10:10:22 +0000 (UTC) Received: from DBXPRD0510HT005.eurprd05.prod.outlook.com (157.56.252.165) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 2 Nov 2012 10:10:22 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT005.eurprd05.prod.outlook.com ([10.255.67.168]) with mapi id 14.16.0233.002; Fri, 2 Nov 2012 10:10:17 +0000 From: C Chauvenet To: Joydeep Tripathi Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNtvRAV6TKZOGU0EeXjdQ8Uxmd8pfVvJCAgACaC8w= Date: Fri, 2 Nov 2012 10:10:17 +0000 Message-ID: <5779F071-79A2-4E03-8CA3-0C8EF2A7A978@watteco.com> References: , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.44.175.115] Content-Type: multipart/alternative; boundary="_000_5779F07179A24E038CA30C8EF2A7A978wattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 10:10:31 -0000 --_000_5779F07179A24E038CA30C8EF2A7A978wattecocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am in violent agreement with all this message ! There are some crucial points to count here. C=E9dric. Sent from a phone Le 2 nov. 2012 =E0 01:59, "Joydeep Tripathi" > a =E9crit : Hi Joe and MANET WG, I was following the discussion on which route to take for a reactive protoc= ol standard very closely, and I think I should post my opinion also. I cham= pion for Option 1, and here is why : I have read both AODVv2 (DYMO) and LOAD-ng drafts, and I have simulated LOA= D-ng myself as well. This experience, I believe, puts me in a position to f= orm an opinion comparing these two protocols. I certainly agree, option 3 i= s *not* an option I would like to be chosen. Reactive protocols, though ver= y much unsuitable for LLNs and Smart Grid AMI meter networks, may have some= usefulness in certain networks for certain sparse traffic scenario, and th= e WG should have a standard for the same. Firstly, LOAD-ng is backed up by the argument that it has implementations a= nd interop documents. However, I have seen in the mailing list, that certai= n question on details of the 'practical' implementation of LOAD-ng has been= avoided. A reactive protocol may do well in a 2000 nodes smart meter netwo= rk, if the data traffic to the base station or collector is 1-2 times a day= . This kind of implementations, in my opinion, say nothing about usefulness= of LOAD-ng in Smart Grid networks or LLNs. Again, whether LLN may be consi= dered as a subset of MANET or not is a different question. But even then, d= eployed LOAD-ng in a 2000 node network may (and in my opinion, will) fail i= f traffic is increased. Agreed, one size does not fit all. However, once we= have multicast traffic in a smart grid or multiple meters generating alert= packets in a region at the same time, a reactive protocol like LOAD-ng wil= l lead to the break-down of the network. Anyone can say multicast traffic o= r several meters reporting emergency at the same time to the same station, = is a very much likely situation in smart grid. Were these situations consid= ered during deployment? Please note, I am NOT saying that AODVv2 / DYMO wil= l be better in this case than LOAD-ng. IMHO, any protocol can be shown 'wor= king perfectly', if we provide a favorable atmosphere only for it to work. = Looking at that perspective, I don't think, LOAD-ng working in one network = under one particular scenario should be considered a vital argument to disc= uss whether to go with AODVv2 or LOAD-ng. One can write a working code of A= ODVv2 in 2 days. The real question we should be asking, which protocol is b= etter suited for general MANET overall, and if there really is a *necessity= * of discarding a working group document. Secondly, LOAD-ng was devised keeping LLN scenario in mind. It was intended= for ROLL WG, and since it had not been adopted in the ROLL WG, it popped u= p in the MANET WG. The change that has been done to LOAD-ng after dragging = it to MANET WG, was really to change the message format to adhere to RFC 54= 44, and do a "find and replace" of the term LLN with 'MANET' along with cha= nging the first 'L' of LOAD ng from 'LLN' to 'Lightweight'. Since the proto= col was designed for LLN at first, I do not think it would be able to cover= the broad spectrum that MANET includes. Since we already have a WG documen= t for a reactive protocol, I do not see any strong reason to discard the cu= rrent one in favor of an individual draft, especially when even LOAD-ng aut= hors agreed that this protocol will not offer any notable performance diffe= rence compared to AODVv2. At the same time, since I have read both drafts, I figured out that AODVv2 = is more generic to MANET than LOAD-ng. It offers the developer or the deplo= yment authority to chose form more than one options. For example, AODVv2 ha= s the option (but it is not mandated) to use a precursor list or have an in= termediate node to reply an RREQ. LOAD-ng does not support either. I can un= derstand that for an LLN it may be beneficial for not maintaining a precurs= or list or having only the destination reply t o a RREQ, there can be (and = are) other instances of MANETs where having the option of precursor list wi= ll come handy. This can save on control overhead, using some storage space = in the node. LOAD-ng, in most cases does not provide this flexibility to th= e developer to chose between options for specific deployment. Some MANET de= ployment may be less harsh than others in nature. Hence, AODVv2 having more= open options than LOAD-ng, in most cases, seem beneficial to me. Of course= , there are other technical differences between these protocols. But I beli= eve there is a separate thread created for that. I will wait for the draft = authors to reply there first, and will reply with my points if all those di= fferences are not covered. There, I will re-iterate the necessity of a prot= ocol to be suited for MANET in general, not only 'some' kind of MANETs. Lastly, I do not come from any industry, neither I have any company road-ma= p of deliverable here. Being a PhD candidate in a university, I tried to fa= irly judge the two options. So I read both drafts, and did not find a stron= g enough reason to discard a current working group document. Whether a few = companies backing up a protocol over the other can be a decisive criteria t= o chose a standard protocol or not, is in the WG and its chairs most capabl= e hands. Also, I did not, very clearly understand how LOAD-ng, operating pr= operly in a 2-5 routers test-bed may be considered as proof of valid intero= perability. I would very much appreciate feedback if I am wrong, since I am= in my learning phase :-) . I have my 2 cents here - a) AODVv2 offers more = flexibility, b) LOAD-ng does not offer enough advantage over AODVv2 to disc= ard the later, c) LOAD-ng was not initially designed for MANET, and d) ther= e are other technical differences that make AODVv2 more suitable for MANETs= over LOAD-ng (To be covered in separate thread). My opinion - We should s= tick to current WG document (AODVv2) and improve it and finish it as soon a= s possible. I hereby stand for Option 1. Thanks and Regards, Joydeep Tripathi PhD Candidate, Drexel University. On Tue, Oct 30, 2012 at 7:13 PM, Joseph Macker > wrote: Hello MANET working group (form Stan and Joe), As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common documen= t effort and given positive feedback at the time we the chairs thought this= was the best approach given the authors potential to come together and gai= n the best of both efforts. Since that period, there has been some fairly = strident and rancorous "at times" debate between the authors of the two doc= uments. During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts = and LOADng had fairly active authorship and implementation efforts. We prov= ided a co-editing proposal to the authors and gave them the timeframe of th= e Atlanta to come up with an answer back to us regarding this. As of this = writing, those discussions of a potential commonn document and authorship m= erger have failed. Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss= ue at the present time. We see only 3 possible paths forward: 1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2. 2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document). 3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus. The co-chairs request and need your opinions on the options. We have been = some silent collecting initial feedback and waiting for author feedback at = this point. Stan and I are both on travel prior to Atlanta so our response= s may be sparse and we will also likely be in a "receive mode" for a few da= ys. So send your opinions. -Joe _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_5779F07179A24E038CA30C8EF2A7A978wattecocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

I am in violent agreement with all this  message !
There are some crucial points to count here. 

C=E9dric. 

Sent from a phone

Le 2 nov. 2012 =E0 01:59, "Joydeep Tripathi" <jt369@drexel.edu> a =E9crit :

Hi Joe and MANET WG,

I was following the discussion on which route to take for a reactive p= rotocol standard very closely, and I think I should post my opinion also. I= champion for Option 1, and here is why : 

I have read both AODVv2 (DYMO) and LOAD-ng drafts, and I have simulate= d LOAD-ng myself as well. This experience, I believe, puts me in a position= to form an opinion comparing these two protocols. I certainly agree, optio= n 3 is *not* an option I would like to be chosen. Reactive protocols, though very much unsuitable for LLNs and= Smart Grid AMI meter networks, may have some usefulness in certain network= s for certain sparse traffic scenario, and the WG should have a standard fo= r the same.

Firstly, LOAD-ng is backed up by the argument that it has implementati= ons and interop documents. However, I have seen in the mailing list, that c= ertain question on details of the 'practical' implementation of LOAD-ng has= been avoided. A reactive protocol may do well in a 2000 nodes smart meter network, if the data traffic to th= e base station or collector is 1-2 times a day. This kind of implementation= s, in my opinion, say nothing about usefulness of LOAD-ng in Smart Grid net= works or LLNs. Again, whether LLN may be considered as a subset of MANET or not is a different question. But= even then, deployed LOAD-ng in a 2000 node network may (and in my opinion,= will) fail if traffic is increased. Agreed, one size does not fit all. How= ever, once we have multicast traffic in a smart grid or multiple meters generating alert packets in a region at= the same time, a reactive protocol like LOAD-ng will lead to the break-dow= n of the network. Anyone can say multicast traffic or several meters report= ing emergency at the same time to the same station, is a very much likely situation in smart grid. Were thes= e situations considered during deployment? Please note, I am NOT saying tha= t AODVv2 / DYMO will be better in this case than LOAD-ng. IMHO, any pr= otocol can be shown 'working perfectly', if we provide a favorable atmosphere only for it to work. Looking at that = perspective, I don't think, LOAD-ng working in one network under one particular scenario should be c= onsidered a vital argument to discuss whether to go with AODVv2 or LOAD-ng<= /b>. One can write a working code of AODVv2 in 2 days. The real question we= should be asking, which protocol is better suited for general MANET overall, and if there really is a *nece= ssity* of discarding a working group document.

Secondly, LOAD-ng was devised keeping LLN scenario in mind. It was int= ended for ROLL WG, and since it had not been adopted in the ROLL WG, it pop= ped up in the MANET WG. The change that has been done to LOAD-ng after drag= ging it to MANET WG, was really to change the message format to adhere to RFC 5444, and do a "find an= d replace" of the term LLN with 'MANET' along with changing the first = 'L' of LOAD ng from 'LLN' to 'Lightweight'. Since the protocol was designed= for LLN at first, I do not think it would be able to cover the broad spectrum that MANET includes. Since we already = have a WG document for a reactive protocol, I do not see any strong reason = to discard the current one in favor of an individual draft, especially when= even LOAD-ng authors agreed that this protocol will not offer any notable performance difference compared t= o AODVv2. 

At the same time, since I have read both drafts, I figured out that AO= DVv2 is more generic to MANET than LOAD-ng. It offers the developer or the = deployment authority to chose form more than one options. For example, AODV= v2 has the option (but it is not mandated) to use a precursor list or have an intermediate node to reply an= RREQ. LOAD-ng does not support either. I can understand that for an LLN it= may be beneficial for not maintaining a precursor list or having only the = destination reply t o a RREQ, there can be (and are) other instances of MANETs where having the option of prec= ursor list will come handy. This can save on control overhead, using some s= torage space in the node. LOAD-ng, in most cases does not provide this flex= ibility to the developer to chose between options for specific deployment. Some MANET deployment may be less= harsh than others in nature. Hence, AODVv2 having more open options than L= OAD-ng, in most cases, seem beneficial to me. Of course, there are other te= chnical differences between these protocols. But I believe there is a separate thread created for that. I wi= ll wait for the draft authors to reply there first, and will reply with my = points if all those differences are not covered. There, I will re-iterate t= he necessity of a protocol to be suited for MANET in general, not only 'some' kind of MANETs.

Lastly, I do not come from any industry, neither I have any company ro= ad-map of deliverable here. Being a PhD candidate in a university= , I tried to fairly judge the two options. So I read both drafts, and did n= ot find a strong enough reason to discard a current working group document. Whether a few companies backing up a pro= tocol over the other can be a decisive criteria to chose a standard protoco= l or not, is in the WG and its chairs most capable hands. Also, I did not, = very clearly understand how LOAD-ng, operating properly in a 2-5 routers test-bed may be considered a= s proof of valid interoperability. I would very much appreciate feedba= ck if I am wrong, since I am in my learning phase :-) . I have my 2 cents h= ere - a) AODVv2 offers more flexibility, b) LOAD-ng does not offer enough advantage over AODVv2 to discard the later, c) LOAD-= ng was not initially designed for MANET, and d) there are other technical d= ifferences that make AODVv2 more suitable for MANETs over LOAD-ng (To be co= vered in separate thread).  My opinion - We should stick to current WG document (AODVv2) and improve it and finis= h it as soon as possible. I hereby stand for Option 1. 

Thanks and Regards,

Joydeep Tripathi
PhD Candidate, 
Drexel University.


On Tue, Oct 30, 2012 at 7:13 PM, Joseph Macker <= span dir=3D"ltr"> <jpmacker@gmail.= com> wrote:
Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.  Sin= ce that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active author= ship and implementation efforts. We provided a co-editing proposal to the a= uthors and gave them the timeframe of the Atlanta to come up with an answer= back to us regarding this.  As of this writing, those discussions of a potential commonn document and aut= horship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.  We s= ee only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have = been some silent collecting initial feedback and waiting for author feedbac= k at this point.  Stan and I are both on travel prior to Atlanta so ou= r responses may be sparse and we will also likely be in a "receive mode" for a few days.  So send your= opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.i= etf.org/mailman/listinfo/manet
--_000_5779F07179A24E038CA30C8EF2A7A978wattecocom_-- From Chris.Dearlove@baesystems.com Fri Nov 2 03:15:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1797721F960C for ; Fri, 2 Nov 2012 03:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.545 X-Spam-Level: X-Spam-Status: No, score=-10.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXCUTQv2T9Wd for ; Fri, 2 Nov 2012 03:15:07 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 3011421F965E for ; Fri, 2 Nov 2012 03:15:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,697,1344207600"; d="scan'208,217";a="283138986" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 02 Nov 2012 10:15:06 +0000 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qA2AF5jH028374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 10:15:06 GMT Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Fri, 2 Nov 2012 10:15:06 +0000 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] Reactive routing protocols, what are the differences? Thread-Index: Ac24S9gO52XASJQwQb67c7wvLBVIbQAC18SAACLc9NA= Date: Fri, 2 Nov 2012 10:15:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6A05GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 10:15:09 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6A05GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You may notice that I asked this question on the list. But there is no eith= er/or. Things are done on the list. Then when we have a meeting things are = done there. And after the meeting things are done on the list. For the form= al process, read the appropriate RFCs. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: 01 November 2012 17:35 To: Dearlove, Christopher (UK) Cc: manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.org) Subject: Re: [manet] Reactive routing protocols, what are the differences? *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Hi Chris, I think that your suggestions and other discussions related to the subject = MUST be done on the MANET list, and not within the f2f meetings. AB On Thu, Nov 1, 2012 at 4:22 PM, Dearlove, Christopher (UK) > wrote: The obviously best people to answer this should be document authors, but an= yone else may have useful additions and comments. Ideally the different doc= ument authors could agree a list. (If they differ in that one has X and the= other doesn't, but one wants to say "we plan to add/remove X" then X shoul= d be listed as a difference with that caveat, in at least my ideal world.) If we set aside, for the moment (though these things matter): - The presentational quality of the documents, - Any issues of 5444 compliance and other formatting issues, - Issues of internal data organisation, - Minor details such as possible different timeout parameters etc. then what are the technical (and I stress that word) differences between DY= MO and LOADng? (I'm withholding the term AODVv2 for reasons I may come back= to.) Note that it's a lot more useful to have direct differences than difference= s of each from AODV (especially when both have the same difference). And it= would be useful to have the objective differences separated from the "and = now why this is better" discussion - though that would be a next step. I'm not saying I don't see any of the differences. But I certainly haven't = worked out the complete list. In trying to form my view of how things shoul= d go forward (a view that is coming together, and when it does, I'll argue = for it) and I hope for other people as well, it would be good to know what = the differences are. Regardless of views for or against each, we should be = able to objectively list the significant differences - if we can't then som= ething is wrong. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** 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. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6A05GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You may notice that I ask= ed this question on the list. But there is no either/or. Things are done on= the list. Then when we have a meeting things are done there. And after the meeting things are done on the list. For the formal process,= read the appropriate RFCs.

 <= /p>

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (O= perations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 <= /p>

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 01 November 2012 17:35
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.org)<= br> Subject: Re: [manet] Reactive routing protocols, what are the differ= ences?

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

Hi Chris,

 

I think that your suggestions and other discuss= ions related to the subject MUST be done on the MANET list, and not wi= thin the f2f meetings.

 

AB

On Thu, Nov 1, 2012 at 4:22 PM, Dearlove, Christophe= r (UK) <Chris.Dearlove@baesystems.com> wrote:

The obviously best people to answer this should be d= ocument authors, but anyone else may have useful additions and comments. Id= eally the different document authors could agree a list. (If they differ in= that one has X and the other doesn't, but one wants to say "we plan to add/remove X" then X should be = listed as a difference with that caveat, in at least my ideal world.)

If we set aside, for the moment (though these things matter):
- The presentational quality of the documents,
- Any issues of 5444 compliance and other formatting issues,
- Issues of internal data organisation,
- Minor details such as possible different timeout parameters etc.
then what are the technical (and I stress that word) differences between DY= MO and LOADng? (I'm withholding the term AODVv2 for reasons I may come back= to.)

Note that it's a lot more useful to have direct differences than difference= s of each from AODV (especially when both have the same difference). And it= would be useful to have the objective differences separated from the "= ;and now why this is better" discussion - though that would be a next step.

I'm not saying I don't see any of the differences. But I certainly haven't = worked out the complete list. In trying to form my view of how things shoul= d go forward (a view that is coming together, and when it does, I'll argue = for it) and I hope for other people as well, it would be good to know what the differences are. Regardless of = views for or against each, we should be able to objectively list the signif= icant differences - if we can't then something is wrong.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 | &= nbsp;Fax: +44 1245 242124
chris.dearlove@baesystems.= com | http://www.baesyste= ms.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687



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

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

 

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6A05GLKXM0002VGREEN_-- From jvasseur@cisco.com Fri Nov 2 03:16:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDC621F9822 for ; Fri, 2 Nov 2012 03:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.493 X-Spam-Level: X-Spam-Status: No, score=-10.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o24iI-baRrpf for ; Fri, 2 Nov 2012 03:16:20 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 60D1521F981A for ; Fri, 2 Nov 2012 03:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29080; q=dns/txt; s=iport; t=1351851380; x=1353060980; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tkeXxXEoo8S5X5kttaMVrBxRRxijim054kNMLfHbM04=; b=mve1ei4CEcsGix6o/iEdCy33GTOcTF+wd3jaI0KIAdMB1dUJoaMGyLtY febSdprDp+ucXIhZlWiBSPKMjYaBFVaOrylcHF1/M63b685+G2d8kygEQ xWjwilvOQvLfMI7ml88eO1nTf5FYT3TFzrbiPc+N25WF8K63zxzi6jvgT U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACCck1CtJV2Z/2dsb2JhbABEwzeBCIIfAQEEAQEBDwEHUgEBCAMQAgEIIhYHByEGCxQRAgQOBQgah1YDDwubX5YlDYlQBIsaZxIOhTphA5QkjQiDJoFrgm+BXB8e X-IronPort-AV: E=Sophos;i="4.80,697,1344211200"; d="scan'208,217";a="138118965" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 02 Nov 2012 10:16:19 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA2AGJtX030777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 10:16:19 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 05:16:18 -0500 From: "JP Vasseur (jvasseur)" To: Jiazi YI Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuOMZLPVi/cSo/ES1hdb7zda62w== Date: Fri, 2 Nov 2012 10:16:18 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204B62C@xmb-rcd-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.149.112] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--40.518200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204B62Cxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 10:16:22 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204B62Cxmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, On Nov 2, 2012, at 10:42 AM, Jiazi YI wrote: Dear Joydeep, Thanks for you comments. Ulrich has already given a detailed reply, so I wo= uld be brief. Please check inline. On Nov 2, 2012, at 1:58 AM, Joydeep Tripathi > wrote: Hi Joe and MANET WG, I was following the discussion on which route to take for a reactive protoc= ol standard very closely, and I think I should post my opinion also. I cham= pion for Option 1, and here is why : I have read both AODVv2 (DYMO) and LOAD-ng drafts, and I have simulated LOA= D-ng myself as well. This experience, I believe, puts me in a position to f= orm an opinion comparing these two protocols. I certainly agree, option 3 i= s *not* an option I would like to be chosen. Reactive protocols, though ver= y much unsuitable for LLNs and Smart Grid AMI meter networks, may have some= usefulness in certain networks for certain sparse traffic scenario, and th= e WG should have a standard for the same. JY>I can't agree here. There have been large deployments of LOADng. But thi= s is not related to this discussion. JP> We would like to hear details on these deployments: traffic matrix/prof= ile, low link layers, =85 Firstly, LOAD-ng is backed up by the argument that it has implementations a= nd interop documents. However, I have seen in the mailing list, that certai= n question on details of the 'practical' implementation of LOAD-ng has been= avoided. A reactive protocol may do well in a 2000 nodes smart meter netwo= rk, if the data traffic to the base station or collector is 1-2 times a day= . This kind of implementations, in my opinion, say nothing about usefulness= of LOAD-ng in Smart Grid networks or LLNs. Again, whether LLN may be consi= dered as a subset of MANET or not is a different question. But even then, d= eployed LOAD-ng in a 2000 node network may (and in my opinion, will) fail i= f traffic is increased. Agreed, one size does not fit all. However, once we= have multicast traffic in a smart grid or multiple meters generating alert= packets in a region at the same time, a reactive protocol like LOAD-ng wil= l lead to the break-down of the network. Anyone can say multicast traffic o= r several meters reporting emergency at the same time to the same station, = is a very much likely situation in smart grid. Were these situations consid= ered during deployment? Please note, I am NOT saying that AODVv2 / DYMO wil= l be better in this case than LOAD-ng. IMHO, any protocol can be shown 'wor= king perfectly', if we provide a favorable atmosphere only for it to work. = Looking at that perspective, I don't think, LOAD-ng working in one network = under one particular scenario should be considered a vital argument to disc= uss whether to go with AODVv2 or LOAD-ng. One can write a working code of A= ODVv2 in 2 days. The real question we should be asking, which protocol is b= etter suited for general MANET overall, and if there really is a *necessity= * of discarding a working group document. Secondly, LOAD-ng was devised keeping LLN scenario in mind. It was intended= for ROLL WG, and since it had not been adopted in the ROLL WG, it popped u= p in the MANET WG. The change that has been done to LOAD-ng after dragging = it to MANET WG, was really to change the message format to adhere to RFC 54= 44, and do a "find and replace" of the term LLN with 'MANET' along with cha= nging the first 'L' of LOAD ng from 'LLN' to 'Lightweight'. Since the proto= col was designed for LLN at first, I do not think it would be able to cover= the broad spectrum that MANET includes. Since we already have a WG documen= t for a reactive protocol, I do not see any strong reason to discard the cu= rrent one in favor of an individual draft, especially when even LOAD-ng aut= hors agreed that this protocol will not offer any notable performance diffe= rence compared to AODVv2. JY>Your first two arguments are self-contradictory. You are saying "LOADng = doesn't fit all", and in the same time, citing "those two will not offer an= y notable performance difference". So my point is: 1. If LOADng can't meet the requirement of MANET, then either do DYMO. I ag= ree that they share the main mechanisms. 2. The reason why LOADng is much more mature than DYMO is that it has much = clearer specification, operation experience, interop test, running code ---= that matters most in IETF. JP> None of the document meet the quality criteria as of now, and both woul= d need more work, as also acknowledged by Charlie who agreed to spend cycles on DYMO/AODVv2. At the same time, since I have read both drafts, I figured out that AODVv2 = is more generic to MANET than LOAD-ng. It offers the developer or the deplo= yment authority to chose form more than one options. For example, AODVv2 ha= s the option (but it is not mandated) to use a precursor list or have an in= termediate node to reply an RREQ. LOAD-ng does not support either. I can un= derstand that for an LLN it may be beneficial for not maintaining a precurs= or list or having only the destination reply t o a RREQ, there can be (and = are) other instances of MANETs where having the option of precursor list wi= ll come handy. This can save on control overhead, using some storage space = in the node. LOAD-ng, in most cases does not provide this flexibility to th= e developer to chose between options for specific deployment. Some MANET de= ployment may be less harsh than others in nature. Hence, AODVv2 having more= open options than LOAD-ng, in most cases, seem beneficial to me. Of course= , there are other technical differences between these protocols. But I beli= eve there is a separate thread created for that. I will wait for the draft = authors to reply there first, and will reply with my points if all those di= fferences are not covered. There, I will re-iterate the necessity of a prot= ocol to be suited for MANET in general, not only 'some' kind of MANETs. JY>Being "more generic" is not necessarily a good thing for standard track = protocol. In fact, DYMO gives a lot of options without specifying them. Thi= s gives a lot of problems in interoperability and security (please check U= lrich's comment to dymo-23. I will post my comments to DYMO-23 later). I ha= ve no doubt that giving how smart you are, you can implement DYMO in severa= l days with your understanding, but I don't believe with dymo-23, one can h= ave independent interoperable implementations. JY>In fact, LOADng offers great flexibility by conforming to rfc5444, and c= an be extended with other options. But this would appear as separate docume= nts with the considerations of interoperability and security. JP> I'd rather think of the opposite. DYMO is IMO a superset that we can ma= ke compatible. Lastly, I do not come from any industry, neither I have any company road-ma= p of deliverable here. Being a PhD candidate in a university, I tried to fa= irly judge the two options. So I read both drafts, and did not find a stron= g enough reason to discard a current working group document. Whether a few = companies backing up a protocol over the other can be a decisive criteria t= o chose a standard protocol or not, is in the WG and its chairs most capabl= e hands. Also, I did not, very clearly understand how LOAD-ng, operating pr= operly in a 2-5 routers test-bed may be considered as proof of valid intero= perability. I would very much appreciate feedback if I am wrong, since I am= in my learning phase :-) . I have my 2 cents here - a) AODVv2 offers more = flexibility, b) LOAD-ng does not offer enough advantage over AODVv2 to disc= ard the later, c) LOAD-ng was not initially designed for MANET, and d) ther= e are other technical differences that make AODVv2 more suitable for MANETs= over LOAD-ng (To be covered in separate thread). My opinion - We should s= tick to current WG document (AODVv2) and improve it and finish it as soon a= s possible. I hereby stand for Option 1. JY> I think I don't need to repeat my preferred option as one of the LOADng= authors. I'm not surprised by your position as researchers around RPL eith= er. JP> Not sure what you mean but two comments: 1) Researchers have considerably helped in protocol designs 2) RPL is certainly not an experimental protocol - as documented with some = details (not enough !) it is running in several large scale networks; within 3-4 weeks two other networks will be added to the document, each wit= h 3-5 thousands nodes. But again, the discussion is not about RPL versus Load or DYMO. But I'm still vey appreciate your detailed comments as your first post to m= anet mailing list (at least with my short memory). I'm glad to see all thos= e discussions are attracting more and more RPLers' attention. Your experien= ce can surely help us improving reactive protocol's application to LLNs (as= a subset of MANET), which makes the LOADng authors can more focus on more = general MANET applications. best Jiazi Thanks and Regards, Joydeep Tripathi PhD Candidate, Drexel University. On Tue, Oct 30, 2012 at 7:13 PM, Joseph Macker > wrote: Hello MANET working group (form Stan and Joe), As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common documen= t effort and given positive feedback at the time we the chairs thought this= was the best approach given the authors potential to come together and gai= n the best of both efforts. Since that period, there has been some fairly = strident and rancorous "at times" debate between the authors of the two doc= uments. During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts = and LOADng had fairly active authorship and implementation efforts. We prov= ided a co-editing proposal to the authors and gave them the timeframe of th= e Atlanta to come up with an answer back to us regarding this. As of this = writing, those discussions of a potential commonn document and authorship m= erger have failed. Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss= ue at the present time. We see only 3 possible paths forward: 1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2. 2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document). 3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus. The co-chairs request and need your opinions on the options. We have been = some silent collecting initial feedback and waiting for author feedback at = this point. Stan and I are both on travel prior to Atlanta so our response= s may be sparse and we will also likely be in a "receive mode" for a few da= ys. So send your opinions. -Joe _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204B62Cxmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8D2D4D4C93F2E247BD06177885A164A5@cisco.com> Content-Transfer-Encoding: quoted-printable Hi,

On Nov 2, 2012, at 10:42 AM, Jiazi YI wrote:

Dear Joydeep, 

Thanks for you comments. Ulrich has already given a detailed reply, so= I would be brief. Please check inline. 

On Nov 2, 2012, at 1:58 AM, Joydeep Tripathi <jt369@drexel.edu> wrote:

Hi Joe and MANET WG,

I was following the discussion on which route to take for a reactive p= rotocol standard very closely, and I think I should post my opinion also. I= champion for Option 1, and here is why : 

I have read both AODVv2 (DYMO) and LOAD-ng drafts, and I have simulate= d LOAD-ng myself as well. This experience, I believe, puts me in a position= to form an opinion comparing these two protocols. I certainly agree, optio= n 3 is *not* an option I would like to be chosen. Reactive protocols, though very much unsuitable for LLNs and= Smart Grid AMI meter networks, may have some usefulness in certain network= s for certain sparse traffic scenario, and the WG should have a standard fo= r the same.

JY>I can't agree here. There have been large deployments of LOADng.= But this is not related to this discussion. 


JP> We would like to hear details on these deployments: traffic mat= rix/profile, low link layers, =85 


Firstly, LOAD-ng is backed up by the argument that it has implementati= ons and interop documents. However, I have seen in the mailing list, that c= ertain question on details of the 'practical' implementation of LOAD-ng has= been avoided. A reactive protocol may do well in a 2000 nodes smart meter network, if the data traffic to th= e base station or collector is 1-2 times a day. This kind of implementation= s, in my opinion, say nothing about usefulness of LOAD-ng in Smart Grid net= works or LLNs. Again, whether LLN may be considered as a subset of MANET or not is a different question. But= even then, deployed LOAD-ng in a 2000 node network may (and in my opinion,= will) fail if traffic is increased. Agreed, one size does not fit all. How= ever, once we have multicast traffic in a smart grid or multiple meters generating alert packets in a region at= the same time, a reactive protocol like LOAD-ng will lead to the break-dow= n of the network. Anyone can say multicast traffic or several meters report= ing emergency at the same time to the same station, is a very much likely situation in smart grid. Were thes= e situations considered during deployment? Please note, I am NOT saying tha= t AODVv2 / DYMO will be better in this case than LOAD-ng. IMHO, any pr= otocol can be shown 'working perfectly', if we provide a favorable atmosphere only for it to work. Looking at that = perspective, I don't think, LOAD-ng working in one network under one particular scenario should be c= onsidered a vital argument to discuss whether to go with AODVv2 or LOAD-ng<= /b>. One can write a working code of AODVv2 in 2 days. The real question we= should be asking, which protocol is better suited for general MANET overall, and if there really is a *nece= ssity* of discarding a working group document.

Secondly, LOAD-ng was devised keeping LLN scenario in mind. It was int= ended for ROLL WG, and since it had not been adopted in the ROLL WG, it pop= ped up in the MANET WG. The change that has been done to LOAD-ng after drag= ging it to MANET WG, was really to change the message format to adhere to RFC 5444, and do a "find an= d replace" of the term LLN with 'MANET' along with changing the first = 'L' of LOAD ng from 'LLN' to 'Lightweight'. Since the protocol was designed= for LLN at first, I do not think it would be able to cover the broad spectrum that MANET includes. Since we already = have a WG document for a reactive protocol, I do not see any strong reason = to discard the current one in favor of an individual draft, especially when= even LOAD-ng authors agreed that this protocol will not offer any notable performance difference compared t= o AODVv2. 

JY>Your first two arguments are self-contradictory. You are saying = "LOADng doesn't fit all", and in the same time, citing "thos= e two will not offer any notable performance difference". So my point = is:
1. If = LOADng can't meet the requirement of MANET, then either do DYMO. I agree th= at they share the main mechanisms.
2. The= reason why LOADng is much more mature than DYMO is that it has much cleare= r specification, operation experience, interop test, running code --- that = matters most in IETF. 

JP> None of the document meet the quality criteria as of now, and b= oth would need more work, as also acknowledged by Charlie who agreed
to spend cycles on DYMO/AODVv2. 



At the same time, since I have read both drafts, I figured out that AO= DVv2 is more generic to MANET than LOAD-ng. It offers the developer or the = deployment authority to chose form more than one options. For example, AODV= v2 has the option (but it is not mandated) to use a precursor list or have an intermediate node to reply an= RREQ. LOAD-ng does not support either. I can understand that for an LLN it= may be beneficial for not maintaining a precursor list or having only the = destination reply t o a RREQ, there can be (and are) other instances of MANETs where having the option of prec= ursor list will come handy. This can save on control overhead, using some s= torage space in the node. LOAD-ng, in most cases does not provide this flex= ibility to the developer to chose between options for specific deployment. Some MANET deployment may be less= harsh than others in nature. Hence, AODVv2 having more open options than L= OAD-ng, in most cases, seem beneficial to me. Of course, there are other te= chnical differences between these protocols. But I believe there is a separate thread created for that. I wi= ll wait for the draft authors to reply there first, and will reply with my = points if all those differences are not covered. There, I will re-iterate t= he necessity of a protocol to be suited for MANET in general, not only 'some' kind of MANETs.

JY>Being "more generic" is not necessarily a good thing f= or standard track protocol. In fact, DYMO gives a lot of options without sp= ecifying them. This gives a lot of problems in interoperability and securit= y  (please check Ulrich's comment to dymo-23. I will post my comments to DYMO-23 later). I have no doubt that giving how= smart you are, you can implement DYMO in several days with your understand= ing, but I don't believe with dymo-23, one can have independent interoperab= le implementations. 

JY>In fact, LOADng offers great flexibility by conforming to rfc544= 4, and can be extended with other options. But this would appear as separat= e documents with the considerations of interoperability and security. =

JP> I'd rather think of the opposite. DYMO is IMO a superset that w= e can make compatible.




Lastly, I do not come from any industry, neither I have any company ro= ad-map of deliverable here. Being a PhD candidate in a university= , I tried to fairly judge the two options. So I read both drafts, and did n= ot find a strong enough reason to discard a current working group document. Whether a few companies backing up a pro= tocol over the other can be a decisive criteria to chose a standard protoco= l or not, is in the WG and its chairs most capable hands. Also, I did not, = very clearly understand how LOAD-ng, operating properly in a 2-5 routers test-bed may be considered a= s proof of valid interoperability. I would very much appreciate feedba= ck if I am wrong, since I am in my learning phase :-) . I have my 2 cents h= ere - a) AODVv2 offers more flexibility, b) LOAD-ng does not offer enough advantage over AODVv2 to discard the later, c) LOAD-= ng was not initially designed for MANET, and d) there are other technical d= ifferences that make AODVv2 more suitable for MANETs over LOAD-ng (To be co= vered in separate thread).  My opinion - We should stick to current WG document (AODVv2) and improve it and finis= h it as soon as possible. I hereby stand for Option 1. 


JY> I think I don't need to repeat my preferred option as one of th= e LOADng authors. I'm not surprised by your position as researchers around = RPL either. 

JP> Not sure what you mean but two comments:
1) Researchers have considerably helped in protocol designs
2) RPL is certainly not an experimental protocol - as documented with = some details (not enough !) it is running in several large scale networks;<= /div>
within 3-4 weeks two other networks will be added to the document, eac= h with 3-5 thousands nodes.

But again, the discussion is not about RPL versus Load or DYMO.

But I'm still vey appreciate your detailed comments as your first post= to manet mailing list (at least with my short memory). I'm glad to see all= those discussions are attracting more and more RPLers' attention. Your exp= erience can surely help us improving reactive protocol's application to LLNs (as a subset of MANET), which make= s the LOADng authors can more focus on more general MANET applications.&nbs= p;

best

Jiazi



Thanks and Regards,

Joydeep Tripathi
PhD Candidate, 
Drexel University.


On Tue, Oct 30, 2012 at 7:13 PM, Joseph Macker <= span dir=3D"ltr"> <jpmacker@gmail.= com> wrote:
Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.  Sin= ce that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active author= ship and implementation efforts. We provided a co-editing proposal to the a= uthors and gave them the timeframe of the Atlanta to come up with an answer= back to us regarding this.  As of this writing, those discussions of a potential commonn document and aut= horship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.  We s= ee only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have = been some silent collecting initial feedback and waiting for author feedbac= k at this point.  Stan and I are both on travel prior to Atlanta so ou= r responses may be sparse and we will also likely be in a "receive mode" for a few days.  So send your= opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A772204B62Cxmbrcdx02ciscoc_-- From Chris.Dearlove@baesystems.com Fri Nov 2 03:22:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BBE21F99EA for ; Fri, 2 Nov 2012 03:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+eo8SpEaFgR for ; Fri, 2 Nov 2012 03:22:41 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id BE79921F99DE for ; Fri, 2 Nov 2012 03:22:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,699,1344207600"; d="scan'208";a="240463498" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 02 Nov 2012 10:22:39 +0000 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qA2AMdM0009310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 10:22:39 GMT Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Fri, 2 Nov 2012 10:22:39 +0000 From: "Dearlove, Christopher (UK)" To: Ulrich Herberg Thread-Topic: [manet] Reactive routing protocols, what are the differences? Thread-Index: Ac24S9gO52XASJQwQb67c7wvLBVIbQAMK9OAABnHRpA= Date: Fri, 2 Nov 2012 10:22:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 10:22:43 -0000 There is, superficially at least, an apparent contradiction between your po= ints: - DYMO cannot be end-to-end secured. Messages are changed in transit (and not just hop-limit or the metric), but rather addresses can be removed from RERRs and RREQs. which implicitly suggests LOADng does not do this and=20 - LOADng uses a Metric message TLV, and it is clearly defined how to update the metric under way. Could you expand on this please? --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Ulrich Herberg [mailto:ulrich@herberg.name]=20 Sent: 01 November 2012 22:02 To: Dearlove, Christopher (UK) Cc: manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.org) Subject: Re: [manet] Reactive routing protocols, what are the differences? ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi Chris, you have seen my review on DYMO. I will try to answer to your question, and focus on the technical differences, not presentation. On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK) wrote: > The obviously best people to answer this should be document authors, but = anyone else may have useful additions and comments. Ideally the different d= ocument authors could agree a list. (If they differ in that one has X and t= he other doesn't, but one wants to say "we plan to add/remove X" then X sho= uld be listed as a difference with that caveat, in at least my ideal world.= ) > > If we set aside, for the moment (though these things matter): > - The presentational quality of the documents, > - Any issues of 5444 compliance and other formatting issues, > - Issues of internal data organisation, > - Minor details such as possible different timeout parameters etc. > then what are the technical (and I stress that word) differences between = DYMO and LOADng? (I'm withholding the term AODVv2 for reasons I may come ba= ck to.) First, let's see what is common. Both are reactive protocols, using RREQ, RREP and RERR. So if someone claims that DYMO performs great and LOADng badly in the same scenario, I cannot understand that. MANET has understood the scenarios where reactive protocols are useful and where not. Now, to the differences: - DYMO cannot be end-to-end secured. Messages are changed in transit (and not just hop-limit or the metric), but rather addresses can be removed from RERRs and RREQs. There is also no provision to allow external mechanisms to add additional reasons to reject messages as invalid. - DYMO uses the originator address in an address block, LOADng in the message header. The sequence number is a TLV value in DYMO, and LOADng uses the message sequence number. DYMO requires the originator address to be the first one in the address block, the destination must be the second one. LOADng uses a TLV to determine the target address. - DYMO can advertise multiple addresses in an RERR; they can be removed in transit of the message. - DYMO allows intermediate routers to reply (as an option). That makes end-to-end security difficult. In the core DYMO, there is a destination sequence number that may be contained in RREQs in DYMO. - DYMO allows for unicast RREQ, but does not specify in detail how to use t= hat. - There are four timers for each route entry in DYMO, only one in LOADng. - LOADng can be used on other layers; DYMO is tied to IP. - LOADng provides a bidirectionality verification using RREP_ACK, a time-out of these, a blacklisted set and a Pending Acknowledgment Set to verify bidirectional links. DYMO says that other mechanisms can be used, but does not specify these. - DYMO has several options for expanding ring RREQ, precursor list, adding route information in transit, message aggregation in RFC5444 packets and reporting multiple unreachable addresses in a RERR. LOADng takes the approach to have a slim core of a basic mechanism that is applicable in all MANET use cases, and companion documents with extensions. In DYMO, it is not clearly specified what happens if some routers support an option, and others don't. - LOADng uses a Metric message TLV, and it is clearly defined how to update the metric under way. If a router in transit does not recognize a route metric type, it is reset to a "hop count" tlv extension type of the Metric TLV and the value set to 0xFFFFF... (for the full TLV length). It is specified that security mechanism must ignore the content of the metric TLV value and that the length cannot be changed under way, so that end-to-end security is possible. DYMO uses an optional "distance" field for the metric, which is not clearly specified how it is updated. Also, since this is optional, it is unclear if routers receiving a message and forwarding it, update the distance field or not. - LOADng allows for (optionally) waiting to reply with a RREP, in case a "better" RREQ comes a little later. In DYMO, a RREP is always sent immediately. There are probably more differences, but I let other chime in. Best regards Ulrich > Note that it's a lot more useful to have direct differences than differen= ces of each from AODV (especially when both have the same difference). And = it would be useful to have the objective differences separated from the "an= d now why this is better" discussion - though that would be a next step. > > I'm not saying I don't see any of the differences. But I certainly haven'= t worked out the complete list. In trying to form my view of how things sho= uld go forward (a view that is coming together, and when it does, I'll argu= e for it) and I hope for other people as well, it would be good to know wha= t the differences are. Regardless of views for or against each, we should b= e able to objectively list the significant differences - if we can't then s= omething is wrong. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > ******************************************************************** > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Fri Nov 2 03:53:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F6221F874F for ; Fri, 2 Nov 2012 03:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuTLr2LVBSz8 for ; Fri, 2 Nov 2012 03:53:27 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 6058B21F8751 for ; Fri, 2 Nov 2012 03:53:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,699,1344207600"; d="scan'208,217";a="283153491" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 02 Nov 2012 10:53:25 +0000 Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qA2ArAl9004413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 10:53:25 GMT Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Fri, 2 Nov 2012 10:53:11 +0000 From: "Dearlove, Christopher (UK)" To: "JP Vasseur (jvasseur)" , Jon Black Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNtvQ8KZyE8G8hv0Kl9ZhEgIu1eJfTFaOAgAAYXXCAAd58AIAAFSgAgAAwCgCAAJfqgIAAS30AgAAsGIA= Date: Fri, 2 Nov 2012 10:53:10 +0000 Message-ID: References: <03B78081B371D44390ED6E7BADBB4A77220419BB@xmb-rcd-x02.cisco.com> <1351784668.10346.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049577@xmb-rcd-x02.cisco.com> <1351827607.38598.YahooMailNeo@web160605.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AA30@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204AA30@xmb-rcd-x02.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6A74GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: manet Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 10:53:34 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6A74GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have missed the technical arguments relating to the differences between D= YMO and LOADng that lead you to favour DYMO. In fact I've missed this from = almost every contributor. The technical differences that have been raised so far relate to message mu= tability, handling asymmetric links, whether features such as IRREPs should= be included, and so on. (I'm excluding nits of 5444 formatting, those are = secondary.) Apart from the first (where LOADng supporters have made a secur= ity point) I don't see much discussing these. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of J= P Vasseur (jvasseur) Sent: 02 November 2012 08:10 To: Jon Black Cc: manet Subject: Re: [manet] Reactive Protocol Situation *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. You keep ignoring what I wrote ... I think that I explained why reactive ro= uting was a major issue for LLN at least twice and I will provide numbers too. I also explained why I would strongly favor Option 1 (which wa= s THE question asked by the chair). On Nov 1, 2012, at 11:40 PM, Jon Black wrote: But opinions without some technical details turns into a beauty contest and= I don't think that is what the chairs were after. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: Abdussalam Baryun >; manet > Sent: Thursday, November 1, 2012 12:36 PM Subject: Re: [manet] Reactive Protocol Situation On Nov 1, 2012, at 4:44 PM, Jon Black wrote: I disagree. The protocol has progressed. It appears that there are implem= entations. There is interoperability. There are deployments. This is all= progress. I'm not favoring LOADng over DYMO. I think the working group should look a= t both fairly and decide the best path forward - chose one over the other o= r find a way to merge the concepts even if the authors are hesitant. Right and I think that this was what the chairs asked us to do: express our= opinion on which option we prefer. Let's wait until everybody express an opinion and see what the chairs think= . Thanks. JP. Jon ________________________________ From: Abdussalam Baryun > To: manet > Sent: Thursday, November 1, 2012 8:28 AM Subject: Re: [manet] Reactive Protocol Situation On Wed, Oct 31, 2012 at 10:02 AM, Dearlove, Christopher (UK) > wrote: As someone who has not (yet) stated an opinion on the matter, except I also= think option 3 is not good, I would very much like to hear technical argum= ents, so if you have technical arguments against LOADng, I think we need to= hear them rather than just suggesting they exist. I haven't yet read LOADn= g carefully to form a view there. I have just recently read the AODVv2 draf= t carefully, and have some technical issues there (which overlap) regarding= asymmetric links, possible dependency on NHDP, and the compatibility of op= tions. If option 1 is followed, the draft needs work (which Charlie has ack= nowledged). I don't think we have time to waste with LOADng, it was presented twice and= no progress, the authors failed to discuss on MANET list, and failed to up= date the draft to match MANET reuirements. I agree that we focus our effort= s to submit AODVv2 as soon as possible, AB -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of JP Vasseur (jv= asseur) Sent: 31 October 2012 08:29 To: Joseph Macker Cc: > Subject: Re: [manet] Reactive Protocol Situation *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Dear chairs, Remembering that I am not a co-authors of either of these drafts. Not commenting on recent discussions but rather focussing on what I hope wi= ll be a good solution for the WG and the Internet at large. Option 3) is my opinion not desirable; I wish we could have a reactive rout= ing protocol for MANET Option 2) is an option I would be strongly opposed to for a number of techn= ical reasons that I would be happy to elaborate on the mailing list and/or in a new I-D (which I would, should option 2 be chosen)= . That being said, I am extremely supportive of option 1), especially in ligh= t of what Charlie said. First of all DYMO is the working group document and excellent progress has been made with recent revisions. But ev= en more importantly, Charlie managed to make it compatible with options, which is in my opinion the best of both worlds; calling it AO= DVv2 is only not very sensible but avoids useful sensitivity around names. Thus I would strongly support Option 1), continue the work that Charlie has= started, which by the way is not far from completion. And as WG,we need to remember that this had been the WG document, the result of= years of work. Still by making it compatible with other options, this is technically flexible and sound. Thanks. JP. On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote: Hello MANET working group (form Stan and Joe), As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common documen= t effort and given positive feedback at the time we the chairs thought this= was the best approach given the authors potential to come together and gai= n the best of both efforts. Since that period, there has been some fairly = strident and rancorous "at times" debate between the authors of the two doc= uments. During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts = and LOADng had fairly active authorship and implementation efforts. We prov= ided a co-editing proposal to the authors and gave them the timeframe of th= e Atlanta to come up with an answer back to us regarding this. As of this = writing, those discussions of a potential commonn document and authorship m= erger have failed. Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss= ue at the present time. We see only 3 possible paths forward: 1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2. 2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document). 3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus. The co-chairs request and need your opinions on the options. We have been = some silent collecting initial feedback and waiting for author feedback at = this point. Stan and I are both on travel prior to Atlanta so our response= s may be sparse and we will also likely be in a "receive mode" for a few da= ys. So send your opinions. -Joe _______________________________________________ manet mailing list manet@ietf.org 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. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6A74GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have missed the technic= al arguments relating to the differences between DYMO and LOADng that lead = you to favour DYMO. In fact I've missed this from almost every contributor.

 <= /p>

The technical differences= that have been raised so far relate to message mutability, handling asymme= tric links, whether features such as IRREPs should be included, and so on. (I'm excluding nits of 5444 formatting, those are secondary.) A= part from the first (where LOADng supporters have made a security point) I = don't see much discussing these.

 <= /p>

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (O= perations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 <= /p>

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org= ] On Behalf Of JP Vasseur (jvasseur)
Sent: 02 November 2012 08:10
To: Jon Black
Cc: manet
Subject: Re: [manet] Reactive Protocol Situation

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

You keep ignoring what I wrote … I think that = I explained why reactive routing was a major issue for LLN at least twice a= nd I will provide

numbers too. I also explained why I would strongly f= avor Option 1 (which was THE question asked by the chair).

 

On Nov 1, 2012, at 11:40 PM, Jon Black wrote:



But opinions without some technical details turns into a beauty contest = and I don't think that is what the chairs were after.

Jon

 

 

From: JP Vasseur (jvasseur) <jvasseur@cisco.com>
To: Jon Black <jblack.ie= tf@yahoo.com>
Cc: Abdussalam Baryun <abdussalambaryun@gmail.com>; manet <manet@ietf.org>
Sent: Thursday, November 1, 2012 12:36 PM
Subject: Re: [manet] Reactive Protocol Situation



 

On Nov 1, 2012, at 4:44 PM, Jon Black wrote:



I disagree.  The protocol has progressed.  It appears that the= re are implementations.  There is interoperability.  There are de= ployments.  This is all progress.

I'm not favoring LOADng over DYMO.  I think the working group should l= ook at both fairly and decide the best path forward - chose one over the ot= her or find a way to merge the concepts even if the authors are hesitant.

 

Right and I think that this was what the chairs asked us to do: express = our opinion on which option we prefer.

Let's wait until everybody express an opinion and see what the chairs th= ink.

 

Thanks.

 

JP.

 




Jon

 

 

From: Abdussalam Baryun <abdussalambaryun@gmail.= com>
To: manet <ma= net@ietf.org>
Sent: Thursday, November 1, 2012 8:28 AM
Subject: Re: [manet] Reactive Protocol Situation

 

On Wed, Oct 31, 2012 at 10:02 AM, Dearlove, Christopher (UK) <Chris.Dearlove@= baesystems.com> wrote:

As someone who has not (yet) stated an opinion on the= matter, except I also think option 3 is not good, I would very much like t= o hear technical arguments, so if you have technical arguments against LOADng, I think we need to hear them rath= er than just suggesting they exist. I haven't yet read LOADng carefully to = form a view there. I have just recently read the AODVv2 draft carefully, an= d have some technical issues there (which overlap) regarding asymmetric links, possible dependency on NHDP, a= nd the compatibility of options. If option 1 is followed, the draft needs w= ork (which Charlie has acknowledged).

 <= /span>

 

I don't think we have time to waste with LOADng, it was presented twice = and no progress, the authors failed to discuss on MANET list, and failed to= update the draft to match MANET reuirements. I agree that we focus our efforts to submit AODVv2 as soon as possible,

 

AB

 

 

 

--

Christopher Dearlove

Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dear= love@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 <= /span>

From: manet-bounces@i= etf.org [mailto:manet-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur)
Sent: 31 October 2012 08:29
To: Joseph Macker
Cc: <manet@ie= tf.org>
Subject: Re: [manet] Reactive Protocol Situation

 

 

*** WARNING ***=

This message or= iginates from outside our organisation, either from an external partner or = the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

Dear chairs,

 

Remembering that I am not a co-authors of either of these drafts.

 

Not commenting on recent discussions but rather focussing on what I h= ope will be a good solution for the WG and the Internet at large.

 

Option 3) is my opinion not desirable; I wish we could have a reactive routing protoc= ol for MANET

 

Option 2) is an option I would be strongly opposed to for a number of technical reasons that I = would be happy to elaborate on the

mailing list and/or in a new I-D (which I would, should option 2 be chos= en).

 

That being said, I am extremely supportive of option 1), especially in light of wh= at Charlie said. First of all DYMO is the working group

document and excellent progress has been made with recent revisions. But= even more importantly, Charlie managed to make it compatible 

with options, which is in my opinion the best of both worlds; calling it AODVv2 is only not very sensible= but avoids useful sensitivity around 

names.

 

Thus I would strongly support Option 1), continue the work that Charl= ie has started, which by the way is = not far from completion. And 

as WG,we need to remember that this had been the WG document, the result= of years of work. Still by making it compatible with other options, <= o:p>

this is technically flexible and sound.

 

Thanks.

 

JP.

 

On Oct 31, 2012, at 12:13 AM, Joseph Macker wrote:

 

Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.  Sin= ce that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active author= ship and implementation efforts. We provided a co-editing proposal to the a= uthors and gave them the timeframe of the Atlanta to come up with an answer= back to us regarding this.  As of this writing, those discussions of a potential commonn document and aut= horship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.  We s= ee only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We have = been some silent collecting initial feedback and waiting for author feedbac= k at this point.  Stan and I are both on travel prior to Atlanta so ou= r responses may be sparse and we will also likely be in a "receive mode" for a few days.  So send your= opinions.

-Joe
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://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.
********************************************************************


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

 


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

 

 

 

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6A74GLKXM0002VGREEN_-- From yi.jiazi@gmail.com Fri Nov 2 03:53:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2C321F8816 for ; Fri, 2 Nov 2012 03:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZihzmLI4+bnV for ; Fri, 2 Nov 2012 03:53:47 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BDBDF21F8756 for ; Fri, 2 Nov 2012 03:53:46 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1634796wgb.13 for ; Fri, 02 Nov 2012 03:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=fKZl2U1bQDLxgsbtoWqikRgJnX7cQ2yCq6a0JPS/p3U=; b=VlYhOBKv1z47AyDaQ/tH1Qo5x8meQTQNHUTNwc6AXAYd8x3FgwvJfgjUoEqlvFJ1lv BlImZmNUcFjsgka0dYn8SoaF9khCKyS+8RTD7Ho7evNV6RTM9d4VB46G6apV4gSsXpvI EWzmnWUJGNUy7EUZuYGniynEskR6yiOTC71v34P/bNZ2DF8t0B1+wkJZEteXPO7anCle CJc8PZDCkd2NXpH2dak8kghrDbZLPlbs8ZbnledXllD4stK1FIu28uVBX5gZced9OOzj v2cSSaFAZWJl+BxqozYdLjvtLLT7ss8H/ltZZeDJqZbkyJshcdaRszi6lPYTCYidMeLT VaAA== Received: by 10.180.92.132 with SMTP id cm4mr2113243wib.12.1351853625774; Fri, 02 Nov 2012 03:53:45 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id f1sm1766792wiy.2.2012.11.02.03.53.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 03:53:44 -0700 (PDT) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_07AED862-93C0-4BEF-8DF6-3904030A9B1A" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi YI In-Reply-To: Date: Fri, 2 Nov 2012 11:53:35 +0100 Message-Id: <12708D7E-C548-4858-8144-6F04D2750E02@jiaziyi.com> References: To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 10:53:49 -0000 --Apple-Mail=_07AED862-93C0-4BEF-8DF6-3904030A9B1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Chris,=20 I think Ulrich is in deep sleep at the moment, so please allow me to = have some words on this.=20 For reactive protocols, updating the route information (hop-count, = metric) is inevitable. In the specification of DYMO, the messages can be = changed relatively arbitrarily, including removing addresses from the = messages. The intermediate RREP also makes end-to-end security = impossible.=20 LOADng clearly defines which fields in the routing messages can't be = changed, and which fields are mutable. For example, for RREQ: > The following fields of an RREQ message are immutable, i.e., they MUST = NOT be changed during processing or forwarding of the message: = RREQ.addr-length, RREQ.seq-num, RREQ.originator, and RREQ.destination. >=20 > The following fields of an RREQ message are mutable, i.e., they will = be changed by intermediate routers during processing or forwarding, as = specified in Section 12.2 and Section 12.3: RREQ.metric-type, = RREQ.route-metric, and RREQ.hop-count. >=20 > Any additional field that is added to the message by an extension to = this protocol, e.g., by way of TLVs, MUST be considered immutable, = unless the extension specifically defines the field as mutable. >=20 This allows the protocol to secure the messages by zeroing the mutable = fields.=20 best Jiazi=20 (sorry to Chris if you received multiple copy of this message. I fixed = one typo though :) My previous one was bounced by manet mailing list = because of not using the right sender address) On Nov 2, 2012, at 11:22 AM, "Dearlove, Christopher (UK)" = wrote: > There is, superficially at least, an apparent contradiction between = your points: >=20 > - DYMO cannot be end-to-end secured. Messages are changed in transit > (and not just hop-limit or the metric), but rather addresses can be > removed from RERRs and RREQs. >=20 > which implicitly suggests LOADng does not do this >=20 > and=20 >=20 > - LOADng uses a Metric message TLV, and it is clearly defined how to > update the metric under way. >=20 > Could you expand on this please? >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Ulrich Herberg [mailto:ulrich@herberg.name]=20 > Sent: 01 November 2012 22:02 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.org) > Subject: Re: [manet] Reactive routing protocols, what are the = differences? >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Hi Chris, >=20 > you have seen my review on DYMO. I will try to answer to your > question, and focus on the technical differences, not presentation. >=20 >=20 > On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK) > wrote: >> The obviously best people to answer this should be document authors, = but anyone else may have useful additions and comments. Ideally the = different document authors could agree a list. (If they differ in that = one has X and the other doesn't, but one wants to say "we plan to = add/remove X" then X should be listed as a difference with that caveat, = in at least my ideal world.) >>=20 >> If we set aside, for the moment (though these things matter): >> - The presentational quality of the documents, >> - Any issues of 5444 compliance and other formatting issues, >> - Issues of internal data organisation, >> - Minor details such as possible different timeout parameters etc. >> then what are the technical (and I stress that word) differences = between DYMO and LOADng? (I'm withholding the term AODVv2 for reasons I = may come back to.) >=20 >=20 > First, let's see what is common. Both are reactive protocols, using > RREQ, RREP and RERR. So if someone claims that DYMO performs great and > LOADng badly in the same scenario, I cannot understand that. MANET has > understood the scenarios where reactive protocols are useful and where > not. >=20 > Now, to the differences: >=20 > - DYMO cannot be end-to-end secured. Messages are changed in transit > (and not just hop-limit or the metric), but rather addresses can be > removed from RERRs and RREQs. There is also no provision to allow > external mechanisms to add additional reasons to reject messages as > invalid. > - DYMO uses the originator address in an address block, LOADng in the > message header. The sequence number is a TLV value in DYMO, and LOADng > uses the message sequence number. DYMO requires the originator address > to be the first one in the address block, the destination must be the > second one. LOADng uses a TLV to determine the target address. > - DYMO can advertise multiple addresses in an RERR; they can be > removed in transit of the message. > - DYMO allows intermediate routers to reply (as an option). That makes > end-to-end security difficult. In the core DYMO, there is a > destination sequence number that may be contained in RREQs in DYMO. > - DYMO allows for unicast RREQ, but does not specify in detail how to = use that. > - There are four timers for each route entry in DYMO, only one in = LOADng. > - LOADng can be used on other layers; DYMO is tied to IP. > - LOADng provides a bidirectionality verification using RREP_ACK, a > time-out of these, a blacklisted set and a Pending Acknowledgment Set > to verify bidirectional links. DYMO says that other mechanisms can be > used, but does not specify these. > - DYMO has several options for expanding ring RREQ, precursor list, > adding route information in transit, message aggregation in RFC5444 > packets and reporting multiple unreachable addresses in a RERR. LOADng > takes the approach to have a slim core of a basic mechanism that is > applicable in all MANET use cases, and companion documents with > extensions. In DYMO, it is not clearly specified what happens if some > routers support an option, and others don't. > - LOADng uses a Metric message TLV, and it is clearly defined how to > update the metric under way. If a router in transit does not recognize > a route metric type, it is reset to a "hop count" tlv extension type > of the Metric TLV and the value set to 0xFFFFF... (for the full TLV > length). It is specified that security mechanism must ignore the > content of the metric TLV value and that the length cannot be changed > under way, so that end-to-end security is possible. DYMO uses an > optional "distance" field for the metric, which is not clearly > specified how it is updated. Also, since this is optional, it is > unclear if routers receiving a message and forwarding it, update the > distance field or not. > - LOADng allows for (optionally) waiting to reply with a RREP, in case > a "better" RREQ comes a little later. In DYMO, a RREP is always sent > immediately. >=20 > There are probably more differences, but I let other chime in. >=20 > Best regards > Ulrich >=20 >=20 >> Note that it's a lot more useful to have direct differences than = differences of each from AODV (especially when both have the same = difference). And it would be useful to have the objective differences = separated from the "and now why this is better" discussion - though that = would be a next step. >>=20 >> I'm not saying I don't see any of the differences. But I certainly = haven't worked out the complete list. In trying to form my view of how = things should go forward (a view that is coming together, and when it = does, I'll argue for it) and I hope for other people as well, it would = be good to know what the differences are. Regardless of views for or = against each, we should be able to objectively list the significant = differences - if we can't then something is wrong. >>=20 >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >>=20 >> ******************************************************************** >> 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. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_07AED862-93C0-4BEF-8DF6-3904030A9B1A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hi Chris, 

I think Ulrich is in deep sleep at the moment, so = please allow me to have some words on this. 

For reactive protocols, updating the route = information (hop-count, metric) is inevitable. In the specification of = DYMO, the messages can be changed relatively arbitrarily, including = removing addresses from the messages. The intermediate RREP also makes = end-to-end security impossible. 

LOADng clearly defines which fields in the = routing messages can't be changed, and which fields are mutable. For = example, for RREQ:

The following fields of an RREQ = message are immutable, i.e., they MUST NOT be changed during processing = or forwarding of the message: RREQ.addr-length, RREQ.seq-num, = RREQ.originator, and RREQ.destination.

The following fields of an RREQ message = are mutable, i.e., they will be changed by intermediate routers during = processing or forwarding, as specified in Section 12.2 and Section 12.3: RREQ.metric-type, RREQ.route-metric, = and RREQ.hop-count.

Any additional field that is added to the message by an = extension to this protocol, e.g., by way of TLVs, MUST be considered = immutable, unless the extension specifically defines the field as = mutable.


This allows the protocol to secure the messages = by zeroing the mutable fields. 

best

Jiazi 

(sorry to Chris if you received multiple copy of = this message. I fixed one typo though :) My previous one was bounced by = manet mailing list because of not using the right sender = address)


On Nov 2, 2012, at 11:22 AM, "Dearlove, Christopher (UK)" = <Chris.Dearlove@baesystems.co= m> wrote:

There is, superficially at least, an apparent = contradiction between your points:

- DYMO cannot be end-to-end = secured. Messages are changed in transit
(and not just hop-limit or = the metric), but rather addresses can be
removed from RERRs and = RREQs.

which implicitly suggests LOADng does not do = this

and

- LOADng uses a Metric message TLV, and it is = clearly defined how to
update the metric under way.

Could you = expand on this please?

--
Christopher Dearlove
Senior = Principal Engineer, Communications Group
Communications, Networks and = Image Analysis Capability
BAE Systems Advanced Technology = Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, = UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.co= m | http://www.baesystems.com

BA= E Systems (Operations) Limited
Registered Office: Warwick House, PO = Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, = UK
Registered in England & Wales No: = 1996687


-----Original Message-----
From: Ulrich Herberg = [mailto:ulrich@herberg.name]
Sent: 01 November 2012 22:02
To: = Dearlove, Christopher (UK)
Cc: manet@ietf.org; Thomas Heide Clausen = (thomas@thomasclausen.org)
= Subject: Re: [manet] Reactive routing protocols, what are the = differences?

----------------------! WARNING ! = ----------------------
This message originates from outside our = organisation,
either from an external partner or from the = internet.
Keep this in mind if you answer this message.
Follow the = 'Report Suspicious Emails' link on IT matters
for instructions on = reporting suspicious email = messages.
--------------------------------------------------------
<= br>Hi Chris,

you have seen my review on DYMO. I will try to = answer to your
question, and focus on the technical differences, not = presentation.


On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, = Christopher (UK)
<Chris.Dearlove@baesystems.co= m> wrote:
The obviously best people = to answer this should be document authors, but anyone else may have = useful additions and comments. Ideally the different document authors = could agree a list. (If they differ in that one has X and the other = doesn't, but one wants to say "we plan to add/remove X" then X should be = listed as a difference with that caveat, in at least my ideal = world.)

If we set aside, for the moment (though these things = matter):
- The presentational quality of the documents,
- Any = issues of 5444 compliance and other formatting issues,
- Issues of = internal data organisation,
- Minor details such as possible = different timeout parameters etc.
then what are the technical (and I = stress that word) differences between DYMO and LOADng? (I'm withholding = the term AODVv2 for reasons I may come back = to.)


First, let's see what is common. Both are = reactive protocols, using
RREQ, RREP and RERR. So if someone claims = that DYMO performs great and
LOADng badly in the same scenario, I = cannot understand that. MANET has
understood the scenarios where = reactive protocols are useful and where
not.

Now, to the = differences:

- DYMO cannot be end-to-end secured. Messages are = changed in transit
(and not just hop-limit or the metric), but rather = addresses can be
removed from RERRs and RREQs. There is also no = provision to allow
external mechanisms to add additional reasons to = reject messages as
invalid.
- DYMO uses the originator address in = an address block, LOADng in the
message header. The sequence number = is a TLV value in DYMO, and LOADng
uses the message sequence number. = DYMO requires the originator address
to be the first one in the = address block, the destination must be the
second one. LOADng uses a = TLV to determine the target address.
- DYMO can advertise multiple = addresses in an RERR; they can be
removed in transit of the = message.
- DYMO allows intermediate routers to reply (as an option). = That makes
end-to-end security difficult. In the core DYMO, there is = a
destination sequence number that may be contained in RREQs in = DYMO.
- DYMO allows for unicast RREQ, but does not specify in detail = how to use that.
- There are four timers for each route entry in = DYMO, only one in LOADng.
- LOADng can be used on other layers; DYMO = is tied to IP.
- LOADng provides a bidirectionality verification = using RREP_ACK, a
time-out of these, a blacklisted set and a Pending = Acknowledgment Set
to verify bidirectional links. DYMO says that = other mechanisms can be
used, but does not specify these.
- DYMO = has several options for expanding ring RREQ, precursor list,
adding = route information in transit, message aggregation in RFC5444
packets = and reporting multiple unreachable addresses in a RERR. LOADng
takes = the approach to have a slim core of a basic mechanism that = is
applicable in all MANET use cases, and companion documents = with
extensions. In DYMO, it is not clearly specified what happens if = some
routers support an option, and others don't.
- LOADng uses a = Metric message TLV, and it is clearly defined how to
update the = metric under way. If a router in transit does not recognize
a route = metric type, it is reset to a "hop count" tlv extension type
of the = Metric TLV and the value set to 0xFFFFF... (for the full TLV
length). = It is specified that security mechanism must ignore the
content of = the metric TLV value and that the length cannot be changed
under way, = so that end-to-end security is possible. DYMO uses an
optional = "distance" field for the metric, which is not clearly
specified how = it is updated. Also, since this is optional, it is
unclear if routers = receiving a message and forwarding it, update the
distance field or = not.
- LOADng allows for (optionally) waiting to reply with a RREP, = in case
a "better" RREQ comes a little later. In DYMO, a RREP is = always sent
immediately.

There are probably more differences, = but I let other chime in.

Best = regards
Ulrich


Note that it's a = lot more useful to have direct differences than differences of each from = AODV (especially when both have the same difference). And it would be = useful to have the objective differences separated from the "and now why = this is better" discussion - though that would be a next = step.

I'm not saying I don't see any of the differences. But I = certainly haven't worked out the complete list. In trying to form my = view of how things should go forward (a view that is coming together, = and when it does, I'll argue for it) and I hope for other people as = well, it would be good to know what the differences are. Regardless of = views for or against each, we should be able to objectively list the = significant differences - if we can't then something is = wrong.

--
Christopher Dearlove
Senior Principal Engineer, = Communications Group
Communications, Networks and Image Analysis = Capability
BAE Systems Advanced Technology Centre
West = Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 = 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.co= m | http://www.baesystems.com

BA= E Systems (Operations) Limited
Registered Office: Warwick House, PO = Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, = UK
Registered in England & Wales No: = 1996687



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

_______________________________________________
manet = mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

_______________________________= ________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= --Apple-Mail=_07AED862-93C0-4BEF-8DF6-3904030A9B1A-- From Chris.Dearlove@baesystems.com Fri Nov 2 04:16:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2046E21F9755 for ; Fri, 2 Nov 2012 04:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVndlXO-KpMH for ; Fri, 2 Nov 2012 04:16:49 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 2678421F9492 for ; Fri, 2 Nov 2012 04:16:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,699,1344207600"; d="scan'208";a="240480579" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 02 Nov 2012 11:16:46 +0000 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qA2BGjrJ008673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 2 Nov 2012 11:16:45 GMT Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Fri, 2 Nov 2012 11:16:45 +0000 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: A proposal - differentiating the document and the protocol Thread-Index: Ac2462GvrkEbwPwlSeKUcYpBS5JqPA== Date: Fri, 2 Nov 2012 11:16:44 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 11:16:50 -0000 Before making a proposal, I'm going to introduce a distinction here between= the DYMO and LOADng documents and protocols. I'm of the opinion that the LOADng document is a greatly superior presentat= ion to the DYMO document. (I'm not really interested in why that has come a= bout.) I think that regardless of whether one makes design decisions favouring DYM= O or LOADng where they differ - and let's not forget they overlap a lot - i= t would actually be easier to modify the LOADng document to specify DYMO th= an it would be to modify the DYMO document to achieve that. And in practice= I think if making decisions it is unlikely that all would favour DYMO over= LOADng. So what I think would be best for the WG is not a simply "option 1" or even= (as it may appear I'm suggesting, but I'm not) "option 2" but rather to a= gree to take the LOADng document, and a list of where DYMO and LOADng diffe= r, and thrash out where they do, what the WG reactive protocol should do - = either as a definite choice, or as an option (but not too many options plea= se- and some could be separate specifications). This would not of course be LOADng, so we'd have to change the document nam= e. And there I suggest we have a candidate name - AODVv2. (Which is why I h= ave recently taken to saying DYMO when referring to that document.) After a= ll, the one thing we are agreed on is that the protocol being developed is = derived from AODV. The editors of this new document would have to agree that what goes in it i= s WG consensus (which should follow proper technical consideration of the i= ssues). If they found it impossible to have other than their way to do thin= gs, they'd have to move on. If that left no one editing it, obviously we do= n't have a consensus of people prepared to do the work and option 3 would w= in. So now I'm partly off the fence I've been sitting on. But only partly. I ha= ven't yet formed a view on e.g. should this AODVv2 have IRREPs as standard,= IRREPs as an option in the main draft, IRREPs as a separate draft option, = no IRREPs. I'd like to move on to those discussions. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** 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 Chris.Dearlove@baesystems.com Fri Nov 2 04:42:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC3F21F9718 for ; Fri, 2 Nov 2012 04:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.538 X-Spam-Level: X-Spam-Status: No, score=-10.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJhQMM+VZSRV for ; Fri, 2 Nov 2012 04:42:46 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id EE49721F970E for ; Fri, 2 Nov 2012 04:42:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,699,1344207600"; d="scan'208,217";a="240488861" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 02 Nov 2012 11:42:42 +0000 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qA2BgVPD023890 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 11:42:41 GMT Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Fri, 2 Nov 2012 11:42:36 +0000 From: "Dearlove, Christopher (UK)" To: Jiazi YI Thread-Topic: [manet] Reactive routing protocols, what are the differences? Thread-Index: Ac24S9gO52XASJQwQb67c7wvLBVIbQAMK9OAABnHRpAAASp5gAABOJ7Q Date: Fri, 2 Nov 2012 11:42:35 +0000 Message-ID: References: <12708D7E-C548-4858-8144-6F04D2750E02@jiaziyi.com> In-Reply-To: <12708D7E-C548-4858-8144-6F04D2750E02@jiaziyi.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6AE9GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 11:42:48 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6AE9GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Having anything other than hop limit and hop count mutable is not the secur= ity mechanism suggested in 6622/5444. I'm of the view that the current approach of securing NHDP, securing OLSRv2= etc. is not where things should ideally be, that the ideal place is at the= 5444 multiplexer wherever possible. If doing hop by hop security, then tha= t is the place, as it's where packets live. But if we could do it once for = all message types, then that's a major gain. Now as soon as LOADng has anything else mutable, that doesn't help that. OK= , it's better than nothing, but those fields are buried in TLVs (using 5444= ) and messy. I'm at a disadvantage, I haven't studied why LOADng needs those fields (oth= er than hop count) mutable - or if it really does. But it reduces "here's a= clear advantage over DYMO" to "here's a more partial advantage over DYMO".= And I think Ulrich's summary could be edited to better present this. So if we adopted my separate proposal, this would be on the menu: why are t= hose fields mutable? Do they have to be? Can we find an alternative? (Unfor= tunately, I can see why probably not. But it's still a question.) [Actually I can see an alternative, which is a much more limited metric, wh= ich takes small integer values, and we increase hop count not by one but by= this metric, limiting paths to maximum 255 metric. We could still get hop = count from hop limit if we knew how it started - e.g. in a non-mutable TLV.= But I strongly doubt this is good enough.] -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI Sent: 02 November 2012 10:54 To: Dearlove, Christopher (UK) Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Clausen (thomas@thomasclau= sen.org) Subject: Re: [manet] Reactive routing protocols, what are the differences? *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Hi Chris, I think Ulrich is in deep sleep at the moment, so please allow me to have s= ome words on this. For reactive protocols, updating the route information (hop-count, metric) = is inevitable. In the specification of DYMO, the messages can be changed re= latively arbitrarily, including removing addresses from the messages. The i= ntermediate RREP also makes end-to-end security impossible. LOADng clearly defines which fields in the routing messages can't be change= d, and which fields are mutable. For example, for RREQ: The following fields of an RREQ message are immutable, i.e., they MUST NOT = be changed during processing or forwarding of the message: RREQ.addr-length= , RREQ.seq-num, RREQ.originator, and RREQ.destination. The following fields of an RREQ message are mutable, i.e., they will be cha= nged by intermediate routers during processing or forwarding, as specified = in Section 12.2 and Section 12.3: RREQ.metric-type, RREQ.route-metric, and RREQ.hop-co= unt. Any additional field that is added to the message by an extension to this p= rotocol, e.g., by way of TLVs, MUST be considered immutable, unless the ext= ension specifically defines the field as mutable. This allows the protocol to secure the messages by zeroing the mutable fiel= ds. best Jiazi (sorry to Chris if you received multiple copy of this message. I fixed one = typo though :) My previous one was bounced by manet mailing list because of= not using the right sender address) On Nov 2, 2012, at 11:22 AM, "Dearlove, Christopher (UK)" > wrote: There is, superficially at least, an apparent contradiction between your po= ints: - DYMO cannot be end-to-end secured. Messages are changed in transit (and not just hop-limit or the metric), but rather addresses can be removed from RERRs and RREQs. which implicitly suggests LOADng does not do this and - LOADng uses a Metric message TLV, and it is clearly defined how to update the metric under way. Could you expand on this please? -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Ulrich Herberg [mailto:ulrich@herberg.name] Sent: 01 November 2012 22:02 To: Dearlove, Christopher (UK) Cc: manet@ietf.org; Thomas Heide Clausen (thomas@tho= masclausen.org) Subject: Re: [manet] Reactive routing protocols, what are the differences? ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi Chris, you have seen my review on DYMO. I will try to answer to your question, and focus on the technical differences, not presentation. On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK) > wrote= : The obviously best people to answer this should be document authors, but an= yone else may have useful additions and comments. Ideally the different doc= ument authors could agree a list. (If they differ in that one has X and the= other doesn't, but one wants to say "we plan to add/remove X" then X shoul= d be listed as a difference with that caveat, in at least my ideal world.) If we set aside, for the moment (though these things matter): - The presentational quality of the documents, - Any issues of 5444 compliance and other formatting issues, - Issues of internal data organisation, - Minor details such as possible different timeout parameters etc. then what are the technical (and I stress that word) differences between DY= MO and LOADng? (I'm withholding the term AODVv2 for reasons I may come back= to.) First, let's see what is common. Both are reactive protocols, using RREQ, RREP and RERR. So if someone claims that DYMO performs great and LOADng badly in the same scenario, I cannot understand that. MANET has understood the scenarios where reactive protocols are useful and where not. Now, to the differences: - DYMO cannot be end-to-end secured. Messages are changed in transit (and not just hop-limit or the metric), but rather addresses can be removed from RERRs and RREQs. There is also no provision to allow external mechanisms to add additional reasons to reject messages as invalid. - DYMO uses the originator address in an address block, LOADng in the message header. The sequence number is a TLV value in DYMO, and LOADng uses the message sequence number. DYMO requires the originator address to be the first one in the address block, the destination must be the second one. LOADng uses a TLV to determine the target address. - DYMO can advertise multiple addresses in an RERR; they can be removed in transit of the message. - DYMO allows intermediate routers to reply (as an option). That makes end-to-end security difficult. In the core DYMO, there is a destination sequence number that may be contained in RREQs in DYMO. - DYMO allows for unicast RREQ, but does not specify in detail how to use t= hat. - There are four timers for each route entry in DYMO, only one in LOADng. - LOADng can be used on other layers; DYMO is tied to IP. - LOADng provides a bidirectionality verification using RREP_ACK, a time-out of these, a blacklisted set and a Pending Acknowledgment Set to verify bidirectional links. DYMO says that other mechanisms can be used, but does not specify these. - DYMO has several options for expanding ring RREQ, precursor list, adding route information in transit, message aggregation in RFC5444 packets and reporting multiple unreachable addresses in a RERR. LOADng takes the approach to have a slim core of a basic mechanism that is applicable in all MANET use cases, and companion documents with extensions. In DYMO, it is not clearly specified what happens if some routers support an option, and others don't. - LOADng uses a Metric message TLV, and it is clearly defined how to update the metric under way. If a router in transit does not recognize a route metric type, it is reset to a "hop count" tlv extension type of the Metric TLV and the value set to 0xFFFFF... (for the full TLV length). It is specified that security mechanism must ignore the content of the metric TLV value and that the length cannot be changed under way, so that end-to-end security is possible. DYMO uses an optional "distance" field for the metric, which is not clearly specified how it is updated. Also, since this is optional, it is unclear if routers receiving a message and forwarding it, update the distance field or not. - LOADng allows for (optionally) waiting to reply with a RREP, in case a "better" RREQ comes a little later. In DYMO, a RREP is always sent immediately. There are probably more differences, but I let other chime in. Best regards Ulrich Note that it's a lot more useful to have direct differences than difference= s of each from AODV (especially when both have the same difference). And it= would be useful to have the objective differences separated from the "and = now why this is better" discussion - though that would be a next step. I'm not saying I don't see any of the differences. But I certainly haven't = worked out the complete list. In trying to form my view of how things shoul= d go forward (a view that is coming together, and when it does, I'll argue = for it) and I hope for other people as well, it would be good to know what = the differences are. Regardless of views for or against each, we should be = able to objectively list the significant differences - if we can't then som= ething is wrong. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** 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. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6AE9GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Having anything other tha= n hop limit and hop count mutable is not the security mechanism suggested i= n 6622/5444.

 <= /p>

I'm of the view that the = current approach of securing NHDP, securing OLSRv2 etc. is not where things= should ideally be, that the ideal place is at the 5444 multiplexer wherever possible. If doing hop by hop security, then that is = the place, as it's where packets live. But if we could do it once for all m= essage types, then that's a major gain.

 <= /p>

Now as soon as LOADng has= anything else mutable, that doesn't help that. OK, it's better than nothin= g, but those fields are buried in TLVs (using 5444) and messy.

 <= /p>

I'm at a disadvantage, I = haven't studied why LOADng needs those fields (other than hop count) mutabl= e - or if it really does. But it reduces "here's a clear advantage over DYMO" to "here's a more partial advantage over DY= MO". And I think Ulrich's summary could be edited to better present th= is.

 <= /p>

So if we adopted my separ= ate proposal, this would be on the menu: why are those fields mutable? Do t= hey have to be? Can we find an alternative? (Unfortunately, I can see why probably not. But it's still a question.)<= /p>

 <= /p>

[Actually I can see an al= ternative, which is a much more limited metric, which takes small integer v= alues, and we increase hop count not by one but by this metric, limiting paths to maximum 255 metric. We could still get hop count= from hop limit if we knew how it started - e.g. in a non-mutable TLV. But = I strongly doubt this is good enough.]

 <= /p>

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (O= perations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 <= /p>

From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI
Sent: 02 November 2012 10:54
To: Dearlove, Christopher (UK)
Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Clausen (thomas@tho= masclausen.org)
Subject: Re: [manet] Reactive routing protocols, what are the differ= ences?

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

Hi Chris, =



I think Ulrich is in deep sleep at the moment, so please allow me t= o have some words on this. 



For reactive protocols, updating the route information (hop-count, = metric) is inevitable. In the specification of DYMO, the messages can be changed relatively arbitrarily, including removing addresses from t= he messages. The intermediate RREP also makes end-to-end security impossibl= e. 



LOADng clearly defines which fields in the routing messages can't b= e changed, and which fields are mutable. For example, for RREQ:



The following fields of an RREQ message are immutable, i.e., they M= UST NOT be changed during processing or forwarding of the message: RREQ.add= r-length, RREQ.seq-num, RREQ.originator, and RREQ.destination.

The following fields of an RREQ message are mutable, i.e., they wil= l be changed by intermediate routers during processing or forwarding, as sp= ecified in Section 12.2&nb= sp;and Section 12.3: RREQ.metric-type, RREQ.route-metric, and RREQ.hop-count.=

Any additional field that is added to the message by an extension t= o this protocol, e.g., by way of TLVs, MUST be considered immutable, unless= the extension specifically defines the field as mutable.=



This allows the protocol to secure the messages by zeroing the muta= ble fields. 



best



Jiazi 



(sorry to Chris if you received multiple copy of this message. I fi= xed one typo though :) My previous one was bounced by manet mailing list because of not using the right sender address)<= span style=3D"font-size:13.5pt;font-family:"Helvetica","sans= -serif";color:black">

 

 

On Nov 2, 2012, at 11:22 AM, "Dearlove, Christo= pher (UK)" <Chris.= Dearlove@baesystems.com> wrote:



There is, superficially at least, an apparent contra= diction between your points:

- DYMO cannot be end-to-end secured. Messages are changed in transit
(and not just hop-limit or the metric), but rather addresses can be
removed from RERRs and RREQs.

which implicitly suggests LOADng does not do this

and

- LOADng uses a Metric message TLV, and it is clearly defined how to
update the metric under way.

Could you expand on this please?

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.= com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Ulrich Herberg [mailto:ulrich@herberg.name]
Sent: 01 November 2012 22:02
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; Thomas Heide Clau= sen (thomas@thomasclausen.org)
Subject: Re: [manet] Reactive routing protocols, what are the differences?<= br>
----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hi Chris,

you have seen my review on DYMO. I will try to answer to your
question, and focus on the technical differences, not presentation.


On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK)
<Chris.Dearlove@baesyst= ems.com> wrote:

The obviously best people to answer this should be d= ocument authors, but anyone else may have useful additions and comments. Id= eally the different document authors could agree a list. (If they differ in= that one has X and the other doesn't, but one wants to say "we plan to add/remove X" then X should be = listed as a difference with that caveat, in at least my ideal world.)

If we set aside, for the moment (though these things matter):
- The presentational quality of the documents,
- Any issues of 5444 compliance and other formatting issues,
- Issues of internal data organisation,
- Minor details such as possible different timeout parameters etc.
then what are the technical (and I stress that word) differences between DY= MO and LOADng? (I'm withholding the term AODVv2 for reasons I may come back= to.)



First, let's see what is common. Both are reactive protocols, using
RREQ, RREP and RERR. So if someone claims that DYMO performs great and
LOADng badly in the same scenario, I cannot understand that. MANET has
understood the scenarios where reactive protocols are useful and where
not.

Now, to the differences:

- DYMO cannot be end-to-end secured. Messages are changed in transit
(and not just hop-limit or the metric), but rather addresses can be
removed from RERRs and RREQs. There is also no provision to allow
external mechanisms to add additional reasons to reject messages as
invalid.
- DYMO uses the originator address in an address block, LOADng in the
message header. The sequence number is a TLV value in DYMO, and LOADng
uses the message sequence number. DYMO requires the originator address
to be the first one in the address block, the destination must be the
second one. LOADng uses a TLV to determine the target address.
- DYMO can advertise multiple addresses in an RERR; they can be
removed in transit of the message.
- DYMO allows intermediate routers to reply (as an option). That makes
end-to-end security difficult. In the core DYMO, there is a
destination sequence number that may be contained in RREQs in DYMO.
- DYMO allows for unicast RREQ, but does not specify in detail how to use t= hat.
- There are four timers for each route entry in DYMO, only one in LOADng. - LOADng can be used on other layers; DYMO is tied to IP.
- LOADng provides a bidirectionality verification using RREP_ACK, a
time-out of these, a blacklisted set and a Pending Acknowledgment Set
to verify bidirectional links. DYMO says that other mechanisms can be
used, but does not specify these.
- DYMO has several options for expanding ring RREQ, precursor list,
adding route information in transit, message aggregation in RFC5444
packets and reporting multiple unreachable addresses in a RERR. LOADng
takes the approach to have a slim core of a basic mechanism that is
applicable in all MANET use cases, and companion documents with
extensions. In DYMO, it is not clearly specified what happens if some
routers support an option, and others don't.
- LOADng uses a Metric message TLV, and it is clearly defined how to
update the metric under way. If a router in transit does not recognize
a route metric type, it is reset to a "hop count" tlv extension t= ype
of the Metric TLV and the value set to 0xFFFFF... (for the full TLV
length). It is specified that security mechanism must ignore the
content of the metric TLV value and that the length cannot be changed
under way, so that end-to-end security is possible. DYMO uses an
optional "distance" field for the metric, which is not clearly specified how it is updated. Also, since this is optional, it is
unclear if routers receiving a message and forwarding it, update the
distance field or not.
- LOADng allows for (optionally) waiting to reply with a RREP, in case
a "better" RREQ comes a little later. In DYMO, a RREP is always s= ent
immediately.

There are probably more differences, but I let other chime in.

Best regards
Ulrich



Note that it's a lot more useful to have direct diff= erences than differences of each from AODV (especially when both have the s= ame difference). And it would be useful to have the objective differences s= eparated from the "and now why this is better" discussion - though that would be a next step.

I'm not saying I don't see any of the differences. But I certainly haven't = worked out the complete list. In trying to form my view of how things shoul= d go forward (a view that is coming together, and when it does, I'll argue = for it) and I hope for other people as well, it would be good to know what the differences are. Regardless of = views for or against each, we should be able to objectively list the signif= icant differences - if we can't then something is wrong.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.= com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687



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

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

 

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6AE9GLKXM0002VGREEN_-- From hrogge@googlemail.com Fri Nov 2 05:01:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE9721F99AF for ; Fri, 2 Nov 2012 05:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhDf7FNQg4Kk for ; Fri, 2 Nov 2012 05:01:45 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1403921F99A1 for ; Fri, 2 Nov 2012 05:01:45 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so1632938dan.31 for ; Fri, 02 Nov 2012 05:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8tS9V1uufYanXDhMoCd8IsLkJYw8md8l1ADhGz7CY80=; b=ocG2Wmih5uucWOBGcgJyL1/jxv3HVMuYQFYbEgiO69SzAXYXE1Iqi2VuLhK8ojvuNH y0nPl2ES0dLVAKQt9+CvKomD1Bio/TPKJNSGWeykqv12bhMV0Ir0LEEteyyRB3Q+Sr3Q STwr4Frh7UQBo0oEXzk4JRWoA9eYfF5HVtidGTDtW2Hf95KgmAre5kBgk7kq0yFmSD1O A6/jJ9obqpGzVudNz0H24o/39OLh7RSD9J9Bz9/AAoRtJvB+LSU2V8QxJcYxwhs+WB2y APCmiUa4MxDA676xfVZMgT10YfkGUw4D6BS3NBKpJ56pN1bmx72BJ0lR6YQ51CO037Qo K3ZA== Received: by 10.68.226.162 with SMTP id rt2mr5433054pbc.62.1351857704596; Fri, 02 Nov 2012 05:01:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Fri, 2 Nov 2012 05:01:24 -0700 (PDT) In-Reply-To: References: <12708D7E-C548-4858-8144-6F04D2750E02@jiaziyi.com> From: Henning Rogge Date: Fri, 2 Nov 2012 13:01:24 +0100 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 12:01:46 -0000 On Fri, Nov 2, 2012 at 12:42 PM, Dearlove, Christopher (UK) wrote: > Having anything other than hop limit and hop count mutable is not the > security mechanism suggested in 6622/5444. Thats my interpretation of RFC6622 too. I want to implement RFC6622 (at least packet and message level ICVs) in my generic "PacketBB" reader/writer core. As soon as more fields become mutable this would get very messy at best. > So if we adopted my separate proposal, this would be on the menu: why are > those fields mutable? Do they have to be? Can we find an alternative? > (Unfortunately, I can see why probably not. But it's still a question.) I am not convinced that securing a Distance Vector Protocol "end to end" is as easy as doing it with a Link State Protocol. Its the nature of Distance Vector Protocols that they Nodes exchange their private idea how to whole world works with their neighbors (local exchange of global information). Link state protocols only exchange their local data, but they flood them to the network (global exchange of local information), which makes things easier security wise. Securing everything except the metric will make it impossible to pretend to be a node that isn't in the mesh, but you still could spoof your local distance to the node in any way you want. Maybe using Address Block ICV TLVs would help, they allow the protocol to explicitly state what should be included into the signature. This could even include parts of the message header. (Does BGP have some ideas how to do end-to-end security? Its the only Distance Vector Protocol I know that is widely deployed.) Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From teco@inf-net.nl Fri Nov 2 05:04:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F8921F99CA for ; Fri, 2 Nov 2012 05:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMKxPxxszbMo for ; Fri, 2 Nov 2012 05:04:43 -0700 (PDT) Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B5F5021F99C8 for ; Fri, 2 Nov 2012 05:04:42 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id 56so633581yhq.31 for ; Fri, 02 Nov 2012 05:04:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=3vPRdvhTbjtE5aghw/0Exrdgw4mYeu0FL6LD4yMG5GE=; b=D+tqs9VSwq4MXFyahFDogz6tScwAcGlXPKelpAT0m6jFdNshVx344P+WnFQxPnTdkm b6Z93VC7gGfsw/XQaHjCreCIgkLrsvNCi37Z9MYYBxl/VDfFEKJ1hYNIJuxh399ExuOn PNlpUIIcCwwKwib6anvcoN9GueIUb60Hzr5VMVJ4D88k8GAAm0LvjUiOev7BtWQFqV0G Hrt7ump344Oqd2YkJLlLy+izbBE/ze7Tokm1RHXW8KOUKDhClFYvgsd6Y+TmB2Kj1B/T yrK1wklDEdram8HB33tIivD42IzfljhXiZIPYi8w8z8hdVLBoQ0w4c2fR24PDzSpnANg 4qBw== Received: by 10.236.137.104 with SMTP id x68mr1369225yhi.65.1351857882216; Fri, 02 Nov 2012 05:04:42 -0700 (PDT) Received: from [10.71.3.32] (173-15-223-105-BusName-Atlanta.hfc.comcastbusiness.net. [173.15.223.105]) by mx.google.com with ESMTPS id u22sm9430164yhl.2.2012.11.02.05.04.41 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 05:04:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Fri, 2 Nov 2012 13:04:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlkY2UiFnSdpDydy9Y0/pCDjkk9fWH1Zoi3ncUpQO9YjaQJp3TJ2XKDuA3AmKvEV8LQEYBm Cc: "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 12:04:44 -0000 This is more or less what I suggested before, perhaps not as clearly as = Chris. I suggested to use the manet-dymo document track. We don't have = to, but I do not see any argument for renaming. But first, let's get in a cooperative mode. I kindly ask al to cool down = a bit. Seen the energy on this list, my conclusion is that we all want a = great reactive MANET protocol as proposed standard. Teco Op 2 nov. 2012, om 12:16 heeft Dearlove, Christopher (UK) het volgende = geschreven: > Before making a proposal, I'm going to introduce a distinction here = between the DYMO and LOADng documents and protocols. >=20 > I'm of the opinion that the LOADng document is a greatly superior = presentation to the DYMO document. (I'm not really interested in why = that has come about.) >=20 > I think that regardless of whether one makes design decisions = favouring DYMO or LOADng where they differ - and let's not forget they = overlap a lot - it would actually be easier to modify the LOADng = document to specify DYMO than it would be to modify the DYMO document to = achieve that. And in practice I think if making decisions it is unlikely = that all would favour DYMO over LOADng. >=20 > So what I think would be best for the WG is not a simply "option 1" or = even (as it may appear I'm suggesting, but I'm not) "option 2" but = rather to agree to take the LOADng document, and a list of where DYMO = and LOADng differ, and thrash out where they do, what the WG reactive = protocol should do - either as a definite choice, or as an option (but = not too many options please- and some could be separate specifications). >=20 > This would not of course be LOADng, so we'd have to change the = document name. And there I suggest we have a candidate name - AODVv2. = (Which is why I have recently taken to saying DYMO when referring to = that document.) After all, the one thing we are agreed on is that the = protocol being developed is derived from AODV. >=20 > The editors of this new document would have to agree that what goes in = it is WG consensus (which should follow proper technical consideration = of the issues). If they found it impossible to have other than their way = to do things, they'd have to move on. If that left no one editing it, = obviously we don't have a consensus of people prepared to do the work = and option 3 would win. >=20 > So now I'm partly off the fence I've been sitting on. But only partly. = I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as = standard, IRREPs as an option in the main draft, IRREPs as a separate = draft option, no IRREPs. I'd like to move on to those discussions. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 >=20 > ******************************************************************** > 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. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Fri Nov 2 05:10:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5B421F8C71 for ; Fri, 2 Nov 2012 05:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-xot2HjTOKU for ; Fri, 2 Nov 2012 05:10:14 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3979C21F8822 for ; Fri, 2 Nov 2012 05:10:14 -0700 (PDT) Received: by mail-gh0-f172.google.com with SMTP id g10so672446ghb.31 for ; Fri, 02 Nov 2012 05:10:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=hjmep4ZYcZylrVqYsX4kVx97zYWCK1laK6EqHipjVFI=; b=Zv9RBMqUUn+IItgrxyPWGtJ+8UtVLlUX9h5yEKUXHsG/XUFBw8Lw7Q35bpqhVID6P1 8PUVg8r3GEy0zQ4HAarAUIojrqLpDS4reiLeaDoQ4HDZQQZgfcLbsi6KoERzl0E3okKw b88A5PsfbYhrCBG7kdEVqPSioc1KQ/Lp6QwbNgeHH88+blzhCUgU9pWwwe/GF2/xsp0S Ub6ImeyIwVgrkVoCpdsu8W3KKq2jetUh1U3odPdQSgR5Cw5Py/d2uej4GYq3TTkgiBBt GLaOuMN54d3O6wwUbO60igmKT3svExSB1bxOrfLbKsLsELtNeDJFzH+wDHYRi9no92/1 NypQ== Received: by 10.236.82.169 with SMTP id o29mr1335438yhe.116.1351858209668; Fri, 02 Nov 2012 05:10:09 -0700 (PDT) Received: from [10.71.3.32] (173-15-223-105-BusName-Atlanta.hfc.comcastbusiness.net. [173.15.223.105]) by mx.google.com with ESMTPS id t46sm9439720yhi.3.2012.11.02.05.10.08 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 05:10:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Fri, 2 Nov 2012 13:10:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12708D7E-C548-4858-8144-6F04D2750E02@jiaziyi.com> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmi5AaD2DpnYx1BWaVEu+fa/j24JPCN0Egy+Bve03O2t3IauFXe52YHGQfk16WQ+7RGDjRH Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 12:10:15 -0000 Op 2 nov. 2012, om 13:01 heeft Henning Rogge het volgende geschreven: > (Does BGP have some ideas how to do end-to-end security? Its the only > Distance Vector Protocol I know that is widely deployed.) We have RIP*, Cisco has EIGRP. In many deployments, routers have shared secret. I don't see much gain = in end-to-end security, as control plain info passes middle routers.=20 Teco= From Chris.Dearlove@baesystems.com Fri Nov 2 05:11:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F2521F982A for ; Fri, 2 Nov 2012 05:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.533 X-Spam-Level: X-Spam-Status: No, score=-10.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9tSjFq5qSan for ; Fri, 2 Nov 2012 05:11:48 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id E998421F8C71 for ; Fri, 2 Nov 2012 05:11:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,699,1344207600"; d="scan'208";a="283183908" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 02 Nov 2012 12:11:46 +0000 Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qA2CBkOi021760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 12:11:46 GMT Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0309.002; Fri, 2 Nov 2012 12:11:46 +0000 From: "Dearlove, Christopher (UK)" To: Teco Boot Thread-Topic: [manet] A proposal - differentiating the document and the protocol Thread-Index: Ac2462GvrkEbwPwlSeKUcYpBS5JqPAABttmAAAAZg7A= Date: Fri, 2 Nov 2012 12:11:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 12:11:49 -0000 As I said, I think the LOADng document will be much easier to adapt. Two comments there. First, it's odd reading that document, which I'm not an= author of, as large amounts feel like I did write them. That is of course = because it borrows the style of OLSRv2/NHDP, in turn adopted from (but impr= oved on) that on RFC 3626. Second, is that a good style? Well, I would refer you to Barry Leiba's comm= ents on OLSRv2 in the ID tracker as it goes through the IESG. It even got a= YES (not just a no objection) from him on that account. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: 02 November 2012 12:05 To: Dearlove, Christopher (UK) Cc: manet@ietf.org Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- This is more or less what I suggested before, perhaps not as clearly as Chr= is. I suggested to use the manet-dymo document track. We don't have to, but= I do not see any argument for renaming. But first, let's get in a cooperative mode. I kindly ask al to cool down a = bit. Seen the energy on this list, my conclusion is that we all want a grea= t reactive MANET protocol as proposed standard. Teco Op 2 nov. 2012, om 12:16 heeft Dearlove, Christopher (UK) het volgende gesc= hreven: > Before making a proposal, I'm going to introduce a distinction here betwe= en the DYMO and LOADng documents and protocols. >=20 > I'm of the opinion that the LOADng document is a greatly superior present= ation to the DYMO document. (I'm not really interested in why that has come= about.) >=20 > I think that regardless of whether one makes design decisions favouring D= YMO or LOADng where they differ - and let's not forget they overlap a lot -= it would actually be easier to modify the LOADng document to specify DYMO = than it would be to modify the DYMO document to achieve that. And in practi= ce I think if making decisions it is unlikely that all would favour DYMO ov= er LOADng. >=20 > So what I think would be best for the WG is not a simply "option 1" or ev= en (as it may appear I'm suggesting, but I'm not) "option 2" but rather to= agree to take the LOADng document, and a list of where DYMO and LOADng dif= fer, and thrash out where they do, what the WG reactive protocol should do = - either as a definite choice, or as an option (but not too many options pl= ease- and some could be separate specifications). >=20 > This would not of course be LOADng, so we'd have to change the document n= ame. And there I suggest we have a candidate name - AODVv2. (Which is why I= have recently taken to saying DYMO when referring to that document.) After= all, the one thing we are agreed on is that the protocol being developed i= s derived from AODV. >=20 > The editors of this new document would have to agree that what goes in it= is WG consensus (which should follow proper technical consideration of the= issues). If they found it impossible to have other than their way to do th= ings, they'd have to move on. If that left no one editing it, obviously we = don't have a consensus of people prepared to do the work and option 3 would= win. >=20 > So now I'm partly off the fence I've been sitting on. But only partly. I = haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standar= d, IRREPs as an option in the main draft, IRREPs as a separate draft option= , no IRREPs. I'd like to move on to those discussions. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 >=20 > ******************************************************************** > 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. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From emmanuel.baccelli@gmail.com Fri Nov 2 05:11:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDAB21F8C71 for ; Fri, 2 Nov 2012 05:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWKv5CncB4mp for ; Fri, 2 Nov 2012 05:11:48 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F31C21F9409 for ; Fri, 2 Nov 2012 05:11:48 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4118826vcb.31 for ; Fri, 02 Nov 2012 05:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=r+uBj2QzBKajLziZwSmnOjrq1d78d4MhoJmYHq4IVwk=; b=lH87+rRc+OvjsyWNgt0FH6R07msF4VhFbUsWzADHtHH4Bd9QwJeWx7X3WXG4n6DRP1 80BnLJ3JauYcD5m/uyMGddbiUnLAumMOtONLOLc/3xkTF0MGpZrnC8HxCsOYp3sfXlMa nmCr6m9qV6T6tb3yT2AzOcorCNvgiFQDj/yYBruY7ok9phSLp236THKuVykptApYlgdP 9mhQPa8D+uvCx/NKza2DZ/xVXOKRQjIfQM8doGXrviIyC0jz35SVkbls29RhNDgkVt+O aef0MzlFLc+qBs8Y8llTxCQWdQJB8XhmgxFO/58WTxNZQae1OhUCd5Owh6f+erXUeEVQ uB3Q== Received: by 10.52.100.229 with SMTP id fb5mr1339324vdb.103.1351858307311; Fri, 02 Nov 2012 05:11:47 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.58.253.136 with HTTP; Fri, 2 Nov 2012 05:11:27 -0700 (PDT) In-Reply-To: References: From: Emmanuel Baccelli Date: Fri, 2 Nov 2012 13:11:27 +0100 X-Google-Sender-Auth: hHT2PR74lMSZOyGrk3PhC-6XvPk Message-ID: To: "manet@ietf.org" Content-Type: multipart/alternative; boundary=20cf307f343e31a66e04cd820acb Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 12:11:49 -0000 --20cf307f343e31a66e04cd820acb Content-Type: text/plain; charset=ISO-8859-1 Hi Chris, I'm a bit of an outsider on this discussion, and I must admit I have not read the latest competing documents (I plan on doing that over the weekend). I therefore cannot claim yet I support your offer (or not). But let me however say that I definitely support a down-to-earth, technically-focused approach to go forward with the consensus standards-track reactive protocol MANET is supposed to deliver. And I think your proposal complies with such requirements - already a good start. Cheers, Emmanuel But if your basic assumptions are correct (concerning document readability), and if we On Fri, Nov 2, 2012 at 12:17 PM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > Before making a proposal, I'm going to introduce a distinction here > between the DYMO and LOADng documents and protocols. > > I'm of the opinion that the LOADng document is a greatly superior > presentation to the DYMO document. (I'm not really interested in why that > has come about.) > > I think that regardless of whether one makes design decisions favouring > DYMO or LOADng where they differ - and let's not forget they overlap a lot > - it would actually be easier to modify the LOADng document to specify DYMO > than it would be to modify the DYMO document to achieve that. And in > practice I think if making decisions it is unlikely that all would favour > DYMO over LOADng. > > So what I think would be best for the WG is not a simply "option 1" or > even (as it may appear I'm suggesting, but I'm not) "option 2" but rather > to agree to take the LOADng document, and a list of where DYMO and LOADng > differ, and thrash out where they do, what the WG reactive protocol should > do - either as a definite choice, or as an option (but not too many options > please- and some could be separate specifications). > > This would not of course be LOADng, so we'd have to change the document > name. And there I suggest we have a candidate name - AODVv2. (Which is why > I have recently taken to saying DYMO when referring to that document.) > After all, the one thing we are agreed on is that the protocol being > developed is derived from AODV. > > The editors of this new document would have to agree that what goes in it > is WG consensus (which should follow proper technical consideration of the > issues). If they found it impossible to have other than their way to do > things, they'd have to move on. If that left no one editing it, obviously > we don't have a consensus of people prepared to do the work and option 3 > would win. > > So now I'm partly off the fence I've been sitting on. But only partly. I > haven't yet formed a view on e.g. should this AODVv2 have IRREPs as > standard, IRREPs as an option in the main draft, IRREPs as a separate draft > option, no IRREPs. I'd like to move on to those discussions. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > ******************************************************************** > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf307f343e31a66e04cd820acb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Chris,
I'm a bit of an outsider on this discussion, and I must a= dmit I have not read the latest competing documents (I plan on doing that o= ver the weekend). I therefore cannot claim yet I support your offer (or not= ).=A0
But let me however say that I definitely support a down-to-earth, tech= nically-focused approach to go forward with the consensus standards-track r= eactive protocol MANET is supposed to deliver. And I think your proposal co= mplies with such requirements - already a good start.
Cheers,
Emmanuel


But= if your basic assumptions are correct (concerning document readability), a= nd if we=A0

On Fri, Nov 2, 2012 at 12:17 = PM, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com<= /a>> wrote:
Befo= re making a proposal, I'm going to introduce a distinction here between= the DYMO and LOADng documents and protocols.

I'm of the opinion that the LOADng document is a greatly superior prese= ntation to the DYMO document. (I'm not really interested in why that ha= s come about.)

I think that regardless of whether one makes design decisions favouring DYM= O or LOADng where they differ - and let's not forget they overlap a lot= - it would actually be easier to modify the LOADng document to specify DYM= O than it would be to modify the DYMO document to achieve that. And in prac= tice I think if making decisions it is unlikely that all would favour DYMO = over LOADng.

So what I think would be best for the WG is not a simply "option 1&quo= t; or even (as it may appear I'm suggesting, but =A0I'm not) "= option 2" but rather to agree to take the LOADng document, and a list = of where DYMO and LOADng differ, and thrash out where they do, what the WG = reactive protocol should do - either as a definite choice, or as an option = (but not too many options please- and some could be separate specifications= ).

This would not of course be LOADng, so we'd have to change the document= name. And there I suggest we have a candidate name - AODVv2. (Which is why= I have recently taken to saying DYMO when referring to that document.) Aft= er all, the one thing we are agreed on is that the protocol being developed= is derived from AODV.

The editors of this new document would have to agree that what goes in it i= s WG consensus (which should follow proper technical consideration of the i= ssues). If they found it impossible to have other than their way to do thin= gs, they'd have to move on. If that left no one editing it, obviously w= e don't have a consensus of people prepared to do the work and option 3= would win.

So now I'm partly off the fence I've been sitting on. But only part= ly. I haven't yet formed a view on e.g. should this AODVv2 have IRREPs = as standard, IRREPs as an option in the main draft, IRREPs as a separate dr= aft option, no IRREPs. I'd like to move on to those discussions.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245= 242194=A0| =A0Fax: +44 1245 242124
chris.dearlove@baesystems.= com | http://ww= w.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687



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

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf307f343e31a66e04cd820acb-- From yi.jiazi@gmail.com Fri Nov 2 05:13:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16D621F872D for ; Fri, 2 Nov 2012 05:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pemgw22WrYqw for ; Fri, 2 Nov 2012 05:13:05 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 90DAD21F99EB for ; Fri, 2 Nov 2012 05:13:04 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1664427wgb.13 for ; Fri, 02 Nov 2012 05:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=VSiXQq05s/MTEY/1U/vOBiKIZOKpH7txZAuaCzpJflw=; b=qfKHB+fO998oD0DFX+2dQybZsgWoHsK4O+F9Rv9FuDbVGERm/+SI9rYVzsVqQYby5e Q33aTAKAIPDJUKGCGdlNTu3pxv83PEdEbAHFxpfaxcIxnj4eDPyORlkFTaGj1uWwI6Xv u24euW7XCjb2VsPWPzqRHr2rXvcz5yIomsTsOIXyqvi7MgmPtr+HL9+3y9kCl6y5pf3X Yxs71TqpGDiBn+Umlvy8gIV//acAqBtP7/X5bdF9EYM+/YlfXbDA4vX3HYcrf1SPRhbp Qa1ZNieQMKbW64jbBd9yLIJ0SeTfysDqjf8ATxhzsXD6qekRHWFqIyDg+rY9h52fKHpp 9Hag== Received: by 10.180.8.134 with SMTP id r6mr2413143wia.18.1351858382780; Fri, 02 Nov 2012 05:13:02 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id hf10sm2098513wib.0.2012.11.02.05.13.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 05:13:01 -0700 (PDT) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_F0F2995B-4DBF-4E96-A04A-C2B91B0FDA8A" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi YI In-Reply-To: Date: Fri, 2 Nov 2012 13:12:59 +0100 Message-Id: <4F9C6208-78B8-41B1-81D2-C7DAAE9D780D@jiaziyi.com> References: <12708D7E-C548-4858-8144-6F04D2750E02@jiaziyi.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 12:13:07 -0000 --Apple-Mail=_F0F2995B-4DBF-4E96-A04A-C2B91B0FDA8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, The reason that LOADng needs those fields mutable is to support = different metrics other than hop-count, even routers using different = metrics in the same routing domain can at least find a path.=20 To support different metric types, a metric-type tlv and a route-metric = tlv are needed. The route-metric tlv has to be mutable because it needs = to be updated at each hop.=20 Having metric-type tlv mutable can make supporting different metrics in = the same network possible.=20 It's common that in a heterogenous network, there are various = transmission medias (802.11, 802.15.4, cable, PLC...), therefore = possible different metrics. In LOADng, if a router A (with metric-A) gets an RREQ message that it = doesn't understand (say, metric-B), router A will change the metric-type = to HOP_COUNT, and forward the message (the hop-count field is always = used). For the destination of RREQ, it will first consider the metrics = that it understands, and then HOP_COUNT. Of course, this will result in = "degrading" to HOP_COUNT for certain routes, but at least we can get a = usable route.=20 I'm just introducing the design of LOADng, and would appreciate any good = idea on this issue.=20 best Jiazi =20 On Nov 2, 2012, at 12:42 PM, "Dearlove, Christopher (UK)" = wrote: > Having anything other than hop limit and hop count mutable is not the = security mechanism suggested in 6622/5444. > =20 > I'm of the view that the current approach of securing NHDP, securing = OLSRv2 etc. is not where things should ideally be, that the ideal place = is at the 5444 multiplexer wherever possible. If doing hop by hop = security, then that is the place, as it's where packets live. But if we = could do it once for all message types, then that's a major gain. > =20 > Now as soon as LOADng has anything else mutable, that doesn't help = that. OK, it's better than nothing, but those fields are buried in TLVs = (using 5444) and messy. > =20 > I'm at a disadvantage, I haven't studied why LOADng needs those fields = (other than hop count) mutable - or if it really does. But it reduces = "here's a clear advantage over DYMO" to "here's a more partial advantage = over DYMO". And I think Ulrich's summary could be edited to better = present this. > =20 > So if we adopted my separate proposal, this would be on the menu: why = are those fields mutable? Do they have to be? Can we find an = alternative? (Unfortunately, I can see why probably not. But it's still = a question.) > =20 > [Actually I can see an alternative, which is a much more limited = metric, which takes small integer values, and we increase hop count not = by one but by this metric, limiting paths to maximum 255 metric. We = could still get hop count from hop limit if we knew how it started - = e.g. in a non-mutable TLV. But I strongly doubt this is good enough.] > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI > Sent: 02 November 2012 10:54 > To: Dearlove, Christopher (UK) > Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Clausen = (thomas@thomasclausen.org) > Subject: Re: [manet] Reactive routing protocols, what are the = differences? > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an = external partner or the internet. > Keep this in mind if you answer this message. > Please see this process on how to deal with suspicious emails. >=20 > Hi Chris,=20 >=20 >=20 > I think Ulrich is in deep sleep at the moment, so please allow me to = have some words on this.=20 >=20 >=20 > For reactive protocols, updating the route information (hop-count, = metric) is inevitable. In the specification of DYMO, the messages can be = changed relatively arbitrarily, including removing addresses from the = messages. The intermediate RREP also makes end-to-end security = impossible.=20 >=20 >=20 > LOADng clearly defines which fields in the routing messages can't be = changed, and which fields are mutable. For example, for RREQ: >=20 >=20 > The following fields of an RREQ message are immutable, i.e., they MUST = NOT be changed during processing or forwarding of the message: = RREQ.addr-length, RREQ.seq-num, RREQ.originator, and RREQ.destination. > The following fields of an RREQ message are mutable, i.e., they will = be changed by intermediate routers during processing or forwarding, as = specified in Section 12.2 and Section 12.3: RREQ.metric-type, = RREQ.route-metric, and RREQ.hop-count. > Any additional field that is added to the message by an extension to = this protocol, e.g., by way of TLVs, MUST be considered immutable, = unless the extension specifically defines the field as mutable. >=20 >=20 > This allows the protocol to secure the messages by zeroing the mutable = fields.=20 >=20 >=20 > best >=20 >=20 > Jiazi=20 >=20 >=20 > (sorry to Chris if you received multiple copy of this message. I fixed = one typo though :) My previous one was bounced by manet mailing list = because of not using the right sender address) > =20 > =20 > On Nov 2, 2012, at 11:22 AM, "Dearlove, Christopher (UK)" = wrote: >=20 >=20 > There is, superficially at least, an apparent contradiction between = your points: >=20 > - DYMO cannot be end-to-end secured. Messages are changed in transit > (and not just hop-limit or the metric), but rather addresses can be > removed from RERRs and RREQs. >=20 > which implicitly suggests LOADng does not do this >=20 > and=20 >=20 > - LOADng uses a Metric message TLV, and it is clearly defined how to > update the metric under way. >=20 > Could you expand on this please? >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Ulrich Herberg [mailto:ulrich@herberg.name]=20 > Sent: 01 November 2012 22:02 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.org) > Subject: Re: [manet] Reactive routing protocols, what are the = differences? >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Hi Chris, >=20 > you have seen my review on DYMO. I will try to answer to your > question, and focus on the technical differences, not presentation. >=20 >=20 > On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK) > wrote: >=20 > The obviously best people to answer this should be document authors, = but anyone else may have useful additions and comments. Ideally the = different document authors could agree a list. (If they differ in that = one has X and the other doesn't, but one wants to say "we plan to = add/remove X" then X should be listed as a difference with that caveat, = in at least my ideal world.) >=20 > If we set aside, for the moment (though these things matter): > - The presentational quality of the documents, > - Any issues of 5444 compliance and other formatting issues, > - Issues of internal data organisation, > - Minor details such as possible different timeout parameters etc. > then what are the technical (and I stress that word) differences = between DYMO and LOADng? (I'm withholding the term AODVv2 for reasons I = may come back to.) >=20 >=20 > First, let's see what is common. Both are reactive protocols, using > RREQ, RREP and RERR. So if someone claims that DYMO performs great and > LOADng badly in the same scenario, I cannot understand that. MANET has > understood the scenarios where reactive protocols are useful and where > not. >=20 > Now, to the differences: >=20 > - DYMO cannot be end-to-end secured. Messages are changed in transit > (and not just hop-limit or the metric), but rather addresses can be > removed from RERRs and RREQs. There is also no provision to allow > external mechanisms to add additional reasons to reject messages as > invalid. > - DYMO uses the originator address in an address block, LOADng in the > message header. The sequence number is a TLV value in DYMO, and LOADng > uses the message sequence number. DYMO requires the originator address > to be the first one in the address block, the destination must be the > second one. LOADng uses a TLV to determine the target address. > - DYMO can advertise multiple addresses in an RERR; they can be > removed in transit of the message. > - DYMO allows intermediate routers to reply (as an option). That makes > end-to-end security difficult. In the core DYMO, there is a > destination sequence number that may be contained in RREQs in DYMO. > - DYMO allows for unicast RREQ, but does not specify in detail how to = use that. > - There are four timers for each route entry in DYMO, only one in = LOADng. > - LOADng can be used on other layers; DYMO is tied to IP. > - LOADng provides a bidirectionality verification using RREP_ACK, a > time-out of these, a blacklisted set and a Pending Acknowledgment Set > to verify bidirectional links. DYMO says that other mechanisms can be > used, but does not specify these. > - DYMO has several options for expanding ring RREQ, precursor list, > adding route information in transit, message aggregation in RFC5444 > packets and reporting multiple unreachable addresses in a RERR. LOADng > takes the approach to have a slim core of a basic mechanism that is > applicable in all MANET use cases, and companion documents with > extensions. In DYMO, it is not clearly specified what happens if some > routers support an option, and others don't. > - LOADng uses a Metric message TLV, and it is clearly defined how to > update the metric under way. If a router in transit does not recognize > a route metric type, it is reset to a "hop count" tlv extension type > of the Metric TLV and the value set to 0xFFFFF... (for the full TLV > length). It is specified that security mechanism must ignore the > content of the metric TLV value and that the length cannot be changed > under way, so that end-to-end security is possible. DYMO uses an > optional "distance" field for the metric, which is not clearly > specified how it is updated. Also, since this is optional, it is > unclear if routers receiving a message and forwarding it, update the > distance field or not. > - LOADng allows for (optionally) waiting to reply with a RREP, in case > a "better" RREQ comes a little later. In DYMO, a RREP is always sent > immediately. >=20 > There are probably more differences, but I let other chime in. >=20 > Best regards > Ulrich >=20 >=20 >=20 > Note that it's a lot more useful to have direct differences than = differences of each from AODV (especially when both have the same = difference). And it would be useful to have the objective differences = separated from the "and now why this is better" discussion - though that = would be a next step. >=20 > I'm not saying I don't see any of the differences. But I certainly = haven't worked out the complete list. In trying to form my view of how = things should go forward (a view that is coming together, and when it = does, I'll argue for it) and I hope for other people as well, it would = be good to know what the differences are. Regardless of views for or = against each, we should be able to objectively list the significant = differences - if we can't then something is wrong. >=20 > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 >=20 > ******************************************************************** > 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. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_F0F2995B-4DBF-4E96-A04A-C2B91B0FDA8A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
The reason = that LOADng needs those fields mutable is to support different metrics = other than hop-count, even routers using different metrics in the same = routing domain can at least find a path. 
To support = different metric types, a metric-type tlv and a route-metric tlv are = needed. The route-metric tlv has to be mutable because it needs to be = updated at each hop. 
Having = metric-type tlv mutable can make supporting different metrics in the = same network possible. 
It's common = that in a heterogenous network, there are various transmission medias = (802.11, 802.15.4, cable, PLC...), therefore possible different = metrics.
In LOADng, if = a router A (with metric-A) gets an RREQ message that it doesn't = understand (say, metric-B), router A will change the metric-type to = HOP_COUNT, and forward the message (the hop-count field is always used). = For the destination of RREQ, it will first consider the metrics that it = understands, and then HOP_COUNT. Of course, this will result in = "degrading" to HOP_COUNT for certain routes, but at least we can get a = usable route. 
I'm just = introducing the design of LOADng, and would appreciate any good idea on = this issue. 


On Nov 2, 2012, at 12:42 PM, "Dearlove, Christopher (UK)" = <Chris.Dearlove@baesystems.co= m> wrote:

Having anything other = than hop limit and hop count mutable is not the security mechanism = suggested in 6622/5444.
 
I'm of the view that the current approach of = securing NHDP, securing OLSRv2 etc. is not where things should ideally = be, that the ideal place is at the 5444 multiplexer wherever possible. = If doing hop by hop security, then that is the place, as it's where = packets live. But if we could do it once for all message types, then = that's a major gain.
 
Now as soon as LOADng has anything else = mutable, that doesn't help that. OK, it's better than nothing, but those = fields are buried in TLVs (using 5444) and = messy.
 
I'm at a disadvantage, I haven't studied why = LOADng needs those fields (other than hop count) mutable - or if it = really does. But it reduces "here's a clear advantage over DYMO" to = "here's a more partial advantage over DYMO". And I think Ulrich's = summary could be edited to better present = this.
 
So if we adopted my separate proposal, this = would be on the menu: why are those fields mutable? Do they have to be? = Can we find an alternative? (Unfortunately, I can see why probably not. = But it's still a question.)
 
[Actually I can see an = alternative, which is a much more limited metric, which takes small = integer values, and we increase hop count not by one but by this metric, = limiting paths to maximum 255 metric. We could still get hop count from = hop limit if we knew how it started - e.g. in a non-mutable TLV. But I = strongly doubt this is good enough.]
--
Christopher = Dearlove
Senior Principal Engineer, Communications = Group
Communications, Networks and Image Analysis Capability
BAE = Systems Advanced Technology Centre
West Hanningfield Road, Great = Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  = Fax: +44 1245 242124
From: Jiazi YI = [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi = YI
Sent: 02 = November 2012 10:54
To: Dearlove, Christopher = (UK)
Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Clausen ( Re: [manet] Reactive = routing protocols, what are the = differences?

This = message originates from outside our organisation, either from an = external partner or the internet.Keep this in = mind if you answer this message.
Please see this process on how to deal with = suspicious emails.Hi Chris, I think Ulrich is in deep sleep at = the moment, so please allow me to have some words on = this. 



For = reactive protocols, updating the route information (hop-count, metric) = is inevitable. In the specification of DYMO, the messages can be changed = relatively arbitrarily, including removing addresses from the messages. = The intermediate RREP also makes end-to-end security = impossible. LOADng clearly defines which = fields in the routing messages can't be changed, and which fields are = mutable. For example, for RREQ:

The following fields of an RREQ message are mutable, i.e., = they will be changed by intermediate routers during processing or = forwarding, as specified in Section 12.3: = RREQ.metric-type, RREQ.route-metric, and = RREQ.hop-count.

Any additional field that is added to the message by an = extension to this protocol, e.g., by way of TLVs, MUST be considered = immutable, unless the extension specifically defines the field as = mutable.

This allows the protocol to secure = the messages by zeroing the mutable fields. bestJiazi (sorry to Chris if you received = multiple copy of this message. I fixed one typo though :) My previous = one was bounced by manet mailing list because of not using the right = sender address)
 
 
On = Nov 2, 2012, at 11:22 AM, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> = wrote:
There is, = superficially at least, an apparent contradiction between your = points:

- DYMO cannot be end-to-end secured. Messages are changed = in transit
(and not just hop-limit or the metric), but rather = addresses can be
removed from RERRs and RREQs.

which = implicitly suggests LOADng does not do this

and 

- LOADng uses a = Metric message TLV, and it is clearly defined how to
update the = metric under way.

Could you expand on this please?

-- 
Christopher = Dearlove
Senior Principal Engineer, Communications = Group
Communications, Networks and Image Analysis Capability
BAE = Systems Advanced Technology Centre
West Hanningfield Road, Great = Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 | =  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE = Systems (Operations) Limited
Registered Office: Warwick House, PO Box = 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, = UK
Registered in England & Wales No: = 1996687


-----Original Message-----
From: Ulrich Herberg = [mailto:ulrich@herberg.name] 
Sent: 01 November 2012 = 22:02
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.org)
Subject: = Re: [manet] Reactive routing protocols, what are the = differences?

----------------------! WARNING ! = ----------------------
This message originates from outside our = organisation,
either from an external partner or from the = internet.
Keep this in mind if you answer this message.
Follow the = 'Report Suspicious Emails' link on IT matters
for instructions on = reporting suspicious email = messages.
--------------------------------------------------------
<= br>Hi Chris,

you have seen my review on DYMO. I will try to = answer to your
question, and focus on the technical differences, not = presentation.


On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, = Christopher (UK)
<The obviously = best people to answer this should be document authors, but anyone else = may have useful additions and comments. Ideally the different document = authors could agree a list. (If they differ in that one has X and the = other doesn't, but one wants to say "we plan to add/remove X" then X = should be listed as a difference with that caveat, in at least my ideal = world.)

If we set aside, for the moment (though these things = matter):
- The presentational quality of the documents,
- Any = issues of 5444 compliance and other formatting issues,
- Issues of = internal data organisation,
- Minor details such as possible = different timeout parameters etc.
then what are the technical (and I = stress that word) differences between DYMO and LOADng? (I'm withholding = the term AODVv2 for reasons I may come back to.)


First, let's see what is common. Both are = reactive protocols, using
RREQ, RREP and RERR. So if someone claims = that DYMO performs great and
LOADng badly in the same scenario, I = cannot understand that. MANET has
understood the scenarios where = reactive protocols are useful and where
not.

Now, to the = differences:

- DYMO cannot be end-to-end secured. Messages are = changed in transit
(and not just hop-limit or the metric), but rather = addresses can be
removed from RERRs and RREQs. There is also no = provision to allow
external mechanisms to add additional reasons to = reject messages as
invalid.
- DYMO uses the originator address in = an address block, LOADng in the
message header. The sequence number = is a TLV value in DYMO, and LOADng
uses the message sequence number. = DYMO requires the originator address
to be the first one in the = address block, the destination must be the
second one. LOADng uses a = TLV to determine the target address.
- DYMO can advertise multiple = addresses in an RERR; they can be
removed in transit of the = message.
- DYMO allows intermediate routers to reply (as an option). = That makes
end-to-end security difficult. In the core DYMO, there is = a
destination sequence number that may be contained in RREQs in = DYMO.
- DYMO allows for unicast RREQ, but does not specify in detail = how to use that.
- There are four timers for each route entry in = DYMO, only one in LOADng.
- LOADng can be used on other layers; DYMO = is tied to IP.
- LOADng provides a bidirectionality verification = using RREP_ACK, a
time-out of these, a blacklisted set and a Pending = Acknowledgment Set
to verify bidirectional links. DYMO says that = other mechanisms can be
used, but does not specify these.
- DYMO = has several options for expanding ring RREQ, precursor list,
adding = route information in transit, message aggregation in RFC5444
packets = and reporting multiple unreachable addresses in a RERR. LOADng
takes = the approach to have a slim core of a basic mechanism that = is
applicable in all MANET use cases, and companion documents = with
extensions. In DYMO, it is not clearly specified what happens if = some
routers support an option, and others don't.
- LOADng uses a = Metric message TLV, and it is clearly defined how to
update the = metric under way. If a router in transit does not recognize
a route = metric type, it is reset to a "hop count" tlv extension type
of the = Metric TLV and the value set to 0xFFFFF... (for the full TLV
length). = It is specified that security mechanism must ignore the
content of = the metric TLV value and that the length cannot be changed
under way, = so that end-to-end security is possible. DYMO uses an
optional = "distance" field for the metric, which is not clearly
specified how = it is updated. Also, since this is optional, it is
unclear if routers = receiving a message and forwarding it, update the
distance field or = not.
- LOADng allows for (optionally) waiting to reply with a RREP, = in case
a "better" RREQ comes a little later. In DYMO, a RREP is = always sent
immediately.

There are probably more differences, = but I let other chime in.

Best = regards
Ulrich



Note that it's a lot more useful to have direct differences = than differences of each from AODV (especially when both have the same = difference). And it would be useful to have the objective differences = separated from the "and now why this is better" discussion - though that = would be a next step.

I'm not saying I don't see any of the = differences. But I certainly haven't worked out the complete list. In = trying to form my view of how things should go forward (a view that is = coming together, and when it does, I'll argue for it) and I hope for = other people as well, it would be good to know what the differences are. = Regardless of views for or against each, we should be able to = objectively list the significant differences - if we can't then = something is wrong.

--
Christopher Dearlove
Senior = Principal Engineer, Communications Group
Communications, Networks and = Image Analysis Capability
BAE Systems Advanced Technology = Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, = UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE = Systems (Operations) Limited
Registered Office: Warwick House, PO Box = 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, = UK
Registered in England & Wales No: = 1996687



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

_______________________________________________
manet = mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

To: Teco Boot , Henning Rogge Thread-Topic: [manet] Reactive routing protocols, what are the differences? Thread-Index: Ac24S9gO52XASJQwQb67c7wvLBVIbQAMK9OAABnHRpAAASp5gAABOJ7QAAEltgAAAE47gAAAFG2A Date: Fri, 2 Nov 2012 12:17:14 +0000 Message-ID: References: <12708D7E-C548-4858-8144-6F04D2750E02@jiaziyi.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 12:17:17 -0000 In a link state protocol there is a real gain. (I'm afraid I've not got eno= ugh time right now to discuss why.) For a reactive protocol which relies no= t just on the end message, but on the intermediate sequence that the RREPs = pass through, that's not so obvious. At least not without an accumulating s= ignature (which the maths exists for without signature size growth, I belie= ve). Those could be a 6622/5444 option. It's an interesting area of discuss= ion if we move into the technical issues. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of T= eco Boot Sent: 02 November 2012 12:10 To: Henning Rogge Cc: Dearlove, Christopher (UK); manet@ietf.org; Thomas Heide Clausen (thoma= s@thomasclausen.org) Subject: Re: [manet] Reactive routing protocols, what are the differences? ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Op 2 nov. 2012, om 13:01 heeft Henning Rogge het volgende geschreven: > (Does BGP have some ideas how to do end-to-end security? Its the only > Distance Vector Protocol I know that is widely deployed.) We have RIP*, Cisco has EIGRP. In many deployments, routers have shared secret. I don't see much gain in e= nd-to-end security, as control plain info passes middle routers.=20 Teco _______________________________________________ manet mailing list manet@ietf.org 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 teco@inf-net.nl Fri Nov 2 05:18:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D613F21F8756 for ; Fri, 2 Nov 2012 05:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPkrkIjEDKV0 for ; Fri, 2 Nov 2012 05:18:07 -0700 (PDT) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B549821F85B1 for ; Fri, 2 Nov 2012 05:18:06 -0700 (PDT) Received: by mail-ye0-f172.google.com with SMTP id l13so673414yen.31 for ; Fri, 02 Nov 2012 05:18:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=YKak8FROq1H2+umSMsINMJ5RUFPX603+wasJ+qLyuD4=; b=lltrnB7pxrbo7VsLqp/k5u0R4Yc+oXe/dufjEzVPAKCtvz/1DjeSoGOZR7oEDPEtoe 6NUufXXCOP75DyU8LAOo3ABd2l1/HUc/S9mxYy9iEShmTHZty23JAlhIzfo9PpKBd1gF u6pinkxUu4NgrLbwzOTXBtYa9VsZo5FL42vGLIkOOnxfgKKEbtHBASbN6lRb4SKhLN/T a4RjLKglqRV6+5BTkfIB1nuslM6Wdy1Z8YMC5Z4vNiN05UHEZNVr0qSTBseU2s4UT3lr TGcSS5ym6nR6kkJefNHQOrulvSutR6gyLUWhv4cq0fNpkCOQL4YH8nvBkVYnroNL5HCS ahew== Received: by 10.101.136.16 with SMTP id o16mr388948ann.74.1351858685326; Fri, 02 Nov 2012 05:18:05 -0700 (PDT) Received: from [10.71.3.32] (173-15-223-105-BusName-Atlanta.hfc.comcastbusiness.net. [173.15.223.105]) by mx.google.com with ESMTPS id d66sm9456414yhe.1.2012.11.02.05.18.04 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 05:18:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_B896265B-9F53-4FF5-814F-B791AB0F703C" From: Teco Boot In-Reply-To: Date: Fri, 2 Nov 2012 13:18:05 +0100 Message-Id: <88AD5814-A6CB-4BBF-9DF5-F55A53552398@inf-net.nl> References: <03B78081B371D44390ED6E7BADBB4A7722049CC0@xmb-rcd-x02.cisco.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkWzUglUEDSEyOefmref6o1LLx9jTczCQUfrrW5rNKxwHRGj3B5CMZQvfu/EMDJmxpgh9wO Cc: " List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 12:18:09 -0000 --Apple-Mail=_B896265B-9F53-4FF5-814F-B791AB0F703C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 @Stan, I think you and Joe should do whatever you can, as chairs, to get our = work done. I have seen confusion on what chairs had in mind with this = polling. Can you guide the discussion? Thanks, Teco Op 1 nov. 2012, om 21:11 heeft Stan Ratliff het volgende geschreven: > JP,=20 >=20 > Speaking for myself (not necessarily for Joe, as I haven't discussed = with him a couple of days), my intent with the email was to bring the = situation vis-a-vis reactive protocols to the WG's attention, and to see = if the group coalesces around any of the three options.=20 >=20 > To be frank, based on the last 3 months of discussion, and the current = email storm (including references to the "toxic environment"), I believe = that the situation has passed to point of no return. I do not think the = respective authors, or the WG as a whole, will ever (or at least for the = foreseeable future) be able to reach consensus on a reactive protocol. = Therefore, my preference is to remove the work item from the charter.=20 >=20 > Let's see how the discussion progresses.=20 >=20 > Regards, > Stan >=20 > On Thu, Nov 1, 2012 at 3:36 PM, JP Vasseur (jvasseur) = wrote: > Agree with you Don. >=20 > Since discussions are going in many directions =85 would the chairs = help us organize these discussions ? >=20 > Are you indeed asking us to express our preference for one of these = options, pick one and start from there ? >=20 > On Nov 1, 2012, at 7:40 PM, Don Sturek wrote: >=20 >> Hi Charlie, >>=20 >> Apologies if I misrepresented the facts on DYMO/AODVv2=85=85 >>=20 >> I do think the facts as exist right now are: >> 1) We have a LOADng draft that claims support to address the MANET = reactive protocol requirements >> 2) Work has restarted (by yourself) on DYMO/AODVv2 >> 3) There are two different views on the ability to merge LOADng with = DYMO/AODVv2. One view is the merge can happen and another (unfortunately = by some authors of LOADng) that such a merge is impractical. >>=20 >> So, irrespective of how we got to where we are, the point is it is a = good time to draw a conclusion on which of the 3 options above MANET = should take to meet its requirement for a reactive routing protocol. >>=20 >> Don >>=20 >>=20 >> From: "Charles E. Perkins" >> Organization: Saratoga Blue Skies >> Date: Thursday, November 1, 2012 11:32 AM >> To: Don Sturek >> Cc: "manet@ietf.org" >> Subject: Re: [manet] Reactive Protocol Situation >>=20 >>=20 >> Hello Don, >>=20 >> Your claim has been made several times, and I think it is highly = misleading. >>=20 >> The bottom line is that the editorship of the WG document is now in = good >> hands, and given the time available in the past, good progress has = been >> made. Also given my renewed emphasis, support from my job, and clear >> understanding of goals, I can confidently state that I can do the = work, and >> can manage the editorship process to follow working group discussion = to >> completion. Here is (some of) what happened. I hope you will read = it. >>=20 >> I was asked last fall to resume editorship of the DYMO document, and >> agreed to do so. >>=20 >> Almost at the same time, I was invited to work with the LOADng = authors >> to produce a merged document that incorporated the best features from >> DYMO and from LOADng. At that time, the general agreement was that >> the merged document would be renamed AODVv2. >>=20 >> Because of various personal difficulties unfamiliar in my experience, = I was >> surprised to find very late in the winter that the merge was not = happening. >> In order to carry out my responsibility, which was clearly to submit = a >> revised document for IETF 83 in Paris, I took the resource available = to me >> and within less than a week I submitted the revised DYMO draft = renamed >> to be AODVv2. >>=20 >> People attending the meeting will remember what happened. I was = quite >> unjustly attacked and called names for doing: >> a) what I said I would do >> b) what I was supposed to do, and >> c) changing the document to become more compatible with LOADng, as >> requested by those authors and according to my best = understanding. >>=20 >> After that, I still hoped that we could do the merge, but nothing = happened >> until in Vancouver when the WG chairs gave us an ultimatum to make >> something happen by November. >>=20 >> We went around and around, but I eventually determined that there >> was almost no chance that the LOADng authors would willingly help to >> produce the desired merge. So I did what the LOADng authors had = asked >> me not to do: namely submit a revised document for consideration. >> This revised document was an attempt to respond to valid comments >> made during 2010 about problems with the document while it was >> under Ian's editorial responsibility. It needs further revision -- = in fact >> I will submit a much more polished document on my website this >> week. >>=20 >> The important point is that for the last year the document languished >> for all but a few weeks *at the request of the LOADng authors* -- >> in fact, I would even say at their *DEMAND*, and all the while they >> refused to help make the merge that (a) they had originally suggested >> and (b) I was supposed to do. >>=20 >> This note is already too long. I have much, much more to say.=20 >> But I will say one more thing: I have the ability and now the time to >> do an excellent job on this, and I am here on the job only for the >> benefit of the working group. Now that I can focus on it, and now >> that I do not feel constrained to abide by the demands for delay >> that were imposed by the LOADng author team, I can do it pretty >> expediently. Of course I will welcome their input as well, and to >> further reiterate it will be my intention to make the WG document >> compatible with the needs of LOADng. >>=20 >> Oh -- and one more thing... Regardless of the poisoned atmosphere >> surrounding this debate, I have nothing but high regard for the work >> done by the LOADng team. I don't think their methods are right for >> this working group, and any statements to the effect that the DYMO >> editorial process has been deficient during the last year or more >> should be understood in light of the above narrative. >>=20 >> Regards, >> Charlie P. >>=20 >> PS. Oh, and one more thing... I am a peaceful man, and if I don't >> respond to all the invective and intransigence so clearly >> in evidence lately, you'll just have to excuse me for trying >> to remain so. >>=20 >>=20 >> On 11/1/2012 9:40 AM, Don Sturek wrote: >>> Hi Adbussalam, >>>=20 >>> It is hard to consider a draft stalled 2+ years as the only way = forward in MANET as a reactive protocol. >>>=20 >>> Don >>>=20 >>>=20 >>>=20 >>> From: Abdussalam Baryun >>> Date: Thursday, November 1, 2012 8:53 AM >>> To: Jon Black >>> Cc: "manet@ietf.org" , Stan Ratliff = >>> Subject: Re: [manet] Reactive Protocol Situation >>>=20 >>> Yes LOADng is a reactive protocols, but not the MANET WG reactive = protocol (DYMO is already authorised). The WG is the only authorised to = make such decisions for its WG drafts, if WG decides to add any LOADng = ideas it can, or to accept such merge it can as well, >>> AB >>> On Thu, Nov 1, 2012 at 3:37 PM, Jon Black = wrote: >>>> Why would you think that LOADng is not reactive? If it is not a = reactive protocol, then what is it? >>>>=20 >>>> As to merging the documents, this is what WGs do. If you have = multiple "competing" ideas you ask the authors to see if they can merge = their concepts and ideas. If they cannot or will not then the WG must = decide based on facts and not conjecture which is the most prudent path = to take. >>>>=20 >>>> Jon >>>>=20 >>>>=20 >>>> From: Abdussalam Baryun >>>> To: Joseph Macker =20 >>>> Cc: manet@ietf.org; Stan Ratliff =20 >>>> Sent: Thursday, November 1, 2012 8:22 AM >>>>=20 >>>> Subject: Re: [manet] Reactive Protocol Situation >>>>=20 >>>> Dear Joseph Macker and Stan, >>>> MANET WG Chairs >>>> =20 >>>> I disagree that the WG arranged/guided to merge the documents, I = never heard that there was a consensus on such activity. DYMO is a = reactive WG draft, but LOADng is not. Why did you guide to merge = documents, I recommend that you ment to merge the team drafts co-authors = to one WG draft (which is only DYMO so far). The authority is for the WG = to decide to merge individual drafts to its WG draft. >>>> =20 >>>> Therefore, my vote is for option 1 only. Thanking you for updating = us with the status. >>>> =20 >>>> Regards >>>> AB >>>>=20 >>>> On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker = wrote: >>>>> Hello MANET working group (form Stan and Joe), >>>>>=20 >>>>> As you are all probably aware, there has been WG activity lately = on competing drafts for a MANET reactive protocol - DYMO (reviving the = current working group document that was parked due to inactivity), and = LOADng. Many months ago there was a somewhat authorship led movement = towards a common document effort and given positive feedback at the time = we the chairs thought this was the best approach given the authors = potential to come together and gain the best of both efforts. Since = that period, there has been some fairly strident and rancorous "at = times" debate between the authors of the two documents. >>>>>=20 >>>>> During IETF 84 in Vancouver, the co-chairs held a discussion with = some of the co-authors of the two documents. Our guidance to the = co-authors was to find a way to merge the two documents into one, as it = was perceived that are not technically far apart and they both derive = roughly from AODV concepts and LOADng had fairly active authorship and = implementation efforts. We provided a co-editing proposal to the authors = and gave them the timeframe of the Atlanta to come up with an answer = back to us regarding this. As of this writing, those discussions of a = potential commonn document and authorship merger have failed. >>>>>=20 >>>>> Therefore, we find ourselves at a crossroads. The authors of the = two documents are divided, and it is unlikely that progress on a merged = document can be reached based upon recent author feedback. I have also = polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat = disengaged on the issue at the present time. We see only 3 possible = paths forward: >>>>>=20 >>>>> 1. Continue the work on the DYMO document, starting with whether = there is consensus on its continued approach and also the desire to = rename it to AODVv2. >>>>> 2. Replace the existing DYMO document effort with the LOADng = related document effort, defusing ealier references to LLNs as = recommended in the last meeting minutes, and to focus more = motivationally on general MANET problem spaces (the authors seem to have = agreed to this issue if its a WG document). >>>>> 3. Remove the working group charter for a reactive protocol, = effectively killing both documents, at least from a working group (WG) = standpoint. This would not be a reflection on the technology in either = case, just an admission that we are not working together and reaching = consensus. >>>>>=20 >>>>> The co-chairs request and need your opinions on the options. We = have been some silent collecting initial feedback and waiting for author = feedback at this point. Stan and I are both on travel prior to Atlanta = so our responses may be sparse and we will also likely be in a "receive = mode" for a few days. So send your opinions. >>>>>=20 >>>>> -Joe >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ manet mailing list = manet@ietf.org https://www.ietf.org/mailman/listinfo/manet=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.orghttps://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> --=20 >> Regards, >> Charlie P. >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 >=20 > --=20 > Regards, > Stan >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_B896265B-9F53-4FF5-814F-B791AB0F703C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

JP, =

Speaking for myself (not necessarily for Joe, as I haven't = discussed with him a couple of days), my intent with the email was to = bring the situation vis-a-vis reactive protocols to the WG's attention, = and to see if the group coalesces around any of the three options.

To be frank, based on the last 3 months of discussion, and the = current email storm (including references to the "toxic environment"), I = believe that the situation has passed to point of no return. I do not = think the respective authors, or the WG as a whole, will ever (or at = least for the foreseeable future) be able to reach consensus on a = reactive protocol. Therefore, my preference is to remove the work item = from the charter.

Let's see how the discussion progresses. =

Regards,
Stan

On Thu, Nov = 1, 2012 at 3:36 PM, JP Vasseur (jvasseur) <jvasseur@cisco.com> wrote:
Agree with you Don.

Since discussions are going in many directions =85 would the chairs = help us organize these discussions ?

Are you indeed asking us to express our preference for one of these = options, pick one and start from there ?

On Nov 1, 2012, at 7:40 PM, Don Sturek wrote:

Hi Charlie,

Apologies if I misrepresented the facts on DYMO/AODVv2=85=85

I do think the facts as exist right now are:
1)  We have a LOADng draft that claims support to address the = MANET reactive protocol requirements
2)  Work has restarted (by yourself) on DYMO/AODVv2
3)  There are two different views on the ability to merge = LOADng with DYMO/AODVv2. One view is the merge can happen and another = (unfortunately by some authors of LOADng) that such a merge is = impractical.

So, irrespective of how we got to where we are, the point is it is = a good time to draw a conclusion on which of the 3 options above MANET = should take to meet its requirement for a reactive routing = protocol.

Don


From: "Charles E. Perkins" = <charliep@computer.org>
Organization: Saratoga Blue = Skies
Date: Thursday, November 1, 2012 = 11:32 AM
To: Don Sturek <d.sturek@att.net>
Cc: "manet@ietf.org" = <manet@ietf.org>
Subject: Re: [manet] Reactive = Protocol Situation


Hello Don,

Your claim has been made several times, and I think it is highly = misleading.

The bottom line is that the editorship of the WG document is now in = good
hands, and given the time available in the past, good progress has = been
made.  Also given my renewed emphasis, support from my job, and = clear
understanding of goals, I can confidently state that I can do the work, = and
can manage the editorship process to follow working group discussion = to
completion.  Here is (some of) what happened.  I hope you will = read it.

I was asked last fall to resume editorship of the DYMO document, and
agreed to do so.

Almost at the same time, I was invited to work with the LOADng = authors
to produce a merged document that incorporated the best features = from
DYMO and from LOADng.  At that time, the general agreement was = that
the merged document would be renamed AODVv2.

Because of various personal difficulties unfamiliar in my experience, I = was
surprised to find very late in the winter that the merge was not = happening.
In order to carry out my responsibility, which was clearly to submit = a
revised document for IETF 83 in Paris, I took the resource available to = me
and within less than a week I submitted the revised DYMO draft = renamed
to be AODVv2.

People attending the meeting will remember what happened.  I was = quite
unjustly attacked and called names for doing:
a) what I said I would do
b) what I was supposed to do, and
c) changing the document to become more compatible with LOADng, as
    requested by those authors and according to my best = understanding.

After that, I still hoped that we could do the merge, but nothing = happened
until in Vancouver when the WG chairs gave us an ultimatum to make
something happen by November.

We went around and around, but I eventually determined that there
was almost no chance that the LOADng authors would willingly help to
produce the desired merge.  So I did what the LOADng authors had = asked
me not to do: namely submit a revised document for consideration.
This revised document was an attempt to respond to valid comments
made during 2010 about problems with the document while it was
under Ian's editorial responsibility.  It needs further revision -- = in fact
I will submit a much more polished document on my website this
week.

The important point is that for the last year the document = languished
for all but a few weeks *at the request of the LOADng authors* --
in fact, I would even say at their *DEMAND*, and all the while they
refused to help make the merge that (a) they had originally = suggested
and (b) I was supposed to do.

This note is already too long.  I have much, much more to say.
But I will say one more thing: I have the ability and now the time = to
do an excellent job on this, and I am here on the job only for the
benefit of the working group.  Now that I can focus on it, and = now
that I do not feel constrained to abide by the demands for delay
that were imposed by the LOADng author team, I can do it pretty
expediently.  Of course I will welcome their input as well, and = to
further reiterate it will be my intention to make the WG document
compatible with the needs of LOADng.

Oh -- and one more thing...  Regardless of the poisoned = atmosphere
surrounding this debate, I have nothing but high regard for the work
done by the LOADng team.  I don't think their methods are right = for
this working group, and any statements to the effect that the DYMO
editorial process has been deficient during the last year or more
should be understood in light of the above narrative.

Regards,
Charlie P.

PS. Oh, and one more thing...  I am a peaceful man, and if I = don't
        respond to all the invective = and intransigence so clearly
        in evidence lately, you'll = just have to excuse me for trying
        to remain so.


On 11/1/2012 9:40 AM, Don Sturek wrote:
Hi Adbussalam,

It is hard to consider a draft stalled 2+ years as the only way = forward in MANET as a reactive protocol.

Don



From: Abdussalam Baryun <abdussalambaryun@gmail.com>
Date: Thursday, November 1, 2012 = 8:53 AM
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" = <manet@ietf.org>, Stan Ratliff <sratliff@cisco.com>
Subject: Re: [manet] Reactive = Protocol Situation

Yes LOADng is a reactive protocols, but not the MANET WG = reactive protocol (DYMO is already authorised). The WG is the only = authorised to make such decisions for its WG drafts, if WG decides to = add any LOADng ideas it can, or to accept such merge it can as well,
AB
On Thu, Nov 1, 2012 at 3:37 PM, Jon Black = <jblack.ietf@yahoo.com> wrote:
Why would you think that LOADng is not reactive?  If it is not a = reactive protocol, then what is it?

As to merging the documents, this is what WGs do.  If you have = multiple "competing" ideas you ask the authors to see if they can merge = their concepts and ideas.  If they cannot or will not then the WG = must decide based on facts and not conjecture which is the most prudent path to take.

Jon


From: Abdussalam Baryun = <abdussalambaryun@gmail.com>
To: Joseph Macker <jpmacker@gmail.com>
Cc: manet@ietf.org; Stan Ratliff <sratliff@cisco.com>
Sent: Thursday, November = 1, 2012 8:22 AM

Subject: Re: [manet] = Reactive Protocol Situation

Dear Joseph Macker and Stan,
MANET WG Chairs
 
I disagree that the WG arranged/guided to merge the = documents, I never heard that there was a consensus on such activity. = DYMO is a reactive WG draft, but LOADng is not. Why did you guide to = merge documents, I recommend that you ment to merge the team drafts co-authors to one WG draft (which is only DYMO so far). The = authority is for the WG to decide to merge individual drafts to its WG = draft.
 
Therefore, my vote is for option 1 only. Thanking you for updating = us with the status.
 
Regards
AB

On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker <jpmacker@gmail.com> wrote:
Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on = competing drafts for a MANET reactive protocol - DYMO (reviving the = current working group document that was parked due to inactivity), and = LOADng. Many months ago there was a somewhat authorship led movement towards a common document effort and given positive = feedback at the time we the chairs thought this was the best approach = given the authors potential to come together and gain the best of both = efforts.  Since that period, there has been some fairly strident and rancorous "at times" debate between the authors of the two = documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some = of the co-authors of the two documents. Our guidance to the co-authors = was to find a way to merge the two documents into one, as it was = perceived that are not technically far apart and they both derive roughly from AODV concepts and LOADng had fairly active = authorship and implementation efforts. We provided a co-editing proposal = to the authors and gave them the timeframe of the Atlanta to come up = with an answer back to us regarding this.  As of this writing, those discussions of a potential commonn document and = authorship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two = documents are divided, and it is unlikely that progress on a merged = document can be reached based upon recent author feedback. I have also = polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present time.  = We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there = is consensus on its continued approach and also the desire to rename it = to AODVv2.
2. Replace the existing DYMO document effort with the LOADng related = document effort, defusing ealier references to LLNs as recommended in = the last meeting minutes, and to focus more motivationally on general = MANET problem spaces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protocol, effectively = killing both documents, at least from a working group (WG) standpoint. = This would not be a reflection on the technology in either case, just an = admission that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.  We = have been some silent collecting initial feedback and waiting for author = feedback at this point.  Stan and I are both on travel prior to = Atlanta so our responses may be sparse and we will also likely be in a "receive mode" for a few days.  So send your = opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
= https://www.ietf.org/mailman/listinfo/manet



_______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet 

_______________________________________________
manet mailing list
manet@ietf.orghttps://www.ietf.org/mailman/listinfo/manet


--=20
Regards,
Charlie P.
= _______________________________________________
manet mailing list
manet@ietf.org
= https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet




-- =
Regards,
Stan

_______________________________________________
manet mailing = list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= --Apple-Mail=_B896265B-9F53-4FF5-814F-B791AB0F703C-- From teco@inf-net.nl Fri Nov 2 05:30:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED62621F891A for ; Fri, 2 Nov 2012 05:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgAmpxgVDtQ9 for ; Fri, 2 Nov 2012 05:30:05 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB23021F86FF for ; Fri, 2 Nov 2012 05:30:04 -0700 (PDT) Received: by mail-gg0-f172.google.com with SMTP id i4so666677ggn.31 for ; Fri, 02 Nov 2012 05:30:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=iDwxs4aECqDDyUCe0q3JU8UxAnpFxYWLiFcCB15Ki2I=; b=HAzxxFW5qsDA8P1DiwBy7Kzg7FnkiQaxH0Cx4Yjj0OP7t+U9yo++q9Oq0MY1WQCBUc Ra74UPHmncO8twZ9WijH80A9/swElONAP7rQJWmAFRJ0G/NFrdqlROf3GOl7Ns0SRKfu HePjeVfByfLqbrsQ6OkETCamr2iVnO582GECmUMA42KdITsqzZA0NtKC8FotDRjN+6nC fksTi3p1XtEPVuE80JrEyJv7C/5jsucKbNgE5+xmQu7gcUJ4pkTfIbQPNsX/ty+lEsgR wmLDTal3TrdKnEe1zDJelWjyvojJmBLCx0s7eexwAb4mUsL5UKNJPmIp8V65edjmGUeH +9dQ== Received: by 10.236.181.225 with SMTP id l61mr1438219yhm.47.1351859404388; Fri, 02 Nov 2012 05:30:04 -0700 (PDT) Received: from [10.71.3.32] (173-15-223-105-BusName-Atlanta.hfc.comcastbusiness.net. [173.15.223.105]) by mx.google.com with ESMTPS id s21sm9476630yhb.5.2012.11.02.05.30.02 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 05:30:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Fri, 2 Nov 2012 13:30:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3C7A4DA4-92ED-42CF-A999-64724F469B56@inf-net.nl> References: To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkJD+MlgHAsbNrz7NE2P5QOJKKAHiqEK4yMdgG8Fnl/rRjxTcckbUD/RwaMduIoVnhqgw8+ Cc: "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 12:30:06 -0000 (document track: the history of ietf-manet-dymo). I suggested in my posting, dd 16 oktober, to use = draft-ietf-manet-dymo-23 as placeholder for an updated text coming from = the LOADng corner. I expected more that just s/LLN/MANET/. And I = expected some cooperation. I still do. There is nothing wrong to have the same document format for both our = core protocols. In the contrary ! Teco=20 Op 2 nov. 2012, om 13:11 heeft Dearlove, Christopher (UK) het volgende = geschreven: > As I said, I think the LOADng document will be much easier to adapt. >=20 > Two comments there. First, it's odd reading that document, which I'm = not an author of, as large amounts feel like I did write them. That is = of course because it borrows the style of OLSRv2/NHDP, in turn adopted = from (but improved on) that on RFC 3626. >=20 > Second, is that a good style? Well, I would refer you to Barry Leiba's = comments on OLSRv2 in the ID tracker as it goes through the IESG. It = even got a YES (not just a no objection) from him on that account. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: 02 November 2012 12:05 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org > Subject: Re: [manet] A proposal - differentiating the document and the = protocol >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > This is more or less what I suggested before, perhaps not as clearly = as Chris. I suggested to use the manet-dymo document track. We don't = have to, but I do not see any argument for renaming. >=20 > But first, let's get in a cooperative mode. I kindly ask al to cool = down a bit. Seen the energy on this list, my conclusion is that we all = want a great reactive MANET protocol as proposed standard. >=20 > Teco >=20 >=20 > Op 2 nov. 2012, om 12:16 heeft Dearlove, Christopher (UK) het volgende = geschreven: >=20 >> Before making a proposal, I'm going to introduce a distinction here = between the DYMO and LOADng documents and protocols. >>=20 >> I'm of the opinion that the LOADng document is a greatly superior = presentation to the DYMO document. (I'm not really interested in why = that has come about.) >>=20 >> I think that regardless of whether one makes design decisions = favouring DYMO or LOADng where they differ - and let's not forget they = overlap a lot - it would actually be easier to modify the LOADng = document to specify DYMO than it would be to modify the DYMO document to = achieve that. And in practice I think if making decisions it is unlikely = that all would favour DYMO over LOADng. >>=20 >> So what I think would be best for the WG is not a simply "option 1" = or even (as it may appear I'm suggesting, but I'm not) "option 2" but = rather to agree to take the LOADng document, and a list of where DYMO = and LOADng differ, and thrash out where they do, what the WG reactive = protocol should do - either as a definite choice, or as an option (but = not too many options please- and some could be separate specifications). >>=20 >> This would not of course be LOADng, so we'd have to change the = document name. And there I suggest we have a candidate name - AODVv2. = (Which is why I have recently taken to saying DYMO when referring to = that document.) After all, the one thing we are agreed on is that the = protocol being developed is derived from AODV. >>=20 >> The editors of this new document would have to agree that what goes = in it is WG consensus (which should follow proper technical = consideration of the issues). If they found it impossible to have other = than their way to do things, they'd have to move on. If that left no one = editing it, obviously we don't have a consensus of people prepared to do = the work and option 3 would win. >>=20 >> So now I'm partly off the fence I've been sitting on. But only = partly. I haven't yet formed a view on e.g. should this AODVv2 have = IRREPs as standard, IRREPs as an option in the main draft, IRREPs as a = separate draft option, no IRREPs. I'd like to move on to those = discussions. >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >>=20 >> ******************************************************************** >> 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. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 From Chris.Dearlove@baesystems.com Fri Nov 2 05:32:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D466521F8CF2 for ; Fri, 2 Nov 2012 05:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.536 X-Spam-Level: X-Spam-Status: No, score=-10.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+ne-q3Z3Qh9 for ; Fri, 2 Nov 2012 05:32:41 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4B921F8D03 for ; Fri, 2 Nov 2012 05:32:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,699,1344207600"; d="scan'208,217";a="283191528" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 02 Nov 2012 12:32:39 +0000 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qA2CWcIV002503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 12:32:38 GMT Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Fri, 2 Nov 2012 12:32:38 +0000 From: "Dearlove, Christopher (UK)" To: Jiazi YI Thread-Topic: [manet] Reactive routing protocols, what are the differences? Thread-Index: Ac24S9gO52XASJQwQb67c7wvLBVIbQAMK9OAABnHRpAAASp5gAABOJ7QAAGNRoAAADmmIA== Date: Fri, 2 Nov 2012 12:32:37 +0000 Message-ID: References: <12708D7E-C548-4858-8144-6F04D2750E02@jiaziyi.com> <4F9C6208-78B8-41B1-81D2-C7DAAE9D780D@jiaziyi.com> In-Reply-To: <4F9C6208-78B8-41B1-81D2-C7DAAE9D780D@jiaziyi.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6B93GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 12:32:44 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6B93GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I understand the basics. And I agree I can't see (except my bracketed aside= ) how to do it without a mutable field. But having that mutable field reduc= es the value of the argument against DYMO from "DYMO is mutable, LOADng is = not" to "DYMO is (uncontrolled?) mutable, LOADng is managed mutable". I'm n= ot convinced by the argument about having to mutate metric type. If you can= 't rely on it being available to your network layer protocol consistently i= n the one MANET, heterogeneous though it may be, I'm not sure you have a we= ll-put-together network. You could always make the metrioc increment when u= nknown the maximum such value. But there is, as another post raised, the larger question of what end to en= d message authentication buys you. If in a route A-B-X-C-D, where X is a ba= d guy, if X relays all RREQs and RREPs flawlessly, but throws all data pack= ets on the floor, X has done his job, and without needing to forge anything= . You also need B and/or C to authenticate X. Lower layer? (in which case w= hy can't that do the whole job?). RREP-ACK? Accumulating signature? Somethi= ng else? (Note that a link state protocol gets the B-X and X-C done. Those are, afte= r all, links.) -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI Sent: 02 November 2012 12:13 To: Dearlove, Christopher (UK) Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Clausen (thomas@thomasclau= sen.org) Subject: Re: [manet] Reactive routing protocols, what are the differences? *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Hi, The reason that LOADng needs those fields mutable is to support different m= etrics other than hop-count, even routers using different metrics in the sa= me routing domain can at least find a path. To support different metric types, a metric-type tlv and a route-metric tlv= are needed. The route-metric tlv has to be mutable because it needs to be = updated at each hop. Having metric-type tlv mutable can make supporting different metrics in the= same network possible. It's common that in a heterogenous network, there are various transmission = medias (802.11, 802.15.4, cable, PLC...), therefore possible different metr= ics. In LOADng, if a router A (with metric-A) gets an RREQ message that it doesn= 't understand (say, metric-B), router A will change the metric-type to HOP_= COUNT, and forward the message (the hop-count field is always used). For th= e destination of RREQ, it will first consider the metrics that it understan= ds, and then HOP_COUNT. Of course, this will result in "degrading" to HOP_C= OUNT for certain routes, but at least we can get a usable route. I'm just introducing the design of LOADng, and would appreciate any good id= ea on this issue. best Jiazi On Nov 2, 2012, at 12:42 PM, "Dearlove, Christopher (UK)" > wrote: Having anything other than hop limit and hop count mutable is not the secur= ity mechanism suggested in 6622/5444. I'm of the view that the current approach of securing NHDP, securing OLSRv2= etc. is not where things should ideally be, that the ideal place is at the= 5444 multiplexer wherever possible. If doing hop by hop security, then tha= t is the place, as it's where packets live. But if we could do it once for = all message types, then that's a major gain. Now as soon as LOADng has anything else mutable, that doesn't help that. OK= , it's better than nothing, but those fields are buried in TLVs (using 5444= ) and messy. I'm at a disadvantage, I haven't studied why LOADng needs those fields (oth= er than hop count) mutable - or if it really does. But it reduces "here's a= clear advantage over DYMO" to "here's a more partial advantage over DYMO".= And I think Ulrich's summary could be edited to better present this. So if we adopted my separate proposal, this would be on the menu: why are t= hose fields mutable? Do they have to be? Can we find an alternative? (Unfor= tunately, I can see why probably not. But it's still a question.) [Actually I can see an alternative, which is a much more limited metric, wh= ich takes small integer values, and we increase hop count not by one but by= this metric, limiting paths to maximum 255 metric. We could still get hop = count from hop limit if we knew how it started - e.g. in a non-mutable TLV.= But I strongly doubt this is good enough.] -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of J= iazi YI Sent: 02 November 2012 10:54 To: Dearlove, Christopher (UK) Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Cla= usen (thomas@thomasclausen.org) Subject: Re: [manet] Reactive routing protocols, what are the differences? *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Hi Chris, I think Ulrich is in deep sleep at the moment, so please allow me to have s= ome words on this. For reactive protocols, updating the route information (hop-count, metric) = is inevitable. In the specification of DYMO, the messages can be changed re= latively arbitrarily, including removing addresses from the messages. The i= ntermediate RREP also makes end-to-end security impossible. LOADng clearly defines which fields in the routing messages can't be change= d, and which fields are mutable. For example, for RREQ: The following fields of an RREQ message are immutable, i.e., they MUST NOT = be changed during processing or forwarding of the message: RREQ.addr-length= , RREQ.seq-num, RREQ.originator, and RREQ.destination. The following fields of an RREQ message are mutable, i.e., they will be cha= nged by intermediate routers during processing or forwarding, as specified = in Section 12.2 and Section 12.3: RREQ.metric-type, RREQ.route-metric, and RREQ.hop-co= unt. Any additional field that is added to the message by an extension to this p= rotocol, e.g., by way of TLVs, MUST be considered immutable, unless the ext= ension specifically defines the field as mutable. This allows the protocol to secure the messages by zeroing the mutable fiel= ds. best Jiazi (sorry to Chris if you received multiple copy of this message. I fixed one = typo though :) My previous one was bounced by manet mailing list because of= not using the right sender address) On Nov 2, 2012, at 11:22 AM, "Dearlove, Christopher (UK)" > wrote: There is, superficially at least, an apparent contradiction between your po= ints: - DYMO cannot be end-to-end secured. Messages are changed in transit (and not just hop-limit or the metric), but rather addresses can be removed from RERRs and RREQs. which implicitly suggests LOADng does not do this and - LOADng uses a Metric message TLV, and it is clearly defined how to update the metric under way. Could you expand on this please? -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Ulrich Herberg [mailto:ulrich@herberg.name] Sent: 01 November 2012 22:02 To: Dearlove, Christopher (UK) Cc: manet@ietf.org; Thomas Heide Clausen (thomas@tho= masclausen.org) Subject: Re: [manet] Reactive routing protocols, what are the differences? ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi Chris, you have seen my review on DYMO. I will try to answer to your question, and focus on the technical differences, not presentation. On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK) > wrote= : The obviously best people to answer this should be document authors, but an= yone else may have useful additions and comments. Ideally the different doc= ument authors could agree a list. (If they differ in that one has X and the= other doesn't, but one wants to say "we plan to add/remove X" then X shoul= d be listed as a difference with that caveat, in at least my ideal world.) If we set aside, for the moment (though these things matter): - The presentational quality of the documents, - Any issues of 5444 compliance and other formatting issues, - Issues of internal data organisation, - Minor details such as possible different timeout parameters etc. then what are the technical (and I stress that word) differences between DY= MO and LOADng? (I'm withholding the term AODVv2 for reasons I may come back= to.) First, let's see what is common. Both are reactive protocols, using RREQ, RREP and RERR. So if someone claims that DYMO performs great and LOADng badly in the same scenario, I cannot understand that. MANET has understood the scenarios where reactive protocols are useful and where not. Now, to the differences: - DYMO cannot be end-to-end secured. Messages are changed in transit (and not just hop-limit or the metric), but rather addresses can be removed from RERRs and RREQs. There is also no provision to allow external mechanisms to add additional reasons to reject messages as invalid. - DYMO uses the originator address in an address block, LOADng in the message header. The sequence number is a TLV value in DYMO, and LOADng uses the message sequence number. DYMO requires the originator address to be the first one in the address block, the destination must be the second one. LOADng uses a TLV to determine the target address. - DYMO can advertise multiple addresses in an RERR; they can be removed in transit of the message. - DYMO allows intermediate routers to reply (as an option). That makes end-to-end security difficult. In the core DYMO, there is a destination sequence number that may be contained in RREQs in DYMO. - DYMO allows for unicast RREQ, but does not specify in detail how to use t= hat. - There are four timers for each route entry in DYMO, only one in LOADng. - LOADng can be used on other layers; DYMO is tied to IP. - LOADng provides a bidirectionality verification using RREP_ACK, a time-out of these, a blacklisted set and a Pending Acknowledgment Set to verify bidirectional links. DYMO says that other mechanisms can be used, but does not specify these. - DYMO has several options for expanding ring RREQ, precursor list, adding route information in transit, message aggregation in RFC5444 packets and reporting multiple unreachable addresses in a RERR. LOADng takes the approach to have a slim core of a basic mechanism that is applicable in all MANET use cases, and companion documents with extensions. In DYMO, it is not clearly specified what happens if some routers support an option, and others don't. - LOADng uses a Metric message TLV, and it is clearly defined how to update the metric under way. If a router in transit does not recognize a route metric type, it is reset to a "hop count" tlv extension type of the Metric TLV and the value set to 0xFFFFF... (for the full TLV length). It is specified that security mechanism must ignore the content of the metric TLV value and that the length cannot be changed under way, so that end-to-end security is possible. DYMO uses an optional "distance" field for the metric, which is not clearly specified how it is updated. Also, since this is optional, it is unclear if routers receiving a message and forwarding it, update the distance field or not. - LOADng allows for (optionally) waiting to reply with a RREP, in case a "better" RREQ comes a little later. In DYMO, a RREP is always sent immediately. There are probably more differences, but I let other chime in. Best regards Ulrich Note that it's a lot more useful to have direct differences than difference= s of each from AODV (especially when both have the same difference). And it= would be useful to have the objective differences separated from the "and = now why this is better" discussion - though that would be a next step. I'm not saying I don't see any of the differences. But I certainly haven't = worked out the complete list. In trying to form my view of how things shoul= d go forward (a view that is coming together, and when it does, I'll argue = for it) and I hope for other people as well, it would be good to know what = the differences are. Regardless of views for or against each, we should be = able to objectively list the significant differences - if we can't then som= ething is wrong. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** 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. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6B93GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I understand the basics. = And I agree I can't see (except my bracketed aside) how to do it without a = mutable field. But having that mutable field reduces the value of the argument against DYMO from "DYMO is mutable, LOADng is n= ot" to "DYMO is (uncontrolled?) mutable, LOADng is managed mutabl= e". I'm not convinced by the argument about having to mutate metric ty= pe. If you can't rely on it being available to your network layer protocol consistently in the one MANET, heterogeneous though= it may be, I'm not sure you have a well-put-together network. You could al= ways make the metrioc increment when unknown the maximum such value.

 <= /p>

But there is, as another = post raised, the larger question of what end to end message authentication = buys you. If in a route A-B-X-C-D, where X is a bad guy, if X relays all RREQs and RREPs flawlessly, but throws all data packets on= the floor, X has done his job, and without needing to forge anything. You = also need B and/or C to authenticate X. Lower layer? (in which case why can= 't that do the whole job?). RREP-ACK? Accumulating signature? Something else?

 <= /p>

(Note that a link state p= rotocol gets the B-X and X-C done. Those are, after all, links.)=

 <= /p>

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (O= perations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 <= /p>

From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI
Sent: 02 November 2012 12:13
To: Dearlove, Christopher (UK)
Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Clausen (thomas@tho= masclausen.org)
Subject: Re: [manet] Reactive routing protocols, what are the differ= ences?

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

Hi,



The reason that LOADng needs those fields mutable is to support dif= ferent metrics other than hop-count, even routers using different metrics in the same routing domain can at least find a path. <= /span>



To support different metric types, a metric-type tlv and a route-me= tric tlv are needed. The route-metric tlv has to be mutable because it needs to be updated at each hop. =

Having metric-type tlv mutable can make supporting different metric= s in the same network possible. 



It's common that in a heterogenous network, there are various trans= mission medias (802.11, 802.15.4, cable, PLC...), therefore possible different metrics.

In LOADng, if a router A (with metric-A) gets an RREQ message that = it doesn't understand (say, metric-B), router A will change the metric-type to HOP_COUNT, and forward the message (the hop-count field= is always used). For the destination of RREQ, it will first consider the m= etrics that it understands, and then HOP_COUNT. Of course, this will result= in "degrading" to HOP_COUNT for certain routes, but at least we can get a usable route. 



I'm just introducing the design of LOADng, and would appreciate any= good idea on this issue. 



best



Jiazi

 

 

 

On Nov 2, 2012, at 12:42 PM, "Dearlove, Christo= pher (UK)" <Chris.= Dearlove@baesystems.com> wrote:



Having anything other tha= n hop limit and hop count mutable is not the security mechanism suggested i= n 6622/5444.

 <= /p>

I'm of the view that the = current approach of securing NHDP, securing OLSRv2 etc. is not where things= should ideally be, that the ideal place is at the 5444 multiplexer wherever possible. If doing hop by hop security, then that is = the place, as it's where packets live. But if we could do it once for all m= essage types, then that's a major gain.

 <= /p>

Now as soon as LOADng has= anything else mutable, that doesn't help that. OK, it's better than nothin= g, but those fields are buried in TLVs (using 5444) and messy.

 <= /p>

I'm at a disadvantage, I = haven't studied why LOADng needs those fields (other than hop count) mutabl= e - or if it really does. But it reduces "here's a clear advantage over DYMO" to "here's a more partial advantage over DY= MO". And I think Ulrich's summary could be edited to better present th= is.

 <= /p>

So if we adopted my separ= ate proposal, this would be on the menu: why are those fields mutable? Do t= hey have to be? Can we find an alternative? (Unfortunately, I can see why probably not. But it's still a question.)<= /p>

 <= /p>

[Actually I can see an al= ternative, which is a much more limited metric, which takes small integer v= alues, and we increase hop count not by one but by this metric, limiting paths to maximum 255 metric. We could still get hop count= from hop limit if we knew how it started - e.g. in a non-mutable TLV. But = I strongly doubt this is good enough.]

 <= /p>

--

Christopher Dearlove

Senior Principal Engineer= , Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124<= /o:p>

= chris.dearlove@baesystems.com | http://www.baes= ystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 <= /p>

From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiaz= i YI
Sent: 02 November = 2012 10:54
To: Dearlove, Chri= stopher (UK)
Cc: Ulrich Herberg= ; manet@ietf.org; Thomas H= eide Clausen (thomas@thomasclausen.org)
Subject: Re: [mane= t] Reactive routing protocols, what are the differences?<= /p>

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see = this process = on how to deal with suspicious emails.

Hi C= hris, 




I th= ink Ulrich is in deep sleep at the moment, so please allow me to have some = words on this. 




For = reactive protocols, updating the route information (hop-count, metric) is i= nevitable. In the specification of DYMO, the messages can be changed relatively arbitrarily, including removing addresses from the m= essages. The intermediate RREP also makes end-to-end security impossible.&n= bsp;




LOAD= ng clearly defines which fields in the routing messages can't be changed, a= nd which fields are mutable. For example, for RREQ:




The = following fields of an RREQ message are immutable, i.e., they MUST NOT be c= hanged during processing or forwarding of the message: RREQ.addr-length, RR= EQ.seq-num, RREQ.originator, and RREQ.destination.

The = following fields of an RREQ message are mutable, i.e., they will be changed= by intermediate routers during processing or forwarding, as specified in&n= bsp;Section 12.2 and Section 12.3: RREQ.metric-type, RREQ.route-metric, and RREQ.hop-count.=

Any = additional field that is added to the message by an extension to this proto= col, e.g., by way of TLVs, MUST be considered immutable, unless the extensi= on specifically defines the field as mutable.




This= allows the protocol to secure the messages by zeroing the mutable fields.&= nbsp;




best=




Jiaz= i 




(sor= ry to Chris if you received multiple copy of this message. I fixed one typo= though :) My previous one was bounced by manet mailing list because of not using the right sender address)

 

 

On Nov 2, 2012, at 11:22 AM, "Dearlove, Christo= pher (UK)" <Chris.Dearlove@baesystems.com> wrote:<= o:p>




There is, superficially at least, an apparent contra= diction between your points:

- DYMO cannot be end-to-end secured. Messages are changed in transit
(and not just hop-limit or the metric), but rather addresses can be
removed from RERRs and RREQs.

which implicitly suggests LOADng does not do this

and 

- LOADng uses a Metric message TLV, and it is clearly defined how to
update the metric under way.

Could you expand on this please?

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.b= aesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Ulrich Herberg [mailto:ulrich@herberg.name] 
Sent: 01 November 2012 22:02
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; Thomas= Heide Clausen (thomas@thomasclausen.org)
Subject: Re: [manet] Reactive routing protocols, what are the differences?<= br>
----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hi Chris,

you have seen my review on DYMO. I will try to answer to your
question, and focus on the technical differences, not presentation.


On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK)
<Chris.Dearlove@baesystems.com> wrote:


The obviously best people to answer this should be d= ocument authors, but anyone else may have useful additions and comments. Id= eally the different document authors could agree a list. (If they differ in= that one has X and the other doesn't, but one wants to say "we plan to add/remove X" then X should be = listed as a difference with that caveat, in at least my ideal world.)

If we set aside, for the moment (though these things matter):
- The presentational quality of the documents,
- Any issues of 5444 compliance and other formatting issues,
- Issues of internal data organisation,
- Minor details such as possible different timeout parameters etc.
then what are the technical (and I stress that word) differences between DY= MO and LOADng? (I'm withholding the term AODVv2 for reasons I may come back= to.)



First, let's see what is common. Both are reactive protocols, using
RREQ, RREP and RERR. So if someone claims that DYMO performs great and
LOADng badly in the same scenario, I cannot understand that. MANET has
understood the scenarios where reactive protocols are useful and where
not.

Now, to the differences:

- DYMO cannot be end-to-end secured. Messages are changed in transit
(and not just hop-limit or the metric), but rather addresses can be
removed from RERRs and RREQs. There is also no provision to allow
external mechanisms to add additional reasons to reject messages as
invalid.
- DYMO uses the originator address in an address block, LOADng in the
message header. The sequence number is a TLV value in DYMO, and LOADng
uses the message sequence number. DYMO requires the originator address
to be the first one in the address block, the destination must be the
second one. LOADng uses a TLV to determine the target address.
- DYMO can advertise multiple addresses in an RERR; they can be
removed in transit of the message.
- DYMO allows intermediate routers to reply (as an option). That makes
end-to-end security difficult. In the core DYMO, there is a
destination sequence number that may be contained in RREQs in DYMO.
- DYMO allows for unicast RREQ, but does not specify in detail how to use t= hat.
- There are four timers for each route entry in DYMO, only one in LOADng. - LOADng can be used on other layers; DYMO is tied to IP.
- LOADng provides a bidirectionality verification using RREP_ACK, a
time-out of these, a blacklisted set and a Pending Acknowledgment Set
to verify bidirectional links. DYMO says that other mechanisms can be
used, but does not specify these.
- DYMO has several options for expanding ring RREQ, precursor list,
adding route information in transit, message aggregation in RFC5444
packets and reporting multiple unreachable addresses in a RERR. LOADng
takes the approach to have a slim core of a basic mechanism that is
applicable in all MANET use cases, and companion documents with
extensions. In DYMO, it is not clearly specified what happens if some
routers support an option, and others don't.
- LOADng uses a Metric message TLV, and it is clearly defined how to
update the metric under way. If a router in transit does not recognize
a route metric type, it is reset to a "hop count" tlv extension t= ype
of the Metric TLV and the value set to 0xFFFFF... (for the full TLV
length). It is specified that security mechanism must ignore the
content of the metric TLV value and that the length cannot be changed
under way, so that end-to-end security is possible. DYMO uses an
optional "distance" field for the metric, which is not clearly specified how it is updated. Also, since this is optional, it is
unclear if routers receiving a message and forwarding it, update the
distance field or not.
- LOADng allows for (optionally) waiting to reply with a RREP, in case
a "better" RREQ comes a little later. In DYMO, a RREP is always s= ent
immediately.

There are probably more differences, but I let other chime in.

Best regards
Ulrich




Note that it's a lot more useful to have direct diff= erences than differences of each from AODV (especially when both have the s= ame difference). And it would be useful to have the objective differences s= eparated from the "and now why this is better" discussion - though that would be a next step.

I'm not saying I don't see any of the differences. But I certainly haven't = worked out the complete list. In trying to form my view of how things shoul= d go forward (a view that is coming together, and when it does, I'll argue = for it) and I hope for other people as well, it would be good to know what the differences are. Regardless of = views for or against each, we should be able to objectively list the signif= icant differences - if we can't then something is wrong.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.b= aesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687



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

_______________________________________________
manet mailing list
manet@ietf.o= rg
https://www.ietf.or= g/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.o= rg
https://www.ietf.or= g/mailman/listinfo/manet

 

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6B93GLKXM0002VGREEN_-- From Chris.Dearlove@baesystems.com Fri Nov 2 05:35:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9CD21F873C for ; Fri, 2 Nov 2012 05:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+Qats7R0wkN for ; Fri, 2 Nov 2012 05:35:54 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id DAF3521F85ED for ; Fri, 2 Nov 2012 05:35:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,699,1344207600"; d="scan'208";a="240506239" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 02 Nov 2012 12:35:53 +0000 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qA2CZq8E022286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 12:35:52 GMT Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Fri, 2 Nov 2012 12:35:52 +0000 From: "Dearlove, Christopher (UK)" To: Teco Boot Thread-Topic: [manet] A proposal - differentiating the document and the protocol Thread-Index: Ac2462GvrkEbwPwlSeKUcYpBS5JqPAABttmAAAAZg7AAAMlJgAAAH7cA Date: Fri, 2 Nov 2012 12:35:52 +0000 Message-ID: References: <3C7A4DA4-92ED-42CF-A999-64724F469B56@inf-net.nl> In-Reply-To: <3C7A4DA4-92ED-42CF-A999-64724F469B56@inf-net.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 12:35:55 -0000 I just wanted to point out I'm familiar with the LOADng style. But that is = not why I say it is a superior presentation, or why I say it's a better sta= rting point - even for DYMO. I've got a lot of ink on a paper copy of dymo-= 23 that convinced me of that. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: 02 November 2012 12:30 To: Dearlove, Christopher (UK) Cc: manet@ietf.org Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- (document track: the history of ietf-manet-dymo). I suggested in my posting, dd 16 oktober, to use draft-ietf-manet-dymo-23 a= s placeholder for an updated text coming from the LOADng corner. I expected= more that just s/LLN/MANET/. And I expected some cooperation. I still do. There is nothing wrong to have the same document format for both our core p= rotocols. In the contrary ! Teco=20 Op 2 nov. 2012, om 13:11 heeft Dearlove, Christopher (UK) het volgende gesc= hreven: > As I said, I think the LOADng document will be much easier to adapt. >=20 > Two comments there. First, it's odd reading that document, which I'm not = an author of, as large amounts feel like I did write them. That is of cours= e because it borrows the style of OLSRv2/NHDP, in turn adopted from (but im= proved on) that on RFC 3626. >=20 > Second, is that a good style? Well, I would refer you to Barry Leiba's co= mments on OLSRv2 in the ID tracker as it goes through the IESG. It even got= a YES (not just a no objection) from him on that account. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: 02 November 2012 12:05 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org > Subject: Re: [manet] A proposal - differentiating the document and the pr= otocol >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > This is more or less what I suggested before, perhaps not as clearly as C= hris. I suggested to use the manet-dymo document track. We don't have to, b= ut I do not see any argument for renaming. >=20 > But first, let's get in a cooperative mode. I kindly ask al to cool down = a bit. Seen the energy on this list, my conclusion is that we all want a gr= eat reactive MANET protocol as proposed standard. >=20 > Teco >=20 >=20 > Op 2 nov. 2012, om 12:16 heeft Dearlove, Christopher (UK) het volgende ge= schreven: >=20 >> Before making a proposal, I'm going to introduce a distinction here betw= een the DYMO and LOADng documents and protocols. >>=20 >> I'm of the opinion that the LOADng document is a greatly superior presen= tation to the DYMO document. (I'm not really interested in why that has com= e about.) >>=20 >> I think that regardless of whether one makes design decisions favouring = DYMO or LOADng where they differ - and let's not forget they overlap a lot = - it would actually be easier to modify the LOADng document to specify DYMO= than it would be to modify the DYMO document to achieve that. And in pract= ice I think if making decisions it is unlikely that all would favour DYMO o= ver LOADng. >>=20 >> So what I think would be best for the WG is not a simply "option 1" or e= ven (as it may appear I'm suggesting, but I'm not) "option 2" but rather t= o agree to take the LOADng document, and a list of where DYMO and LOADng di= ffer, and thrash out where they do, what the WG reactive protocol should do= - either as a definite choice, or as an option (but not too many options p= lease- and some could be separate specifications). >>=20 >> This would not of course be LOADng, so we'd have to change the document = name. And there I suggest we have a candidate name - AODVv2. (Which is why = I have recently taken to saying DYMO when referring to that document.) Afte= r all, the one thing we are agreed on is that the protocol being developed = is derived from AODV. >>=20 >> The editors of this new document would have to agree that what goes in i= t is WG consensus (which should follow proper technical consideration of th= e issues). If they found it impossible to have other than their way to do t= hings, they'd have to move on. If that left no one editing it, obviously we= don't have a consensus of people prepared to do the work and option 3 woul= d win. >>=20 >> So now I'm partly off the fence I've been sitting on. But only partly. I= haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standa= rd, IRREPs as an option in the main draft, IRREPs as a separate draft optio= n, no IRREPs. I'd like to move on to those discussions. >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >>=20 >> ******************************************************************** >> 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. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 From abdussalambaryun@gmail.com Fri Nov 2 05:43:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CCD21F85FD for ; Fri, 2 Nov 2012 05:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGgLBvmF4EwR for ; Fri, 2 Nov 2012 05:43:54 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4490821F87B0 for ; Fri, 2 Nov 2012 05:43:38 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4150449vcb.31 for ; Fri, 02 Nov 2012 05:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7CUUpr5hZnilDmCRKaI9f5cC5I2Jx131/LABjeeHstA=; b=JbofEzlLvJv4YSa8Qp0JYIinu4I4rFvJO3swaYR5AZi16492N9k5LdGbnWcPJq5K40 glvFe1eanUm1tY9xvi07q7I5SuU9tiQtFpL8hV8jrexgDkhPHTtVoe54PZFKqSzq0bzs AFBh4wQCSJTl3N9H9rYJOS1uROAyw2PwWWVZCcOHzQgkDccfLmOaE1g6KQcY1PqDDPeK fcRXhrmNZsQzCS62s9/oeMBCXls3N0j5wvTX8ZqiZq+Jcr9jZ6VNzuqVbOSN1qSlFkj7 jPiqDaTxt0jBkLPz9i1oq5eWbza8u7yuviSqvG98251vqB2B4q8/qaTXVBRtJHkYeQhK +w0A== MIME-Version: 1.0 Received: by 10.52.33.165 with SMTP id s5mr1470324vdi.55.1351860217219; Fri, 02 Nov 2012 05:43:37 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 2 Nov 2012 05:43:37 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 Nov 2012 12:43:37 +0000 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: multipart/alternative; boundary=20cf3079bc70088b8504cd827c82 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 12:43:56 -0000 --20cf3079bc70088b8504cd827c82 Content-Type: text/plain; charset=ISO-8859-1 We always SHOULD be in cooperative mode with our WG drafts and avoid interrupts from other drafts AB On Fri, Nov 2, 2012 at 12:04 PM, Teco Boot wrote: > This is more or less what I suggested before, perhaps not as clearly as > Chris. I suggested to use the manet-dymo document track. We don't have to, > but I do not see any argument for renaming. > > But first, let's get in a cooperative mode. I kindly ask al to cool down a > bit. Seen the energy on this list, my conclusion is that we all want a > great reactive MANET protocol as proposed standard. > > Teco > > > Op 2 nov. 2012, om 12:16 heeft Dearlove, Christopher (UK) het volgende > geschreven: > > > Before making a proposal, I'm going to introduce a distinction here > between the DYMO and LOADng documents and protocols. > > > > I'm of the opinion that the LOADng document is a greatly superior > presentation to the DYMO document. (I'm not really interested in why that > has come about.) > > > > I think that regardless of whether one makes design decisions favouring > DYMO or LOADng where they differ - and let's not forget they overlap a lot > - it would actually be easier to modify the LOADng document to specify DYMO > than it would be to modify the DYMO document to achieve that. And in > practice I think if making decisions it is unlikely that all would favour > DYMO over LOADng. > > > > So what I think would be best for the WG is not a simply "option 1" or > even (as it may appear I'm suggesting, but I'm not) "option 2" but rather > to agree to take the LOADng document, and a list of where DYMO and LOADng > differ, and thrash out where they do, what the WG reactive protocol should > do - either as a definite choice, or as an option (but not too many options > please- and some could be separate specifications). > > > > This would not of course be LOADng, so we'd have to change the document > name. And there I suggest we have a candidate name - AODVv2. (Which is why > I have recently taken to saying DYMO when referring to that document.) > After all, the one thing we are agreed on is that the protocol being > developed is derived from AODV. > > > > The editors of this new document would have to agree that what goes in > it is WG consensus (which should follow proper technical consideration of > the issues). If they found it impossible to have other than their way to do > things, they'd have to move on. If that left no one editing it, obviously > we don't have a consensus of people prepared to do the work and option 3 > would win. > > > > So now I'm partly off the fence I've been sitting on. But only partly. I > haven't yet formed a view on e.g. should this AODVv2 have IRREPs as > standard, IRREPs as an option in the main draft, IRREPs as a separate draft > option, no IRREPs. I'd like to move on to those discussions. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > > > ******************************************************************** > > 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. > > ******************************************************************** > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf3079bc70088b8504cd827c82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We always SHOULD be in cooperative mode with our WG drafts and avoid i= nterrupts from other drafts
=A0
AB

On Fri, Nov 2, 2012 at 12:04 PM, Teco Boot <teco@= inf-net.nl> wrote:
This is more or less what I suggested= before, perhaps not as clearly as Chris. I suggested to use the manet-dymo= document track. We don't have to, but I do not see any argument for re= naming.

But first, let's get in a cooperative mode. I kindly ask al to cool= down a bit. Seen the energy on this list, my conclusion is that we all wan= t a great reactive MANET protocol as proposed standard.

Teco


Op 2 nov. 2012, om 12:16 heeft Dearlove, Christopher (UK) het volge= nde geschreven:

> Before making a proposal, I'm going to intro= duce a distinction here between the DYMO and LOADng documents and protocols= .
>
> I'm of the opinion that the LOADng document is a grea= tly superior presentation to the DYMO document. (I'm not really interes= ted in why that has come about.)
>
> I think that regardless of whether one makes design decisions = favouring DYMO or LOADng where they differ - and let's not forget they = overlap a lot - it would actually be easier to modify the LOADng document t= o specify DYMO than it would be to modify the DYMO document to achieve that= . And in practice I think if making decisions it is unlikely that all would= favour DYMO over LOADng.
>
> So what I think would be best for the WG is not a simply "= ;option 1" or even (as it may appear I'm suggesting, but =A0I'= m not) "option 2" but rather to agree to take the LOADng document= , and a list of where DYMO and LOADng differ, and thrash out where they do,= what the WG reactive protocol should do - either as a definite choice, or = as an option (but not too many options please- and some could be separate s= pecifications).
>
> This would not of course be LOADng, so we'd have to change= the document name. And there I suggest we have a candidate name - AODVv2. = (Which is why I have recently taken to saying DYMO when referring to that d= ocument.) After all, the one thing we are agreed on is that the protocol be= ing developed is derived from AODV.
>
> The editors of this new document would have to agree that what= goes in it is WG consensus (which should follow proper technical considera= tion of the issues). If they found it impossible to have other than their w= ay to do things, they'd have to move on. If that left no one editing it= , obviously we don't have a consensus of people prepared to do the work= and option 3 would win.
>
> So now I'm partly off the fence I've been sitting on. = But only partly. I haven't yet formed a view on e.g. should this AODVv2= have IRREPs as standard, IRREPs as an option in the main draft, IRREPs as = a separate draft option, no IRREPs. I'd like to move on to those discus= sions.
>
> --
> Christopher Dearlove
> Senior Principal Engin= eer, Communications Group
> Communications, Networks and Image Analys= is Capability
> BAE Systems Advanced Technology Centre
> West H= anningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44= 1245 242194 | =A0Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Wa= rwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, G= U14 6YU, UK
> Registered in England & Wales No: 1996687
> >
>
> ******************************************************= **************
> This email and any attachments are confidential to t= he intended
> recipient and may also be privileged. If you are not th= e 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
&g= t; distribute its contents to any other person.
> *******************= *************************************************
>
> _______________________________________________
> manet = mailing list
> manet@ietf.org> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing listmanet@ietf.org
https://www.ietf.o= rg/mailman/listinfo/manet

--20cf3079bc70088b8504cd827c82-- From abdussalambaryun@gmail.com Fri Nov 2 05:52:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A1321F8581 for ; Fri, 2 Nov 2012 05:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.43 X-Spam-Level: X-Spam-Status: No, score=-3.43 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id da2DKdkBXDBj for ; Fri, 2 Nov 2012 05:52:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1DE21F84E4 for ; Fri, 2 Nov 2012 05:52:29 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4196363vbb.31 for ; Fri, 02 Nov 2012 05:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yhXeLMwrDNzg5NNhroJ46D4wXBGnA04pnOyY5rgVtXk=; b=Pu2fz3o52nRVMjFLjHLxzTE7RQHOa4kdEJOfxmNDXQT4vekA83W5WQvsIPPegn/ik0 2hMDwCTjn41tUifPl7+vQ0dBDh4XTNmbs1rPjM3sPqk8xmMezrUZq+5d/5XTGYOWKovO OWs/DXfl0oHmVqp7X9HQNVeHAA7iRlHdIsB6Z/nU1cKmzf108Ixzy7aagzB3TWFA+2Nv g1lUBqDoD9Rm9LfUBjx4PGdOOVOhSPKG5vrz5d7PlG/vUDVkHTCcJba5Z0m+LXwtxz7R +L3ErGZZTvkx9ptJ+UOqPd8FWq2PQwcJ8i0MMyxM9I1hwU9BE+S7LrrokbfjnJFhhyOc 8oOQ== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr1526651vdv.20.1351860749343; Fri, 02 Nov 2012 05:52:29 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 2 Nov 2012 05:52:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 Nov 2012 12:52:29 +0000 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=bcaec50162bdc019f204cd829b75 Cc: "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 12:52:32 -0000 --bcaec50162bdc019f204cd829b75 Content-Type: text/plain; charset=ISO-8859-1 Hi Chris, I always thought that LOADng is different than AODVv2 in deployments but similar in documentations, that is why the LOADng document SHOULD be modified, it should represent the real deployment specification and applicability. Usually it is required by the IETF that all standard protocol document present a section for *Applicability*, I think this will be the main difference between DYMO/AODVv2 and LOADng documents. I don't like to take sides for our assigned work flow, because in the end we are working for the WG progress works (DYMO not LOADng docs). I will provide my review on differences without showing advantages/disadvantages, because in the end we want all a reactive protocol to become standard as soon as possible without delays. Abdussalam Baryun University of Glamorgan, UK On Fri, Nov 2, 2012 at 11:16 AM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > Before making a proposal, I'm going to introduce a distinction here > between the DYMO and LOADng documents and protocols. > > I'm of the opinion that the LOADng document is a greatly superior > presentation to the DYMO document. (I'm not really interested in why that > has come about.) > > I think that regardless of whether one makes design decisions favouring > DYMO or LOADng where they differ - and let's not forget they overlap a lot > - it would actually be easier to modify the LOADng document to specify DYMO > than it would be to modify the DYMO document to achieve that. And in > practice I think if making decisions it is unlikely that all would favour > DYMO over LOADng. > > So what I think would be best for the WG is not a simply "option 1" or > even (as it may appear I'm suggesting, but I'm not) "option 2" but rather > to agree to take the LOADng document, and a list of where DYMO and LOADng > differ, and thrash out where they do, what the WG reactive protocol should > do - either as a definite choice, or as an option (but not too many options > please- and some could be separate specifications). > > This would not of course be LOADng, so we'd have to change the document > name. And there I suggest we have a candidate name - AODVv2. (Which is why > I have recently taken to saying DYMO when referring to that document.) > After all, the one thing we are agreed on is that the protocol being > developed is derived from AODV. > > The editors of this new document would have to agree that what goes in it > is WG consensus (which should follow proper technical consideration of the > issues). If they found it impossible to have other than their way to do > things, they'd have to move on. If that left no one editing it, obviously > we don't have a consensus of people prepared to do the work and option 3 > would win. > > So now I'm partly off the fence I've been sitting on. But only partly. I > haven't yet formed a view on e.g. should this AODVv2 have IRREPs as > standard, IRREPs as an option in the main draft, IRREPs as a separate draft > option, no IRREPs. I'd like to move on to those discussions. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > ******************************************************************** > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --bcaec50162bdc019f204cd829b75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Chris,
=A0
I always thought that LOADng is different than AODVv2 in deployments b= ut similar in documentations, that is why the LOADng document SHOULD be mod= ified, it should represent the real deployment specification and applicabil= ity. Usually it is required by the IETF that all standard protocol document= present a section for *Applicability*, I think this will be the main diffe= rence between DYMO/AODVv2 and LOADng documents. I don't like to take si= des for our assigned work flow, because in the end we are working for the W= G progress works (DYMO not LOADng docs).
=A0
I will provide my review on differences without showing advantages/dis= advantages, because in the end we want all a reactive protocol to become st= andard as soon as possible without delays.
=A0
Abdussalam Baryun
University of Glamorgan, UK


=A0
On Fri, Nov 2, 2012 at 11:16 AM, Dearlove, Chris= topher (UK) <Chris.Dearlove@baesystems.com> wrot= e:
Before making a proposal, I'm goi= ng to introduce a distinction here between the DYMO and LOADng documents an= d protocols.

I'm of the opinion that the LOADng document is a greatly superior p= resentation to the DYMO document. (I'm not really interested in why tha= t has come about.)

I think that regardless of whether one makes desi= gn decisions favouring DYMO or LOADng where they differ - and let's not= forget they overlap a lot - it would actually be easier to modify the LOAD= ng document to specify DYMO than it would be to modify the DYMO document to= achieve that. And in practice I think if making decisions it is unlikely t= hat all would favour DYMO over LOADng.

So what I think would be best for the WG is not a simply "option 1= " or even (as it may appear I'm suggesting, but =A0I'm not) &q= uot;option 2" but rather to agree to take the LOADng document, and a l= ist of where DYMO and LOADng differ, and thrash out where they do, what the= WG reactive protocol should do - either as a definite choice, or as an opt= ion (but not too many options please- and some could be separate specificat= ions).

This would not of course be LOADng, so we'd have to change the docu= ment name. And there I suggest we have a candidate name - AODVv2. (Which is= why I have recently taken to saying DYMO when referring to that document.)= After all, the one thing we are agreed on is that the protocol being devel= oped is derived from AODV.

The editors of this new document would have to agree that what goes in = it is WG consensus (which should follow proper technical consideration of t= he issues). If they found it impossible to have other than their way to do = things, they'd have to move on. If that left no one editing it, obvious= ly we don't have a consensus of people prepared to do the work and opti= on 3 would win.

So now I'm partly off the fence I've been sitting on. But only = partly. I haven't yet formed a view on e.g. should this AODVv2 have IRR= EPs as standard, IRREPs as an option in the main draft, IRREPs as a separat= e draft option, no IRREPs. I'd like to move on to those discussions.
--
Christopher Dearlove
Senior Principal Engineer, Communications= Group
Communications, Networks and Image Analysis Capability
BAE Sys= tems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Ch= elmsford, CM2 8HN, UK
Tel: +44 1245= 242194=A0| =A0Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, P= O Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UKRegistered in England & Wales No: 1996687



*************= *******************************************************
This email and any attachments are confidential to the intended
recipien= t and may also be privileged. If you are not the intended
recipient plea= se 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.
***************************= *****************************************

__________________________= _____________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--bcaec50162bdc019f204cd829b75-- From abdussalambaryun@gmail.com Fri Nov 2 05:57:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F9C21F8952 for ; Fri, 2 Nov 2012 05:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xx6hQV0d1tWX for ; Fri, 2 Nov 2012 05:56:58 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A357421F895A for ; Fri, 2 Nov 2012 05:56:58 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4163961vcb.31 for ; Fri, 02 Nov 2012 05:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PJUKLJJTnUQPi6NpgQZyA3mZ3QZNkIf37VoTcH73DFs=; b=IreWBhlobInGdcn6kX5hRcsR5e4OLL2col1BkdkzhvFOPHfOxivz2GF4rasbOT6AzM uBJeud7ket67zGNPv03R8gtmeIUmPZ83WHhQNkoROFcBTgw61QEN4FjfxoN3SP8qGkCj 513myNHR56PA3f47dSBsohUcgKpFQkHSXz8ToXObmyLIbMf0iVXxNXc+kSiURlBJ98Dk 3l5VEC681jcUIAlRLIVwv1pG+O+YrAoY0l2nMUmU2/GJq99xJvxaIJNzYZi+W4tJOHbT imhgeDK1BJfwLAzcDkvLoN2h4EdypWumHbdYeeXtN31dnnP/XCs4Pznr6g5KEcRbA7jK pFnA== MIME-Version: 1.0 Received: by 10.220.142.8 with SMTP id o8mr1725779vcu.23.1351861018053; Fri, 02 Nov 2012 05:56:58 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 2 Nov 2012 05:56:57 -0700 (PDT) In-Reply-To: <3C7A4DA4-92ED-42CF-A999-64724F469B56@inf-net.nl> References: <3C7A4DA4-92ED-42CF-A999-64724F469B56@inf-net.nl> Date: Fri, 2 Nov 2012 12:56:57 +0000 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: multipart/alternative; boundary=f46d043890b9c44bef04cd82abcc Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 12:57:00 -0000 --f46d043890b9c44bef04cd82abcc Content-Type: text/plain; charset=ISO-8859-1 I have no objection for your recommend process for the dymo work flow, as long as we don't change the I-D's abstract and aim. AB On Fri, Nov 2, 2012 at 12:30 PM, Teco Boot wrote: > (document track: the history of ietf-manet-dymo). > I suggested in my posting, dd 16 oktober, to use draft-ietf-manet-dymo-23 > as placeholder for an updated text coming from the LOADng corner. I > expected more that just s/LLN/MANET/. And I expected some cooperation. I > still do. > > There is nothing wrong to have the same document format for both our core > protocols. In the contrary ! > > Teco > > > Op 2 nov. 2012, om 13:11 heeft Dearlove, Christopher (UK) het volgende > geschreven: > > > As I said, I think the LOADng document will be much easier to adapt. > > > > Two comments there. First, it's odd reading that document, which I'm not > an author of, as large amounts feel like I did write them. That is of > course because it borrows the style of OLSRv2/NHDP, in turn adopted from > (but improved on) that on RFC 3626. > > > > Second, is that a good style? Well, I would refer you to Barry Leiba's > comments on OLSRv2 in the ID tracker as it goes through the IESG. It even > got a YES (not just a no objection) from him on that account. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > -----Original Message----- > > From: Teco Boot [mailto:teco@inf-net.nl] > > Sent: 02 November 2012 12:05 > > To: Dearlove, Christopher (UK) > > Cc: manet@ietf.org > > Subject: Re: [manet] A proposal - differentiating the document and the > protocol > > > > ----------------------! WARNING ! ---------------------- > > This message originates from outside our organisation, > > either from an external partner or from the internet. > > Keep this in mind if you answer this message. > > Follow the 'Report Suspicious Emails' link on IT matters > > for instructions on reporting suspicious email messages. > > -------------------------------------------------------- > > > > This is more or less what I suggested before, perhaps not as clearly as > Chris. I suggested to use the manet-dymo document track. We don't have to, > but I do not see any argument for renaming. > > > > But first, let's get in a cooperative mode. I kindly ask al to cool down > a bit. Seen the energy on this list, my conclusion is that we all want a > great reactive MANET protocol as proposed standard. > > > > Teco > > > > > > Op 2 nov. 2012, om 12:16 heeft Dearlove, Christopher (UK) het volgende > geschreven: > > > >> Before making a proposal, I'm going to introduce a distinction here > between the DYMO and LOADng documents and protocols. > >> > >> I'm of the opinion that the LOADng document is a greatly superior > presentation to the DYMO document. (I'm not really interested in why that > has come about.) > >> > >> I think that regardless of whether one makes design decisions favouring > DYMO or LOADng where they differ - and let's not forget they overlap a lot > - it would actually be easier to modify the LOADng document to specify DYMO > than it would be to modify the DYMO document to achieve that. And in > practice I think if making decisions it is unlikely that all would favour > DYMO over LOADng. > >> > >> So what I think would be best for the WG is not a simply "option 1" or > even (as it may appear I'm suggesting, but I'm not) "option 2" but rather > to agree to take the LOADng document, and a list of where DYMO and LOADng > differ, and thrash out where they do, what the WG reactive protocol should > do - either as a definite choice, or as an option (but not too many options > please- and some could be separate specifications). > >> > >> This would not of course be LOADng, so we'd have to change the document > name. And there I suggest we have a candidate name - AODVv2. (Which is why > I have recently taken to saying DYMO when referring to that document.) > After all, the one thing we are agreed on is that the protocol being > developed is derived from AODV. > >> > >> The editors of this new document would have to agree that what goes in > it is WG consensus (which should follow proper technical consideration of > the issues). If they found it impossible to have other than their way to do > things, they'd have to move on. If that left no one editing it, obviously > we don't have a consensus of people prepared to do the work and option 3 > would win. > >> > >> So now I'm partly off the fence I've been sitting on. But only partly. > I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as > standard, IRREPs as an option in the main draft, IRREPs as a separate draft > option, no IRREPs. I'd like to move on to those discussions. > >> > >> -- > >> Christopher Dearlove > >> Senior Principal Engineer, Communications Group > >> Communications, Networks and Image Analysis Capability > >> BAE Systems Advanced Technology Centre > >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > >> Tel: +44 1245 242194 | Fax: +44 1245 242124 > >> chris.dearlove@baesystems.com | http://www.baesystems.com > >> > >> BAE Systems (Operations) Limited > >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > >> Registered in England & Wales No: 1996687 > >> > >> > >> > >> ******************************************************************** > >> 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. > >> ******************************************************************** > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --f46d043890b9c44bef04cd82abcc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have no objection for your recommend process for the dymo work flow,= as long as we don't change the I-D's abstract and aim.
=A0
AB

On Fri, Nov 2, 2012 at 12:30 PM, Teco Boot <teco@= inf-net.nl> wrote:
(document track: the history of ietf-= manet-dymo).
I suggested in my posting, dd 16 oktober, to use draft-ietf= -manet-dymo-23 as placeholder for an updated text coming from the LOADng co= rner. I expected more that just s/LLN/MANET/. And I expected some cooperati= on. I still do.

There is nothing wrong to have the same document format for both our co= re protocols. In the contrary !

Teco


Op 2 nov. 2012, om 1= 3:11 heeft Dearlove, Christopher (UK) het volgende geschreven:

> As I said, I think the LOADng document will be m= uch easier to adapt.
>
> Two comments there. First, it's od= d reading that document, which I'm not an author of, as large amounts f= eel like I did write them. That is of course because it borrows the style o= f OLSRv2/NHDP, in turn adopted from (but improved on) that on RFC 3626.
>
> Second, is that a good style? Well, I would refer you to Barry= Leiba's comments on OLSRv2 in the ID tracker as it goes through the IE= SG. It even got a YES (not just a no objection) =A0from him on that account= .
>
> --
> Christopher Dearlove
> Senior Principal Engin= eer, Communications Group
> Communications, Networks and Image Analys= is Capability
> BAE Systems Advanced Technology Centre
> West H= anningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44= 1245 242194 | =A0Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Wa= rwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, G= U14 6YU, UK
> Registered in England & Wales No: 1996687
> >
> -----Original Message-----
> From: Teco Boot [mailto:teco@inf-net.nl]
> Sent: 02 Novem= ber 2012 12:05
> To: Dearlove, Christopher (UK)
> Cc: manet@ietf.org
> Subject: Re: [manet] A proposal - differentiating the document and the= protocol
>
> ----------------------! WARNING ! ---------------= -------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep thi= s in mind if you answer this message.
> Follow the 'Report Suspic= ious Emails' link on IT matters
> for instructions on reporting s= uspicious email messages.
> --------------------------------------------------------
>
&g= t; This is more or less what I suggested before, perhaps not as clearly as = Chris. I suggested to use the manet-dymo document track. We don't have = to, but I do not see any argument for renaming.
>
> But first, let's get in a cooperative mode. I kindly ask a= l to cool down a bit. Seen the energy on this list, my conclusion is that w= e all want a great reactive MANET protocol as proposed standard.
> > Teco
>
>
> Op 2 nov. 2012, om 12:16 heeft Dearlove, = Christopher (UK) het volgende geschreven:
>
>> Before making= a proposal, I'm going to introduce a distinction here between the DYMO= and LOADng documents and protocols.
>>
>> I'm of the opinion that the LOADng document is a g= reatly superior presentation to the DYMO document. (I'm not really inte= rested in why that has come about.)
>>
>> I think that re= gardless of whether one makes design decisions favouring DYMO or LOADng whe= re they differ - and let's not forget they overlap a lot - it would act= ually be easier to modify the LOADng document to specify DYMO than it would= be to modify the DYMO document to achieve that. And in practice I think if= making decisions it is unlikely that all would favour DYMO over LOADng. >>
>> So what I think would be best for the WG is not a simp= ly "option 1" or even (as it may appear I'm suggesting, but = =A0I'm not) "option 2" but rather to agree to take the LOADng= document, and a list of where DYMO and LOADng differ, and thrash out where= they do, what the WG reactive protocol should do - either as a definite ch= oice, or as an option (but not too many options please- and some could be s= eparate specifications).
>>
>> This would not of course be LOADng, so we'd have t= o change the document name. And there I suggest we have a candidate name - = AODVv2. (Which is why I have recently taken to saying DYMO when referring t= o that document.) After all, the one thing we are agreed on is that the pro= tocol being developed is derived from AODV.
>>
>> The editors of this new document would have to agree t= hat what goes in it is WG consensus (which should follow proper technical c= onsideration of the issues). If they found it impossible to have other than= their way to do things, they'd have to move on. If that left no one ed= iting it, obviously we don't have a consensus of people prepared to do = the work and option 3 would win.
>>
>> So now I'm partly off the fence I've been sitt= ing on. But only partly. I haven't yet formed a view on e.g. should thi= s AODVv2 have IRREPs as standard, IRREPs as an option in the main draft, IR= REPs as a separate draft option, no IRREPs. I'd like to move on to thos= e discussions.
>>
>> --
>> Christopher Dearlove
>> Senior= Principal Engineer, Communications Group
>> Communications, Netwo= rks and Image Analysis Capability
>> BAE Systems Advanced Technolo= gy Centre
>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
&= gt;> Tel: +44 1245 242194 | =A0Fax: +44 1245 242124
>> chris.dearlove@baesystems.com= | http://www.baes= ystems.com
>>
>> BAE Systems (Operations) Limited
>> Registere= d Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborou= gh, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1= 996687
>>
>>
>>
>> ******************************= **************************************
>> This email and any attac= hments 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.
>> ***= *****************************************************************
>>
>> _______________________________________________
>= ;> manet mailing list
>> mane= t@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet >
>

_______________________________________________
mane= t mailing list
manet@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/manet" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/manet

--f46d043890b9c44bef04cd82abcc-- From teco@inf-net.nl Fri Nov 2 06:00:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411CF21F8A00 for ; Fri, 2 Nov 2012 06:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgsZ4aGmepnv for ; Fri, 2 Nov 2012 06:00:30 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A83B21F89E8 for ; Fri, 2 Nov 2012 06:00:30 -0700 (PDT) Received: by mail-gh0-f172.google.com with SMTP id g10so678716ghb.31 for ; Fri, 02 Nov 2012 06:00:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=nsaySvcCgskBLTM/YI/FW+/N+8eQrBO0mO/8wCWR+Rk=; b=Tn1Quqb1+6+Fyr8IPcyThg9XImPnSdysF4QFOwLBo7FO+Mw0yPNHwDGJe0ngfZWGsj krDJA4jrBDajT7NcLZ/EVabPJQMbst7P7k/rOFenfJG99Uw6YTlZA3KYYnO0StvQwGSt vDcC1nHCycUQQVuOVpZ3Srxwg03vefRXndsL8YW7Nsowkl1IayIYVBxxUp2RM9ngdXBk NiRPwR6sOvoWDwus8ADLyy9tu5CFa4n7wNcgZXudG/1x76uV4goHHQTCPmoqUwtLLrLB N8EBpURGLDbN4RD2bWpSI17h+lpCqcK6I0ghuIn48K7cLlfFgnh8bGNpWPjCXfhKtkHR 5SBQ== Received: by 10.236.87.208 with SMTP id y56mr1610956yhe.9.1351861229905; Fri, 02 Nov 2012 06:00:29 -0700 (PDT) Received: from [10.71.3.32] (173-15-223-105-BusName-Atlanta.hfc.comcastbusiness.net. [173.15.223.105]) by mx.google.com with ESMTPS id s21sm9546886yhb.5.2012.11.02.06.00.27 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 06:00:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_6B5137B2-C5F9-4EC2-A935-E42DE1C6BBA0" From: Teco Boot In-Reply-To: Date: Fri, 2 Nov 2012 14:00:28 +0100 Message-Id: References: <12708D7E-C548-4858-8144-6F04D2750E02@jiaziyi.com> <4F9C6208-78B8-41B1-81D2-C7DAAE9D780D@jiaziyi.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkstUaWvZlk6fhutZt9t3qMk4ZDmDHLrFF/ZTId0UzpLUSVrO4Skk4VZhKCdqD7dMVnq9xo Cc: "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 13:00:33 -0000 --Apple-Mail=_6B5137B2-C5F9-4EC2-A935-E42DE1C6BBA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Op 2 nov. 2012, om 13:32 heeft Dearlove, Christopher (UK) het volgende = geschreven: > I understand the basics. And I agree I can't see (except my bracketed = aside) how to do it without a mutable field. But having that mutable = field reduces the value of the argument against DYMO from "DYMO is = mutable, LOADng is not" to "DYMO is (uncontrolled?) mutable, LOADng is = managed mutable". I'm not convinced by the argument about having to = mutate metric type. If you can't rely on it being available to your = network layer protocol consistently in the one MANET, heterogeneous = though it may be, I'm not sure you have a well-put-together network. You = could always make the metrioc increment when unknown the maximum such = value. > =20 > But there is, as another post raised, the larger question of what end = to end message authentication buys you. If in a route A-B-X-C-D, where X = is a bad guy, if X relays all RREQs and RREPs flawlessly, but throws all = data packets on the floor, X has done his job, and without needing to = forge anything. You also need B and/or C to authenticate X. Lower layer? = (in which case why can't that do the whole job?). There could be 2nd order nodes: hosts. Or the routing protocol security = mechanism is implemented in the routing deamon, which is very similar to = the first. > RREP-ACK? Accumulating signature? Something else? > =20 > (Note that a link state protocol gets the B-X and X-C done. Those are, = after all, links.) There can be malicious routers with link state protocols too.=20 Also, there is a requirement that all routers share the same policy on = what to do with failed authentication, and result of checking must be = the same on all nodes. Not easy to deploy. And missing in olsrv2 core = protocol. Teco > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI > Sent: 02 November 2012 12:13 > To: Dearlove, Christopher (UK) > Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Clausen = (thomas@thomasclausen.org) > Subject: Re: [manet] Reactive routing protocols, what are the = differences? > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an = external partner or the internet. > Keep this in mind if you answer this message. > Please see this process on how to deal with suspicious emails. >=20 > Hi, >=20 >=20 > The reason that LOADng needs those fields mutable is to support = different metrics other than hop-count, even routers using different = metrics in the same routing domain can at least find a path.=20 >=20 >=20 > To support different metric types, a metric-type tlv and a = route-metric tlv are needed. The route-metric tlv has to be mutable = because it needs to be updated at each hop.=20 > Having metric-type tlv mutable can make supporting different metrics = in the same network possible.=20 >=20 >=20 > It's common that in a heterogenous network, there are various = transmission medias (802.11, 802.15.4, cable, PLC...), therefore = possible different metrics. > In LOADng, if a router A (with metric-A) gets an RREQ message that it = doesn't understand (say, metric-B), router A will change the metric-type = to HOP_COUNT, and forward the message (the hop-count field is always = used). For the destination of RREQ, it will first consider the metrics = that it understands, and then HOP_COUNT. Of course, this will result in = "degrading" to HOP_COUNT for certain routes, but at least we can get a = usable route.=20 >=20 >=20 > I'm just introducing the design of LOADng, and would appreciate any = good idea on this issue.=20 >=20 >=20 > best >=20 >=20 > Jiazi > =20 > =20 > =20 > On Nov 2, 2012, at 12:42 PM, "Dearlove, Christopher (UK)" = wrote: >=20 >=20 > Having anything other than hop limit and hop count mutable is not the = security mechanism suggested in 6622/5444. > =20 > I'm of the view that the current approach of securing NHDP, securing = OLSRv2 etc. is not where things should ideally be, that the ideal place = is at the 5444 multiplexer wherever possible. If doing hop by hop = security, then that is the place, as it's where packets live. But if we = could do it once for all message types, then that's a major gain. > =20 > Now as soon as LOADng has anything else mutable, that doesn't help = that. OK, it's better than nothing, but those fields are buried in TLVs = (using 5444) and messy. > =20 > I'm at a disadvantage, I haven't studied why LOADng needs those fields = (other than hop count) mutable - or if it really does. But it reduces = "here's a clear advantage over DYMO" to "here's a more partial advantage = over DYMO". And I think Ulrich's summary could be edited to better = present this. > =20 > So if we adopted my separate proposal, this would be on the menu: why = are those fields mutable? Do they have to be? Can we find an = alternative? (Unfortunately, I can see why probably not. But it's still = a question.) > =20 > [Actually I can see an alternative, which is a much more limited = metric, which takes small integer values, and we increase hop count not = by one but by this metric, limiting paths to maximum 255 metric. We = could still get hop count from hop limit if we knew how it started - = e.g. in a non-mutable TLV. But I strongly doubt this is good enough.] > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI > Sent: 02 November 2012 10:54 > To: Dearlove, Christopher (UK) > Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Clausen = (thomas@thomasclausen.org) > Subject: Re: [manet] Reactive routing protocols, what are the = differences? > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an = external partner or the internet. > Keep this in mind if you answer this message. > Please see this process on how to deal with suspicious emails. >=20 > Hi Chris,=20 >=20 >=20 >=20 > I think Ulrich is in deep sleep at the moment, so please allow me to = have some words on this.=20 >=20 >=20 >=20 > For reactive protocols, updating the route information (hop-count, = metric) is inevitable. In the specification of DYMO, the messages can be = changed relatively arbitrarily, including removing addresses from the = messages. The intermediate RREP also makes end-to-end security = impossible.=20 >=20 >=20 >=20 > LOADng clearly defines which fields in the routing messages can't be = changed, and which fields are mutable. For example, for RREQ: >=20 >=20 >=20 > The following fields of an RREQ message are immutable, i.e., they MUST = NOT be changed during processing or forwarding of the message: = RREQ.addr-length, RREQ.seq-num, RREQ.originator, and RREQ.destination. > The following fields of an RREQ message are mutable, i.e., they will = be changed by intermediate routers during processing or forwarding, as = specified in Section 12.2 and Section 12.3: RREQ.metric-type, = RREQ.route-metric, and RREQ.hop-count. > Any additional field that is added to the message by an extension to = this protocol, e.g., by way of TLVs, MUST be considered immutable, = unless the extension specifically defines the field as mutable. >=20 >=20 >=20 > This allows the protocol to secure the messages by zeroing the mutable = fields.=20 >=20 >=20 >=20 > best >=20 >=20 >=20 > Jiazi=20 >=20 >=20 >=20 > (sorry to Chris if you received multiple copy of this message. I fixed = one typo though :) My previous one was bounced by manet mailing list = because of not using the right sender address) > =20 > =20 > On Nov 2, 2012, at 11:22 AM, "Dearlove, Christopher (UK)" = wrote: >=20 >=20 >=20 > There is, superficially at least, an apparent contradiction between = your points: >=20 > - DYMO cannot be end-to-end secured. Messages are changed in transit > (and not just hop-limit or the metric), but rather addresses can be > removed from RERRs and RREQs. >=20 > which implicitly suggests LOADng does not do this >=20 > and=20 >=20 > - LOADng uses a Metric message TLV, and it is clearly defined how to > update the metric under way. >=20 > Could you expand on this please? >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Ulrich Herberg [mailto:ulrich@herberg.name]=20 > Sent: 01 November 2012 22:02 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.org) > Subject: Re: [manet] Reactive routing protocols, what are the = differences? >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Hi Chris, >=20 > you have seen my review on DYMO. I will try to answer to your > question, and focus on the technical differences, not presentation. >=20 >=20 > On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK) > wrote: >=20 >=20 > The obviously best people to answer this should be document authors, = but anyone else may have useful additions and comments. Ideally the = different document authors could agree a list. (If they differ in that = one has X and the other doesn't, but one wants to say "we plan to = add/remove X" then X should be listed as a difference with that caveat, = in at least my ideal world.) >=20 > If we set aside, for the moment (though these things matter): > - The presentational quality of the documents, > - Any issues of 5444 compliance and other formatting issues, > - Issues of internal data organisation, > - Minor details such as possible different timeout parameters etc. > then what are the technical (and I stress that word) differences = between DYMO and LOADng? (I'm withholding the term AODVv2 for reasons I = may come back to.) >=20 >=20 > First, let's see what is common. Both are reactive protocols, using > RREQ, RREP and RERR. So if someone claims that DYMO performs great and > LOADng badly in the same scenario, I cannot understand that. MANET has > understood the scenarios where reactive protocols are useful and where > not. >=20 > Now, to the differences: >=20 > - DYMO cannot be end-to-end secured. Messages are changed in transit > (and not just hop-limit or the metric), but rather addresses can be > removed from RERRs and RREQs. There is also no provision to allow > external mechanisms to add additional reasons to reject messages as > invalid. > - DYMO uses the originator address in an address block, LOADng in the > message header. The sequence number is a TLV value in DYMO, and LOADng > uses the message sequence number. DYMO requires the originator address > to be the first one in the address block, the destination must be the > second one. LOADng uses a TLV to determine the target address. > - DYMO can advertise multiple addresses in an RERR; they can be > removed in transit of the message. > - DYMO allows intermediate routers to reply (as an option). That makes > end-to-end security difficult. In the core DYMO, there is a > destination sequence number that may be contained in RREQs in DYMO. > - DYMO allows for unicast RREQ, but does not specify in detail how to = use that. > - There are four timers for each route entry in DYMO, only one in = LOADng. > - LOADng can be used on other layers; DYMO is tied to IP. > - LOADng provides a bidirectionality verification using RREP_ACK, a > time-out of these, a blacklisted set and a Pending Acknowledgment Set > to verify bidirectional links. DYMO says that other mechanisms can be > used, but does not specify these. > - DYMO has several options for expanding ring RREQ, precursor list, > adding route information in transit, message aggregation in RFC5444 > packets and reporting multiple unreachable addresses in a RERR. LOADng > takes the approach to have a slim core of a basic mechanism that is > applicable in all MANET use cases, and companion documents with > extensions. In DYMO, it is not clearly specified what happens if some > routers support an option, and others don't. > - LOADng uses a Metric message TLV, and it is clearly defined how to > update the metric under way. If a router in transit does not recognize > a route metric type, it is reset to a "hop count" tlv extension type > of the Metric TLV and the value set to 0xFFFFF... (for the full TLV > length). It is specified that security mechanism must ignore the > content of the metric TLV value and that the length cannot be changed > under way, so that end-to-end security is possible. DYMO uses an > optional "distance" field for the metric, which is not clearly > specified how it is updated. Also, since this is optional, it is > unclear if routers receiving a message and forwarding it, update the > distance field or not. > - LOADng allows for (optionally) waiting to reply with a RREP, in case > a "better" RREQ comes a little later. In DYMO, a RREP is always sent > immediately. >=20 > There are probably more differences, but I let other chime in. >=20 > Best regards > Ulrich >=20 >=20 >=20 >=20 > Note that it's a lot more useful to have direct differences than = differences of each from AODV (especially when both have the same = difference). And it would be useful to have the objective differences = separated from the "and now why this is better" discussion - though that = would be a next step. >=20 > I'm not saying I don't see any of the differences. But I certainly = haven't worked out the complete list. In trying to form my view of how = things should go forward (a view that is coming together, and when it = does, I'll argue for it) and I hope for other people as well, it would = be good to know what the differences are. Regardless of views for or = against each, we should be able to objectively list the significant = differences - if we can't then something is wrong. >=20 > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 >=20 > ******************************************************************** > 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. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > =20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_6B5137B2-C5F9-4EC2-A935-E42DE1C6BBA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Op 2 nov. 2012, om 13:32 heeft = Dearlove, Christopher (UK) het volgende geschreven:

I understand the basics. And I agree I can't see = (except my bracketed aside) how to do it without a mutable field. But = having that mutable field reduces the value of the argument against DYMO = from "DYMO is mutable, LOADng is not" to "DYMO is (uncontrolled?) = mutable, LOADng is managed mutable". I'm not convinced by the argument = about having to mutate metric type. If you can't rely on it being = available to your network layer protocol consistently in the one MANET, = heterogeneous though it may be, I'm not sure you have a = well-put-together network. You could always make the metrioc increment = when unknown the maximum such value.
But there is, as another post raised, the larger = question of what end to end message authentication buys you. If in a = route A-B-X-C-D, where X is a bad guy, if X relays all RREQs and RREPs = flawlessly, but throws all data packets on the floor, X has done his = job, and without needing to forge anything. You also need B and/or C to = authenticate X. Lower layer? (in which case why can't that do the whole = job?).
There could be = 2nd order nodes: hosts. Or the routing protocol security mechanism is = implemented in the routing deamon, which is very similar to the = first.

RREP-ACK? Accumulating signature? Something = else?
 
(Note that a link state protocol = gets the B-X and X-C done. Those are, after all, = links.)
There can be = malicious routers with link state protocols too. 
Also, = there is a requirement that all routers share the same policy on what to = do with failed authentication, and result of checking must be the same = on all nodes. Not easy to deploy. And missing in olsrv2 core = protocol.

Teco


 
--
Christopher = Dearlove
Senior Principal Engineer, Communications = Group
Communications, Networks and Image Analysis Capability
BAE = Systems Advanced Technology Centre
West Hanningfield Road, Great = Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  = Fax: +44 1245 242124
The reason = that LOADng needs those fields mutable is to support different metrics = other than hop-count, even routers using different metrics in the same = routing domain can at least find a = path. 
To support different = metric types, a metric-type tlv and a route-metric tlv are needed. The = route-metric tlv has to be mutable because it needs to be updated at = each hop. 
Having = metric-type tlv mutable can make supporting different metrics in the = same network = possible. 
It's common that in = a heterogenous network, there are various transmission medias (802.11, = 802.15.4, cable, PLC...), therefore possible different = metrics.
In LOADng, = if a router A (with metric-A) gets an RREQ message that it doesn't = understand (say, metric-B), router A will change the metric-type to = HOP_COUNT, and forward the message (the hop-count field is always used). = For the destination of RREQ, it will first consider the metrics that it = understands, and then HOP_COUNT. Of course, this will result in = "degrading" to HOP_COUNT for certain routes, but at least we can get a = usable route. 
I'm just introducing = the design of LOADng, and would appreciate any good idea on this = issue. 
 
On Nov 2, 2012, at = 12:42 PM, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> = wrote:
Having anything other than hop limit and hop count = mutable is not the security mechanism suggested in = 6622/5444.
 
I'm of the view that the current = approach of securing NHDP, securing OLSRv2 etc. is not where things = should ideally be, that the ideal place is at the 5444 multiplexer = wherever possible. If doing hop by hop security, then that is the place, = as it's where packets live. But if we could do it once for all message = types, then that's a major gain.
Now as soon as LOADng has anything else mutable, = that doesn't help that. OK, it's better than nothing, but those fields = are buried in TLVs (using 5444) and = messy.
 
I'm at a disadvantage, I haven't = studied why LOADng needs those fields (other than hop count) mutable - = or if it really does. But it reduces "here's a clear advantage over = DYMO" to "here's a more partial advantage over DYMO". And I think = Ulrich's summary could be edited to better present = this.
 
So if we adopted my separate = proposal, this would be on the menu: why are those fields mutable? Do = they have to be? Can we find an alternative? (Unfortunately, I can see = why probably not. But it's still a = question.)
 
[Actually I can see an = alternative, which is a much more limited metric, which takes small = integer values, and we increase hop count not by one but by this metric, = limiting paths to maximum 255 metric. We could still get hop count from = hop limit if we knew how it started - e.g. in a non-mutable TLV. But I = strongly doubt this is good = enough.]
 
Christopher = Dearlove
Senior Principal Engineer, Communications = Group
Communications, Networks and Image Analysis Capability
BAE = Systems Advanced Technology Centre
West Hanningfield Road, Great = Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  = Fax: +44 1245 242124
chris.dearlove@baesystems.com | 
 Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi = YI
Sent: 02 = November 2012 10:54
To: Dearlove, Christopher = (UK)
Cc: Ulrich Herberg; manet@ietf.org; = Thomas Heide Clausen (thomas@thomasclausen.org)
Subject: Re: [manet] Reactive = routing protocols, what are the = differences?
 
*** WARNING = ***

This message originates from outside our = organisation, either from an external partner or the = internet.
Keep this in mind if you = answer this message.
Please see this = process on how to deal with = suspicious = emails.

Hi = Chris, 



I think Ulrich is in deep = sleep at the moment, so please allow me to have some words on = this. 



For reactive protocols, = updating the route information (hop-count, metric) is inevitable. In the = specification of DYMO, the messages can be changed relatively = arbitrarily, including removing addresses from the messages. The = intermediate RREP also makes end-to-end security = impossible. 



LOADng clearly defines = which fields in the routing messages can't be changed, and which fields = are mutable. For example, for = RREQ:



The following fields of an RREQ message are = immutable, i.e., they MUST NOT be changed during processing or = forwarding of the message: RREQ.addr-length, RREQ.seq-num, = RREQ.originator, and RREQ.destination.

The following fields of an = RREQ message are mutable, i.e., they will be changed by intermediate = routers during processing or forwarding, as specified in Section 12.3: = RREQ.metric-type, RREQ.route-metric, and = RREQ.hop-count.

Any additional field that is added to the message by an = extension to this protocol, e.g., by way of TLVs, MUST be considered = immutable, unless the extension specifically defines the field as = mutable.

This allows the protocol = to secure the messages by zeroing the mutable = fields. 









(sorry to Chris if you = received multiple copy of this message. I fixed one typo though :) My = previous one was bounced by manet mailing list because of not using the = right sender = address)
 
 
=0A=0A

=0A
=0A
JP3> You keep ignorin= g my point. Of it matters. I would even make it work with BGP-4. Would you = recommend the use of BGP in LLN ?
=0A
If you deploy a protocol in = very specific conditions that do not apply to most LLNs, then you may want = to know it before making it an RFC.
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=

=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A

=0A
=0A
=0A
=0A
=0A
=0A
=0APlease share your results.  You= keeps saying you will and you we keep asking you to - where's the results = so they can be reviewed.
=0A
=0A
=0A
=0A
=0A
=0A<= /div>=0A
=0A

=0A
=0A
JP> Once again, I woul= d first like to hear chair's decision. PLEASE note that I would be happy to= see Load's results too. And just be
=0A
patient, I just need to f= ind a bit of time to compile results and you will get many results backing = up my claims. Please also refer to the
=0A
number of discussions p= rior to designing RPL that took place on the ROLL mailing list. Believe me = there was a reason not NOT choosing
=0A
a reactive protocol for LL= N (again I am NOT against reactive routing for other use cases at all). Wou= ld you ignore the findings of a WG
=0A
that worked for 4 years on = the subject matter ? I guess not =E2=80=A6 Just trying to raise my voice (a= s many others on this list) to protect the
=0A
Internet.
=0A=0A[Jon] As others have said - you have it backwards.  If you have da= ta that would show that LOADng or a reactive protocol will not work in MANE= Ts please share it. 
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A

=0A
=0A
JP= 2> Please reread what I wrote ten times =E2=80=A6 I said "LLNs" not "MAN= ET" in general. On top of that, I do prefer the option 1) for the reasons e= xposed 
=0A
before (this is the WG document, Charlie made it = compatible + other technical reasons).
=0A
=0AYou did say LLNs but ag= ain you are wrong.  There are plenty of LLNS that have been built usin= g reactive (and proactive) protocols and will continue to be built using re= active (and proactive protocols).  There is no one size fits all.
= =0A
=0AI prefer to have a debate based on facts and not conjecture and b= ased on technical arguments.=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
That would be
=0Avery insightful and would hel= p guide this discussion and decision.  It would not be prudent to make= a decision and then bring out data that would try to suggest that the deci= sion was incorrect.
=0A
=0AWhat findings are you referring to?  = Where is there a WG document that documents these findings?
=0A
=0A=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A[Jon2] I noticed you skipped this. 
=0A
= =0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=0A

=0A
=0A
JP3> I do not skip anything. I am respe= ctful of the question asked by the chair, knowing that their task is to say= the least not easy.
=0A
As soon as required, I will provide lots = of data, at least the ones that can be shared, if authorization is given by= the owners of these
=0A
networks.
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
= =0A
=0A

=0A
=0A
Thanks.
=0A

=0A
=0A<= div>JP.
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0AJon
=0A
=0A
=0A
=0A

=0A<= /div>=0A
=0A
=0A
=0A
=0AFrom:<= /b> JP Vasseur (jvasseur) <jvasseur@= cisco.com>
=0ATo:= Jon Black <jblack.ietf@yahoo.= com>=0A
=0ACc: "<= a rel=3D"nofollow" ymailto=3D"mailto:manet@ietf.org" target=3D"_blank" href= =3D"mailto:manet@ietf.org">manet@ietf.org" <manet@ietf.org>;=0A "thierry.lys@erdfdistribution.fr" <thierry.lys@erdfdistribution= .fr>=0A
=0ASent: = Wednesday, October 31, 2012 4:09 PM
=0ASubject: Re: [manet] (no subject)
=0A
=0A
= =0A
=0A

=0A
=0A
On Oct 31, 2012, a= t 6:57 PM, Jon Black wrote:
=0A
=0A
=0A
=0A
=0A
On October 31, 2012 T= hierry.Lys wrote:
=0A

=0A
=0A
=0AI speak in the name of EDF group.
= =0A
=0AWe started first to use LOAD= as a routing algorithm and deployed 2000 PLC-meters for smart grid purpose= s in 2011. Taking advantage of this field test, we have been actively parti= cipating to the working group to adopt enhancements=0A in the LOADng specif= ication.
=0AWe are now extr= emely pleased with what LOADng is capable of and are confident that future = deployements will be equipped with it. 
=0A
=0A
=0A
=0A
=0AThis would seem to indicate that LOA= Dng does work and in a rather large deployment.
=0A
=0A
=0A=0A
=0A

=0A
=0A
JP> No this means that L= oadNG works in *a* network. But the major technical difference here is that= reactive routing is highly impacted
=0A
by the user traffic =E2= =80=A6 If you poll a meter every 24 hours, it may work perfectly well. Now = if you start having more frequent traffic flows
=0A
you can either= cache paths (ending up with more frequent broken paths considering how fla= ppy these networks are, thus leading to more
=0A
floods =E2=80=A6 = very undesirable =E2=80=A6 especially when you have hundreds of meters shar= ing a few Kbits/s) or you use short cache timers and you
=0A
keep = flooding :-( If you take actual traces of these networks (both using 15.4g = and P1901.2) and you start adjusting the user traffic rate you
=0Aimmediately see the issues in terms of scalability. Yes you can try to mit= igate the undesirable flooding effect to some extends but showing =0A
the limits in terms of scalability is easy to show. Note that I M= OT against reactive routing by any means, this is IMO just not applicable t= o
=0A
LLNs unless the traffic flows are deterministic and very wel= l knows =E2=80=A6 Lessons from the past show us how difficult it is to pred= ict user 
=0A
applications. We all started with meter reading= to continue with that example and now many utilities wants to use these sm= art metering 
=0A
networks for a number of applications which= different SLA, =E2=80=A6 
=0A

=0A
=0A
Hope this= helps. Once again, when/if required I would be happy to share many results= .
=0A

=0A
=0A
=0A
=0A
=0A=
=0A
=0A
=0A"We believe in rough consensus and running cod= e"=0A
=0A
=0Arough consen= sus : Don't you think we have a rough consensus on LOADng compared to DYMO = ? 10 authors and major companies are supporters of LOADng.=0A
=0A=
=0Arunning code : interoperability= has been checked with 4 sources and other implementations are in progress.= =0A
=0A
=0A
=0AOb= viously from the list we don't have rough consensus.  We have two alte= rnatives each with proponents.  The WG should weigh the technical bene= fits (design, implementation/running code, maturity)  of each and the = group should=0A choose a path forward.
=0A
=0AIn my opinion option 3 = is not an option - this is the working group shirking its responsibility.=0A
=0A
=0A
=0A

=0A
=0A
Thi= s is an option =E2=80=A6 since listed by the chairs. I agree that we should= avoid it, especially when I think we have a very reasonable solution
= =0A
(option1).
=0A

=0A
=0A
JP.
=0A
=0A=0A
=0A
=0A
= =0AJon
=0A=0A
=0A
= =0A
=0A
= =0A
=0A
=0A
=0A_____________________________________________= __
=0Amanet mailing list
=0Amanet@ietf.or= g
=0Ahttps://www.ietf.org/mailman/listinfo/manet=
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A_________= ______________________________________
=0Amanet mailing list
=0Amanet@ietf.org
=0Ahttps://ww= w.ietf.org/mailman/listinfo/manet
=0A
=0A=0A
= =0A=0A=0A=0A =0A
=0A
=0A=0A=0A=0A= =0A
=0A=0A
=0A=0A=0A________________= _______________________________
=0Amanet mailing list
=0Amanet@ietf.org
=0Ahttps://www.ietf.org/mailman/listi= nfo/manet
=0A=0A=0A
=0A=0A=0A=0A=

= ---1725615817-1448048242-1351876062=:61554-- From jvasseur@cisco.com Fri Nov 2 10:09:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACF411E80D1 for ; Fri, 2 Nov 2012 10:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.489 X-Spam-Level: X-Spam-Status: No, score=-10.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGyqmR+RLePh for ; Fri, 2 Nov 2012 10:09:36 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4F111E80AD for ; Fri, 2 Nov 2012 10:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5829; q=dns/txt; s=iport; t=1351876176; x=1353085776; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KYhX3XWabESBaOgvklJLa2T83VjnPB4gZzljJ4+nS90=; b=WUOIhWXL+DaFsDpsdebnsUSHn40HXbsmIixqC1jw4he+nTklIb+Nfx4l TAE+a9MZ8lCkXX4gVSWyTaluQ1WF5lCAyQQkvKrO5Vty36RK16lohJBGQ +N16gfdhwxtOSKJqLzzteX/Xq9dE8+Mtt9HoY4Ov35VNhPXyIAQknU1rG I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIn9k1CtJXG//2dsb2JhbABEwzWBCIIeAQEBAwESAVkNBQsCAQgiJDIlAgQODQwOh2IGm3qgE4wBhVphA6RSgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208";a="138238322" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 02 Nov 2012 17:09:36 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA2H9ZDX003020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 17:09:35 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 12:09:35 -0500 From: "JP Vasseur (jvasseur)" To: "Timothy J. Salo" Thread-Topic: [manet] LOADng works Thread-Index: AQHNuF9dW2UMul6sMEaXNf6TARakEQ== Date: Fri, 2 Nov 2012 17:09:34 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> In-Reply-To: <5093EF93.70201@saloits.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--41.489900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <02A0872EBE53304393D7E4BA3CAEA7CF@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:09:37 -0000 On Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote: >>>> JP> This is not just a question of "how large" it is =85 but also how >>>> dynamic. I could show you few hundreds (if not less number of nodes) >>>> not working if the traffic pattern is too dynamic. This is a >>>> fundamental problem. >=20 > No, it is a fundamental and well-known characteristic of reactive > routing protocols. It is a problem only when this behavior doesn't > match the characteristics of the network in which the reactive routing > protocol is deployed. JP> Indeed =85 and this is why you have a fundamental issue with you have e= xtremely high BER, PDR, low bandwidth =85 as we do in LLNs. Flooding in these networks is driven by= user traffic and of course=20 is highly undesirable. Slightly increase the use traffic and you will see t= he impact on the control plane ... >=20 > We've known for at least 15 years that reactive routing protocols are > more appropriate for light traffic loads and that proactive routing > protocols are more appropriate with heavier traffic loads. =20 JP> This is over-simplying but I see what you mean. > Dozens, > probably hundreds of research papers have reiterated this result. > I don't know of any that have contradicted this result, although > some researchers have tried to develop hybrid routing protocols > (which don't seem to have gained much traction, either in the IETF > or elsewhere). >=20 > Claiming that reactive routing protocols don't scale to heavier traffic > loads is neither a new result nor particularly insightful -- this hasn't > changed for at least 15 years. JP> Let me restate my point. Not sure of what you mean by "heavier" =85 but= if you flood the network with probes each time you need to find a path in a LLN yo= u have=20 a major problem. Of course, there are many ways to control flooding, use ca= ches .. that are all well-known and by the way hard to tune. But overall, reactive = routing in *these* networks is simply ill suited. >=20 > I haven't seen any evidence that _no_ LLN will experience the sort of > light traffic load that matches the characteristics of a reactive > routing protocol. To the contrary, the deployment experience with > LOADng suggests that such do networks exist. JP> Once again it all depends on the traffic profile. Of course you could m= ake a=20 reactive routing protocol work on a LLN as long as the user traffic has spe= cific=20 characteristics. If you carefully analyze the user traffic characteristic i= n networks such as smart metering (since this was mentioned on this list), and you inc= orporate additional applications such as DA, .. to mention a few, you will see that = in most of=20 these networks this simply does not work =85 too many flooding, ending up n= ot even converging in some cases, especially when the number of hops gets high with= poor link quality. >=20 > At the risk of arguing by analogy, the argument that one can "prove" > that reactive routing protocols don't work (in LLNs or elsewhere) seems > to make about as much as sense as "proving" that OSPF doesn't work > because it doesn't behave well in dynamic environments. The failure of > OSPF in dynamic environments didn't cause us to abandon OSPF: there are > many environments in which it works well. =20 JP> Not sure that I would have used this analogy :-( OSPF was not designed = for highly dynamic environment indeed *but* we could easily enhance it with fast failu= re detection (+ BFD), fast LSA generation, fast SPF and incremental SPF, Local Fast Rero= ute, =85=20 because routers had lot of resources, links were highly stable, =85 which i= s by far not the case of LLNs. > Rather, we concluded that we > needed another routing protocol. In a similar manner, the MANET > working group, and as far as I have seen pretty much all of the > research community, concluded that there is a need for both a > reactive routing protocol and a proactive routing protocol. >=20 > Of course, the ROLL working group can decide not to standardize > a reactive routing protocol. However, that doesn't prove that > reactive routing protocols don't work (when they match the > traffic characteristics of the network), that reactive routing > protocols won't work better than proactive routing protocols > in some LLNs (based on the characteristics of the traffic load), > or that reactive routing protocols won't be successfully deployed > in LLNs. =20 JP> Well =85 Think about this: when ROLL was formed, the IESG explicitly an= d rightfully asked the WG to first prove that none of the existing protocol could be used, bef= ore standardizing a new protocol (that was the right choice !!).=20 Could then prove that the current protocol cannot be used in your environme= nt before suggesting to standardize a new one. Once again, if not applicable to LLNs, I have no problem whatsoever. > If fact, the LOADng deployment experience strongly > suggests that reactive routing protocols _will_ be deployed in > some LLNs. And, they will be deployed regardless of the ROLL > working group's decision to not standardize a reactive routing > protocol. JP> And this is perfectly fine, people are free to use any protocol they wa= nt, including proprietary=20 ones. This does not mean that the IETF should standardize them. >=20 > Claiming that reactive routing protocols don't work because they > don't scale to higher traffic loads seems, JP> Then we need to characterize precisely the limits. > at best, a poor > characterization of well-known research results, and at worst > a distraction from the question at hand: namely how to proceed > towards an Internet-standard reactive routing protocol. >=20 > -tjs From jvasseur@cisco.com Fri Nov 2 10:10:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA0311E80CC for ; Fri, 2 Nov 2012 10:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.495 X-Spam-Level: X-Spam-Status: No, score=-10.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDRKgeeIMHFW for ; Fri, 2 Nov 2012 10:10:51 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD8011E80AD for ; Fri, 2 Nov 2012 10:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11851; q=dns/txt; s=iport; t=1351876251; x=1353085851; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=y24ZrNY/VlZayPPsOUcCdSWELbAecjHL4vP3Ryz2Fxo=; b=CFOARI+adggDR99w+hPXsW+7BRxa4CEXzIIGbT2BsfCIQYSGh1W+7a6X tp6HhHV2oSGh9GTywb4jptEtjxNnhcN/oHxJSpgpOOBZdyfc0JsUAV1+/ kl2T9ZvWWAhn1nSJ5uGJzCDlQM2Iu/tqso7GZn75OhC9/egCjtsdXrCsJ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIn9k1CtJXG+/2dsb2JhbABEwzWBCIIeAQEBAwEBAQEPAUIZCwULAgEIBxsdBycLFBECBA4FCBYEh2IGC5tvoBOMARSFRmEDiCWcLYFrgm+BWwkXHg X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208,217";a="138220476" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 02 Nov 2012 17:10:50 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA2HAofv002950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 17:10:50 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 12:10:49 -0500 From: "JP Vasseur (jvasseur)" To: Abdussalam Baryun Thread-Topic: [manet] A proposal - differentiating the document and the protocol Thread-Index: AQHNuR0BQAldmF7ZtU6krGF1ERjKag== Date: Fri, 2 Nov 2012 17:10:48 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204C4DD@xmb-rcd-x02.cisco.com> References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--68.099700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204C4DDxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:10:52 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204C4DDxmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Nov 2, 2012, at 12:24 PM, Abdussalam Baryun wrote: Does All WG, support the proposal stating: Chris>This would not of course be LOADng, so we'd have to change the docume= nt name. And there I suggest we have a candidate name - AODVv2. (Which is w= hy I have recently taken to saying DYMO when referring to that document.) A= fter all, the one thing we are agreed on is that the protocol being develop= ed is derived from AODV. I hope we can agree on the above suggestion to go forward, I would but starting with DYMO as the base document and go from there, whic= h is I think that Charlie proposed. Thanks. JP. Regards AB On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg > wrote: Dear Chris, personally, what you propose makes sense to me. Regards Ulrich On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" > wrote: > Before making a proposal, I'm going to introduce a distinction here betwe= en the DYMO and LOADng documents and protocols. > > I'm of the opinion that the LOADng document is a greatly superior present= ation to the DYMO document. (I'm not really interested in why that has come= about.) > > I think that regardless of whether one makes design decisions favouring D= YMO or LOADng where they differ - and let's not forget they overlap a lot -= it would actually be easier to modify the LOADng document to specify DYMO = than it would be to modify the DYMO document to achieve that. And in practi= ce I think if making decisions it is unlikely that all would favour DYMO ov= er LOADng. > > So what I think would be best for the WG is not a simply "option 1" or ev= en (as it may appear I'm suggesting, but I'm not) "option 2" but rather to= agree to take the LOADng document, and a list of where DYMO and LOADng dif= fer, and thrash out where they do, what the WG reactive protocol should do = - either as a definite choice, or as an option (but not too many options pl= ease- and some could be separate specifications). > > This would not of course be LOADng, so we'd have to change the document n= ame. And there I suggest we have a candidate name - AODVv2. (Which is why I= have recently taken to saying DYMO when referring to that document.) After= all, the one thing we are agreed on is that the protocol being developed i= s derived from AODV. > > The editors of this new document would have to agree that what goes in it= is WG consensus (which should follow proper technical consideration of the= issues). If they found it impossible to have other than their way to do th= ings, they'd have to move on. If that left no one editing it, obviously we = don't have a consensus of people prepared to do the work and option 3 would= win. > > So now I'm partly off the fence I've been sitting on. But only partly. I = haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standar= d, IRREPs as an option in the main draft, IRREPs as a separate draft option= , no IRREPs. I'd like to move on to those discussions. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | htt= p://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > ******************************************************************** > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204C4DDxmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Nov 2, 2012, at 12:24 PM, Abdussalam Baryun wrote:

Does All WG, support the proposal stating:
 
Chris>This would not of course be LOADng, so we'd have to change th= e document name. And there I suggest we have a candidate name - AODVv2. (Wh= ich is why I have recently taken to saying DYMO when referring to that docu= ment.) After all, the one thing we are agreed on is that the protocol being developed is derived from AODV.
I hope we can agree on the above suggestion to go forward,

I would but starting with DYMO as the base document and go from there,= which is I think that Charlie proposed.

Thanks.

JP.

 
Regards
AB

On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg <= span dir=3D"ltr"> <ulrich@herberg= .name> wrote:
Dear Chris,

personally, what you propose makes sense to me.


Regards
Ulrich

On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com= > wrote:

> Before making a proposal, I'm going to introduce a distinction here be= tween the DYMO and LOADng documents and protocols.
>
> I'm of the opinion that the LOADng document is a greatly superior pres= entation to the DYMO document. (I'm not really interested in why that has c= ome about.)
>
> I think that regardless of whether one makes design decisions favourin= g DYMO or LOADng where they differ - and let's not forget they overlap a lo= t - it would actually be easier to modify the LOADng document to specify DY= MO than it would be to modify the DYMO document to achieve that. And in practice I think if making decisions it i= s unlikely that all would favour DYMO over LOADng.
>
> So what I think would be best for the WG is not a simply "option = 1" or even (as it may appear I'm suggesting, but  I'm not) "= option 2" but rather to agree to take the LOADng document, and a list = of where DYMO and LOADng differ, and thrash out where they do, what the WG reactive protocol should do - either as a definite choice, or = as an option (but not too many options please- and some could be separate s= pecifications).
>
> This would not of course be LOADng, so we'd have to change the documen= t name. And there I suggest we have a candidate name - AODVv2. (Which is wh= y I have recently taken to saying DYMO when referring to that document.) Af= ter all, the one thing we are agreed on is that the protocol being developed is derived from AODV.
>
> The editors of this new document would have to agree that what goes in= it is WG consensus (which should follow proper technical consideration of = the issues). If they found it impossible to have other than their way to do= things, they'd have to move on. If that left no one editing it, obviously we don't have a consensus of people= prepared to do the work and option 3 would win.
>
> So now I'm partly off the fence I've been sitting on. But only partly.= I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as stan= dard, IRREPs as an option in the main draft, IRREPs as a separate draft opt= ion, no IRREPs. I'd like to move on to those discussions.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1= 245 242124
> chris.dearlove@baesys= tems.com | http://www.baesyst= ems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
>
> ******************************************************************** > 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.
> ******************************************************************** >
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A772204C4DDxmbrcdx02ciscoc_-- From jvasseur@cisco.com Fri Nov 2 10:13:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7EA11E80D7 for ; Fri, 2 Nov 2012 10:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.339 X-Spam-Level: X-Spam-Status: No, score=-10.339 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KMB97dkZ8um for ; Fri, 2 Nov 2012 10:13:10 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8C53E11E80A2 for ; Fri, 2 Nov 2012 10:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14753; q=dns/txt; s=iport; t=1351876389; x=1353085989; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Rpl8/Q7b5ntOO+VLuyT9NmSIzBVq6SQcdo8wIee48Nk=; b=IoPAaeTVgsv2axvxH7/JDCKE6OaX+8q7UaahIheY7/c+389g0jSH50j0 ePF4hpuQUsbVGK2yZKbjTk3wqRkfYPmQ2/lSQOWNXGn1JLK083qZGdeMS pREYtpEpaOfuznyJvhEdci0xgno5TvgS3rtQmxFYeVId2Ali4swYK3hiB o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIn9k1CtJXG//2dsb2JhbABEwzWBCIIeAQEBAwEBAQEPAUIZCwULAgEIBxsdByEGCxQRAgQOBQgWBIdWAwkGC5tvljINiVSLGmcUhUZhA5QkjQiDJoFrgm+BWwkXHg X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208,217";a="138024021" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 02 Nov 2012 17:13:08 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA2HD8wv006952 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 17:13:08 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 12:13:07 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] A proposal - differentiating the document and the protocol Thread-Index: AQHNuR1TQAldmF7ZtU6krGF1ERjKag== Date: Fri, 2 Nov 2012 17:13:07 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204C538@xmb-rcd-x02.cisco.com> References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--62.625100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204C538xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:13:11 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204C538xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, On Nov 2, 2012, at 12:34 PM, Ulrich Herberg wrote: Hi Abdussalam, there was indeed some hesitance to change the name from some of the authors= (not me). I cannot speak for them here. My intuition is that if the name o= f the protocol is the only factor that avoids the reactive protocol from pr= oceeding in the WG, this can be solved. JP> I do not think that this is the only issue =85 applicability and use of= existing mechanisms in DYMO (potentially marked as optional is another one= ). As far as I can see from the discussions so far, there is a clear consensus= that option 3 is not viable. JP> Not sure =85 I hope that you are right. I guess that option 3 would be = the result of a lack of consensus between 1 and 2 *but* I cannot speak for the chairs. Now, if we want to proceed with the reactive document, the question is from= which document to start. Chris mentioned that even if we wanted the specif= ication of 100%, it would be far quicker to start from the LOADng draft. I = propose that we can start working based on the LOADng draft (possibly renam= e it?), look at each item that is in DYMO and consider whether and in which= way it should be incorporated in the draft. JP> And I propose the opposite =85 We're back to the original question. Thanks. JP. Best Ulrich On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun > wrote: Hi Ulrich, I think that Chris's proposal was not accepted by LOADng co-authors as I un= derstood from following up the WG history (they don't agree to change the n= ame of protocol). As you are one co-author do I understand that you support= the Chris's proposal, AB On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg > wrote: Dear Chris, personally, what you propose makes sense to me. Regards Ulrich On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" > wrote: > Before making a proposal, I'm going to introduce a distinction here betwe= en the DYMO and LOADng documents and protocols. > > I'm of the opinion that the LOADng document is a greatly superior present= ation to the DYMO document. (I'm not really interested in why that has come= about.) > > I think that regardless of whether one makes design decisions favouring D= YMO or LOADng where they differ - and let's not forget they overlap a lot -= it would actually be easier to modify the LOADng document to specify DYMO = than it would be to modify the DYMO document to achieve that. And in practi= ce I think if making decisions it is unlikely that all would favour DYMO ov= er LOADng. > > So what I think would be best for the WG is not a simply "option 1" or ev= en (as it may appear I'm suggesting, but I'm not) "option 2" but rather to= agree to take the LOADng document, and a list of where DYMO and LOADng dif= fer, and thrash out where they do, what the WG reactive protocol should do = - either as a definite choice, or as an option (but not too many options pl= ease- and some could be separate specifications). > > This would not of course be LOADng, so we'd have to change the document n= ame. And there I suggest we have a candidate name - AODVv2. (Which is why I= have recently taken to saying DYMO when referring to that document.) After= all, the one thing we are agreed on is that the protocol being developed i= s derived from AODV. > > The editors of this new document would have to agree that what goes in it= is WG consensus (which should follow proper technical consideration of the= issues). If they found it impossible to have other than their way to do th= ings, they'd have to move on. If that left no one editing it, obviously we = don't have a consensus of people prepared to do the work and option 3 would= win. > > So now I'm partly off the fence I've been sitting on. But only partly. I = haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standar= d, IRREPs as an option in the main draft, IRREPs as a separate draft option= , no IRREPs. I'd like to move on to those discussions. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | htt= p://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > ******************************************************************** > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204C538xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi,

On Nov 2, 2012, at 12:34 PM, Ulrich Herberg wrote:

Hi Abdussalam,

there was indeed some hesitance to change the name from some of the au= thors (not me). I cannot speak for them here. My intuition is that if the n= ame of the protocol is the only factor that avoids the reactive protocol fr= om proceeding in the WG, this can be solved.


JP> I do not think that this is the only issue =85 applicability an= d use of existing mechanisms in DYMO (potentially marked as optional is ano= ther one).

As far as I can see from the discussions so far, there is a clear cons= ensus that option 3 is not viable.

JP> Not sure =85 I hope that you are right. I guess that option 3 w= ould be the result of a lack of consensus between 1 and 2 *but* I cannot
speak for the chairs.

Now, if we want to proceed with the reactive document, the question is= from which document to start. Chris mentioned that even if we wanted the s= pecification of 100%, it would be far quicker to start from the LOADng draf= t. I propose that we can start working based on the LOADng draft (possibly rename it?), look at each item th= at is in DYMO and consider whether and in which way it should be incorporat= ed in the draft. 

JP> And I propose the opposite =85 We're back to the original quest= ion.

Thanks.

JP.


Best
Ulrich



On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryu= n <abdussa= lambaryun@gmail.com> wrote:
Hi Ulrich,
 
I think that Chris's proposal was not accepted by LOADng co-autho= rs as I understood from following up the WG history (they don't agree to ch= ange the name of protocol). As you are one co-author do I understand that y= ou support the Chris's proposal,
AB
On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg <= span dir=3D"ltr"> <ulrich@herberg= .name> wrote:
Dear Chris,

personally, what you propose makes sense to me.


Regards
Ulrich

On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@= baesystems.com> wrote:

> Before making a proposal, I'm going to introduce a distinction here be= tween the DYMO and LOADng documents and protocols.
>
> I'm of the opinion that the LOADng document is a greatly superior pres= entation to the DYMO document. (I'm not really interested in why that has c= ome about.)
>
> I think that regardless of whether one makes design decisions favourin= g DYMO or LOADng where they differ - and let's not forget they overlap a lo= t - it would actually be easier to modify the LOADng document to specify DY= MO than it would be to modify the DYMO document to achieve that. And in practice I think if making decisions it i= s unlikely that all would favour DYMO over LOADng.
>
> So what I think would be best for the WG is not a simply "option = 1" or even (as it may appear I'm suggesting, but  I'm not) "= option 2" but rather to agree to take the LOADng document, and a list = of where DYMO and LOADng differ, and thrash out where they do, what the WG reactive protocol should do - either as a definite choice, or = as an option (but not too many options please- and some could be separate s= pecifications).
>
> This would not of course be LOADng, so we'd have to change the documen= t name. And there I suggest we have a candidate name - AODVv2. (Which is wh= y I have recently taken to saying DYMO when referring to that document.) Af= ter all, the one thing we are agreed on is that the protocol being developed is derived from AODV.
>
> The editors of this new document would have to agree that what goes in= it is WG consensus (which should follow proper technical consideration of = the issues). If they found it impossible to have other than their way to do= things, they'd have to move on. If that left no one editing it, obviously we don't have a consensus of people= prepared to do the work and option 3 would win.
>
> So now I'm partly off the fence I've been sitting on. But only partly.= I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as stan= dard, IRREPs as an option in the main draft, IRREPs as a separate draft opt= ion, no IRREPs. I'd like to move on to those discussions.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chr= is.dearlove@baesystems.com | http://www.baesyst= ems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
>
> ******************************************************************** > 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.
> ******************************************************************** >
> _______________________________________________
> manet mailing list
> manet@ietf.org=
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A772204C538xmbrcdx02ciscoc_-- From jblack.ietf@yahoo.com Fri Nov 2 10:16:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD5C21F8F10 for ; Fri, 2 Nov 2012 10:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.676, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH9a1TnCKoGD for ; Fri, 2 Nov 2012 10:16:28 -0700 (PDT) Received: from nm40-vm4.bullet.mail.bf1.yahoo.com (nm40-vm4.bullet.mail.bf1.yahoo.com [72.30.239.212]) by ietfa.amsl.com (Postfix) with ESMTP id 74E5921F8EC5 for ; Fri, 2 Nov 2012 10:16:28 -0700 (PDT) Received: from [98.139.212.150] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 17:16:27 -0000 Received: from [98.139.212.208] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 17:16:27 -0000 Received: from [127.0.0.1] by omp1017.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 17:16:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 569106.14278.bm@omp1017.mail.bf1.yahoo.com Received: (qmail 94033 invoked by uid 60001); 2 Nov 2012 17:16:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351876587; bh=1JBZ4XF366gSCJPs5OcNH0R3M63RlfdY5uHdrrKZqn8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=wBT/8EuT7s8Xh6TZlGQAn4je7F1J1/e6/fEautvRwFn6nR4lRd0we6nIG/rPaqTTvNvTp5P2LQ8at6orEf8s9PT2d0UCX3DWqTALsdXV8Tv7lCEE9b8GEuo5tnOT6rdqp8fY8CIaY+24adB37Msvj5a7jDnsyscMekAQDrXgtBg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QI/dCJDmqQNgcYoJgbxZvn9TmAm0b5WLybAFHJpxi4Rwevsc4xFdF+kj3355VJb4sa3peOePNkKwJErkvESYrgP8VTF4lUBlIu7HWw4yFPqm3rxekt6la3BRfrpdQ7FHg3PcPmAm5dU9Soox+GyoffEp+owB7/5cMbK1VuHHMy0=; X-YMail-OSG: _qeiG1AVM1msiZVpbO75a.o5VeMcrG2j6EbEXdQM8WIdRtE opZdwXK89uZS7Inc_mtwpuBULIzDjKyiwGWtY2zwCYWFpfjgGYmRZGdZKztb uYFb8nfSrWU9cWIEJyiDC6ssFeDSYaKN1UIszPnslaF8WvEbWvEle4ijyFOa x4bRuzBY6ZmUGhec8.kk0DfG3sGmUjbZnUrGa_5DopX.OOwsl0pCKRCdGRBp eninAVnK0_6J._3xTND40E0SHxIVaGCVX6hX6GDqlkj8FXtHXFGEgszDyHP_ 3Mh2eF.6VrDsMCg4Px63Z6eRAnRJCGpmveUfO5G1jKXuSF5m9JOQzCQNEEln rXMvfxsjNB2lTCuQIedPRiHDDPYs.j2hrwSpShih1es9j_.cCr93IdtIYu3e byRlHKtvOp0d2pRuHLVarZBWtvsQdyV716IlFA3o11X9ygrGZgsliQgbFJoX A3hy7vL1wMSnVUm6crLd1Hww_f.Mf9JEW3Y2i4S3ma_N0WgP3dDKKDlQwIPB 8m3YFc12.9_V6eolNUKzjmEs- Received: from [173.193.202.116] by web160602.mail.bf1.yahoo.com via HTTP; Fri, 02 Nov 2012 10:16:27 PDT X-Rocket-MIMEInfo: 001.001, VGhpcyBzZWVtcyB0byBtYWtlIGdvb2Qgc2Vuc2UuwqAgVGhlIG5hbWUgc2hvdWxkIG5vdCBiZSBpc3N1ZS7CoCBXZSBuZWVkIGEgZ29vZCBzb2xpZCBiYXNlIHRvIHN0YXJ0IGZyb20uwqAgSXQgd291bGQgYXBwZWFyIHRoYXQgaWYgdGhlcmUgYXJlIHdvcmtpbmcgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbiBiYXNlZCBvbiB0aGUgTE9BRG5nIGRyYWZ0IHRoZW4gdGhpcyBpbmRpY2F0ZXMgdGhhdCB0aGUgZHJhZnQgaXMgaW1wbGVtZW50YWJsZS7CoCBBZ2FpbiwgaGF2aW5nIHJlYWQgYm90aCBJIGNvdWwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> Message-ID: <1351876587.86080.YahooMailNeo@web160602.mail.bf1.yahoo.com> Date: Fri, 2 Nov 2012 10:16:27 -0700 (PDT) From: Jon Black To: Ulrich Herberg , Abdussalam Baryun In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1725615817-518105800-1351876587=:86080" Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:16:30 -0000 ---1725615817-518105800-1351876587=:86080 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable This seems to make good sense.=A0 The name should not be issue.=A0 We need = a good solid base to start from.=A0 It would appear that if there are worki= ng interoperable implementation based on the LOADng draft then this indicat= es that the draft is implementable.=A0 Again, having read both I could buil= d something based on the LOADng draft and I (and I'm only talking for me) c= ouldn't based on the DYMO draft.=0A=0AI much prefer starting with something= simple and understandable and adding what is missing rather than starting = with something more difficult to understand trying to remove things that ar= e not needed.=0A=0AJon=0A=0A=0A=0A=0A________________________________=0A Fr= om: Ulrich Herberg =0ATo: Abdussalam Baryun =0ACc: "Dearlove, Christopher (UK)" ; "manet@ietf.org" =0ASent: Friday, November 2,= 2012 10:34 AM=0ASubject: Re: [manet] A proposal - differentiating the docu= ment and the protocol=0A =0A=0AHi Abdussalam,=0A=0Athere was indeed some he= sitance to change the name from some of the authors (not me). I cannot spea= k for them here. My intuition is that if the name of the protocol is the on= ly factor that avoids the reactive protocol from proceeding in the WG, this= can be solved.=0A=0AAs far as I can see from the discussions so far, there= is a clear consensus that option 3 is not viable. Now, if we want to proce= ed with the reactive document, the question is from which document to start= . Chris mentioned that even if we wanted the specification of 100%, it woul= d be far quicker to start from the LOADng draft.=A0I propose that we can st= art working based on the LOADng draft=A0(possibly rename it?), look at each= item that is in DYMO and consider whether and in which way it should be in= corporated in the draft.=A0=0A=0ABest=0AUlrich=0A=0A=0A=0A=0AOn Fri, Nov 2,= 2012 at 9:17 AM, Abdussalam Baryun wrote:=0A= =0AHi Ulrich,=0A>=A0=0A>I think that=A0Chris's proposal was not accepted by= LOADng co-authors as I understood from following up the WG history (they d= on't agree to change the name of protocol). As you are one co-author do I u= nderstand that you support the Chris's proposal,=0A>=0A>AB=0A>=0A>On Fri, N= ov 2, 2012 at 2:41 PM, Ulrich Herberg wrote:=0A>=0A>D= ear Chris,=0A>>=0A>>personally, what you propose makes sense to me.=0A>>=0A= >>=0A>>Regards=0A>>Ulrich=0A>>=0A>>=0A>>On Nov 2, 2012, at 4:16, "Dearlove,= Christopher (UK)" wrote:=0A>>=0A>>> Before= making a proposal, I'm going to introduce a distinction here between the D= YMO and LOADng documents and protocols.=0A>>>=0A>>> I'm of the opinion that= the LOADng document is a greatly superior presentation to the DYMO documen= t. (I'm not really interested in why that has come about.)=0A>>>=0A>>> I th= ink that regardless of whether one makes design decisions favouring DYMO or= LOADng where they differ - and let's not forget they overlap a lot - it wo= uld actually be easier to modify the LOADng document to specify DYMO than i= t would be to modify the DYMO document to achieve that. And in practice I t= hink if making decisions it is unlikely that all would favour DYMO over LOA= Dng.=0A>>>=0A>>> So what I think would be best for the WG is not a simply "= option 1" or even (as it may appear I'm suggesting, but =A0I'm not) "option= 2" but rather to agree to take the LOADng document, and a list of where DY= MO and LOADng differ, and thrash out where they do, what the WG reactive pr= otocol should do - either as a definite choice, or as an option (but not to= o many options please- and some could be separate specifications).=0A>>>=0A= >>> This would not of course be LOADng, so we'd have to change the document= name. And there I suggest we have a candidate name - AODVv2. (Which is why= I have recently taken to saying DYMO when referring to that document.) Aft= er all, the one thing we are agreed on is that the protocol being developed= is derived from AODV.=0A>>>=0A>>> The editors of this new document would h= ave to agree that what goes in it is WG consensus (which should follow prop= er technical consideration of the issues). If they found it impossible to h= ave other than their way to do things, they'd have to move on. If that left= no one editing it, obviously we don't have a consensus of people prepared = to do the work and option 3 would win.=0A>>>=0A>>> So now I'm partly off th= e fence I've been sitting on. But only partly. I haven't yet formed a view = on e.g. should this AODVv2 have IRREPs as standard, IRREPs as an option in = the main draft, IRREPs as a separate draft option, no IRREPs. I'd like to m= ove on to those discussions.=0A>>>=0A>>> --=0A>>> Christopher Dearlove=0A>>= > Senior Principal Engineer, Communications Group=0A>>> Communications, Net= works and Image Analysis Capability=0A>>> BAE Systems Advanced Technology C= entre=0A>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK= =0A>>> Tel: +44 1245 242194 | =A0Fax: +44 1245 242124=0A>>> chris.dearlove@= baesystems.com | http://www.baesystems.com=0A>>>=0A>>> BAE Systems (Operati= ons) Limited=0A>>> Registered Office: Warwick House, PO Box 87, Farnborough= Aerospace Centre, Farnborough, Hants, GU14 6YU, UK=0A>>> Registered in Eng= land & Wales No: 1996687=0A>>>=0A>>>=0A>>>=0A>>> **************************= ******************************************=0A>>> This email and any attachm= ents are confidential to the intended=0A>>> recipient and may also be privi= leged. If you are not the intended=0A>>> recipient please delete it from yo= ur system and notify the sender.=0A>>> You should not copy it or use it for= any purpose nor disclose or=0A>>> distribute its contents to any other per= son.=0A>>> ****************************************************************= ****=0A>>>=0A>>> _______________________________________________=0A>>> mane= t mailing list=0A>>> manet@ietf.org=0A>>> https://www.ietf.org/mailman/list= info/manet=0A>>_______________________________________________=0A>>manet ma= iling list=0A>>manet@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/man= et=0A>>=0A>=0A=0A_______________________________________________=0Amanet ma= iling list=0Amanet@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/manet ---1725615817-518105800-1351876587=:86080 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
This seems to make go= od sense.  The name should not be issue.  We need a good solid ba= se to start from.  It would appear that if there are working interoper= able implementation based on the LOADng draft then this indicates that the = draft is implementable.  Again, having read both I could build somethi= ng based on the LOADng draft and I (and I'm only talking for me) couldn't b= ased on the DYMO draft.

I much prefer starting with something simple= and understandable and adding what is missing rather than starting with so= mething more difficult to understand trying to remove things that are not n= eeded.

Jon


From: Ulrich H= erberg <ulrich@herberg.name>
Cc: "Dearlove, Christopher = (UK)" <Chris.Dearlove@baesystems.com>; "manet@ietf.org" <manet@iet= f.org>
Sent: Frida= y, November 2, 2012 10:34 AM
Subj= ect: Re: [manet] A proposal - differentiating the document and t= he protocol

=0A
Hi Abdussalam,

there was indeed some hesitance to change the name from some of the a= uthors (not me). I cannot speak for them here. My intuition is that if the = name of the protocol is the only factor that avoids the reactive protocol f= rom proceeding in the WG, this can be solved.
=0A

A= s far as I can see from the discussions so far, there is a clear consensus = that option 3 is not viable. Now, if we want to proceed with the reactive d= ocument, the question is from which document to start. Chris mentioned that= even if we wanted the specification of 100%, it would be far quicker to st= art from the LOADng draft. I propose that we can start working based o= n the LOADng draft (possibly rename it?), look at each item that is in= DYMO and consider whether and in which way it should be incorporated in th= e draft. 
=0A

Best
Ulrich
=


On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun <<= a rel=3D"nofollow" ymailto=3D"mailto:abdussalambaryun@gmail.com" target=3D"= _blank" href=3D"mailto:abdussalambaryun@gmail.com">abdussalambaryun@gmail.c= om> wrote:
=0A
<= div>Hi Ulrich,
 
I think that Chris's proposa= l was not accepted by LOADng co-authors as I understood from following up t= he WG history (they don't agree to change the name of protocol). As you are= one co-author do I understand that you support the Chris's proposal,
= =0A=0A
AB
On Fri, Nov 2, 2012 a= t 2:41 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
=0A
=0ADear Chris,
=0A
=0Apersonally, what you propose makes= sense to me.
=0A
=0A
=0ARegards
=0AUlrich
=0A

=0AOn Nov 2, 2012, at 4:16, "De= arlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> wrote:
=0A
=0A>= Before making a proposal, I'm going to introduce a distinction here betwee= n the DYMO and LOADng documents and protocols.
=0A>
=0A> I'm of= the opinion that the LOADng document is a greatly superior presentation to= the DYMO document. (I'm not really interested in why that has come about.)=
=0A>
=0A> I think that regardless of whether one makes design = decisions favouring DYMO or LOADng where they differ - and let's not forget= they overlap a lot - it would actually be easier to modify the LOADng docu= ment to specify DYMO than it would be to modify the DYMO document to achiev= e that. And in practice I think if making decisions it is unlikely that all= would favour DYMO over LOADng.
=0A=0A=0A>
=0A> So what I think= would be best for the WG is not a simply "option 1" or even (as it may app= ear I'm suggesting, but  I'm not) "option 2" but rather to agree to ta= ke the LOADng document, and a list of where DYMO and LOADng differ, and thr= ash out where they do, what the WG reactive protocol should do - either as = a definite choice, or as an option (but not too many options please- and so= me could be separate specifications).
=0A=0A=0A>
=0A> This woul= d not of course be LOADng, so we'd have to change the document name. And th= ere I suggest we have a candidate name - AODVv2. (Which is why I have recen= tly taken to saying DYMO when referring to that document.) After all, the o= ne thing we are agreed on is that the protocol being developed is derived f= rom AODV.
=0A=0A=0A>
=0A> The editors of this new document woul= d have to agree that what goes in it is WG consensus (which should follow p= roper technical consideration of the issues). If they found it impossible t= o have other than their way to do things, they'd have to move on. If that l= eft no one editing it, obviously we don't have a consensus of people prepar= ed to do the work and option 3 would win.
=0A=0A=0A>
=0A> So no= w I'm partly off the fence I've been sitting on. But only partly. I haven't= yet formed a view on e.g. should this AODVv2 have IRREPs as standard, IRRE= Ps as an option in the main draft, IRREPs as a separate draft option, no IR= REPs. I'd like to move on to those discussions.
=0A=0A=0A>
=0A>= --
=0A> Christopher Dearlove
=0A> Senior Principal Engineer, C= ommunications Group
=0A> Communications, Networks and Image Analysis = Capability
=0A> BAE Systems Advanced Technology Centre
=0A> Wes= t Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
=0A> Tel: = +44 1245 242194 |  Fax: +44 1245 242124
=0A> chris.dearlove@baesystems.com | http://= www.baesystems.com
=0A>
=0A> BAE Systems (Operations) Limited=0A> Registered Office: Warwick House, PO Box 87, Farnborough Aerospac= e Centre, Farnborough, Hants, GU14 6YU, UK
=0A> Registered in England= & Wales No: 1996687
=0A>
=0A>
=0A>
=0A> ******= **************************************************************
=0A> T= his email and any attachments are confidential to the intended
=0A> r= ecipient and may also be privileged. If you are not the intended
=0A>= recipient please delete it from your system and notify the sender.
=0A&= gt; You should not copy it or use it for any purpose nor disclose or
=0A= > distribute its contents to any other person.
=0A> **************= ******************************************************
=0A>
=0A>= ; _______________________________________________
=0A> manet mailing = list
=0A> manet@ietf.org
=0A> <= a rel=3D"nofollow" target=3D"_blank" href=3D"https://www.ietf.org/mailman/l= istinfo/manet">https://www.ietf.org/mailman/listinfo/manet
=0A______= _________________________________________
=0Amanet mailing list
=0Amanet@ietf.org
=0Ahttps:/= /www.ietf.org/mailman/listinfo/manet
=0A

=0A

=0A

_____________________= __________________________
manet mailing list
manet@ietf.org
https://= www.ietf.org/mailman/listinfo/manet


---1725615817-518105800-1351876587=:86080-- From jvasseur@cisco.com Fri Nov 2 10:17:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EB611E80D7 for ; Fri, 2 Nov 2012 10:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.353 X-Spam-Level: X-Spam-Status: No, score=-10.353 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8nqOxsVujOZ for ; Fri, 2 Nov 2012 10:16:59 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9D60411E80D1 for ; Fri, 2 Nov 2012 10:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10984; q=dns/txt; s=iport; t=1351876619; x=1353086219; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qI6DwhvneYzLl4gkhNbjRCNMroaCNDtKJzeFFJNKvqs=; b=l3MGc1f4XBD4AOG+XvZ2Pn/HE7+JxP4SOxNm1L1mN8Ucvl34G4YkMdZG d81cRN/6NvEBd80oo7DMrhuFs6kIxcpt0rg38ZvwSYJe6KuyBsmACB9no YRyH1EF0RV+qlWhd9/SFS4yjBStbiicnJSDbB+1JgTSfw/elXo73Vm24w 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHT/k1CtJXG8/2dsb2JhbABEgknAbIEIgh4BAQEEAQEBDwFCGQsQAgEIDgMEAQELHQcnCxQJCAIEDgUIFgSHaAubdaATjAEUhUZhA4glnC2Ba4JvgVsJFx4 X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208,217";a="138244008" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 02 Nov 2012 17:16:59 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA2HGv9u006805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 17:16:58 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 12:16:56 -0500 From: "JP Vasseur (jvasseur)" To: Jon Black Thread-Topic: [manet] A proposal - differentiating the document and the protocol Thread-Index: AQHNuR3cQAldmF7ZtU6krGF1ERjKag== Date: Fri, 2 Nov 2012 17:16:56 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204C608@xmb-rcd-x02.cisco.com> References: <1351875496.58211.YahooMailNeo@web160603.mail.bf1.yahoo.com> In-Reply-To: <1351875496.58211.YahooMailNeo@web160603.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--71.985700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204C608xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:17:00 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204C608xmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jon, You did not reply to my former email - will you be in Atlanta to have a tec= hnical discussion based on our email exchanges ? Thanks. JP. On Nov 2, 2012, at 12:58 PM, Jon Black wrote: I agree that from reading both documents it would make much more sense to s= tart with the LOADng draft and enhance it with the items from DYMO that the= working group feel are necessary. The LOADng draft seems like a much better basis to start from. I don't see= why Charlie and group can't start with LOADng as the base. Jon ________________________________ From: "Dearlove, Christopher (UK)" > To: "manet@ietf.org" > Sent: Friday, November 2, 2012 5:16 AM Subject: [manet] A proposal - differentiating the document and the protocol Before making a proposal, I'm going to introduce a distinction here between= the DYMO and LOADng documents and protocols. I'm of the opinion that the LOADng document is a greatly superior presentat= ion to the DYMO document. (I'm not really interested in why that has come a= bout.) I think that regardless of whether one makes design decisions favouring DYM= O or LOADng where they differ - and let's not forget they overlap a lot - i= t would actually be easier to modify the LOADng document to specify DYMO th= an it would be to modify the DYMO document to achieve that. And in practice= I think if making decisions it is unlikely that all would favour DYMO over= LOADng. So what I think would be best for the WG is not a simply "option 1" or even= (as it may appear I'm suggesting, but I'm not) "option 2" but rather to a= gree to take the LOADng document, and a list of where DYMO and LOADng diffe= r, and thrash out where they do, what the WG reactive protocol should do - = either as a definite choice, or as an option (but not too many options plea= se- and some could be separate specifications). This would not of course be LOADng, so we'd have to change the document nam= e. And there I suggest we have a candidate name - AODVv2. (Which is why I h= ave recently taken to saying DYMO when referring to that document.) After a= ll, the one thing we are agreed on is that the protocol being developed is = derived from AODV. The editors of this new document would have to agree that what goes in it i= s WG consensus (which should follow proper technical consideration of the i= ssues). If they found it impossible to have other than their way to do thin= gs, they'd have to move on. If that left no one editing it, obviously we do= n't have a consensus of people prepared to do the work and option 3 would w= in. So now I'm partly off the fence I've been sitting on. But only partly. I ha= ven't yet formed a view on e.g. should this AODVv2 have IRREPs as standard,= IRREPs as an option in the main draft, IRREPs as a separate draft option, = no IRREPs. I'd like to move on to those discussions. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** 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. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204C608xmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <7FD8AC66509DCD44B67B2D27E23CA65B@cisco.com> Content-Transfer-Encoding: quoted-printable Jon,

You did not reply to my former email - will you be in Atlanta to have = a technical discussion based on our email exchanges ?

Thanks.

JP.

On Nov 2, 2012, at 12:58 PM, Jon Black wrote:

I agree that from reading both documents it would make much more sense to s= tart with the LOADng draft and enhance it with the items from DYMO that the= working group feel are necessary.

The LOADng draft seems like a much better basis to start from.  I don'= t see why Charlie and group can't start with LOADng as the base.

Jon


From: "Dearlove, Chris= topher (UK)" <Chri= s.Dearlove@baesystems.com>
To: "manet@ietf.org" <manet@ietf.org>
Sent: Friday, November 2, = 2012 5:16 AM
Subject: [manet] A proposa= l - differentiating the document and the protocol

Before making a proposal, I'm going to introduce a distinction here between= the DYMO and LOADng documents and protocols.

I'm of the opinion that the LOADng document is a greatly superior presentat= ion to the DYMO document. (I'm not really interested in why that has come a= bout.)

I think that regardless of whether one makes design decisions favouring DYM= O or LOADng where they differ - and let's not forget they overlap a lot - i= t would actually be easier to modify the LOADng document to specify DYMO th= an it would be to modify the DYMO document to achieve that. And in practice I think if making decisions it i= s unlikely that all would favour DYMO over LOADng.

So what I think would be best for the WG is not a simply "option 1&quo= t; or even (as it may appear I'm suggesting, but  I'm not) "optio= n 2" but rather to agree to take the LOADng document, and a list of wh= ere DYMO and LOADng differ, and thrash out where they do, what the WG reactive protocol should do - either as a definite choice, or = as an option (but not too many options please- and some could be separate s= pecifications).

This would not of course be LOADng, so we'd have to change the document nam= e. And there I suggest we have a candidate name - AODVv2. (Which is why I h= ave recently taken to saying DYMO when referring to that document.) After a= ll, the one thing we are agreed on is that the protocol being developed is derived from AODV.

The editors of this new document would have to agree that what goes in it i= s WG consensus (which should follow proper technical consideration of the i= ssues). If they found it impossible to have other than their way to do thin= gs, they'd have to move on. If that left no one editing it, obviously we don't have a consensus of people prep= ared to do the work and option 3 would win.

So now I'm partly off the fence I've been sitting on. But only partly. I ha= ven't yet formed a view on e.g. should this AODVv2 have IRREPs as standard,= IRREPs as an option in the main draft, IRREPs as a separate draft option, = no IRREPs. I'd like to move on to those discussions.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687



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

_______________________________________________
manet mailing list
manet@i= etf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A772204C608xmbrcdx02ciscoc_-- From jvasseur@cisco.com Fri Nov 2 10:18:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3532321F8B99 for ; Fri, 2 Nov 2012 10:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.502 X-Spam-Level: X-Spam-Status: No, score=-10.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQOY-hw40BCf for ; Fri, 2 Nov 2012 10:18:31 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6C83121F8AFE for ; Fri, 2 Nov 2012 10:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1805; q=dns/txt; s=iport; t=1351876707; x=1353086307; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/mKW4Cbr3kX6no6CiXmA668URu8jyY74+eL8WboGmh4=; b=P0twgUsRRlImk0xmjeLGUu5RjQQCr0agubnYlJ+s08OKf0QaTfKb62mI NYR/xzVYStRJfejkKyfVMm/dXPxUQYc+KtCuLQM2gSqFdNWHBQIOohLF6 85Re+Be+v0Q8evyp/tUkihN7n/yipF9d7Vy3Gu4pNGk7Z2Rcol0O5NiAk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHT/k1CtJXHB/2dsb2JhbABEwzWBCIIeAQEBAwEBAQEPAVsLBQsCAQgOCgokJwslAgQOBQgMDodiBgubdaAPBIwBG4U/YQOkUoFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208";a="138242348" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 02 Nov 2012 17:18:27 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA2HIQR3028168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 17:18:26 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 12:18:25 -0500 From: "JP Vasseur (jvasseur)" To: Henning Rogge Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuRrYLPVi/cSo/ES1hdb7zda62w== Date: Fri, 2 Nov 2012 17:18:25 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204C638@xmb-rcd-x02.cisco.com> References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--41.374800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <4F22A83826C29645A012CE5845287B1D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:18:32 -0000 On Nov 2, 2012, at 1:00 PM, Henning Rogge wrote: > On Fri, Nov 2, 2012 at 5:55 PM, JP Vasseur (jvasseur) > wrote: >=20 >> See my point Ulrich =85 and I wrote it down several times. There are maj= or >> concerns in using Load-ng with LLNs. Quoting Load-ng: >>=20 >> 3. Applicability Statement >>=20 >> This protocol: >>=20 >> o Is a reactive routing protocol for Mobile Ad hoc NETworks >> (MANETs). >>=20 >> o Is designed to work in networks with dynamic topology in which the >> links may be lossy due to collisions or unstable channel. The use >> cases include vehicular networks, low power and lossy networks, >> community networks, military networks, disaster recovery networks, >> etc. >>=20 >>=20 >> This is where I strongly object, as several other ones on this mailing l= ist. >> One cannot simply forget 4-5 years of hard work from a WG that focussed >> on this use case and concluded that such protocol is not applicable to L= LNs. >=20 > This argument doesn't make any sense at all. JP> Why ? If MANET standardize a protocol with an applicability statement r= elated to the work of another WG, it does make perfect sense, =85 This is precisely why we hav= e charters. >=20 > The work of ROLL is totally irrelevant to the question if LoadNG is > useful both for MANET and for LLNs (which I still consider a special > case without MANET). >=20 > Henning Rogge >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Fri Nov 2 10:20:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F0E21F9022 for ; Fri, 2 Nov 2012 10:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.507 X-Spam-Level: X-Spam-Status: No, score=-10.507 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyRYmsyTY8Uo for ; Fri, 2 Nov 2012 10:20:12 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B72B421F8AFE for ; Fri, 2 Nov 2012 10:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38155; q=dns/txt; s=iport; t=1351876811; x=1353086411; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pT2Lnnj3bSCF22cqorKV+JXzv+XMZcFWqpB1mLz/7Oo=; b=kpgZtVtE6Z60+2zKIWOshMGm7456K6snxHBYKth6KP+CGYr1ADitSCFo ZKiiVBHrUi6eRPZnZBFDff4sFNyVTbrFeQLRcBbc+oH692b0Vo00L1dKk y+BoJqNykj2TuTte9A4jAVQNXLu/qGIN8/xI3CqggxeO/bVslgT/LfKUn E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHT/k1CtJV2Y/2dsb2JhbABEgkmuVZIXgQiCHgEBAQQBAQEPAVsLEAIBCA4DBAEBCxYBBgcnCxMBCQgCBA4FCBMHh1YDDwubdaAPBIsaZ4VaYQOUKI0EgyaBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208,217";a="138245056" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 02 Nov 2012 17:20:11 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA2HKAsw009016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 17:20:10 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 12:20:10 -0500 From: "JP Vasseur (jvasseur)" To: Jon Black Thread-Topic: [manet] LOADng works Thread-Index: AQHNuF9dW2UMul6sMEaXNf6TARakEQ== Date: Fri, 2 Nov 2012 17:20:09 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204C67C@xmb-rcd-x02.cisco.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204AED7@xmb-rcd-x02.cisco.com> <1351876062.61554.YahooMailNeo@web160602.mail.bf1.yahoo.com> In-Reply-To: <1351876062.61554.YahooMailNeo@web160602.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--55.754200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204C67Cxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:20:14 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204C67Cxmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Very unfortunate =85 Hope to meet you in person though. On Nov 2, 2012, at 1:07 PM, Jon Black wrote: no - i have a conflict next week deploying a sensor network. ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: "manet@ietf.org List" > Sent: Friday, November 2, 2012 2:47 AM Subject: Re: [manet] LOADng works Dear Jon, will you be at the next IETF meeting in MANET WG so that we can have a tech= nical discussion ? Thanks. JP. On Nov 2, 2012, at 4:17 AM, JP Vasseur (jvasseur) wrote: Hi Jon, On Nov 1, 2012, at 11:51 PM, Jon Black wrote: In line [Jon2] ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: "manet@ietf.org" > Sent: Thursday, November 1, 2012 12:33 PM Subject: Re: [manet] LOADng works Hi Jon, In line - JP2> On Nov 1, 2012, at 4:32 PM, Jon Black wrote: ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: "manet@ietf.org" >; "thierry.lys@erdfdistribution.fr" > Sent: Thursday, November 1, 2012 3:41 AM Subject: Re: [manet] (no subject) Hi Jon, On Nov 1, 2012, at 12:39 AM, Jon Black wrote: Yes it shows that it does work in a rather large deployment. JP> This is not just a question of "how large" it is =85 but also how dynam= ic. I could show you few hundreds (if not less number of nodes) not working if the traffic pattern is too dynamic. This is a fundamental pr= oblem. [Jon] Are you saying that their AMI PLC deployment was not dynamic? JP2> We do not have any details so I cannot comment on *that* deployment; m= y point was that you can easily show why the number of nodes is NOT the only issues with reactive routing protocols in LLNs. Ta= ke actual traces (which I personally did with actual deployed networks) and simulate the control plane traffic with moderate use traffic = demand and you will see the issue with such routing approach. In other words, even with a relatively small number of nodes, in contrast w= ith other proactive routing protocols, if the user traffic is moderate (not even very high), you clearly see why this reactive routing is ill suit= ed to LLNs. [Jon2] There are plenty of well working LLNs that use reactive protocols su= ch as AODV. I've built and deployed them so perhaps you can't but I can an= d the protocol and network work well. It depends on the type of traffic, n= odes, radio, ... To say that you can only build a working LLN using a proa= ctive protocol is just plain foolish. JP2> Let's try to be gentle and respectful. If you have built such networks= , feel free to share; But this is certainly not the conclusion the ROLL WG shared after 4 years of work. I have heard others say that it works in other deployments as well - just t= he same as you say RPL works in some deployments. JP> I do not not think that we should go in a RPL versus Load-NG debate but= rather try to find a good solution for MANET. That being said, RPL *for* LLNs the the result of a 4-year work with a DT, weekly call= s, interim WG meetings to make it work in LLNs. [Jon] I did not cast this as a RPL vs LOADng debate - you just did. I am s= aying that LOADng works in some scenarios and proof is the EDF deployment i= n their AMI network. JP2> I would be happy to see detailed results and especially the user traff= ic profiles for the reason exposed above. [Jon2] JP actually it doesn't matter! You say that you CANNOT build a work= ing LLN using a reactive protocol. EDF has proved that wrong. They built = one. You can continue to claim that you can't, but there is an existence p= roof. JP3> You keep ignoring my point. Of it matters. I would even make it work w= ith BGP-4. Would you recommend the use of BGP in LLN ? If you deploy a protocol in very specific conditions that do not apply to m= ost LLNs, then you may want to know it before making it an RFC. Please share your results. You keeps saying you will and you we keep askin= g you to - where's the results so they can be reviewed. JP> Once again, I would first like to hear chair's decision. PLEASE note th= at I would be happy to see Load's results too. And just be patient, I just need to find a bit of time to compile results and you will = get many results backing up my claims. Please also refer to the number of discussions prior to designing RPL that took place on the ROLL ma= iling list. Believe me there was a reason not NOT choosing a reactive protocol for LLN (again I am NOT against reactive routing for ot= her use cases at all). Would you ignore the findings of a WG that worked for 4 years on the subject matter ? I guess not =85 Just trying= to raise my voice (as many others on this list) to protect the Internet. [Jon] As others have said - you have it backwards. If you have data that w= ould show that LOADng or a reactive protocol will not work in MANETs please= share it. JP2> Please reread what I wrote ten times =85 I said "LLNs" not "MANET" in = general. On top of that, I do prefer the option 1) for the reasons exposed before (this is the WG document, Charlie made it compatible + other technic= al reasons). You did say LLNs but again you are wrong. There are plenty of LLNS that ha= ve been built using reactive (and proactive) protocols and will continue to= be built using reactive (and proactive protocols). There is no one size f= its all. I prefer to have a debate based on facts and not conjecture and based on te= chnical arguments. That would be very insightful and would help guide this discussion and decision. It woul= d not be prudent to make a decision and then bring out data that would try = to suggest that the decision was incorrect. What findings are you referring to? Where is there a WG document that docu= ments these findings? [Jon2] I noticed you skipped this. JP3> I do not skip anything. I am respectful of the question asked by the c= hair, knowing that their task is to say the least not easy. As soon as required, I will provide lots of data, at least the ones that ca= n be shared, if authorization is given by the owners of these networks. Thanks. JP. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: "manet@ietf.org" >; "thierry.lys@erdfdistribution.fr" > Sent: Wednesday, October 31, 2012 4:09 PM Subject: Re: [manet] (no subject) On Oct 31, 2012, at 6:57 PM, Jon Black wrote: On October 31, 2012 Thierry.Lys wrote: I speak in the name of EDF group. We started first to use LOAD as a routing algorithm and deployed 2000 PLC-m= eters for smart grid purposes in 2011. Taking advantage of this field test,= we have been actively participating to the working group to adopt enhancem= ents in the LOADng specification. We are now extremely pleased with what LOADng is capable of and are confide= nt that future deployements will be equipped with it. This would seem to indicate that LOADng does work and in a rather large dep= loyment. JP> No this means that LoadNG works in *a* network. But the major technical= difference here is that reactive routing is highly impacted by the user traffic =85 If you poll a meter every 24 hours, it may work per= fectly well. Now if you start having more frequent traffic flows you can either cache paths (ending up with more frequent broken paths consi= dering how flappy these networks are, thus leading to more floods =85 very undesirable =85 especially when you have hundreds of meters= sharing a few Kbits/s) or you use short cache timers and you keep flooding :-( If you take actual traces of these networks (both using 1= 5.4g and P1901.2) and you start adjusting the user traffic rate you immediately see the issues in terms of scalability. Yes you can try to miti= gate the undesirable flooding effect to some extends but showing the limits in terms of scalability is easy to show. Note that I MOT against= reactive routing by any means, this is IMO just not applicable to LLNs unless the traffic flows are deterministic and very well knows =85 Les= sons from the past show us how difficult it is to predict user applications. We all started with meter reading to continue with that examp= le and now many utilities wants to use these smart metering networks for a number of applications which different SLA, =85 Hope this helps. Once again, when/if required I would be happy to share man= y results. "We believe in rough consensus and running code" rough consensus : Don't you think we have a rough consensus on LOADng compa= red to DYMO ? 10 authors and major companies are supporters of LOADng. running code : interoperability has been checked with 4 sources and other i= mplementations are in progress. Obviously from the list we don't have rough consensus. We have two alterna= tives each with proponents. The WG should weigh the technical benefits (de= sign, implementation/running code, maturity) of each and the group should = choose a path forward. In my opinion option 3 is not an option - this is the working group shirkin= g its responsibility. This is an option =85 since listed by the chairs. I agree that we should av= oid it, especially when I think we have a very reasonable solution (option1). JP. Jon _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204C67Cxmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7722178DDB309C43AF712CA660522694@cisco.com> Content-Transfer-Encoding: quoted-printable Very unfortunate =85  Hope to meet you in person though.

On Nov 2, 2012, at 1:07 PM, Jon Black wrote:

no - i have a conflict next week deploying a sensor network.

From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org List" <manet@ietf.org>
Sent: Friday, November 2, = 2012 2:47 AM
Subject: Re: [manet] LOADn= g works

Dear Jon,

will you be at the next IETF meeting in MANET WG so that we can have a= technical discussion ?

Thanks.

JP.

On Nov 2, 2012, at 4:17 AM, JP Vasseur (jvasseur) wrote:

Hi Jon,

On Nov 1, 2012, at 11:51 PM, Jon Black wrote:

In line [Jon2]


From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@i= etf.org>
Sent: Thursday, November 1,= 2012 12:33 PM
Subject: Re: [manet] LOADng= works

Hi Jon,

In line - JP2>

On Nov 1, 2012, at 4:32 PM, Jon Black wrote:



From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@i= etf.org>; "thierr= y.lys@erdfdistribution.fr" <thierry.lys@erdfdistribution.fr>
Sent: Thursday, November 1,= 2012 3:41 AM
Subject: Re: [manet] (no su= bject)

Hi Jon,

On Nov 1, 2012, at 12:39 AM, Jon Black wrote:

Yes it shows that it does work in a rather large deployment.&nbs= p;

JP> This is not just a question of "how large" it is =85 = but also how dynamic. I could show you few hundreds (if not less number of = nodes)
not working if the traffic pattern is too dynamic. This is a fundament= al problem.

[Jon] Are you saying that their AMI PLC deployment was not dynamic?

JP2> We do not have any details so I cannot comment on *that* deplo= yment; my point was that you can easily show why the number
of nodes is NOT the only issues with reactive routing protocols in LLN= s. Take actual traces (which I personally did with actual deployed
networks) and simulate the control plane traffic with moderate use tra= ffic demand and you will see the issue with such routing approach.
In other words, even with a relatively small number of nodes, in contr= ast with other proactive routing protocols, if the user traffic is moderate=
(not even very high), you clearly see why this reactive routing is ill= suited to LLNs.

[Jon2] There are plenty of well working LLNs that use reactive protocols su= ch as AODV.  I've built and deployed them so perhaps you can't but I c= an and the protocol and network work well.  It depends on the type of = traffic, nodes, radio, ...  To say that you can only build a working LLN using a proactive protocol is just plain fool= ish.

JP2> Let's try to be gentle and respectful. If you have built such = networks, feel free to share; But this is certainly not the conclusion the = ROLL
WG shared after 4 years of work.



I have heard others say that it works in other deployments as we= ll - just the same as you say RPL works in some deployments.


JP> I do not not think that we should go in a RPL versus Load-NG de= bate but rather try to find a good solution for MANET. That being
said, RPL *for* LLNs the the result of a 4-year work with a DT, weekly= calls, interim WG meetings to make it work in LLNs.

[Jon] I did not cast this as a RPL vs LOADng debate - you just did.  I= am saying that LOADng works in some scenarios and proof is the EDF deploym= ent in their AMI network.

JP2> I would be happy to see detailed results and especially the us= er traffic profiles for the reason exposed above.

[Jon2] JP actually it doesn't matter!  You say that you CANNOT build a= working LLN using a reactive protocol.  EDF has proved that wrong.&nb= sp; They built one.  You can continue to claim that you can't, but the= re is an existence proof.

JP3> You keep ignoring my point. Of it matters. I would even make i= t work with BGP-4. Would you recommend the use of BGP in LLN ?
If you deploy a protocol in very specific conditions that do not apply= to most LLNs, then you may want to know it before making it an RFC.



Please share your results.  You keeps saying you will and you we= keep asking you to - where's the results so they can be reviewed.


JP> Once again, I would first like to hear chair's decision. PLEASE= note that I would be happy to see Load's results too. And just be
patient, I just need to find a bit of time to compile results and you = will get many results backing up my claims. Please also refer to the
number of discussions prior to designing RPL that took place on the RO= LL mailing list. Believe me there was a reason not NOT choosing
a reactive protocol for LLN (again I am NOT against reactive routing f= or other use cases at all). Would you ignore the findings of a WG
that worked for 4 years on the subject matter ? I guess not =85 Just t= rying to raise my voice (as many others on this list) to protect the
Internet.

[Jon] As others have said - you have it backwards.  If you have data t= hat would show that LOADng or a reactive protocol will not work in MANETs p= lease share it. 

JP2> Please reread what I wrote ten times =85 I said "LLNs&quo= t; not "MANET" in general. On top of that, I do prefer the option= 1) for the reasons exposed 
before (this is the WG document, Charlie made it compatible + othe= r technical reasons).

You did say LLNs but again you are wrong.  There are plenty of LLNS th= at have been built using reactive (and proactive) protocols and will contin= ue to be built using reactive (and proactive protocols).  There is no = one size fits all.

I prefer to have a debate based on facts and not conjecture and based on te= chnical arguments.

That would be
very insightful and would help guide this discussion and decision.  It= would not be prudent to make a decision and then bring out data that would= try to suggest that the decision was incorrect.

What findings are you referring to?  Where is there a WG document that= documents these findings?

[Jon2] I noticed you skipped this. 

JP3> I do not skip anything. I am respectful of the question asked = by the chair, knowing that their task is to say the least not easy.
As soon as required, I will provide lots of data, at least the ones th= at can be shared, if authorization is given by the owners of these
networks.

 

Thanks.

JP.

Jon


From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@i= etf.org>; "thierr= y.lys@erdfdistribution.fr" <thierry.lys@erdfdistribution.fr>
Sent: Wednesday, October 31= , 2012 4:09 PM
Subject: Re: [manet] (no su= bject)


On Oct 31, 2012, at 6:57 PM, Jon Black wrote:

On October 31, 2012 Thierry.Lys wrote:

I speak in the name of EDF group.

We started first to use LOAD as a rout= ing algorithm and deployed 2000 PLC-meters for smart grid purposes in 2011.= Taking advantage of this field test, we have been actively participating t= o the working group to adopt enhancements in the LOADng specification.
We are now extremely pleased with what= LOADng is capable of and are confident that future deployements will be eq= uipped with it. 

This would seem to indicate that LOADng does work and in a rather large dep= loyment.

JP> No this means that LoadNG works in *a* network. But the major t= echnical difference here is that reactive routing is highly impacted
by the user traffic =85 If you poll a meter every 24 hours, it may wor= k perfectly well. Now if you start having more frequent traffic flows
you can either cache paths (ending up with more frequent broken paths = considering how flappy these networks are, thus leading to more
floods =85 very undesirable =85 especially when you have hundreds of m= eters sharing a few Kbits/s) or you use short cache timers and you
keep flooding :-( If you take actual traces of these networks (both us= ing 15.4g and P1901.2) and you start adjusting the user traffic rate you
immediately see the issues in terms of scalability. Yes you can try to= mitigate the undesirable flooding effect to some extends but showing =
the limits in terms of scalability is easy to show. Note that I MOT ag= ainst reactive routing by any means, this is IMO just not applicable to
LLNs unless the traffic flows are deterministic and very well knows = =85 Lessons from the past show us how difficult it is to predict user =
applications. We all started with meter reading to continue with that = example and now many utilities wants to use these smart metering 
networks for a number of applications which different SLA, =85 

Hope this helps. Once again, when/if required I would be happy to shar= e many results.



"We believe in rough consensus an= d running code"

rough consensus : Don't you think we h= ave a rough consensus on LOADng compared to DYMO ? 10 authors and major com= panies are supporters of LOADng.

running code : interoperability has be= en checked with 4 sources and other implementations are in progress.

Obviously from the list we don't ha= ve rough consensus.  We have two alternatives each with proponents.&nb= sp; The WG should weigh the technical benefits (design, implementation/runn= ing code, maturity)  of each and the group should choose a path forward.

In my opinion option 3 is not an option - this is the working group shirkin= g its responsibility.

This is an option =85 since listed by the chairs. I agree that we shou= ld avoid it, especially when I think we have a very reasonable solution
(option1).

JP.


Jon

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet






_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet




_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet




--_000_03B78081B371D44390ED6E7BADBB4A772204C67Cxmbrcdx02ciscoc_-- From jvasseur@cisco.com Fri Nov 2 10:21:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D95211E80E0 for ; Fri, 2 Nov 2012 10:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.511 X-Spam-Level: X-Spam-Status: No, score=-10.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id If1EMemNlzWx for ; Fri, 2 Nov 2012 10:21:03 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 58FF911E80AE for ; Fri, 2 Nov 2012 10:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17799; q=dns/txt; s=iport; t=1351876863; x=1353086463; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=KIzKkP4fB5hFQQSpnlLPjMBxkb4xHZLAxhbKqvJmcRU=; b=fi+rxNktza0+5KkTg9hzxRmHlwHY8w/qlE1Wh/0IXBiLLFP3K7MkjElI hxYKCeVpYns3o+95cTGlO8NwskSWm3RiiVHNef0Pedwn41P9EPEnhCrs5 uqfz1BnWekp+ENrhAFY1hnOiH8r6VLSBJs5RJenu+bvJJiNhZ/+yePL3b E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOH/k1CtJV2b/2dsb2JhbABEgknAbIEIgh4BAQEDAQEBAQ8BQhkQCwIBCA4DBAEBCx0HIQYLFAkIAgQBEggWBIdWAwkGC5t1ljcNiVSLGmcUhUZhA5QkjQiDJoFrgm+BWwkXHg X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208,217";a="138242071" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 02 Nov 2012 17:21:02 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA2HL24m025426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 17:21:02 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 12:21:02 -0500 From: "JP Vasseur (jvasseur)" To: Jon Black , Ulrich Herberg , Abdussalam Baryun , "Dearlove, Christopher (UK)" , "manet@ietf.org List" Thread-Topic: [manet] A proposal - differentiating the document and the protocol Thread-Index: AQHNuR5uQAldmF7ZtU6krGF1ERjKag== Date: Fri, 2 Nov 2012 17:21:01 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204C69E@xmb-rcd-x02.cisco.com> References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> <1351876587.86080.YahooMailNeo@web160602.mail.bf1.yahoo.com> In-Reply-To: <1351876587.86080.YahooMailNeo@web160602.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--65.926300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204C69Exmbrcdx02ciscoc_" MIME-Version: 1.0 Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:21:05 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204C69Exmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable so =85 should we start with a completely new document then ? On Nov 2, 2012, at 1:16 PM, Jon Black wrote: This seems to make good sense. The name should not be issue. We need a go= od solid base to start from. It would appear that if there are working int= eroperable implementation based on the LOADng draft then this indicates tha= t the draft is implementable. Again, having read both I could build someth= ing based on the LOADng draft and I (and I'm only talking for me) couldn't = based on the DYMO draft. I much prefer starting with something simple and understandable and adding = what is missing rather than starting with something more difficult to under= stand trying to remove things that are not needed. Jon ________________________________ From: Ulrich Herberg > To: Abdussalam Baryun > Cc: "Dearlove, Christopher (UK)" >; "manet@ietf.org" > Sent: Friday, November 2, 2012 10:34 AM Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol Hi Abdussalam, there was indeed some hesitance to change the name from some of the authors= (not me). I cannot speak for them here. My intuition is that if the name o= f the protocol is the only factor that avoids the reactive protocol from pr= oceeding in the WG, this can be solved. As far as I can see from the discussions so far, there is a clear consensus= that option 3 is not viable. Now, if we want to proceed with the reactive = document, the question is from which document to start. Chris mentioned tha= t even if we wanted the specification of 100%, it would be far quicker to s= tart from the LOADng draft. I propose that we can start working based on th= e LOADng draft (possibly rename it?), look at each item that is in DYMO and= consider whether and in which way it should be incorporated in the draft. Best Ulrich On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun > wrote: Hi Ulrich, I think that Chris's proposal was not accepted by LOADng co-authors as I un= derstood from following up the WG history (they don't agree to change the n= ame of protocol). As you are one co-author do I understand that you support= the Chris's proposal, AB On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg > wrote: Dear Chris, personally, what you propose makes sense to me. Regards Ulrich On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" > wrote: > Before making a proposal, I'm going to introduce a distinction here betwe= en the DYMO and LOADng documents and protocols. > > I'm of the opinion that the LOADng document is a greatly superior present= ation to the DYMO document. (I'm not really interested in why that has come= about.) > > I think that regardless of whether one makes design decisions favouring D= YMO or LOADng where they differ - and let's not forget they overlap a lot -= it would actually be easier to modify the LOADng document to specify DYMO = than it would be to modify the DYMO document to achieve that. And in practi= ce I think if making decisions it is unlikely that all would favour DYMO ov= er LOADng. > > So what I think would be best for the WG is not a simply "option 1" or ev= en (as it may appear I'm suggesting, but I'm not) "option 2" but rather to= agree to take the LOADng document, and a list of where DYMO and LOADng dif= fer, and thrash out where they do, what the WG reactive protocol should do = - either as a definite choice, or as an option (but not too many options pl= ease- and some could be separate specifications). > > This would not of course be LOADng, so we'd have to change the document n= ame. And there I suggest we have a candidate name - AODVv2. (Which is why I= have recently taken to saying DYMO when referring to that document.) After= all, the one thing we are agreed on is that the protocol being developed i= s derived from AODV. > > The editors of this new document would have to agree that what goes in it= is WG consensus (which should follow proper technical consideration of the= issues). If they found it impossible to have other than their way to do th= ings, they'd have to move on. If that left no one editing it, obviously we = don't have a consensus of people prepared to do the work and option 3 would= win. > > So now I'm partly off the fence I've been sitting on. But only partly. I = haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standar= d, IRREPs as an option in the main draft, IRREPs as a separate draft option= , no IRREPs. I'd like to move on to those discussions. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | htt= p://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > ******************************************************************** > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204C69Exmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable so =85 should we start with a completely new document then ?

On Nov 2, 2012, at 1:16 PM, Jon Black wrote:

This seems to make good sense.  The name should not be issue.  We= need a good solid base to start from.  It would appear that if there = are working interoperable implementation based on the LOADng draft then thi= s indicates that the draft is implementable.  Again, having read both I could build something based on the LOADng draft and I (= and I'm only talking for me) couldn't based on the DYMO draft.

I much prefer starting with something simple and understandable and adding = what is missing rather than starting with something more difficult to under= stand trying to remove things that are not needed.

Jon


From: Ulrich Herberg <ulrich@herberg.name>
To: Abdussalam Baryun <= abdussalambaryun@gmail.com>
Cc: "Dearlove, Christ= opher (UK)" <Chris= .Dearlove@baesystems.com>; "m= anet@ietf.org" <manet@ietf.or= g>
Sent: Friday, November 2, = 2012 10:34 AM
Subject: Re: [manet] A pro= posal - differentiating the document and the protocol

Hi Abdussalam,

there was indeed some hesitance to change the name from some of the au= thors (not me). I cannot speak for them here. My intuition is that if the n= ame of the protocol is the only factor that avoids the reactive protocol fr= om proceeding in the WG, this can be solved.

As far as I can see from the discussions so far, there is a clear cons= ensus that option 3 is not viable. Now, if we want to proceed with the reac= tive document, the question is from which document to start. Chris mentione= d that even if we wanted the specification of 100%, it would be far quicker to start from the LOADng draft. I pr= opose that we can start working based on the LOADng draft (possibly re= name it?), look at each item that is in DYMO and consider whether and in wh= ich way it should be incorporated in the draft. 

Best
Ulrich



On Fri, Nov 2, 2012 at 9:17 AM, Abdus= salam Baryun <a= bdussalambaryun@gmail.com> wrote:
Hi Ulrich,
 
I think that Chris's proposal was not accepted by LOADng co-autho= rs as I understood from following up the WG history (they don't agree to ch= ange the name of protocol). As you are one co-author do I understand that y= ou support the Chris's proposal,
AB
On Fri, Nov 2, 2012 at 2:41 PM, Ulric= h Herberg <ulrich@herberg.= name> wrote:
Dear Chris,

personally, what you propose makes sense to me.


Regards
Ulrich

On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesyste= ms.com> wrote:

> Before making a proposal, I'm going to introduce a distinction here be= tween the DYMO and LOADng documents and protocols.
>
> I'm of the opinion that the LOADng document is a greatly superior pres= entation to the DYMO document. (I'm not really interested in why that has c= ome about.)
>
> I think that regardless of whether one makes design decisions favourin= g DYMO or LOADng where they differ - and let's not forget they overlap a lo= t - it would actually be easier to modify the LOADng document to specify DY= MO than it would be to modify the DYMO document to achieve that. And in practice I think if making decisions it i= s unlikely that all would favour DYMO over LOADng.
>
> So what I think would be best for the WG is not a simply "option = 1" or even (as it may appear I'm suggesting, but  I'm not) "= option 2" but rather to agree to take the LOADng document, and a list = of where DYMO and LOADng differ, and thrash out where they do, what the WG reactive protocol should do - either as a definite choice, or = as an option (but not too many options please- and some could be separate s= pecifications).
>
> This would not of course be LOADng, so we'd have to change the documen= t name. And there I suggest we have a candidate name - AODVv2. (Which is wh= y I have recently taken to saying DYMO when referring to that document.) Af= ter all, the one thing we are agreed on is that the protocol being developed is derived from AODV.
>
> The editors of this new document would have to agree that what goes in= it is WG consensus (which should follow proper technical consideration of = the issues). If they found it impossible to have other than their way to do= things, they'd have to move on. If that left no one editing it, obviously we don't have a consensus of people= prepared to do the work and option 3 would win.
>
> So now I'm partly off the fence I've been sitting on. But only partly.= I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as stan= dard, IRREPs as an option in the main draft, IRREPs as a separate draft opt= ion, no IRREPs. I'd like to move on to those discussions.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194= |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | h= ttp://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
>
> ******************************************************************** > 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.
> ******************************************************************** >
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@i= etf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A772204C69Exmbrcdx02ciscoc_-- From hrogge@googlemail.com Fri Nov 2 10:22:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B9411E80F3 for ; Fri, 2 Nov 2012 10:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AT2yYzebfphd for ; Fri, 2 Nov 2012 10:22:54 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E32C311E80E5 for ; Fri, 2 Nov 2012 10:22:53 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so2604819pbb.31 for ; Fri, 02 Nov 2012 10:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=eyRMGhgptyY8i7eIOEPYlaa7gFElH7cFpob0Nv3ebtA=; b=tOUW7NaIBsXfUUxPJ6EEJ8pn847f7T/lPsL/Fyq2/ndSrHjXDHNRIX0F5mCbt/wF8F /6hurPrwj0cMBBaPkcV1RgIGGZ2z6+u+xI6YoxLTl8JyhAXEP4kHUG944Bt53nZCc+6b CrhSHInf/6yPgpsMrtpqpekTPMKdYmkT4y8mQL/HT9GyH4sGQOzCntq8No1OtrV6A5O/ xftG9rubxfmjvfHjM05aIyOMNLgHxkSUvnfsnG6BJ45jACCzDCBViBACY0Y1mWktQJTL A6GjQzdhtQqbBQP9bErczrQYwiREMsuzKLxUnHEV/WcBIPmdYQ1J8maIpREbPugSNjQN sCpQ== Received: by 10.68.219.163 with SMTP id pp3mr8188273pbc.13.1351876973770; Fri, 02 Nov 2012 10:22:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Fri, 2 Nov 2012 10:22:32 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204C638@xmb-rcd-x02.cisco.com> References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C638@xmb-rcd-x02.cisco.com> From: Henning Rogge Date: Fri, 2 Nov 2012 18:22:32 +0100 Message-ID: To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:22:54 -0000 On Fri, Nov 2, 2012 at 6:18 PM, JP Vasseur (jvasseur) wrote: >>> This is where I strongly object, as several other ones on this mailing = list. >>> One cannot simply forget 4-5 years of hard work from a WG that focussed >>> on this use case and concluded that such protocol is not applicable to = LLNs. >> >> This argument doesn't make any sense at all. > > JP> Why ? If MANET standardize a protocol with an applicability statement= related to the work > of another WG, it does make perfect sense, =85 This is precisely why we h= ave charters. And Charters overlap... just look for RFC 5614 as an example. By your own words the effectiveness/overhead of LoadNG in LLNs compared to other protocols will most likely depend on the traffic patterns (which is also true for most other routing protocols, especially Ripple). Well, if this is true then it will be a GOOD thing to have LoadNG standardized so people can choose the better protocol for their use-case. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ulrich@herberg.name Fri Nov 2 10:23:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA81F11E80F7 for ; Fri, 2 Nov 2012 10:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Jx68tvmt1VJ for ; Fri, 2 Nov 2012 10:22:58 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE0E11E80F6 for ; Fri, 2 Nov 2012 10:22:57 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4492675vbb.31 for ; Fri, 02 Nov 2012 10:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TjJzP6OoSXHHbNGs0nBjM8rjLU6EaZpAf4eMQ+ZGlG0=; b=BddjiH8Su81P/La/51qHPil1xCJG13N4vLNO0sQcPqc38POVp/Eour/dEPSiqm1tff mhWYfsXnVnNAW1jI8Mc4htVmG6mE7TF5CxKgWSqe0ODvqqg+ZHNh7nC2PxSnLLwRBLQx J2FKeVlPg5qvCyosMhnKomTV5yZVtA//fBkAU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=TjJzP6OoSXHHbNGs0nBjM8rjLU6EaZpAf4eMQ+ZGlG0=; b=UfcPvdm4RHXY2Qb1sHUjpD8MP3ztxRQs78CG1d1PfAVz2NGubz19eS958zLmlRX92Q MZv3up762pSDFiwGpQTOzV5vf8xgULoRqJZlOxWtkg2GPAL1Lpr7QczwVTGd6CC9S1PM FlGUzggMCU5kVpeF6Yrx+7wuSrmZYXJz0qc5VqBsiG4CatFdXLfNdqzTGZ0cRJkupk4d 5WYYdAaZZgs2sp+vafY4Ln+UBULWKO3SxlMWlVlZlUCQhAIG3lIcMI4XKTTryjLiYYp0 6XGzwxdXahyFCGe/DAFH4GOjH0QiwbpC5ojNHhm9k66V6HIyW9J6sBY5o3jj/KRjE6eP qZ1w== MIME-Version: 1.0 Received: by 10.52.66.10 with SMTP id b10mr2139155vdt.71.1351876977732; Fri, 02 Nov 2012 10:22:57 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Fri, 2 Nov 2012 10:22:57 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> Date: Fri, 2 Nov 2012 10:22:57 -0700 Message-ID: From: Ulrich Herberg To: "JP Vasseur (jvasseur)" Content-Type: multipart/alternative; boundary=20cf3071cf1e09abc204cd866396 X-Gm-Message-State: ALoCoQm82Wj0Gpr0CfP9tEMzojUGMYeX5c0rHhWle+BMw4M25VXCcvLaJw+/1uWg3KqcjC1SQ7Ho Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:23:00 -0000 --20cf3071cf1e09abc204cd866396 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable JP, On Fri, Nov 2, 2012 at 10:09 AM, JP Vasseur (jvasseur) wrote: > > On Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote: > > >>>> JP> This is not just a question of "how large" it is =85 but also ho= w > >>>> dynamic. I could show you few hundreds (if not less number of nodes) > >>>> not working if the traffic pattern is too dynamic. This is a > >>>> fundamental problem. > > > > No, it is a fundamental and well-known characteristic of reactive > > routing protocols. It is a problem only when this behavior doesn't > > match the characteristics of the network in which the reactive routing > > protocol is deployed. > > JP> Indeed =85 and this is why you have a fundamental issue with you have > extremely high BER, PDR, > low bandwidth =85 as we do in LLNs. Flooding in these networks is driven = by > user traffic and of course > is highly undesirable. Slightly increase the use traffic and you will see > the impact on the control plane ... > Yes, but as Timothy mentioned, there are cases where you don't have much user traffic. This is well known. If you have more user traffic, then you may need a proactive protocol. You may not like the idea that some people actually deploy reactive protocols in LLNs, but it's a fact. And your argument, again, makes no sense that you think that DYMO is suitable and LOADng is not. > > > > We've known for at least 15 years that reactive routing protocols are > > more appropriate for light traffic loads and that proactive routing > > protocols are more appropriate with heavier traffic loads. > > JP> This is over-simplying but I see what you mean. > > > Dozens, > > probably hundreds of research papers have reiterated this result. > > I don't know of any that have contradicted this result, although > > some researchers have tried to develop hybrid routing protocols > > (which don't seem to have gained much traction, either in the IETF > > or elsewhere). > > > > Claiming that reactive routing protocols don't scale to heavier traffic > > loads is neither a new result nor particularly insightful -- this hasn'= t > > changed for at least 15 years. > > JP> Let me restate my point. Not sure of what you mean by "heavier" =85 b= ut > if you > flood the network with probes each time you need to find a path in a LLN > you have > a major problem. Well, if you have few communication streams, the few floods are much less heavy than having a proactive protocol exchange control traffic all day. Again, no argument in favor for DYMO and against LOADng. Note also that you only talk about LLN, but we are the [manet] WG. > Of course, there are many ways to control flooding, use caches .. > that are all well-known and by the way hard to tune. But overall, reactiv= e > routing in > *these* networks is simply ill suited. > > > > > I haven't seen any evidence that _no_ LLN will experience the sort of > > light traffic load that matches the characteristics of a reactive > > routing protocol. To the contrary, the deployment experience with > > LOADng suggests that such do networks exist. > > JP> Once again it all depends on the traffic profile. Of course you could > make a > reactive routing protocol work on a LLN as long as the user traffic has > specific > characteristics. Exactly! Thanks for pointing that out. That's the whole point why [manet] is chartered to do both reactive and proactive protocols. > If you carefully analyze the user traffic characteristic in networks > such as smart metering (since this was mentioned on this list), and you > incorporate > additional applications such as DA, .. to mention a few, you will see tha= t > in most of > these networks this simply does not work =85 too many flooding, ending up > not even > converging in some cases, especially when the number of hops gets high > with poor > link quality. > You are not bringing up any new argument that is not known to [manet] for the last 15 years. Reactive protocols only work for certain scenarios. We know that. We have never disputed that. > > > > > At the risk of arguing by analogy, the argument that one can "prove" > > that reactive routing protocols don't work (in LLNs or elsewhere) seems > > to make about as much as sense as "proving" that OSPF doesn't work > > because it doesn't behave well in dynamic environments. The failure of > > OSPF in dynamic environments didn't cause us to abandon OSPF: there are > > many environments in which it works well. > > JP> Not sure that I would have used this analogy :-( OSPF was not designe= d > for highly > dynamic environment indeed *but* we could easily enhance it with fast > failure detection > (+ BFD), fast LSA generation, fast SPF and incremental SPF, Local Fast > Reroute, =85 > because routers had lot of resources, links were highly stable, =85 which= is > by far not the > case of LLNs. > > > Rather, we concluded that we > > needed another routing protocol. In a similar manner, the MANET > > working group, and as far as I have seen pretty much all of the > > research community, concluded that there is a need for both a > > reactive routing protocol and a proactive routing protocol. > > > > Of course, the ROLL working group can decide not to standardize > > a reactive routing protocol. However, that doesn't prove that > > reactive routing protocols don't work (when they match the > > traffic characteristics of the network), that reactive routing > > protocols won't work better than proactive routing protocols > > in some LLNs (based on the characteristics of the traffic load), > > or that reactive routing protocols won't be successfully deployed > > in LLNs. > > JP> Well =85 Think about this: when ROLL was formed, the IESG explicitly = and > rightfully asked > the WG to first prove that none of the existing protocol could be used, > before standardizing a > new protocol (that was the right choice !!). > Right, but that "proof" was never published by the IETF, and as such only an assertion. Moreover, we are not the ROLL WG. > > Could then prove that the current protocol cannot be used in your > environment before suggesting > to standardize a new one. > > Once again, if not applicable to LLNs, I have no problem whatsoever. > People have deployed reactive protocols as a matter of fact in LLNs. So, is the only reason why you like DYMO and not LOADng, because LOADng mentions the word LLN once in the introduction? Best regards Ulrich > > > If fact, the LOADng deployment experience strongly > > suggests that reactive routing protocols _will_ be deployed in > > some LLNs. And, they will be deployed regardless of the ROLL > > working group's decision to not standardize a reactive routing > > protocol. > > JP> And this is perfectly fine, people are free to use any protocol they > want, including proprietary > ones. This does not mean that the IETF should standardize them. > > > > > Claiming that reactive routing protocols don't work because they > > don't scale to higher traffic loads seems, > > JP> Then we need to characterize precisely the limits. > > > at best, a poor > > characterization of well-known research results, and at worst > > a distraction from the question at hand: namely how to proceed > > towards an Internet-standard reactive routing protocol. > > > > -tjs > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf3071cf1e09abc204cd866396 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable JP,
On Fri, Nov 2, 2012 at 10:09 AM, JP V= asseur (jvasseur) <jvasseur@cisco.com> wrote:

On Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote:

>>>> JP> This is not just a question of "how large"= ; it is =85 but also how
>>>> dynamic. I could show you few hundreds (if not less number= of nodes)
>>>> not working if the traffic pattern is too dynamic. This is= a
>>>> fundamental problem.
>
> No, it is a fundamental and well-known characteristic of reactive
> routing protocols. =A0It is a problem only when this behavior doesn= 9;t
> match the characteristics of the network in which the reactive routing=
> protocol is deployed.

JP> Indeed =85 and this is why you have a fundamental issue with y= ou have extremely high BER, PDR,
low bandwidth =85 as we do in LLNs. Flooding in these networks is driven by= user traffic and of course
is highly undesirable. Slightly increase the use traffic and you will see t= he impact on the control plane ...


=
Yes, but as Timothy mentioned, there are cases where you don'= ;t have much user traffic. This is well known. If you have more user traffi= c, then you may need a proactive protocol. You may not like the idea that s= ome people actually deploy reactive protocols in LLNs, but it's a fact.= =A0And your argument, again, makes no sense that you think that DYMO is sui= table and LOADng is not.

=A0
>
> We've known for at least 15 years that reactive routing protocols = are
> more appropriate for light traffic loads and that proactive routing > protocols are more appropriate with heavier traffic loads.

JP> This is over-simplying but I see what you mean.

> Dozens,
> probably hundreds of research papers have reiterated this result.
> I don't know of any that have contradicted this result, although > some researchers have tried to develop hybrid routing protocols
> (which don't seem to have gained much traction, either in the IETF=
> or elsewhere).
>
> Claiming that reactive routing protocols don't scale to heavier tr= affic
> loads is neither a new result nor particularly insightful -- this hasn= 't
> changed for at least 15 years.

JP> Let me restate my point. Not sure of what you mean by "he= avier" =85 but if you
flood the network with probes each time you need to find a path in a LLN yo= u have
a major problem.

Well, if you have few com= munication streams, the few floods are much less heavy than having a proact= ive protocol exchange control traffic all day. Again, no argument in favor = for DYMO and against LOADng. Note also that you only talk about LLN, but we= are the [manet] WG.

=A0
Of course, ther= e are many ways to control flooding, use caches ..
that are all well-known and by the way hard to tune. But overall, reactive = routing in
*these* networks is simply ill suited.

>
> I haven't seen any evidence that _no_ LLN will experience the sort= of
> light traffic load that matches the characteristics of a reactive
> routing protocol. =A0To the contrary, the deployment experience with > LOADng suggests that such do networks exist.

JP> Once again it all depends on the traffic profile. Of course yo= u could make a
reactive routing protocol work on a LLN as long as the user traffic has spe= cific
characteristics.


Exactly! Th= anks for pointing that out. That's the whole point why [manet] is chart= ered to do both reactive and proactive protocols.

=A0
If you carefully analyze the = user traffic characteristic in networks
such as smart metering (since this was mentioned on this list), and you inc= orporate
additional applications such as DA, .. to mention a few, you will see that = in most of
these networks this simply does not work =85 too many flooding, ending up n= ot even
converging in some cases, especially when the number of hops gets high with= poor
link quality.

You are not bringing up a= ny new argument that is not known to [manet] for the last 15 years. Reactiv= e protocols only work for certain scenarios. We know that. We have never di= sputed that.

=A0

>
> At the risk of arguing by analogy, the argument that one can "pro= ve"
> that reactive routing protocols don't work (in LLNs or elsewhere) = seems
> to =A0make about as much as sense as "proving" that OSPF doe= sn't work
> because it doesn't behave well in dynamic environments. =A0The fai= lure of
> OSPF in dynamic environments didn't cause us to abandon OSPF: ther= e are
> many environments in which it works well.

JP> Not sure that I would have used this analogy :-( OSPF was not = designed for highly
dynamic environment indeed *but* we could easily enhance it with fast failu= re detection
(+ BFD), fast LSA generation, fast SPF and incremental SPF, Local Fast Rero= ute, =85
because routers had lot of resources, links were highly stable, =85 which i= s by far not the
case of LLNs.

> Rather, we concluded that we
> needed another routing protocol. =A0In a similar manner, the MANET
> working group, and as far as I have seen pretty much all of the
> research community, concluded that there is a need for both a
> reactive routing protocol and a proactive routing protocol.
>
> Of course, the ROLL working group can decide not to standardize
> a reactive routing protocol. =A0However, that doesn't prove that > reactive routing protocols don't work (when they match the
> traffic characteristics of the network), that reactive routing
> protocols won't work better than proactive routing protocols
> in some LLNs (based on the characteristics of the traffic load),
> or that reactive routing protocols won't be successfully deployed<= br> > in LLNs.

JP> Well =85 Think about this: when ROLL was formed, the IESG expl= icitly and rightfully asked
the WG to first prove that none of the existing protocol could be used, bef= ore standardizing a
new protocol (that was the right choice !!).


Right, but that "proof" was never published = by the IETF, and as such only an assertion. Moreover, we are not the ROLL W= G.
=A0

Could then prove that the current protocol cannot be used in your environme= nt before suggesting
to standardize a new one.

Once again, if not applicable to LLNs, I have no problem whatsoever.
=A0

People have deployed reactive p= rotocols as a matter of fact in LLNs. So, is the only reason why you like D= YMO and not LOADng, because LOADng mentions the word LLN once in the introd= uction?

Best regards
Ulrich

= =A0

> If fact, the LOADng deployment experience strongly
> suggests that reactive routing protocols _will_ be deployed in
> some LLNs. =A0And, they will be deployed regardless of the ROLL
> working group's decision to not standardize a reactive routing
> protocol.

JP> And this is perfectly fine, people are free to use any protoco= l they want, including proprietary
ones. This does not mean that the IETF should standardize them.

>
> Claiming that reactive routing protocols don't work because they > don't scale to higher traffic loads seems,

JP> Then we need to characterize precisely the limits.

> at best, a poor
> characterization of well-known research results, and at worst
> a distraction from the question at hand: namely how to proceed
> towards an Internet-standard reactive routing protocol.
>
> -tjs

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf3071cf1e09abc204cd866396-- From jvasseur@cisco.com Fri Nov 2 10:38:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F0911E80A2 for ; Fri, 2 Nov 2012 10:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.366 X-Spam-Level: X-Spam-Status: No, score=-10.366 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx1TlkxoEU5T for ; Fri, 2 Nov 2012 10:38:40 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B6CFB11E80A5 for ; Fri, 2 Nov 2012 10:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33195; q=dns/txt; s=iport; t=1351877919; x=1353087519; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=O06xNZ0xsFQx2Y3slF1ydAr47xYYUJXEJfKIlOQqgQo=; b=KVs84MGPm4NjHuBDTKyL+mnrJpnK2bC8dGRKVTp+IJqNgQkBCvIjz0Uq 1eu8DbnemACPxy01SldNI9mNvmFZVzw91D9hEWBHCL2GXzCy/K+H1b3aW kGV6C8+UFVAC/p6iBfJClA5T4nxPw26Yn4c/FJOcxwR7FuIuf5ppL0Pik g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4FAJQElFCtJXG8/2dsb2JhbAAqEAqCSa8IiH4BiGSBCIIeAQEBAwEBAQEPAVkCCwULAgEIIgsLAQYHJwsUEQIEDgUIDA6HYgYLLZtKoBaMARAFBoJwgk9hA5cVjT2Ba4JvcmofHg X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208,217";a="138294606" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 02 Nov 2012 17:38:38 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA2Hcc6H026882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 17:38:38 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 12:38:37 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] LOADng works Thread-Index: AQHNuF9dW2UMul6sMEaXNf6TARakEQ== Date: Fri, 2 Nov 2012 17:38:37 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204C845@xmb-rcd-x02.cisco.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--60.794400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204C845xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:38:42 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204C845xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ulrich, On Nov 2, 2012, at 1:22 PM, Ulrich Herberg wrote: JP, On Fri, Nov 2, 2012 at 10:09 AM, JP Vasseur (jvasseur) > wrote: On Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote: >>>> JP> This is not just a question of "how large" it is =85 but also how >>>> dynamic. I could show you few hundreds (if not less number of nodes) >>>> not working if the traffic pattern is too dynamic. This is a >>>> fundamental problem. > > No, it is a fundamental and well-known characteristic of reactive > routing protocols. It is a problem only when this behavior doesn't > match the characteristics of the network in which the reactive routing > protocol is deployed. JP> Indeed =85 and this is why you have a fundamental issue with you have e= xtremely high BER, PDR, low bandwidth =85 as we do in LLNs. Flooding in these networks is driven by= user traffic and of course is highly undesirable. Slightly increase the use traffic and you will see t= he impact on the control plane ... Yes, but as Timothy mentioned, there are cases where you don't have much us= er traffic. JP> Then if you recognize that reactive routing is an issue when user traff= ic increases, this is a good start. When do you put the limit ? By the way, the topology is another argument, so does the bandwidth. Let me be even more specific: * Case 1: 75KBits/s, P2MP traffic (not referring to multicast), small broad= cast domains, meter readout every 24h. Certainly you can deploy a reactive routing protocol ? Still I do not see w= hy you would not use a pro-active routing but this is another question Now what if you move to case 2: * Unsolicited alarms using meters, DA, EV traffic for bill roaming ? Well y= ou do not have a major problem and when designing protocol we need to take this into accou= nt. Please see RFC RFC 5548 (draft-ietf-roll-urban-routing-reqs) Routing Requirements for Urban Low-Pow= er and Lossy Networks 2009-05 RFC 5548 (Informational) = Adrian Farrel RFC 5673 (draft-ietf-roll-indus-routing-reqs) Industrial Routing Requirements in Low= -Power and Lossy Networks 2009-10 RFC 5673 (Informational) = Adrian Farrel RFC 5826 (draft-ietf-roll-home-routing-reqs) Home Automation Routing Requirements in Low-Po= wer and Lossy Networks 2010-04 RFC 5826 (Informational) Errata = Adrian Farrel RFC 5867 (draft-ietf-roll-building-routing-reqs) Building Automation Routing Requiremen= ts in Low-Power and Lossy Networks 2010-06 RFC 5867 (Informational) * or Case 3 =3D Case 1 but with 5Kbits/s over PLC (at best) and number of h= ops >10. Try to compute the control plane overhead with reactive routing, you will see. This is well known. If you have more user traffic, then you may need a proa= ctive protocol. You may not like the idea that some people actually deploy = reactive protocols in LLNs, but it's a fact. JP> Once again, people are free to deploy whatever they want - REQUESTING t= he IETF to standardize it is different. And your argument, again, makes no sense that you think that DYMO is suitab= le and LOADng is not. JP> I never asked from dropping reactive routing from the MANET charter (I = opted for option 1 not 3). > > We've known for at least 15 years that reactive routing protocols are > more appropriate for light traffic loads and that proactive routing > protocols are more appropriate with heavier traffic loads. JP> This is over-simplying but I see what you mean. > Dozens, > probably hundreds of research papers have reiterated this result. > I don't know of any that have contradicted this result, although > some researchers have tried to develop hybrid routing protocols > (which don't seem to have gained much traction, either in the IETF > or elsewhere). > > Claiming that reactive routing protocols don't scale to heavier traffic > loads is neither a new result nor particularly insightful -- this hasn't > changed for at least 15 years. JP> Let me restate my point. Not sure of what you mean by "heavier" =85 but= if you flood the network with probes each time you need to find a path in a LLN yo= u have a major problem. Well, if you have few communication streams, the few floods are much less h= eavy than having a proactive protocol exchange control traffic all day. JP> Please careful read RFC6550 and companion documents, this is not what t= he protocol does. But we can take it off-line, this is not the right mailing list. Again, no argument in favor for DYMO and against LOADng. Note also that you= only talk about LLN, but we are the [manet] WG. Of course, there are many ways to control flooding, use caches .. that are all well-known and by the way hard to tune. But overall, reactive = routing in *these* networks is simply ill suited. > > I haven't seen any evidence that _no_ LLN will experience the sort of > light traffic load that matches the characteristics of a reactive > routing protocol. To the contrary, the deployment experience with > LOADng suggests that such do networks exist. JP> Once again it all depends on the traffic profile. Of course you could m= ake a reactive routing protocol work on a LLN as long as the user traffic has spe= cific characteristics. Exactly! Thanks for pointing that out. That's the whole point why [manet] i= s chartered to do both reactive and proactive protocols. JP> Again I am not saying that reactive cannot be very useful in some envir= onments *but* not in LLNs. If you carefully analyze the user traffic characteristic in networks such as smart metering (since this was mentioned on this list), and you inc= orporate additional applications such as DA, .. to mention a few, you will see that = in most of these networks this simply does not work =85 too many flooding, ending up n= ot even converging in some cases, especially when the number of hops gets high with= poor link quality. You are not bringing up any new argument that is not known to [manet] for t= he last 15 years. Reactive protocols only work for certain scenarios. We kn= ow that. We have never disputed that. JP> Excellent; the only difference is that now we have large scale deployed= LLN, so we much better understand the dynamics and why a protocol such as Load-ng is ill suited to these networks. > > At the risk of arguing by analogy, the argument that one can "prove" > that reactive routing protocols don't work (in LLNs or elsewhere) seems > to make about as much as sense as "proving" that OSPF doesn't work > because it doesn't behave well in dynamic environments. The failure of > OSPF in dynamic environments didn't cause us to abandon OSPF: there are > many environments in which it works well. JP> Not sure that I would have used this analogy :-( OSPF was not designed = for highly dynamic environment indeed *but* we could easily enhance it with fast failu= re detection (+ BFD), fast LSA generation, fast SPF and incremental SPF, Local Fast Rero= ute, =85 because routers had lot of resources, links were highly stable, =85 which i= s by far not the case of LLNs. > Rather, we concluded that we > needed another routing protocol. In a similar manner, the MANET > working group, and as far as I have seen pretty much all of the > research community, concluded that there is a need for both a > reactive routing protocol and a proactive routing protocol. > > Of course, the ROLL working group can decide not to standardize > a reactive routing protocol. However, that doesn't prove that > reactive routing protocols don't work (when they match the > traffic characteristics of the network), that reactive routing > protocols won't work better than proactive routing protocols > in some LLNs (based on the characteristics of the traffic load), > or that reactive routing protocols won't be successfully deployed > in LLNs. JP> Well =85 Think about this: when ROLL was formed, the IESG explicitly an= d rightfully asked the WG to first prove that none of the existing protocol could be used, bef= ore standardizing a new protocol (that was the right choice !!). Right, but that "proof" was never published by the IETF, and as such only a= n assertion. Moreover, we are not the ROLL WG. JP> I was giving you some feed-back, since LLNs are explicitly listed in th= e Load-ng document. Could then prove that the current protocol cannot be used in your environme= nt before suggesting to standardize a new one. Once again, if not applicable to LLNs, I have no problem whatsoever. People have deployed reactive protocols as a matter of fact in LLNs. So, is= the only reason why you like DYMO and not LOADng, because LOADng mentions = the word LLN once in the introduction? JP> Not at all. I was proposing the following: 1) Build a reactive routing for MANET 2) Start with the WG document (DYMO), call it AODVv2 to avoid conflicts, 3) Add all ideas that we (as a WG) want to keep that came from Load-ng and = any why not new ideas 4) Identify what can be made optional versus mandatory 5) Move fast, in a constructive collective fashion. Makes sense ? Thanks. JP. Best regards Ulrich > If fact, the LOADng deployment experience strongly > suggests that reactive routing protocols _will_ be deployed in > some LLNs. And, they will be deployed regardless of the ROLL > working group's decision to not standardize a reactive routing > protocol. JP> And this is perfectly fine, people are free to use any protocol they wa= nt, including proprietary ones. This does not mean that the IETF should standardize them. > > Claiming that reactive routing protocols don't work because they > don't scale to higher traffic loads seems, JP> Then we need to characterize precisely the limits. > at best, a poor > characterization of well-known research results, and at worst > a distraction from the question at hand: namely how to proceed > towards an Internet-standard reactive routing protocol. > > -tjs _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204C845xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Ulrich,

On Nov 2, 2012, at 1:22 PM, Ulrich Herberg wrote:

JP,

On Fri, Nov 2, 2012 at 10:09 AM, JP Vasseur (jva= sseur) <jvasseur@cisco.= com> wrote:

On Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote:

>>>> JP> This is not just a question of "how large"= ; it is =85 but also how
>>>> dynamic. I could show you few hundreds (if not less number= of nodes)
>>>> not working if the traffic pattern is too dynamic. This is= a
>>>> fundamental problem.
>
> No, it is a fundamental and well-known characteristic of reactive
> routing protocols.  It is a problem only when this behavior doesn= 't
> match the characteristics of the network in which the reactive routing=
> protocol is deployed.

JP> Indeed =85 and this is why you have a fundamental issue with you hav= e extremely high BER, PDR,
low bandwidth =85 as we do in LLNs. Flooding in these networks is driven by= user traffic and of course
is highly undesirable. Slightly increase the use traffic and you will see t= he impact on the control plane ...


Yes, but as Timothy mentioned, there are cases where you don't have mu= ch user traffic.

JP> Then if you recognize that reactive routing is an issue when us= er traffic increases, this is a good start.
When do you put the limit ?
By the way, the topology is another argument, so does the bandwidth.

Let me be even more specific:
* Case 1: 75KBits/s, P2MP traffic (not referring to multicast), small = broadcast domains, meter readout every 24h.
Certainly you can deploy a reactive routing protocol ? Still I do not = see why you would not use a pro-active routing 
but this is another question
Now what if you move to case 2:
* Unsolicited alarms using meters, DA, EV traffic for bill roaming ? W= ell you do not have
a major problem and when designing protocol we need to take this into = account. Please see RFC

RFC 5548 
(draft-ietf-roll-urban-routing-reqs)		 Routing Requirements for Urban Low-Power and Lossy Networks 2009-05 RFC 5548 (Informational) Adrian Farrel
RFC 5673 
(draft-ietf-roll-indus-routing-reqs)		 Industrial Routing Requirements in Low-Power and Lossy Networks 2009-10 RFC 5673 (Informational) Adrian Farrel
RFC 5826 
(draft-ietf-roll-home-routing-reqs)		 Home Automation Routing Requirements in Low-Power and Lossy Networks 2010-04 RFC 5826 (Informational) 
Errata		 Adrian Farrel
RFC 5867 
(draft-ietf-roll-building-routing-reqs)		 Building Automation Routing Requirements in Low-Power and Lossy Networks 2010-06 RFC 5867 (Informational)

* or Case 3 =3D Case 1 but with 5Kbits/s over PLC (at best) and number= of hops >10. Try to compute the control plane
overhead with reactive routing, you will see.

This is well known. If you have more user traffic, then you may need a= proactive protocol. You may not like the idea that some people actually de= ploy reactive protocols in LLNs, but it's a fact. 

JP> Once again, people are free to deploy whatever they want - REQU= ESTING the IETF to standardize it is different.

And your argument, again, makes no sense that you think that DYMO is s= uitable and LOADng is not.


JP> I never asked from dropping reactive routing from the MANET cha= rter (I opted for option 1 not 3).

 
>
> We've known for at least 15 years that reactive routing protocols are<= br> > more appropriate for light traffic loads and that proactive routing > protocols are more appropriate with heavier traffic loads.

JP> This is over-simplying but I see what you mean.

> Dozens,
> probably hundreds of research papers have reiterated this result.
> I don't know of any that have contradicted this result, although
> some researchers have tried to develop hybrid routing protocols
> (which don't seem to have gained much traction, either in the IETF
> or elsewhere).
>
> Claiming that reactive routing protocols don't scale to heavier traffi= c
> loads is neither a new result nor particularly insightful -- this hasn= 't
> changed for at least 15 years.

JP> Let me restate my point. Not sure of what you mean by "heavier&= quot; =85 but if you
flood the network with probes each time you need to find a path in a LLN yo= u have
a major problem.

Well, if you have few communication streams, the few floods are much l= ess heavy than having a proactive protocol exchange control traffic all day= .

JP> Please careful read RFC6550 and companion documents, this is no= t what the protocol does.
But we can take it off-line, this is not the right mailing list.

Again, no argument in favor for DYMO and against LOADng. Note also tha= t you only talk about LLN, but we are the [manet] WG.

 
Of course, there are many ways to control flooding, use caches ..
that are all well-known and by the way hard to tune. But overall, reactive = routing in
*these* networks is simply ill suited.

>
> I haven't seen any evidence that _no_ LLN will experience the sort of<= br> > light traffic load that matches the characteristics of a reactive
> routing protocol.  To the contrary, the deployment experience wit= h
> LOADng suggests that such do networks exist.

JP> Once again it all depends on the traffic profile. Of course you coul= d make a
reactive routing protocol work on a LLN as long as the user traffic has spe= cific
characteristics.


Exactly! Thanks for pointing that out. That's the whole point why [man= et] is chartered to do both reactive and proactive protocols.


JP> Again I am not saying that reactive cannot be very useful in so= me environments *but* not in LLNs.

 
If you carefully analyze the user traffic characteristic in networks
such as smart metering (since this was mentioned on this list), and you inc= orporate
additional applications such as DA, .. to mention a few, you will see that = in most of
these networks this simply does not work =85 too many flooding, ending up n= ot even
converging in some cases, especially when the number of hops gets high with= poor
link quality.

You are not bringing up any new argument that is not known to [manet] = for the last 15 years. Reactive protocols only work for certain scenarios. = We know that. We have never disputed that.

JP> Excellent; the only difference is that now we have large scale = deployed LLN, so we much better understand the dynamics
and why a protocol such as Load-ng is ill suited to these networks.

 

>
> At the risk of arguing by analogy, the argument that one can "pro= ve"
> that reactive routing protocols don't work (in LLNs or elsewhere) seem= s
> to  make about as much as sense as "proving" that OSPF = doesn't work
> because it doesn't behave well in dynamic environments.  The fail= ure of
> OSPF in dynamic environments didn't cause us to abandon OSPF: there ar= e
> many environments in which it works well.

JP> Not sure that I would have used this analogy :-( OSPF was not design= ed for highly
dynamic environment indeed *but* we could easily enhance it with fast failu= re detection
(+ BFD), fast LSA generation, fast SPF and incremental SPF, Local Fast = Reroute, =85
because routers had lot of resources, links were highly stable, =85 which i= s by far not the
case of LLNs.

> Rather, we concluded that we
> needed another routing protocol.  In a similar manner, the MANET<= br> > working group, and as far as I have seen pretty much all of the
> research community, concluded that there is a need for both a
> reactive routing protocol and a proactive routing protocol.
>
> Of course, the ROLL working group can decide not to standardize
> a reactive routing protocol.  However, that doesn't prove that > reactive routing protocols don't work (when they match the
> traffic characteristics of the network), that reactive routing
> protocols won't work better than proactive routing protocols
> in some LLNs (based on the characteristics of the traffic load),
> or that reactive routing protocols won't be successfully deployed
> in LLNs.

JP> Well =85 Think about this: when ROLL was formed, the IESG explicitly= and rightfully asked
the WG to first prove that none of the existing protocol could be used, bef= ore standardizing a
new protocol (that was the right choice !!).


Right, but that "proof" was never published by the IETF, and= as such only an assertion. Moreover, we are not the ROLL WG.
 

JP> I was giving you some feed-back, since LLNs are explicitly list= ed in the Load-ng document.


Could then prove that the current protocol cannot be used in your environme= nt before suggesting
to standardize a new one.

Once again, if not applicable to LLNs, I have no problem whatsoever.
 

People have deployed reactive protocols as a matter of fact in LLNs. S= o, is the only reason why you like DYMO and not LOADng, because LOADng ment= ions the word LLN once in the introduction?

JP> Not at all. I was proposing the following:

1) Build a reactive routing for MANET
2) Start with the WG document (DYMO), call it AODVv2 to avoid conflict= s,
3) Add all ideas that we (as a WG) want to keep that came from Load-ng= and any why not new ideas
4) Identify what can be made optional versus mandatory
5) Move fast, in a constructive collective fashion.
Makes sense ?

Thanks.

JP.


Best regards
Ulrich

 

> If fact, the LOADng deployment experience strongly
> suggests that reactive routing protocols _will_ be deployed in
> some LLNs.  And, they will be deployed regardless of the ROLL
> working group's decision to not standardize a reactive routing
> protocol.

JP> And this is perfectly fine, people are free to use any protocol they= want, including proprietary
ones. This does not mean that the IETF should standardize them.

>
> Claiming that reactive routing protocols don't work because they
> don't scale to higher traffic loads seems,

JP> Then we need to characterize precisely the limits.

> at best, a poor
> characterization of well-known research results, and at worst
> a distraction from the question at hand: namely how to proceed
> towards an Internet-standard reactive routing protocol.
>
> -tjs

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--_000_03B78081B371D44390ED6E7BADBB4A772204C845xmbrcdx02ciscoc_-- From jvasseur@cisco.com Fri Nov 2 10:39:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEDF11E80E2 for ; Fri, 2 Nov 2012 10:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.378 X-Spam-Level: X-Spam-Status: No, score=-10.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpPVGK6DuFnF for ; Fri, 2 Nov 2012 10:39:50 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 595F411E80E0 for ; Fri, 2 Nov 2012 10:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1449; q=dns/txt; s=iport; t=1351877990; x=1353087590; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RUjcMAnGPc4pT/kFKY0XF7iRZoD5x1TOBYJbmWaSGDI=; b=IoBGocEHq6fjAXvokjUTlH4AAqZEugjqzzEatKBstn+mg4g/X8fXEsGh uSt9nn2UG/XDcRc2B0yu85HXB4V+Z/14F7KbpwT5CvcY2YmYOKbQmPH/6 MlE2EqKNXjEXMRfTDgWH7Qxl3yy69lnC7zbBB5Gew8nPmOHSjdRfbUA5o s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJQElFCtJV2a/2dsb2JhbABEwzSBCIIeAQEBAwESAVsLBQsCAQgOCgokMiUCBA4FCBqHYgacAqAWjAGFWmEDpFKBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208";a="138294930" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 02 Nov 2012 17:39:49 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA2Hdn8F018453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 17:39:49 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 12:39:49 -0500 From: "JP Vasseur (jvasseur)" To: Henning Rogge Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuRrYLPVi/cSo/ES1hdb7zda62w== Date: Fri, 2 Nov 2012 17:39:49 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204C877@xmb-rcd-x02.cisco.com> References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C638@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--33.594300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:39:51 -0000 On Nov 2, 2012, at 1:22 PM, Henning Rogge wrote: > On Fri, Nov 2, 2012 at 6:18 PM, JP Vasseur (jvasseur) > wrote: >>>> This is where I strongly object, as several other ones on this mailing= list. >>>> One cannot simply forget 4-5 years of hard work from a WG that focusse= d >>>> on this use case and concluded that such protocol is not applicable to= LLNs. >>>=20 >>> This argument doesn't make any sense at all. >>=20 >> JP> Why ? If MANET standardize a protocol with an applicability statemen= t related to the work >> of another WG, it does make perfect sense, =85 This is precisely why we = have charters. >=20 > And Charters overlap... just look for RFC 5614 as an example. >=20 > By your own words the effectiveness/overhead of LoadNG in LLNs > compared to other protocols will most likely depend on the traffic > patterns (which is also true for most other routing protocols, > especially Ripple). JP> This is technically incorrect - RPL/OSPF/BGP =85 performances are not d= irectly a function of the user traffic. >=20 > Well, if this is true then it will be a GOOD thing to have LoadNG > standardized so people can choose the better protocol for their > use-case. >=20 > Henning Rogge > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From hrogge@googlemail.com Fri Nov 2 10:58:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A128F1F0C69 for ; Fri, 2 Nov 2012 10:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+d3fO44WzmJ for ; Fri, 2 Nov 2012 10:58:23 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 357A01F0C5F for ; Fri, 2 Nov 2012 10:58:23 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so2629332pad.31 for ; Fri, 02 Nov 2012 10:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=mrGfJY02gh4kBthrzaaxGFA8J1xXf55QJ3vbKvjWMXk=; b=d6zvpAkYprZ9T4VuM5wK659w6y4LggZyMmZAFem3OCpTrmp9+xGn90QVoBRiLDoon/ IlaElYio2eC6KObUQDjZdO25KTWb9sPhSXomF+2Oa+aU3l/hpVNbrIcYwAFKvsWxNBYN zmjDeyHynksAITcN3cNsHAjpwDU6A52L7Prm9K7NMiAlBRJGprOoT9L9dKijs29gySbK YhtYwOXhRVSxQOlu5mSvfRLvW05yMu7/1cZd0sTwglWtJS7MDB9g0thDktFD4GHGeGEg km82/9qBrRc2gauFMzYHlz3LFOpLjdy/R1JJrsr7OE/9oxKPb+AqaIUQaijft7lzix0v 6VSw== Received: by 10.66.85.227 with SMTP id k3mr7193709paz.79.1351879102965; Fri, 02 Nov 2012 10:58:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Fri, 2 Nov 2012 10:58:02 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204C877@xmb-rcd-x02.cisco.com> References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C638@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C877@xmb-rcd-x02.cisco.com> From: Henning Rogge Date: Fri, 2 Nov 2012 18:58:02 +0100 Message-ID: To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:58:23 -0000 On Fri, Nov 2, 2012 at 6:39 PM, JP Vasseur (jvasseur) wrote: >> By your own words the effectiveness/overhead of LoadNG in LLNs >> compared to other protocols will most likely depend on the traffic >> patterns (which is also true for most other routing protocols, >> especially Ripple). > > JP> This is technically incorrect - RPL/OSPF/BGP =85 performances are not= directly a function > of the user traffic. Ripple is a tree-based routing protocol. its really good when sending traffic towards the local root, not as good (but still good) when sending traffic from the root to its nodes, bad when you send traffic between two nodes with the same root and really bad when sending traffic between nodes that are not part of the same root tree. I would say its performance depends on the user traffic pattern. The overhead (as a comparison between control plane traffic and data plane traffic) is of course always different for each protocol depending on the user traffic. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From christopher.dearlove@googlemail.com Fri Nov 2 11:02:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122521F0C84 for ; Fri, 2 Nov 2012 11:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCddhWeKhYlO for ; Fri, 2 Nov 2012 11:02:58 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id DCD0D1F0C4C for ; Fri, 2 Nov 2012 11:02:57 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so1252706wib.13 for ; Fri, 02 Nov 2012 11:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=vwCKi+WGmoDdk3HmJ+buwzb74zQE/vdX7YvUTKjyaVM=; b=qIzUzobwZ4CP8/wUExFBKAgJy+b+nOMFit5ESC4PvYTP/pyJOPqDqxwmK388S618s0 B1ab1PJOvTwDtVgsKfb34cAtmo+xf2MYyfmLhXbz0DUyBT5w5EAbS2oNbGouMmmbonO1 bq4zqv4P6tj0OmfTlzSs0+QPATseRJMB/RY0VehUX5V7NAxaWGGp7zp0FH1fs1774vj5 nDhWcSTd1iFuR5GBSroe5pS2661LgzcW5tBIxjHXEM4U0NGwPXA2hbOf3POTp99jLKLa xgDu+P+8TvkVF59tTwPNiQrq600O8GUGNJBNnJ0y8sRhair13aj3xCIwoPZkpAUZer0e tmPQ== Received: by 10.216.193.136 with SMTP id k8mr911396wen.188.1351879377046; Fri, 02 Nov 2012 11:02:57 -0700 (PDT) Received: from [10.209.218.117] ([82.132.139.134]) by mx.google.com with ESMTPS id f1sm3240836wiy.2.2012.11.02.11.02.55 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 11:02:56 -0700 (PDT) References: <03B78081B371D44390ED6E7BADBB4A772204C0B9@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204C0B9@xmb-rcd-x02.cisco.com> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8B117) From: Christopher Dearlove Date: Fri, 2 Nov 2012 18:02:56 +0000 To: "JP Vasseur (jvasseur)" Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:02:59 -0000 However the LOADng document is much better written, and a much better starti= ng point. --=20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) On 2 Nov 2012, at 16:30, "JP Vasseur (jvasseur)" wrote:= >=20 > On Nov 2, 2012, at 12:16 PM, Dearlove, Christopher (UK) wrote: >=20 >> Before making a proposal, I'm going to introduce a distinction here betwe= en the DYMO and LOADng documents and protocols. >>=20 >> I'm of the opinion that the LOADng document is a greatly superior present= ation to the DYMO document. (I'm not really interested in why that has come a= bout.) >>=20 >> I think that regardless of whether one makes design decisions favouring D= YMO or LOADng where they differ - and let's not forget they overlap a lot - i= t would actually be easier to modify the LOADng document to specify DYMO tha= n it would be to modify the DYMO document to achieve that. And in practice I= think if making decisions it is unlikely that all would favour DYMO over LO= ADng. >>=20 >> So what I think would be best for the WG is not a simply "option 1" or ev= en (as it may appear I'm suggesting, but I'm not) "option 2" but rather to a= gree to take the LOADng document, and a list of where DYMO and LOADng differ= , and thrash out where they do, what the WG reactive protocol should do - ei= ther as a definite choice, or as an option (but not too many options please-= and some could be separate specifications). >>=20 >> This would not of course be LOADng, so we'd have to change the document n= ame. And there I suggest we have a candidate name - AODVv2. (Which is why I h= ave recently taken to saying DYMO when referring to that document.) After al= l, the one thing we are agreed on is that the protocol being developed is de= rived from AODV. >=20 > JP> I would be extremely supportive of this, just do the reverse BUT we wo= uld end up with the same results: > * Take the DYMO document > * Change the name to AODVv2 > * List where both protocol differ > * Use options when required. >=20 > I think that this is also what Charlie proposed. >=20 >>=20 >> The editors of this new document would have to agree that what goes in it= is WG consensus (which should follow proper technical consideration of the i= ssues). If they found it impossible to have other than their way to do thing= s, they'd have to move on. If that left no one editing it, obviously we don'= t have a consensus of people prepared to do the work and option 3 would win.= >>=20 >> So now I'm partly off the fence I've been sitting on. But only partly. I h= aven't yet formed a view on e.g. should this AODVv2 have IRREPs as standard,= IRREPs as an option in the main draft, IRREPs as a separate draft option, n= o IRREPs. I'd like to move on to those discussions. >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >>=20 >> ******************************************************************** >> 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. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Fri Nov 2 11:10:27 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8F61F0C7F for ; Fri, 2 Nov 2012 11:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.516 X-Spam-Level: X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmUaxBRrOTRN for ; Fri, 2 Nov 2012 11:10:21 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1641F0C5C for ; Fri, 2 Nov 2012 11:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1503; q=dns/txt; s=iport; t=1351879821; x=1353089421; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tMicamsOeW4LdCwuBDI6RyzCryTle6MQmsHhwT5v750=; b=XRelGNxwLQHGGiCCjrkADJ7O7uAugLnJF3GPzfg3rIbxZwkESthLpXZQ fZhlzZWfnzcFtOJV6dawhNOru4ASdlCUdgT7adhGf1uVCw0y3sKTlFyyl IiYBxx61v7B7FPLDm8lDdXR9DYeWpk/23gyvPV0faJzGc/PwCdLR+lHjf U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIkLlFCtJV2d/2dsb2JhbABEwzSBCIIeAQEBAwESAWYFCwIBCA4KCiQyJQIEDgUIGodiBpwEoBSMAYVaYQOkUoFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208";a="138305522" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 02 Nov 2012 18:10:19 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA2IAJtn017771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 18:10:19 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 13:10:19 -0500 From: "JP Vasseur (jvasseur)" To: Henning Rogge Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuRrYLPVi/cSo/ES1hdb7zda62w== Date: Fri, 2 Nov 2012 18:10:18 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204CB91@xmb-rcd-x02.cisco.com> References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C638@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C877@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--31.565600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:10:27 -0000 Again your assumption are not correct - look at storing mode with OF to inc= rease connectivity if required, for P2P. But again =85 not appropriate for this list. On Nov 2, 2012, at 6:58 PM, Henning Rogge wrote: > On Fri, Nov 2, 2012 at 6:39 PM, JP Vasseur (jvasseur) > wrote: >>> By your own words the effectiveness/overhead of LoadNG in LLNs >>> compared to other protocols will most likely depend on the traffic >>> patterns (which is also true for most other routing protocols, >>> especially Ripple). >>=20 >> JP> This is technically incorrect - RPL/OSPF/BGP =85 performances are no= t directly a function >> of the user traffic. >=20 > Ripple is a tree-based routing protocol. >=20 > its really good when sending traffic towards the local root, not as > good (but still good) when sending traffic from the root to its nodes, > bad when you send traffic between two nodes with the same root and > really bad when sending traffic between nodes that are not part of the > same root tree. >=20 > I would say its performance depends on the user traffic pattern. >=20 > The overhead (as a comparison between control plane traffic and data > plane traffic) is of course always different for each protocol > depending on the user traffic. >=20 > Henning Rogge > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From jvasseur@cisco.com Fri Nov 2 11:11:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABC01F0C5C for ; Fri, 2 Nov 2012 11:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.52 X-Spam-Level: X-Spam-Status: No, score=-10.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUBwurh2MKlh for ; Fri, 2 Nov 2012 11:11:15 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DC47C1F0C69 for ; Fri, 2 Nov 2012 11:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4442; q=dns/txt; s=iport; t=1351879875; x=1353089475; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ao3jlOqkUvYpy1GJhBbj36T4f/kxuFZjJCm8Xcn4qiM=; b=FEQ/f6rhoyOqnQ5tryx9wlabYUR9fKQPNNuGI5Lkc3OL3BSrSmxnfHOt XTElw4xSB2eD8LBUB8uBLuEzbT7MpmmLqHuC7Hqyo9HW+wylA0sCTXX2N scVlLj0SGQGascioDVbJ8TY8biTZgzHY89cNayXzA8xk9YIpy27gK2/78 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFsMlFCtJXG//2dsb2JhbABEwzSBCIIeAQEBAwEBAQEPAScbGQsFCwIBCBgKFBAhBgslAgQOBQgWBIdWAwkGC5t3ljMNiVSLGmcUhUZhA5QkjQiDJoFrgm+BWwkXHg X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208";a="138043570" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 02 Nov 2012 18:11:14 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA2IBEuT007647 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 18:11:14 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 13:11:13 -0500 From: "JP Vasseur (jvasseur)" To: Christopher Dearlove Thread-Topic: [manet] A proposal - differentiating the document and the protocol Thread-Index: AQHNuRdo+F/e031UAkadtES7lvZaHA== Date: Fri, 2 Nov 2012 18:11:13 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204CBA4@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A772204C0B9@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--63.188800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <42C9C4F0FBF4414F8596EB2B6267CEB5@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:11:20 -0000 I think different (this is fine !). Cheers. JP. On Nov 2, 2012, at 7:02 PM, Christopher Dearlove wrote: > However the LOADng document is much better written, and a much better sta= rting point. >=20 > --=20 > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) >=20 > On 2 Nov 2012, at 16:30, "JP Vasseur (jvasseur)" wro= te: >=20 >>=20 >> On Nov 2, 2012, at 12:16 PM, Dearlove, Christopher (UK) wrote: >>=20 >>> Before making a proposal, I'm going to introduce a distinction here bet= ween the DYMO and LOADng documents and protocols. >>>=20 >>> I'm of the opinion that the LOADng document is a greatly superior prese= ntation to the DYMO document. (I'm not really interested in why that has co= me about.) >>>=20 >>> I think that regardless of whether one makes design decisions favouring= DYMO or LOADng where they differ - and let's not forget they overlap a lot= - it would actually be easier to modify the LOADng document to specify DYM= O than it would be to modify the DYMO document to achieve that. And in prac= tice I think if making decisions it is unlikely that all would favour DYMO = over LOADng. >>>=20 >>> So what I think would be best for the WG is not a simply "option 1" or = even (as it may appear I'm suggesting, but I'm not) "option 2" but rather = to agree to take the LOADng document, and a list of where DYMO and LOADng d= iffer, and thrash out where they do, what the WG reactive protocol should d= o - either as a definite choice, or as an option (but not too many options = please- and some could be separate specifications). >>>=20 >>> This would not of course be LOADng, so we'd have to change the document= name. And there I suggest we have a candidate name - AODVv2. (Which is why= I have recently taken to saying DYMO when referring to that document.) Aft= er all, the one thing we are agreed on is that the protocol being developed= is derived from AODV. >>=20 >> JP> I would be extremely supportive of this, just do the reverse BUT we = would end up with the same results: >> * Take the DYMO document >> * Change the name to AODVv2 >> * List where both protocol differ >> * Use options when required. >>=20 >> I think that this is also what Charlie proposed. >>=20 >>>=20 >>> The editors of this new document would have to agree that what goes in = it is WG consensus (which should follow proper technical consideration of t= he issues). If they found it impossible to have other than their way to do = things, they'd have to move on. If that left no one editing it, obviously w= e don't have a consensus of people prepared to do the work and option 3 wou= ld win. >>>=20 >>> So now I'm partly off the fence I've been sitting on. But only partly. = I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as stand= ard, IRREPs as an option in the main draft, IRREPs as a separate draft opti= on, no IRREPs. I'd like to move on to those discussions. >>>=20 >>> --=20 >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cent= re, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>>=20 >>>=20 >>> ******************************************************************** >>> 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. >>> ******************************************************************** >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet From charliep@computer.org Fri Nov 2 11:58:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740AB21F95D2 for ; Fri, 2 Nov 2012 11:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEEoy7DYr+TG for ; Fri, 2 Nov 2012 11:58:39 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id EB60821F9839 for ; Fri, 2 Nov 2012 11:58:38 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.253.71]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TUMRw-0001QK-Fy; Fri, 02 Nov 2012 14:58:36 -0400 Message-ID: <509417D3.4020801@computer.org> Date: Fri, 02 Nov 2012 11:58:27 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Ulrich Herberg References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020108080200020908040903" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad861bb113185a9fcd05d4fdf0719138e160350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:58:40 -0000 This is a multi-part message in MIME format. --------------020108080200020908040903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello folks, I am trying to finish a new revision to the existing DYMO document to make the RFC 5444 compliance, improve terminology, and repair some other things which didn't get done because I ran out of time before the I-D submission deadline. It is my belief that if the WG document is in good shape, it will make for a much clearer way forward. I want to respond to the comments, but insofar as the WG document has editorial errors, I want to make it clear that I am committed to fixing them as a very high priority. The value of "quicker" depends a lot on the desired result. There is an obvious "extreme" case where we publish a document which really serves a very restricted case (say, only three nodes). That could be done in a matter of days, I guess. I do not mean that the LOADng document is anywhere near that restrictive, but that the argument has to be taken in context. Moreover, I would like to point out that the same urgency was expressed to me last year about this time, and at that time the intention was to persuade me that the metric for "weak links" could not be changed. In the meantime, I am happy to report that that metric has now been removed. Since the existing WG document is targeted at a greater scope of applicabililty than the LOADng, if we can get the existing WG document published with expedient and priority effort then it seems we would achieve a much more worthy goal -- all the while offering LOADng compatibility for the metering applications under current discussion. Regards, Charlie P. On 11/2/2012 9:34 AM, Ulrich Herberg wrote: > Hi Abdussalam, > > there was indeed some hesitance to change the name from some of the > authors (not me). I cannot speak for them here. My intuition is that > if the name of the protocol is the only factor that avoids the > reactive protocol from proceeding in the WG, this can be solved. > > As far as I can see from the discussions so far, there is a clear > consensus that option 3 is not viable. Now, if we want to proceed with > the reactive document, the question is from which document to start. > Chris mentioned that even if we wanted the specification of 100%, it > would be far quicker to start from the LOADng draft. I propose that we > can start working based on the LOADng draft (possibly rename it?), > look at each item that is in DYMO and consider whether and in which > way it should be incorporated in the draft. > > Best > Ulrich > > > > On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun > > wrote: > > Hi Ulrich, > I think that Chris's proposal was not accepted by LOADng > co-authors as I understood from following up the WG history (they > don't agree to change the name of protocol). As you are one > co-author do I understand that you support the Chris's proposal, > AB > On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg > > wrote: > > Dear Chris, > > personally, what you propose makes sense to me. > > > Regards > Ulrich > > On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" > > wrote: > > > Before making a proposal, I'm going to introduce a > distinction here between the DYMO and LOADng documents and > protocols. > > > > I'm of the opinion that the LOADng document is a greatly > superior presentation to the DYMO document. (I'm not really > interested in why that has come about.) > > > > I think that regardless of whether one makes design > decisions favouring DYMO or LOADng where they differ - and > let's not forget they overlap a lot - it would actually be > easier to modify the LOADng document to specify DYMO than it > would be to modify the DYMO document to achieve that. And in > practice I think if making decisions it is unlikely that all > would favour DYMO over LOADng. > > > > So what I think would be best for the WG is not a simply > "option 1" or even (as it may appear I'm suggesting, but I'm > not) "option 2" but rather to agree to take the LOADng > document, and a list of where DYMO and LOADng differ, and > thrash out where they do, what the WG reactive protocol should > do - either as a definite choice, or as an option (but not too > many options please- and some could be separate specifications). > > > > This would not of course be LOADng, so we'd have to change > the document name. And there I suggest we have a candidate > name - AODVv2. (Which is why I have recently taken to saying > DYMO when referring to that document.) After all, the one > thing we are agreed on is that the protocol being developed is > derived from AODV. > > > > The editors of this new document would have to agree that > what goes in it is WG consensus (which should follow proper > technical consideration of the issues). If they found it > impossible to have other than their way to do things, they'd > have to move on. If that left no one editing it, obviously we > don't have a consensus of people prepared to do the work and > option 3 would win. > > > > So now I'm partly off the fence I've been sitting on. But > only partly. I haven't yet formed a view on e.g. should this > AODVv2 have IRREPs as standard, IRREPs as an option in the > main draft, IRREPs as a separate draft option, no IRREPs. I'd > like to move on to those discussions. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 > 1245 242124 > > chris.dearlove@baesystems.com > | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough > Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > > > > ******************************************************************** > > 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. > > > ******************************************************************** > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Regards, Charlie P. --------------020108080200020908040903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello folks,

I am trying to finish a new revision to the existing DYMO document to
make the RFC 5444 compliance, improve terminology, and repair some
other things which didn't get done because I ran out of time before the
I-D submission deadline.   It is my belief that if the WG document is in
good shape, it will make for a much clearer way forward.

I want to respond to the comments, but insofar as the WG document
has editorial errors, I want to make it clear that I am committed to
fixing them as a very high priority.

The value of "quicker" depends a lot on the desired result.  There is an
obvious "extreme" case where we publish a document which really
serves a very restricted case (say, only three nodes).  That could be
done in a matter of days, I guess.  I do not mean that the LOADng
document is anywhere near that restrictive, but that the argument
has to be taken in context.  Moreover, I would like to point out that
the same urgency was expressed to me last year about this time,
and at that time the intention was to persuade me that the metric
for "weak links" could not be changed.  In the meantime, I am happy
to report that that metric has now been removed.

Since the existing WG document is targeted at a greater scope of
applicabililty than the LOADng, if we can get the existing WG document
published with expedient and priority effort then it seems we would
achieve a much more worthy goal -- all the while offering LOADng
compatibility for the metering applications under current discussion.

Regards,
Charlie P.



On 11/2/2012 9:34 AM, Ulrich Herberg wrote:
Hi Abdussalam,

there was indeed some hesitance to change the name from some of the authors (not me). I cannot speak for them here. My intuition is that if the name of the protocol is the only factor that avoids the reactive protocol from proceeding in the WG, this can be solved.

As far as I can see from the discussions so far, there is a clear consensus that option 3 is not viable. Now, if we want to proceed with the reactive document, the question is from which document to start. Chris mentioned that even if we wanted the specification of 100%, it would be far quicker to start from the LOADng draft. I propose that we can start working based on the LOADng draft (possibly rename it?), look at each item that is in DYMO and consider whether and in which way it should be incorporated in the draft. 

Best
Ulrich



On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
Hi Ulrich,
 
I think that Chris's proposal was not accepted by LOADng co-authors as I understood from following up the WG history (they don't agree to change the name of protocol). As you are one co-author do I understand that you support the Chris's proposal,
AB
On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
Dear Chris,

personally, what you propose makes sense to me.


Regards
Ulrich

On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> wrote:

> Before making a proposal, I'm going to introduce a distinction here between the DYMO and LOADng documents and protocols.
>
> I'm of the opinion that the LOADng document is a greatly superior presentation to the DYMO document. (I'm not really interested in why that has come about.)
>
> I think that regardless of whether one makes design decisions favouring DYMO or LOADng where they differ - and let's not forget they overlap a lot - it would actually be easier to modify the LOADng document to specify DYMO than it would be to modify the DYMO document to achieve that. And in practice I think if making decisions it is unlikely that all would favour DYMO over LOADng.
>
> So what I think would be best for the WG is not a simply "option 1" or even (as it may appear I'm suggesting, but  I'm not) "option 2" but rather to agree to take the LOADng document, and a list of where DYMO and LOADng differ, and thrash out where they do, what the WG reactive protocol should do - either as a definite choice, or as an option (but not too many options please- and some could be separate specifications).
>
> This would not of course be LOADng, so we'd have to change the document name. And there I suggest we have a candidate name - AODVv2. (Which is why I have recently taken to saying DYMO when referring to that document.) After all, the one thing we are agreed on is that the protocol being developed is derived from AODV.
>
> The editors of this new document would have to agree that what goes in it is WG consensus (which should follow proper technical consideration of the issues). If they found it impossible to have other than their way to do things, they'd have to move on. If that left no one editing it, obviously we don't have a consensus of people prepared to do the work and option 3 would win.
>
> So now I'm partly off the fence I've been sitting on. But only partly. I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standard, IRREPs as an option in the main draft, IRREPs as a separate draft option, no IRREPs. I'd like to move on to those discussions.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
>
> ********************************************************************
> 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.
> ********************************************************************
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet




_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



-- 
Regards,
Charlie P.
--------------020108080200020908040903-- From jvasseur@cisco.com Fri Nov 2 12:12:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69691F0C61 for ; Fri, 2 Nov 2012 12:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrWLJeqKrOmO for ; Fri, 2 Nov 2012 12:12:57 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4F71F0C59 for ; Fri, 2 Nov 2012 12:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18612; q=dns/txt; s=iport; t=1351883577; x=1353093177; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9jMDCk5Y34Kw/nd5SJjQzqZHYQ5kdVyssrzdkoi64zM=; b=RwczXb2l0CpfNg507rZI6OC7rajrnOVU7RRH40JIvCwOs1PkN5mACRW0 o7sF8gr+QgIvcQvm1RJLJLs6KIWEp2001YNvl+B1jO0nG7hYXHRWwuoba IUybd7s4rbh2m493nd1qiCbisVU8zKAzhPKE8qNldeIPjAKyQ40+dbakk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG4alFCtJV2a/2dsb2JhbABEw0KBCIIeAQEBAwEBAQEPAUIZCwULAgEIBxsdByEGCxQRAgQOBQgSBASHVgMJBgucAZYxDYlUixlnFIVGYQOIJYt/jQiDJoFrgm+BWwkXHg X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208,217";a="138277779" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 02 Nov 2012 19:12:56 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA2JCuFr019189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 19:12:56 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 14:12:56 -0500 From: "JP Vasseur (jvasseur)" To: "Charles E. Perkins" Thread-Topic: [manet] A proposal - differentiating the document and the protocol Thread-Index: AQHNuS4QQAldmF7ZtU6krGF1ERjKag== Date: Fri, 2 Nov 2012 19:12:55 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204D2AE@xmb-rcd-x02.cisco.com> References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> <509417D3.4020801@computer.org> In-Reply-To: <509417D3.4020801@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--62.326400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204D2AExmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 19:12:59 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204D2AExmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This a great news - see in line On Nov 2, 2012, at 2:58 PM, Charles E. Perkins wrote: Hello folks, I am trying to finish a new revision to the existing DYMO document to make the RFC 5444 compliance, improve terminology, and repair some other things which didn't get done because I ran out of time before the I-D submission deadline. It is my belief that if the WG document is in good shape, it will make for a much clearer way forward. I want to respond to the comments, but insofar as the WG document has editorial errors, I want to make it clear that I am committed to fixing them as a very high priority. The value of "quicker" depends a lot on the desired result. There is an obvious "extreme" case where we publish a document which really serves a very restricted case (say, only three nodes). That could be done in a matter of days, I guess. I do not mean that the LOADng document is anywhere near that restrictive, but that the argument has to be taken in context. Moreover, I would like to point out that the same urgency was expressed to me last year about this time, and at that time the intention was to persuade me that the metric for "weak links" could not be changed. In the meantime, I am happy to report that that metric has now been removed. Since the existing WG document is targeted at a greater scope of applicabililty than the LOADng, if we can get the existing WG document published with expedient and priority effort then it seems we would achieve a much more worthy goal -- all the while offering LOADng compatibility for the metering applications under current discussion. I cannot agree more. Thanks. JP. Regards, Charlie P. On 11/2/2012 9:34 AM, Ulrich Herberg wrote: Hi Abdussalam, there was indeed some hesitance to change the name from some of the authors= (not me). I cannot speak for them here. My intuition is that if the name o= f the protocol is the only factor that avoids the reactive protocol from pr= oceeding in the WG, this can be solved. As far as I can see from the discussions so far, there is a clear consensus= that option 3 is not viable. Now, if we want to proceed with the reactive = document, the question is from which document to start. Chris mentioned tha= t even if we wanted the specification of 100%, it would be far quicker to s= tart from the LOADng draft. I propose that we can start working based on th= e LOADng draft (possibly rename it?), look at each item that is in DYMO and= consider whether and in which way it should be incorporated in the draft. Best Ulrich On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun > wrote: Hi Ulrich, I think that Chris's proposal was not accepted by LOADng co-authors as I un= derstood from following up the WG history (they don't agree to change the n= ame of protocol). As you are one co-author do I understand that you support= the Chris's proposal, AB On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg > wrote: Dear Chris, personally, what you propose makes sense to me. Regards Ulrich On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" > wrote: > Before making a proposal, I'm going to introduce a distinction here betwe= en the DYMO and LOADng documents and protocols. > > I'm of the opinion that the LOADng document is a greatly superior present= ation to the DYMO document. (I'm not really interested in why that has come= about.) > > I think that regardless of whether one makes design decisions favouring D= YMO or LOADng where they differ - and let's not forget they overlap a lot -= it would actually be easier to modify the LOADng document to specify DYMO = than it would be to modify the DYMO document to achieve that. And in practi= ce I think if making decisions it is unlikely that all would favour DYMO ov= er LOADng. > > So what I think would be best for the WG is not a simply "option 1" or ev= en (as it may appear I'm suggesting, but I'm not) "option 2" but rather to= agree to take the LOADng document, and a list of where DYMO and LOADng dif= fer, and thrash out where they do, what the WG reactive protocol should do = - either as a definite choice, or as an option (but not too many options pl= ease- and some could be separate specifications). > > This would not of course be LOADng, so we'd have to change the document n= ame. And there I suggest we have a candidate name - AODVv2. (Which is why I= have recently taken to saying DYMO when referring to that document.) After= all, the one thing we are agreed on is that the protocol being developed i= s derived from AODV. > > The editors of this new document would have to agree that what goes in it= is WG consensus (which should follow proper technical consideration of the= issues). If they found it impossible to have other than their way to do th= ings, they'd have to move on. If that left no one editing it, obviously we = don't have a consensus of people prepared to do the work and option 3 would= win. > > So now I'm partly off the fence I've been sitting on. But only partly. I = haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standar= d, IRREPs as an option in the main draft, IRREPs as a separate draft option= , no IRREPs. I'd like to move on to those discussions. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | htt= p://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > ******************************************************************** > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet -- Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204D2AExmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <73D4EF69EE1BEE41B23A2CE328617225@cisco.com> Content-Transfer-Encoding: quoted-printable This a great news - see in line 

On Nov 2, 2012, at 2:58 PM, Charles E. Perkins wrote:


Hello folks,

I am trying to finish a new revision to the existing DYMO document to
make the RFC 5444 compliance, improve terminology, and repair some
other things which didn't get done because I ran out of time before the
I-D submission deadline.   It is my belief that if the WG documen= t is in
good shape, it will make for a much clearer way forward.

I want to respond to the comments, but insofar as the WG document
has editorial errors, I want to make it clear that I am committed to
fixing them as a very high priority.

The value of "quicker" depends a lot on the desired result. = There is an
obvious "extreme" case where we publish a document which really serves a very restricted case (say, only three nodes).  That could be<= br> done in a matter of days, I guess.  I do not mean that the LOADng
document is anywhere near that restrictive, but that the argument
has to be taken in context.  Moreover, I would like to point out that<= br> the same urgency was expressed to me last year about this time,
and at that time the intention was to persuade me that the metric
for "weak links" could not be changed.  In the meantime, I a= m happy
to report that that metric has now been removed.

Since the existing WG document is targeted at a greater scope of
applicabililty than the LOADng, if we can get the existing WG document
published with expedient and priority effort then it seems we would
achieve a much more worthy goal -- all the while offering LOADng
compatibility for the metering applications under current discussion.


I cannot agree more.

Thanks.

JP.

Regards,
Charlie P.



On 11/2/2012 9:34 AM, Ulrich Herberg wrote:
Hi Abdussalam,

there was indeed some hesitance to change the name from some of the au= thors (not me). I cannot speak for them here. My intuition is that if the n= ame of the protocol is the only factor that avoids the reactive protocol fr= om proceeding in the WG, this can be solved.

As far as I can see from the discussions so far, there is a clear cons= ensus that option 3 is not viable. Now, if we want to proceed with the reac= tive document, the question is from which document to start. Chris mentione= d that even if we wanted the specification of 100%, it would be far quicker to start from the LOADng draft. I pr= opose that we can start working based on the LOADng draft (possibly re= name it?), look at each item that is in DYMO and consider whether and in wh= ich way it should be incorporated in the draft. 

Best
Ulrich



On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryu= n <abdussalambaryun@gmail.com> wrote:
Hi Ulrich,
 
I think that Chris's proposal was not accepted by LOADng co-autho= rs as I understood from following up the WG history (they don't agree to ch= ange the name of protocol). As you are one co-author do I understand that y= ou support the Chris's proposal,
AB
On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg <= span dir=3D"ltr"> <ulrich@herberg.name> wrote:
Dear Chris,

personally, what you propose makes sense to me.


Regards
Ulrich

On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> wrote:

> Before making a proposal, I'm going to introduce a distinction here be= tween the DYMO and LOADng documents and protocols.
>
> I'm of the opinion that the LOADng document is a greatly superior pres= entation to the DYMO document. (I'm not really interested in why that has c= ome about.)
>
> I think that regardless of whether one makes design decisions favourin= g DYMO or LOADng where they differ - and let's not forget they overlap a lo= t - it would actually be easier to modify the LOADng document to specify DY= MO than it would be to modify the DYMO document to achieve that. And in practice I think if making decisions it i= s unlikely that all would favour DYMO over LOADng.
>
> So what I think would be best for the WG is not a simply "option = 1" or even (as it may appear I'm suggesting, but  I'm not) "= option 2" but rather to agree to take the LOADng document, and a list = of where DYMO and LOADng differ, and thrash out where they do, what the WG reactive protocol should do - either as a definite choice, or = as an option (but not too many options please- and some could be separate s= pecifications).
>
> This would not of course be LOADng, so we'd have to change the documen= t name. And there I suggest we have a candidate name - AODVv2. (Which is wh= y I have recently taken to saying DYMO when referring to that document.) Af= ter all, the one thing we are agreed on is that the protocol being developed is derived from AODV.
>
> The editors of this new document would have to agree that what goes in= it is WG consensus (which should follow proper technical consideration of = the issues). If they found it impossible to have other than their way to do= things, they'd have to move on. If that left no one editing it, obviously we don't have a consensus of people= prepared to do the work and option 3 would win.
>
> So now I'm partly off the fence I've been sitting on. But only partly.= I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as stan= dard, IRREPs as an option in the main draft, IRREPs as a separate draft opt= ion, no IRREPs. I'd like to move on to those discussions.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
>
> ******************************************************************** > 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.
> ******************************************************************** >
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet




_______________________________________________
manet mailing list
manet@=
ietf.org
https://www.ietf.org/mailman/listinfo/manet



--=20
Regards,
Charlie P.
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A772204D2AExmbrcdx02ciscoc_-- From ulrich@herberg.name Fri Nov 2 12:17:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E121F0C89 for ; Fri, 2 Nov 2012 12:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+J8Un8aqBMs for ; Fri, 2 Nov 2012 12:17:32 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCB11F0C7E for ; Fri, 2 Nov 2012 12:17:31 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4605391vbb.31 for ; Fri, 02 Nov 2012 12:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=bCxy0dZIQJdfJeQE5Gzw2h//Yem5Jap0yqxidMRL6ew=; b=tSpmHj03mybvyhzvD+WIsAMz9QSe9Efq00mlkIUnoN4uc6pXpJAZWnMmzCz/2RsioN 689x7I8zGoQ9gdZ91JXSFq+NoVwJUaCStFQM4C2FpjSHIz1iP+ox/IWIw8iR6CMpu/8/ 6pxYRQG+ak0xAitETqS4U8VqRhLvRjqYy0Vts= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=bCxy0dZIQJdfJeQE5Gzw2h//Yem5Jap0yqxidMRL6ew=; b=EKxwpbMQsbcA5AaPJvPrFEU7TReDTjBI7TguKSLAQX1QeNDg+81VQ2t/1jzaW6l2tV TER89RlXOPyA6A4wdrDa7Kj6Rz8TW6phwLscibUpSw11pJiHwxUSg9bjm8BFs+Q/XWcz /9aRSHb+hUkc44lhmX1yj4zQO5VTtstYBBUV4H5NY0lrcDrTpOkVhZinYygm15CkOQdX drbcF7wygqBuwPRGudLEhmXN9w9KcAzVLJKI06kevwK/uHtJM00NdijUsmnLX9t5yBSh LP1VnuVJ7WZETvl/DvH725dARzGB17DppYbH/AkuLCRC1K3BH+qbCkAG52u/gQzcmIH/ a0SQ== MIME-Version: 1.0 Received: by 10.220.119.196 with SMTP id a4mr2820431vcr.19.1351883851408; Fri, 02 Nov 2012 12:17:31 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Fri, 2 Nov 2012 12:17:31 -0700 (PDT) Date: Fri, 2 Nov 2012 12:17:31 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=bcaec54ee94ebda65b04cd87fc89 X-Gm-Message-State: ALoCoQm9EvgEJ457lsikS5jgGu8tks01YCf1MTT1MImSNkoQlT2gtcKlaCkIuJBgz3dRFRK7FJu2 Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , Benoit Claise Subject: [manet] Management use cases for MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 19:17:33 -0000 --bcaec54ee94ebda65b04cd87fc89 Content-Type: text/plain; charset=ISO-8859-1 Hi [manet] participants, I am forwarding an email from Benoit that was sent to coman@ietf.org, since it concerns MANET. COMAN is a new activity (not yet a WG) relating to management of constrained devices and networks. As I mentioned at the last IETF, Benoit cleared his DISCUSS on the NHDP-MIB if we commit to write a document about applicability and use cases of management of MANET routers. In COMAN, an individual ID was presented (draft-ersue-constrained-mgmt) that discusses use cases of management. Note that this is an early draft and will possibly be split in multiple drafts. There is some discussion whether that should include mobility or not (currently, MANET is excluded but mesh networks are not, which I think needs some more discussion, as both are about dynamic topologies). Anyway, similar to Benoit, it is unclear to me whether this draft or any work in COMAN (if it was to become a WG) would satisfy the request for a use case/applicability document, or if MANET should work on a separate draft. As the next OLSRv2-MIB revision will be submitted next Monday, (which I consider ready for WGLC) this is something we need to seriously consider. Opinions? Thanks Ulrich On Fri, Nov 2, 2012 at 4:45 AM, Benoit Claise wrote: > Hi, > > One point regarding MANET. > I believe that it deserves its own document: "MANET network management > considerations". Actually, when looking at draft-ietf-manet-nhdp-mib part > of the IESG review, one of the outcome was that such a document was > required. > I cleared my DISCUSS on draft-ietf-manet-nhdp-mib with this COMMENT > > Note regarding the applicability statement: This is solved, as we > discussed, but I'll keep this little sentence in one > corner of my head "A fuller discussion of MANET network management use > cases and challenges will be provided elsewhere." > > How/If this "MANET network management considerations" draft relates to > the draft-ersue-constrained-mgmt, I'm not sure at this point in time. > > --bcaec54ee94ebda65b04cd87fc89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi [manet] participants,

I am forwarding an e= mail from Benoit that was sent to coman@i= etf.org, since it concerns MANET. COMAN is a new activity (not yet a WG= ) relating to management of constrained devices and networks. As I mentione= d at the last IETF, Benoit cleared his DISCUSS on the NHDP-MIB if we commit= to write a document about applicability and use cases of management of MAN= ET routers.

In COMAN, an individual ID was presented (draft-ersue-c= onstrained-mgmt)=A0that discusses use cases of management. Note that this i= s an early draft and will possibly be split in multiple drafts. There is so= me discussion whether that should include mobility or not (currently, MANET= is excluded but mesh networks are not, which I think needs some more discu= ssion, as both are about dynamic topologies). Anyway, similar to Benoit, it= is unclear to me whether this draft or any work in COMAN (if it was to bec= ome a WG) would satisfy the request for a use case/applicability document, = or if MANET should work on a separate draft.

As the next OLSRv2-MIB revision will be submitted next = Monday, (which I consider ready for WGLC) this is something we need to seri= ously consider.=A0

Opinions?

Thanks
Ulrich

On Fri, Nov = 2, 2012 at 4:45 AM, Benoit Claise <bclaise@cisco.com> wrote:=
=20 =20 =20
Hi,

One point regarding MANET.
I believe that it deserves its own document: "MANET network management considerations". Actually, when looking at draft-ietf-manet-nhdp-mib part of the IESG review, one of the outcome was that such a document was required.
I cleared my DISCUSS on draft-ietf-manet-nhdp-mib with this COMMENT
Note regarding the applicability statement: This is solved, as=
 we
discussed, but I'll keep this little sentence in one=20
corner of my head "A fuller discussion of MANET network management use
cases and challenges will be provided elsewhere."
How/If this "MANET network management considerations" draft relates to the draft-ersue-constrained-mgmt, I'm not sure at this point in time.

--bcaec54ee94ebda65b04cd87fc89-- From robert.g.cole.civ@mail.mil Fri Nov 2 12:46:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6328C11E80D3 for ; Fri, 2 Nov 2012 12:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7STFsXqgFQ0P for ; Fri, 2 Nov 2012 12:46:56 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6D49911E80D1 for ; Fri, 2 Nov 2012 12:46:55 -0700 (PDT) Received: from UCOLHP3I.easf.csd.disa.mil (131.64.100.150) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 2 Nov 2012 19:46:35 +0000 Received: from UCOLHP9K.easf.csd.disa.mil ([169.254.4.61]) by UCOLHP3I.easf.csd.disa.mil ([131.64.100.150]) with mapi id 14.02.0309.003; Fri, 2 Nov 2012 19:46:35 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: Ulrich Herberg , "manet@ietf.org" Thread-Topic: [manet] Management use cases for MANETs (UNCLASSIFIED) Thread-Index: AQHNuS7C2q7K+4zf8kCx+huIU7Wi3ZfW8SHA Date: Fri, 2 Nov 2012 19:46:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02E1_01CDB911.3B6156F0" MIME-Version: 1.0 Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , Benoit Claise Subject: Re: [manet] Management use cases for MANETs (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 19:46:57 -0000 ------=_NextPart_000_02E1_01CDB911.3B6156F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE Ulrich, It was my understanding that, as you mentioned, Benoit had cleared the discuss on the NHDP-MIB conditioned upon the working group drafting a MANET management use case document. I know that you and James Nguyen had contributed some material to Mehmet's draft. I would hope that you and James could start to pull together a draft for the MANET WG for us to meet our commitment to Benoit. I would be glad to help review and comment but prefer not to edit. Thoughts? Thanks, Bob Robert G. Cole Comm: 443.395.8744 Email: robert.g.cole@us.army.mil -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg Sent: Friday, November 02, 2012 3:18 PM To: manet@ietf.org Cc: Ersue, Mehmet (NSN - DE/Munich); Benoit Claise Subject: [manet] Management use cases for MANETs Hi [manet] participants, I am forwarding an email from Benoit that was sent to coman@ietf.org, since it concerns MANET. COMAN is a new activity (not yet a WG) relating to management of constrained devices and networks. As I mentioned at the last IETF, Benoit cleared his DISCUSS on the NHDP-MIB if we commit to write a document about applicability and use cases of management of MANET routers. In COMAN, an individual ID was presented (draft-ersue-constrained-mgmt) that discusses use cases of management. Note that this is an early draft and will possibly be split in multiple drafts. There is some discussion whether that should include mobility or not (currently, MANET is excluded but mesh networks are not, which I think needs some more discussion, as both are about dynamic topologies). Anyway, similar to Benoit, it is unclear to me whether this draft or any work in COMAN (if it was to become a WG) would satisfy the request for a use case/applicability document, or if MANET should work on a separate draft. As the next OLSRv2-MIB revision will be submitted next Monday, (which I consider ready for WGLC) this is something we need to seriously consider. Opinions? Thanks Ulrich On Fri, Nov 2, 2012 at 4:45 AM, Benoit Claise wrote: Hi, One point regarding MANET. I believe that it deserves its own document: "MANET network management considerations". Actually, when looking at draft-ietf-manet-nhdp-mib part of the IESG review, one of the outcome was that such a document was required. I cleared my DISCUSS on draft-ietf-manet-nhdp-mib with this COMMENT Note regarding the applicability statement: This is solved, as we discussed, but I'll keep this little sentence in one corner of my head "A fuller discussion of MANET network management use cases and challenges will be provided elsewhere." How/If this "MANET network management considerations" draft relates to the draft-ersue-constrained-mgmt, I'm not sure at this point in time. Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_02E1_01CDB911.3B6156F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIS3DCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEwTCCA6mgAwIBAgIDDNszMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcN MTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJP QkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKU7 jo5hPKcK6V92Cni9Bu445V7UQJBLIu1eX3brV/yB6uFNd+lIdV5n6RBpE1QcsIUEyS1GVDvTR/Qs kbUInPJC8ioZCX/V5Y2J8nRNidXoLX4SdeQ3Gc6jLPn+1W8KHRdATHy+SYGcrHnePyRAhTO73rN3 97CqgOaxnS4wo/Eanw9Re5UGq70cN/G7376Oxa7A2xdtY9w8gLUilFmcYXuwR7FGxcnDhsqAW3fv tgM18ZWn/hioEhmRZz514jXPnHCvSPAkofjb4Mjucnku8uNowu+PMw5Yqv9wimBEitvQGPnyac41 MNtsflnmVqWswTwhzVzIGdodKZTw2h6byTcCAwEAAaOCAWwwggFoMB8GA1UdIwQYMBaAFFSqcyrH s3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCGLmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0 Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/BAQDAgUgMCMGA1UdIAQcMBowCwYJYIZI AWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUyGOLOF3I71SMIzwNIujoox8W0CowbQYIKwYB BQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3JsLmRpc2EubWlsL2dldHNpZ24/RE9EJTIw RU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwJAYDVR0RBB0w G4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVT MA0GCSqGSIb3DQEBBQUAA4IBAQAVD+rqDKxhGbV78baC+EUC3jiDUO6C41wsmB4ckt5akJPvVrB4 mjlnoG0lm19qovC98eO0vPQMUx1F6/jP9/xg32W2Ks2HZUR3ipZWBEqVi8i20Wz4sVFgXHkJjoP5 bju0XvJk/d6wze65iZqFuILuPplugaHg7iC5B/NAMELTGx8hoK3LVqmIIyMpEFlrxTygIkyuI+NK IqcbLtBOEW0bP7TNyBh/VShmtrXAtpPP0AAi+kaUURcG1x2xdPCR3cD2bjWYkfxQYeZRl2zTuOMg Mpr9pG3MuImao/C+v6IaXGuAU8xS8hSEbHGNLrXjJ9UIxw0K45WxjR7CrPFIJ4R5MIIFDDCCA/Sg AwIBAgIDDNswMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcNMTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UE CxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJPQkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOsVn1k8Ax7kkzWXvrNf7oI7iy5zEeLACdGKrODL9riDBNUF HvD4JtafUcwq03s4Daq0tscNL8J1ONDeML5s0X8UeNfCyexrkSpPwY9g/zVO6mJmG4OunTz/7fc2 G0ZR64VYlEBZeQ88JIMIs6bYXiO9SxuOCS47aGx/CGqdpFwt713bBAQvzAjLUSWBvjZN2bviTQrY wAg1/1AnlxY6Zl4YPBSV9c1TbtTQNjbRyFRabiqNMh0XaQ0ZHxQgsGOqNwfyMlmadL2m3ILhKpFh oMfOV01at2eDj8+wFvDXLXAL1f3HAQKv5W5GEoBYNDqp/ULDBJcXVPT8mYWzxMkca/MCAwEAAaOC AbcwggGzMB8GA1UdIwQYMBaAFFSqcyrHs3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCG Lmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/ BAQDAgbAMCMGA1UdIAQcMBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUBeVx RkqbKuf17SKV2ZZOsCXLQ+gwbQYIKwYBBQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3Js LmRpc2EubWlsL2dldHNpZ24/RE9EJTIwRU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDov L29jc3AuZGlzYS5taWwwRAYDVR0RBD0wO4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbKAeBgor BgEEAYI3FAIDoBAMDjEzNjY1NjAzOTBAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMw KQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUA A4IBAQBhwXMphuaV+lhIZbI35yGpZ7zy/uXNyr41+/dibahnAIisIIHFSTeEk9GFepxqV45hagTo //0UycQ/ShOIHzV/+u3l/97k+l8imMdbjhgklb2UFROSz7TJzhO3w4S7g7DpU+GTxE2Uax+iD2t0 Bmio3ut9fr/dWvi6OTYVFMTW7M6pd8gOPqmg8ADGdljGsSotMAhXzFJgAPtnsca5HfyYpGi0NQj0 ucT/sWUGwnnjlqtYyP+SY2pOPpbN9gACkv8UKJMkik5GEFobaHbI8KWr4FFOXAIAauW1DvGFq5Pe WdDgj39r6PkdOLg3v+B9/hnkP6uOyH5Oi9pcHb+d/hPuMIIFjzCCBHegAwIBAgIBRTANBgkqhkiG 9w0BAQUFADBbMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQL EwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNRG9EIFJvb3QgQ0EgMjAeFw0wOTAxMjYyMDI2 MTVaFw0xNTAxMjUyMDI2MTVaMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1l bnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClLlh6od7mmlv2AvHV1Nw1I5p7bihkdBpw PJYdzMKfdAQ8DDmSIQgNEk6g1zeo0snGJ50o+lXXshcEGc4yvPB5nvVoqy7MzzcEsvgKZZpJIBQl wbwSaqBCbRsItIehQiKrE5naAgE5H14IV2tg3hN+aGp+QfWJgDh6/Zey0uKWSzaAYrbsJbvQD6ej zVGo99J5VZA0JqPkXM27aCZ0CTeh5q/N5D6ZR/9/wke8ZYS6MimjDvDColt66rJKfQvGw26svRB/ T6l2Oj0CASwqMLT3yKDSmDp8CNBaiQ+1ioL6DTAeftbRx7ZDJ7EoqQzjswd432JkmkWMTs2vDq6c WDbfAgMBAAGjggJaMIICVjAOBgNVHQ8BAf8EBAMCAYYwHwYDVR0jBBgwFoAUSXS7DF66ev4CVO97 oMaVxgmAcJYwHQYDVR0OBBYEFFSqcyrHs3fqzSJAeUh7EfunmSKCMAwGA1UdJAQFMAOAAQAwEgYD VR0TAQH/BAgwBgEB/wIBADCBnwYDVR0gBIGXMIGUMAsGCWCGSAFlAgELBTALBglghkgBZQIBCwkw CwYJYIZIAWUCAQsKMAsGCWCGSAFlAgELEjALBglghkgBZQIBCxMwCwYJYIZIAWUCAQsUMAwGCmCG SAFlAwIBAwYwDAYKYIZIAWUDAgEDBzAMBgpghkgBZQMCAQMIMAwGCmCGSAFlAwIBAw0wDAYKYIZI AWUDAgEDETA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLmRpc2EubWlsL2dldGNybD9Eb0Ql MjBSb290JTIwQ0ElMjAyMIH+BggrBgEFBQcBAQSB8TCB7jA/BggrBgEFBQcwAoYzaHR0cDovL2Ny bC5kaXNhLm1pbC9nZXRJc3N1ZWRUbz9Eb0QlMjBSb290JTIwQ0ElMjAyMCAGCCsGAQUFBzABhhRo dHRwOi8vb2NzcC5kaXNhLm1pbDCBiAYIKwYBBQUHMAKGfGxkYXA6Ly9jcmwuZ2RzLmRpc2EubWls L2NuJTNkRG9EJTIwUm9vdCUyMENBJTIwMiUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5T LiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwDQYJKoZIhvcNAQEF BQADggEBAHIW3DlzY02T6Tccz7LtnNhN9wwySomes8q68wSscWYxpiq9un1U2C8JY0qICOhsE6Hs XntWFzAtyNLt141HRGnPEW/L2OdSdbVRyKodafAZHzDwB8c2vc4M3jt2/QrOy7YTutaFi/FcEpHK r+h/EqisLYvWdlCU7Db6ow/fxjLqx3NG/IQami/E6CccSMJGNvYX7O1nMg+4ouC30l6QBhOUIWFD bH3zO2tl7ePbqP/Fm7KS5+tf7u+/8zmMs/UX0obVw2xKOmw/nq/oWx02W6YmFUYLRmvH1ICq564c uCtO+iFyn1+fga+07lvJlymJfOnceOJO4HSf0oZ4ZqLHmKgxggL+MIIC+gIBATBkMF0xCzAJBgNV BAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMD UEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQCAwzbMDAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjExMDIxOTQ2MzJaMCMGCSqGSIb3 DQEJBDEWBBR0JboZdE38ByhQiYS6rBSuYlX7DDAkBgkqhkiG9w0BCQ8xFzAVMAoGCCqGSIb3DQMH MAcGBSsOAwIaMHMGCSsGAQQBgjcQBDFmMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJ TCBDQS0yNAIDDNszMHUGCyqGSIb3DQEJEAILMWagZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP VS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9E IEVNQUlMIENBLTI0AgMM2zMwDQYJKoZIhvcNAQEBBQAEggEAt4TQYpo9y7tE5EvY7qvImKO5lzQ8 qOg6Em67Tmbx40f9C+ETEOM1jcvhyVRSif/7G4IgnIvTVpjhydpScPY5cT1PRioUS1Y3q9CWkoHK VWNs77X1kKonI12zgx1SDjsHhCFXGzhiyZxsR+fVsytMSM629BrZkqw1n1NsGStVwRRpNgzzTJvX r02rBLxvE6jBlnd8HhrE4wkRO5Ffu3Co39ImWZFOkGu7T+bFDW5l6eefLL4EPWtB8yNiABB7KLS/ rwH/BZgj1+GzbBLQ9b39EtY81A/NGssbhW1eao/AJLULHNknmK2O3px7wNR06pggNlkGxr2RDqcj FHiop/ftcAAAAAAAAA== ------=_NextPart_000_02E1_01CDB911.3B6156F0-- From drdanhe@gmail.com Fri Nov 2 13:25:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258CA1F0C7E for ; Fri, 2 Nov 2012 13:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L64+bTkAVPVg for ; Fri, 2 Nov 2012 13:25:22 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 928381F0C61 for ; Fri, 2 Nov 2012 13:25:21 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1862237wgb.13 for ; Fri, 02 Nov 2012 13:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=njcQ4vBDl3kl5SNDm6qCvwnwYDpFrrUdr5ArytjGQsM=; b=kutLChTLWUedWJq89L/gbbLOzblNw/CUhYekylPjE4KsuwTmZtTpsFupcURAAtxYy8 qbPEdL+1oyuya8nllUZfeMTO74LNbixhDVoRbr/NZTEI/Ps/JSOBTuC+5WACMBLLUMb9 //y1JYMZZRgx9PRvf2h5LvovfIpYlRJRLvzm8SABwQCXjqHS9TWUDyVLYNGajK5izfIc wMIBtqvNiyVbjl5KmGxNw37ObC4skzIBic7TsiEjmo/mjYcwQ47H1f6XSr4L0mwA/3LI QqRZED3sxMGw4LjpzE3bqf7kQVk03HLbn8XJRLZsufL5Ajruky+icNsGiGNKhmt3MG52 p2Tg== MIME-Version: 1.0 Received: by 10.180.80.100 with SMTP id q4mr4097980wix.20.1351887920409; Fri, 02 Nov 2012 13:25:20 -0700 (PDT) Received: by 10.194.59.71 with HTTP; Fri, 2 Nov 2012 13:25:20 -0700 (PDT) In-Reply-To: References: <03B78081B371D44390ED6E7BADBB4A772204C0B9@xmb-rcd-x02.cisco.com> Date: Fri, 2 Nov 2012 20:25:20 +0000 Message-ID: From: Daniel He To: Christopher Dearlove Content-Type: multipart/alternative; boundary=f46d0442835445adf304cd88efec Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 20:25:23 -0000 --f46d0442835445adf304cd88efec Content-Type: text/plain; charset=ISO-8859-1 I also agree with Chris. If we have a solid draft like LOADng already, why we cann't reuse it as a start point. I saw both drafts were derivated from AODV and LOADng has progressed somehow in security mechanism although it is not perfect and I view it is too overhead to insure end-to-end security at routing level. DYMO has certainly not progressed that much although we can trust Charlie for his reputation work and he has ability to make his reactive routing protocol progress. The question seems to me whether we start to work on LOADng or start to work on DYMO to make this discussion move forward. What is the advantage and disadvantage to do so? Any risk or how much work needs to be done before we can possibly establish a solid draft? Cheers, Dan On 2 November 2012 18:02, Christopher Dearlove < christopher.dearlove@googlemail.com> wrote: > However the LOADng document is much better written, and a much better > starting point. > > -- > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) > > On 2 Nov 2012, at 16:30, "JP Vasseur (jvasseur)" > wrote: > > > > > On Nov 2, 2012, at 12:16 PM, Dearlove, Christopher (UK) wrote: > > > >> Before making a proposal, I'm going to introduce a distinction here > between the DYMO and LOADng documents and protocols. > >> > >> I'm of the opinion that the LOADng document is a greatly superior > presentation to the DYMO document. (I'm not really interested in why that > has come about.) > >> > >> I think that regardless of whether one makes design decisions favouring > DYMO or LOADng where they differ - and let's not forget they overlap a lot > - it would actually be easier to modify the LOADng document to specify DYMO > than it would be to modify the DYMO document to achieve that. And in > practice I think if making decisions it is unlikely that all would favour > DYMO over LOADng. > >> > >> So what I think would be best for the WG is not a simply "option 1" or > even (as it may appear I'm suggesting, but I'm not) "option 2" but rather > to agree to take the LOADng document, and a list of where DYMO and LOADng > differ, and thrash out where they do, what the WG reactive protocol should > do - either as a definite choice, or as an option (but not too many options > please- and some could be separate specifications). > >> > >> This would not of course be LOADng, so we'd have to change the document > name. And there I suggest we have a candidate name - AODVv2. (Which is why > I have recently taken to saying DYMO when referring to that document.) > After all, the one thing we are agreed on is that the protocol being > developed is derived from AODV. > > > > JP> I would be extremely supportive of this, just do the reverse BUT we > would end up with the same results: > > * Take the DYMO document > > * Change the name to AODVv2 > > * List where both protocol differ > > * Use options when required. > > > > I think that this is also what Charlie proposed. > > > >> > >> The editors of this new document would have to agree that what goes in > it is WG consensus (which should follow proper technical consideration of > the issues). If they found it impossible to have other than their way to do > things, they'd have to move on. If that left no one editing it, obviously > we don't have a consensus of people prepared to do the work and option 3 > would win. > >> > >> So now I'm partly off the fence I've been sitting on. But only partly. > I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as > standard, IRREPs as an option in the main draft, IRREPs as a separate draft > option, no IRREPs. I'd like to move on to those discussions. > >> > >> -- > >> Christopher Dearlove > >> Senior Principal Engineer, Communications Group > >> Communications, Networks and Image Analysis Capability > >> BAE Systems Advanced Technology Centre > >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > >> Tel: +44 1245 242194 | Fax: +44 1245 242124 > >> chris.dearlove@baesystems.com | http://www.baesystems.com > >> > >> BAE Systems (Operations) Limited > >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > >> Registered in England & Wales No: 1996687 > >> > >> > >> > >> ******************************************************************** > >> 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. > >> ******************************************************************** > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Dan He --------------------- Tel: +44-788-686-3428 --f46d0442835445adf304cd88efec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I also agree with Chris. If we have a solid draft like LOADng already, why = we cann't reuse it
as a start point. I saw both drafts were derivate= d from AODV and LOADng has progressed
somehow in security mechanism alth= ough it is not perfect and I view it is too overhead to
insure end-to-end security at routing level. DYMO has certainly not progres= sed that much
although we can trust Charlie for his reputation work and = he has ability to make his reactive
routing protocol progress.

The question seems to me whether we start to work on LOADng or start to wor= k on DYMO
to make this discussion move forward. What is the advantage an= d disadvantage to do so?
Any risk or how much work needs to be done befo= re we can possibly establish a solid draft?

Cheers,
Dan

On 2 November 2012 18:= 02, Christopher Dearlove <christopher.dearlove@googlemai= l.com> wrote:
However the LOADng document is much better w= ritten, and a much better starting point.

--
Christopher Dearlove
christopher.dearlove@gmai= l.com (iPhone)
chris@mnemosyne.demon.co.uk<= /a> (home)

On 2 Nov 2012, at 16:30, "JP Vasseur (jvasseur)" <jvasseur@cisco.com> wrote:

>
> On Nov 2, 2012, at 12:16 PM, Dearlove, Christopher (UK) wrote:
>
>> Before making a proposal, I'm going to introduce a distinction= here between the DYMO and LOADng documents and protocols.
>>
>> I'm of the opinion that the LOADng document is a greatly super= ior presentation to the DYMO document. (I'm not really interested in wh= y that has come about.)
>>
>> I think that regardless of whether one makes design decisions favo= uring DYMO or LOADng where they differ - and let's not forget they over= lap a lot - it would actually be easier to modify the LOADng document to sp= ecify DYMO than it would be to modify the DYMO document to achieve that. An= d in practice I think if making decisions it is unlikely that all would fav= our DYMO over LOADng.
>>
>> So what I think would be best for the WG is not a simply "opt= ion 1" or even (as it may appear I'm suggesting, but =A0I'm no= t) "option 2" but rather to agree to take the LOADng document, an= d a list of where DYMO and LOADng differ, and thrash out where they do, wha= t the WG reactive protocol should do - either as a definite choice, or as a= n option (but not too many options please- and some could be separate speci= fications).
>>
>> This would not of course be LOADng, so we'd have to change the= document name. And there I suggest we have a candidate name - AODVv2. (Whi= ch is why I have recently taken to saying DYMO when referring to that docum= ent.) After all, the one thing we are agreed on is that the protocol being = developed is derived from AODV.
>
> JP> I would be extremely supportive of this, just do the reverse BU= T we would end up with the same results:
> * Take the DYMO document
> * Change the name to AODVv2
> * List where both protocol differ
> * Use options when required.
>
> I think that this is also what Charlie proposed.
>
>>
>> The editors of this new document would have to agree that what goe= s in it is WG consensus (which should follow proper technical consideration= of the issues). If they found it impossible to have other than their way t= o do things, they'd have to move on. If that left no one editing it, ob= viously we don't have a consensus of people prepared to do the work and= option 3 would win.
>>
>> So now I'm partly off the fence I've been sitting on. But = only partly. I haven't yet formed a view on e.g. should this AODVv2 hav= e IRREPs as standard, IRREPs as an option in the main draft, IRREPs as a se= parate draft option, no IRREPs. I'd like to move on to those discussion= s.
>>
>> --
>> Christopher Dearlove
>> Senior Principal Engineer, Communications Group
>> Communications, Networks and Image Analysis Capability
>> BAE Systems Advanced Technology Centre
>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>> Tel: +44 1245 242194 | =A0Fax: +44 1245 242124
>> chris.dearlove@ba= esystems.com | = http://www.baesystems.com
>>
>> BAE Systems (Operations) Limited
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace= Centre, Farnborough, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1996687
>>
>>
>>
>> ******************************************************************= **
>> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended<= br> >> 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.
>> ******************************************************************= **
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



--
Dan He
-= --------------------
Tel: +44-788-686-3428

--f46d0442835445adf304cd88efec-- From jblack.ietf@yahoo.com Fri Nov 2 13:37:28 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4492A21F9A47 for ; Fri, 2 Nov 2012 13:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.783 X-Spam-Level: X-Spam-Status: No, score=-0.783 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfLDTD9Kw+uz for ; Fri, 2 Nov 2012 13:37:27 -0700 (PDT) Received: from nm28-vm0.bullet.mail.bf1.yahoo.com (nm28-vm0.bullet.mail.bf1.yahoo.com [98.139.213.149]) by ietfa.amsl.com (Postfix) with ESMTP id 2F68921F9A56 for ; Fri, 2 Nov 2012 13:37:27 -0700 (PDT) Received: from [98.139.212.151] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 20:37:15 -0000 Received: from [98.139.212.203] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 20:37:15 -0000 Received: from [127.0.0.1] by omp1012.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 20:37:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 199798.68829.bm@omp1012.mail.bf1.yahoo.com Received: (qmail 86213 invoked by uid 60001); 2 Nov 2012 20:37:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351888635; bh=W7uAuDIHYn6aZCxwl7L3i6X6gnNCg8Nz/R6wfW8L4+4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=WiPezpSLQu084/YNhER6CiaEPzQFCEDBJYnY98F+q7XSlKVwVvf9270oX8Q9F/jKctsx3apA0XCf4I3tVqnQkFUafUSyeJfEWAF9fGJeyTkxE8nyBUpMLMt46oxJE8LyNDC0+sBZq1X9IoTF/KOxc4vogCvLdgRidNLPseUfCl8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RgU2KYvrgDNVevCTf80+6BWKxObIrHwY/z5pRkkEw6okdSUMdyVlKoKdtrUQAHgkn1rUdUVPnDkHc+1946cnonxaNmJiVkm4ikUWDujnK+Wf+laJRN/azTkkwfP9wcUhQAHbaHbpp4PySJsgduNmkvkjTjMsvbBYnDAGiCskbTA=; X-YMail-OSG: Rv.BocsVM1nEAK1wgUv0wuDnJvvUb0hrqIfj8ZIxjNN5igY OGMBIyAvl.RSw.OXgsV6FDkZQx15KTNcQW38oYcFbuMkgRm4i9Ie5iayan.H 0l3iHDpJqHfhj_eOdDFdoGDqen1SMDS9P1E5ejtVlC.xkPICS2.PmOSSLa2D WiFPTEjlThBewuBYPHCbpnQKkYxbEJcEKYSn7pFguNp_dniYNUBBv9XKT84z wKB7yV8EyDI3OPb14LPOjJbsl1yaO9QxBZ_2hg7_5Xz9rbHyLI0o6w1mE6Qh BXufnKOkQZKgZ3FaPAvbpI67sc8j7m2AxL2mBR9fj8QyzDNWXZ3QeFAmO2bx relFahf4a1iRgPWPWbyczp3.FUy74Yn05AMyqrd7Yp4HXgeSmqHhohKnND7A I0b4_hQDaVwCU4KF9yn4wbvQ9QHGkWqPiYycOpe_MI5KLXUftWa9NHjXeMTY XlJxG7nGG Received: from [173.193.202.116] by web160606.mail.bf1.yahoo.com via HTTP; Fri, 02 Nov 2012 13:37:15 PDT X-Rocket-MIMEInfo: 001.001, RnJvbTogSlAgVmFzc2V1ciAoanZhc3NldXIpIDxqdmFzc2V1ckBjaXNjby5jb20.CgoKT24gTm92IDIsIDIwMTIsIGF0IDEyOjE2IFBNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSB3cm90ZToKCj4gQmVmb3JlIG1ha2luZyBhIHByb3Bvc2FsLCBJJ20gZ29pbmcgdG8gaW50cm9kdWNlIGEgZGlzdGluY3Rpb24gaGVyZSBiZXR3ZWVuIHRoZSBEWU1PIGFuZCBMT0FEbmcgZG9jdW1lbnRzIGFuZCBwcm90b2NvbHMuCj4gCj4gSSdtIG9mIHRoZSBvcGluaW9uIHRoYXQgdGhlIExPQURuZyBkb2N1bWVudCBpcyABMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <03B78081B371D44390ED6E7BADBB4A772204C0B9@xmb-rcd-x02.cisco.com> Message-ID: <1351888635.56259.YahooMailNeo@web160606.mail.bf1.yahoo.com> Date: Fri, 2 Nov 2012 13:37:15 -0700 (PDT) From: Jon Black To: "JP Vasseur \(jvasseur\)" , "Dearlove, Christopher \(UK\)" In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204C0B9@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1874956439-1815326047-1351888635=:56259" Cc: "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 20:37:28 -0000 --1874956439-1815326047-1351888635=:56259 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: JP Vasseur (jvasseur) =0A=0A=0AOn Nov 2, 2012, at= 12:16 PM, Dearlove, Christopher (UK) wrote:=0A=0A> Before making a proposa= l, I'm going to introduce a distinction here between the DYMO and LOADng do= cuments and protocols.=0A> =0A> I'm of the opinion that the LOADng document= is a greatly superior presentation to the DYMO document. (I'm not really i= nterested in why that has come about.)=0A> =0A> I think that regardless of = whether one makes design decisions favouring DYMO or LOADng where they diff= er - and let's not forget they overlap a lot - it would actually be easier = to modify the LOADng document to specify DYMO than it would be to modify th= e DYMO document to achieve that. And in practice I think if making decision= s it is unlikely that all would favour DYMO over LOADng.=0A> =0A> So what I= think would be best for the WG is not a simply "option 1" or even (as it m= ay appear I'm suggesting, but=A0 I'm not) "option 2" but rather to agree to= take the LOADng document, and a list of where DYMO and LOADng differ, and = thrash out where they do, what the WG reactive protocol should do - either = as a definite choice, or as an option (but not too many options please- and= some could be separate specifications).=0A> =0A> This would not of course = be LOADng, so we'd have to change the document name. And there I suggest we= have a candidate name - AODVv2. (Which is why I have recently taken to say= ing DYMO when referring to that document.) After all, the one thing we are = agreed on is that the protocol being developed is derived from AODV.=0A=0AJ= P> I would be extremely supportive of this, just do the reverse BUT we woul= d end up with the same results:=0A* Take the DYMO document=0A* Change the n= ame to AODVv2=0A* List where both protocol differ=0A* Use options when requ= ired.=0A=0AI think that this is also what Charlie proposed.=0A=0A[Jon] I ha= rdly think that we would end up with the same results.=A0 Adding required a= nd necessary improvements to a good base is significantly faster and easier= than trying to understand and remove unnecessary concepts, features, ...= =0A=0AJon=0A --1874956439-1815326047-1351888635=:56259 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
From: JP Vasseur (jvasseur) <jvasseur@cisco.c= om>

On Nov 2, 2012, at 12:16 PM, Dearlove, = Christopher (UK) wrote:

> Before making a proposal, I'm going to = introduce a distinction here between the DYMO and LOADng documents and prot= ocols.
>
> I'm of the opinion that the LOADng document is a gr= eatly superior presentation to the DYMO document. (I'm not really intereste= d in why that has come about.)
>
> I think that regardless of = whether one makes design decisions favouring DYMO or LOADng where they diff= er - and let's not forget they overlap a lot - it would actually be easier to modify the LOADng document to specify DYMO than it would be to modify t= he DYMO document to achieve that. And in practice I think if making decisio= ns it is unlikely that all would favour DYMO over LOADng.
>
> = So what I think would be best for the WG is not a simply "option 1" or even= (as it may appear I'm suggesting, but  I'm not) "option 2" but rather= to agree to take the LOADng document, and a list of where DYMO and LOADng = differ, and thrash out where they do, what the WG reactive protocol should = do - either as a definite choice, or as an option (but not too many options= please- and some could be separate specifications).
>
> This = would not of course be LOADng, so we'd have to change the document name. An= d there I suggest we have a candidate name - AODVv2. (Which is why I have r= ecently taken to saying DYMO when referring to that document.) After all, t= he one thing we are agreed on is that the protocol being developed is derived from AODV.

JP> I would be extremely supportive of thi= s, just do the reverse BUT we would end up with the same results:
* Take= the DYMO document
* Change the name to AODVv2
* List where both prot= ocol differ
* Use options when required.

I think that this is als= o what Charlie proposed.

[Jon] I hardly think that we would end up w= ith the same results.  Adding required and necessary improvements to a= good base is significantly faster and easier than trying to understand and= remove unnecessary concepts, features, ...

Jon
<= /div> --1874956439-1815326047-1351888635=:56259-- From jblack.ietf@yahoo.com Fri Nov 2 13:38:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179AF11E80BF for ; Fri, 2 Nov 2012 13:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.635 X-Spam-Level: X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aOtInmLLs2g for ; Fri, 2 Nov 2012 13:38:28 -0700 (PDT) Received: from nm35-vm4.bullet.mail.bf1.yahoo.com (nm35-vm4.bullet.mail.bf1.yahoo.com [72.30.238.76]) by ietfa.amsl.com (Postfix) with ESMTP id 00E0621F9A37 for ; Fri, 2 Nov 2012 13:38:23 -0700 (PDT) Received: from [98.139.212.149] by nm35.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 20:38:23 -0000 Received: from [98.139.212.231] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 20:38:23 -0000 Received: from [127.0.0.1] by omp1040.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 20:38:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 189122.33347.bm@omp1040.mail.bf1.yahoo.com Received: (qmail 57881 invoked by uid 60001); 2 Nov 2012 20:38:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351888702; bh=VYm2CIbj56IYq0i9olFIEXhBSAOJff9tJsYMQ/aJkVM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IIoU6zUlfGr+78eLdaEhkNGtRi2dHEZ/X+ba0avp2yTsxQK8sNZSwKt0Oxe0TnhEO+qvLM5xDcBewIbqVZKkNYdOBlb3o5of9/Vk1zvj+i2xsmzbwXZCrpPOskjgFK0BRNQck3i344oKIuaMbYVtA4ak5ZeTChXg7D38BQCYcBY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OEiW9Diu6/IQc5cm7pWMVl4xIj6kfJmrsp0/DWr4bvE9bpnMoCb+mJY6JkwfJbkzTqcFkRUTqvX0nQpPPtW+FqInYjleD+PixmMVGI1LRsA5v7MAA1x9wbuUEEdk341MJfr6ZrXqz3+HKmlKSb+wWFZxJHZro7MUFw4Xbq1llD8=; X-YMail-OSG: iIlOGvMVM1nY0U0_TZt11m38srMb88JE3VxYH.9YQHuUIJ7 jM_SZ6Mzy67CBAN99rxd0cpjdPWjd5TG7UhMBbLDx05pnSHQglRyuAHebCpq Z7jpDLkgWd.Qow0oZt_MdJ3rZCN6.L_mIb7J6uruKFfwLgFME6DwUQCJQP5H EODsMJAQ_Zj0bDp8JqUb37RSymvRp_TFb9QcvL2SzuDBEWja4HLYLHudfCOk 86ZGnK5fU9EvSrdnlYCvUi1k.9dheeNr7z.bwtwLtCO6vJ4m0Ht2GoxOIhPW u8lzlGoRVj8S.h_7MjSQOQJMJeb72aQ6YcaExkg3ed64GDdGC36LYzUD4Ap5 1EnUTO7IY5lKMZctVPqIurCXMwjEO3Rk5jN7te6ytqSKDi4iEJHi1RAftOvx MjRUCHogU_uCfeDPRzPvLwacxNgUAG.4BmXHWx3dlmRDwoIs1kXbab_cGi_Q w6TFZhHmD Received: from [173.193.202.116] by web160603.mail.bf1.yahoo.com via HTTP; Fri, 02 Nov 2012 13:38:22 PDT X-Rocket-MIMEInfo: 001.001, RnJvbTogSlAgVmFzc2V1ciAoanZhc3NldXIpIDxqdmFzc2V1ckBjaXNjby5jb20.CgoKRGVhciBZdWljaGksCgpXZSBhbGwgYWdyZWUgdGhhdCB0aGUgZG9jdW1lbnQgc2hvdWxkIGJlIGVhc3kgdG8gcmVhZCBhbmQgaW1wbGVtZW50OyBpZiBpbXByb3ZlbWVudHMgbXVzdCBiZSBtYWRlIHRvIERZTU8tMjMsIGFuZCB0aGVyZSBhcmUg4oCmIGxldCdzIGdvIGFoZWFkIGFuZAppbXByb3ZlIHRoZSBkb2N1bWVudC4gTm90aGluZyB3cm9uZyB3aXRoIHRoYXQuIFdlIHNob3VsZCBub3QgZ2V0IG1peCB0aGUgY29tcGwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <03B78081B371D44390ED6E7BADBB4A772204C304@xmb-rcd-x02.cisco.com> Message-ID: <1351888702.57714.YahooMailNeo@web160603.mail.bf1.yahoo.com> Date: Fri, 2 Nov 2012 13:38:22 -0700 (PDT) From: Jon Black To: "JP Vasseur \(jvasseur\)" , Yuichi IGARASHI In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204C304@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1886287700-1479670266-1351888702=:57714" Cc: "" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 20:38:29 -0000 --1886287700-1479670266-1351888702=:57714 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: JP Vasseur (jvasseur) =0A=0A=0ADear Yuichi,=0A=0A= We all agree that the document should be easy to read and implement; if imp= rovements must be made to DYMO-23, and there are =E2=80=A6 let's go ahead a= nd=0Aimprove the document. Nothing wrong with that. We should not get mix t= he complexity of the document and the protocol.=0A=0A[Jon] Sometimes they a= re one in the same=0A=0AJon=0A=0AOn Nov 2, 2012, at 10:54 AM, Yuichi IGARAS= HI wrote:=0A=0A> Hi,=0A> =0A> I agree with Martin and I would support optio= n 2) at this stage.=0A> =0A> We LOADng co-authors made efforts to simplify = core specification of the reactive protocol and to improve the readability = of the draft. I think this approach is important not only for all implement= or to shorten the development time, but also for business operators to make= multi-vendor system easier to provide. Of course, I agree that, as several= persons pointed out, "this draft" may limit use case. But we leave suffici= ent space for improving performance/adding functions by companion drafts.= =0A> =0A> I am really concerned about complexity/difficulty of guaranteeing= of interoperability. If the protocol becomes complicated, we need much tim= e(many years?) for interoperability test. I think we should consider both t= ime required for merging drafts and shape of document.=0A> =0A> Best regard= s,=0A> Yuichi=0A> (2012/11/02 23:01), Martin Heusse wrote:=0A>> =0A>> I'm s= tanding for option 2 (LOADng).=0A>> =0A>> I think it's better to agree firs= t on a simple basic (versatile?) protocol before proposing extensions to it= ; instead of starting from a collection of ideas that can be used or not (a= nd we know today what are the options, thank to the huge amount of work don= e on reactive routing during the past years). Conversely, it would be certa= inly easier to reach a consensus on a set of variants but we need a good re= ference point, first.=0A>> =0A>> Moreover, reactive routing is most probabl= y the approach that one would pick for a simple case. So it should be simpl= e...=0A>> =0A>> Martin=0A>> =0A>> =0A>> Le 2 nov. 2012 =C3=A0 01:58, Joydee= p Tripathi a =C3=A9crit :=0A>> =0A>>>=C2=A0 I can understand that for an LL= N it may be beneficial for not maintaining a precursor list or having only = the destination reply t o a RREQ, there can be (and are) other instances of= MANETs where having the option of precursor list will come handy. This can= save on control overhead, using some storage space in the node. LOAD-ng, i= n most cases does not provide this flexibility to the developer to chose be= tween options for specific deployment. Some MANET deployment may be less ha= rsh than others in nature. Hence, AODVv2 having more open options than LOAD= -ng, in most cases, seem beneficial to me.=0A>> =0A>> _____________________= __________________________=0A>> manet mailing list=0A>> manet@ietf.org=0A>>= https://www.ietf.org/mailman/listinfo/manet =0A>> =0A> =0A> -- =0A> Hitach= i, Ltd., Yokohama Research Laboratory=0A> IGARASHI Yuichi=0A> Mail=EF=BC=9A= yuichi.igarashi.hb@hitachi.com=0A> Tel =EF=BC=9A +81-(0)45-860-3083=0A> FA= X =EF=BC=9A +81-(0)45-860-1673=0A> ________________________________________= _______=0A> manet mailing list=0A> manet@ietf.org=0A> https://www.ietf.org/= mailman/listinfo/manet =0A=0A______________________________________________= _=0Amanet mailing list=0Amanet@ietf.org=0Ahttps://www.ietf.org/mailman/list= info/manet --1886287700-1479670266-1351888702=:57714 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: JP Vasseur (jvasseur) <jvasseur@cisco.c= om>

=0ADear Yuichi,

We all agree tha= t the document should be easy to read and implement; if improvements must b= e made to DYMO-23, and there are =E2=80=A6 let's go ahead and
improve th= e document. Nothing wrong with that. We should not get mix the complexity o= f the document and the protocol.

[Jon] Sometimes they are one in the= same

Jon

On Nov 2, 2012, at 10:54 AM, Yuichi IGARASHI wrote:=

> Hi,
>
> I agree with Martin and I would support o= ption 2) at this stage.
>
> We LOADng co-authors made efforts = to simplify core specification of the reactive protocol and to improve the = readability of the draft. I think this approach is important not only for a= ll implementor to shorten the development time, but also for business opera= tors to make multi-vendor system easier to provide. Of course, I agree that= , as several persons pointed out, "this draft" may limit use case. But we l= eave sufficient space for improving performance/adding functions by companion drafts.
>
> I am re= ally concerned about complexity/difficulty of guaranteeing of interoperabil= ity. If the protocol becomes complicated, we need much time(many years?) fo= r interoperability test. I think we should consider both time required for = merging drafts and shape of document.
>
> Best regards,
>= ; Yuichi
> (2012/11/02 23:01), Martin Heusse wrote:
>>
&= gt;> I'm standing for option 2 (LOADng).
>>
>> I thin= k it's better to agree first on a simple basic (versatile?) protocol before= proposing extensions to it; instead of starting from a collection of ideas= that can be used or not (and we know today what are the options, thank to = the huge amount of work done on reactive routing during the past years). Co= nversely, it would be certainly easier to reach a consensus on a set of var= iants but we need a good reference point, first.
>>
>> Moreover, reactive routing is most probably the approach that= one would pick for a simple case. So it should be simple...
>> >> Martin
>>
>>
>> Le 2 nov. 2012 =C3= =A0 01:58, Joydeep Tripathi a =C3=A9crit :
>>
>>>&nbs= p; I can understand that for an LLN it may be beneficial for not maintainin= g a precursor list or having only the destination reply t o a RREQ, there c= an be (and are) other instances of MANETs where having the option of precur= sor list will come handy. This can save on control overhead, using some sto= rage space in the node. LOAD-ng, in most cases does not provide this flexib= ility to the developer to chose between options for specific deployment. So= me MANET deployment may be less harsh than others in nature. Hence, AODVv2 = having more open options than LOAD-ng, in most cases, seem beneficial to me= .
>>
>> _______________________________________________
>> manet mailing = list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listin= fo/manet=0A
>>
>
> --
> Hitachi, Ltd., Yo= kohama Research Laboratory
> IGARASHI Yuichi
> Mail=EF=BC=9A yuichi.igarashi.hb@hitachi.com
> Tel =EF= =BC=9A +81-(0)45-860-3083
> FAX =EF=BC=9A +81-(0)45-860-1673
> = _______________________________________________
> manet mailing list<= br>> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet=0A

_______________________________________________
manet mailing = list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--1886287700-1479670266-1351888702=:57714-- From jblack.ietf@yahoo.com Fri Nov 2 13:50:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA1811E80E3 for ; Fri, 2 Nov 2012 13:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxKMRhfQqLFO for ; Fri, 2 Nov 2012 13:50:05 -0700 (PDT) Received: from nm15.bullet.mail.bf1.yahoo.com (nm15.bullet.mail.bf1.yahoo.com [98.139.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id DF52E11E80D9 for ; Fri, 2 Nov 2012 13:50:04 -0700 (PDT) Received: from [98.139.212.153] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 20:49:54 -0000 Received: from [98.139.212.204] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 20:49:54 -0000 Received: from [127.0.0.1] by omp1013.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 20:49:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 664203.99983.bm@omp1013.mail.bf1.yahoo.com Received: (qmail 9135 invoked by uid 60001); 2 Nov 2012 20:49:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351889394; bh=K1Xz+GCJyQp+0YWQhkZxLXJQswfvKV4mP73AyJLkTGY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Oh0fym/Q6UjhUE+1NhIDdR0lX0iVnly5Y42DBhTNIcZiAckzkfKYh+R17ElzmhPckw8hikPx5gUSK3qXqTft4SYX9LYSFSxwlHLeyupvM2FgH+QlcEkOi8bZAHiDggR2FW8eLF6iQNfbmvTMWllR2sm1kwAvO/QRyr5+IS0umRA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ZhrTzH2tZ8ngQHW/xI4jahD1zI+07O3ro+f52lKdiDbp8tsZc68Du5Cu8wRkUZlAmOQrRlX/Tz3cHkUXofj8X6Su7vd+2D/FYu5NLxOjkkkVRvaMiBLELJ5cIEpcDWWC0Sj4hphehpKrSOikQw45KT+IfvigS35hcffylA7Ev0g=; X-YMail-OSG: Sv4nkZ0VM1mCvb67rhI9hBShN_XAa1vW4eAhkrkhm4rLxXo 8AVBOPOtoB1YJcMW5QrMO19pocfDbOgLu.YZr4mtKb7ircSC7.VoVt4ErgMq hEq8s45A4PoftEBXvNA74x4WGqvrXMW5CzAssQPh2VLmBW5uAlh4o9p19b2y 7eb0D0rvXQoI04kYSX.WD.O.N_foNyPlOOabvA1nWoL5LZBD54B6LeF6FYYN kLh7jrRaMwwqzOXRNrabXVkAOCCLklRuAapyy9Igdzi9N.OXnZUIVM8hR_qz eCXbRpGIVV4ioyKdpNACCKyo3l0WCivQcfXOOPbyL0a3IPyL4AKQ34g60llB hq_84jhJvRzrgDb.dNx6tWOVBS3NR.Arr1S9LZ_V6hNGE9WgClr2f9..CcsA 7_L46bNaXbrra8.aCixl.AZcWX4TDtf6LN_fQmNBuH1NF1gvWP7j8ye6EffS 4Dl7.e6It Received: from [173.193.202.116] by web160601.mail.bf1.yahoo.com via HTTP; Fri, 02 Nov 2012 13:49:54 PDT X-Rocket-MIMEInfo: 001.001, RnJvbTogSlAgVmFzc2V1ciAoanZhc3NldXIpIDxqdmFzc2V1ckBjaXNjby5jb20.CgpPbiBOb3YgMiwgMjAxMiwgYXQgMTE6MDggQU0sIFVscmljaCBIZXJiZXJnIHdyb3RlOgoKSSB0aGluayBvbmUga2V5IHBvaW50IHRvIHN0cmVzcyBpcyBvbmUgdGhhdCBDaHJpcyBtZW50aW9uZWQ6Cj5Cb3RoIHByb3RvY29scyBhcmUgc2ltaWxhciBpbiB0aGVpciBvcGVyYXRpb24gYW5kIHBlcmZvcm1hbmNlLiBTbyBhbnlvbmUgYXJndWluZyBhZ2FpbnN0IHRoZSBwZXJmb3JtYW5jZSBvZiBMT0FEbmcgaXMgYXV0b21hdGkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> Message-ID: <1351889394.5207.YahooMailNeo@web160601.mail.bf1.yahoo.com> Date: Fri, 2 Nov 2012 13:49:54 -0700 (PDT) From: Jon Black To: "JP Vasseur \(jvasseur\)" , Ulrich Herberg In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1737431079-1789328019-1351889394=:5207" Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 20:50:06 -0000 --1737431079-1789328019-1351889394=:5207 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: JP Vasseur (jvasseur) =0A=0AOn Nov 2, 2012, at 11= :08 AM, Ulrich Herberg wrote:=0A=0AI think one key point to stress is one t= hat Chris mentioned:=0A>Both protocols are similar in their operation and p= erformance. So anyone arguing against the performance of LOADng is automati= cally also not interested in DYMO. =0A>=0A>=0A=0ASee my point Ulrich =E2=80= =A6 and I wrote it down several times. There are major concerns in using Lo= ad-ng with LLNs. Quoting Load-ng:=0A=0A3. Applicability Statement This pro= tocol: o Is a reactive routing protocol for Mobile Ad hoc NETworks (MANETs= ). o Is designed to work in networks with dynamic topology in which the li= nks may be lossy due to collisions or unstable channel. The use cases incl= ude vehicular networks, low power and lossy networks, community networks, m= ilitary networks, disaster recovery networks, etc. =0A=0AThis is where I st= rongly object, as several other ones on this mailing list. One cannot simpl= y forget 4-5 years of hard work from a WG that focussed=C2=A0=0Aon this use= case=C2=A0and concluded that such protocol is not applicable to LLNs.=0A= =0A[Jon] Is that your true objection to the LOADng draft.=C2=A0 Then I woul= d think the simple solution is to remove this one paragraph and move on.=C2= =A0 =0ADevelopers will=C2=A0 decide what protocols are applicable to their = application as they should - as I will.=0AI will ask in ROLL where the conc= lusion was drawn that you cannot possibly use a reactive protocol in any LL= N application.=C2=A0 That is for a discussion in ROLL not here.=0AAgain if = this one paragraph is all the fuss then lets please reach consensus to remo= ve this and move forward.=C2=A0 Gosh that seems simple.=0A=0AJon=0A=0A=0A= =0AHowever, LOADng is far closer to become an RFC in terms of the document = quality. If we start the new reactive protocol on the basis of the LOADng d= raft (and I personally don't care what we name that protocol is), we can co= ntinue the work on the reactive protocol together and discuss the multiple = options that are currently in DYMO and see whether they should be discarded= , put into a companion document or in the core spec. =0A>=0A>Best=0A>Ulrich= =0A>=0A>On Nov 2, 2012, at 7:54, Yuichi IGARASHI wrote:=0A>=0A>=0A>Hi,=0A>>=0A>=0A>>=0A>I agree with Martin and I wou= ld support option 2) at this stage.=0A>>=0A>=0A>>=0A>We LOADng co-authors m= ade efforts to simplify core specification of the reactive protocol and to = improve the readability of the draft. I think this approach is important no= t only for all implementor to shorten the development time, but also for bu= siness operators to make multi-vendor system easier to provide. Of course, = I agree that, as several persons pointed out, "this draft" may limit use ca= se. But we leave sufficient space for improving performance/adding function= s by companion drafts.=0A>>=0A>=0A>>=0A>I am really concerned about complex= ity/difficulty of guaranteeing of interoperability. If the protocol becomes= complicated, we need much time(many years?) for interoperability test. I t= hink we should consider both time required for merging drafts and shape of = document.=0A>>=0A>=0A>>=0A>Best regards,=0A>>=0A>Yuichi=0A>>=0A>(2012/11/02= 23:01), Martin Heusse wrote:=0A>>=0A>=0A>>>=0A>I'm standing for option 2 (= LOADng).=0A>>>=0A>=0A>>>=0A>I think it's better to agree first on a simple = basic (versatile?) protocol before proposing extensions to it; instead of s= tarting from a collection of ideas that can be used or not (and we know tod= ay what are the options, thank to the huge amount of work done on reactive = routing during the past years). Conversely, it would be certainly easier to= reach a consensus on a set of variants but we need a good reference point,= first.=0A>>>=0A>=0A>>>=0A>Moreover, reactive routing is most probably the = approach that one would pick for a simple case. So it should be simple...= =0A>>>=0A>=0A>>>=0A>Martin=0A>>>=0A>=0A>>>=0A>=0A>>>=0A>Le 2 nov. 2012 =C3= =A0 01:58, Joydeep Tripathi a =C3=A9crit :=0A>>>=0A>=0A>>>=0A>I can underst= and that for an LLN it may be beneficial for not maintaining a precursor li= st or having only the destination reply t o a RREQ, there can be (and are) = other instances of MANETs where having the option of precursor list will co= me handy. This can save on control overhead, using some storage space in th= e node. LOAD-ng, in most cases does not provide this flexibility to the dev= eloper to chose between options for specific deployment. Some MANET deploym= ent may be less harsh than others in nature. Hence, AODVv2 having more open= options than LOAD-ng, in most cases, seem beneficial to me.=0A>>>>=0A>=0A>= >>=0A>_______________________________________________=0A>>>=0A>manet mailin= g list=0A>>>=0A>manet@ietf.org=0A>>>=0A>https://www.ietf.org/mailman/listin= fo/manet=0A>>>=0A>=0A>>>=0A>=0A>>=0A>-- =0A>>=0A>Hitachi, Ltd., Yokohama Re= search Laboratory=0A>>=0A>IGARASHI Yuichi=0A>>=0A>Mail=EF=BC=9A yuichi.igar= ashi.hb@hitachi.com=0A>>=0A>Tel =EF=BC=9A +81-(0)45-860-3083=0A>>=0A>FAX = =EF=BC=9A +81-(0)45-860-1673=0A>>=0A>______________________________________= _________=0A>>=0A>manet mailing list=0A>>=0A>manet@ietf.org=0A>>=0A>https:/= /www.ietf.org/mailman/listinfo/manet=0A>>=0A_______________________________= ________________=0A>manet mailing list=0A>manet@ietf.org=0A>https://www.iet= f.org/mailman/listinfo/manet=0A>=0A=0A_____________________________________= __________=0Amanet mailing list=0Amanet@ietf.org=0Ahttps://www.ietf.org/mai= lman/listinfo/manet --1737431079-1789328019-1351889394=:5207 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: JP Vasse= ur (jvasseur) <jvasseur@cisco.com>

On Nov 2, 2012, at 11:08 AM= , Ulrich Herberg wrote:
<= /div>
=0A
=0A=0A=0A
I think one key p= oint to stress is one that Chris mentioned:
=0ABoth protocols are simila= r in their operation and performance. So anyone arguing against the perform= ance of LOADng is automatically also not interested in DYMO.=0A
=0A
= =0A
=0A=0A

=0A
= =0A
See my point Ulrich =E2=80=A6 and I wr= ote it down several times. There are major concerns in using Load-ng with L= LNs. Quoting Load-ng:
=0A

=0A=0A
=0A
3.  Applicability Statement
=0A=0A   This protocol:=0A=0A   o  Is a reactive routing protocol for Mob=
ile Ad hoc NETworks=0A      (MANETs).=0A=0A   o  Is designed to work in net=
works with dynamic topology in which the=0A      links may be lossy due to =
collisions or unstable channel.  The use=0A      cases include vehicular ne=
tworks, low power and lossy networks,=0A      community networks, military =
networks, disaster recovery networks,=0A      etc.=0A
=0A

=0A<= /div>=0A
This is where I strongly object, as several other ones on this= mailing list. One cannot simply forget 4-5 years of hard work from a WG th= at focussed 
=0A
on this use case and concluded that suc= h protocol is not applicable to LLNs.

[Jon] Is that your= true objection to the LOADng draft.  Then I would think the simple so= lution is to remove this one paragraph and move on. 
Developers wi= ll  decide what protocols are applicable to their application as they = should - as I will.
I will ask in ROLL where the conclusion was drawn th= at you cannot possibly use a reactive protocol in any LLN application. = ; That is for a discussion in ROLL not here.
Again if this one paragraph= is all the fuss then lets please reach consensus to remove this and move f= orward.  Gosh that seems simple.

Jon

=0A
=0A

=0A
=0A
However, LOADng is f= ar closer to become an RFC in terms of the document quality. If we start th= e new reactive protocol on the basis of the LOADng draft (and I personally = don't care what we name that protocol is), we can continue the work on the = reactive=0A protocol together and discuss the multiple options that are cur= rently in DYMO and see whether they should be discarded, put into a compani= on document or in the core spec.=0A
=0A
=0ABest
=0AUlrich
=0A=0AOn Nov 2, 2012, at 7:54, Yuichi IGARASHI <yuichi.igarashi.hb@hitachi.com> w= rote:
=0A
=0A
Hi,
=0A
=0A
=0A
=0A
I ag= ree with Martin and I would support option 2) at this stage.
=0A=0A

=0A
=0A
We LOADng co-authors made efforts to simplify core specification = of the reactive protocol and to improve the readability of the draft. I thi= nk this approach is important not only for all implementor to shorten the d= evelopment time, but=0A also for business operators to make multi-vendor sy= stem easier to provide. Of course, I agree that, as several persons pointed= out, "this draft" may limit use case. But we leave sufficient space for im= proving performance/adding functions by companion drafts.
=0A=0A

=0A
=0A
I am really concerned about complexity/difficulty of guaranteeing of i= nteroperability. If the protocol becomes complicated, we need much time(man= y years?) for interoperability test. I think we should consider both time r= equired for merging=0A drafts and shape of document.
=0A
=0A=

=0A
=0A
= Best regards,
=0A
=0A
Yuichi
=0A=
=0A
(2012/11/02 23:01), Martin Heusse= wrote:
=0A
=0A
=0A

=0A
=0A
=0A
= =0A
I'm standing for option 2 (LOADng).
=0A=0A
=0A
=0A

=0A
=0A
=0A
= =0A
I think it's better to agree first on a simple= basic (versatile?) protocol before proposing extensions to it; instead of = starting from a collection of ideas that can be used or not (and we know to= day what are the options, thank to the=0A huge amount of work done on react= ive routing during the past years). Conversely, it would be certainly easie= r to reach a consensus on a set of variants but we need a good reference po= int, first.
=0A
=0A
=0A
=0A

=0A
=0A
=0A=0A
Moreover, reactive routing= is most probably the approach that one would pick for a simple case. So it= should be simple...
=0A
=0A
=0A
=0A

=0A
=0A
= =0A
=0A
Martin
=0A=0A
=0A
=0A

=0A
=0A
=0A
= =0A

=0A
=0A
=0A=0A
Le 2 nov. 2012 =C3=A0 01:58= , Joydeep Tripathi a =C3=A9crit :
=0A
=0A
=0A=0A

=0A
=0A=
=0A
=0A
=0A<= blockquote type=3D"cite">I can understand that for an LLN it may be benefic= ial for not maintaining a precursor list or having only the destination rep= ly t o a RREQ, there can be (and are) other instances of MANETs where havin= g the option of precursor list will=0A come handy. This can save on control= overhead, using some storage space in the node. LOAD-ng, in most cases doe= s not provide this flexibility to the developer to chose between options fo= r specific deployment. Some MANET deployment may be less harsh than others= =0A in nature. Hence, AODVv2 having more open options than LOAD-ng, in most= cases, seem beneficial to me.
=0A
=0A
=0A=0A
=0A

=0A=0A
=0A
=0A
_______________________________________________
=0A=0A
=0A
=0A
manet mailing list
=0A
=0A
=0A
=0A
manet@ie= tf.org
=0A
=0A
=0A
= =0A
https://www.ietf.org/mailman/l= istinfo/manet
=0A
=0A
=0A
=0A

=0A
=0A
=0A=

=0A
=0A
= --
=0A
=0A
Hitachi, Ltd., Yokohama= Research Laboratory
=0A
=0A
IGARAS= HI Yuichi
=0A
=0A
Mail=EF=BC=9A yuichi.igarashi.= hb@hitachi.com
=0A
=0A
Tel =EF= =BC=9A +81-(0)45-860-3083
=0A
=0A
F= AX =EF=BC=9A +81-(0)45-860-1673
=0A
=0A
_______________________________________________
=0A
=0A=
manet mailing list
=0A
=0Amanet@ietf.org
=0A=0A
https://www.ietf.org/= mailman/listinfo/manet
=0A
=0A__________________________= _____________________
=0Amanet mailing list
=0Amanet@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/manet<= br>=0A
=0A=0A
=0A
=0A
=0A=0A

______________________= _________________________
manet mailing list
manet@ietf.org
https://= www.ietf.org/mailman/listinfo/manet


--1737431079-1789328019-1351889394=:5207-- From jblack.ietf@yahoo.com Fri Nov 2 14:10:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7B01F0C8C for ; Fri, 2 Nov 2012 14:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3454rWFpzw9G for ; Fri, 2 Nov 2012 14:10:56 -0700 (PDT) Received: from nm26.bullet.mail.bf1.yahoo.com (nm26.bullet.mail.bf1.yahoo.com [98.139.212.185]) by ietfa.amsl.com (Postfix) with ESMTP id 0E15F1F0C84 for ; Fri, 2 Nov 2012 14:10:54 -0700 (PDT) Received: from [98.139.212.148] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 21:10:54 -0000 Received: from [98.139.212.196] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 21:10:54 -0000 Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 21:10:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 267273.47234.bm@omp1005.mail.bf1.yahoo.com Received: (qmail 89533 invoked by uid 60001); 2 Nov 2012 21:10:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351890653; bh=HYxJ/0mpoOAFeIboNImPB6E/Z3KL+jTnreyR7xwVxfA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=DUNFLPT4jwlGDq+1MzDSGV8PDx3qsANzrTHb9Wcm53GH/upuWKQiOiMHkwT44MPig4cXPXJuICnz+4ysDgrIGuAIe/3Qnanl6pNSN9DQa6IzwXiJJwKMSaqFCuMkEBi0OaKFATJJEEE1hrxi6B/Jub8Fk2bo/GhS9W9urBjMU5M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Ysrjo/AcARuZtb/dybIoNoKYX8ktGvPcpP99q0LXyw341VqSMCcD/IE6epb/jz6tm32//4PPSMizSGGzYMzxTLFR9eGGo/6o1/Kk7MHNPL9eXzoQn3KP80UTSX3cAgfHPWb+4K4ydFp5xxqNMFz7qukxtSFUWer0HrRrZFCFrbM=; X-YMail-OSG: 0aNIi88VM1nASIjZdV1jXVwKg1KweNg5pP1Og8ZlUFYWuGU h49uwPBLWbTQU6lNbIBIUZcTX3FdVDLZ0sheCvEjhmMNAtJ2LQS_ra5QLNTc qt15xdt6KzdLVMgP5ApHS2hAhyTHgMTaFc9p6txvRezJgNvf5XZiTik4l5_0 yQtzhVG3G5hlI0lOHakzwYPXaJLSB5Oc0CzUsRKKZ6arY58h4mr7MG2AGEz0 xYBcfq6EfV8unYLiuFmDBmrKCZ8ylUxE7ARI2kqfGVUxoy1505iKtHHHr0WS ompdkhKu8Qy9tRGRmLu9WXpinIZlVZoI0k_zdV6TGFGK8stMYr97ZdZCkFwE Lyf.LNaXN5Okk5z629zGY6UG3XyrX4zNYAZsQOTrGIVuzZx57v6jzrAhPVuT HHZr8nAXiYUt8GrDFfZQ51Iq41RpcxTZbmAbJyvy3UID8lw2aHpiY5Rk7zrh AEsOJHGILW3D5v8tcf1KqgUkPsQCe7p6lYX1enpgW2Xwakz5..MJSkYJV45l 7LjL5oZ7QhfUtBE_NsHb2vsU- Received: from [173.193.202.116] by web160603.mail.bf1.yahoo.com via HTTP; Fri, 02 Nov 2012 14:10:53 PDT X-Rocket-MIMEInfo: 001.001, SXQgaXMgbm90IGNvbXBsZXRlbHkgbmV3IGFuZCBpdCBpcyBtdWNoIG1vcmUgbWF0dXJlLsKgIEl0IGhhcyBiZWVuIGJlaW5nIGRldmVsb3BlZCBmb3IgcXVpdGUgc29tZSB0aW1lLCBpdCBoYXMgaW1wbGVtZW50YXRpb25zLCBpdCBoYXMgaW50ZXJvcGVyYWJpbGl0eS7CoCBBZ2Ugb2YgYSBkb2N1bWVudCBpcyBub3QgYSBnb29kIGNyaXRlcmlhLsKgIFNvbWV0aGluZyBjYW4gYmUgd3JpdHRlbiBxdWl0ZSBhIGxvbmcgdGltZSBhZ28gYW5kIG5vdGhpbmcgZG9uZSBvbiBpdC7CoCBBbm90aGVyIGRvY3VtZW50L3ABMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> <1351876587.86080.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204C69E@xmb-rcd-x02.cisco.com> Message-ID: <1351890653.89343.YahooMailNeo@web160603.mail.bf1.yahoo.com> Date: Fri, 2 Nov 2012 14:10:53 -0700 (PDT) From: Jon Black To: "JP Vasseur \(jvasseur\)" , Ulrich Herberg , Abdussalam Baryun , "Dearlove, Christopher \(UK\)" , "manet@ietf.org List" In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204C69E@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1886287700-2015016816-1351890653=:89343" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 21:10:57 -0000 --1886287700-2015016816-1351890653=:89343 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It is not completely new and it is much more mature.=C2=A0 It has been bein= g developed for quite some time, it has implementations, it has interoperab= ility.=C2=A0 Age of a document is not a good criteria.=C2=A0 Something can = be written quite a long time ago and nothing done on it.=C2=A0 Another docu= ment/protocol may come along, gain critical mass, gain experience and even = though younger may be a much better starting point.=0A=0AJon=0A=0A=0A=0A___= _____________________________=0A From: JP Vasseur (jvasseur) =0ATo: Jon Black ; Ulrich Herberg ; Abdussalam Baryun ; "Dearlove, Chris= topher (UK)" ; "manet@ietf.org List" =0ASent: Friday, November 2, 2012 11:21 AM=0ASubject: Re: [manet]= A proposal - differentiating the document and the protocol=0A =0A=0Aso =E2= =80=A6 should we start with a completely new document then ? =0A=0A=0AOn No= v 2, 2012, at 1:16 PM, Jon Black wrote:=0A=0AThis seems to make good sense.= =C2=A0 The name should not be issue.=C2=A0 We need a good solid base to sta= rt from.=C2=A0 It would appear that if there are working interoperable impl= ementation based on the LOADng draft then this indicates that the draft is = implementable.=C2=A0 Again, having read both I could build something based = on the LOADng draft and I (and I'm only talking for me) couldn't based on t= he DYMO draft.=0A>=0A>I much prefer starting with something simple and unde= rstandable and adding what is missing rather than starting with something m= ore difficult to understand trying to remove things that are not needed.=0A= >=0A>Jon=0A>=0A>=0A>=0A>=0A>=0A>=0A>________________________________=0A> Fr= om: Ulrich Herberg =0A>To: Abdussalam Baryun =0A>Cc: "Dearlove, Christopher (UK)" ; "manet@ietf.org" =0A>Sent: Friday, November= 2, 2012 10:34 AM=0A>Subject: Re: [manet] A proposal - differentiating the = document and the protocol=0A>=0A>=0A>Hi Abdussalam, =0A>=0A>=0A>there was i= ndeed some hesitance to change the name from some of the authors (not me). = I cannot speak for them here. My intuition is that if the name of the proto= col is the only factor that avoids the reactive protocol from proceeding in= the WG, this can be solved.=0A>=0A>=0A>As far as I can see from the discus= sions so far, there is a clear consensus that option 3 is not viable. Now, = if we want to proceed with the reactive document, the question is from whic= h document to start. Chris mentioned that even if we wanted the specificati= on of 100%, it would be far quicker to start from the LOADng draft.=C2=A0I = propose that we can start working based on the LOADng draft=C2=A0(possibly = rename it?), look at each item that is in DYMO and consider whether and in = which way it should be incorporated in the draft.=C2=A0=0A>=0A>=0A>Best=0A>= Ulrich=0A>=0A>=0A>=0A>=0A>=0A>=0A>On Fri, Nov 2, 2012 at 9:17 AM, Abdussala= m Baryun wrote:=0A>=0A>Hi Ulrich,=0A>>=C2=A0= =0A>>I think that=C2=A0Chris's proposal was not accepted by LOADng co-autho= rs as I understood from following up the WG history (they don't agree to ch= ange the name of protocol). As you are one co-author do I understand that y= ou support the Chris's proposal,=0A>>=0A>>AB=0A>>=0A>>On Fri, Nov 2, 2012 a= t 2:41 PM, Ulrich Herberg wrote:=0A>>=0A>>Dear Chris,= =0A>>>=0A>>>personally, what you propose makes sense to me.=0A>>>=0A>>>=0A>= >>Regards=0A>>>Ulrich=0A>>> =0A>>>=0A>>>On Nov 2, 2012, at 4:16, "Dearlove,= Christopher (UK)" wrote:=0A>>>=0A>>>> Befo= re making a proposal, I'm going to introduce a distinction here between the= DYMO and LOADng documents and protocols.=0A>>>>=0A>>>> I'm of the opinion = that the LOADng document is a greatly superior presentation to the DYMO doc= ument. (I'm not really interested in why that has come about.)=0A>>>>=0A>>>= > I think that regardless of whether one makes design decisions favouring D= YMO or LOADng where they differ - and let's not forget they overlap a lot -= it would actually be easier to modify the LOADng document to specify DYMO = than it would be to modify the DYMO=0A document to achieve that. And in pra= ctice I think if making decisions it is unlikely that all would favour DYMO= over LOADng.=0A>>>>=0A>>>> So what I think would be best for the WG is not= a simply "option 1" or even (as it may appear I'm suggesting, but =C2=A0I'= m not) "option 2" but rather to agree to take the LOADng document, and a li= st of where DYMO and LOADng differ, and thrash out where they do,=0A what t= he WG reactive protocol should do - either as a definite choice, or as an o= ption (but not too many options please- and some could be separate specific= ations).=0A>>>>=0A>>>> This would not of course be LOADng, so we'd have to = change the document name. And there I suggest we have a candidate name - AO= DVv2. (Which is why I have recently taken to saying DYMO when referring to = that document.) After all, the one thing we are agreed=0A on is that the pr= otocol being developed is derived from AODV.=0A>>>>=0A>>>> The editors of t= his new document would have to agree that what goes in it is WG consensus (= which should follow proper technical consideration of the issues). If they = found it impossible to have other than their way to do things, they'd have = to move on. If=0A that left no one editing it, obviously we don't have a co= nsensus of people prepared to do the work and option 3 would win.=0A>>>>=0A= >>>> So now I'm partly off the fence I've been sitting on. But only partly.= I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as stan= dard, IRREPs as an option in the main draft, IRREPs as a separate draft opt= ion, no IRREPs. I'd like to move on=0A to those discussions.=0A>>>>=0A>>>> = --=0A>>>> Christopher Dearlove=0A>>>> Senior Principal Engineer, Communicat= ions Group=0A>>>> Communications, Networks and Image Analysis Capability=0A= >>>> BAE Systems Advanced Technology Centre=0A>>>> West Hanningfield Road, = Great Baddow, Chelmsford, CM2 8HN, UK=0A>>>> Tel: +44 1245 242194 | =C2=A0F= ax: +44 1245 242124=0A>>>> chris.dearlove@baesystems.com | http://www.baesy= stems.com=0A>>>>=0A>>>> BAE Systems (Operations) Limited=0A>>>> Registered = Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough= , Hants, GU14 6YU, UK=0A>>>> Registered in England & Wales No: 1996687=0A>>= >>=0A>>>>=0A>>>>=0A>>>> ***************************************************= *****************=0A>>>> This email and any attachments are confidential to= the intended=0A>>>> recipient and may also be privileged. If you are not t= he intended=0A>>>> recipient please delete it from your system and notify t= he sender.=0A>>>> You should not copy it or use it for any purpose nor disc= lose or=0A>>>> distribute its contents to any other person.=0A>>>> ********= ************************************************************=0A>>>>=0A>>>> = _______________________________________________=0A>>>> manet mailing list= =0A>>>> manet@ietf.org=0A>>>> https://www.ietf.org/mailman/listinfo/manet= =0A>>>_______________________________________________=0A>>>manet mailing li= st=0A>>>manet@ietf.org=0A>>>https://www.ietf.org/mailman/listinfo/manet=0A>= >>=0A>>=0A>=0A>_______________________________________________=0A>manet mai= ling list=0A>manet@ietf.org=0A>https://www.ietf.org/mailman/listinfo/manet= =0A>=0A>=0A>=0A_______________________________________________=0A>manet mai= ling list=0A>manet@ietf.org=0A>https://www.ietf.org/mailman/listinfo/manet= =0A> --1886287700-2015016816-1351890653=:89343 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
It is not completely = new and it is much more mature.  It has been being developed for quite= some time, it has implementations, it has interoperability.  Age of a= document is not a good criteria.  Something can be written quite a lo= ng time ago and nothing done on it.  Another document/protocol may com= e along, gain critical mass, gain experience and even though younger may be= a much better starting point.

Jon

<= div style=3D"font-family: times new roman, new york, times, serif; font-siz= e: 12pt;">
From: JP Vasseur (jvass= eur) <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>; Ulrich Herb= erg <ulrich@herberg.name>; Abdussalam Baryun <abdussalambaryun@gma= il.com>; "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com&= gt;; "manet@ietf.org List" <manet@ietf.org>
Sent: Friday, November 2, 2012 11:21 AM
Subject: Re: [manet] A propo= sal - differentiating the document and the protocol

= =0A
=0A=0A =0A=0A
=0Aso =E2=80=A6 should we start with a comp= letely new document then ?=0A

=0A
=0A
On Nov 2, 2012, at 1:= 16 PM, Jon Black wrote:
=0A
=0A
=0A
=0A
=0AThis seems to make good sense.  The name should not= be issue.  We need a good solid base to start from.  It would ap= pear that if there are working interoperable implementation based on the LO= ADng draft then this indicates that the draft is implementable.  Again= ,=0A having read both I could build something based on the LOADng draft and= I (and I'm only talking for me) couldn't based on the DYMO draft.
=0A=0AI much prefer starting with something simple and understandable and ad= ding what is missing rather than starting with something more difficult to = understand trying to remove things that are not needed.
=0A
=0AJon=0A

=0A
=0A

=0A
=0A
=0A
=0A
=0A
= =0AFrom: Ulrich Herberg <= ;ulrich@herberg.name>
=0ATo: Abdussalam Baryun <abdussalambaryun@gmail.com= >=0A
=0ACc: "Dear= love, Christopher (UK)" <Chris.Dearlove@baesystems.com>; "manet@ietf.org" <manet@ietf.org&= gt;=0A
=0ASent: Friday, = November 2, 2012 10:34 AM
=0ASubjec= t: Re: [manet] A proposal - differentiating the document and the= protocol
=0A
=0A
=0A =0A
Hi Abd= ussalam,=0A

=0A
=0A
there was indeed some hesitance to cha= nge the name from some of the authors (not me). I cannot speak for them her= e. My intuition is that if the name of the protocol is the only factor that= avoids the reactive protocol from proceeding in the WG, this can=0A be sol= ved.
=0A

=0A
=0A
As far as I can see from the discuss= ions so far, there is a clear consensus that option 3 is not viable. Now, i= f we want to proceed with the reactive document, the question is from which= document to start. Chris mentioned that even if we wanted the specificatio= n=0A of 100%, it would be far quicker to start from the LOADng draft. = I propose that we can start working based on the LOADng draft (possibl= y rename it?), look at each item that is in DYMO and consider whether and i= n which way it should be incorporated in the draft. 
=0A

= =0A
=0A
Best
=0A
Ulrich
=0A

=0A
=0A
=0A
=0A
=0A

=0A
On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun=0A<= ;abdussalambaryun@gma= il.com> wrote:
=0A
=0A
Hi Ulrich,
=0A
 
=0A
I think that = Chris's proposal was not accepted by LOADng co-authors as I understood from= following up the WG history (they don't agree to change the name of protoc= ol). As you are one co-author do I understand that you support the Chris's = proposal,
=0A
=0A
AB
=0A
=0A
=0A
=0A
On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg=0A<ulrich@herberg.name> wrote:
=0A
=0ADear Chris,
=0A
= =0Apersonally, what you propose makes sense to me.
=0A
=0A
=0ARega= rds
=0AUlrich
=0A=0A
= =0A

=0AOn Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@ba= esystems.com> wrote:
=0A
=0A> Before making a proposal, I'm= going to introduce a distinction here between the DYMO and LOADng document= s and protocols.
=0A>
=0A> I'm of the opinion that the LOADng d= ocument is a greatly superior presentation to the DYMO document. (I'm not r= eally interested in why that has come about.)
=0A>
=0A> I think= that regardless of whether one makes design decisions favouring DYMO or LO= ADng where they differ - and let's not forget they overlap a lot - it would= actually be easier to modify the LOADng document to specify DYMO than it w= ould be to modify the DYMO=0A document to achieve that. And in practice I t= hink if making decisions it is unlikely that all would favour DYMO over LOA= Dng.
=0A>
=0A> So what I think would be best for the WG is not = a simply "option 1" or even (as it may appear I'm suggesting, but  I'm= not) "option 2" but rather to agree to take the LOADng document, and a lis= t of where DYMO and LOADng differ, and thrash out where they do,=0A what th= e WG reactive protocol should do - either as a definite choice, or as an op= tion (but not too many options please- and some could be separate specifica= tions).
=0A>
=0A> This would not of course be LOADng, so we'd h= ave to change the document name. And there I suggest we have a candidate na= me - AODVv2. (Which is why I have recently taken to saying DYMO when referr= ing to that document.) After all, the one thing we are agreed=0A on is that= the protocol being developed is derived from AODV.
=0A>
=0A> T= he editors of this new document would have to agree that what goes in it is= WG consensus (which should follow proper technical consideration of the is= sues). If they found it impossible to have other than their way to do thing= s, they'd have to move on. If=0A that left no one editing it, obviously we = don't have a consensus of people prepared to do the work and option 3 would= win.
=0A>
=0A> So now I'm partly off the fence I've been sitti= ng on. But only partly. I haven't yet formed a view on e.g. should this AOD= Vv2 have IRREPs as standard, IRREPs as an option in the main draft, IRREPs = as a separate draft option, no IRREPs. I'd like to move on=0A to those disc= ussions.
=0A>
=0A> --
=0A> Christopher Dearlove
=0A>= ; Senior Principal Engineer, Communications Group
=0A> Communications= , Networks and Image Analysis Capability
=0A> BAE Systems Advanced Te= chnology Centre
=0A> West Hanningfield Road, Great Baddow, Chelmsford= , CM2 8HN, UK
=0A> Tel: +44 1245 242194= |  Fax: =0A+44 1245 242124
= =0A> =0Achris.= dearlove@baesystems.com | http://www.baesystems.com
=0A>
= =0A> BAE Systems (Operations) Limited
=0A> Registered Office: Warw= ick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU1= 4 6YU, UK
=0A> Registered in England & Wales No: 1996687
=0A&g= t;
=0A>
=0A>
=0A> ***************************************= *****************************
=0A> This email and any attachments are= confidential to the intended
=0A> recipient and may also be privileg= ed. If you are not the intended
=0A> recipient please delete it from = your system and notify the sender.
=0A> You should not copy it or use= it for any purpose nor disclose or
=0A> distribute its contents to a= ny other person.
=0A> ***********************************************= *********************
=0A>
=0A> _______________________________= ________________
=0A> manet mailing list
=0A> =0Amanet@ietf.org
=0A> =0Ahttps://www.= ietf.org/mailman/listinfo/manet
=0A_________________________________= ______________
=0Amanet mailing list
=0Amanet@ietf.org
=0Ahttps://www.ietf.org/mailman/list= info/manet
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A = =0A
=0A_______________________________________________
=0Amanet maili= ng list
=0Amanet@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/manet
=0A
=0A
= =0A
=0A
=0A
=0A
=0A____________________________________= ___________
=0Amanet mailing list
=0Amane= t@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/manet
=0A=0A
=0A
=0A
=0A
=0A=0A


--1886287700-2015016816-1351890653=:89343-- From jblack.ietf@yahoo.com Fri Nov 2 14:23:24 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1D911E80E5 for ; Fri, 2 Nov 2012 14:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.035 X-Spam-Level: X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njHEwtp1fG1h for ; Fri, 2 Nov 2012 14:23:23 -0700 (PDT) Received: from nm32-vm4.bullet.mail.bf1.yahoo.com (nm32-vm4.bullet.mail.bf1.yahoo.com [72.30.239.140]) by ietfa.amsl.com (Postfix) with ESMTP id 37DD111E80DE for ; Fri, 2 Nov 2012 14:23:23 -0700 (PDT) Received: from [98.139.212.153] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 21:23:22 -0000 Received: from [98.139.215.250] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 21:23:22 -0000 Received: from [127.0.0.1] by omp1063.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 21:23:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 366302.20795.bm@omp1063.mail.bf1.yahoo.com Received: (qmail 80153 invoked by uid 60001); 2 Nov 2012 21:23:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351891402; bh=lK3ZU4OA1shdWmNLMkwBtrQlpZwlf62sTQD8tsBBtco=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ujmA6jTKSR7fzdDDXw+gj3dDQCOOeHWmCI+EvLOLw7i1pXDrztOtyIoicPqXK59Pqkd8Wxl0/rOclVDyvXtpsdHmMVL6TmXW6cjjXv8mbGVPsC3ihVp/FsvTLzdFliVO4Jgdq/ikzupDJtesPBrpzx9XerQnXneI9nwwu0Nsqu0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=4LXpVvmpHgPoW/CHU7HeGNsvx/jd4VbE2HuYoN92qsGuiniKV0J3n6ypulY1wHuvWyGDolF7S7xMRPh4thwf6K3rzzsMFEiWGvIIT6AsjtZZqcteE5sBn0BUvh7VpZCfpaEfWt5y3LZtfnbj/TP6ay383zn/ZBq18f3qhISw2f4=; X-YMail-OSG: Olj2POYVM1l6kOuiwOoymkM_rEOX8rJtoxgriE7ijWwVdf9 Bgc7GkmUr5BFUNM57pMuVE8J1bMJnaqxxfnktrtHlgbElXV50mCA84DLTi2B QK5mk1DNe72thDhY92B8hyKlyylA3zoisKWwTTGfEcMY_Z8B1._ON_TRL6TR .MKOVsfOsupUld8vNHc1lmF4LWQiZWHma41AHxPLgIh38XI9WkNpnV1mN1oQ BHRqTk8AkQ24N1xDCH2fY0LxwvNTqzHp4ZL8NSdHIC8WNqU14tyfKHQvWLeb ILY5pcZqOKoiG7PQbtZjVVVWmtSFdO2QIHHhox6GMORcq_iiZJxIF5vzNy3i PVZ9ZqmeTMwRj5sowaHEplKv6ps09WWgn015nePquoZMEaOUW1O2SNnENElS AYFO36D.oFtKN9Gnv72ucwAkicGu1CvfR95OpBnHA4c5a7BNx8kMQZovHN5c g8P81t5Oi_gNtk1xe8Xnwc..PBoyiPcsRDGjl64iL.9YcrX3zXXu2VLtUekr MXBZpLHaCwBAo2.ec7uJOjDGm8NtjnAVZyikQyTYhU0FHAShEApcY5A7Hufn jVd2GmLgskG.v1W1S70L7g1O9QxE2gc6N9swFyhso9.yAnAJuYVlN1RJ.LMh r Received: from [173.193.202.116] by web160605.mail.bf1.yahoo.com via HTTP; Fri, 02 Nov 2012 14:23:22 PDT X-Rocket-MIMEInfo: 001.001, c2VlIGxpbmUgW0pvbl0KCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBKUCBWYXNzZXVyIChqdmFzc2V1cikgPGp2YXNzZXVyQGNpc2NvLmNvbT4KCkhpIFVscmljaCwgCgoKT24gTm92IDIsIDIwMTIsIGF0IDE6MjIgUE0sIFVscmljaCBIZXJiZXJnIHdyb3RlOgoKSlAsCj4KPgo.T24gRnJpLCBOb3YgMiwgMjAxMiBhdCAxMDowOSBBTSwgSlAgVmFzc2V1ciAoanZhc3NldXIpIDxqdmFzc2V1ckBjaXNjby5jb20.IHdyb3RlOgo.Cj4KPj5PbiBOb3YgMiwgMjAxMiwgYXQgMTI6MDYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C845@xmb-rcd-x02.cisco.com> Message-ID: <1351891402.40332.YahooMailNeo@web160605.mail.bf1.yahoo.com> Date: Fri, 2 Nov 2012 14:23:22 -0700 (PDT) From: Jon Black To: "JP Vasseur \(jvasseur\)" , Ulrich Herberg In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204C845@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1933122451-1380974158-1351891402=:40332" Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 21:23:24 -0000 ---1933122451-1380974158-1351891402=:40332 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable see line [Jon]=0A=0A=0A=0A=0A________________________________=0A From: JP V= asseur (jvasseur) =0A=0AHi Ulrich, =0A=0A=0AOn Nov 2, 2= 012, at 1:22 PM, Ulrich Herberg wrote:=0A=0AJP,=0A>=0A>=0A>On Fri, Nov 2, 2= 012 at 10:09 AM, JP Vasseur (jvasseur) wrote:=0A>=0A>= =0A>>On Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote:=0A>>=0A>>>>>> JP> = This is not just a question of "how large" it is =E2=80=A6 but also how=0A>= >>>>> dynamic. I could show you few hundreds (if not less number of nodes)= =0A>>>>>> not working if the traffic pattern is too dynamic. This is a=0A>>= >>>> fundamental problem.=0A>>>=0A>>> No, it is a fundamental and well-know= n characteristic of reactive=0A>>> routing protocols. =C2=A0It is a problem= only when this behavior doesn't=0A>>> match the characteristics of the net= work in which the reactive routing=0A>>> protocol is deployed.=0A>>=0A>>=0A= JP> Indeed =E2=80=A6 and this is why you have a fundamental issue with you = have extremely high BER, PDR,=0A>>low bandwidth =E2=80=A6 as we do in LLNs.= Flooding in these networks is driven by user traffic and of course=0A>>is = highly undesirable. Slightly increase the use traffic and you will see the = impact on the control plane ...=0A>>=0A>=0A>=0A>=0A>=0A>Yes, but as Timothy= mentioned, there are cases where you don't have much user traffic. =0A=0AJ= P> Then if you recognize that reactive routing is an issue when user traffi= c increases, this is a good start.=0AWhen do you put the limit ?=0ABy the w= ay, the topology is another argument, so does the bandwidth.=0A=0ALet me be= even more specific:=0A* Case 1: 75KBits/s, P2MP traffic (not referring to = multicast), small broadcast domains, meter readout every 24h.=0ACertainly y= ou can deploy a reactive routing protocol ? Still I do not see why you woul= d not use a pro-active routing=C2=A0=0Abut this is another question=0ANow w= hat if you move to case 2:=0A* Unsolicited alarms using meters, DA, EV traf= fic for bill roaming ? Well you do not have=0Aa major problem and when desi= gning protocol we need to take this into account. Please see RFC=0A=0A=0ARF= C 5548=C2=A0=0A(draft-ietf-roll-urban-routing-reqs) Routing Requirements fo= r Urban Low-Power and Lossy Networks 2009-05 RFC 5548 (Informational) Adr= ian Farrel =0ARFC 5673=C2=A0=0A(draft-ietf-roll-indus-routing-reqs) Industr= ial Routing Requirements in Low-Power and Lossy Networks 2009-10 RFC 5673 (= Informational) Adrian Farrel =0ARFC 5826=C2=A0=0A(draft-ietf-roll-home-ro= uting-reqs) Home Automation Routing Requirements in Low-Power and Lossy Net= works 2010-04 RFC 5826 (Informational)=C2=A0=0AErrata Adrian Farrel =0ARF= C 5867=C2=A0=0A(draft-ietf-roll-building-routing-reqs) Building Automation = Routing Requirements in Low-Power and Lossy Networks 2010-06 RFC 5867 (Info= rmational)=0A=0A =0A=0A[Jon] Which RFC?=C2=A0 Do you mean =0ARFC 5826 or 58= 67 both of which seem to need RPL P2P which looks like a =0Anew protocol?= =C2=A0 Do you mean RFC 5548 which seems to be the use case from =0AEDF that= is using a reactive protocol (LOADng), or RFC5673 which no one =0Ahas trie= d.=0A=0AJust because something was designed to do something =0Ayou can't cl= aim that it actually will do it.=C2=A0 The Titanic was designed =0Ato be un= sinkable...=C2=A0 But I digress, since you did.=0A=0AIt does appear that yo= ur objection is the name ('cause it could confuse someone into think they c= ould use this manet protocol in an LLN - which as you said was their choice= ) and that there is one small paragraph there it says that they might be ab= le to use this protocol in their LLN.=0A=0AReally, this is what all the hub= -bub is about.=C2=A0 After all they really are both AODV++.=C2=A0 So we fin= d a new name and remove one paragraph.=0A=0AI think now the debate is what = is the proper base from which to start.=C2=A0 Which document is clearer, an= d more stable.=0A=0AJon ---1933122451-1380974158-1351891402=:40332 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
see line [Jon]


From: JP Vasseur (jvasseur) <jvasseur@= cisco.com>
=0A
Hi Ulrich,=0A

=0A
=0A=
On Nov 2, 2012, at 1:22 PM, Ulrich Herberg wrote:
=0A
=0A
JP,=0A
=0A
On Fri, Nov 2, 2012 at = 10:09 AM, JP Vasseur (jvasseur) =0A<jvasseur@cisco.com> wrote:
=0A=0A

= =0AOn Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote:
=0A
=0A>>= ;>> JP> This is not just a question of "how large" it is =E2=80=A6= but also how
=0A>>>> dynamic. I could show you few hundreds= (if not less number of nodes)
=0A>>>> not working if the tr= affic pattern is too dynamic. This is a
=0A>>>> fundamental = problem.
=0A>
=0A> No, it is a fundamental and well-known chara= cteristic of reactive
=0A> routing protocols.  It is a problem o= nly when this behavior doesn't
=0A> match the characteristics of the = network in which the reactive routing
=0A> protocol is deployed.
= =0A
=0A
=0AJP> Indeed =E2=80=A6 and this is why you have a funda= mental issue with you have extremely high BER, PDR,
=0Alow bandwidth =E2= =80=A6 as we do in LLNs. Flooding in these networks is driven by user traff= ic and of course
=0Ais highly undesirable. Slightly increase the use tra= ffic and you will see the impact on the control plane ...
=0A=0A

=0A
=0A

=0A
=0A
Yes, but as Timothy men= tioned, there are cases where you don't have much user traffic.=0A
=0A=
=0A
=0A

=0A
=0A
JP> Then if you recog= nize that reactive routing is an issue when user traffic increases, this is= a good start.
=0A
When do you put the limit ?
=0A
By the= way, the topology is another argument, so does the bandwidth.
=0A
=0A
=0A
Let me be even more specific:
=0A
* Case 1: = 75KBits/s, P2MP traffic (not referring to multicast), small broadcast domai= ns, meter readout every 24h.
=0A
Certainly you can deploy a reacti= ve routing protocol ? Still I do not see why you would not use a pro-active= routing 
=0A
but this is another question
=0A
Now w= hat if you move to case 2:
=0A
* Unsolicited alarms using meters, = DA, EV traffic for bill roaming ? Well you do not have
=0A
a major= problem and when designing protocol we need to take this into account. Ple= ase see RFC

=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A2010-06=0A=0A=0A= =0A
=0ARFC 5548 
=0A(draft-ietf-roll-urban-routing-reqs)		=0ARouting Requirements for Urban Low-Power = and Lossy Networks= =0A2009-05=0ARFC 5548 (Informational= )=0A=0A=0A= Adrian Farrel
=0ARFC 5673 
=0A(= draft-ietf-roll-indus-routing-reqs)		=0AIndustrial Routing Requirements in Low-Power and Lossy = Networks=0A2009-10=0A=0ARFC 5673 (Informational)=0A=0AAdrian Farre= l
=0ARFC 5826 
=0A(draft-ietf-roll-home-routing-reqs)		=0AHome Automation Routing Requirements in Low-Power and L= ossy Networks=0A2010= -04=0ARFC 5826 (Informational) =
=0AErrata		=0A=0A=0AAdrian Farrel
=0ARFC 5867 
=0A= (draft-ietf-roll-building-routin= g-reqs)		=0ABuilding= Automation Routing Requirements in Low-Power and Lossy Networks=0ARFC 5867 (Informational)
=0A
=0A
=0A
=0A

[Jon] Which RFC?  Do you mean = =0ARFC 5826 or 5867 both of which seem to need RPL P2P which looks like a = =0Anew protocol?  Do you mean RFC 5548 which seems to be the use case = from =0AEDF that is using a reactive protocol (LOADng), or RFC5673 which no= one =0Ahas tried.

Just because something was designed to do somethi= ng =0Ayou can't claim that it actually will do it.  The Titanic was de= signed =0Ato be unsinkable...  But I digress, since you did.

It= does appear that your objection is the name ('cause it could confuse someo= ne into think they could use this manet protocol in an LLN - which as you s= aid was their choice) and that there is one small paragraph there it says t= hat they might be able to use this protocol in their LLN.

Really, th= is is what all the hub-bub is about.  After all they really are both A= ODV++.  So we find a new name and remove one paragraph.

I think= now the debate is what is the proper base from which to start.  Which= document is clearer, and more stable.

Jon
=0A

=0A
<= br>=0A


---1933122451-1380974158-1351891402=:40332-- From jblack.ietf@yahoo.com Fri Nov 2 14:26:04 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B6F11E80E5 for ; Fri, 2 Nov 2012 14:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eV987lI4aFcg for ; Fri, 2 Nov 2012 14:26:03 -0700 (PDT) Received: from nm36-vm7.bullet.mail.bf1.yahoo.com (nm36-vm7.bullet.mail.bf1.yahoo.com [72.30.238.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2307611E80E1 for ; Fri, 2 Nov 2012 14:26:03 -0700 (PDT) Received: from [98.139.212.145] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 21:25:56 -0000 Received: from [98.139.212.243] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 21:25:56 -0000 Received: from [127.0.0.1] by omp1052.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 21:25:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 478190.80360.bm@omp1052.mail.bf1.yahoo.com Received: (qmail 25498 invoked by uid 60001); 2 Nov 2012 21:25:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351891556; bh=UjgTuAMaPbEsZsAVNemUNAP3EWpW/3Z+w9Ipm+2Nnc4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=n9DIw42DBcL4iK5G5A79td7UP7GMJargxkvRU402pkNG4vJORR2b4bWuxdKh+XRB2I/ovgyB3NuWM9A5oa/0GKWAuonYsflEKMOnajdX9TATPGpoOuiHl9ZagUZcE9IZRQAPRG6O/9nPVCK/cR7GOYxPOwKkUEwthNvoVELNh7k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=U+FstbLzNeSXZUR8uAqVrtMgb9+HfMxd8XPZDZnVxxRcQ2a6rP+/cjXP+OqFVrBE3YFyHnii4cECGIOiTcUqDi2BZD7pZUHSXHmHOaakDgJrGHSiF3V+RgpQ0rISnn+xQEbA/ypgbzrG4PgAcXwvOvhcRFW+LN/ufYIXNYFXvtw=; X-YMail-OSG: HzqTqucVM1meBXII3x6ppkNRxFaejg.91ELi4naI4Voouy8 fQvBhQR3_JX6FqkONOfIkgwSgTvoCHJ60LR5hclj8hdONC2z9eiKlbbAAwyV e1HNuw6SvNipBGwq3fU5sCv3gci2rPcW5Buen9H9IYCVLxbh8ebQFCs_iJv5 WUJ1eLecp4P.PawEzGWNZta2kt9JVMEkTjLvGTNSH8qcTIGTGoYDG_jTZBem D3GL1jSXgQuM5Ys35OTMAtrKSBYnOSwzfzWN68t59_izbE2JZRi7ycDMpvIY JN5CJzA96Qor0IC4N8YIqmV0ipexbk.xl2thMfdwToTxDrXXXbRt06BQcGri vfnEvSSFForBL.lXjn54._8pVj.GJHcwASGhRuJVkuc5_MgZN2Cz.VFSd2JH jhSolbN.eOhIkj9WSptUD0eXFtXr_IlFzzrSNbrEc6wUZXA3BIHo39M9mtsM 9hukvNTUbLrx0AOc- Received: from [173.193.202.116] by web160604.mail.bf1.yahoo.com via HTTP; Fri, 02 Nov 2012 14:25:56 PDT X-Rocket-MIMEInfo: 001.001, U3RyYW5nZSB0aGF0IHlvdSB3b3VsZCBsdW1wIFJQTCB3aXRoIE9TUEYgYW5kIEJHUC7CoCBSUEwgaXMgYSBjb2xsZWN0aW9uIHRyZWUuwqAgSXQgaXMgYSB0cmVlLsKgIEl0IGlzIGdyZWF0IGZvciBNUDJQIGFzIGFyZSBhbGwgY29sbGVjdGlvbiB0cmVlcy7CoCBJdCBpcyBsZXNzIGdyZWF0IGZvciBQMk1QIGFuZCByYXRoZXIgcG9vciBmb3IgUDJQLgoKQnV0IHRoaXMgZGViYXRlIHNob3VsZCBnbyB0byBST0xMLCBub3QgaGVyZS4KCkpvbgoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C638@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C877@xmb-rcd-x02.cisco.com> Message-ID: <1351891556.24614.YahooMailNeo@web160604.mail.bf1.yahoo.com> Date: Fri, 2 Nov 2012 14:25:56 -0700 (PDT) From: Jon Black To: "JP Vasseur \(jvasseur\)" , Henning Rogge In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204C877@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-318397788-1847493272-1351891556=:24614" Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 21:26:04 -0000 ---318397788-1847493272-1351891556=:24614 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Strange that you would lump RPL with OSPF and BGP.=C2=A0 RPL is a collectio= n tree.=C2=A0 It is a tree.=C2=A0 It is great for MP2P as are all collectio= n trees.=C2=A0 It is less great for P2MP and rather poor for P2P.=0A=0ABut = this debate should go to ROLL, not here.=0A=0AJon=0A=0A=0A=0A=0A___________= _____________________=0A From: JP Vasseur (jvasseur) = =0ATo: Henning Rogge =0ACc: "manet@ietf.org" =0ASent: Friday, November 2, 2012 11:39 AM=0ASubject: Re: [manet= ] Reactive Protocol Situation=0A =0A=0AOn Nov 2, 2012, at 1:22 PM, Henning = Rogge wrote:=0A=0A> On Fri, Nov 2, 2012 at 6:18 PM, JP Vasseur (jvasseur)= =0A> wrote:=0A>>>> This is where I strongly object, as= several other ones on this mailing list.=0A>>>> One cannot simply forget 4= -5 years of hard work from a WG that focussed=0A>>>> on this use case and c= oncluded that such protocol is not applicable to LLNs.=0A>>> =0A>>> This ar= gument doesn't make any sense at all.=0A>> =0A>> JP> Why ? If MANET standar= dize a protocol with an applicability statement related to the work=0A>> of= another WG, it does make perfect sense, =E2=80=A6 This is precisely why we= have charters.=0A> =0A> And Charters overlap... just look for RFC 5614 as = an example.=0A> =0A> By your own words the effectiveness/overhead of LoadNG= in LLNs=0A> compared to other protocols will most likely depend on the tra= ffic=0A> patterns (which is also true for most other routing protocols,=0A>= especially Ripple).=0A=0AJP> This is technically incorrect - RPL/OSPF/BGP = =E2=80=A6 performances are not directly a function=0Aof the user traffic.= =0A=0A> =0A> Well, if this is true then it will be a GOOD thing to have Loa= dNG=0A> standardized so people can choose the better protocol for their=0A>= use-case.=0A> =0A> Henning Rogge=0A> -- =0A> Steven Hawkings about cosmic = inflation: "An increase of billions of=0A> billions of percent in a tiny fr= action of a second. Of course, that=0A> was before the present government."= =0A=0A_______________________________________________=0Amanet mailing list= =0Amanet@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/manet ---318397788-1847493272-1351891556=:24614 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Strange that you woul= d lump RPL with OSPF and BGP.  RPL is a collection tree.  It is a= tree.  It is great for MP2P as are all collection trees.  It is = less great for P2MP and rather poor for P2P.

But this debate should = go to ROLL, not here.

Jon


From:<= /b> JP Vasseur (jvasseur) <jvasseur@cisco.com>
To: Henning Rogge <hrogge@googlemail.com&= gt;
Cc: "manet@ietf.or= g" <manet@ietf.org>
Sent: Friday, November 2, 2012 11:39 AM
Subject: Re: [manet] Reactive Protocol Situation
<= /font>

=0A
On Nov 2, 2012, at 1:22 PM, Henning Rogge wrote:
> On Fri, Nov 2, 2012 at 6:18 PM, JP Vasseur (jvasseur)
> &l= t;jvasseur@cisco.com> wrote:
>>>> This is where I st= rongly object, as several other ones on this mailing list.
>>>&= gt; One cannot simply forget 4-5 years of hard work from a WG that focussed=
>>>> on this use case and concluded that such protocol is n= ot applicable to LLNs.
>>>
>>> This argument doesn= 't make any sense at all.
>>
>> JP> Why ? If MANET st= andardize a protocol with an applicability statement related to the work>> of another WG, it does make perfect sense, =E2=80=A6 This is prec= isely why we have charters.
>
> And Charters overlap... just l= ook for RFC 5614 as an example.
>
> By your own words the effe= ctiveness/overhead of LoadNG in LLNs
> compared to other protocols will most likely depend= on the traffic
> patterns (which is also true for most other routing= protocols,
> especially Ripple).

JP> This is technically i= ncorrect - RPL/OSPF/BGP =E2=80=A6 performances are not directly a function<= br>of the user traffic.

>
> Well, if this is true then it = will be a GOOD thing to have LoadNG
> standardized so people can choo= se the better protocol for their
> use-case.
>
> Henning= Rogge
> --
> Steven Hawkings about cosmic inflation: "An incr= ease of billions of
> billions of percent in a tiny fraction of a sec= ond. Of course, that
> was before the present government."

___= ____________________________________________
manet mailing list
manet@ietf.o= rg
https://www.ietf.org/mailman/listinfo/manet

<= br>
---318397788-1847493272-1351891556=:24614-- From jblack.ietf@yahoo.com Fri Nov 2 14:29:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365C711E80E8 for ; Fri, 2 Nov 2012 14:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mi1DhhkK0ItR for ; Fri, 2 Nov 2012 14:29:01 -0700 (PDT) Received: from nm11.bullet.mail.bf1.yahoo.com (nm11.bullet.mail.bf1.yahoo.com [98.139.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBE811E80E6 for ; Fri, 2 Nov 2012 14:29:00 -0700 (PDT) Received: from [98.139.212.150] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 21:29:00 -0000 Received: from [98.139.212.235] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 21:29:00 -0000 Received: from [127.0.0.1] by omp1044.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 21:29:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 350489.98924.bm@omp1044.mail.bf1.yahoo.com Received: (qmail 85442 invoked by uid 60001); 2 Nov 2012 21:29:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351891740; bh=uVT0pt7YbrfFPqn7uqWjVMfs6l8vZOr6UrwgUysUy0M=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GlRTSBVetdlrhPWrxVJ/Z+oswnMuCVop58M3lOa4Sp+MP0RUNirHMz0anBkkakeQKWsCfhhZUDRbWWW6pt7dprVkW0ByVEEG37gwoGuwg41tz/xT9tIPojwDeffoWiwC/3wDdCHjDots/mRjdpGc0XEAKxgiIyMPOOG6TX86lb4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=XbE9fh0ir5nQj8IMsLZWfx76p0Qhbr6RCz+dJcCf1jBjHaMJDdiqBrgpLkTezEVnmRQlyAbaEDFoHpHKxBO6SQj8XKJvPM5cq0aX9SCqpZpWzdm7XNy0gd6E3q8YfQbSj+v4vR/UIuF5fFuwn7b61ofrm99cfJ2ZjFxydF9R734=; X-YMail-OSG: EYy2FlIVM1nrmDEluLTNqXSAbXmlc2iqw2mThtbFMq13dSY kAMLufo9TNiCYJiwM5XFB8ycVmquBVF5TYeczrn0L67CvUVnHLIComh4Hod2 EqSoqo8xHA.ck0md8iBTQ..vHUUz1GvnzUdRMD.9qURMzMVCkrG8TMlvGDTy KujHHHlvIcdHJdyVkq02EKJ6B2P62Qm4K0lK17d6lmW6Azusz4wxPEW4z5N0 hid4ZPpAzOuHj8PQx.ayv3FPdnx21XGzYUGAh33fmqFR4J.wTo6w3VAEjhfY ZixWFG8VRdiAuWRCjInjB2tnzghACATeOAOTn2kouk55AEdoFbXi2f9PaBK0 SULLyZVPviTyQhL8mT9iwrq6s.6H3q3vu174F9a_nbNRZ6WXj6xdFbQpIuvh FfVLeslDyUWxYWoZ72_SjOvLF7xDmINEyq3BAY.yoqbRFMaIBiH7rV.sXo__ TdmR9.ALLjYoi00rS Received: from [173.193.202.116] by web160605.mail.bf1.yahoo.com via HTTP; Fri, 02 Nov 2012 14:29:00 PDT X-Rocket-MIMEInfo: 001.001, QWggYnV0IG5vdyB5b3UgbWl4IGFwcGxlcyBhbmQgb3Jhbmdlcy7CoCBTdG9yaW5nIG1vZGUgaXMgbm90IGdvb2QgZm9yIGhpZ2hseSBjb25zdHJhaW5lZCBkZXZpY2VzICh0aGV5IGRvbid0IGhhdmUgdGhlIG1lbW9yeSBmb3Igc3RvcmluZyBtb2RlKSBzbyBmb3IgbWFueSBMTE5zIHlvdSBhcmUgc3R1Y2sgd2l0aCBub24tc3RvcmluZyBtb2RlIHdoaWNoIGlzIHBvb3Igd2l0aCBQMk1QLCBidXQgc3RpbGwgZmluZSB3aXRoIE1QMlAuwqAgQW5kIHRoZXJlZm9yZSBIZW5uaW5nJ3MgcG9pbnQgaXMgdmFsaWQuwqABMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C638@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C877@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204CB91@xmb-rcd-x02.cisco.com> Message-ID: <1351891740.83248.YahooMailNeo@web160605.mail.bf1.yahoo.com> Date: Fri, 2 Nov 2012 14:29:00 -0700 (PDT) From: Jon Black To: "JP Vasseur \(jvasseur\)" , Henning Rogge In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204CB91@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1933122451-1261983182-1351891740=:83248" Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 21:29:02 -0000 ---1933122451-1261983182-1351891740=:83248 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ah but now you mix apples and oranges.=C2=A0 Storing mode is not good for h= ighly constrained devices (they don't have the memory for storing mode) so = for many LLNs you are stuck with non-storing mode which is poor with P2MP, = but still fine with MP2P.=C2=A0 And therefore Henning's point is valid.=C2= =A0 It depends on traffic.=0A=0AJon=0A=0A=0A=0A=0A_________________________= _______=0A From: JP Vasseur (jvasseur) =0ATo: Henning R= ogge =0ACc: "manet@ietf.org" =0ASe= nt: Friday, November 2, 2012 12:10 PM=0ASubject: Re: [manet] Reactive Proto= col Situation=0A =0AAgain your assumption are not correct - look at storing= mode with OF to increase connectivity if required,=0Afor P2P. But again = =E2=80=A6 not appropriate for this list.=0A=0AOn Nov 2, 2012, at 6:58 PM, H= enning Rogge wrote:=0A=0A> On Fri, Nov 2, 2012 at 6:39 PM, JP Vasseur (jvas= seur)=0A> wrote:=0A>>> By your own words the effective= ness/overhead of LoadNG in LLNs=0A>>> compared to other protocols will most= likely depend on the traffic=0A>>> patterns (which is also true for most o= ther routing protocols,=0A>>> especially Ripple).=0A>> =0A>> JP> This is te= chnically incorrect - RPL/OSPF/BGP =E2=80=A6 performances are not directly = a function=0A>> of the user traffic.=0A> =0A> Ripple is a tree-based routin= g protocol.=0A> =0A> its really good when sending traffic towards the local= root, not as=0A> good (but still good) when sending traffic from the root = to its nodes,=0A> bad when you send traffic between two nodes with the same= root and=0A> really bad when sending traffic between nodes that are not pa= rt of the=0A> same root tree.=0A> =0A> I would say its performance depends = on the user traffic pattern.=0A> =0A> The overhead (as a comparison between= control plane traffic and data=0A> plane traffic) is of course always diff= erent for each protocol=0A> depending on the user traffic.=0A> =0A> Henning= Rogge=0A> -- =0A> Steven Hawkings about cosmic inflation: "An increase of = billions of=0A> billions of percent in a tiny fraction of a second. Of cour= se, that=0A> was before the present government."=0A=0A_____________________= __________________________=0Amanet mailing list=0Amanet@ietf.org=0Ahttps://= www.ietf.org/mailman/listinfo/manet ---1933122451-1261983182-1351891740=:83248 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ah but now you mix ap= ples and oranges.  Storing mode is not good for highly constrained dev= ices (they don't have the memory for storing mode) so for many LLNs you are= stuck with non-storing mode which is poor with P2MP, but still fine with M= P2P.  And therefore Henning's point is valid.  It depends on traf= fic.

Jon


From: JP Vasseur (= jvasseur) <jvasseur@cisco.com>
To: Henning Rogge <hrogge@googlemail.com>
Cc: "manet@ietf.org" <manet@iet= f.org>
Sent: Frida= y, November 2, 2012 12:10 PM
Subj= ect: Re: [manet] Reactive Protocol Situation
=
=0AAgain your assumption are not correct - look at storing mode with OF= to increase connectivity if required,
for P2P. But again =E2=80=A6 not = appropriate for this list.

On Nov 2, 2012, at 6:58 PM, Henning Rogge= wrote:

> On Fri, Nov 2, 2012 at 6:39 PM, JP Vasseur (jvasseur)> <jvasseur@cisco.com> wrote:
>>> By your own w= ords the effectiveness/overhead of LoadNG in LLNs
>>> compared = to other protocols will most likely depend on the traffic
>>> p= atterns (which is also true for most other routing protocols,
>>&g= t; especially Ripple).
>>
>> JP> This is technically = incorrect - RPL/OSPF/BGP =E2=80=A6 performances are not directly a function=
>> of the user traffic.
>
> Ripple is a tree-based r= outing protocol.
>
> its really good when sending traffic towa= rds the local root, not as
> good (but still good) when sending traffic from the r= oot to its nodes,
> bad when you send traffic between two nodes with = the same root and
> really bad when sending traffic between nodes tha= t are not part of the
> same root tree.
>
> I would say = its performance depends on the user traffic pattern.
>
> The o= verhead (as a comparison between control plane traffic and data
> pla= ne traffic) is of course always different for each protocol
> dependi= ng on the user traffic.
>
> Henning Rogge
> --
> = Steven Hawkings about cosmic inflation: "An increase of billions of
>= billions of percent in a tiny fraction of a second. Of course, that
>= ; was before the present government."

______________________________= _________________
manet mailing list
manet@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/manet


---1933122451-1261983182-1351891740=:83248-- From c.chauvenet@watteco.com Fri Nov 2 15:41:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7575F11E80F9 for ; Fri, 2 Nov 2012 15:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.865 X-Spam-Level: X-Spam-Status: No, score=-3.865 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DesyYxB2r6BH for ; Fri, 2 Nov 2012 15:41:46 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC4E11E80EE for ; Fri, 2 Nov 2012 15:41:45 -0700 (PDT) Received: from mail9-am1-R.bigfish.com (10.3.201.237) by AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 2 Nov 2012 22:41:44 +0000 Received: from mail9-am1 (localhost [127.0.0.1]) by mail9-am1-R.bigfish.com (Postfix) with ESMTP id C6C1CC0527; Fri, 2 Nov 2012 22:41:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT002.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zz98dI9371Ic89bh1503Mc85eh1432I1418I14ffIzz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dh84d07hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received: from mail9-am1 (localhost.localdomain [127.0.0.1]) by mail9-am1 (MessageSwitch) id 1351896102181938_30219; Fri, 2 Nov 2012 22:41:42 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.246]) by mail9-am1.bigfish.com (Postfix) with ESMTP id 25F5E4800AE; Fri, 2 Nov 2012 22:41:42 +0000 (UTC) Received: from DBXPRD0510HT002.eurprd05.prod.outlook.com (157.56.252.165) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 2 Nov 2012 22:41:40 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT002.eurprd05.prod.outlook.com ([10.255.67.165]) with mapi id 14.16.0233.002; Fri, 2 Nov 2012 22:41:39 +0000 From: C Chauvenet To: Jon Black Thread-Topic: [manet] A proposal - differentiating the document and the protocol Thread-Index: AQHNuT6WIMnDBMUBbUqmStqbwYqiQpfXI+2A Date: Fri, 2 Nov 2012 22:41:38 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D21572F63@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> <1351876587.86080.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204C69E@xmb-rcd-x02.cisco.com> <1351890653.89343.YahooMailNeo@web160603.mail.bf1.yahoo.com> In-Reply-To: <1351890653.89343.YahooMailNeo@web160603.mail.bf1.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.42.4] Content-Type: multipart/alternative; boundary="_000_97B69B30E0EF244B940B65EA541E3F2D21572F63DBXPRD0510MB395_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org List" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 22:41:48 -0000 --_000_97B69B30E0EF244B940B65EA541E3F2D21572F63DBXPRD0510MB395_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, If we add mechanisms to LOADng or prune some from DYMO, we end up with a di= fferent protocol, so I think that we will need to change the name of the re= sulting protocol. I support the AODVv2 naming for the reactive protocol of = MANET, if chairs decide to go forward and do not take option 3). It seems that charlie is working hard on updating the DYMO draft, by addres= sing reviews of the document. These reviews contains most of the improvemen= ts (readability, RFC5444 compliance ....) that people found missing in DYMO= . I think that would make sense to wait for the next update of DYMO before = choosing between LOADng and DYMO. I think that the WG want something good, = rather than something quick. In addition, we would benefit from the work that charlie is currently doing= , rather that skip it if we made a decision based on the actual DYMO versio= n. C=E9dric. Le 2 nov. 2012 =E0 22:10, Jon Black a =E9crit : It is not completely new and it is much more mature. It has been being dev= eloped for quite some time, it has implementations, it has interoperability= . Age of a document is not a good criteria. Something can be written quit= e a long time ago and nothing done on it. Another document/protocol may co= me along, gain critical mass, gain experience and even though younger may b= e a much better starting point. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black >; Ulrich= Herberg >; Abdussalam Bary= un >; "Dearlo= ve, Christopher (UK)" >; "manet@ietf.org List" > Sent: Friday, November 2, 2012 11:21 AM Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol so =85 should we start with a completely new document then ? On Nov 2, 2012, at 1:16 PM, Jon Black wrote: This seems to make good sense. The name should not be issue. We need a go= od solid base to start from. It would appear that if there are working int= eroperable implementation based on the LOADng draft then this indicates tha= t the draft is implementable. Again, having read both I could build someth= ing based on the LOADng draft and I (and I'm only talking for me) couldn't = based on the DYMO draft. I much prefer starting with something simple and understandable and adding = what is missing rather than starting with something more difficult to under= stand trying to remove things that are not needed. Jon ________________________________ From: Ulrich Herberg > To: Abdussalam Baryun > Cc: "Dearlove, Christopher (UK)" >; "manet@ietf.org" > Sent: Friday, November 2, 2012 10:34 AM Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol Hi Abdussalam, there was indeed some hesitance to change the name from some of the authors= (not me). I cannot speak for them here. My intuition is that if the name o= f the protocol is the only factor that avoids the reactive protocol from pr= oceeding in the WG, this can be solved. As far as I can see from the discussions so far, there is a clear consensus= that option 3 is not viable. Now, if we want to proceed with the reactive = document, the question is from which document to start. Chris mentioned tha= t even if we wanted the specification of 100%, it would be far quicker to s= tart from the LOADng draft. I propose that we can start working based on th= e LOADng draft (possibly rename it?), look at each item that is in DYMO and= consider whether and in which way it should be incorporated in the draft. Best Ulrich On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun > wrote: Hi Ulrich, I think that Chris's proposal was not accepted by LOADng co-authors as I un= derstood from following up the WG history (they don't agree to change the n= ame of protocol). As you are one co-author do I understand that you support= the Chris's proposal, AB On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg > wrote: Dear Chris, personally, what you propose makes sense to me. Regards Ulrich On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" > wrote: > Before making a proposal, I'm going to introduce a distinction here betwe= en the DYMO and LOADng documents and protocols. > > I'm of the opinion that the LOADng document is a greatly superior present= ation to the DYMO document. (I'm not really interested in why that has come= about.) > > I think that regardless of whether one makes design decisions favouring D= YMO or LOADng where they differ - and let's not forget they overlap a lot -= it would actually be easier to modify the LOADng document to specify DYMO = than it would be to modify the DYMO document to achieve that. And in practi= ce I think if making decisions it is unlikely that all would favour DYMO ov= er LOADng. > > So what I think would be best for the WG is not a simply "option 1" or ev= en (as it may appear I'm suggesting, but I'm not) "option 2" but rather to= agree to take the LOADng document, and a list of where DYMO and LOADng dif= fer, and thrash out where they do, what the WG reactive protocol should do = - either as a definite choice, or as an option (but not too many options pl= ease- and some could be separate specifications). > > This would not of course be LOADng, so we'd have to change the document n= ame. And there I suggest we have a candidate name - AODVv2. (Which is why I= have recently taken to saying DYMO when referring to that document.) After= all, the one thing we are agreed on is that the protocol being developed i= s derived from AODV. > > The editors of this new document would have to agree that what goes in it= is WG consensus (which should follow proper technical consideration of the= issues). If they found it impossible to have other than their way to do th= ings, they'd have to move on. If that left no one editing it, obviously we = don't have a consensus of people prepared to do the work and option 3 would= win. > > So now I'm partly off the fence I've been sitting on. But only partly. I = haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standar= d, IRREPs as an option in the main draft, IRREPs as a separate draft option= , no IRREPs. I'd like to move on to those discussions. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | htt= p://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > ******************************************************************** > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_97B69B30E0EF244B940B65EA541E3F2D21572F63DBXPRD0510MB395_ Content-Type: text/html; charset="Windows-1252" Content-ID: <85AE2E0EC50F8642880C08B2B5DE2663@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi all, 

If we add mechanisms to LOADng or prune some from DYMO, we end up with= a different protocol, so I think that we will need to change the name of t= he resulting protocol. I support the AODVv2 naming for the reactive protoco= l of MANET, if chairs decide to go forward and do not take option 3).

It seems that charlie is working hard on updating the DYMO draft, by a= ddressing reviews of the document. These reviews contains most of the impro= vements (readability, RFC5444 compliance ....) that people found missing in= DYMO. I think that would make sense to wait for the next update of DYMO before choosing between LOADng and DYM= O. I think that the WG want something good, rather than something quick.&nb= sp;
In addition, we would benefit from the work that charlie is currently = doing, rather that skip it if we made a decision based on the actual DYMO v= ersion.

C=E9dric.

Le 2 nov. 2012 =E0 22:10, Jon Black a =E9crit :

It is not completely new and it is much more mature.  It has been bein= g developed for quite some time, it has implementations, it has interoperab= ility.  Age of a document is not a good criteria.  Something can = be written quite a long time ago and nothing done on it.  Another document/protocol may come along, gain critical mass,= gain experience and even though younger may be a much better starting poin= t.

Jon

From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>; Ulrich Herberg <ulrich@herberg.name>; Abdussalam Baryun <abdussalambaryun@gmail.com>; "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>; "manet@ietf.org List" <manet@ietf.org>
Sent: Friday, November 2, = 2012 11:21 AM
Subject: Re: [manet] A pro= posal - differentiating the document and the protocol

so =85 should we start with a completely new document then ?

On Nov 2, 2012, at 1:16 PM, Jon Black wrote:

This seems to make good sense.  The name should not be issue.  We= need a good solid base to start from.  It would appear that if there = are working interoperable implementation based on the LOADng draft then thi= s indicates that the draft is implementable.  Again, having read both I could build something based on the LOADng draft and I (= and I'm only talking for me) couldn't based on the DYMO draft.

I much prefer starting with something simple and understandable and adding = what is missing rather than starting with something more difficult to under= stand trying to remove things that are not needed.

Jon


From: Ulrich Herberg <ulrich@herberg.name>
To: Abdussalam Baryun <<= a rel=3D"nofollow" ymailto=3D"mailto:abdussalambaryun@gmail.com" target=3D"= _blank" href=3D"mailto:abdussalambaryun@gmail.com">abdussalambaryun@gmail.c= om>
Cc: "Dearlove, Christo= pher (UK)" <Chris.Dearlove@baesystems.com>; "manet@ietf.org" <manet@ietf.org>
Sent: Friday, November 2, 2= 012 10:34 AM
Subject: Re: [manet] A prop= osal - differentiating the document and the protocol

Hi Abdussalam,

there was indeed some hesitance to change the name from some of the au= thors (not me). I cannot speak for them here. My intuition is that if the n= ame of the protocol is the only factor that avoids the reactive protocol fr= om proceeding in the WG, this can be solved.

As far as I can see from the discussions so far, there is a clear cons= ensus that option 3 is not viable. Now, if we want to proceed with the reac= tive document, the question is from which document to start. Chris mentione= d that even if we wanted the specification of 100%, it would be far quicker to start from the LOADng draft. I pr= opose that we can start working based on the LOADng draft (possibly re= name it?), look at each item that is in DYMO and consider whether and in wh= ich way it should be incorporated in the draft. 

Best
Ulrich



On Fri, Nov 2, 2012 at 9:17 AM, Abd= ussalam Baryun <a= bdussalambaryun@gmail.com> wrote:
Hi Ulrich,
 
I think that Chris's proposal was not accepted by LOADng co-autho= rs as I understood from following up the WG history (they don't agree to ch= ange the name of protocol). As you are one co-author do I understand that y= ou support the Chris's proposal,
AB
On Fri, Nov 2, 2012 at 2:41 PM, Ulr= ich Herberg <ulrich@herberg.= name> wrote:
Dear Chris,

personally, what you propose makes sense to me.


Regards
Ulrich

On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesyste= ms.com> wrote:

> Before making a proposal, I'm going to introduce a distinction here be= tween the DYMO and LOADng documents and protocols.
>
> I'm of the opinion that the LOADng document is a greatly superior pres= entation to the DYMO document. (I'm not really interested in why that has c= ome about.)
>
> I think that regardless of whether one makes design decisions favourin= g DYMO or LOADng where they differ - and let's not forget they overlap a lo= t - it would actually be easier to modify the LOADng document to specify DY= MO than it would be to modify the DYMO document to achieve that. And in practice I think if making decisions it i= s unlikely that all would favour DYMO over LOADng.
>
> So what I think would be best for the WG is not a simply "option = 1" or even (as it may appear I'm suggesting, but  I'm not) "= option 2" but rather to agree to take the LOADng document, and a list = of where DYMO and LOADng differ, and thrash out where they do, what the WG reactive protocol should do - either as a definite choice, or = as an option (but not too many options please- and some could be separate s= pecifications).
>
> This would not of course be LOADng, so we'd have to change the documen= t name. And there I suggest we have a candidate name - AODVv2. (Which is wh= y I have recently taken to saying DYMO when referring to that document.) Af= ter all, the one thing we are agreed on is that the protocol being developed is derived from AODV.
>
> The editors of this new document would have to agree that what goes in= it is WG consensus (which should follow proper technical consideration of = the issues). If they found it impossible to have other than their way to do= things, they'd have to move on. If that left no one editing it, obviously we don't have a consensus of people= prepared to do the work and option 3 would win.
>
> So now I'm partly off the fence I've been sitting on. But only partly.= I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as stan= dard, IRREPs as an option in the main draft, IRREPs as a separate draft opt= ion, no IRREPs. I'd like to move on to those discussions.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
>
> ******************************************************************** > 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.
> ******************************************************************** >
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_97B69B30E0EF244B940B65EA541E3F2D21572F63DBXPRD0510MB395_-- From c.chauvenet@watteco.com Fri Nov 2 16:19:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA92E11E80FC for ; Fri, 2 Nov 2012 16:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5edU3MpGYuF for ; Fri, 2 Nov 2012 16:19:25 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 20DBB11E80FA for ; Fri, 2 Nov 2012 16:19:24 -0700 (PDT) Received: from mail69-co9-R.bigfish.com (10.236.132.250) by CO9EHSOBE021.bigfish.com (10.236.130.84) with Microsoft SMTP Server id 14.1.225.23; Fri, 2 Nov 2012 23:19:24 +0000 Received: from mail69-co9 (localhost [127.0.0.1]) by mail69-co9-R.bigfish.com (Postfix) with ESMTP id 77551260149; Fri, 2 Nov 2012 23:19:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zz98dI9371Ic89bhc85eh148cI1432I1453Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received: from mail69-co9 (localhost.localdomain [127.0.0.1]) by mail69-co9 (MessageSwitch) id 1351898360894643_32516; Fri, 2 Nov 2012 23:19:20 +0000 (UTC) Received: from CO9EHSMHS025.bigfish.com (unknown [10.236.132.234]) by mail69-co9.bigfish.com (Postfix) with ESMTP id D7DFE180044; Fri, 2 Nov 2012 23:19:20 +0000 (UTC) Received: from DBXPRD0510HT004.eurprd05.prod.outlook.com (157.56.252.165) by CO9EHSMHS025.bigfish.com (10.236.130.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 2 Nov 2012 23:19:20 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT004.eurprd05.prod.outlook.com ([10.255.67.167]) with mapi id 14.16.0233.002; Fri, 2 Nov 2012 23:19:19 +0000 From: C Chauvenet To: Ulrich Herberg Thread-Topic: [manet] LOADng works Thread-Index: AQHNuEYjLqnfvWsGTUKn5f9jVwDGQ5fVTi6AgACcCgCAAEpAgIAAgxWAgAARjwCAAAO+gIAAY4+A Date: Fri, 2 Nov 2012 23:19:18 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.57.4] Content-Type: multipart/alternative; boundary="_000_97B69B30E0EF244B940B65EA541E3F2D21573150DBXPRD0510MB395_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 23:19:26 -0000 --_000_97B69B30E0EF244B940B65EA541E3F2D21573150DBXPRD0510MB395_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable HI, See inline. Le 2 nov. 2012 =E0 18:22, Ulrich Herberg a =E9crit : JP, On Fri, Nov 2, 2012 at 10:09 AM, JP Vasseur (jvasseur) > wrote: On Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote: >>>> JP> This is not just a question of "how large" it is =85 but also how >>>> dynamic. I could show you few hundreds (if not less number of nodes) >>>> not working if the traffic pattern is too dynamic. This is a >>>> fundamental problem. > > No, it is a fundamental and well-known characteristic of reactive > routing protocols. It is a problem only when this behavior doesn't > match the characteristics of the network in which the reactive routing > protocol is deployed. JP> Indeed =85 and this is why you have a fundamental issue with you have e= xtremely high BER, PDR, low bandwidth =85 as we do in LLNs. Flooding in these networks is driven by= user traffic and of course is highly undesirable. Slightly increase the use traffic and you will see t= he impact on the control plane ... Yes, but as Timothy mentioned, there are cases where you don't have much us= er traffic. This is well known. If you have more user traffic, then you may= need a proactive protocol. You may not like the idea that some people actu= ally deploy reactive protocols in LLNs, but it's a fact. And your argument,= again, makes no sense that you think that DYMO is suitable and LOADng is n= ot. > > We've known for at least 15 years that reactive routing protocols are > more appropriate for light traffic loads and that proactive routing > protocols are more appropriate with heavier traffic loads. JP> This is over-simplying but I see what you mean. > Dozens, > probably hundreds of research papers have reiterated this result. > I don't know of any that have contradicted this result, although > some researchers have tried to develop hybrid routing protocols > (which don't seem to have gained much traction, either in the IETF > or elsewhere). > > Claiming that reactive routing protocols don't scale to heavier traffic > loads is neither a new result nor particularly insightful -- this hasn't > changed for at least 15 years. JP> Let me restate my point. Not sure of what you mean by "heavier" =85 but= if you flood the network with probes each time you need to find a path in a LLN yo= u have a major problem. Well, if you have few communication streams, the few floods are much less h= eavy than having a proactive protocol exchange control traffic all day. Aga= in, no argument in favor for DYMO and against LOADng. Note also that you on= ly talk about LLN, but we are the [manet] WG. Of course, there are many ways to control flooding, use caches .. that are all well-known and by the way hard to tune. But overall, reactive = routing in *these* networks is simply ill suited. > > I haven't seen any evidence that _no_ LLN will experience the sort of > light traffic load that matches the characteristics of a reactive > routing protocol. To the contrary, the deployment experience with > LOADng suggests that such do networks exist. JP> Once again it all depends on the traffic profile. Of course you could m= ake a reactive routing protocol work on a LLN as long as the user traffic has spe= cific characteristics. Exactly! Thanks for pointing that out. That's the whole point why [manet] i= s chartered to do both reactive and proactive protocols. If you carefully analyze the user traffic characteristic in networks such as smart metering (since this was mentioned on this list), and you inc= orporate additional applications such as DA, .. to mention a few, you will see that = in most of these networks this simply does not work =85 too many flooding, ending up n= ot even converging in some cases, especially when the number of hops gets high with= poor link quality. You are not bringing up any new argument that is not known to [manet] for t= he last 15 years. Reactive protocols only work for certain scenarios. We kn= ow that. We have never disputed that. > > At the risk of arguing by analogy, the argument that one can "prove" > that reactive routing protocols don't work (in LLNs or elsewhere) seems > to make about as much as sense as "proving" that OSPF doesn't work > because it doesn't behave well in dynamic environments. The failure of > OSPF in dynamic environments didn't cause us to abandon OSPF: there are > many environments in which it works well. JP> Not sure that I would have used this analogy :-( OSPF was not designed = for highly dynamic environment indeed *but* we could easily enhance it with fast failu= re detection (+ BFD), fast LSA generation, fast SPF and incremental SPF, Local Fast Rero= ute, =85 because routers had lot of resources, links were highly stable, =85 which i= s by far not the case of LLNs. > Rather, we concluded that we > needed another routing protocol. In a similar manner, the MANET > working group, and as far as I have seen pretty much all of the > research community, concluded that there is a need for both a > reactive routing protocol and a proactive routing protocol. > > Of course, the ROLL working group can decide not to standardize > a reactive routing protocol. However, that doesn't prove that > reactive routing protocols don't work (when they match the > traffic characteristics of the network), that reactive routing > protocols won't work better than proactive routing protocols > in some LLNs (based on the characteristics of the traffic load), > or that reactive routing protocols won't be successfully deployed > in LLNs. JP> Well =85 Think about this: when ROLL was formed, the IESG explicitly an= d rightfully asked the WG to first prove that none of the existing protocol could be used, bef= ore standardizing a new protocol (that was the right choice !!). Right, but that "proof" was never published by the IETF, and as such only a= n assertion. Moreover, we are not the ROLL WG. I think http://tools.ietf.org/html/draft-ietf-roll-protocols-survey-07 is s= uch a publication. BTW, it covers AODV and DYMO, and explains why it does not match general LL= N requirements (and so for any AODV-based protocols such as LOADng). But I agree that this is MANET list, so this should not be the place to deb= ate RPL here. I think ROLL-ers came in the discussion because LOADng authors explicitly s= tates that they want to use LOADng in LLNs, that is ROLL working space. Tho= ugh, I think you agree that LOADng will not match general LLN requirements = and be limited to specific low traffic deployment. C=E9dric. Could then prove that the current protocol cannot be used in your environme= nt before suggesting to standardize a new one. Once again, if not applicable to LLNs, I have no problem whatsoever. People have deployed reactive protocols as a matter of fact in LLNs. So, is= the only reason why you like DYMO and not LOADng, because LOADng mentions = the word LLN once in the introduction? Best regards Ulrich > If fact, the LOADng deployment experience strongly > suggests that reactive routing protocols _will_ be deployed in > some LLNs. And, they will be deployed regardless of the ROLL > working group's decision to not standardize a reactive routing > protocol. JP> And this is perfectly fine, people are free to use any protocol they wa= nt, including proprietary ones. This does not mean that the IETF should standardize them. > > Claiming that reactive routing protocols don't work because they > don't scale to higher traffic loads seems, JP> Then we need to characterize precisely the limits. > at best, a poor > characterization of well-known research results, and at worst > a distraction from the question at hand: namely how to proceed > towards an Internet-standard reactive routing protocol. > > -tjs _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_97B69B30E0EF244B940B65EA541E3F2D21573150DBXPRD0510MB395_ Content-Type: text/html; charset="Windows-1252" Content-ID: <33A8E8ED2E50DD46A59F16F9A24E9CED@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable HI, 
See inline.

Le 2 nov. 2012 =E0 18:22, Ulrich Herberg a =E9crit :

JP,

On Fri, Nov 2, 2012 at 10:09 AM, JP Vasseur (jva= sseur) <jvasseur@cisco.= com> wrote:

On Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote:

>>>> JP> This is not just a question of "how large"= ; it is =85 but also how
>>>> dynamic. I could show you few hundreds (if not less number= of nodes)
>>>> not working if the traffic pattern is too dynamic. This is= a
>>>> fundamental problem.
>
> No, it is a fundamental and well-known characteristic of reactive
> routing protocols.  It is a problem only when this behavior doesn= 't
> match the characteristics of the network in which the reactive routing=
> protocol is deployed.

JP> Indeed =85 and this is why you have a fundamental issue with you hav= e extremely high BER, PDR,
low bandwidth =85 as we do in LLNs. Flooding in these networks is driven by= user traffic and of course
is highly undesirable. Slightly increase the use traffic and you will see t= he impact on the control plane ...


Yes, but as Timothy mentioned, there are cases where you don't have mu= ch user traffic. This is well known. If you have more user traffic, then yo= u may need a proactive protocol. You may not like the idea that some people= actually deploy reactive protocols in LLNs, but it's a fact. And your argument, again, makes no sense th= at you think that DYMO is suitable and LOADng is not.

 
>
> We've known for at least 15 years that reactive routing protocols are<= br> > more appropriate for light traffic loads and that proactive routing > protocols are more appropriate with heavier traffic loads.

JP> This is over-simplying but I see what you mean.

> Dozens,
> probably hundreds of research papers have reiterated this result.
> I don't know of any that have contradicted this result, although
> some researchers have tried to develop hybrid routing protocols
> (which don't seem to have gained much traction, either in the IETF
> or elsewhere).
>
> Claiming that reactive routing protocols don't scale to heavier traffi= c
> loads is neither a new result nor particularly insightful -- this hasn= 't
> changed for at least 15 years.

JP> Let me restate my point. Not sure of what you mean by "heavier&= quot; =85 but if you
flood the network with probes each time you need to find a path in a LLN yo= u have
a major problem.

Well, if you have few communication streams, the few floods are much l= ess heavy than having a proactive protocol exchange control traffic all day= . Again, no argument in favor for DYMO and against LOADng. Note also that y= ou only talk about LLN, but we are the [manet] WG.

 
Of course, there are many ways to control flooding, use caches ..
that are all well-known and by the way hard to tune. But overall, reactive = routing in
*these* networks is simply ill suited.

>
> I haven't seen any evidence that _no_ LLN will experience the sort of<= br> > light traffic load that matches the characteristics of a reactive
> routing protocol.  To the contrary, the deployment experience wit= h
> LOADng suggests that such do networks exist.

JP> Once again it all depends on the traffic profile. Of course you coul= d make a
reactive routing protocol work on a LLN as long as the user traffic has spe= cific
characteristics.


Exactly! Thanks for pointing that out. That's the whole point why [man= et] is chartered to do both reactive and proactive protocols.

 
If you carefully analyze the user traffic characteristic in networks
such as smart metering (since this was mentioned on this list), and you inc= orporate
additional applications such as DA, .. to mention a few, you will see that = in most of
these networks this simply does not work =85 too many flooding, ending up n= ot even
converging in some cases, especially when the number of hops gets high with= poor
link quality.

You are not bringing up any new argument that is not known to [manet] = for the last 15 years. Reactive protocols only work for certain scenarios. = We know that. We have never disputed that.

 

>
> At the risk of arguing by analogy, the argument that one can "pro= ve"
> that reactive routing protocols don't work (in LLNs or elsewhere) seem= s
> to  make about as much as sense as "proving" that OSPF = doesn't work
> because it doesn't behave well in dynamic environments.  The fail= ure of
> OSPF in dynamic environments didn't cause us to abandon OSPF: there ar= e
> many environments in which it works well.

JP> Not sure that I would have used this analogy :-( OSPF was not design= ed for highly
dynamic environment indeed *but* we could easily enhance it with fast failu= re detection
(+ BFD), fast LSA generation, fast SPF and incremental SPF, Local Fast = Reroute, =85
because routers had lot of resources, links were highly stable, =85 which i= s by far not the
case of LLNs.

> Rather, we concluded that we
> needed another routing protocol.  In a similar manner, the MANET<= br> > working group, and as far as I have seen pretty much all of the
> research community, concluded that there is a need for both a
> reactive routing protocol and a proactive routing protocol.
>
> Of course, the ROLL working group can decide not to standardize
> a reactive routing protocol.  However, that doesn't prove that > reactive routing protocols don't work (when they match the
> traffic characteristics of the network), that reactive routing
> protocols won't work better than proactive routing protocols
> in some LLNs (based on the characteristics of the traffic load),
> or that reactive routing protocols won't be successfully deployed
> in LLNs.

JP> Well =85 Think about this: when ROLL was formed, the IESG explicitly= and rightfully asked
the WG to first prove that none of the existing protocol could be used, bef= ore standardizing a
new protocol (that was the right choice !!).


Right, but that "proof" was never published by the IETF, and= as such only an assertion. Moreover, we are not the ROLL WG.

BTW, it covers AODV and DYMO, and explains why it does not match gener= al LLN requirements (and so for any AODV-based protocols such as LOADng).

But I agree that this is MANET list, so this should not be the place t= o debate RPL here.
I think ROLL-ers came in the discussion because LOADng authors explici= tly states that they want to use LOADng in LLNs, that is ROLL working space= . Though, I think you agree that LOADng will not match general LLN requirem= ents and be limited to specific low traffic deployment.

C=E9dric.

 

Could then prove that the current protocol cannot be used in your environme= nt before suggesting
to standardize a new one.

Once again, if not applicable to LLNs, I have no problem whatsoever.
 

People have deployed reactive protocols as a matter of fact in LLNs. S= o, is the only reason why you like DYMO and not LOADng, because LOADng ment= ions the word LLN once in the introduction?

Best regards
Ulrich

 

> If fact, the LOADng deployment experience strongly
> suggests that reactive routing protocols _will_ be deployed in
> some LLNs.  And, they will be deployed regardless of the ROLL
> working group's decision to not standardize a reactive routing
> protocol.

JP> And this is perfectly fine, people are free to use any protocol they= want, including proprietary
ones. This does not mean that the IETF should standardize them.

>
> Claiming that reactive routing protocols don't work because they
> don't scale to higher traffic loads seems,

JP> Then we need to characterize precisely the limits.

> at best, a poor
> characterization of well-known research results, and at worst
> a distraction from the question at hand: namely how to proceed
> towards an Internet-standard reactive routing protocol.
>
> -tjs

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_97B69B30E0EF244B940B65EA541E3F2D21573150DBXPRD0510MB395_-- From yi.jiazi@gmail.com Fri Nov 2 16:27:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE4511E8102 for ; Fri, 2 Nov 2012 16:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqoWToA-e14E for ; Fri, 2 Nov 2012 16:27:38 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5E05011E80FC for ; Fri, 2 Nov 2012 16:27:33 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so1411526wib.13 for ; Fri, 02 Nov 2012 16:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=WS6ZcsjfLRiUAU3rPb0Sw8jkLpyMbYgUQ6wN7VTxJko=; b=AQw49DdgyPgQtEyQgYfRGA0VlxjjmfkdN7QlhlGMDFYz1CtS2I3iLwnqEXq7757OU0 DtTKC/6vlWGz7WRv7WLXbhurxQ0Vc4LnwqZUIcyV/1QH0VJQIAZ72pvblevTV800heX3 S9uHy0viNrxHdZUEiKEJoszjLVkT8sSqR+03NoUNBeaURWgnlF1sNuAG1Y7OazDD/h+h xLgX+5gCRdUDfbpwmRtkwz6fCm5so3Pq1Q5l0TuOXQUeFx7uYrzcztGxMPN3TlDgXkC/ T1B1m0MMDFunzGy6nDCUQdeckjKfNPJD5kVKCPJdMxd5YQcoeRcSESMG7W/sbIYjbfYG Jh8w== Received: by 10.180.77.231 with SMTP id v7mr4564532wiw.9.1351898852546; Fri, 02 Nov 2012 16:27:32 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id dm2sm362467wib.4.2012.11.02.16.27.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 16:27:31 -0700 (PDT) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_275365DA-0E65-47DD-AB52-6539676BBA4D" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi YI In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> Date: Sat, 3 Nov 2012 00:27:26 +0100 Message-Id: References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> To: C Chauvenet X-Mailer: Apple Mail (2.1499) Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 23:27:40 -0000 --Apple-Mail=_275365DA-0E65-47DD-AB52-6539676BBA4D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi,=20 I don't think citing a draft that has been expired for 3 years actually = says anything.=20 best Jiazi On Nov 3, 2012, at 12:19 AM, C Chauvenet = wrote: > HI,=20 > See inline. >=20 > Le 2 nov. 2012 =E0 18:22, Ulrich Herberg a =E9crit : >=20 >> JP, >>=20 >> On Fri, Nov 2, 2012 at 10:09 AM, JP Vasseur (jvasseur) = wrote: >>=20 >> On Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote: >>=20 >> >>>> JP> This is not just a question of "how large" it is =85 but = also how >> >>>> dynamic. I could show you few hundreds (if not less number of = nodes) >> >>>> not working if the traffic pattern is too dynamic. This is a >> >>>> fundamental problem. >> > >> > No, it is a fundamental and well-known characteristic of reactive >> > routing protocols. It is a problem only when this behavior doesn't >> > match the characteristics of the network in which the reactive = routing >> > protocol is deployed. >>=20 >> JP> Indeed =85 and this is why you have a fundamental issue with you = have extremely high BER, PDR, >> low bandwidth =85 as we do in LLNs. Flooding in these networks is = driven by user traffic and of course >> is highly undesirable. Slightly increase the use traffic and you will = see the impact on the control plane ... >>=20 >>=20 >> Yes, but as Timothy mentioned, there are cases where you don't have = much user traffic. This is well known. If you have more user traffic, = then you may need a proactive protocol. You may not like the idea that = some people actually deploy reactive protocols in LLNs, but it's a fact. = And your argument, again, makes no sense that you think that DYMO is = suitable and LOADng is not. >>=20 >> =20 >> > >> > We've known for at least 15 years that reactive routing protocols = are >> > more appropriate for light traffic loads and that proactive routing >> > protocols are more appropriate with heavier traffic loads. >>=20 >> JP> This is over-simplying but I see what you mean. >>=20 >> > Dozens, >> > probably hundreds of research papers have reiterated this result. >> > I don't know of any that have contradicted this result, although >> > some researchers have tried to develop hybrid routing protocols >> > (which don't seem to have gained much traction, either in the IETF >> > or elsewhere). >> > >> > Claiming that reactive routing protocols don't scale to heavier = traffic >> > loads is neither a new result nor particularly insightful -- this = hasn't >> > changed for at least 15 years. >>=20 >> JP> Let me restate my point. Not sure of what you mean by "heavier" =85= but if you >> flood the network with probes each time you need to find a path in a = LLN you have >> a major problem. >>=20 >> Well, if you have few communication streams, the few floods are much = less heavy than having a proactive protocol exchange control traffic all = day. Again, no argument in favor for DYMO and against LOADng. Note also = that you only talk about LLN, but we are the [manet] WG. >>=20 >> =20 >> Of course, there are many ways to control flooding, use caches .. >> that are all well-known and by the way hard to tune. But overall, = reactive routing in >> *these* networks is simply ill suited. >>=20 >> > >> > I haven't seen any evidence that _no_ LLN will experience the sort = of >> > light traffic load that matches the characteristics of a reactive >> > routing protocol. To the contrary, the deployment experience with >> > LOADng suggests that such do networks exist. >>=20 >> JP> Once again it all depends on the traffic profile. Of course you = could make a >> reactive routing protocol work on a LLN as long as the user traffic = has specific >> characteristics. >>=20 >>=20 >> Exactly! Thanks for pointing that out. That's the whole point why = [manet] is chartered to do both reactive and proactive protocols. >>=20 >> =20 >> If you carefully analyze the user traffic characteristic in networks >> such as smart metering (since this was mentioned on this list), and = you incorporate >> additional applications such as DA, .. to mention a few, you will see = that in most of >> these networks this simply does not work =85 too many flooding, = ending up not even >> converging in some cases, especially when the number of hops gets = high with poor >> link quality. >>=20 >> You are not bringing up any new argument that is not known to [manet] = for the last 15 years. Reactive protocols only work for certain = scenarios. We know that. We have never disputed that. >>=20 >> =20 >>=20 >> > >> > At the risk of arguing by analogy, the argument that one can = "prove" >> > that reactive routing protocols don't work (in LLNs or elsewhere) = seems >> > to make about as much as sense as "proving" that OSPF doesn't work >> > because it doesn't behave well in dynamic environments. The = failure of >> > OSPF in dynamic environments didn't cause us to abandon OSPF: there = are >> > many environments in which it works well. >>=20 >> JP> Not sure that I would have used this analogy :-( OSPF was not = designed for highly >> dynamic environment indeed *but* we could easily enhance it with fast = failure detection >> (+ BFD), fast LSA generation, fast SPF and incremental SPF, Local = Fast Reroute, =85 >> because routers had lot of resources, links were highly stable, =85 = which is by far not the >> case of LLNs. >>=20 >> > Rather, we concluded that we >> > needed another routing protocol. In a similar manner, the MANET >> > working group, and as far as I have seen pretty much all of the >> > research community, concluded that there is a need for both a >> > reactive routing protocol and a proactive routing protocol. >> > >> > Of course, the ROLL working group can decide not to standardize >> > a reactive routing protocol. However, that doesn't prove that >> > reactive routing protocols don't work (when they match the >> > traffic characteristics of the network), that reactive routing >> > protocols won't work better than proactive routing protocols >> > in some LLNs (based on the characteristics of the traffic load), >> > or that reactive routing protocols won't be successfully deployed >> > in LLNs. >>=20 >> JP> Well =85 Think about this: when ROLL was formed, the IESG = explicitly and rightfully asked >> the WG to first prove that none of the existing protocol could be = used, before standardizing a >> new protocol (that was the right choice !!). >>=20 >>=20 >> Right, but that "proof" was never published by the IETF, and as such = only an assertion. Moreover, we are not the ROLL WG. >=20 > I think http://tools.ietf.org/html/draft-ietf-roll-protocols-survey-07 = is such a publication. > BTW, it covers AODV and DYMO, and explains why it does not match = general LLN requirements (and so for any AODV-based protocols such as = LOADng). >=20 > But I agree that this is MANET list, so this should not be the place = to debate RPL here. > I think ROLL-ers came in the discussion because LOADng authors = explicitly states that they want to use LOADng in LLNs, that is ROLL = working space. Though, I think you agree that LOADng will not match = general LLN requirements and be limited to specific low traffic = deployment. >=20 > C=E9dric. >=20 >> =20 >>=20 >> Could then prove that the current protocol cannot be used in your = environment before suggesting >> to standardize a new one. >>=20 >> Once again, if not applicable to LLNs, I have no problem whatsoever. >> =20 >>=20 >> People have deployed reactive protocols as a matter of fact in LLNs. = So, is the only reason why you like DYMO and not LOADng, because LOADng = mentions the word LLN once in the introduction? >>=20 >> Best regards >> Ulrich >>=20 >> =20 >>=20 >> > If fact, the LOADng deployment experience strongly >> > suggests that reactive routing protocols _will_ be deployed in >> > some LLNs. And, they will be deployed regardless of the ROLL >> > working group's decision to not standardize a reactive routing >> > protocol. >>=20 >> JP> And this is perfectly fine, people are free to use any protocol = they want, including proprietary >> ones. This does not mean that the IETF should standardize them. >>=20 >> > >> > Claiming that reactive routing protocols don't work because they >> > don't scale to higher traffic loads seems, >>=20 >> JP> Then we need to characterize precisely the limits. >>=20 >> > at best, a poor >> > characterization of well-known research results, and at worst >> > a distraction from the question at hand: namely how to proceed >> > towards an Internet-standard reactive routing protocol. >> > >> > -tjs >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_275365DA-0E65-47DD-AB52-6539676BBA4D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I don't think = citing a draft that has been expired for 3 years actually says = anything. 
Jiazi


On Nov 3, 2012, at 12:19 AM, C Chauvenet <c.chauvenet@watteco.com> = wrote:

HI, 
See inline.

Le 2 nov. 2012 =E0 18:22, Ulrich Herberg a =E9crit :

JP,

On Fri, Nov 2, 2012 at 10:09 AM, JP Vasseur = (jvasseur) <jvasseur@cisco.com> wrote:

On Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote:

>>>> JP> This is not just a question of "how large" it is = =85 but also how
>>>> dynamic. I could show you few hundreds (if not less = number of nodes)
>>>> not working if the traffic pattern is too dynamic. This = is a
>>>> fundamental problem.
>
> No, it is a fundamental and well-known characteristic of = reactive
> routing protocols.  It is a problem only when this behavior = doesn't
> match the characteristics of the network in which the reactive = routing
> protocol is deployed.

JP> Indeed =85 and this is why you have a fundamental issue with you = have extremely high BER, PDR,
low bandwidth =85 as we do in LLNs. Flooding in these networks is driven = by user traffic and of course
is highly undesirable. Slightly increase the use traffic and you will = see the impact on the control plane ...


Yes, but as Timothy mentioned, there are cases where you don't have = much user traffic. This is well known. If you have more user traffic, = then you may need a proactive protocol. You may not like the idea that = some people actually deploy reactive protocols in LLNs, but it's a fact. And your argument, again, makes no sense = that you think that DYMO is suitable and LOADng is not.

 
>
> We've known for at least 15 years that reactive routing protocols = are
> more appropriate for light traffic loads and that proactive = routing
> protocols are more appropriate with heavier traffic loads.

JP> This is over-simplying but I see what you mean.

> Dozens,
> probably hundreds of research papers have reiterated this = result.
> I don't know of any that have contradicted this result, = although
> some researchers have tried to develop hybrid routing protocols
> (which don't seem to have gained much traction, either in the = IETF
> or elsewhere).
>
> Claiming that reactive routing protocols don't scale to heavier = traffic
> loads is neither a new result nor particularly insightful -- this = hasn't
> changed for at least 15 years.

JP> Let me restate my point. Not sure of what you mean by "heavier" =85= but if you
flood the network with probes each time you need to find a path in a LLN = you have
a major problem.

Well, if you have few communication streams, the few floods are = much less heavy than having a proactive protocol exchange control = traffic all day. Again, no argument in favor for DYMO and against = LOADng. Note also that you only talk about LLN, but we are the [manet] WG.

 
Of course, there are many ways to control flooding, use caches ..
that are all well-known and by the way hard to tune. But overall, = reactive routing in
*these* networks is simply ill suited.

>
> I haven't seen any evidence that _no_ LLN will experience the sort = of
> light traffic load that matches the characteristics of a = reactive
> routing protocol.  To the contrary, the deployment experience = with
> LOADng suggests that such do networks exist.

JP> Once again it all depends on the traffic profile. Of course you = could make a
reactive routing protocol work on a LLN as long as the user traffic has = specific
characteristics.


Exactly! Thanks for pointing that out. That's the whole point why = [manet] is chartered to do both reactive and proactive protocols.

 
If you carefully analyze the user traffic characteristic in networks
such as smart metering (since this was mentioned on this list), and you = incorporate
additional applications such as DA, .. to mention a few, you will see = that in most of
these networks this simply does not work =85 too many flooding, ending = up not even
converging in some cases, especially when the number of hops gets high = with poor
link quality.

You are not bringing up any new argument that is not known to = [manet] for the last 15 years. Reactive protocols only work for certain = scenarios. We know that. We have never disputed that.

 

>
> At the risk of arguing by analogy, the argument that one can = "prove"
> that reactive routing protocols don't work (in LLNs or elsewhere) = seems
> to  make about as much as sense as "proving" that OSPF doesn't = work
> because it doesn't behave well in dynamic environments.  The = failure of
> OSPF in dynamic environments didn't cause us to abandon OSPF: there = are
> many environments in which it works well.

JP> Not sure that I would have used this analogy :-( OSPF was not = designed for highly
dynamic environment indeed *but* we could easily enhance it with fast = failure detection
(+ BFD), fast LSA generation, fast SPF and incremental SPF, Local Fast = Reroute, =85
because routers had lot of resources, links were highly stable, =85 = which is by far not the
case of LLNs.

> Rather, we concluded that we
> needed another routing protocol.  In a similar manner, the = MANET
> working group, and as far as I have seen pretty much all of the
> research community, concluded that there is a need for both a
> reactive routing protocol and a proactive routing protocol.
>
> Of course, the ROLL working group can decide not to standardize
> a reactive routing protocol.  However, that doesn't prove = that
> reactive routing protocols don't work (when they match the
> traffic characteristics of the network), that reactive routing
> protocols won't work better than proactive routing protocols
> in some LLNs (based on the characteristics of the traffic = load),
> or that reactive routing protocols won't be successfully = deployed
> in LLNs.

JP> Well =85 Think about this: when ROLL was formed, the IESG = explicitly and rightfully asked
the WG to first prove that none of the existing protocol could be used, = before standardizing a
new protocol (that was the right choice !!).


Right, but that "proof" was never published by the IETF, and as = such only an assertion. Moreover, we are not the ROLL WG.

BTW, it covers AODV and DYMO, and explains why it does not match = general LLN requirements (and so for any AODV-based protocols such as = LOADng).

But I agree that this is MANET list, so this should not be the = place to debate RPL here.
I think ROLL-ers came in the discussion because LOADng authors = explicitly states that they want to use LOADng in LLNs, that is ROLL = working space. Though, I think you agree that LOADng will not match = general LLN requirements and be limited to specific low traffic deployment.

C=E9dric.

 

Could then prove that the current protocol cannot be used in your = environment before suggesting
to standardize a new one.

Once again, if not applicable to LLNs, I have no problem whatsoever.
 

People have deployed reactive protocols as a matter of fact in = LLNs. So, is the only reason why you like DYMO and not LOADng, because = LOADng mentions the word LLN once in the introduction?

Best regards
Ulrich

 

> If fact, the LOADng deployment experience strongly
> suggests that reactive routing protocols _will_ be deployed in
> some LLNs.  And, they will be deployed regardless of the = ROLL
> working group's decision to not standardize a reactive routing
> protocol.

JP> And this is perfectly fine, people are free to use any protocol = they want, including proprietary
ones. This does not mean that the IETF should standardize them.

>
> Claiming that reactive routing protocols don't work because = they
> don't scale to higher traffic loads seems,

JP> Then we need to characterize precisely the limits.

> at best, a poor
> characterization of well-known research results, and at worst
> a distraction from the question at hand: namely how to proceed
> towards an Internet-standard reactive routing protocol.
>
> -tjs

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

_______________________________________________
manet mailing = list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= --Apple-Mail=_275365DA-0E65-47DD-AB52-6539676BBA4D-- From ulrich@herberg.name Fri Nov 2 16:29:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4253E11E80FE for ; Fri, 2 Nov 2012 16:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuXxNbyNE7a8 for ; Fri, 2 Nov 2012 16:29:52 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B83411E80E9 for ; Fri, 2 Nov 2012 16:29:51 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4739945vcb.31 for ; Fri, 02 Nov 2012 16:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NQkXkf5G67PYbzAQKsQOx82RZSg5tZsKuJQYlAjOJ0M=; b=mRUqqadY3DleXByzpCidYJ+mHov1NZZhIyBK7upMHZx4y2EU679+cgo8xVT63WIpLl HfCH5tuHgsH1T0pRQux04sJ935MiyWwDva3n8z1UceQN9np7pbVn9Z8k3D49gu0Oq1ac k6P4zhKVwWV+VWNgtDPGTftHIHGMh4Jj9wO7g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=NQkXkf5G67PYbzAQKsQOx82RZSg5tZsKuJQYlAjOJ0M=; b=lWwkmLgZjnvJm7M+XlYQMm94c5jzDW4hCRNzLerI+HUGlzfoYrsA9Y6o6n1hcHPiiW 4tv4+3V9VcYt9WfZBXF95tsN5NnmaOIWE4yl4tLHhrU05mSYiHKmJij0ISxlVR0e7kk1 lRBE6qUu9BM6LZRJLauJ7BSTrmTwM1CaRdvdho7wLU1y/4L/55EAq8BqxkC7FA+7rx57 efgq1a5ffiAxi6xmr2sTtuZwAhqN8qJ1AMr+ITq9lPoOHkKo/oJL5ZRo9tjXB08zTPms k0gW20kbQd6bLayvNvWAXD2blnmmDEFxWX4yqCtQRn9dN4qYUDGaSej6AMpGOSkS567U YZqA== MIME-Version: 1.0 Received: by 10.52.67.44 with SMTP id k12mr2923379vdt.15.1351898991001; Fri, 02 Nov 2012 16:29:51 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Fri, 2 Nov 2012 16:29:50 -0700 (PDT) In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> Date: Fri, 2 Nov 2012 16:29:50 -0700 Message-ID: From: Ulrich Herberg To: C Chauvenet Content-Type: multipart/alternative; boundary=20cf307abeb521825904cd8b839a X-Gm-Message-State: ALoCoQnF56ZD2B0S46zZYhw26IlHhTd35ft26QSXlR36bKqdxAoXxTo7+AKnzuMHxraQshW1khI+ Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 23:29:53 -0000 --20cf307abeb521825904cd8b839a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable C=E9dric, On Fri, Nov 2, 2012 at 4:19 PM, C Chauvenet wrote= : > [...] > > Right, but that "proof" was never published by the IETF, and as such > only an assertion. Moreover, we are not the ROLL WG. > > > I think http://tools.ietf.org/html/draft-ietf-roll-protocols-survey-07 i= s > such a publication. > That is the draft I was talking about. It is *not* a publication. It was never published by the IETF, even though some claim it is a publication. BTW, it covers AODV and DYMO, and explains why it does not match general > LLN requirements (and so for any AODV-based protocols such as LOADng). > The document was rejected for a reason. It is heavily flawed and misleading, in my opinion. > But I agree that this is MANET list, so this should not be the place to > debate RPL here. > Right. > I think ROLL-ers came in the discussion because LOADng authors explicitly > states that they want to use LOADng in LLNs, that is ROLL working space. > And if that one word in the introduction is the whole reason why you prefer DYMO over LOADng, it is a pretty weak argument. And again, you cannot dispute the fact that LOADng is used in such deployments. You may not like it, for business or other reasons, but it's a fact. > Though, I think you agree that LOADng will not match general LLN > requirements and be limited to specific low traffic deployment. > I agree that LOADng (or DYMO for that matter) will not be suitable for all LLN deployments. But it is, as a matter of fact, used in some such deployments. RPL also does not fulfill all requirements of all kinds of LLNs, in my opinion, but that's another matter not to be discussed here. Best Ulrich > > C=E9dric. > > > >> >> Could then prove that the current protocol cannot be used in your >> environment before suggesting >> to standardize a new one. >> >> Once again, if not applicable to LLNs, I have no problem whatsoever. >> > > > People have deployed reactive protocols as a matter of fact in LLNs. So, > is the only reason why you like DYMO and not LOADng, because LOADng > mentions the word LLN once in the introduction? > > Best regards > Ulrich > > > >> >> > If fact, the LOADng deployment experience strongly >> > suggests that reactive routing protocols _will_ be deployed in >> > some LLNs. And, they will be deployed regardless of the ROLL >> > working group's decision to not standardize a reactive routing >> > protocol. >> >> JP> And this is perfectly fine, people are free to use any protocol the= y >> want, including proprietary >> ones. This does not mean that the IETF should standardize them. >> >> > >> > Claiming that reactive routing protocols don't work because they >> > don't scale to higher traffic loads seems, >> >> JP> Then we need to characterize precisely the limits. >> >> > at best, a poor >> > characterization of well-known research results, and at worst >> > a distraction from the question at hand: namely how to proceed >> > towards an Internet-standard reactive routing protocol. >> > >> > -tjs >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > --20cf307abeb521825904cd8b839a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable C=E9dric,

On Fri, Nov 2, 2012 at 4:19 PM,= C Chauvenet <c.chauvenet@watteco.com> wrote:
<= blockquote type=3D"cite">
[...]

Right, but that "proof" was never published by the IETF, and= as such only an assertion. Moreover, we are not the ROLL WG.


That is the draft I was talkin= g about. It is *not* a publication. It was never published by the IETF, eve= n though some claim it is a publication.
=A0

BTW, it covers AODV and DYMO, and explains why it does not match gener= al LLN requirements (and so for any AODV-based protocols such as LOADng).


The document was rejected for a reason. It is heavily flawed and misle= ading, in my opinion.
=A0


But I agree that this is MANET list, so this should not be the place t= o debate RPL here.

Right.

=A0
I think ROLL-ers came in the discussion because LOADng authors explici= tly states that they want to use LOADng in LLNs, that is ROLL working space= .

And if tha= t one word in the introduction is the whole reason why you prefer DYMO over= LOADng, it is a pretty weak argument.=A0
And again, you cannot dispute the fact that LOADng is used in such dep= loyments. You may not like it, for business or other reasons, but it's = a fact.

=A0
Though, I think you= agree that LOADng will not match general LLN requirements and be limited t= o specific low traffic deployment.
=A0=

I agree that LOADng (or DYMO for that matter) wil= l not be suitable for all LLN deployments. But it is, as a matter of fact, = used in some such deployments. RPL also does not fulfill all requirements o= f all kinds of LLNs, in my opinion, but that's another matter not to be= discussed here.

Best
Ulrich


=A0

C=E9dric.

=A0

Could then prove that the current protocol cannot be used in your environme= nt before suggesting
to standardize a new one.

Once again, if not applicable to LLNs, I have no problem whatsoever.
=A0

People have deployed reactive protocols as a matter of fact in LLNs. S= o, is the only reason why you like DYMO and not LOADng, because LOADng ment= ions the word LLN once in the introduction?

Best regards
Ulrich

=A0

> If fact, the LOADng deployment experience strongly
> suggests that reactive routing protocols _will_ be deployed in
> some LLNs. =A0And, they will be deployed regardless of the ROLL
> working group's decision to not standardize a reactive routing
> protocol.

JP> And this is perfectly fine, people are free to use any protocol they= want, including proprietary
ones. This does not mean that the IETF should standardize them.

>
> Claiming that reactive routing protocols don't work because they > don't scale to higher traffic loads seems,

JP> Then we need to characterize precisely the limits.

> at best, a poor
> characterization of well-known research results, and at worst
> a distraction from the question at hand: namely how to proceed
> towards an Internet-standard reactive routing protocol.
>
> -tjs

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--20cf307abeb521825904cd8b839a-- From c.chauvenet@watteco.com Fri Nov 2 16:31:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741A211E8109 for ; Fri, 2 Nov 2012 16:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDdGJlZ5PZoP for ; Fri, 2 Nov 2012 16:31:34 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6A72E11E8102 for ; Fri, 2 Nov 2012 16:31:32 -0700 (PDT) Received: from mail177-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Fri, 2 Nov 2012 23:31:31 +0000 Received: from mail177-ch1 (localhost [127.0.0.1]) by mail177-ch1-R.bigfish.com (Postfix) with ESMTP id 45A882601B2; Fri, 2 Nov 2012 23:31:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT003.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zz98dI9371Ic89bh1503Mc85eh1432I1418I14ffIzz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dh84d07hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received: from mail177-ch1 (localhost.localdomain [127.0.0.1]) by mail177-ch1 (MessageSwitch) id 1351899087858078_29357; Fri, 2 Nov 2012 23:31:27 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236]) by mail177-ch1.bigfish.com (Postfix) with ESMTP id C57071E00A4; Fri, 2 Nov 2012 23:31:27 +0000 (UTC) Received: from DBXPRD0510HT003.eurprd05.prod.outlook.com (157.56.252.165) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 2 Nov 2012 23:31:27 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT003.eurprd05.prod.outlook.com ([10.255.67.166]) with mapi id 14.16.0233.002; Fri, 2 Nov 2012 23:31:25 +0000 From: C Chauvenet To: Ulrich Herberg , Jiazi YI , =?Windows-1252?Q?Axel_Colin_de_Verdi=E8re?= Thread-Topic: [manet] A proposal - differentiating the document and the protocol Thread-Index: AQHNuVIschpyVsufZ06r0nmSRqEp9A== Date: Fri, 2 Nov 2012 23:31:25 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D215731FF@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> <1351876587.86080.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204C69E@xmb-rcd-x02.cisco.com> <1351890653.89343.YahooMailNeo@web160603.mail.bf1.yahoo.com> <97B69B30E0EF244B940B65EA541E3F2D21572F63@DBXPRD0510MB395.eurprd05.prod.outlook.com> In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D21572F63@DBXPRD0510MB395.eurprd05.prod.outlook.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.57.4] Content-Type: multipart/alternative; boundary="_000_97B69B30E0EF244B940B65EA541E3F2D215731FFDBXPRD0510MB395_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "manet@ietf.org List" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 23:31:36 -0000 --_000_97B69B30E0EF244B940B65EA541E3F2D215731FFDBXPRD0510MB395_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable One thing that popped up in my mind : Are we trying to do the merge between DYMO and LOADng that has previously f= ailed ?? Regardless from which document we start, I understood (from Charlie massage= s) that LOADng authors were not OK to merge their document with functionali= ties from DYMO . Did I missed something here ? C=E9dric. Le 2 nov. 2012 =E0 23:41, C Chauvenet a =E9crit : Hi all, If we add mechanisms to LOADng or prune some from DYMO, we end up with a di= fferent protocol, so I think that we will need to change the name of the re= sulting protocol. I support the AODVv2 naming for the reactive protocol of = MANET, if chairs decide to go forward and do not take option 3). It seems that charlie is working hard on updating the DYMO draft, by addres= sing reviews of the document. These reviews contains most of the improvemen= ts (readability, RFC5444 compliance ....) that people found missing in DYMO= . I think that would make sense to wait for the next update of DYMO before = choosing between LOADng and DYMO. I think that the WG want something good, = rather than something quick. In addition, we would benefit from the work that charlie is currently doing= , rather that skip it if we made a decision based on the actual DYMO versio= n. C=E9dric. Le 2 nov. 2012 =E0 22:10, Jon Black a =E9crit : It is not completely new and it is much more mature. It has been being dev= eloped for quite some time, it has implementations, it has interoperability= . Age of a document is not a good criteria. Something can be written quit= e a long time ago and nothing done on it. Another document/protocol may co= me along, gain critical mass, gain experience and even though younger may b= e a much better starting point. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black >; Ulrich= Herberg >; Abdussalam Bary= un >; "Dearlo= ve, Christopher (UK)" >; "manet@ietf.org List" > Sent: Friday, November 2, 2012 11:21 AM Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol so =85 should we start with a completely new document then ? On Nov 2, 2012, at 1:16 PM, Jon Black wrote: This seems to make good sense. The name should not be issue. We need a go= od solid base to start from. It would appear that if there are working int= eroperable implementation based on the LOADng draft then this indicates tha= t the draft is implementable. Again, having read both I could build someth= ing based on the LOADng draft and I (and I'm only talking for me) couldn't = based on the DYMO draft. I much prefer starting with something simple and understandable and adding = what is missing rather than starting with something more difficult to under= stand trying to remove things that are not needed. Jon ________________________________ From: Ulrich Herberg > To: Abdussalam Baryun > Cc: "Dearlove, Christopher (UK)" >; "manet@ietf.org" > Sent: Friday, November 2, 2012 10:34 AM Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol Hi Abdussalam, there was indeed some hesitance to change the name from some of the authors= (not me). I cannot speak for them here. My intuition is that if the name o= f the protocol is the only factor that avoids the reactive protocol from pr= oceeding in the WG, this can be solved. As far as I can see from the discussions so far, there is a clear consensus= that option 3 is not viable. Now, if we want to proceed with the reactive = document, the question is from which document to start. Chris mentioned tha= t even if we wanted the specification of 100%, it would be far quicker to s= tart from the LOADng draft. I propose that we can start working based on th= e LOADng draft (possibly rename it?), look at each item that is in DYMO and= consider whether and in which way it should be incorporated in the draft. Best Ulrich On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun > wrote: Hi Ulrich, I think that Chris's proposal was not accepted by LOADng co-authors as I un= derstood from following up the WG history (they don't agree to change the n= ame of protocol). As you are one co-author do I understand that you support= the Chris's proposal, AB On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg > wrote: Dear Chris, personally, what you propose makes sense to me. Regards Ulrich On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" > wrote: > Before making a proposal, I'm going to introduce a distinction here betwe= en the DYMO and LOADng documents and protocols. > > I'm of the opinion that the LOADng document is a greatly superior present= ation to the DYMO document. (I'm not really interested in why that has come= about.) > > I think that regardless of whether one makes design decisions favouring D= YMO or LOADng where they differ - and let's not forget they overlap a lot -= it would actually be easier to modify the LOADng document to specify DYMO = than it would be to modify the DYMO document to achieve that. And in practi= ce I think if making decisions it is unlikely that all would favour DYMO ov= er LOADng. > > So what I think would be best for the WG is not a simply "option 1" or ev= en (as it may appear I'm suggesting, but I'm not) "option 2" but rather to= agree to take the LOADng document, and a list of where DYMO and LOADng dif= fer, and thrash out where they do, what the WG reactive protocol should do = - either as a definite choice, or as an option (but not too many options pl= ease- and some could be separate specifications). > > This would not of course be LOADng, so we'd have to change the document n= ame. And there I suggest we have a candidate name - AODVv2. (Which is why I= have recently taken to saying DYMO when referring to that document.) After= all, the one thing we are agreed on is that the protocol being developed i= s derived from AODV. > > The editors of this new document would have to agree that what goes in it= is WG consensus (which should follow proper technical consideration of the= issues). If they found it impossible to have other than their way to do th= ings, they'd have to move on. If that left no one editing it, obviously we = don't have a consensus of people prepared to do the work and option 3 would= win. > > So now I'm partly off the fence I've been sitting on. But only partly. I = haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standar= d, IRREPs as an option in the main draft, IRREPs as a separate draft option= , no IRREPs. I'd like to move on to those discussions. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | htt= p://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > ******************************************************************** > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_97B69B30E0EF244B940B65EA541E3F2D215731FFDBXPRD0510MB395_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9133452684909A448DD7D87A68C00288@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable One thing that popped up in my mind : 

Are we trying to do the merge between DYMO and LOADng that has previou= sly failed ??

Regardless from which document we start, I understood (from Charlie ma= ssages) that LOADng authors were not OK to merge their document with functi= onalities from DYMO . Did I missed something here ?

C=E9dric.

Le 2 nov. 2012 =E0 23:41, C Chauvenet a =E9crit :

Hi all, 

If we add mechanisms to LOADng or prune some from DYMO, we end up with= a different protocol, so I think that we will need to change the name of t= he resulting protocol. I support the AODVv2 naming for the reactive protoco= l of MANET, if chairs decide to go forward and do not take option 3).

It seems that charlie is working hard on updating the DYMO draft, by a= ddressing reviews of the document. These reviews contains most of the impro= vements (readability, RFC5444 compliance ....) that people found missing in= DYMO. I think that would make sense to wait for the next update of DYMO before choosing between LOADng and DYM= O. I think that the WG want something good, rather than something quick.&nb= sp;
In addition, we would benefit from the work that charlie is currently = doing, rather that skip it if we made a decision based on the actual DYMO v= ersion.

C=E9dric.

Le 2 nov. 2012 =E0 22:10, Jon Black a =E9crit :

It is not completely new and it is much more mature.  It has been bein= g developed for quite some time, it has implementations, it has interoperab= ility.  Age of a document is not a good criteria.  Something can = be written quite a long time ago and nothing done on it.  Another document/protocol may come along, gain critical mass,= gain experience and even though younger may be a much better starting poin= t.

Jon

From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>; Ulrich Herberg <ulrich@herberg.name>; Abdussalam Baryun <abdussalambaryun@gmail.com>; "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>; "manet@ietf.org List" <manet@ietf.org>
Sent: Friday, November 2, = 2012 11:21 AM
Subject: Re: [manet] A pro= posal - differentiating the document and the protocol

so =85 should we start with a completely new document then ?

On Nov 2, 2012, at 1:16 PM, Jon Black wrote:

This seems to make good sense.  The name should not be issue.  We= need a good solid base to start from.  It would appear that if there = are working interoperable implementation based on the LOADng draft then thi= s indicates that the draft is implementable.  Again, having read both I could build something based on the LOADng draft and I (= and I'm only talking for me) couldn't based on the DYMO draft.

I much prefer starting with something simple and understandable and adding = what is missing rather than starting with something more difficult to under= stand trying to remove things that are not needed.

Jon


From: Ulrich Herberg <ulrich@herberg.name>
To: Abdussalam Baryun <<= a rel=3D"nofollow" ymailto=3D"mailto:abdussalambaryun@gmail.com" target=3D"= _blank" href=3D"mailto:abdussalambaryun@gmail.com">abdussalambaryun@gmail.c= om>
Cc: "Dearlove, Christo= pher (UK)" <Chris.Dearlove@baesystems.com>; "manet@ietf.org" <manet@ietf.org>
Sent: Friday, November 2, 2= 012 10:34 AM
Subject: Re: [manet] A prop= osal - differentiating the document and the protocol

Hi Abdussalam,

there was indeed some hesitance to change the name from some of the au= thors (not me). I cannot speak for them here. My intuition is that if the n= ame of the protocol is the only factor that avoids the reactive protocol fr= om proceeding in the WG, this can be solved.

As far as I can see from the discussions so far, there is a clear cons= ensus that option 3 is not viable. Now, if we want to proceed with the reac= tive document, the question is from which document to start. Chris mentione= d that even if we wanted the specification of 100%, it would be far quicker to start from the LOADng draft. I pr= opose that we can start working based on the LOADng draft (possibly re= name it?), look at each item that is in DYMO and consider whether and in wh= ich way it should be incorporated in the draft. 

Best
Ulrich



On Fri, Nov 2, 2012 at 9:17 AM, Abd= ussalam Baryun <a= bdussalambaryun@gmail.com> wrote:
Hi Ulrich,
 
I think that Chris's proposal was not accepted by LOADng co-autho= rs as I understood from following up the WG history (they don't agree to ch= ange the name of protocol). As you are one co-author do I understand that y= ou support the Chris's proposal,
AB
On Fri, Nov 2, 2012 at 2:41 PM, Ulr= ich Herberg <ulrich@herberg.= name> wrote:
Dear Chris,

personally, what you propose makes sense to me.


Regards
Ulrich

On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesyste= ms.com> wrote:

> Before making a proposal, I'm going to introduce a distinction here be= tween the DYMO and LOADng documents and protocols.
>
> I'm of the opinion that the LOADng document is a greatly superior pres= entation to the DYMO document. (I'm not really interested in why that has c= ome about.)
>
> I think that regardless of whether one makes design decisions favourin= g DYMO or LOADng where they differ - and let's not forget they overlap a lo= t - it would actually be easier to modify the LOADng document to specify DY= MO than it would be to modify the DYMO document to achieve that. And in practice I think if making decisions it i= s unlikely that all would favour DYMO over LOADng.
>
> So what I think would be best for the WG is not a simply "option = 1" or even (as it may appear I'm suggesting, but  I'm not) "= option 2" but rather to agree to take the LOADng document, and a list = of where DYMO and LOADng differ, and thrash out where they do, what the WG reactive protocol should do - either as a definite choice, or = as an option (but not too many options please- and some could be separate s= pecifications).
>
> This would not of course be LOADng, so we'd have to change the documen= t name. And there I suggest we have a candidate name - AODVv2. (Which is wh= y I have recently taken to saying DYMO when referring to that document.) Af= ter all, the one thing we are agreed on is that the protocol being developed is derived from AODV.
>
> The editors of this new document would have to agree that what goes in= it is WG consensus (which should follow proper technical consideration of = the issues). If they found it impossible to have other than their way to do= things, they'd have to move on. If that left no one editing it, obviously we don't have a consensus of people= prepared to do the work and option 3 would win.
>
> So now I'm partly off the fence I've been sitting on. But only partly.= I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as stan= dard, IRREPs as an option in the main draft, IRREPs as a separate draft opt= ion, no IRREPs. I'd like to move on to those discussions.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
>
> ******************************************************************** > 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.
> ******************************************************************** >
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_97B69B30E0EF244B940B65EA541E3F2D215731FFDBXPRD0510MB395_-- From ulrich@herberg.name Fri Nov 2 16:45:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5F921F9BBF for ; Fri, 2 Nov 2012 16:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SH99G7q2SC7S for ; Fri, 2 Nov 2012 16:45:01 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2173221F9BBB for ; Fri, 2 Nov 2012 16:45:01 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4747625vcb.31 for ; Fri, 02 Nov 2012 16:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b7GyRft2QhpouP3KoS5l9tyaqtBKiMXh24G23kMj5RY=; b=WwXQuAFeW6hrPFDIxSBw5+GyShihBlNQJ8SE7NEQ8+cPjoEd8G7tWQLMKKocvXHukM P3aNdUX4XwWvZphPg36WloCxjDsuQEiBgFNBwjV1OaFJSRrNczuA6qa0AxPAHtxXI41L /So4+c6cY/9Q4IwzWfOjqzk+8nTTRa9gNMrj4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=b7GyRft2QhpouP3KoS5l9tyaqtBKiMXh24G23kMj5RY=; b=SsFyk+eL2opmU+yxiHkVXIpfd7MM/Ht16NcKY/NwpkD9Ai2sdtGsmVCcxohYyJg6MP IgYfiy5fPYoE49l28RddgwKUS1nPGRppsa5whC7u1nEVrkdp6X/Hfzm8GyTPvYutHZBQ wjkkkU+O0slo06vEJFT+jRDJ7ysMviGfUUQ1iqlkdZsOfmmmBImgCddD8FyaqyQ49vLJ 6w4bPUX10OdgvAUNsysrAFj8kJrlBfGmhRGePiqatSLm6O6KlQCHf+lpv1Wr72rxw4QH E7cbcXeizPrYqmeWhKZU1fs1zSkrERVq9Z4D0zdYuAhKzHXDfyt/LGWADBissSx/00Zb cxmg== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr2998955vdv.20.1351899900431; Fri, 02 Nov 2012 16:45:00 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Fri, 2 Nov 2012 16:45:00 -0700 (PDT) In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D215731FF@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> <1351876587.86080.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204C69E@xmb-rcd-x02.cisco.com> <1351890653.89343.YahooMailNeo@web160603.mail.bf1.yahoo.com> <97B69B30E0EF244B940B65EA541E3F2D21572F63@DBXPRD0510MB395.eurprd05.prod.outlook.com> <97B69B30E0EF244B940B65EA541E3F2D215731FF@DBXPRD0510MB395.eurprd05.prod.outlook.com> Date: Fri, 2 Nov 2012 16:45:00 -0700 Message-ID: From: Ulrich Herberg To: C Chauvenet Content-Type: multipart/alternative; boundary=bcaec50162bd564bbd04cd8bb945 X-Gm-Message-State: ALoCoQlaphX8aFTHSAgwwmg+6KPs8jBng00r2J1Hip0SDjLgu3qBsKI1ISALo0fWauWyIlA6smJy Cc: =?ISO-8859-1?Q?Axel_Colin_de_Verdi=E8re?= , "manet@ietf.org List" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 23:45:03 -0000 --bcaec50162bd564bbd04cd8bb945 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable C=E9dric, the merge did not fail for technical but for process reasons. We offered Charlie to be editor, together with Thomas. Charlie is already author of LOADng. In my opinion (I can't speak for anyone else), that has not changed. If we start the merge from the LOADng document, we would be far quicker to come to an RFC. As said, we can then look at each option, see if it's suitable or not, and if it should be part of the core or rather be in a companion document. Best Ulrich On Fri, Nov 2, 2012 at 4:31 PM, C Chauvenet wrote= : > One thing that popped up in my mind : > > Are we trying to do the merge between DYMO and LOADng that has > previously failed ?? > > Regardless from which document we start, I understood (from Charlie > massages) that LOADng authors were not OK to merge their document with > functionalities from DYMO . Did I missed something here ? > > C=E9dric. > > Le 2 nov. 2012 =E0 23:41, C Chauvenet a =E9crit : > > Hi all, > > If we add mechanisms to LOADng or prune some from DYMO, we end up with a > different protocol, so I think that we will need to change the name of th= e > resulting protocol. I support the AODVv2 naming for the reactive protocol > of MANET, if chairs decide to go forward and do not take option 3). > > It seems that charlie is working hard on updating the DYMO draft, by > addressing reviews of the document. These reviews contains most of the > improvements (readability, RFC5444 compliance ....) that people found > missing in DYMO. I think that would make sense to wait for the next updat= e > of DYMO before choosing between LOADng and DYMO. I think that the WG want > something good, rather than something quick. > In addition, we would benefit from the work that charlie is currently > doing, rather that skip it if we made a decision based on the actual DYMO > version. > > C=E9dric. > > Le 2 nov. 2012 =E0 22:10, Jon Black a =E9crit : > > It is not completely new and it is much more mature. It has been being > developed for quite some time, it has implementations, it has > interoperability. Age of a document is not a good criteria. Something c= an > be written quite a long time ago and nothing done on it. Another > document/protocol may come along, gain critical mass, gain experience and > even though younger may be a much better starting point. > > Jon > > ------------------------------ > *From:* JP Vasseur (jvasseur) > *To:* Jon Black ; Ulrich Herberg < > ulrich@herberg.name>; Abdussalam Baryun ; > "Dearlove, Christopher (UK)" ; " > manet@ietf.org List" > *Sent:* Friday, November 2, 2012 11:21 AM > *Subject:* Re: [manet] A proposal - differentiating the document and the > protocol > > so =85 should we start with a completely new document then ? > > On Nov 2, 2012, at 1:16 PM, Jon Black wrote: > > This seems to make good sense. The name should not be issue. We need > a good solid base to start from. It would appear that if there are worki= ng > interoperable implementation based on the LOADng draft then this indicate= s > that the draft is implementable. Again, having read both I could build > something based on the LOADng draft and I (and I'm only talking for me) > couldn't based on the DYMO draft. > > I much prefer starting with something simple and understandable and addin= g > what is missing rather than starting with something more difficult to > understand trying to remove things that are not needed. > > Jon > > > ------------------------------ > *From:* Ulrich Herberg > *To:* Abdussalam Baryun > *Cc:* "Dearlove, Christopher (UK)" ; " > manet@ietf.org" > *Sent:* Friday, November 2, 2012 10:34 AM > *Subject:* Re: [manet] A proposal - differentiating the document and the > protocol > > Hi Abdussalam, > > there was indeed some hesitance to change the name from some of the > authors (not me). I cannot speak for them here. My intuition is that if t= he > name of the protocol is the only factor that avoids the reactive protocol > from proceeding in the WG, this can be solved. > > As far as I can see from the discussions so far, there is a clear > consensus that option 3 is not viable. Now, if we want to proceed with th= e > reactive document, the question is from which document to start. Chris > mentioned that even if we wanted the specification of 100%, it would be f= ar > quicker to start from the LOADng draft. I propose that we can start worki= ng > based on the LOADng draft (possibly rename it?), look at each item that i= s > in DYMO and consider whether and in which way it should be incorporated i= n > the draft. > > Best > Ulrich > > > > On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > > Hi Ulrich, > > I think that Chris's proposal was not accepted by LOADng co-authors as I > understood from following up the WG history (they don't agree to change t= he > name of protocol). As you are one co-author do I understand that you > support the Chris's proposal, > AB > On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg wro= te: > > Dear Chris, > > personally, what you propose makes sense to me. > > > Regards > Ulrich > > On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" < > Chris.Dearlove@baesystems.com> wrote: > > > Before making a proposal, I'm going to introduce a distinction here > between the DYMO and LOADng documents and protocols. > > > > I'm of the opinion that the LOADng document is a greatly superior > presentation to the DYMO document. (I'm not really interested in why that > has come about.) > > > > I think that regardless of whether one makes design decisions favouring > DYMO or LOADng where they differ - and let's not forget they overlap a lo= t > - it would actually be easier to modify the LOADng document to specify DY= MO > than it would be to modify the DYMO document to achieve that. And in > practice I think if making decisions it is unlikely that all would favour > DYMO over LOADng. > > > > So what I think would be best for the WG is not a simply "option 1" or > even (as it may appear I'm suggesting, but I'm not) "option 2" but rathe= r > to agree to take the LOADng document, and a list of where DYMO and LOADng > differ, and thrash out where they do, what the WG reactive protocol shoul= d > do - either as a definite choice, or as an option (but not too many optio= ns > please- and some could be separate specifications). > > > > This would not of course be LOADng, so we'd have to change the document > name. And there I suggest we have a candidate name - AODVv2. (Which is wh= y > I have recently taken to saying DYMO when referring to that document.) > After all, the one thing we are agreed on is that the protocol being > developed is derived from AODV. > > > > The editors of this new document would have to agree that what goes in > it is WG consensus (which should follow proper technical consideration of > the issues). If they found it impossible to have other than their way to = do > things, they'd have to move on. If that left no one editing it, obviously > we don't have a consensus of people prepared to do the work and option 3 > would win. > > > > So now I'm partly off the fence I've been sitting on. But only partly. = I > haven't yet formed a view on e.g. should this AODVv2 have IRREPs as > standard, IRREPs as an option in the main draft, IRREPs as a separate dra= ft > option, no IRREPs. I'd like to move on to those discussions. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > > > ******************************************************************** > > 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. > > ******************************************************************** > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > --bcaec50162bd564bbd04cd8bb945 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable C=E9dric,

the merge did not fail for technical but for p= rocess reasons.=A0We offered Charlie to be editor, together with Thomas. Ch= arlie is already author of LOADng. In my opinion (I can't speak for any= one else), that has not changed.=A0
If we start the merge from the LOADng document, we would be far quicke= r to come to an RFC. As said, we can then look at each option, see if it= 9;s suitable or not, and if it should be part of the core or rather be in a= companion document.

Best
Ulrich



=
On Fri, Nov 2, 2012 at 4:31 PM, C Chauvenet <c.chauvenet@watteco.com> wrote:
One thing that popped up in my mind :=A0

Are we trying to do the merge between DYMO and LOADng that has previou= sly failed ??

Regardless from which document we start, I understood (from Charlie ma= ssages) that LOADng authors were not OK to merge their document with functi= onalities from DYMO . Did I missed something here ?

C=E9dric.

Le 2 nov. 2012 =E0 23:41, C Chauvenet a =E9crit :

Hi all,=A0

If we add mechanisms to LOADng or prune some from DYMO, we end up with= a different protocol, so I think that we will need to change the name of t= he resulting protocol. I support the AODVv2 naming for the reactive protoco= l of MANET, if chairs decide to go forward and do not take option 3).

It seems that charlie is working hard on updating the DYMO draft, by a= ddressing reviews of the document. These reviews contains most of the impro= vements (readability, RFC5444 compliance ....) that people found missing in= DYMO. I think that would make sense to wait for the next update of DYMO before choosing between LOADng and DYM= O. I think that the WG want something good, rather than something quick.=A0=
In addition, we would benefit from the work that charlie is currently = doing, rather that skip it if we made a decision based on the actual DYMO v= ersion.

C=E9dric.

Le 2 nov. 2012 =E0 22:10, Jon Black a =E9crit :

It is not completely new and it is much more mature.=A0 It has been being d= eveloped for quite some time, it has implementations, it has interoperabili= ty.=A0 Age of a document is not a good criteria.=A0 Something can be writte= n quite a long time ago and nothing done on it.=A0 Another document/protocol may come along, gain critical mass, ga= in experience and even though younger may be a much better starting point.<= br>
Jon

From: JP Vasseur (jvasseur) = <jvasseur@cisco.= com>
To: Jon Black <jblack.ietf@yahoo.com&= gt;; Ulrich Herberg <ulrich@herberg.name>; Abdussalam Baryun <abdussalambaryun@gmail.com>; "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>; = "manet@ietf.org List" <manet@= ietf.org>
Sent: Friday, November 2, 20= 12 11:21 AM
Subject: Re: [manet] A propo= sal - differentiating the document and the protocol

so =85 should we start with a completely new document then ?

On Nov 2, 2012, at 1:16 PM, Jon Black wrote:

This seems to make good sense.=A0 The name should not be issue.=A0 We need = a good solid base to start from.=A0 It would appear that if there are worki= ng interoperable implementation based on the LOADng draft then this indicat= es that the draft is implementable.=A0 Again, having read both I could build something based on the LOADng draft and I (= and I'm only talking for me) couldn't based on the DYMO draft.

I much prefer starting with something simple and understandable and adding = what is missing rather than starting with something more difficult to under= stand trying to remove things that are not needed.

Jon


From: Ulrich Herberg <ulri= ch@herberg.name>
To: Abdussalam Baryun <abdussalambaryun@gmail.com>
Cc: "Dearlove, Christop= her (UK)" <Chris.Dearlove@baesystems.com>; "manet@ie= tf.org" <m= anet@ietf.org>
Sent: Friday, November 2, 20= 12 10:34 AM
Subject: Re: [manet] A propo= sal - differentiating the document and the protocol

Hi Abdussalam,

there was indeed some hesitance to change the name from some of the au= thors (not me). I cannot speak for them here. My intuition is that if the n= ame of the protocol is the only factor that avoids the reactive protocol fr= om proceeding in the WG, this can be solved.

As far as I can see from the discussions so far, there is a clear cons= ensus that option 3 is not viable. Now, if we want to proceed with the reac= tive document, the question is from which document to start. Chris mentione= d that even if we wanted the specification of 100%, it would be far quicker to start from the LOADng draft.=A0I propo= se that we can start working based on the LOADng draft=A0(possibly rename i= t?), look at each item that is in DYMO and consider whether and in which wa= y it should be incorporated in the draft.=A0

Best
Ulrich



On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote= :
Hi Ulrich,
=A0
I think that=A0Chris's proposal was not accepted by LOADng co-auth= ors as I understood from following up the WG history (they don't agree = to change the name of protocol). As you are one co-author do I understand t= hat you support the Chris's proposal,
AB
On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
Dear Chris,

personally, what you propose makes sense to me.


Regards
Ulrich

On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> wrote:

> Before making a proposal, I'm going to introduce a distinction her= e between the DYMO and LOADng documents and protocols.
>
> I'm of the opinion that the LOADng document is a greatly superior = presentation to the DYMO document. (I'm not really interested in why th= at has come about.)
>
> I think that regardless of whether one makes design decisions favourin= g DYMO or LOADng where they differ - and let's not forget they overlap = a lot - it would actually be easier to modify the LOADng document to specif= y DYMO than it would be to modify the DYMO document to achieve that. And in practice I think if making decisions it i= s unlikely that all would favour DYMO over LOADng.
>
> So what I think would be best for the WG is not a simply "option = 1" or even (as it may appear I'm suggesting, but =A0I'm not) &= quot;option 2" but rather to agree to take the LOADng document, and a = list of where DYMO and LOADng differ, and thrash out where they do, what the WG reactive protocol should do - either as a definite choice, or = as an option (but not too many options please- and some could be separate s= pecifications).
>
> This would not of course be LOADng, so we'd have to change the doc= ument name. And there I suggest we have a candidate name - AODVv2. (Which i= s why I have recently taken to saying DYMO when referring to that document.= ) After all, the one thing we are agreed on is that the protocol being developed is derived from AODV.
>
> The editors of this new document would have to agree that what goes in= it is WG consensus (which should follow proper technical consideration of = the issues). If they found it impossible to have other than their way to do= things, they'd have to move on. If that left no one editing it, obviously we don't have a consensus of pe= ople prepared to do the work and option 3 would win.
>
> So now I'm partly off the fence I've been sitting on. But only= partly. I haven't yet formed a view on e.g. should this AODVv2 have IR= REPs as standard, IRREPs as an option in the main draft, IRREPs as a separa= te draft option, no IRREPs. I'd like to move on to those discussions.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 | =A0Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
>
> ******************************************************************** > 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.
> ******************************************************************** >
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@= ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@= ietf.org
https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@= ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--bcaec50162bd564bbd04cd8bb945-- From yi.jiazi@gmail.com Fri Nov 2 16:45:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5CC21F9BC4 for ; Fri, 2 Nov 2012 16:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nndCS8EzE83T for ; Fri, 2 Nov 2012 16:45:35 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id CAEF221F9BD0 for ; Fri, 2 Nov 2012 16:45:34 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm2so1513411wib.1 for ; Fri, 02 Nov 2012 16:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=vhtDNfmA7BhpM7qdckzK3MVT1vj2SrneGtAu19OAB+c=; b=fs9jcjfFJ7dNuODcOhvu4EBj5qjhuImqEyGGlLXcTII+YEY6VqYHd+ikpY3kF3CZbw y6YIlZMcc4ypBnnwc+pvp7UOrkRQlaXlaoW7vkVmbH5+XzSOkh2i98nyoXvsXELYQak2 2jI9ELUnq1x7WPIlSGw7MLNClGEtWspUeHxHXo6DwJeA0e/tk+tS1ZnXRpROu0rp2EGk nIOxAJJZYRFzgiv14LywI5dn3qu8xN2LMMs+cMr0j22KF/FyKCXiT5dfMQl0fJI4A9Qw akYFXUUTNiWwgbUwzO/f7aLORp6KYTDUpb8vTuQ+MyIJcYT12RVhYfyBnYF32+rOJ8n6 DLsQ== Received: by 10.216.195.25 with SMTP id o25mr1094217wen.6.1351899933918; Fri, 02 Nov 2012 16:45:33 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id ey2sm241537wib.9.2012.11.02.16.45.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 16:45:33 -0700 (PDT) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_EBAC4642-CF4A-4ACD-9100-053CCC984FAC" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi YI In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D215731FF@DBXPRD0510MB395.eurprd05.prod.outlook.com> Date: Sat, 3 Nov 2012 00:45:30 +0100 Message-Id: References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> <1351876587.86080.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204C69E@xmb-rcd-x02.cisco.com> <1351890653.89343.YahooMailNeo@web160603.mail.bf1.yahoo.com> <97B69B30E0EF244B940B65EA541E3F2D21572F63@DBXPRD0510MB395.eurprd05.prod.outlook.com> <97B69B30E0EF244B940B65EA541E3F2D215731FF@DBXPRD0510MB395.eurprd05.prod.outlook.com> To: C Chauvenet X-Mailer: Apple Mail (2.1499) Cc: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= , "manet@ietf.org List" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 23:45:37 -0000 --Apple-Mail=_EBAC4642-CF4A-4ACD-9100-053CCC984FAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Cedric,=20 The LOADng always welcome good ideas from DYMO if it can help improving = the protocol.=20 But Charlie insists starting from DYMO.=20 What I believe is that, the WG should begin with the document in better = shape, as suggested by Chris.=20 best Jiazi On Nov 3, 2012, at 12:31 AM, C Chauvenet = wrote: > One thing that popped up in my mind :=20 >=20 > Are we trying to do the merge between DYMO and LOADng that has = previously failed ?? >=20 > Regardless from which document we start, I understood (from Charlie = massages) that LOADng authors were not OK to merge their document with = functionalities from DYMO . Did I missed something here ? >=20 > C=E9dric. >=20 > Le 2 nov. 2012 =E0 23:41, C Chauvenet a =E9crit : >=20 >> Hi all,=20 >>=20 >> If we add mechanisms to LOADng or prune some from DYMO, we end up = with a different protocol, so I think that we will need to change the = name of the resulting protocol. I support the AODVv2 naming for the = reactive protocol of MANET, if chairs decide to go forward and do not = take option 3). >>=20 >> It seems that charlie is working hard on updating the DYMO draft, by = addressing reviews of the document. These reviews contains most of the = improvements (readability, RFC5444 compliance ....) that people found = missing in DYMO. I think that would make sense to wait for the next = update of DYMO before choosing between LOADng and DYMO. I think that the = WG want something good, rather than something quick.=20 >> In addition, we would benefit from the work that charlie is currently = doing, rather that skip it if we made a decision based on the actual = DYMO version. >>=20 >> C=E9dric. >>=20 >> Le 2 nov. 2012 =E0 22:10, Jon Black a =E9crit : >>=20 >>> It is not completely new and it is much more mature. It has been = being developed for quite some time, it has implementations, it has = interoperability. Age of a document is not a good criteria. Something = can be written quite a long time ago and nothing done on it. Another = document/protocol may come along, gain critical mass, gain experience = and even though younger may be a much better starting point. >>>=20 >>> Jon >>>=20 >>> From: JP Vasseur (jvasseur) >>> To: Jon Black ; Ulrich Herberg = ; Abdussalam Baryun ; = "Dearlove, Christopher (UK)" ; = "manet@ietf.org List" =20 >>> Sent: Friday, November 2, 2012 11:21 AM >>> Subject: Re: [manet] A proposal - differentiating the document and = the protocol >>>=20 >>> so =85 should we start with a completely new document then ? >>>=20 >>> On Nov 2, 2012, at 1:16 PM, Jon Black wrote: >>>=20 >>>> This seems to make good sense. The name should not be issue. We = need a good solid base to start from. It would appear that if there are = working interoperable implementation based on the LOADng draft then this = indicates that the draft is implementable. Again, having read both I = could build something based on the LOADng draft and I (and I'm only = talking for me) couldn't based on the DYMO draft. >>>>=20 >>>> I much prefer starting with something simple and understandable and = adding what is missing rather than starting with something more = difficult to understand trying to remove things that are not needed. >>>>=20 >>>> Jon >>>>=20 >>>>=20 >>>> From: Ulrich Herberg >>>> To: Abdussalam Baryun =20 >>>> Cc: "Dearlove, Christopher (UK)" ; = "manet@ietf.org" =20 >>>> Sent: Friday, November 2, 2012 10:34 AM >>>> Subject: Re: [manet] A proposal - differentiating the document and = the protocol >>>>=20 >>>> Hi Abdussalam, >>>>=20 >>>> there was indeed some hesitance to change the name from some of the = authors (not me). I cannot speak for them here. My intuition is that if = the name of the protocol is the only factor that avoids the reactive = protocol from proceeding in the WG, this can be solved. >>>>=20 >>>> As far as I can see from the discussions so far, there is a clear = consensus that option 3 is not viable. Now, if we want to proceed with = the reactive document, the question is from which document to start. = Chris mentioned that even if we wanted the specification of 100%, it = would be far quicker to start from the LOADng draft. I propose that we = can start working based on the LOADng draft (possibly rename it?), look = at each item that is in DYMO and consider whether and in which way it = should be incorporated in the draft.=20 >>>>=20 >>>> Best >>>> Ulrich >>>>=20 >>>>=20 >>>>=20 >>>> On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun = wrote: >>>> Hi Ulrich, >>>> =20 >>>> I think that Chris's proposal was not accepted by LOADng co-authors = as I understood from following up the WG history (they don't agree to = change the name of protocol). As you are one co-author do I understand = that you support the Chris's proposal, >>>> AB >>>> On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg = wrote: >>>> Dear Chris, >>>>=20 >>>> personally, what you propose makes sense to me. >>>>=20 >>>>=20 >>>> Regards >>>> Ulrich >>>>=20 >>>> On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" = wrote: >>>>=20 >>>> > Before making a proposal, I'm going to introduce a distinction = here between the DYMO and LOADng documents and protocols. >>>> > >>>> > I'm of the opinion that the LOADng document is a greatly superior = presentation to the DYMO document. (I'm not really interested in why = that has come about.) >>>> > >>>> > I think that regardless of whether one makes design decisions = favouring DYMO or LOADng where they differ - and let's not forget they = overlap a lot - it would actually be easier to modify the LOADng = document to specify DYMO than it would be to modify the DYMO document to = achieve that. And in practice I think if making decisions it is unlikely = that all would favour DYMO over LOADng. >>>> > >>>> > So what I think would be best for the WG is not a simply "option = 1" or even (as it may appear I'm suggesting, but I'm not) "option 2" = but rather to agree to take the LOADng document, and a list of where = DYMO and LOADng differ, and thrash out where they do, what the WG = reactive protocol should do - either as a definite choice, or as an = option (but not too many options please- and some could be separate = specifications). >>>> > >>>> > This would not of course be LOADng, so we'd have to change the = document name. And there I suggest we have a candidate name - AODVv2. = (Which is why I have recently taken to saying DYMO when referring to = that document.) After all, the one thing we are agreed on is that the = protocol being developed is derived from AODV. >>>> > >>>> > The editors of this new document would have to agree that what = goes in it is WG consensus (which should follow proper technical = consideration of the issues). If they found it impossible to have other = than their way to do things, they'd have to move on. If that left no one = editing it, obviously we don't have a consensus of people prepared to do = the work and option 3 would win. >>>> > >>>> > So now I'm partly off the fence I've been sitting on. But only = partly. I haven't yet formed a view on e.g. should this AODVv2 have = IRREPs as standard, IRREPs as an option in the main draft, IRREPs as a = separate draft option, no IRREPs. I'd like to move on to those = discussions. >>>> > >>>> > -- >>>> > Christopher Dearlove >>>> > Senior Principal Engineer, Communications Group >>>> > Communications, Networks and Image Analysis Capability >>>> > BAE Systems Advanced Technology Centre >>>> > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> > Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>> > chris.dearlove@baesystems.com | http://www.baesystems.com >>>> > >>>> > BAE Systems (Operations) Limited >>>> > Registered Office: Warwick House, PO Box 87, Farnborough = Aerospace Centre, Farnborough, Hants, GU14 6YU, UK >>>> > Registered in England & Wales No: 1996687 >>>> > >>>> > >>>> > >>>> > = ******************************************************************** >>>> > 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. >>>> > = ******************************************************************** >>>> > >>>> > _______________________________________________ >>>> > manet mailing list >>>> > manet@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/manet >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail=_EBAC4642-CF4A-4ACD-9100-053CCC984FAC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Cedric, 

The LOADng always welcome good ideas from = DYMO if it can help improving the protocol. 
But Charlie insists starting from = DYMO. 
What I believe is = that, the WG should begin with the document in better shape, as = suggested by Chris. 

best

Jiazi

On Nov 3, 2012, at 12:31 AM, C Chauvenet <c.chauvenet@watteco.com> = wrote:

One thing that popped up in my mind : 

Are we trying to do the merge between DYMO and LOADng that has = previously failed ??

Regardless from which document we start, I understood (from Charlie = massages) that LOADng authors were not OK to merge their document with = functionalities from DYMO . Did I missed something here ?

C=E9dric.

Le 2 nov. 2012 =E0 23:41, C Chauvenet a =E9crit :

Hi all, 

If we add mechanisms to LOADng or prune some from DYMO, we end up = with a different protocol, so I think that we will need to change the = name of the resulting protocol. I support the AODVv2 naming for the = reactive protocol of MANET, if chairs decide to go forward and do not take option 3).

It seems that charlie is working hard on updating the DYMO draft, = by addressing reviews of the document. These reviews contains most of = the improvements (readability, RFC5444 compliance ....) that people = found missing in DYMO. I think that would make sense to wait for the next update of DYMO before choosing between LOADng and = DYMO. I think that the WG want something good, rather than something = quick. 
In addition, we would benefit from the work that charlie is = currently doing, rather that skip it if we made a decision based on the = actual DYMO version.

C=E9dric.

Le 2 nov. 2012 =E0 22:10, Jon Black a =E9crit :

It is not completely new and it is much more mature.  It has been = being developed for quite some time, it has implementations, it has = interoperability.  Age of a document is not a good criteria.  = Something can be written quite a long time ago and nothing done on it.  Another document/protocol may come along, gain critical = mass, gain experience and even though younger may be a much better = starting point.

Jon

From: JP Vasseur = (jvasseur) <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>; = Ulrich Herberg <ulrich@herberg.name>; = Abdussalam Baryun <abdussalambaryun@gmail.com&= gt;; "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.co= m>; "manet@ietf.org List" = <manet@ietf.org>
Sent: Friday, November = 2, 2012 11:21 AM
Subject: Re: [manet] A = proposal - differentiating the document and the protocol

so =85 should we start with a completely new document then ?

On Nov 2, 2012, at 1:16 PM, Jon Black wrote:

This seems to make good sense.  The name should not be issue.  = We need a good solid base to start from.  It would appear that if = there are working interoperable implementation based on the LOADng draft = then this indicates that the draft is implementable.  Again, having read both I could build something based on the LOADng draft and = I (and I'm only talking for me) couldn't based on the DYMO draft.

I much prefer starting with something simple and understandable and = adding what is missing rather than starting with something more = difficult to understand trying to remove things that are not needed.

Jon


From: Ulrich Herberg = <ulrich@herberg.name>
To: Abdussalam Baryun = <abdussalambaryun@gmail.com&= gt;
Cc: "Dearlove, = Christopher (UK)" <Chris.Dearlove@baesystems.co= m>; "manet@ietf.org" <manet@ietf.org>
Sent: Friday, November = 2, 2012 10:34 AM
Subject: Re: [manet] A = proposal - differentiating the document and the protocol

Hi Abdussalam,

there was indeed some hesitance to change the name from some of the = authors (not me). I cannot speak for them here. My intuition is that if = the name of the protocol is the only factor that avoids the reactive = protocol from proceeding in the WG, this can be solved.

As far as I can see from the discussions so far, there is a clear = consensus that option 3 is not viable. Now, if we want to proceed with = the reactive document, the question is from which document to start. = Chris mentioned that even if we wanted the specification of 100%, it would be far quicker to start from the LOADng draft. I = propose that we can start working based on the LOADng = draft (possibly rename it?), look at each item that is in DYMO and = consider whether and in which way it should be incorporated in the = draft. 

Best
Ulrich



On Fri, Nov 2, 2012 at 9:17 AM, = Abdussalam Baryun <abdussalambaryun@gmail.com&= gt; wrote:
Hi Ulrich,
 
I think that Chris's proposal was not accepted by LOADng = co-authors as I understood from following up the WG history (they don't = agree to change the name of protocol). As you are one co-author do I = understand that you support the Chris's proposal,
AB
On Fri, Nov 2, 2012 at 2:41 PM, = Ulrich Herberg <ulrich@herberg.name> = wrote:
Dear Chris,

personally, what you propose makes sense to me.


Regards
Ulrich

On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.co= m> wrote:

> Before making a proposal, I'm going to introduce a distinction here = between the DYMO and LOADng documents and protocols.
>
> I'm of the opinion that the LOADng document is a greatly superior = presentation to the DYMO document. (I'm not really interested in why = that has come about.)
>
> I think that regardless of whether one makes design decisions = favouring DYMO or LOADng where they differ - and let's not forget they = overlap a lot - it would actually be easier to modify the LOADng = document to specify DYMO than it would be to modify the DYMO document to achieve that. And in practice I think if making decisions = it is unlikely that all would favour DYMO over LOADng.
>
> So what I think would be best for the WG is not a simply "option 1" = or even (as it may appear I'm suggesting, but  I'm not) "option 2" = but rather to agree to take the LOADng document, and a list of where = DYMO and LOADng differ, and thrash out where they do, what the WG reactive protocol should do - either as a definite choice, = or as an option (but not too many options please- and some could be = separate specifications).
>
> This would not of course be LOADng, so we'd have to change the = document name. And there I suggest we have a candidate name - AODVv2. = (Which is why I have recently taken to saying DYMO when referring to = that document.) After all, the one thing we are agreed on is that the protocol being developed is derived from AODV.
>
> The editors of this new document would have to agree that what goes = in it is WG consensus (which should follow proper technical = consideration of the issues). If they found it impossible to have other = than their way to do things, they'd have to move on. If that left no one editing it, obviously we don't have a consensus of = people prepared to do the work and option 3 would win.
>
> So now I'm partly off the fence I've been sitting on. But only = partly. I haven't yet formed a view on e.g. should this AODVv2 have = IRREPs as standard, IRREPs as an option in the main draft, IRREPs as a = separate draft option, no IRREPs. I'd like to move on to those discussions.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 = |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
>
> = ********************************************************************
> 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.
> = ********************************************************************
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet


= --Apple-Mail=_EBAC4642-CF4A-4ACD-9100-053CCC984FAC-- From trac+manet@trac.tools.ietf.org Fri Nov 2 19:41:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523EA1F0CA0 for ; Fri, 2 Nov 2012 19:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPb7tgGOjr4L for ; Fri, 2 Nov 2012 19:41:30 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3541F0C9C for ; Fri, 2 Nov 2012 19:41:30 -0700 (PDT) Received: from localhost ([127.0.0.1]:44383 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TUTfi-0007G7-9f; Sat, 03 Nov 2012 03:41:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "manet issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Sat, 03 Nov 2012 02:41:18 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/4 Message-ID: <061.9fd5709d256b2f4a875556dafc06bb3b@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: [manet] #4: Change to handling of Route.Dist for AdditionalNode routing information X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 02:41:31 -0000 #4: Change to handling of Route.Dist for AdditionalNode routing information Normal RREQ + RREP processing for route information always requires inclusion of a valid Route.Dist (i.e., Hop Count [as of the current revision]). Optionally, routing information related to "Additional Nodes" can be included for nodes that are not themselves AODVv2 routers. For such nodes, provision has been made to include relevant information (e.g., next hop) without requiring a valid Route.Dist for the additional node. However, this makes some of the specification more difficult to understand. The same effect can be achieved by assigning a large value for Route.Dist, so that any measured hop count will have the proper effect of updating the route table entry. Such a parameter is available now, namely MAX_HOPCOUNT. This only affects the optional inclusion of routing information about Additional Nodes. -- --------------------------------+------------------------------------- Reporter: charliep@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: dymo | Version: Severity: Active WG Document | Keywords: route metric, hop count --------------------------------+------------------------------------- Ticket URL: manet From jvasseur@cisco.com Sat Nov 3 01:02:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABBC21F9C9D for ; Sat, 3 Nov 2012 01:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.388 X-Spam-Level: X-Spam-Status: No, score=-10.388 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhvwlqAtQsLA for ; Sat, 3 Nov 2012 01:02:56 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA7921F9C9C for ; Sat, 3 Nov 2012 01:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6481; q=dns/txt; s=iport; t=1351929776; x=1353139376; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0+h11L1/tCnCW63JJ7IfJWZV8LqGxLKG8P/U4Ia6IoU=; b=BD44gw6/qa9cyZzWodiYT2i5hwV+FPZqipAykuBgY88p7ms4F9foTCTh xG9a1KF2ElYM9bhWUHXChvuVDA0ZohlLzGupwCvRKXPeh1sXYY8qkDnN3 txS4885Og2liFurF+adLt2X3EejXL9Hl/WB6PUdcyewRT1bY9lxMSibGV Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAC7PlFCtJXG9/2dsb2JhbABEwzKBCIIfAQEEAQEBDwFbCxACAQgiHQcnCxQRAgQOBQgah2gLnAGfdASMAYVbYQOIJZwvgWuCb4FkFx4 X-IronPort-AV: E=Sophos;i="4.80,704,1344211200"; d="scan'208,217";a="138408755" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 03 Nov 2012 08:02:56 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA382tR4002509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 08:02:55 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 03:02:55 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] Management use cases for MANETs Thread-Index: AQHNuZmgx87EYAkCY02yFM4IXK+VPQ== Date: Sat, 3 Nov 2012 08:02:54 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204D608@xmb-rcd-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.169] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--44.283200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204D608xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , "Benoit Claise \(bclaise\)" , "" Subject: Re: [manet] Management use cases for MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 08:02:57 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204D608xmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ulrich, On Nov 2, 2012, at 3:17 PM, Ulrich Herberg wrote: Hi [manet] participants, I am forwarding an email from Benoit that was sent to coman@ietf.org, since it concerns MANET. COMAN is a new activity (not yet= a WG) relating to management of constrained devices and networks. As I men= tioned at the last IETF, Benoit cleared his DISCUSS on the NHDP-MIB if we c= ommit to write a document about applicability and use cases of management o= f MANET routers. In COMAN, an individual ID was presented (draft-ersue-constrained-mgmt) tha= t discusses use cases of management. Note that this is an early draft and w= ill possibly be split in multiple drafts. There is some discussion whether = that should include mobility or not (currently, MANET is excluded but mesh = networks are not, which I think needs some more discussion, as both are abo= ut dynamic topologies). Anyway, similar to Benoit, it is unclear to me whet= her this draft or any work in COMAN (if it was to become a WG) would satisf= y the request for a use case/applicability document, or if MANET should wor= k on a separate draft. As the next OLSRv2-MIB revision will be submitted next Monday, (which I con= sider ready for WGLC) this is something we need to seriously consider. Opinions? It would make a lot of sense to work on a separate document on the subject = matter. Thanks for forwarding. JP. Thanks Ulrich On Fri, Nov 2, 2012 at 4:45 AM, Benoit Claise > wrote: Hi, One point regarding MANET. I believe that it deserves its own document: "MANET network management cons= iderations". Actually, when looking at draft-ietf-manet-nhdp-mib part of th= e IESG review, one of the outcome was that such a document was required. I cleared my DISCUSS on draft-ietf-manet-nhdp-mib with this COMMENT Note regarding the applicability statement: This is solved, as we discussed, but I'll keep this little sentence in one corner of my head "A fuller discussion of MANET network management use cases and challenges will be provided elsewhere." How/If this "MANET network management considerations" draft relates to the = draft-ersue-constrained-mgmt, I'm not sure at this point in time. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204D608xmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <897AEB6CB7BD354D96FC1037E86FE3CC@cisco.com> Content-Transfer-Encoding: quoted-printable Hi Ulrich,

On Nov 2, 2012, at 3:17 PM, Ulrich Herberg wrote:

Hi [manet] participants,

I am forwarding an email from Benoit that was sent to coman@ietf.org, since it concerns MANET. COMAN is a new activity (not y= et a WG) relating to management of constrained devices and networks. As I m= entioned at the last IETF, Benoit cleared his DISCUSS on the NHDP-MIB if we= commit to write a document about applicability and use cases of management of MANET routers.

In COMAN, an individual ID was presented (draft-ersue-constrained-mgmt= ) that discusses use cases of management. Note that this is an early d= raft and will possibly be split in multiple drafts. There is some discussio= n whether that should include mobility or not (currently, MANET is excluded but mesh networks are not, which I th= ink needs some more discussion, as both are about dynamic topologies). Anyw= ay, similar to Benoit, it is unclear to me whether this draft or any work i= n COMAN (if it was to become a WG) would satisfy the request for a use case/applicability document, or if MAN= ET should work on a separate draft.

As the next OLSRv2-MIB revision will be submitted next Monday, (which = I consider ready for WGLC) this is something we need to seriously consider.=  

Opinions?


It would make a lot of sense to work on a separate document on the sub= ject matter.

Thanks for forwarding.

JP.

Thanks
Ulrich

On Fri, Nov 2, 2012 at 4:45 AM, Benoit Claise <bclaise@cisco.co= m> wrote:
Hi,

One point regarding MANET.
I believe that it deserves its own document: "MANET network management= considerations". Actually, when looking at draft-ietf-manet-nhdp-mib = part of the IESG review, one of the outcome was that such a document was re= quired.
I cleared my DISCUSS on draft-ietf-manet-nhdp-mib with this COMMENT
Note regarding the applicability statement: This is solved, as we
discussed, but I'll keep this little sentence in one=20
corner of my head "A fuller discussion of MANET network management use
cases and challenges will be provided elsewhere."
How/If this "MANET network management considerations" draft relat= es to the draft-ersue-constrained-mgmt, I'm not sure at this point in time.=

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A772204D608xmbrcdx02ciscoc_-- From jvasseur@cisco.com Sat Nov 3 01:10:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D615B21F9CA8 for ; Sat, 3 Nov 2012 01:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.226 X-Spam-Level: X-Spam-Status: No, score=-10.226 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvD4+6x1s+iT for ; Sat, 3 Nov 2012 01:10:39 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9089C21F9C88 for ; Sat, 3 Nov 2012 01:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23594; q=dns/txt; s=iport; t=1351930239; x=1353139839; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hbYPSCgXXJnqoMd6d8roW9wbijFvf+4SkCFITUABNSc=; b=ac1mv5s5TbhtwpmLzvZImOhYsHuhuOpcb0hEQQi2X1guVctxB/3tda6d qImK0ZTzqKnrV018WFfmAYcfyBI8q8O8qkjs0uTqYpceNXaVcg6DHyd9S b5CoNr7kwN8ACvk0+ydYtGgpTfWThuUpWanIDbzBGP7Q8EZqftQfgQdyt E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAE3QlFCtJV2Y/2dsb2JhbABEgkmDTrwge4EIgh4BAQEEAQEBDwEQSwYFEAIBCA4HDR0DAgICJQsUEQIEDgUIDAcHh2gLnAKNKZJPjAEKCwUBBYUJMmEDlxeNPYFrgm+BXAgXHg X-IronPort-AV: E=Sophos;i="4.80,704,1344211200"; d="scan'208,217";a="138409660" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 03 Nov 2012 08:10:25 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA38APPV030456 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 08:10:25 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 03:10:25 -0500 From: "JP Vasseur (jvasseur)" To: Jon Black Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuRrYLPVi/cSo/ES1hdb7zda62w== Date: Sat, 3 Nov 2012 08:10:24 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204D666@xmb-rcd-x02.cisco.com> References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <1351889394.5207.YahooMailNeo@web160601.mail.bf1.yahoo.com> In-Reply-To: <1351889394.5207.YahooMailNeo@web160601.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.169] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--49.509400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204D666xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 08:10:41 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204D666xmbrcdx02ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgIkpvbiINCg0KWW91IGNhbiBrZWVwIGlnbm9yaW5nIHdoYXQgSSBhbSB3cml0aW5nIOKApiBi dXQgdGhpcyBkb2VzIG5vdCBoZWxwLiBUaGUgaXNzdWUgaXMgbm90ICJ0aGlzIiBwYXJhZ3JhcGgg LSBJIGV4cGxhaW5lZCB3aHkgYSBudW1iZXIgb2YgdGltZXMuDQpBbmQgcHJvcG9zZWQgYSB3YXkg dG8gZ28sIGNhbGwgaXQgb3B0aW9uIDEuNS4NCg0KT24gTm92IDIsIDIwMTIsIGF0IDQ6NDkgUE0s IEpvbiBCbGFjayB3cm90ZToNCg0KRnJvbTogSlAgVmFzc2V1ciAoanZhc3NldXIpIDxqdmFzc2V1 ckBjaXNjby5jb208bWFpbHRvOmp2YXNzZXVyQGNpc2NvLmNvbT4+DQoNCk9uIE5vdiAyLCAyMDEy LCBhdCAxMTowOCBBTSwgVWxyaWNoIEhlcmJlcmcgd3JvdGU6DQpJIHRoaW5rIG9uZSBrZXkgcG9p bnQgdG8gc3RyZXNzIGlzIG9uZSB0aGF0IENocmlzIG1lbnRpb25lZDoNCkJvdGggcHJvdG9jb2xz IGFyZSBzaW1pbGFyIGluIHRoZWlyIG9wZXJhdGlvbiBhbmQgcGVyZm9ybWFuY2UuIFNvIGFueW9u ZSBhcmd1aW5nIGFnYWluc3QgdGhlIHBlcmZvcm1hbmNlIG9mIExPQURuZyBpcyBhdXRvbWF0aWNh bGx5IGFsc28gbm90IGludGVyZXN0ZWQgaW4gRFlNTy4NCg0KDQpTZWUgbXkgcG9pbnQgVWxyaWNo IOKApiBhbmQgSSB3cm90ZSBpdCBkb3duIHNldmVyYWwgdGltZXMuIFRoZXJlIGFyZSBtYWpvciBj b25jZXJucyBpbiB1c2luZyBMb2FkLW5nIHdpdGggTExOcy4gUXVvdGluZyBMb2FkLW5nOg0KDQoN CjM8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2xhdXNlbi1sbG4tbG9hZG5nLTA2 I3NlY3Rpb24tMz4uICBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudA0KDQoNCiAgIFRoaXMgcHJvdG9j b2w6DQoNCiAgIG8gIElzIGEgcmVhY3RpdmUgcm91dGluZyBwcm90b2NvbCBmb3IgTW9iaWxlIEFk IGhvYyBORVR3b3Jrcw0KICAgICAgKE1BTkVUcykuDQoNCiAgIG8gIElzIGRlc2lnbmVkIHRvIHdv cmsgaW4gbmV0d29ya3Mgd2l0aCBkeW5hbWljIHRvcG9sb2d5IGluIHdoaWNoIHRoZQ0KICAgICAg bGlua3MgbWF5IGJlIGxvc3N5IGR1ZSB0byBjb2xsaXNpb25zIG9yIHVuc3RhYmxlIGNoYW5uZWwu ICBUaGUgdXNlDQogICAgICBjYXNlcyBpbmNsdWRlIHZlaGljdWxhciBuZXR3b3JrcywgbG93IHBv d2VyIGFuZCBsb3NzeSBuZXR3b3JrcywNCiAgICAgIGNvbW11bml0eSBuZXR3b3JrcywgbWlsaXRh cnkgbmV0d29ya3MsIGRpc2FzdGVyIHJlY292ZXJ5IG5ldHdvcmtzLA0KICAgICAgZXRjLg0KDQoN ClRoaXMgaXMgd2hlcmUgSSBzdHJvbmdseSBvYmplY3QsIGFzIHNldmVyYWwgb3RoZXIgb25lcyBv biB0aGlzIG1haWxpbmcgbGlzdC4gT25lIGNhbm5vdCBzaW1wbHkgZm9yZ2V0IDQtNSB5ZWFycyBv ZiBoYXJkIHdvcmsgZnJvbSBhIFdHIHRoYXQgZm9jdXNzZWQNCm9uIHRoaXMgdXNlIGNhc2UgYW5k IGNvbmNsdWRlZCB0aGF0IHN1Y2ggcHJvdG9jb2wgaXMgbm90IGFwcGxpY2FibGUgdG8gTExOcy4N Cg0KW0pvbl0gSXMgdGhhdCB5b3VyIHRydWUgb2JqZWN0aW9uIHRvIHRoZSBMT0FEbmcgZHJhZnQu ICBUaGVuIEkgd291bGQgdGhpbmsgdGhlIHNpbXBsZSBzb2x1dGlvbiBpcyB0byByZW1vdmUgdGhp cyBvbmUgcGFyYWdyYXBoIGFuZCBtb3ZlIG9uLg0KRGV2ZWxvcGVycyB3aWxsICBkZWNpZGUgd2hh dCBwcm90b2NvbHMgYXJlIGFwcGxpY2FibGUgdG8gdGhlaXIgYXBwbGljYXRpb24gYXMgdGhleSBz aG91bGQgLSBhcyBJIHdpbGwuDQpJIHdpbGwgYXNrIGluIFJPTEwgd2hlcmUgdGhlIGNvbmNsdXNp b24gd2FzIGRyYXduIHRoYXQgeW91IGNhbm5vdCBwb3NzaWJseSB1c2UgYSByZWFjdGl2ZSBwcm90 b2NvbCBpbiBhbnkgTExOIGFwcGxpY2F0aW9uLiAgVGhhdCBpcyBmb3IgYSBkaXNjdXNzaW9uIGlu IFJPTEwgbm90IGhlcmUuDQpBZ2FpbiBpZiB0aGlzIG9uZSBwYXJhZ3JhcGggaXMgYWxsIHRoZSBm dXNzIHRoZW4gbGV0cyBwbGVhc2UgcmVhY2ggY29uc2Vuc3VzIHRvIHJlbW92ZSB0aGlzIGFuZCBt b3ZlIGZvcndhcmQuICBHb3NoIHRoYXQgc2VlbXMgc2ltcGxlLg0KDQpKb24NCg0KDQpIb3dldmVy LCBMT0FEbmcgaXMgZmFyIGNsb3NlciB0byBiZWNvbWUgYW4gUkZDIGluIHRlcm1zIG9mIHRoZSBk b2N1bWVudCBxdWFsaXR5LiBJZiB3ZSBzdGFydCB0aGUgbmV3IHJlYWN0aXZlIHByb3RvY29sIG9u IHRoZSBiYXNpcyBvZiB0aGUgTE9BRG5nIGRyYWZ0IChhbmQgSSBwZXJzb25hbGx5IGRvbid0IGNh cmUgd2hhdCB3ZSBuYW1lIHRoYXQgcHJvdG9jb2wgaXMpLCB3ZSBjYW4gY29udGludWUgdGhlIHdv cmsgb24gdGhlIHJlYWN0aXZlIHByb3RvY29sIHRvZ2V0aGVyIGFuZCBkaXNjdXNzIHRoZSBtdWx0 aXBsZSBvcHRpb25zIHRoYXQgYXJlIGN1cnJlbnRseSBpbiBEWU1PIGFuZCBzZWUgd2hldGhlciB0 aGV5IHNob3VsZCBiZSBkaXNjYXJkZWQsIHB1dCBpbnRvIGEgY29tcGFuaW9uIGRvY3VtZW50IG9y IGluIHRoZSBjb3JlIHNwZWMuDQoNCkJlc3QNClVscmljaA0KDQpPbiBOb3YgMiwgMjAxMiwgYXQg Nzo1NCwgWXVpY2hpIElHQVJBU0hJIDx5dWljaGkuaWdhcmFzaGkuaGJAaGl0YWNoaS5jb208bWFp bHRvOnl1aWNoaS5pZ2FyYXNoaS5oYkBoaXRhY2hpLmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0KSSBh Z3JlZSB3aXRoIE1hcnRpbiBhbmQgSSB3b3VsZCBzdXBwb3J0IG9wdGlvbiAyKSBhdCB0aGlzIHN0 YWdlLg0KDQpXZSBMT0FEbmcgY28tYXV0aG9ycyBtYWRlIGVmZm9ydHMgdG8gc2ltcGxpZnkgY29y ZSBzcGVjaWZpY2F0aW9uIG9mIHRoZSByZWFjdGl2ZSBwcm90b2NvbCBhbmQgdG8gaW1wcm92ZSB0 aGUgcmVhZGFiaWxpdHkgb2YgdGhlIGRyYWZ0LiBJIHRoaW5rIHRoaXMgYXBwcm9hY2ggaXMgaW1w b3J0YW50IG5vdCBvbmx5IGZvciBhbGwgaW1wbGVtZW50b3IgdG8gc2hvcnRlbiB0aGUgZGV2ZWxv cG1lbnQgdGltZSwgYnV0IGFsc28gZm9yIGJ1c2luZXNzIG9wZXJhdG9ycyB0byBtYWtlIG11bHRp LXZlbmRvciBzeXN0ZW0gZWFzaWVyIHRvIHByb3ZpZGUuIE9mIGNvdXJzZSwgSSBhZ3JlZSB0aGF0 LCBhcyBzZXZlcmFsIHBlcnNvbnMgcG9pbnRlZCBvdXQsICJ0aGlzIGRyYWZ0IiBtYXkgbGltaXQg dXNlIGNhc2UuIEJ1dCB3ZSBsZWF2ZSBzdWZmaWNpZW50IHNwYWNlIGZvciBpbXByb3ZpbmcgcGVy Zm9ybWFuY2UvYWRkaW5nIGZ1bmN0aW9ucyBieSBjb21wYW5pb24gZHJhZnRzLg0KDQpJIGFtIHJl YWxseSBjb25jZXJuZWQgYWJvdXQgY29tcGxleGl0eS9kaWZmaWN1bHR5IG9mIGd1YXJhbnRlZWlu ZyBvZiBpbnRlcm9wZXJhYmlsaXR5LiBJZiB0aGUgcHJvdG9jb2wgYmVjb21lcyBjb21wbGljYXRl ZCwgd2UgbmVlZCBtdWNoIHRpbWUobWFueSB5ZWFycz8pIGZvciBpbnRlcm9wZXJhYmlsaXR5IHRl c3QuIEkgdGhpbmsgd2Ugc2hvdWxkIGNvbnNpZGVyIGJvdGggdGltZSByZXF1aXJlZCBmb3IgbWVy Z2luZyBkcmFmdHMgYW5kIHNoYXBlIG9mIGRvY3VtZW50Lg0KDQpCZXN0IHJlZ2FyZHMsDQpZdWlj aGkNCigyMDEyLzExLzAyIDIzOjAxKSwgTWFydGluIEhldXNzZSB3cm90ZToNCg0KSSdtIHN0YW5k aW5nIGZvciBvcHRpb24gMiAoTE9BRG5nKS4NCg0KSSB0aGluayBpdCdzIGJldHRlciB0byBhZ3Jl ZSBmaXJzdCBvbiBhIHNpbXBsZSBiYXNpYyAodmVyc2F0aWxlPykgcHJvdG9jb2wgYmVmb3JlIHBy b3Bvc2luZyBleHRlbnNpb25zIHRvIGl0OyBpbnN0ZWFkIG9mIHN0YXJ0aW5nIGZyb20gYSBjb2xs ZWN0aW9uIG9mIGlkZWFzIHRoYXQgY2FuIGJlIHVzZWQgb3Igbm90IChhbmQgd2Uga25vdyB0b2Rh eSB3aGF0IGFyZSB0aGUgb3B0aW9ucywgdGhhbmsgdG8gdGhlIGh1Z2UgYW1vdW50IG9mIHdvcmsg ZG9uZSBvbiByZWFjdGl2ZSByb3V0aW5nIGR1cmluZyB0aGUgcGFzdCB5ZWFycykuIENvbnZlcnNl bHksIGl0IHdvdWxkIGJlIGNlcnRhaW5seSBlYXNpZXIgdG8gcmVhY2ggYSBjb25zZW5zdXMgb24g YSBzZXQgb2YgdmFyaWFudHMgYnV0IHdlIG5lZWQgYSBnb29kIHJlZmVyZW5jZSBwb2ludCwgZmly c3QuDQoNCk1vcmVvdmVyLCByZWFjdGl2ZSByb3V0aW5nIGlzIG1vc3QgcHJvYmFibHkgdGhlIGFw cHJvYWNoIHRoYXQgb25lIHdvdWxkIHBpY2sgZm9yIGEgc2ltcGxlIGNhc2UuIFNvIGl0IHNob3Vs ZCBiZSBzaW1wbGUuLi4NCg0KTWFydGluDQoNCg0KTGUgMiBub3YuIDIwMTIgw6AgMDE6NTgsIEpv eWRlZXAgVHJpcGF0aGkgYSDDqWNyaXQgOg0KDQpJIGNhbiB1bmRlcnN0YW5kIHRoYXQgZm9yIGFu IExMTiBpdCBtYXkgYmUgYmVuZWZpY2lhbCBmb3Igbm90IG1haW50YWluaW5nIGEgcHJlY3Vyc29y IGxpc3Qgb3IgaGF2aW5nIG9ubHkgdGhlIGRlc3RpbmF0aW9uIHJlcGx5IHQgbyBhIFJSRVEsIHRo ZXJlIGNhbiBiZSAoYW5kIGFyZSkgb3RoZXIgaW5zdGFuY2VzIG9mIE1BTkVUcyB3aGVyZSBoYXZp bmcgdGhlIG9wdGlvbiBvZiBwcmVjdXJzb3IgbGlzdCB3aWxsIGNvbWUgaGFuZHkuIFRoaXMgY2Fu IHNhdmUgb24gY29udHJvbCBvdmVyaGVhZCwgdXNpbmcgc29tZSBzdG9yYWdlIHNwYWNlIGluIHRo ZSBub2RlLiBMT0FELW5nLCBpbiBtb3N0IGNhc2VzIGRvZXMgbm90IHByb3ZpZGUgdGhpcyBmbGV4 aWJpbGl0eSB0byB0aGUgZGV2ZWxvcGVyIHRvIGNob3NlIGJldHdlZW4gb3B0aW9ucyBmb3Igc3Bl Y2lmaWMgZGVwbG95bWVudC4gU29tZSBNQU5FVCBkZXBsb3ltZW50IG1heSBiZSBsZXNzIGhhcnNo IHRoYW4gb3RoZXJzIGluIG5hdHVyZS4gSGVuY2UsIEFPRFZ2MiBoYXZpbmcgbW9yZSBvcGVuIG9w dGlvbnMgdGhhbiBMT0FELW5nLCBpbiBtb3N0IGNhc2VzLCBzZWVtIGJlbmVmaWNpYWwgdG8gbWUu DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5l dCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KDQotLQ0KSGl0YWNo aSwgTHRkLiwgWW9rb2hhbWEgUmVzZWFyY2ggTGFib3JhdG9yeQ0KSUdBUkFTSEkgWXVpY2hpDQpN YWls77yaIHl1aWNoaS5pZ2FyYXNoaS5oYkBoaXRhY2hpLmNvbTxtYWlsdG86eXVpY2hpLmlnYXJh c2hpLmhiQGhpdGFjaGkuY29tPg0KVGVsIO+8miArODEtKDApNDUtODYwLTMwODMNCkZBWCDvvJog KzgxLSgwKTQ1LTg2MC0xNjczDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFu ZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0 DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQg bWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0K bWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQoNCg0K --_000_03B78081B371D44390ED6E7BADBB4A772204D666xmbrcdx02ciscoc_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCkhpICZxdW90O0pvbiZxdW90Ow0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+WW91IGNhbiBrZWVwIGlnbm9yaW5nIHdoYXQgSSBhbSB3cml0aW5nIOKA piBidXQgdGhpcyBkb2VzIG5vdCBoZWxwLiBUaGUgaXNzdWUgaXMgbm90ICZxdW90O3RoaXMmcXVv dDsgcGFyYWdyYXBoIC0gSSBleHBsYWluZWQgd2h5IGEgbnVtYmVyIG9mIHRpbWVzLjwvZGl2Pg0K PGRpdj5BbmQgcHJvcG9zZWQgYSB3YXkgdG8gZ28sIGNhbGwgaXQgb3B0aW9uIDEuNS48L2Rpdj4N CjxkaXY+PGJyPg0KPGRpdj4NCjxkaXY+T24gTm92IDIsIDIwMTIsIGF0IDQ6NDkgUE0sIEpvbiBC bGFjayB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjojMDAw OyBiYWNrZ3JvdW5kLWNvbG9yOiNmZmY7IGZvbnQtZmFtaWx5OnRpbWVzIG5ldyByb21hbiwgbmV3 IHlvcmssIHRpbWVzLCBzZXJpZjtmb250LXNpemU6MTJwdCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDogNDBweDsiPjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkOyI+RnJvbTo8L3Nw YW4+PC9iPiBKUCBWYXNzZXVyIChqdmFzc2V1cikgJmx0OzxhIGhyZWY9Im1haWx0bzpqdmFzc2V1 ckBjaXNjby5jb20iPmp2YXNzZXVyQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGJyPg0KT24gTm92 IDIsIDIwMTIsIGF0IDExOjA4IEFNLCBVbHJpY2ggSGVyYmVyZyB3cm90ZTo8YnIgY2xhc3M9Inlp djQ0MjExMDU0QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sIG5ldyB5b3JrLCB0aW1lcywgc2VyaWY7IGZv bnQtc2l6ZTogMTJwdDsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IHRpbWVzIG5ldyByb21h biwgbmV3IHlvcmssIHRpbWVzLCBzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQo8ZGl2IGlkPSJ5 aXY0NDIxMTA1NCI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVm dDogNDBweDsiIHR5cGU9ImNpdGUiPg0KPGRpdj5JIHRoaW5rIG9uZSBrZXkgcG9pbnQgdG8gc3Ry ZXNzIGlzIG9uZSB0aGF0IENocmlzIG1lbnRpb25lZDo8YnI+DQpCb3RoIHByb3RvY29scyBhcmUg c2ltaWxhciBpbiB0aGVpciBvcGVyYXRpb24gYW5kIHBlcmZvcm1hbmNlLiBTbyBhbnlvbmUgYXJn dWluZyBhZ2FpbnN0IHRoZSBwZXJmb3JtYW5jZSBvZiBMT0FEbmcgaXMgYXV0b21hdGljYWxseSBh bHNvIG5vdCBpbnRlcmVzdGVkIGluIERZTU8uDQo8YnI+DQo8YnI+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OiA0MHB4OyI+PGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDogNDBweDsiPlNlZSBteSBwb2ludCBVbHJpY2gg4oCmIGFuZCBJ IHdyb3RlIGl0IGRvd24gc2V2ZXJhbCB0aW1lcy4gVGhlcmUgYXJlIG1ham9yIGNvbmNlcm5zIGlu IHVzaW5nIExvYWQtbmcgd2l0aCBMTE5zLiBRdW90aW5nIExvYWQtbmc6PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDogNDBweDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6IDQwcHg7Ij4NCjxwcmUgY2xhc3M9InlpdjQ0MjExMDU0bmV3cGFnZSIgc3R5bGU9ImZv bnQtc2l6ZToxZW07bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Y29sb3I6cmdiKDAs IDAsIDApO2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7Zm9udC13ZWlnaHQ6 bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDtsaW5lLWhlaWdodDpub3JtYWw7b3JwaGFuczoy O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3dpZG93czoyO3dvcmQtc3BhY2lu ZzowcHg7Ij48c3BhbiBjbGFzcz0ieWl2NDQyMTEwNTRoMiIgc3R5bGU9ImxpbmUtaGVpZ2h0OjBw dDtkaXNwbGF5OmlubGluZTt3aGl0ZS1zcGFjZTpwcmU7Zm9udC1mYW1pbHk6bW9ub3NwYWNlO2Zv bnQtc2l6ZToxZW07Zm9udC13ZWlnaHQ6Ym9sZDsiPjxoMiBzdHlsZT0ibGluZS1oZWlnaHQ6MHB0 O2Rpc3BsYXk6aW5saW5lO3doaXRlLXNwYWNlOnByZTtmb250LWZhbWlseTptb25vc3BhY2U7Zm9u dC1zaXplOjFlbTtmb250LXdlaWdodDpib2xkOyI+PGEgcmVsPSJub2ZvbGxvdyIgY2xhc3M9Inlp djQ0MjExMDU0c2VsZmxpbmsiIG5hbWU9InNlY3Rpb24tMyIgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNsYXVzZW4tbGxuLWxvYWRuZy0wNiNz ZWN0aW9uLTMiIHN0eWxlPSJjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZTsiPjM8L2E+ LiAgQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnQ8L2gyPjwvc3Bhbj4NCg0KICAgVGhpcyBwcm90b2Nv bDoNCg0KICAgbyAgSXMgYSByZWFjdGl2ZSByb3V0aW5nIHByb3RvY29sIGZvciBNb2JpbGUgQWQg aG9jIE5FVHdvcmtzDQogICAgICAoTUFORVRzKS4NCg0KICAgbyAgSXMgZGVzaWduZWQgdG8gd29y ayBpbiBuZXR3b3JrcyB3aXRoIGR5bmFtaWMgdG9wb2xvZ3kgaW4gd2hpY2ggdGhlDQogICAgICBs aW5rcyBtYXkgYmUgbG9zc3kgZHVlIHRvIGNvbGxpc2lvbnMgb3IgdW5zdGFibGUgY2hhbm5lbC4g IFRoZSB1c2UNCiAgICAgIGNhc2VzIGluY2x1ZGUgdmVoaWN1bGFyIG5ldHdvcmtzLCBsb3cgcG93 ZXIgYW5kIGxvc3N5IG5ldHdvcmtzLA0KICAgICAgY29tbXVuaXR5IG5ldHdvcmtzLCBtaWxpdGFy eSBuZXR3b3JrcywgZGlzYXN0ZXIgcmVjb3ZlcnkgbmV0d29ya3MsDQogICAgICBldGMuDQo8L3By ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgaXMgd2hlcmUgSSBzdHJvbmdseSBvYmpl Y3QsIGFzIHNldmVyYWwgb3RoZXIgb25lcyBvbiB0aGlzIG1haWxpbmcgbGlzdC4gT25lIGNhbm5v dCBzaW1wbHkgZm9yZ2V0IDQtNSB5ZWFycyBvZiBoYXJkIHdvcmsgZnJvbSBhIFdHIHRoYXQgZm9j dXNzZWQmbmJzcDs8L2Rpdj4NCjxkaXY+b24gdGhpcyB1c2UgY2FzZSZuYnNwO2FuZCBjb25jbHVk ZWQgdGhhdCBzdWNoIHByb3RvY29sIGlzIG5vdCBhcHBsaWNhYmxlIHRvIExMTnMuPGJyPg0KPGJy Pg0KPC9kaXY+DQo8L2Rpdj4NCltKb25dIElzIHRoYXQgeW91ciB0cnVlIG9iamVjdGlvbiB0byB0 aGUgTE9BRG5nIGRyYWZ0LiZuYnNwOyBUaGVuIEkgd291bGQgdGhpbmsgdGhlIHNpbXBsZSBzb2x1 dGlvbiBpcyB0byByZW1vdmUgdGhpcyBvbmUgcGFyYWdyYXBoIGFuZCBtb3ZlIG9uLiZuYnNwOw0K PGJyPg0KRGV2ZWxvcGVycyB3aWxsJm5ic3A7IGRlY2lkZSB3aGF0IHByb3RvY29scyBhcmUgYXBw bGljYWJsZSB0byB0aGVpciBhcHBsaWNhdGlvbiBhcyB0aGV5IHNob3VsZCAtIGFzIEkgd2lsbC48 YnI+DQpJIHdpbGwgYXNrIGluIFJPTEwgd2hlcmUgdGhlIGNvbmNsdXNpb24gd2FzIGRyYXduIHRo YXQgeW91IGNhbm5vdCBwb3NzaWJseSB1c2UgYSByZWFjdGl2ZSBwcm90b2NvbCBpbiBhbnkgTExO IGFwcGxpY2F0aW9uLiZuYnNwOyBUaGF0IGlzIGZvciBhIGRpc2N1c3Npb24gaW4gUk9MTCBub3Qg aGVyZS48YnI+DQpBZ2FpbiBpZiB0aGlzIG9uZSBwYXJhZ3JhcGggaXMgYWxsIHRoZSBmdXNzIHRo ZW4gbGV0cyBwbGVhc2UgcmVhY2ggY29uc2Vuc3VzIHRvIHJlbW92ZSB0aGlzIGFuZCBtb3ZlIGZv cndhcmQuJm5ic3A7IEdvc2ggdGhhdCBzZWVtcyBzaW1wbGUuPGJyPg0KPGJyPg0KSm9uPGJyPg0K PGRpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 OiA0MHB4OyI+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDogNDBweDsiPjxicj4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pkhvd2V2ZXIsIExPQURuZyBpcyBm YXIgY2xvc2VyIHRvIGJlY29tZSBhbiBSRkMgaW4gdGVybXMgb2YgdGhlIGRvY3VtZW50IHF1YWxp dHkuIElmIHdlIHN0YXJ0IHRoZSBuZXcgcmVhY3RpdmUgcHJvdG9jb2wgb24gdGhlIGJhc2lzIG9m IHRoZSBMT0FEbmcgZHJhZnQgKGFuZCBJIHBlcnNvbmFsbHkgZG9uJ3QgY2FyZSB3aGF0IHdlIG5h bWUgdGhhdCBwcm90b2NvbCBpcyksIHdlIGNhbiBjb250aW51ZSB0aGUgd29yayBvbiB0aGUgcmVh Y3RpdmUNCiBwcm90b2NvbCB0b2dldGhlciBhbmQgZGlzY3VzcyB0aGUgbXVsdGlwbGUgb3B0aW9u cyB0aGF0IGFyZSBjdXJyZW50bHkgaW4gRFlNTyBhbmQgc2VlIHdoZXRoZXIgdGhleSBzaG91bGQg YmUgZGlzY2FyZGVkLCBwdXQgaW50byBhIGNvbXBhbmlvbiBkb2N1bWVudCBvciBpbiB0aGUgY29y ZSBzcGVjLg0KPGJyPg0KPGJyPg0KQmVzdDxicj4NClVscmljaDxicj4NCjxicj4NCk9uIE5vdiAy LCAyMDEyLCBhdCA3OjU0LCBZdWljaGkgSUdBUkFTSEkgJmx0OzxhIHJlbD0ibm9mb2xsb3ciIHlt YWlsdG89Im1haWx0bzp5dWljaGkuaWdhcmFzaGkuaGJAaGl0YWNoaS5jb20iIHRhcmdldD0iX2Js YW5rIiBocmVmPSJtYWlsdG86eXVpY2hpLmlnYXJhc2hpLmhiQGhpdGFjaGkuY29tIj55dWljaGku aWdhcmFzaGkuaGJAaGl0YWNoaS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj5IaSw8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5JIGFn cmVlIHdpdGggTWFydGluIGFuZCBJIHdvdWxkIHN1cHBvcnQgb3B0aW9uIDIpIGF0IHRoaXMgc3Rh Z2UuPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJyPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+V2UgTE9BRG5nIGNvLWF1dGhvcnMg bWFkZSBlZmZvcnRzIHRvIHNpbXBsaWZ5IGNvcmUgc3BlY2lmaWNhdGlvbiBvZiB0aGUgcmVhY3Rp dmUgcHJvdG9jb2wgYW5kIHRvIGltcHJvdmUgdGhlIHJlYWRhYmlsaXR5IG9mIHRoZSBkcmFmdC4g SSB0aGluayB0aGlzIGFwcHJvYWNoIGlzIGltcG9ydGFudCBub3Qgb25seSBmb3IgYWxsIGltcGxl bWVudG9yIHRvIHNob3J0ZW4gdGhlIGRldmVsb3BtZW50IHRpbWUsIGJ1dA0KIGFsc28gZm9yIGJ1 c2luZXNzIG9wZXJhdG9ycyB0byBtYWtlIG11bHRpLXZlbmRvciBzeXN0ZW0gZWFzaWVyIHRvIHBy b3ZpZGUuIE9mIGNvdXJzZSwgSSBhZ3JlZSB0aGF0LCBhcyBzZXZlcmFsIHBlcnNvbnMgcG9pbnRl ZCBvdXQsICZxdW90O3RoaXMgZHJhZnQmcXVvdDsgbWF5IGxpbWl0IHVzZSBjYXNlLiBCdXQgd2Ug bGVhdmUgc3VmZmljaWVudCBzcGFjZSBmb3IgaW1wcm92aW5nIHBlcmZvcm1hbmNlL2FkZGluZyBm dW5jdGlvbnMgYnkgY29tcGFuaW9uIGRyYWZ0cy48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj5JIGFtIHJlYWxseSBjb25jZXJuZWQgYWJvdXQgY29tcGxleGl0eS9kaWZmaWN1bHR5IG9m IGd1YXJhbnRlZWluZyBvZiBpbnRlcm9wZXJhYmlsaXR5LiBJZiB0aGUgcHJvdG9jb2wgYmVjb21l cyBjb21wbGljYXRlZCwgd2UgbmVlZCBtdWNoIHRpbWUobWFueSB5ZWFycz8pIGZvciBpbnRlcm9w ZXJhYmlsaXR5IHRlc3QuIEkgdGhpbmsgd2Ugc2hvdWxkIGNvbnNpZGVyIGJvdGggdGltZSByZXF1 aXJlZCBmb3IgbWVyZ2luZw0KIGRyYWZ0cyBhbmQgc2hhcGUgb2YgZG9jdW1lbnQuPGJyPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJyPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+QmVzdCByZWdhcmRzLDxicj4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPll1aWNoaTxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPigyMDEyLzExLzAyIDIzOjAxKSwgTWFydGluIEhldXNzZSB3cm90 ZTo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+SSdtIHN0YW5kaW5n IGZvciBvcHRpb24gMiAoTE9BRG5nKS48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+SSB0aGluayBpdCdzIGJldHRlciB0byBhZ3JlZSBmaXJz dCBvbiBhIHNpbXBsZSBiYXNpYyAodmVyc2F0aWxlPykgcHJvdG9jb2wgYmVmb3JlIHByb3Bvc2lu ZyBleHRlbnNpb25zIHRvIGl0OyBpbnN0ZWFkIG9mIHN0YXJ0aW5nIGZyb20gYSBjb2xsZWN0aW9u IG9mIGlkZWFzIHRoYXQgY2FuIGJlIHVzZWQgb3Igbm90IChhbmQgd2Uga25vdyB0b2RheSB3aGF0 IGFyZSB0aGUgb3B0aW9ucywgdGhhbmsgdG8gdGhlDQogaHVnZSBhbW91bnQgb2Ygd29yayBkb25l IG9uIHJlYWN0aXZlIHJvdXRpbmcgZHVyaW5nIHRoZSBwYXN0IHllYXJzKS4gQ29udmVyc2VseSwg aXQgd291bGQgYmUgY2VydGFpbmx5IGVhc2llciB0byByZWFjaCBhIGNvbnNlbnN1cyBvbiBhIHNl dCBvZiB2YXJpYW50cyBidXQgd2UgbmVlZCBhIGdvb2QgcmVmZXJlbmNlIHBvaW50LCBmaXJzdC48 YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ TW9yZW92ZXIsIHJlYWN0aXZlIHJvdXRpbmcgaXMgbW9zdCBwcm9iYWJseSB0aGUgYXBwcm9hY2gg dGhhdCBvbmUgd291bGQgcGljayBmb3IgYSBzaW1wbGUgY2FzZS4gU28gaXQgc2hvdWxkIGJlIHNp bXBsZS4uLjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJyPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj5NYXJ0aW48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5MZSAyIG5vdi4gMjAx MiDDoCAwMTo1OCwgSm95ZGVlcCBUcmlwYXRoaSBhIMOpY3JpdCA6PGJyPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+SSBjYW4gdW5kZXJzdGFuZCB0aGF0IGZvciBhbiBMTE4gaXQgbWF5IGJlIGJlbmVm aWNpYWwgZm9yIG5vdCBtYWludGFpbmluZyBhIHByZWN1cnNvciBsaXN0IG9yIGhhdmluZyBvbmx5 IHRoZSBkZXN0aW5hdGlvbiByZXBseSB0IG8gYSBSUkVRLCB0aGVyZSBjYW4gYmUgKGFuZCBhcmUp IG90aGVyIGluc3RhbmNlcyBvZiBNQU5FVHMgd2hlcmUgaGF2aW5nIHRoZSBvcHRpb24gb2YgcHJl Y3Vyc29yIGxpc3Qgd2lsbA0KIGNvbWUgaGFuZHkuIFRoaXMgY2FuIHNhdmUgb24gY29udHJvbCBv dmVyaGVhZCwgdXNpbmcgc29tZSBzdG9yYWdlIHNwYWNlIGluIHRoZSBub2RlLiBMT0FELW5nLCBp biBtb3N0IGNhc2VzIGRvZXMgbm90IHByb3ZpZGUgdGhpcyBmbGV4aWJpbGl0eSB0byB0aGUgZGV2 ZWxvcGVyIHRvIGNob3NlIGJldHdlZW4gb3B0aW9ucyBmb3Igc3BlY2lmaWMgZGVwbG95bWVudC4g U29tZSBNQU5FVCBkZXBsb3ltZW50IG1heSBiZSBsZXNzIGhhcnNoIHRoYW4gb3RoZXJzDQogaW4g bmF0dXJlLiBIZW5jZSwgQU9EVnYyIGhhdmluZyBtb3JlIG9wZW4gb3B0aW9ucyB0aGFuIExPQUQt bmcsIGluIG1vc3QgY2FzZXMsIHNlZW0gYmVuZWZpY2lhbCB0byBtZS48YnI+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPm1hbmV0IG1haWxpbmcgbGlzdDxicj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PGEgcmVsPSJub2ZvbGxvdyIgeW1haWx0bz0ibWFpbHRvOm1hbmV0QGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayIgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRm Lm9yZzwvYT48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxhIHJlbD0ibm9mb2xsb3ciIHRh cmdldD0iX2JsYW5rIiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21hbmV0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxi cj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+LS0gPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+SGl0YWNoaSwgTHRkLiwgWW9rb2hhbWEgUmVzZWFyY2ggTGFib3JhdG9yeTxicj4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPklHQVJBU0hJIFl1aWNoaTxi cj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPk1haWzvvJogPGEgcmVs PSJub2ZvbGxvdyIgeW1haWx0bz0ibWFpbHRvOnl1aWNoaS5pZ2FyYXNoaS5oYkBoaXRhY2hpLmNv bSIgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9Im1haWx0bzp5dWljaGkuaWdhcmFzaGkuaGJAaGl0YWNo aS5jb20iPg0KeXVpY2hpLmlnYXJhc2hpLmhiQGhpdGFjaGkuY29tPC9hPjxicj4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPlRlbCDvvJogJiM0Mzs4MS0oMCk0NS04NjAt MzA4Mzxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPkZBWCDvvJog JiM0Mzs4MS0oMCk0NS04NjAtMTY3Mzxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+bWFuZXQgbWFpbGlu ZyBsaXN0PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGEgcmVs PSJub2ZvbGxvdyIgeW1haWx0bz0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayIgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YSByZWw9Im5vZm9sbG93IiB0 YXJnZXQ9Il9ibGFuayIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tYW5ldCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48 YnI+DQo8L2Jsb2NrcXVvdGU+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4NCjxhIHJlbD0ibm9mb2xsb3ci IHltYWlsdG89Im1haWx0bzptYW5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9Im1h aWx0bzptYW5ldEBpZXRmLm9yZyI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxtZXRhIGh0dHAtZXF1aXY9IngtZG5z LXByZWZldGNoLWNvbnRyb2wiIGNvbnRlbnQ9Im9uIj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJy Pg0KPGEgeW1haWx0bz0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiBocmVmPSJtYWlsdG86bWFuZXRA aWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxicj4NCjxicj4NCjxicj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_03B78081B371D44390ED6E7BADBB4A772204D666xmbrcdx02ciscoc_-- From jvasseur@cisco.com Sat Nov 3 01:18:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F7D21F9495 for ; Sat, 3 Nov 2012 01:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.398 X-Spam-Level: X-Spam-Status: No, score=-10.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnXKh11LK9zK for ; Sat, 3 Nov 2012 01:18:09 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C979421F842B for ; Sat, 3 Nov 2012 01:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19489; q=dns/txt; s=iport; t=1351930688; x=1353140288; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UPTHCPR8Fl1/CIlNCxmAkuQ6TDhaELjIlKrxMXiOz8k=; b=IDGk6iuvqe6m/D7iYpiQToEPXbBYMVnXGBC00/9qSSBs+1P0gd44QiBN nk/s+pbtZUtyevzYJPDdM49oBJHXNJmeTpCRVSNpejZYPCxhl3PPx36oX faJqNh6P9IGkMit9wWXV9APbEd/GEab0dzbJnfwRiJ81YciOot/2Ttc+7 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKTSlFCtJXHA/2dsb2JhbAAqGoJJwGqBCIIeAQEBBBIBZhACAQgOBw0LEgcyFBECBA4FCBqHaAstm1WfeIwBFQaCcIJQYQOXF409gWuCb3JqCBce X-IronPort-AV: E=Sophos;i="4.80,704,1344211200"; d="scan'208,217";a="138413357" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 03 Nov 2012 08:18:08 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA38I82p021844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 08:18:08 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 03:18:07 -0500 From: "JP Vasseur (jvasseur)" To: Jon Black Thread-Topic: [manet] LOADng works Thread-Index: AQHNuF9dW2UMul6sMEaXNf6TARakEQ== Date: Sat, 3 Nov 2012 08:18:06 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204D692@xmb-rcd-x02.cisco.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C845@xmb-rcd-x02.cisco.com> <1351891402.40332.YahooMailNeo@web160605.mail.bf1.yahoo.com> In-Reply-To: <1351891402.40332.YahooMailNeo@web160605.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.169] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--55.665500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204D692xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 08:18:10 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204D692xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Once again you always restart from scratch ignoring emails - I was providin= g you the rationale on why you cannot use one deployment of LLN (not even knowing any details) to claim that the protocol= actually works, this is in reply to Ulrich's email. If indeed, MANET designs a reactive routing protocol for MANET including LL= Ns, since it was (finally) said that this could work in very specific (restrained) conditions, otherwise we would need to use th= e protocol the IETF has designed for LLN (RFC6550 and companion) then let's specifically remove LLN (not implicitly, by remov= ing a section or chaining a name) from the protocol designed in MANET, and use that protocol (RFC6550) for LLNs. On Nov 2, 2012, at 5:23 PM, Jon Black wrote: see line [Jon] ________________________________ From: JP Vasseur (jvasseur) > Hi Ulrich, On Nov 2, 2012, at 1:22 PM, Ulrich Herberg wrote: JP, On Fri, Nov 2, 2012 at 10:09 AM, JP Vasseur (jvasseur) > wrote: On Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote: >>>> JP> This is not just a question of "how large" it is =85 but also how >>>> dynamic. I could show you few hundreds (if not less number of nodes) >>>> not working if the traffic pattern is too dynamic. This is a >>>> fundamental problem. > > No, it is a fundamental and well-known characteristic of reactive > routing protocols. It is a problem only when this behavior doesn't > match the characteristics of the network in which the reactive routing > protocol is deployed. JP> Indeed =85 and this is why you have a fundamental issue with you have e= xtremely high BER, PDR, low bandwidth =85 as we do in LLNs. Flooding in these networks is driven by= user traffic and of course is highly undesirable. Slightly increase the use traffic and you will see t= he impact on the control plane ... Yes, but as Timothy mentioned, there are cases where you don't have much us= er traffic. JP> Then if you recognize that reactive routing is an issue when user traff= ic increases, this is a good start. When do you put the limit ? By the way, the topology is another argument, so does the bandwidth. Let me be even more specific: * Case 1: 75KBits/s, P2MP traffic (not referring to multicast), small broad= cast domains, meter readout every 24h. Certainly you can deploy a reactive routing protocol ? Still I do not see w= hy you would not use a pro-active routing but this is another question Now what if you move to case 2: * Unsolicited alarms using meters, DA, EV traffic for bill roaming ? Well y= ou do not have a major problem and when designing protocol we need to take this into accou= nt. Please see RFC RFC 5548 (draft-ietf-roll-urban-routing-reqs) Routing Requirements for Urban Low-Pow= er and Lossy Networks 2009-05 RFC 5548 (Informational) = Adrian Farrel RFC 5673 (draft-ietf-roll-indus-routing-reqs) Industrial Routing Requirements in Low= -Power and Lossy Networks 2009-10 RFC 5673 (Informational) = Adrian Farrel RFC 5826 (draft-ietf-roll-home-routing-reqs) Home Automation Routing Requirements in Low-Po= wer and Lossy Networks 2010-04 RFC 5826 (Informational) Errata = Adrian Farrel RFC 5867 (draft-ietf-roll-building-routing-reqs) Building Automation Routing Requiremen= ts in Low-Power and Lossy Networks 2010-06 RFC 5867 (Informational) [Jon] Which RFC? Do you mean RFC 5826 or 5867 both of which seem to need R= PL P2P which looks like a new protocol? Do you mean RFC 5548 which seems t= o be the use case from EDF that is using a reactive protocol (LOADng), or R= FC5673 which no one has tried. Just because something was designed to do something you can't claim that it= actually will do it. The Titanic was designed to be unsinkable... But I = digress, since you did. It does appear that your objection is the name ('cause it could confuse som= eone into think they could use this manet protocol in an LLN - which as you= said was their choice) and that there is one small paragraph there it says= that they might be able to use this protocol in their LLN. Really, this is what all the hub-bub is about. After all they really are b= oth AODV++. So we find a new name and remove one paragraph. I think now the debate is what is the proper base from which to start. Whi= ch document is clearer, and more stable. Jon --_000_03B78081B371D44390ED6E7BADBB4A772204D692xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <500FD572FF096B4D9D18749EEE925624@cisco.com> Content-Transfer-Encoding: quoted-printable Once again you always restart from scratch ignoring emails - I was providin= g you the rationale on why you cannot use one
deployment of LLN (not even knowing any details) to claim that the pro= tocol actually works, this is in reply to Ulrich's email.
If indeed, MANET designs a reactive routing protocol for MANET includi= ng LLNs, since it was (finally) said that this could work 
in very specific (restrained) conditions, otherwise we would need to u= se the protocol the IETF has designed for LLN (RFC6550 
and companion) then let's specifically remove LLN (not implicitly= , by removing a section or chaining a name) from the protocol 
designed in MANET, and use that protocol (RFC6550) for LLNs.

On Nov 2, 2012, at 5:23 PM, Jon Black wrote:

see line [Jon]


From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>

Hi Ulrich,

On Nov 2, 2012, at 1:22 PM, Ulrich Herberg wrote:

JP,

On Fri, Nov 2, 2012 at 10:09 AM, JP= Vasseur (jvasseur) <jvasseur@cisco.co= m> wrote:

On Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote:

>>>> JP> This is not just a question of "how large"= ; it is =85 but also how
>>>> dynamic. I could show you few hundreds (if not less number= of nodes)
>>>> not working if the traffic pattern is too dynamic. This is= a
>>>> fundamental problem.
>
> No, it is a fundamental and well-known characteristic of reactive
> routing protocols.  It is a problem only when this behavior doesn= 't
> match the characteristics of the network in which the reactive routing=
> protocol is deployed.

JP> Indeed =85 and this is why you have a fundamental issue with you hav= e extremely high BER, PDR,
low bandwidth =85 as we do in LLNs. Flooding in these networks is driven by= user traffic and of course
is highly undesirable. Slightly increase the use traffic and you will see t= he impact on the control plane ...


Yes, but as Timothy mentioned, there are cases where you don't have mu= ch user traffic.

JP> Then if you recognize that reactive routing is an issue when us= er traffic increases, this is a good start.
When do you put the limit ?
By the way, the topology is another argument, so does the bandwidth.

Let me be even more specific:
* Case 1: 75KBits/s, P2MP traffic (not referring to multicast), small = broadcast domains, meter readout every 24h.
Certainly you can deploy a reactive routing protocol ? Still I do not = see why you would not use a pro-active routing 
but this is another question
Now what if you move to case 2:
* Unsolicited alarms using meters, DA, EV traffic for bill roaming ? W= ell you do not have
a major problem and when designing protocol we need to take this into = account. Please see RFC

RFC 5548 
(draft-ietf-roll-urban-routing-reqs= )		 Routing Requirements for Urban Low-Power and Lossy Networks 2009-05 RFC 5548 (Informational) Adrian Farrel
RFC 5673 
(draft-ietf-roll-indus-routing-reqs= )		 Industrial Routing Requirements in Low-Power and Lossy Networks 2009-10 RFC 5673 (Informational) Adrian Farrel
RFC 5826 
(draft-ietf-roll-home-routing-reqs)		 Home Automation Routing Requirements in Low-Power and Lossy Networks 2010-04 RFC 5826 (Informational) 
Errata		 Adrian Farrel
RFC 5867 
(draft-ietf-roll-building-routin= g-reqs)		 Building Automation Routing Requirements in Low-Power and Lossy Networks 2010-06 RFC 5867 (Informational)

[Jon] Which RFC?  Do you mean RFC 5826 or 5867 both of which seem to n= eed RPL P2P which looks like a new protocol?  Do you mean RFC 5548 whi= ch seems to be the use case from EDF that is using a reactive protocol (LOA= Dng), or RFC5673 which no one has tried.

Just because something was designed to do something you can't claim that it= actually will do it.  The Titanic was designed to be unsinkable...&nb= sp; But I digress, since you did.

It does appear that your objection is the name ('cause it could confuse som= eone into think they could use this manet protocol in an LLN - which as you= said was their choice) and that there is one small paragraph there it says= that they might be able to use this protocol in their LLN.

Really, this is what all the hub-bub is about.  After all they really = are both AODV++.  So we find a new name and remove one paragra= ph.

I think now the debate is what is the proper base from which to start. = ; Which document is clearer, and more stable.

Jon





--_000_03B78081B371D44390ED6E7BADBB4A772204D692xmbrcdx02ciscoc_-- From jvasseur@cisco.com Sat Nov 3 01:22:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29ED21F9CA2 for ; Sat, 3 Nov 2012 01:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.407 X-Spam-Level: X-Spam-Status: No, score=-10.407 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NENYawiNAsiT for ; Sat, 3 Nov 2012 01:22:33 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7F40221F9C95 for ; Sat, 3 Nov 2012 01:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8005; q=dns/txt; s=iport; t=1351930953; x=1353140553; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SLzzeizy/BfUSXbUddrrQrW1X3pOaE6JAigLNhFRGVI=; b=VPr4wm2bm5S/b8/2+RelrFWaN3BrIhPYOzjq01QxsKZn5cwOJA1Wrq0U 0CBiOV+riXbdG18H/vWgz54y65vEt73oLGyr1H86inS5VPxzccpmPTIlh dSP0tk2cW9oD0ipVcmCL5Wvh3go/R9v27oVkN/duICNrw+wcB1xeKYYWB k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKTSlFCtJV2Y/2dsb2JhbABEgknAaoEIgh4BAQEDAQEBAQ8BWwsFCwIBCA4DBAEBAQodBycLFAkIAgQOBQgah1YDCQYLnAKWFw2JUASLGWiFW2EDpFSBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,704,1344211200"; d="scan'208,217";a="138445670" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 03 Nov 2012 08:22:32 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA38MVlq003375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 08:22:31 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 03:22:31 -0500 From: "JP Vasseur (jvasseur)" To: Jon Black Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuRrYLPVi/cSo/ES1hdb7zda62w== Date: Sat, 3 Nov 2012 08:22:30 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204D6E0@xmb-rcd-x02.cisco.com> References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C638@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C877@xmb-rcd-x02.cisco.com> <1351891556.24614.YahooMailNeo@web160604.mail.bf1.yahoo.com> In-Reply-To: <1351891556.24614.YahooMailNeo@web160604.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.169] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--44.204900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204D6E0xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 08:22:34 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204D6E0xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry but you missed the point. These were examples of routing protocols no= t affected by the user traffic since you assessment was technically completely incorrect. Please read RFC6550: RPL is not a collect= ion tree, but build DAGs (this is a very different mathematical construct), potentially multiple DAGs (instances) and yes there is a P2P ve= rsion. Even in storing mode, P2P is supported. You only need to read the introduction to get this information. Anyway, let's move on, this is not the mailing list for this discussion. Time to move on =85 On Nov 2, 2012, at 5:25 PM, Jon Black wrote: Strange that you would lump RPL with OSPF and BGP. RPL is a collection tre= e. It is a tree. It is great for MP2P as are all collection trees. It is= less great for P2MP and rather poor for P2P. But this debate should go to ROLL, not here. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Henning Rogge > Cc: "manet@ietf.org" > Sent: Friday, November 2, 2012 11:39 AM Subject: Re: [manet] Reactive Protocol Situation On Nov 2, 2012, at 1:22 PM, Henning Rogge wrote: > On Fri, Nov 2, 2012 at 6:18 PM, JP Vasseur (jvasseur) > > wrote: >>>> This is where I strongly object, as several other ones on this mailing= list. >>>> One cannot simply forget 4-5 years of hard work from a WG that focusse= d >>>> on this use case and concluded that such protocol is not applicable to= LLNs. >>> >>> This argument doesn't make any sense at all. >> >> JP> Why ? If MANET standardize a protocol with an applicability statemen= t related to the work >> of another WG, it does make perfect sense, =85 This is precisely why we = have charters. > > And Charters overlap... just look for RFC 5614 as an example. > > By your own words the effectiveness/overhead of LoadNG in LLNs > compared to other protocols will most likely depend on the traffic > patterns (which is also true for most other routing protocols, > especially Ripple). JP> This is technically incorrect - RPL/OSPF/BGP =85 performances are not d= irectly a function of the user traffic. > > Well, if this is true then it will be a GOOD thing to have LoadNG > standardized so people can choose the better protocol for their > use-case. > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204D6E0xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3DF7F27CAD638B4893559EDA715EA02E@cisco.com> Content-Transfer-Encoding: quoted-printable Sorry but you missed the point. These were examples of routing protocols no= t affected by the user traffic since you assessment was
technically completely incorrect. Please read RFC6550: RPL is not a co= llection tree, but build DAGs (this is a very different mathematical
construct), potentially multiple DAGs (instances) and yes there is a P= 2P version. Even in storing mode, P2P is supported. You only need
to read the introduction to get this information.

Anyway, let's move on, this is not the mailing list for this discussio= n.

Time to move on =85

On Nov 2, 2012, at 5:25 PM, Jon Black wrote:

Strange that you would lump RPL with OSPF and BGP.  RPL is a collectio= n tree.  It is a tree.  It is great for MP2P as are all collectio= n trees.  It is less great for P2MP and rather poor for P2P.

But this debate should go to ROLL, not here.

Jon


From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Henning Rogge <hrogge@googlemail.com>
Cc: "manet@ietf.org" <manet@ietf.org>
Sent: Friday, November 2, = 2012 11:39 AM
Subject: Re: [manet] React= ive Protocol Situation


On Nov 2, 2012, at 1:22 PM, Henning Rogge wrote:

> On Fri, Nov 2, 2012 at 6:18 PM, JP Vasseur (jvasseur)
> <jvasseur@cisco.com> wrote:
>>>> This is where I strongly object, as several other ones on = this mailing list.
>>>> One cannot simply forget 4-5 years of hard work from a WG = that focussed
>>>> on this use case and concluded that such protocol is not a= pplicable to LLNs.
>>>
>>> This argument doesn't make any sense at all.
>>
>> JP> Why ? If MANET standardize a protocol with an applicability= statement related to the work
>> of another WG, it does make perfect sense, =85 This is precisely w= hy we have charters.
>
> And Charters overlap... just look for RFC 5614 as an example.
>
> By your own words the effectiveness/overhead of LoadNG in LLNs
> compared to other protocols will most likely depend on the traffic
> patterns (which is also true for most other routing protocols,
> especially Ripple).

JP> This is technically incorrect - RPL/OSPF/BGP =85 performances are no= t directly a function
of the user traffic.

>
> Well, if this is true then it will be a GOOD thing to have LoadNG
> standardized so people can choose the better protocol for their
> use-case.
>
> Henning Rogge
> --
> Steven Hawkings about cosmic inflation: "An increase of billions = of
> billions of percent in a tiny fraction of a second. Of course, that > was before the present government."

_______________________________________________
manet mailing list
manet@i= etf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



--_000_03B78081B371D44390ED6E7BADBB4A772204D6E0xmbrcdx02ciscoc_-- From jvasseur@cisco.com Sat Nov 3 01:25:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10DC21F9C9E for ; Sat, 3 Nov 2012 01:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.517 X-Spam-Level: X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbNtLvIZhnqO for ; Sat, 3 Nov 2012 01:25:16 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C78FC21F9C9D for ; Sat, 3 Nov 2012 01:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7601; q=dns/txt; s=iport; t=1351931115; x=1353140715; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/oSP4lW6ZodG4xzqBEXs/+VgigPQOM/p+8tMgtKMsys=; b=l9yB1atBRvVP1ECJbcd062gBsr6nUXuEpbWf1QRkOQVFJkRCfdxQ4MP2 nCfyC5vppzqpOxcR7lLgMTUlclodqQ2My+U2fmsAIdN4YIzvNLYqnUlEk WIoYHMglBaEgMdTVEe+E5fI9kiq2vPxi6NLYQw7ZukYUJHnOcRetsUQML E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALTUlFCtJXHA/2dsb2JhbABEgknAa4EIgh4BAQEDAQEBAQ8BWwsFCwIBCA4DBAEBAQodBycLFAkIAgQOBQgah1YDCQYLnAKWFQ2JUASLGWiFW2EDpFSBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,704,1344211200"; d="scan'208,217";a="138389532" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 03 Nov 2012 08:25:14 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA38PEQq024739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 08:25:14 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 03:25:13 -0500 From: "JP Vasseur (jvasseur)" To: Jon Black Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuRrYLPVi/cSo/ES1hdb7zda62w== Date: Sat, 3 Nov 2012 08:25:12 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204D717@xmb-rcd-x02.cisco.com> References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C638@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C877@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204CB91@xmb-rcd-x02.cisco.com> <1351891740.83248.YahooMailNeo@web160605.mail.bf1.yahoo.com> In-Reply-To: <1351891740.83248.YahooMailNeo@web160605.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.169] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--33.163300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204D717xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 08:25:16 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204D717xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable OK I will stop arguing here -- If I may reread what you wrote, then read RF= C6550 and you will quickly see why you mis-undertood the protocol. Hint: think of DAG rooted at source of traffic, use address aggregation map= ping to topologies, P2P, storing of source routed paths. On Nov 2, 2012, at 5:29 PM, Jon Black wrote: Ah but now you mix apples and oranges. Storing mode is not good for highly= constrained devices (they don't have the memory for storing mode) so for m= any LLNs you are stuck with non-storing mode which is poor with P2MP, but s= till fine with MP2P. And therefore Henning's point is valid. It depends o= n traffic. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Henning Rogge > Cc: "manet@ietf.org" > Sent: Friday, November 2, 2012 12:10 PM Subject: Re: [manet] Reactive Protocol Situation Again your assumption are not correct - look at storing mode with OF to inc= rease connectivity if required, for P2P. But again =85 not appropriate for this list. On Nov 2, 2012, at 6:58 PM, Henning Rogge wrote: > On Fri, Nov 2, 2012 at 6:39 PM, JP Vasseur (jvasseur) > > wrote: >>> By your own words the effectiveness/overhead of LoadNG in LLNs >>> compared to other protocols will most likely depend on the traffic >>> patterns (which is also true for most other routing protocols, >>> especially Ripple). >> >> JP> This is technically incorrect - RPL/OSPF/BGP =85 performances are no= t directly a function >> of the user traffic. > > Ripple is a tree-based routing protocol. > > its really good when sending traffic towards the local root, not as > good (but still good) when sending traffic from the root to its nodes, > bad when you send traffic between two nodes with the same root and > really bad when sending traffic between nodes that are not part of the > same root tree. > > I would say its performance depends on the user traffic pattern. > > The overhead (as a comparison between control plane traffic and data > plane traffic) is of course always different for each protocol > depending on the user traffic. > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204D717xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6E690FE59F3CDA4BA190E891B70158EA@cisco.com> Content-Transfer-Encoding: quoted-printable OK I will stop arguing here -- If I may reread what you wrote, then read RF= C6550 and you will quickly see why you mis-undertood the protocol.
Hint: think of DAG rooted at source of traffic, use address aggregatio= n mapping to topologies, P2P, storing of source routed paths.

On Nov 2, 2012, at 5:29 PM, Jon Black wrote:

Ah but now you mix apples and oranges.  Storing mode is not good for h= ighly constrained devices (they don't have the memory for storing mode) so = for many LLNs you are stuck with non-storing mode which is poor with P2MP, = but still fine with MP2P.  And therefore Henning's point is valid.  It depends on traffic.

Jon


From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Henning Rogge <hrogge@googlemail.com>
Cc: "manet@ietf.org" <manet@ietf.org>
Sent: Friday, November 2, = 2012 12:10 PM
Subject: Re: [manet] React= ive Protocol Situation

Again your assumption are not correct - look at storing mode with OF to inc= rease connectivity if required,
for P2P. But again =85 not appropriate for this list.

On Nov 2, 2012, at 6:58 PM, Henning Rogge wrote:

> On Fri, Nov 2, 2012 at 6:39 PM, JP Vasseur (jvasseur)
> <jvasseur@cisco.com> wrote:
>>> By your own words the effectiveness/overhead of LoadNG in LLNs=
>>> compared to other protocols will most likely depend on the tra= ffic
>>> patterns (which is also true for most other routing protocols,=
>>> especially Ripple).
>>
>> JP> This is technically incorrect - RPL/OSPF/BGP =85 performanc= es are not directly a function
>> of the user traffic.
>
> Ripple is a tree-based routing protocol.
>
> its really good when sending traffic towards the local root, not as > good (but still good) when sending traffic from the root to its nodes,=
> bad when you send traffic between two nodes with the same root and
> really bad when sending traffic between nodes that are not part of the=
> same root tree.
>
> I would say its performance depends on the user traffic pattern.
>
> The overhead (as a comparison between control plane traffic and data > plane traffic) is of course always different for each protocol
> depending on the user traffic.
>
> Henning Rogge
> --
> Steven Hawkings about cosmic inflation: "An increase of billions = of
> billions of percent in a tiny fraction of a second. Of course, that > was before the present government."

_______________________________________________
manet mailing list
manet@i= etf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



--_000_03B78081B371D44390ED6E7BADBB4A772204D717xmbrcdx02ciscoc_-- From jvasseur@cisco.com Sat Nov 3 01:26:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7890221F9CB8 for ; Sat, 3 Nov 2012 01:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.415 X-Spam-Level: X-Spam-Status: No, score=-10.415 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2LM5xgiwmD4 for ; Sat, 3 Nov 2012 01:26:29 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6E721F9C9E for ; Sat, 3 Nov 2012 01:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24760; q=dns/txt; s=iport; t=1351931188; x=1353140788; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6riCOVWlvkAAK4dh/byi0CpwY9bam5nlSEUIuqW2mK0=; b=Pa5oy+whtuvedpvs88es2Qo8ptyLqorzDrz9fROWiozzWh36BT5bi/Vz /iJBj5gI/GDQJBI6ULr7BIi43pq+kVXeo8wSihuSa9N84daLY8IBKvf/1 I7RVA7WXd2WyPPXbv01J2BpbzjsBZUyHkZtrzQobjxUn2S4qDswJjcqX/ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAM7TlFCtJXG9/2dsb2JhbABEgkmuQ5IogQiCHgEBAQMBAQEBDwFCFwIIAwULAgEIBwoEAQELHQchBgsTAQkIAgQOBQgWBIdWAwkGC5wClhUNiVSLGWgUhUdhA5QmBI0EgyaBa4JvgVsJFx4 X-IronPort-AV: E=Sophos;i="4.80,704,1344211200"; d="scan'208,217";a="135409889" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 03 Nov 2012 08:26:27 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA38QSN2014385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 08:26:28 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 03:26:27 -0500 From: "JP Vasseur (jvasseur)" To: C Chauvenet Thread-Topic: [manet] A proposal - differentiating the document and the protocol Thread-Index: AQHNuR5uQAldmF7ZtU6krGF1ERjKag== Date: Sat, 3 Nov 2012 08:26:26 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204D73B@xmb-rcd-x02.cisco.com> References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> <1351876587.86080.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204C69E@xmb-rcd-x02.cisco.com> <1351890653.89343.YahooMailNeo@web160603.mail.bf1.yahoo.com> <97B69B30E0EF244B940B65EA541E3F2D21572F63@DBXPRD0510MB395.eurprd05.prod.outlook.com> In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D21572F63@DBXPRD0510MB395.eurprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.169] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--52.693900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204D73Bxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org List" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 08:26:31 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204D73Bxmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Cedrix, Completely agreeing with you; this is what I called option 1+. Thanks. JP. On Nov 2, 2012, at 6:41 PM, C Chauvenet wrote: Hi all, If we add mechanisms to LOADng or prune some from DYMO, we end up with a di= fferent protocol, so I think that we will need to change the name of the re= sulting protocol. I support the AODVv2 naming for the reactive protocol of = MANET, if chairs decide to go forward and do not take option 3). It seems that charlie is working hard on updating the DYMO draft, by addres= sing reviews of the document. These reviews contains most of the improvemen= ts (readability, RFC5444 compliance ....) that people found missing in DYMO= . I think that would make sense to wait for the next update of DYMO before = choosing between LOADng and DYMO. I think that the WG want something good, = rather than something quick. In addition, we would benefit from the work that charlie is currently doing= , rather that skip it if we made a decision based on the actual DYMO versio= n. C=E9dric. Le 2 nov. 2012 =E0 22:10, Jon Black a =E9crit : It is not completely new and it is much more mature. It has been being dev= eloped for quite some time, it has implementations, it has interoperability= . Age of a document is not a good criteria. Something can be written quit= e a long time ago and nothing done on it. Another document/protocol may co= me along, gain critical mass, gain experience and even though younger may b= e a much better starting point. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black >; Ulrich= Herberg >; Abdussalam Bary= un >; "Dearlo= ve, Christopher (UK)" >; "manet@ietf.org List" > Sent: Friday, November 2, 2012 11:21 AM Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol so =85 should we start with a completely new document then ? On Nov 2, 2012, at 1:16 PM, Jon Black wrote: This seems to make good sense. The name should not be issue. We need a go= od solid base to start from. It would appear that if there are working int= eroperable implementation based on the LOADng draft then this indicates tha= t the draft is implementable. Again, having read both I could build someth= ing based on the LOADng draft and I (and I'm only talking for me) couldn't = based on the DYMO draft. I much prefer starting with something simple and understandable and adding = what is missing rather than starting with something more difficult to under= stand trying to remove things that are not needed. Jon ________________________________ From: Ulrich Herberg > To: Abdussalam Baryun > Cc: "Dearlove, Christopher (UK)" >; "manet@ietf.org" > Sent: Friday, November 2, 2012 10:34 AM Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol Hi Abdussalam, there was indeed some hesitance to change the name from some of the authors= (not me). I cannot speak for them here. My intuition is that if the name o= f the protocol is the only factor that avoids the reactive protocol from pr= oceeding in the WG, this can be solved. As far as I can see from the discussions so far, there is a clear consensus= that option 3 is not viable. Now, if we want to proceed with the reactive = document, the question is from which document to start. Chris mentioned tha= t even if we wanted the specification of 100%, it would be far quicker to s= tart from the LOADng draft. I propose that we can start working based on th= e LOADng draft (possibly rename it?), look at each item that is in DYMO and= consider whether and in which way it should be incorporated in the draft. Best Ulrich On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun > wrote: Hi Ulrich, I think that Chris's proposal was not accepted by LOADng co-authors as I un= derstood from following up the WG history (they don't agree to change the n= ame of protocol). As you are one co-author do I understand that you support= the Chris's proposal, AB On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg > wrote: Dear Chris, personally, what you propose makes sense to me. Regards Ulrich On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" > wrote: > Before making a proposal, I'm going to introduce a distinction here betwe= en the DYMO and LOADng documents and protocols. > > I'm of the opinion that the LOADng document is a greatly superior present= ation to the DYMO document. (I'm not really interested in why that has come= about.) > > I think that regardless of whether one makes design decisions favouring D= YMO or LOADng where they differ - and let's not forget they overlap a lot -= it would actually be easier to modify the LOADng document to specify DYMO = than it would be to modify the DYMO document to achieve that. And in practi= ce I think if making decisions it is unlikely that all would favour DYMO ov= er LOADng. > > So what I think would be best for the WG is not a simply "option 1" or ev= en (as it may appear I'm suggesting, but I'm not) "option 2" but rather to= agree to take the LOADng document, and a list of where DYMO and LOADng dif= fer, and thrash out where they do, what the WG reactive protocol should do = - either as a definite choice, or as an option (but not too many options pl= ease- and some could be separate specifications). > > This would not of course be LOADng, so we'd have to change the document n= ame. And there I suggest we have a candidate name - AODVv2. (Which is why I= have recently taken to saying DYMO when referring to that document.) After= all, the one thing we are agreed on is that the protocol being developed i= s derived from AODV. > > The editors of this new document would have to agree that what goes in it= is WG consensus (which should follow proper technical consideration of the= issues). If they found it impossible to have other than their way to do th= ings, they'd have to move on. If that left no one editing it, obviously we = don't have a consensus of people prepared to do the work and option 3 would= win. > > So now I'm partly off the fence I've been sitting on. But only partly. I = haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standar= d, IRREPs as an option in the main draft, IRREPs as a separate draft option= , no IRREPs. I'd like to move on to those discussions. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | htt= p://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > ******************************************************************** > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204D73Bxmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Cedrix,

Completely agreeing with you; this is what I called option 1+.

Thanks.

JP.

On Nov 2, 2012, at 6:41 PM, C Chauvenet wrote:

Hi all, 

If we add mechanisms to LOADng or prune some from DYMO, we end up with= a different protocol, so I think that we will need to change the name of t= he resulting protocol. I support the AODVv2 naming for the reactive protoco= l of MANET, if chairs decide to go forward and do not take option 3).

It seems that charlie is working hard on updating the DYMO draft, by a= ddressing reviews of the document. These reviews contains most of the impro= vements (readability, RFC5444 compliance ....) that people found missing in= DYMO. I think that would make sense to wait for the next update of DYMO before choosing between LOADng and DYM= O. I think that the WG want something good, rather than something quick.&nb= sp;
In addition, we would benefit from the work that charlie is currently = doing, rather that skip it if we made a decision based on the actual DYMO v= ersion.

C=E9dric.

Le 2 nov. 2012 =E0 22:10, Jon Black a =E9crit :

It is not completely new and it is much more mature.  It has been bein= g developed for quite some time, it has implementations, it has interoperab= ility.  Age of a document is not a good criteria.  Something can = be written quite a long time ago and nothing done on it.  Another document/protocol may come along, gain critical mass,= gain experience and even though younger may be a much better starting poin= t.

Jon

From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>; Ulrich Herberg <ulrich@herberg.name>; Abdussalam Baryun <abdussalambaryun@gmail.com>; "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>; "manet@ietf.org List" <manet@ietf.org>
Sent: Friday, November 2, = 2012 11:21 AM
Subject: Re: [manet] A pro= posal - differentiating the document and the protocol

so =85 should we start with a completely new document then ?

On Nov 2, 2012, at 1:16 PM, Jon Black wrote:

This seems to make good sense.  The name should not be issue.  We= need a good solid base to start from.  It would appear that if there = are working interoperable implementation based on the LOADng draft then thi= s indicates that the draft is implementable.  Again, having read both I could build something based on the LOADng draft and I (= and I'm only talking for me) couldn't based on the DYMO draft.

I much prefer starting with something simple and understandable and adding = what is missing rather than starting with something more difficult to under= stand trying to remove things that are not needed.

Jon


From: Ulrich Herberg <ulrich@herberg.name>
To: Abdussalam Baryun <<= a rel=3D"nofollow" ymailto=3D"mailto:abdussalambaryun@gmail.com" target=3D"= _blank" href=3D"mailto:abdussalambaryun@gmail.com">abdussalambaryun@gmail.c= om>
Cc: "Dearlove, Christo= pher (UK)" <Chris.Dearlove@baesystems.com>; "manet@ietf.org" <manet@ietf.org>
Sent: Friday, November 2, 2= 012 10:34 AM
Subject: Re: [manet] A prop= osal - differentiating the document and the protocol

Hi Abdussalam,

there was indeed some hesitance to change the name from some of the au= thors (not me). I cannot speak for them here. My intuition is that if the n= ame of the protocol is the only factor that avoids the reactive protocol fr= om proceeding in the WG, this can be solved.

As far as I can see from the discussions so far, there is a clear cons= ensus that option 3 is not viable. Now, if we want to proceed with the reac= tive document, the question is from which document to start. Chris mentione= d that even if we wanted the specification of 100%, it would be far quicker to start from the LOADng draft. I pr= opose that we can start working based on the LOADng draft (possibly re= name it?), look at each item that is in DYMO and consider whether and in wh= ich way it should be incorporated in the draft. 

Best
Ulrich



On Fri, Nov 2, 2012 at 9:17 AM, Abd= ussalam Baryun <a= bdussalambaryun@gmail.com> wrote:
Hi Ulrich,
 
I think that Chris's proposal was not accepted by LOADng co-autho= rs as I understood from following up the WG history (they don't agree to ch= ange the name of protocol). As you are one co-author do I understand that y= ou support the Chris's proposal,
AB
On Fri, Nov 2, 2012 at 2:41 PM, Ulr= ich Herberg <ulrich@herberg.= name> wrote:
Dear Chris,

personally, what you propose makes sense to me.


Regards
Ulrich

On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesyste= ms.com> wrote:

> Before making a proposal, I'm going to introduce a distinction here be= tween the DYMO and LOADng documents and protocols.
>
> I'm of the opinion that the LOADng document is a greatly superior pres= entation to the DYMO document. (I'm not really interested in why that has c= ome about.)
>
> I think that regardless of whether one makes design decisions favourin= g DYMO or LOADng where they differ - and let's not forget they overlap a lo= t - it would actually be easier to modify the LOADng document to specify DY= MO than it would be to modify the DYMO document to achieve that. And in practice I think if making decisions it i= s unlikely that all would favour DYMO over LOADng.
>
> So what I think would be best for the WG is not a simply "option = 1" or even (as it may appear I'm suggesting, but  I'm not) "= option 2" but rather to agree to take the LOADng document, and a list = of where DYMO and LOADng differ, and thrash out where they do, what the WG reactive protocol should do - either as a definite choice, or = as an option (but not too many options please- and some could be separate s= pecifications).
>
> This would not of course be LOADng, so we'd have to change the documen= t name. And there I suggest we have a candidate name - AODVv2. (Which is wh= y I have recently taken to saying DYMO when referring to that document.) Af= ter all, the one thing we are agreed on is that the protocol being developed is derived from AODV.
>
> The editors of this new document would have to agree that what goes in= it is WG consensus (which should follow proper technical consideration of = the issues). If they found it impossible to have other than their way to do= things, they'd have to move on. If that left no one editing it, obviously we don't have a consensus of people= prepared to do the work and option 3 would win.
>
> So now I'm partly off the fence I've been sitting on. But only partly.= I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as stan= dard, IRREPs as an option in the main draft, IRREPs as a separate draft opt= ion, no IRREPs. I'd like to move on to those discussions.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
>
> ******************************************************************** > 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.
> ******************************************************************** >
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet


--_000_03B78081B371D44390ED6E7BADBB4A772204D73Bxmbrcdx02ciscoc_-- From jvasseur@cisco.com Sat Nov 3 01:29:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522AC21F9C6C for ; Sat, 3 Nov 2012 01:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.52 X-Spam-Level: X-Spam-Status: No, score=-10.52 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYOsMQ91Skbu for ; Sat, 3 Nov 2012 01:29:21 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 817B921F93EE for ; Sat, 3 Nov 2012 01:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21652; q=dns/txt; s=iport; t=1351931360; x=1353140960; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=adZwG0eMWH5JQUCq48f/f421kC+o3F3mWY6PKE9dbEE=; b=C5l3Cmxfn/AGWDDNvKq9pP8U8viGQIxKwF4ICFIo1q0nTO+ildPxJYmD k0QFR6x7b/u01xyPVQRl//D8K0ZGt9vAaa+U8oBe8fJYxRTle1Uz5BXXP 1iFRm19VFz9MtTS05tI8ZhVY3+rPZXUvtcK0cW3ux2hGd2DzkNdnt9fxW E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGnVlFCtJXG+/2dsb2JhbABEukABiHOBCIIeAQEBAwEBAQEPAQVUAgsFCwIBCCIdBycLFBECBA4FCAwOh2IGC5wCn3aMARSFR2EDlxeNPYFrgm+BWyAe X-IronPort-AV: E=Sophos;i="4.80,704,1344211200"; d="scan'208,217";a="135410346" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 03 Nov 2012 08:29:20 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA38TKrv006524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 08:29:20 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 03:29:13 -0500 From: "JP Vasseur (jvasseur)" To: C Chauvenet Thread-Topic: [manet] LOADng works Thread-Index: AQHNuF9dW2UMul6sMEaXNf6TARakEQ== Date: Sat, 3 Nov 2012 08:29:13 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204D763@xmb-rcd-x02.cisco.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.169] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--53.985200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204D763xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 08:29:23 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204D763xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable See JP2 On Nov 2, 2012, at 7:19 PM, C Chauvenet wrote: HI, See inline. Le 2 nov. 2012 =E0 18:22, Ulrich Herberg a =E9crit : JP, On Fri, Nov 2, 2012 at 10:09 AM, JP Vasseur (jvasseur) > wrote: On Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote: >>>> JP> This is not just a question of "how large" it is =85 but also how >>>> dynamic. I could show you few hundreds (if not less number of nodes) >>>> not working if the traffic pattern is too dynamic. This is a >>>> fundamental problem. > > No, it is a fundamental and well-known characteristic of reactive > routing protocols. It is a problem only when this behavior doesn't > match the characteristics of the network in which the reactive routing > protocol is deployed. JP> Indeed =85 and this is why you have a fundamental issue with you have e= xtremely high BER, PDR, low bandwidth =85 as we do in LLNs. Flooding in these networks is driven by= user traffic and of course is highly undesirable. Slightly increase the use traffic and you will see t= he impact on the control plane ... Yes, but as Timothy mentioned, there are cases where you don't have much us= er traffic. This is well known. If you have more user traffic, then you may= need a proactive protocol. You may not like the idea that some people actu= ally deploy reactive protocols in LLNs, but it's a fact. And your argument,= again, makes no sense that you think that DYMO is suitable and LOADng is n= ot. > > We've known for at least 15 years that reactive routing protocols are > more appropriate for light traffic loads and that proactive routing > protocols are more appropriate with heavier traffic loads. JP> This is over-simplying but I see what you mean. > Dozens, > probably hundreds of research papers have reiterated this result. > I don't know of any that have contradicted this result, although > some researchers have tried to develop hybrid routing protocols > (which don't seem to have gained much traction, either in the IETF > or elsewhere). > > Claiming that reactive routing protocols don't scale to heavier traffic > loads is neither a new result nor particularly insightful -- this hasn't > changed for at least 15 years. JP> Let me restate my point. Not sure of what you mean by "heavier" =85 but= if you flood the network with probes each time you need to find a path in a LLN yo= u have a major problem. Well, if you have few communication streams, the few floods are much less h= eavy than having a proactive protocol exchange control traffic all day. Aga= in, no argument in favor for DYMO and against LOADng. Note also that you on= ly talk about LLN, but we are the [manet] WG. Of course, there are many ways to control flooding, use caches .. that are all well-known and by the way hard to tune. But overall, reactive = routing in *these* networks is simply ill suited. > > I haven't seen any evidence that _no_ LLN will experience the sort of > light traffic load that matches the characteristics of a reactive > routing protocol. To the contrary, the deployment experience with > LOADng suggests that such do networks exist. JP> Once again it all depends on the traffic profile. Of course you could m= ake a reactive routing protocol work on a LLN as long as the user traffic has spe= cific characteristics. Exactly! Thanks for pointing that out. That's the whole point why [manet] i= s chartered to do both reactive and proactive protocols. If you carefully analyze the user traffic characteristic in networks such as smart metering (since this was mentioned on this list), and you inc= orporate additional applications such as DA, .. to mention a few, you will see that = in most of these networks this simply does not work =85 too many flooding, ending up n= ot even converging in some cases, especially when the number of hops gets high with= poor link quality. You are not bringing up any new argument that is not known to [manet] for t= he last 15 years. Reactive protocols only work for certain scenarios. We kn= ow that. We have never disputed that. > > At the risk of arguing by analogy, the argument that one can "prove" > that reactive routing protocols don't work (in LLNs or elsewhere) seems > to make about as much as sense as "proving" that OSPF doesn't work > because it doesn't behave well in dynamic environments. The failure of > OSPF in dynamic environments didn't cause us to abandon OSPF: there are > many environments in which it works well. JP> Not sure that I would have used this analogy :-( OSPF was not designed = for highly dynamic environment indeed *but* we could easily enhance it with fast failu= re detection (+ BFD), fast LSA generation, fast SPF and incremental SPF, Local Fast Rero= ute, =85 because routers had lot of resources, links were highly stable, =85 which i= s by far not the case of LLNs. > Rather, we concluded that we > needed another routing protocol. In a similar manner, the MANET > working group, and as far as I have seen pretty much all of the > research community, concluded that there is a need for both a > reactive routing protocol and a proactive routing protocol. > > Of course, the ROLL working group can decide not to standardize > a reactive routing protocol. However, that doesn't prove that > reactive routing protocols don't work (when they match the > traffic characteristics of the network), that reactive routing > protocols won't work better than proactive routing protocols > in some LLNs (based on the characteristics of the traffic load), > or that reactive routing protocols won't be successfully deployed > in LLNs. JP> Well =85 Think about this: when ROLL was formed, the IESG explicitly an= d rightfully asked the WG to first prove that none of the existing protocol could be used, bef= ore standardizing a new protocol (that was the right choice !!). Right, but that "proof" was never published by the IETF, and as such only a= n assertion. Moreover, we are not the ROLL WG. I think http://tools.ietf.org/html/draft-ietf-roll-protocols-survey-07 is s= uch a publication. BTW, it covers AODV and DYMO, and explains why it does not match general LL= N requirements (and so for any AODV-based protocols such as LOADng). But I agree that this is MANET list, so this should not be the place to deb= ate RPL here. I think ROLL-ers came in the discussion because LOADng authors explicitly s= tates that they want to use LOADng in LLNs, that is ROLL working space. Tho= ugh, I think you agree that LOADng will not match general LLN requirements = and be limited to specific low traffic deployment. JP2> Absolutely. And I tool the example of what the IESG rightfully asked u= s to do when forming ROLL. *If* you want to specify a new protocol for this use case, first demonstrate why you cannot use what exists first. C=E9dric. Could then prove that the current protocol cannot be used in your environme= nt before suggesting to standardize a new one. Once again, if not applicable to LLNs, I have no problem whatsoever. People have deployed reactive protocols as a matter of fact in LLNs. So, is= the only reason why you like DYMO and not LOADng, because LOADng mentions = the word LLN once in the introduction? Best regards Ulrich > If fact, the LOADng deployment experience strongly > suggests that reactive routing protocols _will_ be deployed in > some LLNs. And, they will be deployed regardless of the ROLL > working group's decision to not standardize a reactive routing > protocol. JP> And this is perfectly fine, people are free to use any protocol they wa= nt, including proprietary ones. This does not mean that the IETF should standardize them. > > Claiming that reactive routing protocols don't work because they > don't scale to higher traffic loads seems, JP> Then we need to characterize precisely the limits. > at best, a poor > characterization of well-known research results, and at worst > a distraction from the question at hand: namely how to proceed > towards an Internet-standard reactive routing protocol. > > -tjs _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204D763xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2DB8C8F5E489CE4785A336847FB8CDAD@cisco.com> Content-Transfer-Encoding: quoted-printable See JP2

On Nov 2, 2012, at 7:19 PM, C Chauvenet wrote:

HI, 
See inline.

Le 2 nov. 2012 =E0 18:22, Ulrich Herberg a =E9crit :

JP,

On Fri, Nov 2, 2012 at 10:09 AM, JP Vasseur (jva= sseur) <jvasseur@cisco.= com> wrote:

On Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote:

>>>> JP> This is not just a question of "how large"= ; it is =85 but also how
>>>> dynamic. I could show you few hundreds (if not less number= of nodes)
>>>> not working if the traffic pattern is too dynamic. This is= a
>>>> fundamental problem.
>
> No, it is a fundamental and well-known characteristic of reactive
> routing protocols.  It is a problem only when this behavior doesn= 't
> match the characteristics of the network in which the reactive routing=
> protocol is deployed.

JP> Indeed =85 and this is why you have a fundamental issue with you hav= e extremely high BER, PDR,
low bandwidth =85 as we do in LLNs. Flooding in these networks is driven by= user traffic and of course
is highly undesirable. Slightly increase the use traffic and you will see t= he impact on the control plane ...


Yes, but as Timothy mentioned, there are cases where you don't have mu= ch user traffic. This is well known. If you have more user traffic, then yo= u may need a proactive protocol. You may not like the idea that some people= actually deploy reactive protocols in LLNs, but it's a fact. And your argument, again, makes no sense th= at you think that DYMO is suitable and LOADng is not.

 
>
> We've known for at least 15 years that reactive routing protocols are<= br> > more appropriate for light traffic loads and that proactive routing > protocols are more appropriate with heavier traffic loads.

JP> This is over-simplying but I see what you mean.

> Dozens,
> probably hundreds of research papers have reiterated this result.
> I don't know of any that have contradicted this result, although
> some researchers have tried to develop hybrid routing protocols
> (which don't seem to have gained much traction, either in the IETF
> or elsewhere).
>
> Claiming that reactive routing protocols don't scale to heavier traffi= c
> loads is neither a new result nor particularly insightful -- this hasn= 't
> changed for at least 15 years.

JP> Let me restate my point. Not sure of what you mean by "heavier&= quot; =85 but if you
flood the network with probes each time you need to find a path in a LLN yo= u have
a major problem.

Well, if you have few communication streams, the few floods are much l= ess heavy than having a proactive protocol exchange control traffic all day= . Again, no argument in favor for DYMO and against LOADng. Note also that y= ou only talk about LLN, but we are the [manet] WG.

 
Of course, there are many ways to control flooding, use caches ..
that are all well-known and by the way hard to tune. But overall, reactive = routing in
*these* networks is simply ill suited.

>
> I haven't seen any evidence that _no_ LLN will experience the sort of<= br> > light traffic load that matches the characteristics of a reactive
> routing protocol.  To the contrary, the deployment experience wit= h
> LOADng suggests that such do networks exist.

JP> Once again it all depends on the traffic profile. Of course you coul= d make a
reactive routing protocol work on a LLN as long as the user traffic has spe= cific
characteristics.


Exactly! Thanks for pointing that out. That's the whole point why [man= et] is chartered to do both reactive and proactive protocols.

 
If you carefully analyze the user traffic characteristic in networks
such as smart metering (since this was mentioned on this list), and you inc= orporate
additional applications such as DA, .. to mention a few, you will see that = in most of
these networks this simply does not work =85 too many flooding, ending up n= ot even
converging in some cases, especially when the number of hops gets high with= poor
link quality.

You are not bringing up any new argument that is not known to [manet] = for the last 15 years. Reactive protocols only work for certain scenarios. = We know that. We have never disputed that.

 

>
> At the risk of arguing by analogy, the argument that one can "pro= ve"
> that reactive routing protocols don't work (in LLNs or elsewhere) seem= s
> to  make about as much as sense as "proving" that OSPF = doesn't work
> because it doesn't behave well in dynamic environments.  The fail= ure of
> OSPF in dynamic environments didn't cause us to abandon OSPF: there ar= e
> many environments in which it works well.

JP> Not sure that I would have used this analogy :-( OSPF was not design= ed for highly
dynamic environment indeed *but* we could easily enhance it with fast failu= re detection
(+ BFD), fast LSA generation, fast SPF and incremental SPF, Local Fast = Reroute, =85
because routers had lot of resources, links were highly stable, =85 which i= s by far not the
case of LLNs.

> Rather, we concluded that we
> needed another routing protocol.  In a similar manner, the MANET<= br> > working group, and as far as I have seen pretty much all of the
> research community, concluded that there is a need for both a
> reactive routing protocol and a proactive routing protocol.
>
> Of course, the ROLL working group can decide not to standardize
> a reactive routing protocol.  However, that doesn't prove that > reactive routing protocols don't work (when they match the
> traffic characteristics of the network), that reactive routing
> protocols won't work better than proactive routing protocols
> in some LLNs (based on the characteristics of the traffic load),
> or that reactive routing protocols won't be successfully deployed
> in LLNs.

JP> Well =85 Think about this: when ROLL was formed, the IESG explicitly= and rightfully asked
the WG to first prove that none of the existing protocol could be used, bef= ore standardizing a
new protocol (that was the right choice !!).


Right, but that "proof" was never published by the IETF, and= as such only an assertion. Moreover, we are not the ROLL WG.

BTW, it covers AODV and DYMO, and explains why it does not match gener= al LLN requirements (and so for any AODV-based protocols such as LOADng).

But I agree that this is MANET list, so this should not be the place t= o debate RPL here.
I think ROLL-ers came in the discussion because LOADng authors explici= tly states that they want to use LOADng in LLNs, that is ROLL working space= . Though, I think you agree that LOADng will not match general LLN requirem= ents and be limited to specific low traffic deployment.


JP2> Absolutely. And I tool the example of what the IESG rightfully= asked us to do when forming ROLL. *If* you want to specify a new protocol<= /div>
for this use case, first demonstrate why you cannot use what exists fi= rst.

C=E9dric.

 

Could then prove that the current protocol cannot be used in your environme= nt before suggesting
to standardize a new one.

Once again, if not applicable to LLNs, I have no problem whatsoever.
 

People have deployed reactive protocols as a matter of fact in LLNs. S= o, is the only reason why you like DYMO and not LOADng, because LOADng ment= ions the word LLN once in the introduction?

Best regards
Ulrich

 

> If fact, the LOADng deployment experience strongly
> suggests that reactive routing protocols _will_ be deployed in
> some LLNs.  And, they will be deployed regardless of the ROLL
> working group's decision to not standardize a reactive routing
> protocol.

JP> And this is perfectly fine, people are free to use any protocol they= want, including proprietary
ones. This does not mean that the IETF should standardize them.

>
> Claiming that reactive routing protocols don't work because they
> don't scale to higher traffic loads seems,

JP> Then we need to characterize precisely the limits.

> at best, a poor
> characterization of well-known research results, and at worst
> a distraction from the question at hand: namely how to proceed
> towards an Internet-standard reactive routing protocol.
>
> -tjs

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet


--_000_03B78081B371D44390ED6E7BADBB4A772204D763xmbrcdx02ciscoc_-- From jvasseur@cisco.com Sat Nov 3 01:30:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC4921F9CBF for ; Sat, 3 Nov 2012 01:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.422 X-Spam-Level: X-Spam-Status: No, score=-10.422 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGsmEdeYgjRa for ; Sat, 3 Nov 2012 01:29:59 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BF3E421F9CB8 for ; Sat, 3 Nov 2012 01:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26745; q=dns/txt; s=iport; t=1351931398; x=1353140998; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sLom31/D8akmjtU6t7UtVqnQhLwKFuhVW7+rmd7tgro=; b=FmEr5B979ydaXWIccsdMK0jgMTX0YERiKYHxiK6JGX/zGdOVCDYBJpn/ 5Zb2hUdrkNddtgTsY4EjHb1nSJ0EAYDrFfsUygp84we1PpqlIB+fQ8P5x YDSCcdrRsBs4j0ctJ6Yz0mb6KM8JOiSU+bGCYB4U/RiAJEVbGW78l7ikk Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAHVlFCtJV2c/2dsb2JhbABEukABiHOBCIIeAQEBAwEBAQEPAQVUAgsFCwIBCCIWBwcnCxQRAgQOBQgMDodiBgucAp92jAEUhUdhA5cXjT2Ba4JvgVsgHg X-IronPort-AV: E=Sophos;i="4.80,704,1344211200"; d="scan'208,217";a="138414650" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 03 Nov 2012 08:29:58 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA38Tw5R029610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 08:29:58 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 03:29:57 -0500 From: "JP Vasseur (jvasseur)" To: Jiazi YI Thread-Topic: [manet] LOADng works Thread-Index: AQHNuF9dW2UMul6sMEaXNf6TARakEQ== Date: Sat, 3 Nov 2012 08:29:56 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204D773@xmb-rcd-x02.cisco.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.169] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--50.409400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204D773xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org List" , "Timothy J. Salo" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 08:30:00 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204D773xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Nov 2, 2012, at 7:27 PM, Jiazi YI wrote: Hi, I don't think citing a draft that has been expired for 3 years actually say= s anything. Why ignoring excellent work ? best Jiazi On Nov 3, 2012, at 12:19 AM, C Chauvenet > wrote: HI, See inline. Le 2 nov. 2012 =E0 18:22, Ulrich Herberg a =E9crit : JP, On Fri, Nov 2, 2012 at 10:09 AM, JP Vasseur (jvasseur) > wrote: On Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote: >>>> JP> This is not just a question of "how large" it is =85 but also how >>>> dynamic. I could show you few hundreds (if not less number of nodes) >>>> not working if the traffic pattern is too dynamic. This is a >>>> fundamental problem. > > No, it is a fundamental and well-known characteristic of reactive > routing protocols. It is a problem only when this behavior doesn't > match the characteristics of the network in which the reactive routing > protocol is deployed. JP> Indeed =85 and this is why you have a fundamental issue with you have e= xtremely high BER, PDR, low bandwidth =85 as we do in LLNs. Flooding in these networks is driven by= user traffic and of course is highly undesirable. Slightly increase the use traffic and you will see t= he impact on the control plane ... Yes, but as Timothy mentioned, there are cases where you don't have much us= er traffic. This is well known. If you have more user traffic, then you may= need a proactive protocol. You may not like the idea that some people actu= ally deploy reactive protocols in LLNs, but it's a fact. And your argument,= again, makes no sense that you think that DYMO is suitable and LOADng is n= ot. > > We've known for at least 15 years that reactive routing protocols are > more appropriate for light traffic loads and that proactive routing > protocols are more appropriate with heavier traffic loads. JP> This is over-simplying but I see what you mean. > Dozens, > probably hundreds of research papers have reiterated this result. > I don't know of any that have contradicted this result, although > some researchers have tried to develop hybrid routing protocols > (which don't seem to have gained much traction, either in the IETF > or elsewhere). > > Claiming that reactive routing protocols don't scale to heavier traffic > loads is neither a new result nor particularly insightful -- this hasn't > changed for at least 15 years. JP> Let me restate my point. Not sure of what you mean by "heavier" =85 but= if you flood the network with probes each time you need to find a path in a LLN yo= u have a major problem. Well, if you have few communication streams, the few floods are much less h= eavy than having a proactive protocol exchange control traffic all day. Aga= in, no argument in favor for DYMO and against LOADng. Note also that you on= ly talk about LLN, but we are the [manet] WG. Of course, there are many ways to control flooding, use caches .. that are all well-known and by the way hard to tune. But overall, reactive = routing in *these* networks is simply ill suited. > > I haven't seen any evidence that _no_ LLN will experience the sort of > light traffic load that matches the characteristics of a reactive > routing protocol. To the contrary, the deployment experience with > LOADng suggests that such do networks exist. JP> Once again it all depends on the traffic profile. Of course you could m= ake a reactive routing protocol work on a LLN as long as the user traffic has spe= cific characteristics. Exactly! Thanks for pointing that out. That's the whole point why [manet] i= s chartered to do both reactive and proactive protocols. If you carefully analyze the user traffic characteristic in networks such as smart metering (since this was mentioned on this list), and you inc= orporate additional applications such as DA, .. to mention a few, you will see that = in most of these networks this simply does not work =85 too many flooding, ending up n= ot even converging in some cases, especially when the number of hops gets high with= poor link quality. You are not bringing up any new argument that is not known to [manet] for t= he last 15 years. Reactive protocols only work for certain scenarios. We kn= ow that. We have never disputed that. > > At the risk of arguing by analogy, the argument that one can "prove" > that reactive routing protocols don't work (in LLNs or elsewhere) seems > to make about as much as sense as "proving" that OSPF doesn't work > because it doesn't behave well in dynamic environments. The failure of > OSPF in dynamic environments didn't cause us to abandon OSPF: there are > many environments in which it works well. JP> Not sure that I would have used this analogy :-( OSPF was not designed = for highly dynamic environment indeed *but* we could easily enhance it with fast failu= re detection (+ BFD), fast LSA generation, fast SPF and incremental SPF, Local Fast Rero= ute, =85 because routers had lot of resources, links were highly stable, =85 which i= s by far not the case of LLNs. > Rather, we concluded that we > needed another routing protocol. In a similar manner, the MANET > working group, and as far as I have seen pretty much all of the > research community, concluded that there is a need for both a > reactive routing protocol and a proactive routing protocol. > > Of course, the ROLL working group can decide not to standardize > a reactive routing protocol. However, that doesn't prove that > reactive routing protocols don't work (when they match the > traffic characteristics of the network), that reactive routing > protocols won't work better than proactive routing protocols > in some LLNs (based on the characteristics of the traffic load), > or that reactive routing protocols won't be successfully deployed > in LLNs. JP> Well =85 Think about this: when ROLL was formed, the IESG explicitly an= d rightfully asked the WG to first prove that none of the existing protocol could be used, bef= ore standardizing a new protocol (that was the right choice !!). Right, but that "proof" was never published by the IETF, and as such only a= n assertion. Moreover, we are not the ROLL WG. I think http://tools.ietf.org/html/draft-ietf-roll-protocols-survey-07 is s= uch a publication. BTW, it covers AODV and DYMO, and explains why it does not match general LL= N requirements (and so for any AODV-based protocols such as LOADng). But I agree that this is MANET list, so this should not be the place to deb= ate RPL here. I think ROLL-ers came in the discussion because LOADng authors explicitly s= tates that they want to use LOADng in LLNs, that is ROLL working space. Tho= ugh, I think you agree that LOADng will not match general LLN requirements = and be limited to specific low traffic deployment. C=E9dric. Could then prove that the current protocol cannot be used in your environme= nt before suggesting to standardize a new one. Once again, if not applicable to LLNs, I have no problem whatsoever. People have deployed reactive protocols as a matter of fact in LLNs. So, is= the only reason why you like DYMO and not LOADng, because LOADng mentions = the word LLN once in the introduction? Best regards Ulrich > If fact, the LOADng deployment experience strongly > suggests that reactive routing protocols _will_ be deployed in > some LLNs. And, they will be deployed regardless of the ROLL > working group's decision to not standardize a reactive routing > protocol. JP> And this is perfectly fine, people are free to use any protocol they wa= nt, including proprietary ones. This does not mean that the IETF should standardize them. > > Claiming that reactive routing protocols don't work because they > don't scale to higher traffic loads seems, JP> Then we need to characterize precisely the limits. > at best, a poor > characterization of well-known research results, and at worst > a distraction from the question at hand: namely how to proceed > towards an Internet-standard reactive routing protocol. > > -tjs _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204D773xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Nov 2, 2012, at 7:27 PM, Jiazi YI wrote:

Hi, 

I don't think citing a draft that has been expired for 3 years actually says= anything. 

Why ignoring excellent work ?


best

Jiazi


On Nov 3, 2012, at 12:19 AM, C Chauvenet <c.chauvenet@watteco.com> wrote:

HI, 
See inline.

Le 2 nov. 2012 =E0 18:22, Ulrich Herberg a =E9crit :

JP,

On Fri, Nov 2, 2012 at 10:09 AM, JP Vasseur (jva= sseur) <jvasseur@cisco.= com> wrote:

On Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote:

>>>> JP> This is not just a question of "how large"= ; it is =85 but also how
>>>> dynamic. I could show you few hundreds (if not less number= of nodes)
>>>> not working if the traffic pattern is too dynamic. This is= a
>>>> fundamental problem.
>
> No, it is a fundamental and well-known characteristic of reactive
> routing protocols.  It is a problem only when this behavior doesn= 't
> match the characteristics of the network in which the reactive routing=
> protocol is deployed.

JP> Indeed =85 and this is why you have a fundamental issue with you hav= e extremely high BER, PDR,
low bandwidth =85 as we do in LLNs. Flooding in these networks is driven by= user traffic and of course
is highly undesirable. Slightly increase the use traffic and you will see t= he impact on the control plane ...


Yes, but as Timothy mentioned, there are cases where you don't have mu= ch user traffic. This is well known. If you have more user traffic, then yo= u may need a proactive protocol. You may not like the idea that some people= actually deploy reactive protocols in LLNs, but it's a fact. And your argument, again, makes no sense th= at you think that DYMO is suitable and LOADng is not.

 
>
> We've known for at least 15 years that reactive routing protocols are<= br> > more appropriate for light traffic loads and that proactive routing > protocols are more appropriate with heavier traffic loads.

JP> This is over-simplying but I see what you mean.

> Dozens,
> probably hundreds of research papers have reiterated this result.
> I don't know of any that have contradicted this result, although
> some researchers have tried to develop hybrid routing protocols
> (which don't seem to have gained much traction, either in the IETF
> or elsewhere).
>
> Claiming that reactive routing protocols don't scale to heavier traffi= c
> loads is neither a new result nor particularly insightful -- this hasn= 't
> changed for at least 15 years.

JP> Let me restate my point. Not sure of what you mean by "heavier&= quot; =85 but if you
flood the network with probes each time you need to find a path in a LLN yo= u have
a major problem.

Well, if you have few communication streams, the few floods are much l= ess heavy than having a proactive protocol exchange control traffic all day= . Again, no argument in favor for DYMO and against LOADng. Note also that y= ou only talk about LLN, but we are the [manet] WG.

 
Of course, there are many ways to control flooding, use caches ..
that are all well-known and by the way hard to tune. But overall, reactive = routing in
*these* networks is simply ill suited.

>
> I haven't seen any evidence that _no_ LLN will experience the sort of<= br> > light traffic load that matches the characteristics of a reactive
> routing protocol.  To the contrary, the deployment experience wit= h
> LOADng suggests that such do networks exist.

JP> Once again it all depends on the traffic profile. Of course you coul= d make a
reactive routing protocol work on a LLN as long as the user traffic has spe= cific
characteristics.


Exactly! Thanks for pointing that out. That's the whole point why [man= et] is chartered to do both reactive and proactive protocols.

 
If you carefully analyze the user traffic characteristic in networks
such as smart metering (since this was mentioned on this list), and you inc= orporate
additional applications such as DA, .. to mention a few, you will see that = in most of
these networks this simply does not work =85 too many flooding, ending up n= ot even
converging in some cases, especially when the number of hops gets high with= poor
link quality.

You are not bringing up any new argument that is not known to [manet] = for the last 15 years. Reactive protocols only work for certain scenarios. = We know that. We have never disputed that.

 

>
> At the risk of arguing by analogy, the argument that one can "pro= ve"
> that reactive routing protocols don't work (in LLNs or elsewhere) seem= s
> to  make about as much as sense as "proving" that OSPF = doesn't work
> because it doesn't behave well in dynamic environments.  The fail= ure of
> OSPF in dynamic environments didn't cause us to abandon OSPF: there ar= e
> many environments in which it works well.

JP> Not sure that I would have used this analogy :-( OSPF was not design= ed for highly
dynamic environment indeed *but* we could easily enhance it with fast failu= re detection
(+ BFD), fast LSA generation, fast SPF and incremental SPF, Local Fast = Reroute, =85
because routers had lot of resources, links were highly stable, =85 which i= s by far not the
case of LLNs.

> Rather, we concluded that we
> needed another routing protocol.  In a similar manner, the MANET<= br> > working group, and as far as I have seen pretty much all of the
> research community, concluded that there is a need for both a
> reactive routing protocol and a proactive routing protocol.
>
> Of course, the ROLL working group can decide not to standardize
> a reactive routing protocol.  However, that doesn't prove that > reactive routing protocols don't work (when they match the
> traffic characteristics of the network), that reactive routing
> protocols won't work better than proactive routing protocols
> in some LLNs (based on the characteristics of the traffic load),
> or that reactive routing protocols won't be successfully deployed
> in LLNs.

JP> Well =85 Think about this: when ROLL was formed, the IESG explicitly= and rightfully asked
the WG to first prove that none of the existing protocol could be used, bef= ore standardizing a
new protocol (that was the right choice !!).


Right, but that "proof" was never published by the IETF, and= as such only an assertion. Moreover, we are not the ROLL WG.

BTW, it covers AODV and DYMO, and explains why it does not match gener= al LLN requirements (and so for any AODV-based protocols such as LOADng).

But I agree that this is MANET list, so this should not be the place t= o debate RPL here.
I think ROLL-ers came in the discussion because LOADng authors explici= tly states that they want to use LOADng in LLNs, that is ROLL working space= . Though, I think you agree that LOADng will not match general LLN requirem= ents and be limited to specific low traffic deployment.

C=E9dric.

 

Could then prove that the current protocol cannot be used in your environme= nt before suggesting
to standardize a new one.

Once again, if not applicable to LLNs, I have no problem whatsoever.
 

People have deployed reactive protocols as a matter of fact in LLNs. S= o, is the only reason why you like DYMO and not LOADng, because LOADng ment= ions the word LLN once in the introduction?

Best regards
Ulrich

 

> If fact, the LOADng deployment experience strongly
> suggests that reactive routing protocols _will_ be deployed in
> some LLNs.  And, they will be deployed regardless of the ROLL
> working group's decision to not standardize a reactive routing
> protocol.

JP> And this is perfectly fine, people are free to use any protocol they= want, including proprietary
ones. This does not mean that the IETF should standardize them.

>
> Claiming that reactive routing protocols don't work because they
> don't scale to higher traffic loads seems,

JP> Then we need to characterize precisely the limits.

> at best, a poor
> characterization of well-known research results, and at worst
> a distraction from the question at hand: namely how to proceed
> towards an Internet-standard reactive routing protocol.
>
> -tjs

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A772204D773xmbrcdx02ciscoc_-- From jvasseur@cisco.com Sat Nov 3 01:32:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B0A21F9CB8 for ; Sat, 3 Nov 2012 01:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjrBpsrC2BUY for ; Sat, 3 Nov 2012 01:32:49 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 55D3921F9C6D for ; Sat, 3 Nov 2012 01:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11913; q=dns/txt; s=iport; t=1351931569; x=1353141169; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1CzDNfw+lG1+vFjlkn8dqjvxodj3TP8/wZ/uXOlMsZc=; b=lHa1bn4z9G71KJ6U6Dutqm6tD4idCdHjSNYDfkU5R0C47JpfHw6ePDq/ Z9FaWe0GqfRKRWFcHnpQSP8EBKFONF19bHyoM29xLoKwsfB9JQmi8Vucr Zsb7dtBOsEgZ6JLTfuatJVPprYVkbssN0Pwjppd+mPHNchKjQ9CeiUYfO Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGnVlFCtJV2b/2dsb2JhbABEukABiHOBCIIeAQEBAwEBAQEPAQVWCwULAgEIIh0HJwsUEQIEDgUIGodiBgucAp92jAEUhUdhA4gljnKNPYFrgm+BWyAe X-IronPort-AV: E=Sophos;i="4.80,704,1344211200"; d="scan'208,217";a="138446834" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 03 Nov 2012 08:32:48 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA38Wm7s010345 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 08:32:48 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 03:32:47 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] LOADng works Thread-Index: AQHNuF9dW2UMul6sMEaXNf6TARakEQ== Date: Sat, 3 Nov 2012 08:32:47 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.169] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--38.588600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204D7AExmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" , "Timothy J. Salo" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 08:32:50 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204D7AExmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Nov 2, 2012, at 7:29 PM, Ulrich Herberg wrote: C=E9dric, On Fri, Nov 2, 2012 at 4:19 PM, C Chauvenet > wrote: [...] Right, but that "proof" was never published by the IETF, and as such only a= n assertion. Moreover, we are not the ROLL WG. I think http://tools.ietf.org/html/draft-ietf-roll-protocols-survey-07 is s= uch a publication. That is the draft I was talking about. It is *not* a publication. It was ne= ver published by the IETF, even though some claim it is a publication. JP> If you are "picky" about IETF document state, you should then propose t= o select *the* MANET working group document as a base: DYMO. BTW, it covers AODV and DYMO, and explains why it does not match general LL= N requirements (and so for any AODV-based protocols such as LOADng). The document was rejected for a reason. It is heavily flawed and misleading= , in my opinion. But I agree that this is MANET list, so this should not be the place to deb= ate RPL here. Right. I think ROLL-ers came in the discussion because LOADng authors explicitly s= tates that they want to use LOADng in LLNs, that is ROLL working space. And if that one word in the introduction is the whole reason why you prefer= DYMO over LOADng, it is a pretty weak argument. And again, you cannot dispute the fact that LOADng is used in such deployme= nts. You may not like it, for business or other reasons, but it's a fact. Though, I think you agree that LOADng will not match general LLN requiremen= ts and be limited to specific low traffic deployment. I agree that LOADng (or DYMO for that matter) will not be suitable for all = LLN deployments. But it is, as a matter of fact, used in some such deployme= nts. JP> Do you know how proprietary or non IETF standards are used in the filed= for that matter ? The IETF is not here to standardize protocols used in the field because the= y have been chosen in some deployment. RPL also does not fulfill all requirements of all kinds of LLNs, in my opin= ion, but that's another matter not to be discussed here. Best Ulrich C=E9dric. Could then prove that the current protocol cannot be used in your environme= nt before suggesting to standardize a new one. Once again, if not applicable to LLNs, I have no problem whatsoever. People have deployed reactive protocols as a matter of fact in LLNs. So, is= the only reason why you like DYMO and not LOADng, because LOADng mentions = the word LLN once in the introduction? Best regards Ulrich > If fact, the LOADng deployment experience strongly > suggests that reactive routing protocols _will_ be deployed in > some LLNs. And, they will be deployed regardless of the ROLL > working group's decision to not standardize a reactive routing > protocol. JP> And this is perfectly fine, people are free to use any protocol they wa= nt, including proprietary ones. This does not mean that the IETF should standardize them. > > Claiming that reactive routing protocols don't work because they > don't scale to higher traffic loads seems, JP> Then we need to characterize precisely the limits. > at best, a poor > characterization of well-known research results, and at worst > a distraction from the question at hand: namely how to proceed > towards an Internet-standard reactive routing protocol. > > -tjs _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204D7AExmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <278D00EB14FD704E9B9195FDC9A463D2@cisco.com> Content-Transfer-Encoding: quoted-printable
On Nov 2, 2012, at 7:29 PM, Ulrich Herberg wrote:

C=E9dric,

On Fri, Nov 2, 2012 at 4:19 PM, C Chauvenet <c.chauvene= t@watteco.com> wrote:
[...]

Right, but that "proof" was never published by the IETF, and= as such only an assertion. Moreover, we are not the ROLL WG.


That is the draft I was talking about. It is *not* a publication. It w= as never published by the IETF, even though some claim it is a publication.=

JP> If you are "picky" about IETF document state, you sho= uld then propose to select *the* MANET working group document as a base: DY= MO.

 

BTW, it covers AODV and DYMO, and explains why it does not match gener= al LLN requirements (and so for any AODV-based protocols such as LOADng).


The document was rejected for a reason. It is heavily flawed and misle= ading, in my opinion.
 


But I agree that this is MANET list, so this should not be the place t= o debate RPL here.

Right.

 
I think ROLL-ers came in the discussion because LOADng authors explici= tly states that they want to use LOADng in LLNs, that is ROLL working space= .

And if that one word in the introduction is the whole reason why you p= refer DYMO over LOADng, it is a pretty weak argument. 
And again, you cannot dispute the fact that LOADng is used in such dep= loyments. You may not like it, for business or other reasons, but it's a fa= ct.

 
Though, I think you agree that LOADng will not match general LLN requi= rements and be limited to specific low traffic deployment.
 

I agree that LOADng (or DYMO for that matter) will not be suitable for= all LLN deployments. But it is, as a matter of fact, used in some such dep= loyments.

JP> Do you know how proprietary or non IETF standards are used in t= he filed for that matter ?
The IETF is not here to standardize protocols used in the field becaus= e they have been chosen in some deployment.

RPL also does not fulfill all requirements of all kinds of LLNs, in my= opinion, but that's another matter not to be discussed here.

Best
Ulrich


 

C=E9dric.

 

Could then prove that the current protocol cannot be used in your environme= nt before suggesting
to standardize a new one.

Once again, if not applicable to LLNs, I have no problem whatsoever.
 

People have deployed reactive protocols as a matter of fact in LLNs. S= o, is the only reason why you like DYMO and not LOADng, because LOADng ment= ions the word LLN once in the introduction?

Best regards
Ulrich

 

> If fact, the LOADng deployment experience strongly
> suggests that reactive routing protocols _will_ be deployed in
> some LLNs.  And, they will be deployed regardless of the ROLL
> working group's decision to not standardize a reactive routing
> protocol.

JP> And this is perfectly fine, people are free to use any protocol they= want, including proprietary
ones. This does not mean that the IETF should standardize them.

>
> Claiming that reactive routing protocols don't work because they
> don't scale to higher traffic loads seems,

JP> Then we need to characterize precisely the limits.

> at best, a poor
> characterization of well-known research results, and at worst
> a distraction from the question at hand: namely how to proceed
> towards an Internet-standard reactive routing protocol.
>
> -tjs

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



--_000_03B78081B371D44390ED6E7BADBB4A772204D7AExmbrcdx02ciscoc_-- From jvasseur@cisco.com Sat Nov 3 01:35:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100E621F9A32 for ; Sat, 3 Nov 2012 01:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.376 X-Spam-Level: X-Spam-Status: No, score=-10.376 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IQK33gg6KEF for ; Sat, 3 Nov 2012 01:35:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E6F2921F9C6F for ; Sat, 3 Nov 2012 01:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27633; q=dns/txt; s=iport; t=1351931707; x=1353141307; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YJfsn7fZv17gFcklxvsqq/wsNGs8wre+s0RUhqJBlhM=; b=VWLhVWAFkFdmWveIGFM370eCBJpZVCn/WBQrdZrvfOt0F/ZqZe/zKfsx wbHE4fJ4CBOr4vVyC/tuzCqT7PQMbwXPllTZt6xBky447l6NvqTFEAjw/ miGzoVqjz7otw6QcR9fC3Cbz6+sMLHREfytVNX7ct2OB2Dg64hk5TH9sE c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAOLVlFCtJV2c/2dsb2JhbABEgkmuQ5IogQiCHgEBAQMBAQEBDwFCFwIIAwULAgEIBwoEAQELFgcHIQYLEwEJCAIEDgUIFgSHVgMJBgucApYVDYlUixloFIVHYQOUJgSNBIMmgWuCb4FbCRce X-IronPort-AV: E=Sophos;i="4.80,704,1344211200"; d="scan'208,217";a="138390736" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 03 Nov 2012 08:35:06 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA38Z6Rm032363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 08:35:06 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 03:35:05 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] A proposal - differentiating the document and the protocol Thread-Index: AQHNuR5uQAldmF7ZtU6krGF1ERjKag== Date: Sat, 3 Nov 2012 08:35:05 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204D7E5@xmb-rcd-x02.cisco.com> References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> <1351876587.86080.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204C69E@xmb-rcd-x02.cisco.com> <1351890653.89343.YahooMailNeo@web160603.mail.bf1.yahoo.com> <97B69B30E0EF244B940B65EA541E3F2D21572F63@DBXPRD0510MB395.eurprd05.prod.outlook.com> <97B69B30E0EF244B940B65EA541E3F2D215731FF@DBXPRD0510MB395.eurprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.169] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--51.110900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204D7E5xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: =?Windows-1252?Q?Axel_Colin_de_Verdi=E8re?= , "manet@ietf.org List" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 08:35:09 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204D7E5xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I was about to ask the same question =85 merge did not happen for a number = of reasons (that I do not all know by the way), thus the questions from the chairs. I fail to understand why we cannot start from the WG docum= ent (result of years of work) and quickly improve it. By the way, as a reminder, I'd rather do the right thing that rushing out. On Nov 2, 2012, at 7:45 PM, Ulrich Herberg wrote: C=E9dric, the merge did not fail for technical but for process reasons. We offered Ch= arlie to be editor, together with Thomas. Charlie is already author of LOAD= ng. In my opinion (I can't speak for anyone else), that has not changed. If we start the merge from the LOADng document, we would be far quicker to = come to an RFC. As said, we can then look at each option, see if it's suita= ble or not, and if it should be part of the core or rather be in a companio= n document. Best Ulrich On Fri, Nov 2, 2012 at 4:31 PM, C Chauvenet > wrote: One thing that popped up in my mind : Are we trying to do the merge between DYMO and LOADng that has previously f= ailed ?? Regardless from which document we start, I understood (from Charlie massage= s) that LOADng authors were not OK to merge their document with functionali= ties from DYMO . Did I missed something here ? C=E9dric. Le 2 nov. 2012 =E0 23:41, C Chauvenet a =E9crit : Hi all, If we add mechanisms to LOADng or prune some from DYMO, we end up with a di= fferent protocol, so I think that we will need to change the name of the re= sulting protocol. I support the AODVv2 naming for the reactive protocol of = MANET, if chairs decide to go forward and do not take option 3). It seems that charlie is working hard on updating the DYMO draft, by addres= sing reviews of the document. These reviews contains most of the improvemen= ts (readability, RFC5444 compliance ....) that people found missing in DYMO= . I think that would make sense to wait for the next update of DYMO before = choosing between LOADng and DYMO. I think that the WG want something good, = rather than something quick. In addition, we would benefit from the work that charlie is currently doing= , rather that skip it if we made a decision based on the actual DYMO versio= n. C=E9dric. Le 2 nov. 2012 =E0 22:10, Jon Black a =E9crit : It is not completely new and it is much more mature. It has been being dev= eloped for quite some time, it has implementations, it has interoperability= . Age of a document is not a good criteria. Something can be written quit= e a long time ago and nothing done on it. Another document/protocol may co= me along, gain critical mass, gain experience and even though younger may b= e a much better starting point. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black >; Ulrich= Herberg >; Abdussalam Bary= un >; "Dearlo= ve, Christopher (UK)" >; "manet@ietf.org List" > Sent: Friday, November 2, 2012 11:21 AM Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol so =85 should we start with a completely new document then ? On Nov 2, 2012, at 1:16 PM, Jon Black wrote: This seems to make good sense. The name should not be issue. We need a go= od solid base to start from. It would appear that if there are working int= eroperable implementation based on the LOADng draft then this indicates tha= t the draft is implementable. Again, having read both I could build someth= ing based on the LOADng draft and I (and I'm only talking for me) couldn't = based on the DYMO draft. I much prefer starting with something simple and understandable and adding = what is missing rather than starting with something more difficult to under= stand trying to remove things that are not needed. Jon ________________________________ From: Ulrich Herberg > To: Abdussalam Baryun > Cc: "Dearlove, Christopher (UK)" >; "manet@ietf.org" > Sent: Friday, November 2, 2012 10:34 AM Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol Hi Abdussalam, there was indeed some hesitance to change the name from some of the authors= (not me). I cannot speak for them here. My intuition is that if the name o= f the protocol is the only factor that avoids the reactive protocol from pr= oceeding in the WG, this can be solved. As far as I can see from the discussions so far, there is a clear consensus= that option 3 is not viable. Now, if we want to proceed with the reactive = document, the question is from which document to start. Chris mentioned tha= t even if we wanted the specification of 100%, it would be far quicker to s= tart from the LOADng draft. I propose that we can start working based on th= e LOADng draft (possibly rename it?), look at each item that is in DYMO and= consider whether and in which way it should be incorporated in the draft. Best Ulrich On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun > wrote: Hi Ulrich, I think that Chris's proposal was not accepted by LOADng co-authors as I un= derstood from following up the WG history (they don't agree to change the n= ame of protocol). As you are one co-author do I understand that you support= the Chris's proposal, AB On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg > wrote: Dear Chris, personally, what you propose makes sense to me. Regards Ulrich On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" > wrote: > Before making a proposal, I'm going to introduce a distinction here betwe= en the DYMO and LOADng documents and protocols. > > I'm of the opinion that the LOADng document is a greatly superior present= ation to the DYMO document. (I'm not really interested in why that has come= about.) > > I think that regardless of whether one makes design decisions favouring D= YMO or LOADng where they differ - and let's not forget they overlap a lot -= it would actually be easier to modify the LOADng document to specify DYMO = than it would be to modify the DYMO document to achieve that. And in practi= ce I think if making decisions it is unlikely that all would favour DYMO ov= er LOADng. > > So what I think would be best for the WG is not a simply "option 1" or ev= en (as it may appear I'm suggesting, but I'm not) "option 2" but rather to= agree to take the LOADng document, and a list of where DYMO and LOADng dif= fer, and thrash out where they do, what the WG reactive protocol should do = - either as a definite choice, or as an option (but not too many options pl= ease- and some could be separate specifications). > > This would not of course be LOADng, so we'd have to change the document n= ame. And there I suggest we have a candidate name - AODVv2. (Which is why I= have recently taken to saying DYMO when referring to that document.) After= all, the one thing we are agreed on is that the protocol being developed i= s derived from AODV. > > The editors of this new document would have to agree that what goes in it= is WG consensus (which should follow proper technical consideration of the= issues). If they found it impossible to have other than their way to do th= ings, they'd have to move on. If that left no one editing it, obviously we = don't have a consensus of people prepared to do the work and option 3 would= win. > > So now I'm partly off the fence I've been sitting on. But only partly. I = haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standar= d, IRREPs as an option in the main draft, IRREPs as a separate draft option= , no IRREPs. I'd like to move on to those discussions. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | htt= p://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > ******************************************************************** > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204D7E5xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1C565CB8FA899C49AF6D813E9747BC64@cisco.com> Content-Transfer-Encoding: quoted-printable I was about to ask the same question =85 merge did not happen for a number = of reasons (that I do not all know by the way), thus the questions
from the chairs. I fail to understand why we cannot start from the WG = document (result of years of work) and quickly improve it. By the way, as
a reminder, I'd rather do the right thing that rushing out.

On Nov 2, 2012, at 7:45 PM, Ulrich Herberg wrote:

C=E9dric,

the merge did not fail for technical but for process reasons. We = offered Charlie to be editor, together with Thomas. Charlie is already auth= or of LOADng. In my opinion (I can't speak for anyone else), that has not c= hanged. 
If we start the merge from the LOADng document, we would be far quicke= r to come to an RFC. As said, we can then look at each option, see if it's = suitable or not, and if it should be part of the core or rather be in a com= panion document.

Best
Ulrich



On Fri, Nov 2, 2012 at 4:31 PM, C Chauvenet <c.chauvene= t@watteco.com> wrote:
One thing that popped up in my mind :&n= bsp;

Are we trying to do the merge between DYMO and LOADng that has previou= sly failed ??

Regardless from which document we start, I understood (from Charlie ma= ssages) that LOADng authors were not OK to merge their document with functi= onalities from DYMO . Did I missed something here ?

C=E9dric.

Le 2 nov. 2012 =E0 23:41, C Chauvenet a =E9crit :

Hi all, 

If we add mechanisms to LOADng or prune some from DYMO, we end up with= a different protocol, so I think that we will need to change the name of t= he resulting protocol. I support the AODVv2 naming for the reactive protoco= l of MANET, if chairs decide to go forward and do not take option 3).

It seems that charlie is working hard on updating the DYMO draft, by a= ddressing reviews of the document. These reviews contains most of the impro= vements (readability, RFC5444 compliance ....) that people found missing in= DYMO. I think that would make sense to wait for the next update of DYMO before choosing between LOADng and DYM= O. I think that the WG want something good, rather than something quick.&nb= sp;
In addition, we would benefit from the work that charlie is currently = doing, rather that skip it if we made a decision based on the actual DYMO v= ersion.

C=E9dric.

Le 2 nov. 2012 =E0 22:10, Jon Black a =E9crit :

It is not completely new and it is much more mature.  It has been = being developed for quite some time, it has implementations, it has interop= erability.  Age of a document is not a good criteria.  Something can be written quite a long time ago and no= thing done on it.  Another document/protocol may come along, gain crit= ical mass, gain experience and even though younger may be a much better sta= rting point.

Jon

From: JP Vasseur (jvasseur) = <jvasseur@cisco.= com>
To: Jon Black <jblack.ietf@yahoo.com&= gt;; Ulrich Herberg <ulrich@herberg.name>; Abdussalam Baryun <abdussalambaryun@gmail.com>; "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>; = "manet@ietf.org List" <manet@= ietf.org>
Sent: Friday, November 2, 20= 12 11:21 AM
Subject: Re: [manet] A propo= sal - differentiating the document and the protocol

so =85 should we start with a completely new document then ?

On Nov 2, 2012, at 1:16 PM, Jon Black wrote:

This seems to make good sense.  The name should not be issue. = ; We need a good solid base to start from.  It would appear that if th= ere are working interoperable implementation based on the LOADng draft then this indicates that the draft is implementable.&n= bsp; Again, having read both I could build something based on the LOADng dr= aft and I (and I'm only talking for me) couldn't based on the DYMO draft.
I much prefer starting with something simple and understandable and adding = what is missing rather than starting with something more difficult to under= stand trying to remove things that are not needed.

Jon


From: Ulrich Herberg <ulri= ch@herberg.name>
To: Abdussalam Baryun <abdussalambaryun@gmail.com>
Cc: "Dearlove, Christop= her (UK)" <Chris.Dearlove@baesystems.com>; "manet@ie= tf.org" <m= anet@ietf.org>
Sent: Friday, November 2, 20= 12 10:34 AM
Subject: Re: [manet] A propo= sal - differentiating the document and the protocol

Hi Abdussalam,

there was indeed some hesitance to change the name from some of the au= thors (not me). I cannot speak for them here. My intuition is that if the n= ame of the protocol is the only factor that avoids the reactive protocol fr= om proceeding in the WG, this can be solved.

As far as I can see from the discussions so far, there is a clear cons= ensus that option 3 is not viable. Now, if we want to proceed with the reac= tive document, the question is from which document to start. Chris mentione= d that even if we wanted the specification of 100%, it would be far quicker to start from the LOADng draft. I pr= opose that we can start working based on the LOADng draft (possibly re= name it?), look at each item that is in DYMO and consider whether and in wh= ich way it should be incorporated in the draft. 

Best
Ulrich



On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun &l= t;abdussalambaryun@gmail.com> wrote:
Hi Ulrich,
 
I think that Chris's proposal was not accepted by LOADng co-autho= rs as I understood from following up the WG history (they don't agree to ch= ange the name of protocol). As you are one co-author do I understand that y= ou support the Chris's proposal,
AB
On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg <<= a rel=3D"nofollow" href=3D"mailto:ulrich@herberg.name" target=3D"_blank">ul= rich@herberg.name> wrote:
Dear Chris,

personally, what you propose makes sense to me.


Regards
Ulrich

On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> wrote:

> Before making a proposal, I'm going to introduce a distinction here be= tween the DYMO and LOADng documents and protocols.
>
> I'm of the opinion that the LOADng document is a greatly superior pres= entation to the DYMO document. (I'm not really interested in why that has c= ome about.)
>
> I think that regardless of whether one makes design decisions favourin= g DYMO or LOADng where they differ - and let's not forget they overlap a lo= t - it would actually be easier to modify the LOADng document to specify DY= MO than it would be to modify the DYMO document to achieve that. And in practice I think if making decisions it i= s unlikely that all would favour DYMO over LOADng.
>
> So what I think would be best for the WG is not a simply "option = 1" or even (as it may appear I'm suggesting, but  I'm not) "= option 2" but rather to agree to take the LOADng document, and a list = of where DYMO and LOADng differ, and thrash out where they do, what the WG reactive protocol should do - either as a definite choice, or = as an option (but not too many options please- and some could be separate s= pecifications).
>
> This would not of course be LOADng, so we'd have to change the documen= t name. And there I suggest we have a candidate name - AODVv2. (Which is wh= y I have recently taken to saying DYMO when referring to that document.) Af= ter all, the one thing we are agreed on is that the protocol being developed is derived from AODV.
>
> The editors of this new document would have to agree that what goes in= it is WG consensus (which should follow proper technical consideration of = the issues). If they found it impossible to have other than their way to do= things, they'd have to move on. If that left no one editing it, obviously we don't have a consensus of people= prepared to do the work and option 3 would win.
>
> So now I'm partly off the fence I've been sitting on. But only partly.= I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as stan= dard, IRREPs as an option in the main draft, IRREPs as a separate draft opt= ion, no IRREPs. I'd like to move on to those discussions.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | h= ttp://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
>
> ******************************************************************** > 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.
> ******************************************************************** >
> _______________________________________________
> manet mailing list
> m= anet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@= ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@= ietf.org
https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@= ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A772204D7E5xmbrcdx02ciscoc_-- From jvasseur@cisco.com Sat Nov 3 01:37:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B5821F9CA4 for ; Sat, 3 Nov 2012 01:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcPV-7pGrSNy for ; Sat, 3 Nov 2012 01:37:01 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id F027421F9C6F for ; Sat, 3 Nov 2012 01:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28821; q=dns/txt; s=iport; t=1351931821; x=1353141421; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1sbhYRXrW/aQImAMgrXmiDeyVJ0Fr52n95Ym3PaU/1E=; b=WgwBrf+NB5WD1LUR2B7zTRQdPfy93pWWG+UiYzN7H2vr9OA9JGcbZVb4 y5FjeIub/Y5HO4fFRdA4y808RsnG0MutKG5ViQICo9+D5cLkMyM16OtCf iI9Agx2x1MtU9XQ2EM3VOwPzE2AAGDWvuZ9jt0dPlL22Ost0qi7xKsswk M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAA3XlFCtJV2Z/2dsb2JhbABEgkmuQ5IogQiCHgEBAQMBAQEBDwFCFwIIAwULAgEIBwoEAQELFgcHIQYLEwEJCAIEDgUIFgSHVgMJBgucBpYSDYlUixloFIVHYQOUJgSNBIMmgWuCb4FbCRce X-IronPort-AV: E=Sophos;i="4.80,704,1344211200"; d="scan'208,217";a="138194133" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 03 Nov 2012 08:36:58 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA38awvi015539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 08:36:58 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 03:36:58 -0500 From: "JP Vasseur (jvasseur)" To: Jiazi YI Thread-Topic: [manet] A proposal - differentiating the document and the protocol Thread-Index: AQHNuZ5ihycIneFUb0CEyNUKY+/KlQ== Date: Sat, 3 Nov 2012 08:36:57 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204D80B@xmb-rcd-x02.cisco.com> References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> <1351876587.86080.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204C69E@xmb-rcd-x02.cisco.com> <1351890653.89343.YahooMailNeo@web160603.mail.bf1.yahoo.com> <97B69B30E0EF244B940B65EA541E3F2D21572F63@DBXPRD0510MB395.eurprd05.prod.outlook.com> <97B69B30E0EF244B940B65EA541E3F2D215731FF@DBXPRD0510MB395.eurprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.169] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--56.014900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204D80Bxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: =?Windows-1252?Q?Axel_Colin_de_Verdi=E8re?= , "manet@ietf.org List" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 08:37:03 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204D80Bxmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, On Nov 2, 2012, at 7:45 PM, Jiazi YI wrote: Hi Cedric, The LOADng always welcome good ideas from DYMO if it can help improving the= protocol. But Charlie insists starting from DYMO. I cannot speak for Charlie, but you may not have missed that many of this l= ist insist on starting with the WG document and welcome improvements. I seriously do not think that one can chime in wi= th an individual submission, claim that the WG document is not good and strongly request to replace it by they document= . This is ignoring years of excellent work from a WG. What I believe is that, the WG should begin with the document in better sha= pe, as suggested by Chris. best Jiazi On Nov 3, 2012, at 12:31 AM, C Chauvenet > wrote: One thing that popped up in my mind : Are we trying to do the merge between DYMO and LOADng that has previously f= ailed ?? Regardless from which document we start, I understood (from Charlie massage= s) that LOADng authors were not OK to merge their document with functionali= ties from DYMO . Did I missed something here ? C=E9dric. Le 2 nov. 2012 =E0 23:41, C Chauvenet a =E9crit : Hi all, If we add mechanisms to LOADng or prune some from DYMO, we end up with a di= fferent protocol, so I think that we will need to change the name of the re= sulting protocol. I support the AODVv2 naming for the reactive protocol of = MANET, if chairs decide to go forward and do not take option 3). It seems that charlie is working hard on updating the DYMO draft, by addres= sing reviews of the document. These reviews contains most of the improvemen= ts (readability, RFC5444 compliance ....) that people found missing in DYMO= . I think that would make sense to wait for the next update of DYMO before = choosing between LOADng and DYMO. I think that the WG want something good, = rather than something quick. In addition, we would benefit from the work that charlie is currently doing= , rather that skip it if we made a decision based on the actual DYMO versio= n. C=E9dric. Le 2 nov. 2012 =E0 22:10, Jon Black a =E9crit : It is not completely new and it is much more mature. It has been being dev= eloped for quite some time, it has implementations, it has interoperability= . Age of a document is not a good criteria. Something can be written quit= e a long time ago and nothing done on it. Another document/protocol may co= me along, gain critical mass, gain experience and even though younger may b= e a much better starting point. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black >; Ulrich= Herberg >; Abdussalam Bary= un >; "Dearlo= ve, Christopher (UK)" >; "manet@ietf.org List" > Sent: Friday, November 2, 2012 11:21 AM Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol so =85 should we start with a completely new document then ? On Nov 2, 2012, at 1:16 PM, Jon Black wrote: This seems to make good sense. The name should not be issue. We need a go= od solid base to start from. It would appear that if there are working int= eroperable implementation based on the LOADng draft then this indicates tha= t the draft is implementable. Again, having read both I could build someth= ing based on the LOADng draft and I (and I'm only talking for me) couldn't = based on the DYMO draft. I much prefer starting with something simple and understandable and adding = what is missing rather than starting with something more difficult to under= stand trying to remove things that are not needed. Jon ________________________________ From: Ulrich Herberg > To: Abdussalam Baryun > Cc: "Dearlove, Christopher (UK)" >; "manet@ietf.org" > Sent: Friday, November 2, 2012 10:34 AM Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol Hi Abdussalam, there was indeed some hesitance to change the name from some of the authors= (not me). I cannot speak for them here. My intuition is that if the name o= f the protocol is the only factor that avoids the reactive protocol from pr= oceeding in the WG, this can be solved. As far as I can see from the discussions so far, there is a clear consensus= that option 3 is not viable. Now, if we want to proceed with the reactive = document, the question is from which document to start. Chris mentioned tha= t even if we wanted the specification of 100%, it would be far quicker to s= tart from the LOADng draft. I propose that we can start working based on th= e LOADng draft (possibly rename it?), look at each item that is in DYMO and= consider whether and in which way it should be incorporated in the draft. Best Ulrich On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun > wrote: Hi Ulrich, I think that Chris's proposal was not accepted by LOADng co-authors as I un= derstood from following up the WG history (they don't agree to change the n= ame of protocol). As you are one co-author do I understand that you support= the Chris's proposal, AB On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg > wrote: Dear Chris, personally, what you propose makes sense to me. Regards Ulrich On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" > wrote: > Before making a proposal, I'm going to introduce a distinction here betwe= en the DYMO and LOADng documents and protocols. > > I'm of the opinion that the LOADng document is a greatly superior present= ation to the DYMO document. (I'm not really interested in why that has come= about.) > > I think that regardless of whether one makes design decisions favouring D= YMO or LOADng where they differ - and let's not forget they overlap a lot -= it would actually be easier to modify the LOADng document to specify DYMO = than it would be to modify the DYMO document to achieve that. And in practi= ce I think if making decisions it is unlikely that all would favour DYMO ov= er LOADng. > > So what I think would be best for the WG is not a simply "option 1" or ev= en (as it may appear I'm suggesting, but I'm not) "option 2" but rather to= agree to take the LOADng document, and a list of where DYMO and LOADng dif= fer, and thrash out where they do, what the WG reactive protocol should do = - either as a definite choice, or as an option (but not too many options pl= ease- and some could be separate specifications). > > This would not of course be LOADng, so we'd have to change the document n= ame. And there I suggest we have a candidate name - AODVv2. (Which is why I= have recently taken to saying DYMO when referring to that document.) After= all, the one thing we are agreed on is that the protocol being developed i= s derived from AODV. > > The editors of this new document would have to agree that what goes in it= is WG consensus (which should follow proper technical consideration of the= issues). If they found it impossible to have other than their way to do th= ings, they'd have to move on. If that left no one editing it, obviously we = don't have a consensus of people prepared to do the work and option 3 would= win. > > So now I'm partly off the fence I've been sitting on. But only partly. I = haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standar= d, IRREPs as an option in the main draft, IRREPs as a separate draft option= , no IRREPs. I'd like to move on to those discussions. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | htt= p://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > ******************************************************************** > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204D80Bxmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5552015BA58551488600E383EA950A5B@cisco.com> Content-Transfer-Encoding: quoted-printable Hi,

On Nov 2, 2012, at 7:45 PM, Jiazi YI wrote:

Hi Cedric, 

The LOADng always welcome good ideas fro= m DYMO if it can help improving the protocol. 
But Charlie insists starting from DYMO.&= nbsp;

I cannot speak for Charlie, but you may not have missed that many of t= his list insist on starting with the WG document
and welcome improvements. I seriously do not think that one can chime = in with an individual submission, claim that the
WG document is not good and strongly request to replace it by they doc= ument. This is ignoring years of excellent work
from a WG.

What I believe is that, the WG should be= gin with the document in better shape, as suggested by Chris. 

best

Jiazi

On Nov 3, 2012, at 12:31 AM, C Chauvenet <c.chauvenet@watteco.com> wrote:

One thing that popped up in my mind : 

Are we trying to do the merge between DYMO and LOADng that has previou= sly failed ??

Regardless from which document we start, I understood (from Charlie ma= ssages) that LOADng authors were not OK to merge their document with functi= onalities from DYMO . Did I missed something here ?

C=E9dric.

Le 2 nov. 2012 =E0 23:41, C Chauvenet a =E9crit :

Hi all, 

If we add mechanisms to LOADng or prune some from DYMO, we end up with= a different protocol, so I think that we will need to change the name of t= he resulting protocol. I support the AODVv2 naming for the reactive protoco= l of MANET, if chairs decide to go forward and do not take option 3).

It seems that charlie is working hard on updating the DYMO draft, by a= ddressing reviews of the document. These reviews contains most of the impro= vements (readability, RFC5444 compliance ....) that people found missing in= DYMO. I think that would make sense to wait for the next update of DYMO before choosing between LOADng and DYM= O. I think that the WG want something good, rather than something quick.&nb= sp;
In addition, we would benefit from the work that charlie is currently = doing, rather that skip it if we made a decision based on the actual DYMO v= ersion.

C=E9dric.

Le 2 nov. 2012 =E0 22:10, Jon Black a =E9crit :

It is not completely new and it is much more mature.  It has been bein= g developed for quite some time, it has implementations, it has interoperab= ility.  Age of a document is not a good criteria.  Something can = be written quite a long time ago and nothing done on it.  Another document/protocol may come along, gain critical mass,= gain experience and even though younger may be a much better starting poin= t.

Jon

From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>; Ulrich Herberg <ulrich@herberg.name>; Abdussalam Baryun <abdussalambaryun@gmail.com>; "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>; "manet@ietf.org List" <manet@ietf.org>
Sent: Friday, November 2, = 2012 11:21 AM
Subject: Re: [manet] A pro= posal - differentiating the document and the protocol

so =85 should we start with a completely new document then ?

On Nov 2, 2012, at 1:16 PM, Jon Black wrote:

This seems to make good sense.  The name should not be issue.  We= need a good solid base to start from.  It would appear that if there = are working interoperable implementation based on the LOADng draft then thi= s indicates that the draft is implementable.  Again, having read both I could build something based on the LOADng draft and I (= and I'm only talking for me) couldn't based on the DYMO draft.

I much prefer starting with something simple and understandable and adding = what is missing rather than starting with something more difficult to under= stand trying to remove things that are not needed.

Jon


From: Ulrich Herberg <ulrich@herberg.name>
To: Abdussalam Baryun <<= a rel=3D"nofollow" ymailto=3D"mailto:abdussalambaryun@gmail.com" target=3D"= _blank" href=3D"mailto:abdussalambaryun@gmail.com">abdussalambaryun@gmail.c= om>
Cc: "Dearlove, Christo= pher (UK)" <Chris.Dearlove@baesystems.com>; "manet@ietf.org" <manet@ietf.org>
Sent: Friday, November 2, 2= 012 10:34 AM
Subject: Re: [manet] A prop= osal - differentiating the document and the protocol

Hi Abdussalam,

there was indeed some hesitance to change the name from some of the au= thors (not me). I cannot speak for them here. My intuition is that if the n= ame of the protocol is the only factor that avoids the reactive protocol fr= om proceeding in the WG, this can be solved.

As far as I can see from the discussions so far, there is a clear cons= ensus that option 3 is not viable. Now, if we want to proceed with the reac= tive document, the question is from which document to start. Chris mentione= d that even if we wanted the specification of 100%, it would be far quicker to start from the LOADng draft. I pr= opose that we can start working based on the LOADng draft (possibly re= name it?), look at each item that is in DYMO and consider whether and in wh= ich way it should be incorporated in the draft. 

Best
Ulrich



On Fri, Nov 2, 2012 at 9:17 AM, Abd= ussalam Baryun <a= bdussalambaryun@gmail.com> wrote:
Hi Ulrich,
 
I think that Chris's proposal was not accepted by LOADng co-autho= rs as I understood from following up the WG history (they don't agree to ch= ange the name of protocol). As you are one co-author do I understand that y= ou support the Chris's proposal,
AB
On Fri, Nov 2, 2012 at 2:41 PM, Ulr= ich Herberg <ulrich@herberg.= name> wrote:
Dear Chris,

personally, what you propose makes sense to me.


Regards
Ulrich

On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesyste= ms.com> wrote:

> Before making a proposal, I'm going to introduce a distinction here be= tween the DYMO and LOADng documents and protocols.
>
> I'm of the opinion that the LOADng document is a greatly superior pres= entation to the DYMO document. (I'm not really interested in why that has c= ome about.)
>
> I think that regardless of whether one makes design decisions favourin= g DYMO or LOADng where they differ - and let's not forget they overlap a lo= t - it would actually be easier to modify the LOADng document to specify DY= MO than it would be to modify the DYMO document to achieve that. And in practice I think if making decisions it i= s unlikely that all would favour DYMO over LOADng.
>
> So what I think would be best for the WG is not a simply "option = 1" or even (as it may appear I'm suggesting, but  I'm not) "= option 2" but rather to agree to take the LOADng document, and a list = of where DYMO and LOADng differ, and thrash out where they do, what the WG reactive protocol should do - either as a definite choice, or = as an option (but not too many options please- and some could be separate s= pecifications).
>
> This would not of course be LOADng, so we'd have to change the documen= t name. And there I suggest we have a candidate name - AODVv2. (Which is wh= y I have recently taken to saying DYMO when referring to that document.) Af= ter all, the one thing we are agreed on is that the protocol being developed is derived from AODV.
>
> The editors of this new document would have to agree that what goes in= it is WG consensus (which should follow proper technical consideration of = the issues). If they found it impossible to have other than their way to do= things, they'd have to move on. If that left no one editing it, obviously we don't have a consensus of people= prepared to do the work and option 3 would win.
>
> So now I'm partly off the fence I've been sitting on. But only partly.= I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as stan= dard, IRREPs as an option in the main draft, IRREPs as a separate draft opt= ion, no IRREPs. I'd like to move on to those discussions.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
>
> ******************************************************************** > 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.
> ******************************************************************** >
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A772204D80Bxmbrcdx02ciscoc_-- From prvs=647a504e0=mukul@uwm.edu Sat Nov 3 02:27:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77F221F9C9B for ; Sat, 3 Nov 2012 02:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Al7XeNXVBE35 for ; Sat, 3 Nov 2012 02:27:41 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED2A21F9C8F for ; Sat, 3 Nov 2012 02:27:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAADjlFB/AAAB/2dsb2JhbABEhheqdJVOAQEBAwEBAQEgMhcCCAMFBw8RBAEBAwINGQIjBh4KCAYTHodaAwkGC6k8iF8NTIkIgSCJeWgUhRWBEwOIWotMBIFRizOFEYMNgT0JFx4 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 5BC6C1209AD; Sat, 3 Nov 2012 04:27:40 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id io3K6qgUQX3e; Sat, 3 Nov 2012 04:27:39 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id A540D1209A7; Sat, 3 Nov 2012 04:27:39 -0500 (CDT) Date: Sat, 3 Nov 2012 04:27:39 -0500 (CDT) From: Mukul Goyal To: "JP Vasseur (jvasseur)" Message-ID: <1147137266.197841.1351934859577.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204D73B@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: "Christopher Dearlove \(UK\)" , "manet@ietf.org List" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 09:27:42 -0000 > I think that would make sense to wait for the next update of DYMO before = choosing between LOADng and DYMO. I think that the WG want something good, = rather than something quick. =20 I totally agree. Thanks Mukul ----- Original Message ----- From: "JP Vasseur (jvasseur)" To: "C Chauvenet" Cc: "Christopher Dearlove (UK)" , "manet@iet= f.org List" Sent: Saturday, November 3, 2012 3:26:26 AM Subject: Re: [manet] A proposal - differentiating the document and t= he protocol Hi Cedrix,=20 Completely agreeing with you; this is what I called option 1+.=20 Thanks.=20 JP.=20 On Nov 2, 2012, at 6:41 PM, C Chauvenet wrote:=20 Hi all, =20 If we add mechanisms to LOADng or prune some from DYMO, we end up with a di= fferent protocol, so I think that we will need to change the name of the re= sulting protocol. I support the AODVv2 naming for the reactive protocol of = MANET, if chairs decide to go forward and do not take option 3).=20 It seems that charlie is working hard on updating the DYMO draft, by addres= sing reviews of the document. These reviews contains most of the improvemen= ts (readability, RFC5444 compliance ....) that people found missing in DYMO= . I think that would make sense to wait for the next update of DYMO before = choosing between LOADng and DYMO. I think that the WG want something good, = rather than something quick. =20 In addition, we would benefit from the work that charlie is currently doing= , rather that skip it if we made a decision based on the actual DYMO versio= n.=20 C=C3=A9dric.=20 Le 2 nov. 2012 =C3=A0 22:10, Jon Black a =C3=A9crit :=20 It is not completely new and it is much more mature. It has been being dev= eloped for quite some time, it has implementations, it has interoperability= . Age of a document is not a good criteria. Something can be written quit= e a long time ago and nothing done on it. Another document/protocol may co= me along, gain critical mass, gain experience and even though younger may b= e a much better starting point.=20 Jon=20 From: JP Vasseur (jvasseur) < jvasseur@cisco.com >=20 To: Jon Black < jblack.ietf@yahoo.com >; Ulrich Herberg < ulrich@herberg.na= me >; Abdussalam Baryun < abdussalambaryun@gmail.com >; "Dearlove, Christop= her (UK)" < Chris.Dearlove@baesystems.com >; " manet@ietf.org List" < manet= @ietf.org >=20 Sent: Friday, November 2, 2012 11:21 AM=20 Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol=20 so =E2=80=A6 should we start with a completely new document then ?=20 On Nov 2, 2012, at 1:16 PM, Jon Black wrote:=20 This seems to make good sense. The name should not be issue. We need a go= od solid base to start from. It would appear that if there are working int= eroperable implementation based on the LOADng draft then this indicates tha= t the draft is implementable. Again, having read both I could build someth= ing based on the LOADng draft and I (and I'm only talking for me) couldn't = based on the DYMO draft.=20 I much prefer starting with something simple and understandable and adding = what is missing rather than starting with something more difficult to under= stand trying to remove things that are not needed.=20 Jon=20 From: Ulrich Herberg < ulrich@herberg.name >=20 To: Abdussalam Baryun < abdussalambaryun@gmail.com >=20 Cc: "Dearlove, Christopher (UK)" < Chris.Dearlove@baesystems.com >; " manet= @ietf.org " < manet@ietf.org >=20 Sent: Friday, November 2, 2012 10:34 AM=20 Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol=20 Hi Abdussalam,=20 there was indeed some hesitance to change the name from some of the authors= (not me). I cannot speak for them here. My intuition is that if the name o= f the protocol is the only factor that avoids the reactive protocol from pr= oceeding in the WG, this can be solved.=20 As far as I can see from the discussions so far, there is a clear consensus= that option 3 is not viable. Now, if we want to proceed with the reactive = document, the question is from which document to start. Chris mentioned tha= t even if we wanted the specification of 100%, it would be far quicker to s= tart from the LOADng draft. I propose that we can start working based on th= e LOADng draft (possibly rename it?), look at each item that is in DYMO and= consider whether and in which way it should be incorporated in the draft. = =20 Best=20 Ulrich=20 On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun < abdussalambaryun@gmail.= com > wrote:=20 Hi Ulrich,=20 =20 I think that Chris's proposal was not accepted by LOADng co-authors as I un= derstood from following up the WG history (they don't agree to change the n= ame of protocol). As you are one co-author do I understand that you support= the Chris's proposal,=20 AB=20 On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg < ulrich@herberg.name > wrot= e:=20 Dear Chris,=20 personally, what you propose makes sense to me.=20 Regards=20 Ulrich=20 On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" < Chris.Dearlove@baes= ystems.com > wrote:=20 > Before making a proposal, I'm going to introduce a distinction here betwe= en the DYMO and LOADng documents and protocols.=20 >=20 > I'm of the opinion that the LOADng document is a greatly superior present= ation to the DYMO document. (I'm not really interested in why that has come= about.)=20 >=20 > I think that regardless of whether one makes design decisions favouring D= YMO or LOADng where they differ - and let's not forget they overlap a lot -= it would actually be easier to modify the LOADng document to specify DYMO = than it would be to modify the DYMO document to achieve that. And in practi= ce I think if making decisions it is unlikely that all would favour DYMO ov= er LOADng.=20 >=20 > So what I think would be best for the WG is not a simply "option 1" or ev= en (as it may appear I'm suggesting, but I'm not) "option 2" but rather to= agree to take the LOADng document, and a list of where DYMO and LOADng dif= fer, and thrash out where they do, what the WG reactive protocol should do = - either as a definite choice, or as an option (but not too many options pl= ease- and some could be separate specifications).=20 >=20 > This would not of course be LOADng, so we'd have to change the document n= ame. And there I suggest we have a candidate name - AODVv2. (Which is why I= have recently taken to saying DYMO when referring to that document.) After= all, the one thing we are agreed on is that the protocol being developed i= s derived from AODV.=20 >=20 > The editors of this new document would have to agree that what goes in it= is WG consensus (which should follow proper technical consideration of the= issues). If they found it impossible to have other than their way to do th= ings, they'd have to move on. If that left no one editing it, obviously we = don't have a consensus of people prepared to do the work and option 3 would= win.=20 >=20 > So now I'm partly off the fence I've been sitting on. But only partly. I = haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standar= d, IRREPs as an option in the main draft, IRREPs as a separate draft option= , no IRREPs. I'd like to move on to those discussions.=20 >=20 > --=20 > Christopher Dearlove=20 > Senior Principal Engineer, Communications Group=20 > Communications, Networks and Image Analysis Capability=20 > BAE Systems Advanced Technology Centre=20 > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK=20 > Tel: +44 1245 242194 | Fax: +44 1245 242124=20 > chris.dearlove@baesystems.com | http://www.baesystems.com=20 >=20 > BAE Systems (Operations) Limited=20 > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK=20 > Registered in England & Wales No: 1996687=20 >=20 >=20 >=20 > ********************************************************************=20 > This email and any attachments are confidential to the intended=20 > recipient and may also be privileged. If you are not the intended=20 > recipient please delete it from your system and notify the sender.=20 > You should not copy it or use it for any purpose nor disclose or=20 > distribute its contents to any other person.=20 > ********************************************************************=20 >=20 > _______________________________________________=20 > manet mailing list=20 > manet@ietf.org=20 > https://www.ietf.org/mailman/listinfo/manet=20 _______________________________________________=20 manet mailing list=20 manet@ietf.org=20 https://www.ietf.org/mailman/listinfo/manet=20 _______________________________________________=20 manet mailing list=20 manet@ietf.org=20 https://www.ietf.org/mailman/listinfo/manet=20 _______________________________________________=20 manet mailing list=20 manet@ietf.org=20 https://www.ietf.org/mailman/listinfo/manet=20 _______________________________________________=20 manet mailing list=20 manet@ietf.org=20 https://www.ietf.org/mailman/listinfo/manet=20 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From christopher.dearlove@googlemail.com Sat Nov 3 04:07:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A632521F9C77 for ; Sat, 3 Nov 2012 04:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ch1OHkBTrnwV for ; Sat, 3 Nov 2012 04:07:10 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0643421F9C76 for ; Sat, 3 Nov 2012 04:07:08 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so1607217wib.13 for ; Sat, 03 Nov 2012 04:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=hzh8B6YforVrGn6FKIcwRFOu/P5HFYwiDl3d8epkESE=; b=c9UStwEmHuesXj61gBRYrNKn7vAXqgpcnzc3Nl6ROvDKoS+wJBqAbj74jgn+eApoUo MT65W2mYXRT1sUM7KKqT5NeKRAlZvKbYFKoc6aX1Vw7EUwaP1fhRRR5HyN+Ygm3t4mHr QgMnqZ8XLX5iEydBS9bAYBmmi0Go/MWSBOkz/RfSwsGLv6UZtXpqif3jPkXL4rTHZsR+ KRs3TK3cFVwzxYE/gsZ/jrefBo8jom9nvFM5dyoZH8nTWTcgVllc3yPnrH8y5b24g1tI btUQ+7zZI5RgQeJSTeW2XawHWWAlc3p0LRZ1z7txOwBxEAgIMSX1XIXO6zFfspA9EjMc s/3w== Received: by 10.216.207.160 with SMTP id n32mr1622053weo.61.1351940827773; Sat, 03 Nov 2012 04:07:07 -0700 (PDT) Received: from [10.38.186.177] ([82.132.248.63]) by mx.google.com with ESMTPS id ea9sm2244328wib.11.2012.11.03.04.07.01 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 03 Nov 2012 04:07:07 -0700 (PDT) References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> <1351876587.86080.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204C69E@xmb-rcd-x02.cisco.com> <1351890653.89343.YahooMailNeo@web160603.mail.bf1.yahoo.com> <97B69B30E0EF244B940B65EA541E3F2D21572F63@DBXPRD0510MB395.eurprd05.prod.outlook.com> <97B69B30E0EF244B940B65EA541E3F2D215731FF@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D80B@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204D80B@xmb-rcd-x02.cisco.com> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-2--28518894 Message-Id: <0A918FF2-302F-4C6E-A8E3-85F357209DB6@gmail.com> X-Mailer: iPhone Mail (8B117) From: Christopher Dearlove Date: Sat, 3 Nov 2012 11:07:06 +0000 To: "JP Vasseur (jvasseur)" Cc: =?utf-8?Q?Axel_Colin_de_Verdi=C3=A8re?= , "manet@ietf.org List" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 11:07:12 -0000 --Apple-Mail-2--28518894 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sunk cost fallacy. It's not important how much work was spent on a document.= What matters is what state the document is in. --=20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) On 3 Nov 2012, at 08:36, "JP Vasseur (jvasseur)" wrote:= > Hi, >=20 > On Nov 2, 2012, at 7:45 PM, Jiazi YI wrote: >=20 >> Hi Cedric,=20 >>=20 >> The LOADng always welcome good ideas from DYMO if it can help improving t= he protocol.=20 >> But Charlie insists starting from DYMO.=20 >=20 > I cannot speak for Charlie, but you may not have missed that many of this l= ist insist on starting with the WG document > and welcome improvements. I seriously do not think that one can chime in w= ith an individual submission, claim that the > WG document is not good and strongly request to replace it by they documen= t. This is ignoring years of excellent work > from a WG. >=20 >> What I believe is that, the WG should begin with the document in better s= hape, as suggested by Chris.=20 >>=20 >> best >>=20 >> Jiazi >>=20 >> On Nov 3, 2012, at 12:31 AM, C Chauvenet wrote:= >>=20 >>> One thing that popped up in my mind :=20 >>>=20 >>> Are we trying to do the merge between DYMO and LOADng that has previousl= y failed ?? >>>=20 >>> Regardless from which document we start, I understood (from Charlie mass= ages) that LOADng authors were not OK to merge their document with functiona= lities from DYMO . Did I missed something here ? >>>=20 >>> C=C3=A9dric. >>>=20 >>> Le 2 nov. 2012 =C3=A0 23:41, C Chauvenet a =C3=A9crit : >>>=20 >>>> Hi all,=20 >>>>=20 >>>> If we add mechanisms to LOADng or prune some from DYMO, we end up with a= different protocol, so I think that we will need to change the name of the r= esulting protocol. I support the AODVv2 naming for the reactive protocol of M= ANET, if chairs decide to go forward and do not take option 3). >>>>=20 >>>> It seems that charlie is working hard on updating the DYMO draft, by ad= dressing reviews of the document. These reviews contains most of the improve= ments (readability, RFC5444 compliance ....) that people found missing in DY= MO. I think that would make sense to wait for the next update of DYMO before= choosing between LOADng and DYMO. I think that the WG want something good, r= ather than something quick.=20 >>>> In addition, we would benefit from the work that charlie is currently d= oing, rather that skip it if we made a decision based on the actual DYMO ver= sion. >>>>=20 >>>> C=C3=A9dric. >>>>=20 >>>> Le 2 nov. 2012 =C3=A0 22:10, Jon Black a =C3=A9crit : >>>>=20 >>>>> It is not completely new and it is much more mature. It has been bein= g developed for quite some time, it has implementations, it has interoperabi= lity. Age of a document is not a good criteria. Something can be written q= uite a long time ago and nothing done on it. Another document/protocol may c= ome along, gain critical mass, gain experience and even though younger may b= e a much better starting point. >>>>>=20 >>>>> Jon >>>>>=20 >>>>> From: JP Vasseur (jvasseur) >>>>> To: Jon Black ; Ulrich Herberg ; Abdussalam Baryun ; "Dearlove, Christophe= r (UK)" ; "manet@ietf.org List" =20 >>>>> Sent: Friday, November 2, 2012 11:21 AM >>>>> Subject: Re: [manet] A proposal - differentiating the document and the= protocol >>>>>=20 >>>>> so =E2=80=A6 should we start with a completely new document then ? >>>>>=20 >>>>> On Nov 2, 2012, at 1:16 PM, Jon Black wrote: >>>>>=20 >>>>>> This seems to make good sense. The name should not be issue. We nee= d a good solid base to start from. It would appear that if there are workin= g interoperable implementation based on the LOADng draft then this indicates= that the draft is implementable. Again, having read both I could build som= ething based on the LOADng draft and I (and I'm only talking for me) couldn'= t based on the DYMO draft. >>>>>>=20 >>>>>> I much prefer starting with something simple and understandable and a= dding what is missing rather than starting with something more difficult to u= nderstand trying to remove things that are not needed. >>>>>>=20 >>>>>> Jon >>>>>>=20 >>>>>>=20 >>>>>> From: Ulrich Herberg >>>>>> To: Abdussalam Baryun =20 >>>>>> Cc: "Dearlove, Christopher (UK)" ; "ma= net@ietf.org" =20 >>>>>> Sent: Friday, November 2, 2012 10:34 AM >>>>>> Subject: Re: [manet] A proposal - differentiating the document and th= e protocol >>>>>>=20 >>>>>> Hi Abdussalam, >>>>>>=20 >>>>>> there was indeed some hesitance to change the name from some of the a= uthors (not me). I cannot speak for them here. My intuition is that if the n= ame of the protocol is the only factor that avoids the reactive protocol fro= m proceeding in the WG, this can be solved. >>>>>>=20 >>>>>> As far as I can see from the discussions so far, there is a clear con= sensus that option 3 is not viable. Now, if we want to proceed with the reac= tive document, the question is from which document to start. Chris mentioned= that even if we wanted the specification of 100%, it would be far quicker t= o start from the LOADng draft. I propose that we can start working based on t= he LOADng draft (possibly rename it?), look at each item that is in DYMO and= consider whether and in which way it should be incorporated in the draft.=20= >>>>>>=20 >>>>>> Best >>>>>> Ulrich >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun wrote: >>>>>> Hi Ulrich, >>>>>> =20 >>>>>> I think that Chris's proposal was not accepted by LOADng co-authors a= s I understood from following up the WG history (they don't agree to change t= he name of protocol). As you are one co-author do I understand that you supp= ort the Chris's proposal, >>>>>> AB >>>>>> On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg w= rote: >>>>>> Dear Chris, >>>>>>=20 >>>>>> personally, what you propose makes sense to me. >>>>>>=20 >>>>>>=20 >>>>>> Regards >>>>>> Ulrich >>>>>>=20 >>>>>> On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" wrote: >>>>>>=20 >>>>>> > Before making a proposal, I'm going to introduce a distinction here= between the DYMO and LOADng documents and protocols. >>>>>> > >>>>>> > I'm of the opinion that the LOADng document is a greatly superior p= resentation to the DYMO document. (I'm not really interested in why that has= come about.) >>>>>> > >>>>>> > I think that regardless of whether one makes design decisions favou= ring DYMO or LOADng where they differ - and let's not forget they overlap a l= ot - it would actually be easier to modify the LOADng document to specify DY= MO than it would be to modify the DYMO document to achieve that. And in prac= tice I think if making decisions it is unlikely that all would favour DYMO o= ver LOADng. >>>>>> > >>>>>> > So what I think would be best for the WG is not a simply "option 1"= or even (as it may appear I'm suggesting, but I'm not) "option 2" but rath= er to agree to take the LOADng document, and a list of where DYMO and LOADng= differ, and thrash out where they do, what the WG reactive protocol should d= o - either as a definite choice, or as an option (but not too many options p= lease- and some could be separate specifications). >>>>>> > >>>>>> > This would not of course be LOADng, so we'd have to change the docu= ment name. And there I suggest we have a candidate name - AODVv2. (Which is w= hy I have recently taken to saying DYMO when referring to that document.) Af= ter all, the one thing we are agreed on is that the protocol being developed= is derived from AODV. >>>>>> > >>>>>> > The editors of this new document would have to agree that what goes= in it is WG consensus (which should follow proper technical consideration o= f the issues). If they found it impossible to have other than their way to d= o things, they'd have to move on. If that left no one editing it, obviously w= e don't have a consensus of people prepared to do the work and option 3 woul= d win. >>>>>> > >>>>>> > So now I'm partly off the fence I've been sitting on. But only part= ly. I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as st= andard, IRREPs as an option in the main draft, IRREPs as a separate draft op= tion, no IRREPs. I'd like to move on to those discussions. >>>>>> > >>>>>> > -- >>>>>> > Christopher Dearlove >>>>>> > Senior Principal Engineer, Communications Group >>>>>> > Communications, Networks and Image Analysis Capability >>>>>> > BAE Systems Advanced Technology Centre >>>>>> > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>>> > Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>>> > chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>> > >>>>>> > BAE Systems (Operations) Limited >>>>>> > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace C= entre, Farnborough, Hants, GU14 6YU, UK >>>>>> > Registered in England & Wales No: 1996687 >>>>>> > >>>>>> > >>>>>> > >>>>>> > *******************************************************************= * >>>>>> > 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. >>>>>> > *******************************************************************= * >>>>>> > >>>>>> > _______________________________________________ >>>>>> > manet mailing list >>>>>> > manet@ietf.org >>>>>> > https://www.ietf.org/mailman/listinfo/manet >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-2--28518894 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
Sunk cost fallacy. It's not important how much work was spent on a document. What matters is what state the document is in.

-- 
Christopher Dearlove

On 3 Nov 2012, at 08:36, "JP Vasseur (jvasseur)" <jvasseur@cisco.com> wrote:

Hi,

On Nov 2, 2012, at 7:45 PM, Jiazi YI wrote:

Hi Cedric, 

The LOADng always welcome good ideas from DYMO if it can help improving the protocol. 
But Charlie insists starting from DYMO. 

I cannot speak for Charlie, but you may not have missed that many of this list insist on starting with the WG document
and welcome improvements. I seriously do not think that one can chime in with an individual submission, claim that the
WG document is not good and strongly request to replace it by they document. This is ignoring years of excellent work
from a WG.

What I believe is that, the WG should begin with the document in better shape, as suggested by Chris. 

best

Jiazi

On Nov 3, 2012, at 12:31 AM, C Chauvenet <c.chauvenet@watteco.com> wrote:

One thing that popped up in my mind : 

Are we trying to do the merge between DYMO and LOADng that has previously failed ??

Regardless from which document we start, I understood (from Charlie massages) that LOADng authors were not OK to merge their document with functionalities from DYMO . Did I missed something here ?

Cédric.

Le 2 nov. 2012 à 23:41, C Chauvenet a écrit :

Hi all, 

If we add mechanisms to LOADng or prune some from DYMO, we end up with a different protocol, so I think that we will need to change the name of the resulting protocol. I support the AODVv2 naming for the reactive protocol of MANET, if chairs decide to go forward and do not take option 3).

It seems that charlie is working hard on updating the DYMO draft, by addressing reviews of the document. These reviews contains most of the improvements (readability, RFC5444 compliance ....) that people found missing in DYMO. I think that would make sense to wait for the next update of DYMO before choosing between LOADng and DYMO. I think that the WG want something good, rather than something quick. 
In addition, we would benefit from the work that charlie is currently doing, rather that skip it if we made a decision based on the actual DYMO version.

Cédric.

Le 2 nov. 2012 à 22:10, Jon Black a écrit :

It is not completely new and it is much more mature.  It has been being developed for quite some time, it has implementations, it has interoperability.  Age of a document is not a good criteria.  Something can be written quite a long time ago and nothing done on it.  Another document/protocol may come along, gain critical mass, gain experience and even though younger may be a much better starting point.

Jon

From: JP Vasseur (jvasseur) <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>; Ulrich Herberg <ulrich@herberg.name>; Abdussalam Baryun <abdussalambaryun@gmail.com>; "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>; "manet@ietf.org List" <manet@ietf.org>
Sent: Friday, November 2, 2012 11:21 AM
Subject: Re: [manet] A proposal - differentiating the document and the protocol

so … should we start with a completely new document then ?

On Nov 2, 2012, at 1:16 PM, Jon Black wrote:

This seems to make good sense.  The name should not be issue.  We need a good solid base to start from.  It would appear that if there are working interoperable implementation based on the LOADng draft then this indicates that the draft is implementable.  Again, having read both I could build something based on the LOADng draft and I (and I'm only talking for me) couldn't based on the DYMO draft.

I much prefer starting with something simple and understandable and adding what is missing rather than starting with something more difficult to understand trying to remove things that are not needed.

Jon


From: Ulrich Herberg <ulrich@herberg.name>
To: Abdussalam Baryun <abdussalambaryun@gmail.com>
Cc: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>; "manet@ietf.org" <manet@ietf.org>
Sent: Friday, November 2, 2012 10:34 AM
Subject: Re: [manet] A proposal - differentiating the document and the protocol

Hi Abdussalam,

there was indeed some hesitance to change the name from some of the authors (not me). I cannot speak for them here. My intuition is that if the name of the protocol is the only factor that avoids the reactive protocol from proceeding in the WG, this can be solved.

As far as I can see from the discussions so far, there is a clear consensus that option 3 is not viable. Now, if we want to proceed with the reactive document, the question is from which document to start. Chris mentioned that even if we wanted the specification of 100%, it would be far quicker to start from the LOADng draft. I propose that we can start working based on the LOADng draft (possibly rename it?), look at each item that is in DYMO and consider whether and in which way it should be incorporated in the draft. 

Best
Ulrich



On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
Hi Ulrich,
 
I think that Chris's proposal was not accepted by LOADng co-authors as I understood from following up the WG history (they don't agree to change the name of protocol). As you are one co-author do I understand that you support the Chris's proposal,
AB
On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
Dear Chris,

personally, what you propose makes sense to me.


Regards
Ulrich

On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> wrote:

> Before making a proposal, I'm going to introduce a distinction here between the DYMO and LOADng documents and protocols.
>
> I'm of the opinion that the LOADng document is a greatly superior presentation to the DYMO document. (I'm not really interested in why that has come about.)
>
> I think that regardless of whether one makes design decisions favouring DYMO or LOADng where they differ - and let's not forget they overlap a lot - it would actually be easier to modify the LOADng document to specify DYMO than it would be to modify the DYMO document to achieve that. And in practice I think if making decisions it is unlikely that all would favour DYMO over LOADng.
>
> So what I think would be best for the WG is not a simply "option 1" or even (as it may appear I'm suggesting, but  I'm not) "option 2" but rather to agree to take the LOADng document, and a list of where DYMO and LOADng differ, and thrash out where they do, what the WG reactive protocol should do - either as a definite choice, or as an option (but not too many options please- and some could be separate specifications).
>
> This would not of course be LOADng, so we'd have to change the document name. And there I suggest we have a candidate name - AODVv2. (Which is why I have recently taken to saying DYMO when referring to that document.) After all, the one thing we are agreed on is that the protocol being developed is derived from AODV.
>
> The editors of this new document would have to agree that what goes in it is WG consensus (which should follow proper technical consideration of the issues). If they found it impossible to have other than their way to do things, they'd have to move on. If that left no one editing it, obviously we don't have a consensus of people prepared to do the work and option 3 would win.
>
> So now I'm partly off the fence I've been sitting on. But only partly. I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standard, IRREPs as an option in the main draft, IRREPs as a separate draft option, no IRREPs. I'd like to move on to those discussions.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
>
> ********************************************************************
> 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.
> ********************************************************************
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--Apple-Mail-2--28518894-- From jvasseur@cisco.com Sat Nov 3 04:16:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2030121F9C77 for ; Sat, 3 Nov 2012 04:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.429 X-Spam-Level: X-Spam-Status: No, score=-10.429 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CG-5CuApHTpV for ; Sat, 3 Nov 2012 04:16:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id F1BD221F9C43 for ; Sat, 3 Nov 2012 04:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33426; q=dns/txt; s=iport; t=1351941368; x=1353150968; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8zsObEcTADUuNFd7bUAWaax8tZvKhBWnpkra1pFifhU=; b=Yph3E1VDMtq3Cxh3udrEMaDPvwyluhddbGCFLINHRhZsYBMCqKposqA+ 60jfxnTFI+3+D/6hA5IfU2ZoKzYeduXPMNfj6613/fQwUyYJtN3++H9CN xB/NMjjP4TDlSwyeE/HZkTeADPsRmTtjcgh5duUWRBgVKKWYXpNPTS2KH E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUGALf7lFCtJXG+/2dsb2JhbABEgkmEaalZkiiBCIIeAQEBAwEBAQEPAQc7FwIIAwULAgEIBwoEAQEhBwchBgsTAQkIAgQOBR4Eh1YDCQYLmxaVfw2JVIsZaBSFR2EDlCYEgVGLM4MmgWuCb4FbCRc X-IronPort-AV: E=Sophos;i="4.80,705,1344211200"; d="scan'208,217";a="138463116" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 03 Nov 2012 11:16:07 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA3BG7vg016504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 11:16:07 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 06:16:06 -0500 From: "JP Vasseur (jvasseur)" To: Christopher Dearlove Thread-Topic: [manet] A proposal - differentiating the document and the protocol Thread-Index: AQHNubNoLZ86zywFik2+PXjDfGksEpfX9dX9 Date: Sat, 3 Nov 2012 11:16:06 +0000 Message-ID: References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> <1351876587.86080.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204C69E@xmb-rcd-x02.cisco.com> <1351890653.89343.YahooMailNeo@web160603.mail.bf1.yahoo.com> <97B69B30E0EF244B940B65EA541E3F2D21572F63@DBXPRD0510MB395.eurprd05.prod.outlook.com> <97B69B30E0EF244B940B65EA541E3F2D215731FF@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D80B@xmb-rcd-x02.cisco.com>, <0A918FF2-302F-4C6E-A8E3-85F357209DB6@gmail.com> In-Reply-To: <0A918FF2-302F-4C6E-A8E3-85F357209DB6@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--57.320800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_A4F72C65B2D24A5B92F72173A326C005ciscocom_" MIME-Version: 1.0 Cc: =?Windows-1252?Q?Axel_Colin_de_Verdi=E8re?= , "manet@ietf.org List" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 11:16:10 -0000 --_000_A4F72C65B2D24A5B92F72173A326C005ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable So lets wait a bit and decide without rush. JP Vasseur Cisco Fellow Sent from my iPhone On 3 nov. 2012, at 12:07, "Christopher Dearlove" > wrote: Sunk cost fallacy. It's not important how much work was spent on a document= . What matters is what state the document is in. -- Christopher Dearlove christopher.dearlove@gmail.com (iPho= ne) chris@mnemosyne.demon.co.uk (home) On 3 Nov 2012, at 08:36, "JP Vasseur (jvasseur)" > wrote: Hi, On Nov 2, 2012, at 7:45 PM, Jiazi YI wrote: Hi Cedric, The LOADng always welcome good ideas from DYMO if it can help improving the= protocol. But Charlie insists starting from DYMO. I cannot speak for Charlie, but you may not have missed that many of this l= ist insist on starting with the WG document and welcome improvements. I seriously do not think that one can chime in wi= th an individual submission, claim that the WG document is not good and strongly request to replace it by they document= . This is ignoring years of excellent work from a WG. What I believe is that, the WG should begin with the document in better sha= pe, as suggested by Chris. best Jiazi On Nov 3, 2012, at 12:31 AM, C Chauvenet <c= .chauvenet@watteco.com> wrote: One thing that popped up in my mind : Are we trying to do the merge between DYMO and LOADng that has previously f= ailed ?? Regardless from which document we start, I understood (from Charlie massage= s) that LOADng authors were not OK to merge their document with functionali= ties from DYMO . Did I missed something here ? C=E9dric. Le 2 nov. 2012 =E0 23:41, C Chauvenet a =E9crit : Hi all, If we add mechanisms to LOADng or prune some from DYMO, we end up with a di= fferent protocol, so I think that we will need to change the name of the re= sulting protocol. I support the AODVv2 naming for the reactive protocol of = MANET, if chairs decide to go forward and do not take option 3). It seems that charlie is working hard on updating the DYMO draft, by addres= sing reviews of the document. These reviews contains most of the improvemen= ts (readability, RFC5444 compliance ....) that people found missing in DYMO= . I think that would make sense to wait for the next update of DYMO before = choosing between LOADng and DYMO. I think that the WG want something good, = rather than something quick. In addition, we would benefit from the work that charlie is currently doing= , rather that skip it if we made a decision based on the actual DYMO versio= n. C=E9dric. Le 2 nov. 2012 =E0 22:10, Jon Black a =E9crit : It is not completely new and it is much more mature. It has been being dev= eloped for quite some time, it has implementations, it has interoperability= . Age of a document is not a good criteria. Something can be written quit= e a long time ago and nothing done on it. Another document/protocol may co= me along, gain critical mass, gain experience and even though younger may b= e a much better starting point. Jon ________________________________ From: JP Vasseur (jvasseur) <jvasseur@cisco.com<= mailto:jvasseur@cisco.com>> To: Jon Black <jblack.ietf@yahoo.com>; Ulrich Herberg <ulrich@= herberg.name>; Abdussalam Baryun <abdussalambaryun@gmail.com>; "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>; "= manet@ietf.org List" <manet@ietf.org> Sent: Friday, November 2, 2012 11:21 AM Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol so =85 should we start with a completely new document then ? On Nov 2, 2012, at 1:16 PM, Jon Black wrote: This seems to make good sense. The name should not be issue. We need a go= od solid base to start from. It would appear that if there are working int= eroperable implementation based on the LOADng draft then this indicates tha= t the draft is implementable. Again, having read both I could build someth= ing based on the LOADng draft and I (and I'm only talking for me) couldn't = based on the DYMO draft. I much prefer starting with something simple and understandable and adding = what is missing rather than starting with something more difficult to under= stand trying to remove things that are not needed. Jon ________________________________ From: Ulrich Herberg <ulrich@herberg.name> To: Abdussalam Baryun <abdussalambaryun@= gmail.com> Cc: "Dearlove, Christopher (UK)" <Chr= is.Dearlove@baesystems.com>; "manet@ietf.org" <manet@ietf.org> Sent: Friday, November 2, 2012 10:34 AM Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol Hi Abdussalam, there was indeed some hesitance to change the name from some of the authors= (not me). I cannot speak for them here. My intuition is that if the name o= f the protocol is the only factor that avoids the reactive protocol from pr= oceeding in the WG, this can be solved. As far as I can see from the discussions so far, there is a clear consensus= that option 3 is not viable. Now, if we want to proceed with the reactive = document, the question is from which document to start. Chris mentioned tha= t even if we wanted the specification of 100%, it would be far quicker to s= tart from the LOADng draft. I propose that we can start working based on th= e LOADng draft (possibly rename it?), look at each item that is in DYMO and= consider whether and in which way it should be incorporated in the draft. Best Ulrich On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> w= rote: Hi Ulrich, I think that Chris's proposal was not accepted by LOADng co-authors as I un= derstood from following up the WG history (they don't agree to change the n= ame of protocol). As you are one co-author do I understand that you support= the Chris's proposal, AB On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg <ulrich@herberg.name> wrote: Dear Chris, personally, what you propose makes sense to me. Regards Ulrich On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> wrote: > Before making a proposal, I'm going to introduce a distinction here betwe= en the DYMO and LOADng documents and protocols. > > I'm of the opinion that the LOADng document is a greatly superior present= ation to the DYMO document. (I'm not really interested in why that has come= about.) > > I think that regardless of whether one makes design decisions favouring D= YMO or LOADng where they differ - and let's not forget they overlap a lot -= it would actually be easier to modify the LOADng document to specify DYMO = than it would be to modify the DYMO document to achieve that. And in practi= ce I think if making decisions it is unlikely that all would favour DYMO ov= er LOADng. > > So what I think would be best for the WG is not a simply "option 1" or ev= en (as it may appear I'm suggesting, but I'm not) "option 2" but rather to= agree to take the LOADng document, and a list of where DYMO and LOADng dif= fer, and thrash out where they do, what the WG reactive protocol should do = - either as a definite choice, or as an option (but not too many options pl= ease- and some could be separate specifications). > > This would not of course be LOADng, so we'd have to change the document n= ame. And there I suggest we have a candidate name - AODVv2. (Which is why I= have recently taken to saying DYMO when referring to that document.) After= all, the one thing we are agreed on is that the protocol being developed i= s derived from AODV. > > The editors of this new document would have to agree that what goes in it= is WG consensus (which should follow proper technical consideration of the= issues). If they found it impossible to have other than their way to do th= ings, they'd have to move on. If that left no one editing it, obviously we = don't have a consensus of people prepared to do the work and option 3 would= win. > > So now I'm partly off the fence I've been sitting on. But only partly. I = haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standar= d, IRREPs as an option in the main draft, IRREPs as a separate draft option= , no IRREPs. I'd like to move on to those discussions. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www= .baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > ******************************************************************** > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailma= n/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/l= istinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/l= istinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/l= istinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/l= istinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/l= istinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/l= istinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_A4F72C65B2D24A5B92F72173A326C005ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
So lets wait a bit and decide without rush.

JP Vasseur
Cisco Fellow

Sent from my iPhone

On 3 nov. 2012, at 12:07, "Christopher Dearlove" <christopher.dearlove@googlemail.= com> wrote:

Sunk cost fallacy. It's not important how much work was spent on a doc= ument. What matters is what state the document is in.

-- 
Christopher Dearlove

On 3 Nov 2012, at 08:36, "JP Vasseur (jvasseur)" <jvasseur@cisco.com> wrote:

Hi,

On Nov 2, 2012, at 7:45 PM, Jiazi YI wrote:

Hi Cedric, 

The LOADng always welcome good ideas fro= m DYMO if it can help improving the protocol. 
But Charlie insists starting from DYMO.&= nbsp;

I cannot speak for Charlie, but you may not have missed that many of t= his list insist on starting with the WG document
and welcome improvements. I seriously do not think that one can chime = in with an individual submission, claim that the
WG document is not good and strongly request to replace it by they doc= ument. This is ignoring years of excellent work
from a WG.

What I believe is that, the WG should be= gin with the document in better shape, as suggested by Chris. 

best

Jiazi

On Nov 3, 2012, at 12:31 AM, C Chauvenet <c.chauvene= t@watteco.com> wrote:

One thing that popped up in my mind : 

Are we trying to do the merge between DYMO and LOADng that has previou= sly failed ??

Regardless from which document we start, I understood (from Charlie ma= ssages) that LOADng authors were not OK to merge their document with functi= onalities from DYMO . Did I missed something here ?

C=E9dric.

Le 2 nov. 2012 =E0 23:41, C Chauvenet a =E9crit :

Hi all, 

If we add mechanisms to LOADng or prune some from DYMO, we end up with= a different protocol, so I think that we will need to change the name of t= he resulting protocol. I support the AODVv2 naming for the reactive protoco= l of MANET, if chairs decide to go forward and do not take option 3).

It seems that charlie is working hard on updating the DYMO draft, by a= ddressing reviews of the document. These reviews contains most of the impro= vements (readability, RFC5444 compliance ....) that people found missing in= DYMO. I think that would make sense to wait for the next update of DYMO before choosing between LOADng and DYM= O. I think that the WG want something good, rather than something quick.&nb= sp;
In addition, we would benefit from the work that charlie is currently = doing, rather that skip it if we made a decision based on the actual DYMO v= ersion.

C=E9dric.

Le 2 nov. 2012 =E0 22:10, Jon Black a =E9crit :

It is not completely new and it is much more mature.  It has been bein= g developed for quite some time, it has implementations, it has interoperab= ility.  Age of a document is not a good criteria.  Something can = be written quite a long time ago and nothing done on it.  Another document/protocol may come along, gain critical mass,= gain experience and even though younger may be a much better starting poin= t.

Jon

From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com&g= t;; Ulrich Herberg <ulrich@herberg.name>; Abdussalam Baryun <abdussalambaryun@gmail.com&= gt;; "Dearlove, Christopher (UK)" <= Chris.Dearlove@baesystems.com>; "manet@ietf.org List" <manet@ietf.org>
Sent: Friday, November 2, = 2012 11:21 AM
Subject: Re: [manet] A pro= posal - differentiating the document and the protocol

so =85 should we start with a completely new document then ?

On Nov 2, 2012, at 1:16 PM, Jon Black wrote:

This seems to make good sense.  The name should not be issue.  We= need a good solid base to start from.  It would appear that if there = are working interoperable implementation based on the LOADng draft then thi= s indicates that the draft is implementable.  Again, having read both I could build something based on the LOADng draft and I (= and I'm only talking for me) couldn't based on the DYMO draft.

I much prefer starting with something simple and understandable and adding = what is missing rather than starting with something more difficult to under= stand trying to remove things that are not needed.

Jon


From: Ulrich Herberg <ulrich@herberg.name>
To: Abdussalam Baryun <<= a rel=3D"nofollow" ymailto=3D"mailto:abdussalambaryun@gmail.com" target=3D"= _blank" href=3D"mailto:abdussalambaryun@gmail.com">abdussalambaryun@gmail.com>
Cc: "Dearlove, Christo= pher (UK)" <Chris.Dearlove@baes= ystems.com>; "ma= net@ietf.org" <manet@ietf.org>
Sent: Friday, November 2, 2= 012 10:34 AM
Subject: Re: [manet] A prop= osal - differentiating the document and the protocol

Hi Abdussalam,

there was indeed some hesitance to change the name from some of the au= thors (not me). I cannot speak for them here. My intuition is that if the n= ame of the protocol is the only factor that avoids the reactive protocol fr= om proceeding in the WG, this can be solved.

As far as I can see from the discussions so far, there is a clear cons= ensus that option 3 is not viable. Now, if we want to proceed with the reac= tive document, the question is from which document to start. Chris mentione= d that even if we wanted the specification of 100%, it would be far quicker to start from the LOADng draft. I pr= opose that we can start working based on the LOADng draft (possibly re= name it?), look at each item that is in DYMO and consider whether and in wh= ich way it should be incorporated in the draft. 

Best
Ulrich



On Fri, Nov 2, 2012 at 9:17 AM, Abd= ussalam Baryun <<= /a>abdussalambaryun@gmail.com= > wrote:
Hi Ulrich,
 
I think that Chris's proposal was not accepted by LOADng co-autho= rs as I understood from following up the WG history (they don't agree to ch= ange the name of protocol). As you are one co-author do I understand that y= ou support the Chris's proposal,
AB
On Fri, Nov 2, 2012 at 2:41 PM, Ulr= ich Herberg <ulrich@herberg.name> wrote:
Dear Chris,

personally, what you propose makes sense to me.


Regards
Ulrich

On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> wrote:

> Before making a proposal, I'm going to introduce a distinction here be= tween the DYMO and LOADng documents and protocols.
>
> I'm of the opinion that the LOADng document is a greatly superior pres= entation to the DYMO document. (I'm not really interested in why that has c= ome about.)
>
> I think that regardless of whether one makes design decisions favourin= g DYMO or LOADng where they differ - and let's not forget they overlap a lo= t - it would actually be easier to modify the LOADng document to specify DY= MO than it would be to modify the DYMO document to achieve that. And in practice I think if making decisions it i= s unlikely that all would favour DYMO over LOADng.
>
> So what I think would be best for the WG is not a simply "option = 1" or even (as it may appear I'm suggesting, but  I'm not) "= option 2" but rather to agree to take the LOADng document, and a list = of where DYMO and LOADng differ, and thrash out where they do, what the WG reactive protocol should do - either as a definite choice, or = as an option (but not too many options please- and some could be separate s= pecifications).
>
> This would not of course be LOADng, so we'd have to change the documen= t name. And there I suggest we have a candidate name - AODVv2. (Which is wh= y I have recently taken to saying DYMO when referring to that document.) Af= ter all, the one thing we are agreed on is that the protocol being developed is derived from AODV.
>
> The editors of this new document would have to agree that what goes in= it is WG consensus (which should follow proper technical consideration of = the issues). If they found it impossible to have other than their way to do= things, they'd have to move on. If that left no one editing it, obviously we don't have a consensus of people= prepared to do the work and option 3 would win.
>
> So now I'm partly off the fence I've been sitting on. But only partly.= I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as stan= dard, IRREPs as an option in the main draft, IRREPs as a separate draft opt= ion, no IRREPs. I'd like to move on to those discussions.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesyst= ems.com | <= /a>http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
>
> ******************************************************************** > 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.
> ******************************************************************** >
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.iet= f.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@iet= f.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@iet= f.org
https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@iet= f.org
https://www.ietf.org/mailman/listi= nfo/manet



_______________________________________________
manet mailing list
man= et@ietf.org
https://www.ietf.org/mailman/listi= nfo/manet

_______________________________________________
manet mailing list
man= et@ietf.org
https://www.ietf.org/mailman/listi= nfo/manet


_______________________________________________
manet mailing list
man= et@ietf.org
https://www.ietf.org/mailman/listi= nfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.i= etf.org/mailman/listinfo/manet
--_000_A4F72C65B2D24A5B92F72173A326C005ciscocom_-- From prvs=647a504e0=mukul@uwm.edu Sat Nov 3 04:18:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE8B21F84DD for ; Sat, 3 Nov 2012 04:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y583kg4K0l7J for ; Sat, 3 Nov 2012 04:18:33 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 72C6B21F9B59 for ; Sat, 3 Nov 2012 04:18:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4XAE79lFB/AAAB/2dsb2JhbABEgXQGAYQcqnSVTgEBAQMBAQEBIDIXAggDBQcPEQQBAQMCDRkCIwYeCggGEx6HWgMJBguoOohWDUyJCIEgiXloFIUVgRMDiFqLTASBUYszhRGDDYE9CRce Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id C16D22E0A4F; Sat, 3 Nov 2012 06:18:24 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1j2Jw3qfaDgU; Sat, 3 Nov 2012 06:18:24 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 1CB4A2E0A71; Sat, 3 Nov 2012 06:18:23 -0500 (CDT) Date: Sat, 3 Nov 2012 06:18:23 -0500 (CDT) From: Mukul Goyal To: Christopher Dearlove Message-ID: <408541807.197885.1351941503916.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <0A918FF2-302F-4C6E-A8E3-85F357209DB6@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: =?utf-8?Q?Axel_Colin_de_Verdi=C3=A8re?= , "manet@ietf.org List" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 11:18:35 -0000 Give Charlie a chance! It is not too hard, esp for some one lie Charlie, to= significantly improve a document's readability etc. in one edit cycle. Thanks Mukul ----- Original Message ----- From: "Christopher Dearlove" To: "JP Vasseur (jvasseur)" Cc: "Axel Colin de Verdi=C3=A8re" , "manet@ietf.org List" Sent: Saturday, November 3, 2012 6:07:06 AM Subject: Re: [manet] A proposal - differentiating the document and=09the=09= protocol Sunk cost fallacy. It's not important how much work was spent on a document= . What matters is what state the document is in.=20 --=C2=A0=20 Christopher Dearlove=20 christopher.dearlove@gmail.com (iPhone)=20 chris@mnemosyne.demon.co.uk (home)=20 On 3 Nov 2012, at 08:36, "JP Vasseur (jvasseur)" < jvasseur@cisco.com > wro= te:=20 Hi,=20 On Nov 2, 2012, at 7:45 PM, Jiazi YI wrote:=20 Hi Cedric,=C2=A0=20 The LOADng always welcome good ideas from DYMO if it can help improving the= protocol.=C2=A0=20 But Charlie insists starting from DYMO.=C2=A0=20 I cannot speak for Charlie, but you may not have missed that many of this l= ist insist on starting with the WG document=20 and welcome improvements. I seriously do not think that one can chime in wi= th an individual submission, claim that the=20 WG document is not good and strongly request to replace it by they document= . This is ignoring years of excellent work=20 from a WG.=20 What I believe is that, the WG should begin with the document in better sha= pe, as suggested by Chris.=C2=A0=20 best=20 Jiazi=20 On Nov 3, 2012, at 12:31 AM, C Chauvenet < c.chauvenet@watteco.com > wrote:= =20 One thing that popped up in my mind :=C2=A0=20 Are we trying to do the merge between DYMO and LOADng that has previously f= ailed ??=20 Regardless from which document we start, I understood (from Charlie massage= s) that LOADng authors were not OK to merge their document with functionali= ties from DYMO . Did I missed something here ?=20 C=C3=A9dric.=20 Le 2 nov. 2012 =C3=A0 23:41, C Chauvenet a =C3=A9crit :=20 Hi all,=C2=A0=20 If we add mechanisms to LOADng or prune some from DYMO, we end up with a di= fferent protocol, so I think that we will need to change the name of the re= sulting protocol. I support the AODVv2 naming for the reactive protocol of = MANET, if chairs decide to go forward and do not take option 3).=20 It seems that charlie is working hard on updating the DYMO draft, by addres= sing reviews of the document. These reviews contains most of the improvemen= ts (readability, RFC5444 compliance ....) that people found missing in DYMO= . I think that would make sense to wait for the next update of DYMO before = choosing between LOADng and DYMO. I think that the WG want something good, = rather than something quick.=C2=A0=20 In addition, we would benefit from the work that charlie is currently doing= , rather that skip it if we made a decision based on the actual DYMO versio= n.=20 C=C3=A9dric.=20 Le 2 nov. 2012 =C3=A0 22:10, Jon Black a =C3=A9crit :=20 It is not completely new and it is much more mature.=C2=A0 It has been bein= g developed for quite some time, it has implementations, it has interoperab= ility.=C2=A0 Age of a document is not a good criteria.=C2=A0 Something can = be written quite a long time ago and nothing done on it.=C2=A0 Another docu= ment/protocol may come along, gain critical mass, gain experience and even = though younger may be a much better starting point.=20 Jon=20 From: JP Vasseur (jvasseur) < jvasseur@cisco.com >=20 To: Jon Black < jblack.ietf@yahoo.com >; Ulrich Herberg < ulrich@herberg.na= me >; Abdussalam Baryun < abdussalambaryun@gmail.com >; "Dearlove, Christop= her (UK)" < Chris.Dearlove@baesystems.com >; " manet@ietf.org List" < manet= @ietf.org >=20 Sent: Friday, November 2, 2012 11:21 AM=20 Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol=20 so =E2=80=A6 should we start with a completely new document then ?=20 On Nov 2, 2012, at 1:16 PM, Jon Black wrote:=20 This seems to make good sense.=C2=A0 The name should not be issue.=C2=A0 We= need a good solid base to start from.=C2=A0 It would appear that if there = are working interoperable implementation based on the LOADng draft then thi= s indicates that the draft is implementable.=C2=A0 Again, having read both = I could build something based on the LOADng draft and I (and I'm only talki= ng for me) couldn't based on the DYMO draft.=20 I much prefer starting with something simple and understandable and adding = what is missing rather than starting with something more difficult to under= stand trying to remove things that are not needed.=20 Jon=20 From: Ulrich Herberg < ulrich@herberg.name >=20 To: Abdussalam Baryun < abdussalambaryun@gmail.com >=20 Cc: "Dearlove, Christopher (UK)" < Chris.Dearlove@baesystems.com >; " manet= @ietf.org " < manet@ietf.org >=20 Sent: Friday, November 2, 2012 10:34 AM=20 Subject: Re: [manet] A proposal - differentiating the document and the prot= ocol=20 Hi Abdussalam,=20 there was indeed some hesitance to change the name from some of the authors= (not me). I cannot speak for them here. My intuition is that if the name o= f the protocol is the only factor that avoids the reactive protocol from pr= oceeding in the WG, this can be solved.=20 As far as I can see from the discussions so far, there is a clear consensus= that option 3 is not viable. Now, if we want to proceed with the reactive = document, the question is from which document to start. Chris mentioned tha= t even if we wanted the specification of 100%, it would be far quicker to s= tart from the LOADng draft.=C2=A0I propose that we can start working based = on the LOADng draft=C2=A0(possibly rename it?), look at each item that is i= n DYMO and consider whether and in which way it should be incorporated in t= he draft.=C2=A0=20 Best=20 Ulrich=20 On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun < abdussalambaryun@gmail.= com > wrote:=20 Hi Ulrich,=20 =C2=A0=20 I think that=C2=A0Chris's proposal was not accepted by LOADng co-authors as= I understood from following up the WG history (they don't agree to change = the name of protocol). As you are one co-author do I understand that you su= pport the Chris's proposal,=20 AB=20 On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg < ulrich@herberg.name > wrot= e:=20 Dear Chris,=20 personally, what you propose makes sense to me.=20 Regards=20 Ulrich=20 On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" < Chris.Dearlove@baes= ystems.com > wrote:=20 > Before making a proposal, I'm going to introduce a distinction here betwe= en the DYMO and LOADng documents and protocols.=20 >=20 > I'm of the opinion that the LOADng document is a greatly superior present= ation to the DYMO document. (I'm not really interested in why that has come= about.)=20 >=20 > I think that regardless of whether one makes design decisions favouring D= YMO or LOADng where they differ - and let's not forget they overlap a lot -= it would actually be easier to modify the LOADng document to specify DYMO = than it would be to modify the DYMO document to achieve that. And in practi= ce I think if making decisions it is unlikely that all would favour DYMO ov= er LOADng.=20 >=20 > So what I think would be best for the WG is not a simply "option 1" or ev= en (as it may appear I'm suggesting, but =C2=A0I'm not) "option 2" but rath= er to agree to take the LOADng document, and a list of where DYMO and LOADn= g differ, and thrash out where they do, what the WG reactive protocol shoul= d do - either as a definite choice, or as an option (but not too many optio= ns please- and some could be separate specifications).=20 >=20 > This would not of course be LOADng, so we'd have to change the document n= ame. And there I suggest we have a candidate name - AODVv2. (Which is why I= have recently taken to saying DYMO when referring to that document.) After= all, the one thing we are agreed on is that the protocol being developed i= s derived from AODV.=20 >=20 > The editors of this new document would have to agree that what goes in it= is WG consensus (which should follow proper technical consideration of the= issues). If they found it impossible to have other than their way to do th= ings, they'd have to move on. If that left no one editing it, obviously we = don't have a consensus of people prepared to do the work and option 3 would= win.=20 >=20 > So now I'm partly off the fence I've been sitting on. But only partly. I = haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standar= d, IRREPs as an option in the main draft, IRREPs as a separate draft option= , no IRREPs. I'd like to move on to those discussions.=20 >=20 > --=20 > Christopher Dearlove=20 > Senior Principal Engineer, Communications Group=20 > Communications, Networks and Image Analysis Capability=20 > BAE Systems Advanced Technology Centre=20 > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK=20 > Tel: +44 1245 242194 | =C2=A0Fax: +44 1245 242124=20 > chris.dearlove@baesystems.com | http://www.baesystems.com=20 >=20 > BAE Systems (Operations) Limited=20 > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK=20 > Registered in England & Wales No: 1996687=20 >=20 >=20 >=20 > ********************************************************************=20 > This email and any attachments are confidential to the intended=20 > recipient and may also be privileged. If you are not the intended=20 > recipient please delete it from your system and notify the sender.=20 > You should not copy it or use it for any purpose nor disclose or=20 > distribute its contents to any other person.=20 > ********************************************************************=20 >=20 > _______________________________________________=20 > manet mailing list=20 > manet@ietf.org=20 > https://www.ietf.org/mailman/listinfo/manet=20 _______________________________________________=20 manet mailing list=20 manet@ietf.org=20 https://www.ietf.org/mailman/listinfo/manet=20 _______________________________________________=20 manet mailing list=20 manet@ietf.org=20 https://www.ietf.org/mailman/listinfo/manet=20 _______________________________________________=20 manet mailing list=20 manet@ietf.org=20 https://www.ietf.org/mailman/listinfo/manet=20 _______________________________________________=20 manet mailing list=20 manet@ietf.org=20 https://www.ietf.org/mailman/listinfo/manet=20 _______________________________________________=20 manet mailing list=20 manet@ietf.org=20 https://www.ietf.org/mailman/listinfo/manet=20 _______________________________________________=20 manet mailing list=20 manet@ietf.org=20 https://www.ietf.org/mailman/listinfo/manet=20 _______________________________________________=20 manet mailing list=20 manet@ietf.org=20 https://www.ietf.org/mailman/listinfo/manet=20 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From jpmacker@gmail.com Sat Nov 3 07:55:04 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14A821F9B59 for ; Sat, 3 Nov 2012 07:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.306 X-Spam-Level: X-Spam-Status: No, score=-3.306 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SE3kXc1BNaE7 for ; Sat, 3 Nov 2012 07:55:04 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F1C9A21F9B53 for ; Sat, 3 Nov 2012 07:55:03 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so5128324vcb.31 for ; Sat, 03 Nov 2012 07:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Bu7nXS4LYHGN4BjUBQd0JRL7cGcj3BNRxJFbJBZBlvQ=; b=Mc8Nt2x1KKRdGnGAwi4u3m0QcWh1Hf8aTzvXCejH4QvwUEMo/pvSmmke1fVMSQ8drl UpcSe39zlE0X7v1L//Ef5cRbjR6JlIHYxMx+zFQQP6feiDN0oE2rS61Ca3elh+MeGuH2 TDBJuEMgkj/5pcsb3bYMQIa76LcO2btUq6WSgokxR5W04m900qtdhsmFfOEHa8MJeIup p8zUcbmlnAxfexy9w5hh3r61ge8BuMcc5C8gT9UJcf6CcQz0kRJzE2XiLe5NHMrcB7Vd VGn5mhkjDj8pw0NmyynJysupPGBUdE2UFfC0JDVOB79sNyDaTbFyAS1g+jAxeKjDsY9w Ikig== MIME-Version: 1.0 Received: by 10.52.37.43 with SMTP id v11mr4156583vdj.29.1351954503492; Sat, 03 Nov 2012 07:55:03 -0700 (PDT) Received: by 10.58.161.206 with HTTP; Sat, 3 Nov 2012 07:55:03 -0700 (PDT) In-Reply-To: References: Date: Sat, 3 Nov 2012 10:55:03 -0400 Message-ID: From: Joseph Macker To: Ulrich Herberg Content-Type: multipart/alternative; boundary=20cf30780a72eee3de04cd986f65 Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , Benoit Claise , "manet@ietf.org" Subject: Re: [manet] Management use cases for MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 14:55:04 -0000 --20cf30780a72eee3de04cd986f65 Content-Type: text/plain; charset=ISO-8859-1 Thanks Ulrich for pointing this out since we have dynamic meshes in our charter both mobility and dynamic topology aspects would be relevant. Community network related manet deployments etc come to mind. On Fri, Nov 2, 2012 at 3:17 PM, Ulrich Herberg wrote: > Hi [manet] participants, > > I am forwarding an email from Benoit that was sent to coman@ietf.org, > since it concerns MANET. COMAN is a new activity (not yet a WG) relating to > management of constrained devices and networks. As I mentioned at the last > IETF, Benoit cleared his DISCUSS on the NHDP-MIB if we commit to write a > document about applicability and use cases of management of MANET routers. > > In COMAN, an individual ID was presented > (draft-ersue-constrained-mgmt) that discusses use cases of management. Note > that this is an early draft and will possibly be split in multiple drafts. > There is some discussion whether that should include mobility or not > (currently, MANET is excluded but mesh networks are not, which I think > needs some more discussion, as both are about dynamic topologies). Anyway, > similar to Benoit, it is unclear to me whether this draft or any work in > COMAN (if it was to become a WG) would satisfy the request for a use > case/applicability document, or if MANET should work on a separate draft. > > As the next OLSRv2-MIB revision will be submitted next Monday, (which I > consider ready for WGLC) this is something we need to seriously consider. > > Opinions? > > Thanks > Ulrich > > On Fri, Nov 2, 2012 at 4:45 AM, Benoit Claise wrote: > >> Hi, >> >> One point regarding MANET. >> I believe that it deserves its own document: "MANET network management >> considerations". Actually, when looking at draft-ietf-manet-nhdp-mib part >> of the IESG review, one of the outcome was that such a document was >> required. >> I cleared my DISCUSS on draft-ietf-manet-nhdp-mib with this COMMENT >> >> Note regarding the applicability statement: This is solved, as we >> discussed, but I'll keep this little sentence in one >> corner of my head "A fuller discussion of MANET network management use >> cases and challenges will be provided elsewhere." >> >> How/If this "MANET network management considerations" draft relates to >> the draft-ersue-constrained-mgmt, I'm not sure at this point in time. >> >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --20cf30780a72eee3de04cd986f65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Ulrich for pointing this out since we have dynamic meshes in our cha= rter both mobility and dynamic topology aspects would be relevant. Communit= y network related manet deployments etc come to mind.


On Fri, Nov 2, 2012 at 3:17 PM, Ulrich H= erberg <ulrich@herberg.name> wrote:
Hi [manet] participants,

I am forwarding an e= mail from Benoit that was sent to coman@ietf.org, since it concerns MANET. COMAN is a new act= ivity (not yet a WG) relating to management of constrained devices and netw= orks. As I mentioned at the last IETF, Benoit cleared his DISCUSS on the NH= DP-MIB if we commit to write a document about applicability and use cases o= f management of MANET routers.

In COMAN, an individual ID was presented (draft-ersue-c= onstrained-mgmt)=A0that discusses use cases of management. Note that this i= s an early draft and will possibly be split in multiple drafts. There is so= me discussion whether that should include mobility or not (currently, MANET= is excluded but mesh networks are not, which I think needs some more discu= ssion, as both are about dynamic topologies). Anyway, similar to Benoit, it= is unclear to me whether this draft or any work in COMAN (if it was to bec= ome a WG) would satisfy the request for a use case/applicability document, = or if MANET should work on a separate draft.

As the next OLSRv2-MIB revision will be submitted next = Monday, (which I consider ready for WGLC) this is something we need to seri= ously consider.=A0

Opinions?

Thanks
Ulrich

On Fri, Nov = 2, 2012 at 4:45 AM, Benoit Claise <bclaise@cisco.com> wrote:=
=20 =20 =20
Hi,

One point regarding MANET.
I believe that it deserves its own document: "MANET network management considerations". Actually, when looking at draft-ietf-manet-nhdp-mib part of the IESG review, one of the outcome was that such a document was required.
I cleared my DISCUSS on draft-ietf-manet-nhdp-mib with this COMMENT
Note regarding the applicability statement: This is solved, as=
 we
discussed, but I'll keep this little sentence in one=20
corner of my head "A fuller discussion of MANET network management use
cases and challenges will be provided elsewhere."
How/If this "MANET network management considerations" draft relates to the draft-ersue-constrained-mgmt, I'm not sure at this point in time.


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--20cf30780a72eee3de04cd986f65-- From jpmacker@gmail.com Sat Nov 3 08:01:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B25321F9BBE for ; Sat, 3 Nov 2012 08:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XAf6KX6g939 for ; Sat, 3 Nov 2012 08:01:52 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A355321F9B72 for ; Sat, 3 Nov 2012 08:01:52 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so5190725vbb.31 for ; Sat, 03 Nov 2012 08:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rO52KvuECXfP7x7/oHWUj2ylEbNNGi6o39A1+rviziA=; b=RuDJvtBRiUaniRNqIXMSJXehh30SiRK3nD14NVmOagdXrfplyftMCtAnZsVnEZiC6k CfAliWaOK2HLhUlX33W03DYrBRv4wCNQTDKZWLS7fbdUQrCIRRR3ObbtBPeXfb1448df 4M9R6qfqA4g6zWxLyWUPc+vxvSvo/cqdqNPb3GvjeqSF29McOTffZEQ406UdpOFYuR6K 36X7Xxs0S5cm7IlZzjSfAfZsUFtc/x1HHxivjYGwdPNH3sh2+oO/SCxjXNRf2cpb5zFa PaDDtjWkQJb/zalnmrKTRHmkfg2V0jL77Agk7JkN9kWHu5Cr0H/jo9wnjsHokcr+a6n2 hsTA== MIME-Version: 1.0 Received: by 10.58.201.73 with SMTP id jy9mr4858744vec.29.1351954911867; Sat, 03 Nov 2012 08:01:51 -0700 (PDT) Received: by 10.58.161.206 with HTTP; Sat, 3 Nov 2012 08:01:51 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204D717@xmb-rcd-x02.cisco.com> References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C638@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C877@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204CB91@xmb-rcd-x02.cisco.com> <1351891740.83248.YahooMailNeo@web160605.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204D717@xmb-rcd-x02.cisco.com> Date: Sat, 3 Nov 2012 11:01:51 -0400 Message-ID: From: Joseph Macker To: "JP Vasseur (jvasseur)" Content-Type: multipart/alternative; boundary=047d7b677afa4634c904cd9888bd Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 15:01:53 -0000 --047d7b677afa4634c904cd9888bd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I realize it is exciting to discuss and people keep alluding to it so responses are naturally triggers but I would ask you to please remove any further ROLL performance debates from this WG list. Let us concentrate on LOADng and DYMO documents and find a way forward. On Sat, Nov 3, 2012 at 4:25 AM, JP Vasseur (jvasseur) w= rote: > OK I will stop arguing here -- If I may reread what you wrote, then read > RFC6550 and you will quickly see why you mis-undertood the protocol. > Hint: think of DAG rooted at source of traffic, use address aggregation > mapping to topologies, P2P, storing of source routed paths. > > On Nov 2, 2012, at 5:29 PM, Jon Black wrote: > > Ah but now you mix apples and oranges. Storing mode is not good for > highly constrained devices (they don't have the memory for storing mode) = so > for many LLNs you are stuck with non-storing mode which is poor with P2MP= , > but still fine with MP2P. And therefore Henning's point is valid. It > depends on traffic. > > Jon > > > ------------------------------ > *From:* JP Vasseur (jvasseur) > *To:* Henning Rogge > *Cc:* "manet@ietf.org" > *Sent:* Friday, November 2, 2012 12:10 PM > *Subject:* Re: [manet] Reactive Protocol Situation > > Again your assumption are not correct - look at storing mode with OF to > increase connectivity if required, > for P2P. But again =85 not appropriate for this list. > > On Nov 2, 2012, at 6:58 PM, Henning Rogge wrote: > > > On Fri, Nov 2, 2012 at 6:39 PM, JP Vasseur (jvasseur) > > wrote: > >>> By your own words the effectiveness/overhead of LoadNG in LLNs > >>> compared to other protocols will most likely depend on the traffic > >>> patterns (which is also true for most other routing protocols, > >>> especially Ripple). > >> > >> JP> This is technically incorrect - RPL/OSPF/BGP =85 performances are = not > directly a function > >> of the user traffic. > > > > Ripple is a tree-based routing protocol. > > > > its really good when sending traffic towards the local root, not as > > good (but still good) when sending traffic from the root to its nodes, > > bad when you send traffic between two nodes with the same root and > > really bad when sending traffic between nodes that are not part of the > > same root tree. > > > > I would say its performance depends on the user traffic pattern. > > > > The overhead (as a comparison between control plane traffic and data > > plane traffic) is of course always different for each protocol > > depending on the user traffic. > > > > Henning Rogge > > -- > > Steven Hawkings about cosmic inflation: "An increase of billions of > > billions of percent in a tiny fraction of a second. Of course, that > > was before the present government." > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --047d7b677afa4634c904cd9888bd Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I realize it is exciting to discuss and people keep alluding to it so respo= nses are naturally triggers but=A0 I would ask you to please remove any fur= ther ROLL performance debates from this WG list.

Let us concentrate = on LOADng and DYMO documents and find a way forward.=A0




On Sa= t, Nov 3, 2012 at 4:25 AM, JP Vasseur (jvasseur) <jvasseur@cisco.com&= gt; wrote:
OK I will stop arguing here -- If I may reread what you wrote, then read RF= C6550 and you will quickly see why you mis-undertood the protocol.
Hint: think of DAG rooted at source of traffic, use address aggregatio= n mapping to topologies, P2P, storing of source routed paths.

On Nov 2, 2012, at 5:29 PM, Jon Black wrote:

Ah but now you mix apples and oranges.=A0 Storing mode is not good for high= ly constrained devices (they don't have the memory for storing mode) so= for many LLNs you are stuck with non-storing mode which is poor with P2MP,= but still fine with MP2P.=A0 And therefore Henning's point is valid.=A0 It depends on traffic.

Jon


From: JP Vasseur (jvasseur) = <jvasseur@cisco.= com>
To: Henning Rogge <hrogge@googlemail.com<= /a>>
Cc: "manet@ietf.org" <manet@ietf.org>
Sent: Friday, November 2, 20= 12 12:10 PM
Subject: Re: [manet] Reactiv= e Protocol Situation

Again your assumption are not correct - look at storing mode with OF to inc= rease connectivity if required,
for P2P. But again =85 not appropriate for this list.

On Nov 2, 2012, at 6:58 PM, Henning Rogge wrote:

> On Fri, Nov 2, 2012 at 6:39 PM, JP Vasseur (jvasseur)
> <jvasseur@c= isco.com> wrote:
>>> By your own words the effectiveness/overhead of LoadNG in LLNs=
>>> compared to other protocols will most likely depend on the tra= ffic
>>> patterns (which is also true for most other routing protocols,=
>>> especially Ripple).
>>
>> JP> This is technically incorrect - RPL/OSPF/BGP =85 performanc= es are not directly a function
>> of the user traffic.
>
> Ripple is a tree-based routing protocol.
>
> its really good when sending traffic towards the local root, not as > good (but still good) when sending traffic from the root to its nodes,=
> bad when you send traffic between two nodes with the same root and
> really bad when sending traffic between nodes that are not part of the=
> same root tree.
>
> I would say its performance depends on the user traffic pattern.
>
> The overhead (as a comparison between control plane traffic and data > plane traffic) is of course always different for each protocol
> depending on the user traffic.
>
> Henning Rogge
> --
> Steven Hawkings about cosmic inflation: "An increase of billions = of
> billions of percent in a tiny fraction of a second. Of course, that > was before the present government."

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet




_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--047d7b677afa4634c904cd9888bd-- From jpmacker@gmail.com Sat Nov 3 08:14:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAB821F9BAF for ; Sat, 3 Nov 2012 08:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.365 X-Spam-Level: X-Spam-Status: No, score=-3.365 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 188ayrKNCSXd for ; Sat, 3 Nov 2012 08:14:05 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 760C621F9851 for ; Sat, 3 Nov 2012 08:14:05 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so5138146vcb.31 for ; Sat, 03 Nov 2012 08:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=87rHk0JsEVd/NOitD/wK3YMfaERXeomhmnpG1t3wZgQ=; b=QSf8n/hFOOJhJZOcCV3WYDCCcjixCgCdygYsSqxK3THjybxawKwbvcyhyAdP7RFm/i eWPn+HCOs6Q8W+KyIdAjmuhA9R6R/2HaPYXSQ0nOY0OSNchnBuI/jVNgnqBTwBIsF01q XKwuENjzORLYf3atzHyDcHiLAU5EPhvn+E5sN754QhsU1T+Ly6LlYJtMg8Tdffulfvx+ eQdxVBQwN7yyJyvWt0lrfFXkNr0IsydCFYBJgqRGhrfzgFHY+qBPo72IBwULEIGw3Ddh /fNt54N9+N4AefcaOe+mP8JZKGzhsB4cbS5gXu3hU0hroXCp4vLYro0++JqpZthfW82S tXGw== MIME-Version: 1.0 Received: by 10.58.74.196 with SMTP id w4mr1173182vev.7.1351955644832; Sat, 03 Nov 2012 08:14:04 -0700 (PDT) Received: by 10.58.161.206 with HTTP; Sat, 3 Nov 2012 08:14:04 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> Date: Sat, 3 Nov 2012 11:14:04 -0400 Message-ID: From: Joseph Macker To: "JP Vasseur (jvasseur)" Content-Type: multipart/alternative; boundary=047d7b86edf6f65a3504cd98b37c Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 15:14:06 -0000 --047d7b86edf6f65a3504cd98b37c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Again I would ask that we move ROLL and LLN discussions to ROLL if people want to continue. JP your opinion to the WG chairs is pretty obvious. We need some bandwidth to discuss quality of documents and authors agreement to various other WG issues. I will provide some questions to that effect shortly. Let us focus on our WG's challenges. -Joe On Sat, Nov 3, 2012 at 4:32 AM, JP Vasseur (jvasseur) w= rote: > > On Nov 2, 2012, at 7:29 PM, Ulrich Herberg wrote: > > C=E9dric, > > On Fri, Nov 2, 2012 at 4:19 PM, C Chauvenet wrot= e: > >> [...] >> >> Right, but that "proof" was never published by the IETF, and as such >> only an assertion. Moreover, we are not the ROLL WG. >> >> >> I think http://tools.ietf.org/html/draft-ietf-roll-protocols-survey-07= is >> such a publication. >> > > That is the draft I was talking about. It is *not* a publication. It was > never published by the IETF, even though some claim it is a publication. > > > JP> If you are "picky" about IETF document state, you should then > propose to select *the* MANET working group document as a base: DYMO. > > > > BTW, it covers AODV and DYMO, and explains why it does not match >> general LLN requirements (and so for any AODV-based protocols such as >> LOADng). >> > > > The document was rejected for a reason. It is heavily flawed and > misleading, in my opinion. > > > >> But I agree that this is MANET list, so this should not be the place to >> debate RPL here. >> > > Right. > > > >> I think ROLL-ers came in the discussion because LOADng authors >> explicitly states that they want to use LOADng in LLNs, that is ROLL >> working space. >> > > And if that one word in the introduction is the whole reason why you > prefer DYMO over LOADng, it is a pretty weak argument. > And again, you cannot dispute the fact that LOADng is used in such > deployments. You may not like it, for business or other reasons, but it's= a > fact. > > > >> Though, I think you agree that LOADng will not match general LLN >> requirements and be limited to specific low traffic deployment. >> > > > I agree that LOADng (or DYMO for that matter) will not be suitable for > all LLN deployments. But it is, as a matter of fact, used in some such > deployments. > > > JP> Do you know how proprietary or non IETF standards are used in the > filed for that matter ? > The IETF is not here to standardize protocols used in the field because > they have been chosen in some deployment. > > RPL also does not fulfill all requirements of all kinds of LLNs, in my > opinion, but that's another matter not to be discussed here. > > Best > Ulrich > > > > >> >> C=E9dric. >> >> >> >>> >>> Could then prove that the current protocol cannot be used in your >>> environment before suggesting >>> to standardize a new one. >>> >>> Once again, if not applicable to LLNs, I have no problem whatsoever. >>> >> >> >> People have deployed reactive protocols as a matter of fact in LLNs. >> So, is the only reason why you like DYMO and not LOADng, because LOADng >> mentions the word LLN once in the introduction? >> >> Best regards >> Ulrich >> >> >> >>> >>> > If fact, the LOADng deployment experience strongly >>> > suggests that reactive routing protocols _will_ be deployed in >>> > some LLNs. And, they will be deployed regardless of the ROLL >>> > working group's decision to not standardize a reactive routing >>> > protocol. >>> >>> JP> And this is perfectly fine, people are free to use any protocol >>> they want, including proprietary >>> ones. This does not mean that the IETF should standardize them. >>> >>> > >>> > Claiming that reactive routing protocols don't work because they >>> > don't scale to higher traffic loads seems, >>> >>> JP> Then we need to characterize precisely the limits. >>> >>> > at best, a poor >>> > characterization of well-known research results, and at worst >>> > a distraction from the question at hand: namely how to proceed >>> > towards an Internet-standard reactive routing protocol. >>> > >>> > -tjs >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --047d7b86edf6f65a3504cd98b37c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Again I would ask that we move ROLL and LLN discussions to ROLL if people w= ant to continue.
JP your opinion to the WG chairs is pretty obvious.
=
We need some bandwidth to discuss quality of documents and authors agre= ement to various other WG issues.
I will provide some questions to that effect shortly. Let us focus on our W= G's challenges.

-Joe


On Sat, Nov 3, 2012 at 4:32 AM, JP Vasseur (jvasseur)= <jvasseur@cisco.com> wrote:

On Nov 2, 2012, at 7:29 PM, Ulrich Herberg wrote:

C=E9dric,

On Fri, Nov 2, 2012 at 4:19 PM, C Chauvenet <c.chauvene= t@watteco.com> wrote:
[...]

Right, but that "proof" was never published by the IETF, and= as such only an assertion. Moreover, we are not the ROLL WG.


That is the draft I was talking about. It is *not* a publication. It w= as never published by the IETF, even though some claim it is a publication.=

JP> If you are "picky" about IETF document state, y= ou should then propose to select *the* MANET working group document as a ba= se: DYMO.

=A0

BTW, it covers AODV and DYMO, and explains why it does not match gener= al LLN requirements (and so for any AODV-based protocols such as LOADng).


The document was rejected for a reason. It is heavily flawed and misle= ading, in my opinion.
=A0


But I agree that this is MANET list, so this should not be the place t= o debate RPL here.

Right.

=A0
I think ROLL-ers came in the discussion because LOADng authors explici= tly states that they want to use LOADng in LLNs, that is ROLL working space= .

And if that one word in the introduction is the whole reason why you p= refer DYMO over LOADng, it is a pretty weak argument.=A0
And again, you cannot dispute the fact that LOADng is used in such dep= loyments. You may not like it, for business or other reasons, but it's = a fact.

=A0
Though, I think you agree that LOADng will not match general LLN requi= rements and be limited to specific low traffic deployment.
=A0

I agree that LOADng (or DYMO for that matter) will not be suitable for= all LLN deployments. But it is, as a matter of fact, used in some such dep= loyments.

JP> Do you know how proprietary or non IETF standards are use= d in the filed for that matter ?
The IETF is not here to standardize protocols used in the field becaus= e they have been chosen in some deployment.

RPL also does not fulfill all requirements of all kinds of LLNs, in my= opinion, but that's another matter not to be discussed here.

Best
Ulrich


=A0

C=E9dric.

=A0

Could then prove that the current protocol cannot be used in your environme= nt before suggesting
to standardize a new one.

Once again, if not applicable to LLNs, I have no problem whatsoever.
=A0

People have deployed reactive protocols as a matter of fact in LLNs. S= o, is the only reason why you like DYMO and not LOADng, because LOADng ment= ions the word LLN once in the introduction?

Best regards
Ulrich

=A0

> If fact, the LOADng deployment experience strongly
> suggests that reactive routing protocols _will_ be deployed in
> some LLNs. =A0And, they will be deployed regardless of the ROLL
> working group's decision to not standardize a reactive routing
> protocol.

JP> And this is perfectly fine, people are free to use any protocol they= want, including proprietary
ones. This does not mean that the IETF should standardize them.

>
> Claiming that reactive routing protocols don't work because they > don't scale to higher traffic loads seems,

JP> Then we need to characterize precisely the limits.

> at best, a poor
> characterization of well-known research results, and at worst
> a distraction from the question at hand: namely how to proceed
> towards an Internet-standard reactive routing protocol.
>
> -tjs

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet




_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--047d7b86edf6f65a3504cd98b37c-- From jvasseur@cisco.com Sat Nov 3 08:17:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CECD21F9BBF for ; Sat, 3 Nov 2012 08:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.526 X-Spam-Level: X-Spam-Status: No, score=-10.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PZk0zxVFh7g for ; Sat, 3 Nov 2012 08:17:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 71E9721F992A for ; Sat, 3 Nov 2012 08:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9802; q=dns/txt; s=iport; t=1351955869; x=1353165469; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2hcXvgwvOBOmmnt4cEmA5naKsbUZMYj/oH0wum/MyJU=; b=je9LCIa5YJhzVzD+8VvP8SUH5ajucVs+2JHf1tyYlofxedQDefYuOJBl 5XngQFBj92GshRm+2taZKmzxvGr79d/J0X9jjEcpmpbktXAgIHCesFBMB ZmnMqyqDRcQ8/pOjzVCcnFNI7g0jEQEPczxwOBy4YBeKZcT+96P4c6t7s 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFU0lVCtJV2Y/2dsb2JhbABEgknAbIEIgh4BAQEDAQEBAQ8BWwsFCwIBCA4DBAEBAQodBycLFAkIAgQOBQgah1YDCQYLmWmVcQ2JUASLGWiFW2EDpFSBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,705,1344211200"; d="scan'208,217";a="138456898" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 03 Nov 2012 15:17:48 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA3FHmID027083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 15:17:48 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 10:17:48 -0500 From: "JP Vasseur (jvasseur)" To: Joseph Macker Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuRrYLPVi/cSo/ES1hdb7zda62w== Date: Sat, 3 Nov 2012 15:17:48 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204E2F9@xmb-rcd-x02.cisco.com> References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C638@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C877@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204CB91@xmb-rcd-x02.cisco.com> <1351891740.83248.YahooMailNeo@web160605.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204D717@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.229] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--34.247700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204E2F9xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 15:17:50 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204E2F9xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable completely agreeing ! On Nov 3, 2012, at 11:01 AM, Joseph Macker wrote: I realize it is exciting to discuss and people keep alluding to it so respo= nses are naturally triggers but I would ask you to please remove any furth= er ROLL performance debates from this WG list. Let us concentrate on LOADng and DYMO documents and find a way forward. On Sat, Nov 3, 2012 at 4:25 AM, JP Vasseur (jvasseur) > wrote: OK I will stop arguing here -- If I may reread what you wrote, then read RF= C6550 and you will quickly see why you mis-undertood the protocol. Hint: think of DAG rooted at source of traffic, use address aggregation map= ping to topologies, P2P, storing of source routed paths. On Nov 2, 2012, at 5:29 PM, Jon Black wrote: Ah but now you mix apples and oranges. Storing mode is not good for highly= constrained devices (they don't have the memory for storing mode) so for m= any LLNs you are stuck with non-storing mode which is poor with P2MP, but s= till fine with MP2P. And therefore Henning's point is valid. It depends o= n traffic. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Henning Rogge > Cc: "manet@ietf.org" > Sent: Friday, November 2, 2012 12:10 PM Subject: Re: [manet] Reactive Protocol Situation Again your assumption are not correct - look at storing mode with OF to inc= rease connectivity if required, for P2P. But again =85 not appropriate for this list. On Nov 2, 2012, at 6:58 PM, Henning Rogge wrote: > On Fri, Nov 2, 2012 at 6:39 PM, JP Vasseur (jvasseur) > > wrote: >>> By your own words the effectiveness/overhead of LoadNG in LLNs >>> compared to other protocols will most likely depend on the traffic >>> patterns (which is also true for most other routing protocols, >>> especially Ripple). >> >> JP> This is technically incorrect - RPL/OSPF/BGP =85 performances are no= t directly a function >> of the user traffic. > > Ripple is a tree-based routing protocol. > > its really good when sending traffic towards the local root, not as > good (but still good) when sending traffic from the root to its nodes, > bad when you send traffic between two nodes with the same root and > really bad when sending traffic between nodes that are not part of the > same root tree. > > I would say its performance depends on the user traffic pattern. > > The overhead (as a comparison between control plane traffic and data > plane traffic) is of course always different for each protocol > depending on the user traffic. > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772204E2F9xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable completely agreeing !

On Nov 3, 2012, at 11:01 AM, Joseph Macker wrote:

I realize it is exciting to discuss and people ke= ep alluding to it so responses are naturally triggers but  I would ask= you to please remove any further ROLL performance debates from this WG lis= t.

Let us concentrate on LOADng and DYMO documents and find a way forward.&nbs= p;




On Sat, Nov 3, 2012 at 4:25 AM, JP Vasseur (jvas= seur) <jvasseur@cisco.= com> wrote:
OK I will stop arguing here -- If I may= reread what you wrote, then read RFC6550 and you will quickly see why you = mis-undertood the protocol.
Hint: think of DAG rooted at source of traffic, use address aggregatio= n mapping to topologies, P2P, storing of source routed paths.

On Nov 2, 2012, at 5:29 PM, Jon Black wrote:

Ah but now you mix apples and oranges.  Storing mode is not good f= or highly constrained devices (they don't have the memory for storing mode)= so for many LLNs you are stuck with non-storing mode which is poor with P2MP, but still fine with MP2P.  And therefor= e Henning's point is valid.  It depends on traffic.

Jon


From: JP Vasseur (jvasseur) = <jvasseur@cisco.= com>
To: Henning Rogge <hrogge@googlemail.com<= /a>>
Cc: "manet@ietf.org" <manet@ietf.org>
Sent: Friday, November 2, 20= 12 12:10 PM
Subject: Re: [manet] Reactiv= e Protocol Situation

Again your assumption are not correct - look at storing mode with OF to inc= rease connectivity if required,
for P2P. But again =85 not appropriate for this list.

On Nov 2, 2012, at 6:58 PM, Henning Rogge wrote:

> On Fri, Nov 2, 2012 at 6:39 PM, JP Vasseur (jvasseur)
> <jvasseur@c= isco.com> wrote:
>>> By your own words the effectiveness/overhead of LoadNG in LLNs=
>>> compared to other protocols will most likely depend on the tra= ffic
>>> patterns (which is also true for most other routing protocols,=
>>> especially Ripple).
>>
>> JP> This is technically incorrect - RPL/OSPF/BGP =85 performanc= es are not directly a function
>> of the user traffic.
>
> Ripple is a tree-based routing protocol.
>
> its really good when sending traffic towards the local root, not as > good (but still good) when sending traffic from the root to its nodes,=
> bad when you send traffic between two nodes with the same root and
> really bad when sending traffic between nodes that are not part of the=
> same root tree.
>
> I would say its performance depends on the user traffic pattern.
>
> The overhead (as a comparison between control plane traffic and data > plane traffic) is of course always different for each protocol
> depending on the user traffic.
>
> Henning Rogge
> --
> Steven Hawkings about cosmic inflation: "An increase of billions = of
> billions of percent in a tiny fraction of a second. Of course, that > was before the present government."

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet




_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A772204E2F9xmbrcdx02ciscoc_-- From jblack.ietf@yahoo.com Sat Nov 3 08:28:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A0521F8AFC for ; Sat, 3 Nov 2012 08:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSG5P+alc7bK for ; Sat, 3 Nov 2012 08:28:48 -0700 (PDT) Received: from nm9.bullet.mail.bf1.yahoo.com (nm9.bullet.mail.bf1.yahoo.com [98.139.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 55D0521F8AF0 for ; Sat, 3 Nov 2012 08:28:48 -0700 (PDT) Received: from [98.139.215.143] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 15:28:47 -0000 Received: from [98.139.215.248] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 15:28:47 -0000 Received: from [127.0.0.1] by omp1061.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 15:28:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 817088.90149.bm@omp1061.mail.bf1.yahoo.com Received: (qmail 20614 invoked by uid 60001); 3 Nov 2012 15:28:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351956527; bh=0iSD/R9iNI4nIytoMZvpKwHEaApTONJjiVQRjOyrRx4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Wxghtt9fr4H7LO0dlGokbOZwMV1f2tHkrzmR0FMPVYY/+IdmxMBSU+rc02DYCuO7Mnxw6BZTWmDB8pL3cpsLMHWIaQODdT9Z36YJxWILcJDZY8HVQGe9/0cgUVTujb1W0IRbq0qMHNuDFjmiXBTMPV+3dDmkiNhwb99ARTltyP0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=eHZnV0SjCfw5ufcQg6Y13ktLLr7NQzxmgj9030TGFUxE28kCopqtqlKirS7CGQc3soQWdv/00tB+fLGvIVj7MIKyzjI4E/24umF/8d6DDPTtA0MzhSfCCzLJR/Hco/uaRfo2PWxGjvmB8r1waaiWdgzsCbP6p51n3T26VIxIY4w=; X-YMail-OSG: WB4wAlIVM1mTPLHdjNK3YrHqYkAA4.8choloLyupZdDHAUa _MR_0..IMGVSnRoiLUzZaUqOxWlK3v9LQt6CJcwC6.WDzF_6oqAzZvmtQ9bR GdLkzJxvygJ7x3NJIyrMmA7zPiHcbSHvzgY5AW2W.3w8ZiGEpDyM_gAP9t9v bR8AI6UWVFn7rSc.dk9v7JwlZ4l.KixFssNHZEoUPlG7CtVBZ5ZI52Dm8j0q GvkTHj89FFFuNFCcq5AHoQ3H.jOUUHaThTvwwKuUihcseodKluk.6ntMPRSx AwjpcL9.dyEWwIkwrtEXipUbJp.qGAHMb5b.MjyK4TwWduR8o6iev0m4WcDh GFsEOpWBE35qoxeg9jjSkJdpRAYtw3IN8Q9ujtj0jNpHyYNDDBbsbDNhEgDC iZzdoSY6Whw0jNQlOYBU6aZV57yS5sRPDl9OJI0UnonMiYpRWOmea04K_jP. irlyQ_g-- Received: from [67.213.218.72] by web160606.mail.bf1.yahoo.com via HTTP; Sat, 03 Nov 2012 08:28:47 PDT X-Rocket-MIMEInfo: 001.001, QWdyZWVkLsKgIFRoaXMgZG9jdW1lbnQgbmV2ZXIgd2VudCB0aHJvdWdoIHRoZSBJRVRGIHByb2Nlc3MgYW5kIHdhcyBhYmFuZG9uZWQgYnkgdGhlIFdHIHNvIGl0IHNlZW1zIGlycmVsZXZhbnQgdG8gdGhlIGRpc2N1c3Npb24uCgpJIGRvbid0IGV2ZW4gdGhpbmsgaXQgd2FzIGJyb3VnaHQgYmVmb3JlIG1hbmV0IGZvciByZXZpZXcuwqAgSSBhbSBzdXJlIHRoYXQgbWFuZXQgd291bGQgbm90IG5vdCBhZ3JlZWQgd2l0aCBpdHMgY29uY2x1c2lvbiBhbmQgc3VjaCBpcyB0aGUgcmVhc29uIGl0IHdhcyBub3QuCgoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> Message-ID: <1351956527.18637.YahooMailNeo@web160606.mail.bf1.yahoo.com> Date: Sat, 3 Nov 2012 08:28:47 -0700 (PDT) From: Jon Black To: Jiazi YI , C Chauvenet In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1874956439-343297097-1351956527=:18637" Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 15:28:50 -0000 --1874956439-343297097-1351956527=:18637 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Agreed.=C2=A0 This document never went through the IETF process and was aba= ndoned by the WG so it seems irrelevant to the discussion.=0A=0AI don't eve= n think it was brought before manet for review.=C2=A0 I am sure that manet = would not not agreed with its conclusion and such is the reason it was not.= =0A=0A=0AJon=0A=0A=0A=0A________________________________=0A From: Jiazi YI = =0ATo: C Chauvenet =0ACc: Timot= hy J. Salo ; "manet@ietf.org" =0ASent: F= riday, November 2, 2012 5:27 PM=0ASubject: Re: [manet] LOADng works=0A =0A= =0AHi,=C2=A0=0A=0AI don't think citing a draft that has been expired for 3 = years actually says anything.=C2=A0=0A=0Abest=0A=0AJiazi=0A=0A=0A=0AOn Nov = 3, 2012, at 12:19 AM, C Chauvenet wrote:=0A=0AHI,= =C2=A0 =0A>See inline.=0A>=0A>=0A>Le 2 nov. 2012 =C3=A0 18:22, Ulrich Herbe= rg a =C3=A9crit :=0A>=0A>JP,=0A>>=0A>>=0A>>On Fri, Nov 2, 2012 at 10:09 AM,= JP Vasseur (jvasseur) wrote:=0A>>=0A>>=0A>>>On Nov 2,= 2012, at 12:06 PM, Timothy J. Salo wrote:=0A>>>=0A>>>>>>> JP> This is not = just a question of "how large" it is =E2=80=A6 but also how=0A>>>>>>> dynam= ic. I could show you few hundreds (if not less number of nodes)=0A>>>>>>> n= ot working if the traffic pattern is too dynamic. This is a=0A>>>>>>> funda= mental problem.=0A>>>>=0A>>>> No, it is a fundamental and well-known charac= teristic of reactive=0A>>>> routing protocols. =C2=A0It is a problem only w= hen this behavior doesn't=0A>>>> match the characteristics of the network i= n which the reactive routing=0A>>>> protocol is deployed.=0A>>>=0A>>>=0AJP>= Indeed =E2=80=A6 and this is why you have a fundamental issue with you hav= e extremely high BER, PDR,=0A>>>low bandwidth =E2=80=A6 as we do in LLNs. F= looding in these networks is driven by user traffic and of course=0A>>>is h= ighly undesirable. Slightly increase the use traffic and you will see the i= mpact on the control plane ...=0A>>>=0A>>=0A>>=0A>>=0A>>=0A>>Yes, but as Ti= mothy mentioned, there are cases where you don't have much user traffic. Th= is is well known. If you have more user traffic, then you may need a proact= ive protocol. You may not like the idea that some people actually deploy re= active protocols in LLNs, but it's a fact.=C2=A0And your argument, again, m= akes no sense that you think that DYMO is suitable and LOADng is not.=0A>>= =0A>>=0A>>=C2=A0=0A>>>=0A>>>> We've known for at least 15 years that reacti= ve routing protocols are=0A>>>> more appropriate for light traffic loads an= d that proactive routing=0A>>>> protocols are more appropriate with heavier= traffic loads.=0A>>>=0A>>>=0AJP> This is over-simplying but I see what you= mean.=0A>>>=0A>>>=0A>>>> Dozens,=0A>>>> probably hundreds of research pape= rs have reiterated this result.=0A>>>> I don't know of any that have contra= dicted this result, although=0A>>>> some researchers have tried to develop = hybrid routing protocols=0A>>>> (which don't seem to have gained much tract= ion, either in the IETF=0A>>>> or elsewhere).=0A>>>>=0A>>>> Claiming that r= eactive routing protocols don't scale to heavier traffic=0A>>>> loads is ne= ither a new result nor particularly insightful -- this hasn't=0A>>>> change= d for at least 15 years.=0A>>>=0A>>>=0AJP> Let me restate my point. Not sur= e of what you mean by "heavier" =E2=80=A6 but if you=0A>>>flood the network= with probes each time you need to find a path in a LLN you have=0A>>>a maj= or problem. =0A>>=0A>>=0A>>Well, if you have few communication streams, the= few floods are much less heavy than having a proactive protocol exchange c= ontrol traffic all day. Again, no argument in favor for DYMO and against LO= ADng. Note also that you only talk about LLN, but we are the [manet] WG.=0A= >>=0A>>=0A>>=C2=A0=0A>>Of course, there are many ways to control flooding, = use caches ..=0A>>>that are all well-known and by the way hard to tune. But= overall, reactive routing in=0A>>>*these* networks is simply ill suited.= =0A>>>=0A>>>=0A>>>>=0A>>>> I haven't seen any evidence that _no_ LLN will e= xperience the sort of=0A>>>> light traffic load that matches the characteri= stics of a reactive=0A>>>> routing protocol. =C2=A0To the contrary, the dep= loyment experience with=0A>>>> LOADng suggests that such do networks exist.= =0A>>>=0A>>>=0AJP> Once again it all depends on the traffic profile. Of cou= rse you could make a=0A>>>reactive routing protocol work on a LLN as long a= s the user traffic has specific=0A>>>characteristics.=0A>>=0A>>=0A>>=0A>>= =0A>>Exactly! Thanks for pointing that out. That's the whole point why [man= et] is chartered to do both reactive and proactive protocols.=0A>>=0A>>=0A>= >=C2=A0=0A>>If you carefully analyze the user traffic characteristic in net= works=0A>>>such as smart metering (since this was mentioned on this list), = and you incorporate=0A>>>additional applications such as DA, .. to mention = a few, you will see that in most of=0A>>>these networks this simply does no= t work =E2=80=A6 too many flooding, ending up not even=0A>>>converging in s= ome cases, especially when the number of hops gets high with poor=0A>>>link= quality.=0A>>>=0A>>=0A>>=0A>>You are not bringing up any new argument that= is not known to [manet] for the last 15 years. Reactive protocols only wor= k for certain scenarios. We know that. We have never disputed that.=0A>>=0A= >>=0A>>=C2=A0=0A>>=0A>>>>=0A>>>> At the risk of arguing by analogy, the arg= ument that one can "prove"=0A>>>> that reactive routing protocols don't wor= k (in LLNs or elsewhere) seems=0A>>>> to =C2=A0make about as much as sense = as "proving" that OSPF doesn't work=0A>>>> because it doesn't behave well i= n dynamic environments. =C2=A0The failure of=0A>>>> OSPF in dynamic environ= ments didn't cause us to abandon OSPF: there are=0A>>>> many environments i= n which it works well.=0A>>>=0A>>>=0AJP> Not sure that I would have used th= is analogy :-( OSPF was not designed for highly=0A>>>dynamic environment in= deed *but* we could easily enhance it with fast failure detection=0A>>>(+ B= FD), fast LSA generation, fast SPF and incremental SPF, Local Fast Reroute,= =E2=80=A6=0A>>>because routers had lot of resources, links were highly sta= ble, =E2=80=A6 which is by far not the=0A>>>case of LLNs.=0A>>>=0A>>>=0A>>>= > Rather, we concluded that we=0A>>>> needed another routing protocol. =C2= =A0In a similar manner, the MANET=0A>>>> working group, and as far as I hav= e seen pretty much all of the=0A>>>> research community, concluded that the= re is a need for both a=0A>>>> reactive routing protocol and a proactive ro= uting protocol.=0A>>>>=0A>>>> Of course, the ROLL working group can decide = not to standardize=0A>>>> a reactive routing protocol. =C2=A0However, that = doesn't prove that=0A>>>> reactive routing protocols don't work (when they = match the=0A>>>> traffic characteristics of the network), that reactive rou= ting=0A>>>> protocols won't work better than proactive routing protocols=0A= >>>> in some LLNs (based on the characteristics of the traffic load),=0A>>>= > or that reactive routing protocols won't be successfully deployed=0A>>>> = in LLNs.=0A>>>=0A>>>=0AJP> Well =E2=80=A6 Think about this: when ROLL was f= ormed, the IESG explicitly and rightfully asked=0A>>>the WG to first prove = that none of the existing protocol could be used, before standardizing a=0A= >>>new protocol (that was the right choice !!).=0A>>>=0A>>=0A>>=0A>>=0A>>= =0A>>Right, but that "proof" was never published by the IETF, and as such o= nly an assertion. Moreover, we are not the ROLL WG.=0A>=0A>=0A>I think=C2= =A0http://tools.ietf.org/html/draft-ietf-roll-protocols-survey-07=C2=A0is s= uch a publication.=0A>BTW, it covers AODV and DYMO, and explains why it doe= s not match general LLN requirements (and so for any AODV-based protocols s= uch as LOADng).=0A>=0A>=0A>But I agree that this is MANET list, so this sho= uld not be the place to debate RPL here.=0A>I think ROLL-ers came in the di= scussion because LOADng authors explicitly states that they want to use LOA= Dng in LLNs, that is ROLL working space. Though, I think you agree that LOA= Dng will not match general LLN requirements and be limited to specific low = traffic deployment.=0A>=0A>=0A>C=C3=A9dric.=0A>=0A>=C2=A0=0A>>=0A>>>Could t= hen prove that the current protocol cannot be used in your environment befo= re suggesting=0A>>>to standardize a new one.=0A>>>=0A>>>Once again, if not = applicable to LLNs, I have no problem whatsoever.=0A>>>=0A>>=C2=A0=0A>>=0A>= >=0A>>People have deployed reactive protocols as a matter of fact in LLNs. = So, is the only reason why you like DYMO and not LOADng, because LOADng men= tions the word LLN once in the introduction?=0A>>=0A>>=0A>>Best regards=0A>= >Ulrich=0A>>=0A>>=0A>>=C2=A0=0A>>=0A>>>> If fact, the LOADng deployment exp= erience strongly=0A>>>> suggests that reactive routing protocols _will_ be = deployed in=0A>>>> some LLNs. =C2=A0And, they will be deployed regardless o= f the ROLL=0A>>>> working group's decision to not standardize a reactive ro= uting=0A>>>> protocol.=0A>>>=0A>>>=0AJP> And this is perfectly fine, people= are free to use any protocol they want, including proprietary=0A>>>ones. T= his does not mean that the IETF should standardize them.=0A>>>=0A>>>=0A>>>>= =0A>>>> Claiming that reactive routing protocols don't work because they=0A= >>>> don't scale to higher traffic loads seems,=0A>>>=0A>>>=0AJP> Then we n= eed to characterize precisely the limits.=0A>>>=0A>>>=0A>>>> at best, a poo= r=0A>>>> characterization of well-known research results, and at worst=0A>>= >> a distraction from the question at hand: namely how to proceed=0A>>>> to= wards an Internet-standard reactive routing protocol.=0A>>>>=0A>>>> -tjs=0A= >>>=0A>>>_______________________________________________=0A>>>manet mailing= list=0A>>>manet@ietf.org=0A>>>https://www.ietf.org/mailman/listinfo/manet= =0A>>>=0A>>_______________________________________________=0A>>manet mailin= g list=0A>>manet@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/manet= =0A>>=0A>=0A_______________________________________________=0A>manet mailin= g list=0A>manet@ietf.org=0A>https://www.ietf.org/mailman/listinfo/manet=0A>= =0A=0A_______________________________________________=0Amanet mailing list= =0Amanet@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/manet --1874956439-343297097-1351956527=:18637 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Agreed.  This do= cument never went through the IETF process and was abandoned by the WG so i= t seems irrelevant to the discussion.

I don't even think it was brou= ght before manet for review.  I am sure that manet would not not agree= d with its conclusion and such is the reason it was not.

=
Jon

<= b>From: Jiazi YI <ietf@jiaz= iyi.com>
To: C Chau= venet <c.chauvenet@watteco.com>
Cc: Timothy J. Salo <salo@saloits.com>; "manet@iet= f.org" <manet@ietf.org>
Se= nt: Friday, November 2, 2012 5:27 PM
Subject: Re: [manet] LOADng works
=0A
Hi, =

I don't think citing a draft that has been expired for 3 years act= ually says anything. 
best

Jiazi

=0A
=0A=0A
On Nov 3, 201= 2, at 12:19 AM, C Chauvenet <c.chauvenet@watteco.com> wrote:

=0A=0A =0A=0A
=0AHI, =0A
See inline.
=0A
=0A
=0A
=0A
Le 2 nov. 2012 =C3=A0 18:22, Ulrich Herberg a =C3= =A9crit :
=0A
=0AJP,
=0A
=0A
On Fri, Nov 2, 2012 at 10:09 AM, JP Vasseur (jvasseur) =0A<jvasseur@cisco.com> wrote:
=0A
=0A

=0AOn Nov 2, 2012, at 12:06 PM, Timothy J. Salo wr= ote:
=0A
=0A>>>> JP> This is not just a question of "h= ow large" it is =E2=80=A6 but also how
=0A>>>> dynamic. I co= uld show you few hundreds (if not less number of nodes)
=0A>>>&= gt; not working if the traffic pattern is too dynamic. This is a
=0A>= >>> fundamental problem.
=0A>
=0A> No, it is a fundame= ntal and well-known characteristic of reactive
=0A> routing protocols= .  It is a problem only when this behavior doesn't
=0A> match th= e characteristics of the network in which the reactive routing
=0A> p= rotocol is deployed.
=0A
=0A
=0AJP> Indeed =E2=80=A6 and this= is why you have a fundamental issue with you have extremely high BER, PDR,=
=0Alow bandwidth =E2=80=A6 as we do in LLNs. Flooding in these networks= is driven by user traffic and of course
=0Ais highly undesirable. Sligh= tly increase the use traffic and you will see the impact on the control pla= ne ...
=0A
=0A

=0A
=0A

=0A
=0AYes, but as Timothy mentioned, there are cases where you don't have much u= ser traffic. This is well known. If you have more user traffic, then you ma= y need a proactive protocol. You may not like the idea that some people act= ually deploy reactive protocols=0A in LLNs, but it's a fact. And your = argument, again, makes no sense that you think that DYMO is suitable and LO= ADng is not.
=0A

=0A
=0A
 
=0A
=0A
>
=0A= > We've known for at least 15 years that reactive routing protocols are<= br>=0A> more appropriate for light traffic loads and that proactive rout= ing
=0A> protocols are more appropriate with heavier traffic loads.=0A
=0A
=0AJP> This is over-simplying but I see what you mean.=
=0A

=0A> Dozens,
=0A> probabl= y hundreds of research papers have reiterated this result.
=0A> I don= 't know of any that have contradicted this result, although
=0A> some= researchers have tried to develop hybrid routing protocols
=0A> (whi= ch don't seem to have gained much traction, either in the IETF
=0A> o= r elsewhere).
=0A>
=0A> Claiming that reactive routing protocol= s don't scale to heavier traffic
=0A> loads is neither a new result n= or particularly insightful -- this hasn't
=0A> changed for at least 1= 5 years.
=0A
=0A
=0AJP> Let me restate my point. Not sure of = what you mean by "heavier" =E2=80=A6 but if you
=0Aflood the network wit= h probes each time you need to find a path in a LLN you have
=0Aa major = problem.
=0A

=0A
=0A
Well, if you have few co= mmunication streams, the few floods are much less heavy than having a proac= tive protocol exchange control traffic all day. Again, no argument in favor= for DYMO and against LOADng. Note also that you only talk about LLN, but w= e are=0A the [manet] WG.
=0A

=0A
=0A
 
=0A<= blockquote class=3D"yiv438605259gmail_quote" style=3D"margin:0 0 0 .8ex;bor= der-left:1px #ccc solid;padding-left:1ex;">=0AOf course, there are many way= s to control flooding, use caches ..
=0Athat are all well-known and by t= he way hard to tune. But overall, reactive routing in
=0A*these* network= s is simply ill suited.
=0A

=0A>
= =0A> I haven't seen any evidence that _no_ LLN will experience the sort = of
=0A> light traffic load that matches the characteristics of a reac= tive
=0A> routing protocol.  To the contrary, the deployment exp= erience with
=0A> LOADng suggests that such do networks exist.
=0A=
=0A
=0AJP> Once again it all depends on the traffic profile. Of= course you could make a
=0Areactive routing protocol work on a LLN as l= ong as the user traffic has specific
=0Acharacteristics.
=0A=

=0A
=0A

=0A
=0A
Exactly! Thanks for pointing= that out. That's the whole point why [manet] is chartered to do both react= ive and proactive protocols.
=0A

=0A
=0A
 
= =0A
=0AIf you carefully analyze = the user traffic characteristic in networks
=0Asuch as smart metering (s= ince this was mentioned on this list), and you incorporate
=0Aadditional= applications such as DA, .. to mention a few, you will see that in most of=
=0Athese networks this simply does not work =E2=80=A6 too many flooding= , ending up not even
=0Aconverging in some cases, especially when the nu= mber of hops gets high with poor
=0Alink quality.
=0A
=0A=

=0A
=0A
You are not bringing up any new argument that is = not known to [manet] for the last 15 years. Reactive protocols only work fo= r certain scenarios. We know that. We have never disputed that.
=0A
=0A
=0A
 
=0A
=0A

=0A>
=0A> At the risk = of arguing by analogy, the argument that one can "prove"
=0A> that re= active routing protocols don't work (in LLNs or elsewhere) seems
=0A>= to  make about as much as sense as "proving" that OSPF doesn't work=0A> because it doesn't behave well in dynamic environments.  The= failure of
=0A> OSPF in dynamic environments didn't cause us to aban= don OSPF: there are
=0A> many environments in which it works well.=0A
=0A
=0AJP> Not sure that I would have used this analogy :-(= OSPF was not designed for highly
=0Adynamic environment indeed *but* we= could easily enhance it with fast failure detection
=0A(+ BFD), fast LS= A generation, fast SPF and incremental SPF, Local Fast Reroute, =E2=80=A6=0Abecause routers had lot of resources, links were highly stable, =E2=80= =A6 which is by far not the
=0Acase of LLNs.
=0A

=0A> Rather, we concluded that we
=0A> needed another= routing protocol.  In a similar manner, the MANET
=0A> working = group, and as far as I have seen pretty much all of the
=0A> research= community, concluded that there is a need for both a
=0A> reactive r= outing protocol and a proactive routing protocol.
=0A>
=0A> Of = course, the ROLL working group can decide not to standardize
=0A> a r= eactive routing protocol.  However, that doesn't prove that
=0A>= reactive routing protocols don't work (when they match the
=0A> traf= fic characteristics of the network), that reactive routing
=0A> proto= cols won't work better than proactive routing protocols
=0A> in some = LLNs (based on the characteristics of the traffic load),
=0A> or that= reactive routing protocols won't be successfully deployed
=0A> in LL= Ns.
=0A
=0A
=0AJP> Well =E2=80=A6 Think about this: when ROLL= was formed, the IESG explicitly and rightfully asked
=0Athe WG to first= prove that none of the existing protocol could be used, before standardizi= ng a
=0Anew protocol (that was the right choice !!).
=0A
= =0A

=0A
=0A

=0A
=0A
Right, but that "proof" w= as never published by the IETF, and as such only an assertion. Moreover, we= are not the ROLL WG.
=0A
=0A=0A

=0A
= =0A=0A
BTW, it covers AODV and DYMO, and explains why it does not ma= tch general LLN requirements (and so for any AODV-based protocols such as L= OADng).
=0A

=0A
=0A
But I agree that this is MANET li= st, so this should not be the place to debate RPL here.
=0A
I thin= k ROLL-ers came in the discussion because LOADng authors explicitly states = that they want to use LOADng in LLNs, that is ROLL working space. Though, I= think you agree that LOADng will not match general LLN requirements and be= limited to specific=0A low traffic deployment.
=0A

=0A
= =0A
C=C3=A9dric.
=0A
=0A
=0A
=0A
 
=0A
=0A
=0ACould then prove that the current protocol c= annot be used in your environment before suggesting
=0Ato standardize a = new one.
=0A
=0AOnce again, if not applicable to LLNs, I have no prob= lem whatsoever.
=0A
=0A
 
=0A

=0A=0A
People have deployed reactive protocols as a matter of fact in LLN= s. So, is the only reason why you like DYMO and not LOADng, because LOADng = mentions the word LLN once in the introduction?
=0A

=0A
= =0A
Best regards
=0A
Ulrich
=0A

=0A
=0A
=  
=0A
=0A

=0A> If fact, the LOADng deployment experience stro= ngly
=0A> suggests that reactive routing protocols _will_ be deployed= in
=0A> some LLNs.  And, they will be deployed regardless of th= e ROLL
=0A> working group's decision to not standardize a reactive ro= uting
=0A> protocol.
=0A
=0A
=0AJP> And this is perfect= ly fine, people are free to use any protocol they want, including proprieta= ry
=0Aones. This does not mean that the IETF should standardize them.=0A

=0A>
=0A> Claiming that reac= tive routing protocols don't work because they
=0A> don't scale to hi= gher traffic loads seems,
=0A
=0A
=0AJP> Then we need to char= acterize precisely the limits.
=0A
=0A<= div class=3D"yiv438605259h5">
=0A> at best, a poor
=0A> charact= erization of well-known research results, and at worst
=0A> a distrac= tion from the question at hand: namely how to proceed
=0A> towards an= Internet-standard reactive routing protocol.
=0A>
=0A> -tjs=0A
=0A_______________________________________________
=0Amanet mail= ing list
=0Amanet@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/manet
=0A
=0A=0A
=0A
=0A
=0A____________________________________= ___________
=0Amanet mailing list
=0Amane= t@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/= manet
=0A
=0A
=0A
=0A
=0A
=0A
=0A= =0A_______________________________________________
manet mailing listmanet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet


____________________________= ___________________
manet mailing list
manet@ietf.org
https://www.ietf= .org/mailman/listinfo/manet


--1874956439-343297097-1351956527=:18637-- From loli_m1@yahoo.fr Sat Nov 3 08:33:04 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D0E21F9055 for ; Sat, 3 Nov 2012 08:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.601 X-Spam-Level: ** X-Spam-Status: No, score=2.601 tagged_above=-999 required=5 tests=[BAYES_80=2, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pG3XV7b3-7gF for ; Sat, 3 Nov 2012 08:33:04 -0700 (PDT) Received: from nm18.bullet.mail.ird.yahoo.com (nm18.bullet.mail.ird.yahoo.com [77.238.189.71]) by ietfa.amsl.com (Postfix) with ESMTP id 08F1F21F8BB2 for ; Sat, 3 Nov 2012 08:33:03 -0700 (PDT) Received: from [212.82.105.244] by nm18.bullet.mail.ird.yahoo.com with NNFMP; 03 Nov 2012 15:32:53 -0000 Received: from [212.82.108.116] by tm16.bullet.mail.ird.yahoo.com with NNFMP; 03 Nov 2012 15:32:53 -0000 Received: from [127.0.0.1] by omp1025.mail.ird.yahoo.com with NNFMP; 03 Nov 2012 15:32:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 720589.23152.bm@omp1025.mail.ird.yahoo.com Received: (qmail 10878 invoked by uid 60001); 3 Nov 2012 15:32:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1351956773; bh=yvE9p7wXdmUXjI+UWo2HkLQZmZQeY3F+ZFZoUGxWttY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=ltJzxv8sbckzkrpxXzrqobnBPbuKqgYMG/QyFF4Ew9Skbgm8++k6pf7YDZF8t2l4AiHuCUQ0Jt5VgLry2tfaj0RyvMshF9ccTzykbwZzx48CLv/roXyP26RFygc/r18ejbs0bl7NkSXLyb24Y6E5evoN2ppk/3MVt0xr+Ya7ZPM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=bg55kn1pazarE8Vg1X4UQECD5aw9Ymw9/ENJeIDvYGj3OERCnAkaQ4ifXomfZSAH1CgqLcqi4Yc2+xAT5kPu8QmBhn6V79Cg46bkZpNXciFM669OFlVzNbvo628IQqZrltSOdaal2NCXWItLGzkYlNrdKbzXhvxUdJ7pe/9ZVZY=; X-YMail-OSG: Xq2_RgQVM1kFhVvI0_Nuu3YCWgT3dc3GzuXpVhl2AMar1QQ abHdaOWxQTAXj_XZWb689colNa0oGr7rQ_ce9l3lzWou3PiylmRtYJMvgR3A AYLuIG9H0zL40J4h2PhcSojVQtEpoDSa.NhGbfF_0JjPp73kkeXU0RWaM27_ tSrxO8OnICGPCbqFYzTELeiGCHE4h0jz8YM0boaFyiV10_fAED5d4gDg2HkD PIxWun3Q_a57RU4wEx66issicl4w4JcXir7KUAFsqAxYjgwF5gYJ8I7LJ1CS FI4kIsTROgT509BQmc0kIM_j7SfbJcw0YBnSyXngHQBTPYLv2ApxuplJQ9mt ZnDh5owHmXhKBvqhbpwe8Ng0MimkYGaANmp2dhprwPzHPMJkow9JsR6Y6Cq. 50q1vQp86s8w- Received: from [80.88.14.237] by web133201.mail.ir2.yahoo.com via HTTP; Sat, 03 Nov 2012 15:32:53 GMT X-Rocket-MIMEInfo: 001.001, SGkgbWFuZXQgbWFpbGxpbmcgbGlzdCBtZW1iZXJzO0knbSBhIG5ldyBucy0yIHVzZXIsIGFuZCBpIG5lZWQgeW91ciBoZWxwIHBsZWFzZS4NCkknbSBzaW11bGF0aW5nIGEgbmV0d29yaywgd2hlcmUgbm9kZXMgYXJlIGVxdWlwcGVkIGJ5IGdwcyBkZXZpY2VzLldoYXQgaSB3b250IGlzIHNlbmRpbmcgYSByZXF1ZXN0IHRvIGEgbm9kZSAoc291cmNlKSB0aGF0IGkga25veCBoaXMgY29vcmRpbmF0ZXPCoA0Kc2V0IHhzb3VyY2UgWyRub2RlXygkTlNvdXJjZSkgc2V0IFhfXXNldCB5c291cmNlIFskbm9kZV8oJE4BMAEBAQE- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.123.460 Message-ID: <1351956773.4362.YahooMailClassic@web133201.mail.ir2.yahoo.com> Date: Sat, 3 Nov 2012 15:32:53 +0000 (GMT) From: Louiza Louiza To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1982344905-1884994754-1351956773=:4362" Subject: [manet] Send a request (Geographic routing). X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 15:33:04 -0000 --1982344905-1884994754-1351956773=:4362 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi manet mailling list members;I'm a new ns-2 user, and i need your help pl= ease. I'm simulating a network, where nodes are equipped by gps devices.What i wo= nt is sending a request to a node (source) that i knox his coordinates=A0 set xsource [$node_($NSource) set X_]set ysource [$node_($NSource) set Y_]s= et xid [$node_($Node_info($id)) set X_]set yid [$node_($Node_info($id)) set= Y_] if {[getdist $xsource $ysource $xid $yid] <=3D $radius} {# Send the request= in one hop (directely)...} else {# Send the request to a node closer to th= e source node...} I dont know how i send the request ??????? Thank you for helping me. --1982344905-1884994754-1351956773=:4362 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi manet mailling list members;
I'm a new= ns-2 user, and i need your help please.

I'm simul= ating a network, where nodes are equipped by gps devices.
What i = wont is sending a request to a node (source) that i knox his coordinates&nb= sp;

set xsource [$node_($NSource) set X_]
set ysource [$node_($NSource) set Y_]
set xid [$node_($Nod= e_info($id)) set X_]
set yid [$node_($Node_info($id)) set Y_]

if {[getdist $xsource $ysource $xid $yid] = <=3D $radius} {
# Send the request in one hop (directely)
...
} else {
# Send the request to a node closer = to the source node
...
}

I dont know how i send the request ???????


Thank you for helping me.<= /div>
--1982344905-1884994754-1351956773=:4362-- From adrian@olddog.co.uk Sat Nov 3 08:33:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DC821F9C51 for ; Sat, 3 Nov 2012 08:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydmMlTsEQUnj for ; Sat, 3 Nov 2012 08:33:47 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 215A921F93E0 for ; Sat, 3 Nov 2012 08:33:46 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id qA3FXfXC009196; Sat, 3 Nov 2012 15:33:41 GMT Received: from 950129200 ([80.187.201.110]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id qA3FXKiG009088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 3 Nov 2012 15:33:31 GMT From: "Adrian Farrel" To: "'Teco Boot'" , "'Henning Rogge'" Date: Sat, 3 Nov 2012 15:33:19 -0000 Message-ID: <005101cdb9d8$9a3ee4e0$cebcaea0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac252G9HgtGLDdc7SUqoOvHP2+GwKg== Content-Language: en-gb Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org, 'Thomas Heide Clausen' Subject: [manet] End to end security [Was? Reactive routing protocols, what are the differences?] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 15:33:48 -0000 Op 2 nov. 2012, om 13:01 heeft Henning Rogge het volgende geschreven: > (Does BGP have some ideas how to do end-to-end security? Its the only > Distance Vector Protocol I know that is widely deployed.) Please be aware of the work in SIDR. Cheers, Adrian From jblack.ietf@yahoo.com Sat Nov 3 08:42:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8153121F9C4D for ; Sat, 3 Nov 2012 08:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.803 X-Spam-Level: X-Spam-Status: No, score=-1.803 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhIiQc8PMlfE for ; Sat, 3 Nov 2012 08:42:17 -0700 (PDT) Received: from nm29.bullet.mail.bf1.yahoo.com (nm29.bullet.mail.bf1.yahoo.com [98.139.212.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0C521F9C55 for ; Sat, 3 Nov 2012 08:42:16 -0700 (PDT) Received: from [98.139.215.141] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 15:42:16 -0000 Received: from [98.139.212.248] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 15:42:16 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 15:42:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 45871.64426.bm@omp1057.mail.bf1.yahoo.com Received: (qmail 1926 invoked by uid 60001); 3 Nov 2012 15:42:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351957335; bh=YH/khzaCrKvKb8R//QYIbLBj/vECykzDmhXM8AtHJ+c=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=KjSEFMTVHsZe4abGFR61OrASorMUxo3uXFw/wlOLc5LiFIYhh94wP2uFEBUauGAYHF4PD0QcX0h2fOdH9u+MdoNfUG6/bRn9qZYOW6M8ZumOSeWaKwpous1WisWNTkQSCiCyhRcAMX7ahOkcyPbMyf8/RrqnJXDzQnzYpXyJPe8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=et/iCSagnkOn0iqux9skPhxNoyolOqXw2STW+RWkGjG5dNNqKhKum9+pTifUSIHLfjdT/rWrujvO/e+Tu/KFfXClyqDBINsUgh+U5Nbf6CKn7gauj77zbxiS3H2aRPKfkNDRSF5OysKh4L51aD7armpf04XUK+EK792mXALuU5U=; X-YMail-OSG: bD.bG20VM1npt4G1zzTHCEEVCbMeF_nQ4wFcxnFNEPoaSO6 Gxtec6ERtX8_6QvdfkrZ5jtekzDlvA7hMFnmV2REqknsZ.5dsmZD8Q3Mg04_ bsndIlFcODb6dxJ8.dYhnZdkWLt.KaTd_Rq_I7_kuq4beeHWn5zz7u8jZLEw s9ZT02SjnGec7Agzdrib6km2zp4Q0aFcF83K1WVm342dC9xTmemmF.Hgf1dh EE4XQhrwygx1bcc7.ntEPwH1lXcLypJT9WVkeQG4yoHsgKs0B0hj8fZB6pD5 PeshtpgO8SN2cwAlGvCrduSGOCB_mn5LAXqEhJaSVsn1ycQPSpfZ0rncZs2m MpNIX0Zv3OaQ9f1c9l8xSKzJNqIntGdruiaoGhQKD9DIAOVenfCTiijdC3zt yDrA4xZWfZVgki.F5LttP_rc_J0_gR.E5nahEQ4fdZhomfV3REs4jHPYdE_l 5xF51r98- Received: from [67.213.218.72] by web160603.mail.bf1.yahoo.com via HTTP; Sat, 03 Nov 2012 08:42:15 PDT X-Rocket-MIMEInfo: 001.001, V2hhdCB5b3UgY29udGVuZCBpcyB0aGF0IGEgcmVhY3RpdmUgcHJvdG9jb2wgY2Fubm90IGJlIHVzZWQgaW4gYW4gTExOIChKdXN0IHBsYWluIHdyb25nLCBidXQgdGhhdCBpc24ndCB0aGlzIGRpc2N1c3Npb24uwqAgWW91IGRlcmFpbGVkIHRoZSBkaXNjdXNzaW9uIGJyaW5naW5nIGl0IHRvIHRoYXQuKcKgIEJ1dCB0aGF0IGlzbid0IHRoZSBpc3N1ZSBiZWZvcmUgdGhlIGdyb3VwLgoKWW91IGhhdmUgbm8gc3Vic3RhbnRpdmUgdGVjaG5pY2FsIGFyZ3VtZW50cyBvbiB3aHkgd2Ugc2hvdWxkIHByb2NlZWQgd2kBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <1351889394.5207.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204D666@xmb-rcd-x02.cisco.com> Message-ID: <1351957335.1256.YahooMailNeo@web160603.mail.bf1.yahoo.com> Date: Sat, 3 Nov 2012 08:42:15 -0700 (PDT) From: Jon Black To: "JP Vasseur \(jvasseur\)" In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204D666@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1886287700-1595170763-1351957335=:1256" Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 15:42:18 -0000 --1886287700-1595170763-1351957335=:1256 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable What you contend is that a reactive protocol cannot be used in an LLN (Just= plain wrong, but that isn't this discussion.=C2=A0 You derailed the discus= sion bringing it to that.)=C2=A0 But that isn't the issue before the group.= =0A=0AYou have no substantive technical arguments on why we should proceed = with DYMO rather than LOADng.=0A=0Ait appears you only real objection to th= e LOADng draft is the name and that it suggests that it can be used in LLNs= .=C2=A0 Your acceptance of the DYMO draft is not at all technical. [Your co= ncerns about LOADng used in LLNs apply equally to DYMO, so there is no tech= nical argument between moving forward with DYMO or LOADng].=C2=A0 You accep= t DYMO because the current draft does not indicate that it can be used in a= n LLN.=0A=0AYou don't like the name and you don't like that the authors ind= icated it could be used in some LLN applications (which it can).=0A=0AI and= other have said that the current state of the draft is that the DYMO draft= needs a lot of major work and things have to cut down to generate a draft = that is implementable.=C2=A0 We have said that the LOADng draft appears to = be closer to stable, is implementable (there are multiple implementations) = but still needs working group input to complete.=0A=0AAny discussion of if = a reactive protocol could be or should be used in an LLN can be taken to RO= LL for now and into the market.=0A=0AThis discussion should be about the di= fferences in the drafts (which Ulrich has pointed out) and only that so tha= t we can find the best starting point.=0A=0AIf you have specific points in = the differences between the drafts bring them up.=0A=0AWe now know you don'= t like the name and the paragraph about LLNs=0A=0AJon=0A=0A=0A=0A=0A_______= _________________________=0A From: JP Vasseur (jvasseur) =0ATo: Jon Black =0ACc: Ulrich Herberg ; "manet@ietf.org" =0ASent: Saturday, November = 3, 2012 2:10 AM=0ASubject: Re: [manet] Reactive Protocol Situation=0A =0A= =0AHi "Jon" =0A=0AYou can keep ignoring what I am writing =E2=80=A6 but thi= s does not help. The issue is not "this" paragraph - I explained why a numb= er of times.=0AAnd proposed a way to go, call it option 1.5.=0A=0A=0AOn Nov= 2, 2012, at 4:49 PM, Jon Black wrote:=0A=0AFrom: JP Vasseur (jvasseur) =0A>=0A>On Nov 2, 2012, at 11:08 AM, Ulrich Herberg wrote:= =0A>=0A>I think one key point to stress is one that Chris mentioned:=0A>>Bo= th protocols are similar in their operation and performance. So anyone argu= ing against the performance of LOADng is automatically also not interested = in DYMO. =0A>>=0A>>=0A>=0A>=0A>See my point Ulrich =E2=80=A6 and I wrote it= down several times. There are major concerns in using Load-ng with LLNs. Q= uoting Load-ng:=0A>=0A>=0A>3. Applicability Statement This protocol: o Is= a reactive routing protocol for Mobile Ad hoc NETworks (MANETs). o Is des= igned to work in networks with dynamic topology in which the links may be l= ossy due to collisions or unstable channel. The use cases include vehicula= r networks, low power and lossy networks, community networks, military netw= orks, disaster recovery networks, etc. =0A>=0A>=0A>This is where I strongly= object, as several other ones on this mailing list. One cannot simply forg= et 4-5 years of hard work from a WG that focussed=C2=A0=0A>on this use case= =C2=A0and concluded that such protocol is not applicable to LLNs.=0A>=0A>= =0A[Jon] Is that your true objection to the LOADng draft.=C2=A0 Then I woul= d think the simple solution is to remove this one paragraph and move on.=C2= =A0 =0A>Developers will=C2=A0 decide what protocols are applicable to their= application as they should - as I will.=0A>I will ask in ROLL where the co= nclusion was drawn that you cannot possibly use a reactive protocol in any = LLN application.=C2=A0 That is for a discussion in ROLL not here.=0A>Again = if this one paragraph is all the fuss then lets please reach consensus to r= emove this and move forward.=C2=A0 Gosh that seems simple.=0A>=0A>Jon=0A>= =0A>=0A>=0A>=0A>=0A>However, LOADng is far closer to become an RFC in terms= of the document quality. If we start the new reactive protocol on the basi= s of the LOADng draft (and I personally don't care what we name that protoc= ol is), we can continue the work on the reactive protocol together and disc= uss the multiple options that are currently in DYMO and see whether they sh= ould be discarded, put into a companion document or in the core spec. =0A>>= =0A>>Best=0A>>Ulrich=0A>>=0A>>On Nov 2, 2012, at 7:54, Yuichi IGARASHI wrote:=0A>>=0A>>=0A>>Hi,=0A>>>=0A>>=0A>>>=0A>>= I agree with Martin and I would support option 2) at this stage.=0A>>>=0A>>= =0A>>>=0A>>We LOADng co-authors made efforts to simplify core specification= of the reactive protocol and to improve the readability of the draft. I th= ink this approach is important not only for all implementor to shorten the = development time, but also for business operators to make multi-vendor syst= em easier to provide. Of course, I agree that, as several persons pointed o= ut, "this draft" may limit use case. But we leave sufficient space for impr= oving performance/adding functions by companion drafts.=0A>>>=0A>>=0A>>>=0A= >>I am really concerned about complexity/difficulty of guaranteeing of inte= roperability. If the protocol becomes complicated, we need much time(many y= ears?) for interoperability test. I think we should consider both time requ= ired for merging drafts and shape of document.=0A>>>=0A>>=0A>>>=0A>>Best re= gards,=0A>>>=0A>>Yuichi=0A>>>=0A>>(2012/11/02 23:01), Martin Heusse wrote:= =0A>>>=0A>>=0A>>>>=0A>>I'm standing for option 2 (LOADng).=0A>>>>=0A>>=0A>>= >>=0A>>I think it's better to agree first on a simple basic (versatile?) pr= otocol before proposing extensions to it; instead of starting from a collec= tion of ideas that can be used or not (and we know today what are the optio= ns, thank to the huge amount of work done on reactive routing during the pa= st years). Conversely, it would be certainly easier to reach a consensus on= a set of variants but we need a good reference point, first.=0A>>>>=0A>>= =0A>>>>=0A>>Moreover, reactive routing is most probably the approach that o= ne would pick for a simple case. So it should be simple...=0A>>>>=0A>>=0A>>= >>=0A>>Martin=0A>>>>=0A>>=0A>>>>=0A>>=0A>>>>=0A>>Le 2 nov. 2012 =C3=A0 01:5= 8, Joydeep Tripathi a =C3=A9crit :=0A>>>>=0A>>=0A>>>>=0A>>I can understand = that for an LLN it may be beneficial for not maintaining a precursor list o= r having only the destination reply t o a RREQ, there can be (and are) othe= r instances of MANETs where having the option of precursor list will come h= andy. This can save on control overhead, using some storage space in the no= de. LOAD-ng, in most cases does not provide this flexibility to the develop= er to chose between options for specific deployment. Some MANET deployment = may be less harsh than others in nature. Hence, AODVv2 having more open opt= ions than LOAD-ng, in most cases, seem beneficial to me.=0A>>>>>=0A>>=0A>>>= >=0A>>_______________________________________________=0A>>>>=0A>>manet mail= ing list=0A>>>>=0A>>manet@ietf.org=0A>>>>=0A>>https://www.ietf.org/mailman/= listinfo/manet=0A>>>>=0A>>=0A>>>>=0A>>=0A>>>=0A>>-- =0A>>>=0A>>Hitachi, Ltd= ., Yokohama Research Laboratory=0A>>>=0A>>IGARASHI Yuichi=0A>>>=0A>>Mail=EF= =BC=9A yuichi.igarashi.hb@hitachi.com=0A>>>=0A>>Tel =EF=BC=9A +81-(0)45-860= -3083=0A>>>=0A>>FAX =EF=BC=9A +81-(0)45-860-1673=0A>>>=0A>>________________= _______________________________=0A>>>=0A>>manet mailing list=0A>>>=0A>>mane= t@ietf.org=0A>>>=0A>>https://www.ietf.org/mailman/listinfo/manet=0A>>>=0A__= _____________________________________________=0A>>manet mailing list=0A>>ma= net@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/manet=0A>>=0A>=0A>__= _____________________________________________=0A>manet mailing list=0A>mane= t@ietf.org=0A>https://www.ietf.org/mailman/listinfo/manet=0A>=0A>=0A> --1886287700-1595170763-1351957335=:1256 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
What you contend is t= hat a reactive protocol cannot be used in an LLN (Just plain wrong, but tha= t isn't this discussion.  You derailed the discussion bringing it to t= hat.)  But that isn't the issue before the group.

You have no s= ubstantive technical arguments on why we should proceed with DYMO rather th= an LOADng.

it appears you only real objection to the LOADng draft is= the name and that it suggests that it can be used in LLNs.  Your acce= ptance of the DYMO draft is not at all technical. [Your concerns about LOAD= ng used in LLNs apply equally to DYMO, so there is no technical argument be= tween moving forward with DYMO or LOADng].  You accept DYMO because th= e current draft does not indicate that it can be used in an LLN.

You= don't like the name and you don't like that the authors indicated it could be used in some LLN applications (which it can).

I and other = have said that the current state of the draft is that the DYMO draft needs = a lot of major work and things have to cut down to generate a draft that is= implementable.  We have said that the LOADng draft appears to be clos= er to stable, is implementable (there are multiple implementations) but sti= ll needs working group input to complete.

Any discussion of if a rea= ctive protocol could be or should be used in an LLN can be taken to ROLL fo= r now and into the market.

This discussion should be about the diffe= rences in the drafts (which Ulrich has pointed out) and only that so that w= e can find the best starting point.

If you have specific points in t= he differences between the drafts bring them up.

We now know you don= 't like the name and the paragraph about LLNs

Jon

=

From: JP Vasseur (jvasseur) <jvasseur@cisco= .com>
To: Jon Black= <jblack.ietf@yahoo.com>
Cc= : Ulrich Herberg <ulrich@herberg.name>; "manet@ietf.org" &= lt;manet@ietf.org>
Sent: Saturday, November 3, 2012 2:10 AM
Subject: Re: [manet] Reactive Protocol Situation

=0A
=0A=0A =0A=0A
=0AHi "Jon"=0A

=0A=0A
You can keep ignoring what I am writing =E2=80=A6 but this does= not help. The issue is not "this" paragraph - I explained why a number of = times.
=0A
And proposed a way to go, call it option 1.5.
=0A<= div>
=0A
=0A
On Nov 2, 2012, at 4:49 PM, Jon Black wrote:
= =0A
=0A
=0A
=0A
=0A
From: JP Vasseur (jvasseur) <jvasseur@ci= sco.com>
=0A
=0AOn Nov 2, 2012, at 11:08 AM, Ulrich Herberg wr= ote:
=0A
=0A
= =0A
=0A
=0A
=0A
=0A
=0A
I think one key point to stres= s is one that Chris mentioned:
=0ABoth protocols are similar in their op= eration and performance. So anyone arguing against the performance of LOADn= g is automatically also not interested in DYMO.=0A
=0A
=0A
=0A=0A

=0A
=0A
See my point Ulrich =E2=80=A6 and I wrote it down se= veral times. There are major concerns in using Load-ng with LLNs. Quoting L= oad-ng:
=0A

=0A
=0A
=0A
3.  Applicability Statement=0A=0A   This =
protocol:=0A=0A   o  Is a reactive routing protocol for Mobile Ad hoc NETwo=
rks=0A      (MANETs).=0A=0A   o  Is designed to work in networks with dynam=
ic topology in which the=0A      links may be lossy due to collisions or un=
stable channel.  The use=0A      cases include vehicular networks, low powe=
r and lossy networks,=0A      community networks, military networks, disast=
er recovery networks,=0A      etc.=0A
=0A

=0A
=0A
Thi= s is where I strongly object, as several other ones on this mailing list. O= ne cannot simply forget 4-5 years of hard work from a WG that focussed = ;
=0A
on this use case and concluded that such protocol is no= t applicable to LLNs.
=0A
=0A
=0A
=0A[Jon] Is that your tru= e objection to the LOADng draft.  Then I would think the simple soluti= on is to remove this one paragraph and move on. =0A
=0ADevelopers w= ill  decide what protocols are applicable to their application as they= should - as I will.
=0AI will ask in ROLL where the conclusion was draw= n that you cannot possibly use a reactive protocol in any LLN application.&= nbsp; That is for a discussion in ROLL not here.
=0AAgain if this one pa= ragraph is all the fuss then lets please reach consensus to remove this and= move forward.  Gosh that seems simple.
=0A
=0AJon
=0A
= =0A

=0A
=0A
=0A
=0A=

=0A
=0A
= =0A
However, LOADng is far closer to become an RFC in terms of the docu= ment quality. If we start the new reactive protocol on the basis of the LOA= Dng draft (and I personally don't care what we name that protocol is), we c= an continue the work on the reactive=0A protocol together and discuss the m= ultiple options that are currently in DYMO and see whether they should be d= iscarded, put into a companion document or in the core spec.=0A
=0A
= =0ABest
=0AUlrich
=0A
=0AOn Nov 2, 2012, at 7:54, Yuichi IGARASHI = <yuichi.igar= ashi.hb@hitachi.com> wrote:
=0A
=0A
H= i,
=0A
=0A

=0A
=0A<= blockquote type=3D"cite">I agree with Martin and I would support option 2) = at this stage.
=0A
=0A

=0A=0A
We LOADng co-authors made efforts to s= implify core specification of the reactive protocol and to improve the read= ability of the draft. I think this approach is important not only for all i= mplementor to shorten the development time, but=0A also for business operat= ors to make multi-vendor system easier to provide. Of course, I agree that,= as several persons pointed out, "this draft" may limit use case. But we le= ave sufficient space for improving performance/adding functions by companio= n drafts.
=0A
=0A

=0A=0A
I am really concerned about complexity/diff= iculty of guaranteeing of interoperability. If the protocol becomes complic= ated, we need much time(many years?) for interoperability test. I think we = should consider both time required for merging=0A drafts and shape of docum= ent.
=0A
=0A

=0A
= =0A
Best regards,
=0A
=0AYuichi
=0A
=0A
(201= 2/11/02 23:01), Martin Heusse wrote:
=0A
=0A
=0A

=0A
=0A
= =0A
=0A
I'm standing for = option 2 (LOADng).
=0A
=0A
=0A
=0A

=0A
=0A
= =0A
=0A
I think it's bett= er to agree first on a simple basic (versatile?) protocol before proposing = extensions to it; instead of starting from a collection of ideas that can b= e used or not (and we know today what are the options, thank to the=0A huge= amount of work done on reactive routing during the past years). Conversely= , it would be certainly easier to reach a consensus on a set of variants bu= t we need a good reference point, first.
=0A
=0A=0A
=0A

=0A=0A
=0A
=0A
Moreover, reactive routing is most probably the approach that one would = pick for a simple case. So it should be simple...
=0A
=0A=0A
=0A

=0A=
=0A
=0A
=0A
Martin
=0A
=0A
=0A
=0A

=0A
=0A
= =0A
=0A

=0A=0A
=0A
=0A
Le 2 nov. 2012 =C3=A0 01:58, Joydeep Tripathi a =C3=A9crit :
=0A=0A
=0A
=0A

=0A
=0A
=0A
=0A<= blockquote type=3D"cite">=0A
I can understand that= for an LLN it may be beneficial for not maintaining a precursor list or ha= ving only the destination reply t o a RREQ, there can be (and are) other in= stances of MANETs where having the option of precursor list will=0A come ha= ndy. This can save on control overhead, using some storage space in the nod= e. LOAD-ng, in most cases does not provide this flexibility to the develope= r to chose between options for specific deployment. Some MANET deployment m= ay be less harsh than others=0A in nature. Hence, AODVv2 having more open o= ptions than LOAD-ng, in most cases, seem beneficial to me.
=0A=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
____________________________________= ___________
=0A
=0A
=0A
=0A
manet mailing list
=0A
=0A=0A
=0A
manet@ietf.org
=0A
=0A=0A
=0A
= https://www.ietf.org/mailman/listinfo/manet
=0A
=0A=0A
=0A

=0A=0A
=0A

=0A=0A
--
=0A
=0A
Hitachi, Ltd., Yokohama Research Laboratory
=0A
=0AIGARASHI Yuichi
=0A
=0A
Mail=EF=BC=9A =0Ayuichi.igarashi.hb@hitachi.com
=0A
=0ATel =EF=BC=9A +81-(0)45-860-3083
=0A
= =0A
FAX =EF=BC=9A +81-(0)45-860-1673
=0A=0A
________________________________________= _______
=0A
=0A
manet mailing list<= br>=0A
=0A
manet@ietf.org
=0A
=0A
https://www.ietf.org/mailman/listinfo/manet
=0A=0A_______________________________________________
=0Amanet mailing li= st
=0Amanet@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/manet
=0A
=0A=0A
=0A
=0A
=0A
=0A =0A
=0A_______________________= ________________________
=0Amanet mailing list
=0Amanet@ietf.org
=0Ahttps://www.ietf.org/mail= man/listinfo/manet
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A
=0A=0A


--1886287700-1595170763-1351957335=:1256-- From jblack.ietf@yahoo.com Sat Nov 3 08:55:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86DDA21F9BBE for ; Sat, 3 Nov 2012 08:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEkHSZmQ7OxJ for ; Sat, 3 Nov 2012 08:55:11 -0700 (PDT) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id F293121F9C81 for ; Sat, 3 Nov 2012 08:55:10 -0700 (PDT) Received: from [98.139.214.32] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 15:55:07 -0000 Received: from [98.139.212.202] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 15:55:06 -0000 Received: from [127.0.0.1] by omp1011.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 15:55:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 986017.49509.bm@omp1011.mail.bf1.yahoo.com Received: (qmail 94970 invoked by uid 60001); 3 Nov 2012 15:55:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351958106; bh=u3B86nMy580DCBnuKQKg7pvI+swZQbhvCMuP83Kn+to=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qpwHYcB9iTchQ1MQz4uvWUs/3X//OarD3DUSTg0FvK02QjAg16YS8QdVLg5Ia46zwSwNEj6k6lMgtdVXa2XWANxet3y9HbZxf97MPOnWrWfH475zNUhlM3j0AE9GNmQ4nx6vrh9W8tX34i85dFSFGC0mPDE22dI7EUNxrMIGX+o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ozYGSIUXqDVdZ/Jlt16D/uFrF5PQel00tSIQUXt4tIMNQYBK4I6N/IOPvUZ7fKsAbACtM7Zv7+dvSbMbVkcgUVjFe2I+FDBC587ZuZFMR4+qhJ1SAnRWXpypnX7/NZ/Uu9F1JTUI+QfQC4pm54XyuYr9UM8hSPPmQcuflYF9SsI=; X-YMail-OSG: 3zKst.0VM1kDotma2vgwEM7v9732Jz2DVI0DkNBowcRVF7k C_ZyAgoaEFGnVhslBUmS1JQDR5J_r0M53Jq50iF0PB3vKCA3bLBTwGt1dAo9 KyjSiCbaTAv0VJX5chXSTVlfwku3M5JUQvg5CegkHhQSU0PaRznQhXYtWVdb y1cJo8VZ5Vs9SdRWqRldCm1eaA_qowK2u86KRyXLJtYMEDCCT16lEFdV4FPK X2N5I0iBGBbBU9Ov4YD8vQEf9BlGOoEEl_GkIh30PBTYLKs28CLSENrDqMNG FDxGKRKLiNESVn43fjAKIN.TfDPCqckKsDOTtY.p3aVroU6HVU7j_kROkj8m PVKVN8f_4hwfylnRCrcKUPAhev_Dkr0zwvyv4uAA0lhzffQv3HZYq2HPDhtR pIyvwgH6AJxQQANjj9vyTvQpHCz.fL3PJxkucfrfTwf92B3_ts.qBBHmivat 5Bs_4mPE- Received: from [67.213.218.72] by web160602.mail.bf1.yahoo.com via HTTP; Sat, 03 Nov 2012 08:55:06 PDT X-Rocket-MIMEInfo: 001.001, V2hhdCBzbyBub3cgeW91IHdhbnQgdGhlIGRyYWZ0IHRvIGV4cGxpY2l0bHkgc3RhdGUgdGhhdCBpdCBjYW5ub3QgYmUgdXNlZCBpbiBhIExMTj8KClRoaXMgaXMgYmVzaWRlIHRoZSBwb2ludCBvZiBhbnkgdGVjaG5pY2FsIGRpc2N1c3Npb24gcmVsYXRlZCB0byB0aGUgdHdvIGRyYWZ0cy4KClRoaXMgZ3JvdXAgc2hvdWxkIHN0b3AgZ2V0dGluZyBzaWRldHJhY2tlZCAoYW5kIEkgaGF2ZSBiZWVuIGFsc28pIG9uIHRoZSB3cm9uZyB0b3BpYy7CoCBXZSBuZWVkIHRvIGxvb2sgYXQgdGhlIHR3byBkcmFmdHMgYW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C845@xmb-rcd-x02.cisco.com> <1351891402.40332.YahooMailNeo@web160605.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204D692@xmb-rcd-x02.cisco.com> Message-ID: <1351958106.93711.YahooMailNeo@web160602.mail.bf1.yahoo.com> Date: Sat, 3 Nov 2012 08:55:06 -0700 (PDT) From: Jon Black To: "JP Vasseur \(jvasseur\)" In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204D692@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1725615817-87132766-1351958106=:93711" Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 15:55:12 -0000 ---1725615817-87132766-1351958106=:93711 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable What so now you want the draft to explicitly state that it cannot be used i= n a LLN?=0A=0AThis is beside the point of any technical discussion related = to the two drafts.=0A=0AThis group should stop getting sidetracked (and I h= ave been also) on the wrong topic.=C2=A0 We need to look at the two drafts = and determine which is the best to continue to put working group effort beh= ind.=0A=0ACharlie has indicated and is working to improve DYMO.=C2=A0 This = is great.=0A=0AUlrich and others have been making updates to LOADng.=0A=0AT= his WG should read both draft with an eye on which is closer to implementat= ion, stability and has the technical features for a Manet reactive protocol= .=0A=0AThe issue is not about could someone use whatever Manet publishes as= reactive protocol in an LLN.=C2=A0 Lets stop getting distracted from the n= ecessary discussion.=0A=0AI've read both drafts.=C2=A0 I find the LOADng dr= aft more concise, and something I can implement.=C2=A0 I find the DYMO draf= t less understandable, many more options and not in a state that I could tr= y to write code to implement it.=0A=0AI obviously feel strongly that we sho= uld use LOADng as the basis for the reactive protocol from Manet - what eve= r the name eventually is (I don't care) and whatever the eventual applicabi= lity.=0A=0ATo Joe and Stan, I really do think that we are not far from agre= ement (save for few) if we look at the discussion with a filter on just the= technical merits of the two drafts and eliminate the rhetoric around where= people can choose to use the protocol.=0A=0AJon=0A=0A=0A=0A=0A____________= ____________________=0A From: JP Vasseur (jvasseur) =0A= To: Jon Black =0ACc: Ulrich Herberg ; Timothy J. Salo ; "manet@ietf.org" =0ASent: Saturday, November 3, 2012 2:18 AM=0ASubject: Re: [manet] LOADn= g works=0A =0A=0AOnce again you always restart from scratch ignoring emails= - I was providing you the rationale on why you cannot use one =0Adeploymen= t of LLN (not even knowing any details) to claim that the protocol actually= works, this is in reply to Ulrich's email.=0AIf indeed, MANET designs a re= active routing protocol for MANET including LLNs, since it was (finally) sa= id that this=C2=A0could work=C2=A0=0Ain very specific (restrained) conditio= ns, otherwise we would need to use the protocol the IETF has designed for L= LN (RFC6550=C2=A0=0Aand companion)=C2=A0then let's specifically remove LLN = (not implicitly, by removing a section or chaining a name) from the protoco= l=C2=A0=0Adesigned in MANET, and use that protocol (RFC6550)=C2=A0for LLNs.= =0A=0A=0AOn Nov 2, 2012, at 5:23 PM, Jon Black wrote:=0A=0Asee line [Jon]= =0A>=0A>=0A>=0A>=0A>=0A>=0A>________________________________=0A> From: JP V= asseur (jvasseur) =0A>=0A>=0AHi Ulrich, =0A>=0A>=0A>On = Nov 2, 2012, at 1:22 PM, Ulrich Herberg wrote:=0A>=0A>JP,=0A>>=0A>>=0A>>On = Fri, Nov 2, 2012 at 10:09 AM, JP Vasseur (jvasseur) wr= ote:=0A>>=0A>>=0A>>>On Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote:=0A>= >>=0A>>>>>>> JP> This is not just a question of "how large" it is =E2=80=A6= but also how=0A>>>>>>> dynamic. I could show you few hundreds (if not less= number of nodes)=0A>>>>>>> not working if the traffic pattern is too dynam= ic. This is a=0A>>>>>>> fundamental problem.=0A>>>>=0A>>>> No, it is a fund= amental and well-known characteristic of reactive=0A>>>> routing protocols.= =C2=A0It is a problem only when this behavior doesn't=0A>>>> match the cha= racteristics of the network in which the reactive routing=0A>>>> protocol i= s deployed.=0A>>>=0A>>>=0AJP> Indeed =E2=80=A6 and this is why you have a f= undamental issue with you have extremely high BER, PDR,=0A>>>low bandwidth = =E2=80=A6 as we do in LLNs. Flooding in these networks is driven by user tr= affic and of course=0A>>>is highly undesirable. Slightly increase the use t= raffic and you will see the impact on the control plane ...=0A>>>=0A>>=0A>>= =0A>>=0A>>=0A>>Yes, but as Timothy mentioned, there are cases where you don= 't have much user traffic. =0A>=0A>=0A>JP> Then if you recognize that react= ive routing is an issue when user traffic increases, this is a good start.= =0A>When do you put the limit ?=0A>By the way, the topology is another argu= ment, so does the bandwidth.=0A>=0A>=0A>Let me be even more specific:=0A>* = Case 1: 75KBits/s, P2MP traffic (not referring to multicast), small broadca= st domains, meter readout every 24h.=0A>Certainly you can deploy a reactive= routing protocol ? Still I do not see why you would not use a pro-active r= outing=C2=A0=0A>but this is another question=0A>Now what if you move to cas= e 2:=0A>* Unsolicited alarms using meters, DA, EV traffic for bill roaming = ? Well you do not have=0A>a major problem and when designing protocol we ne= ed to take this into account. Please see RFC=0A>=0A>=0A>RFC 5548=C2=A0=0A>(= draft-ietf-roll-urban-routing-reqs) Routing Requirements for Urban Low-Powe= r and Lossy Networks 2009-05 RFC 5548 (Informational) Adrian Farrel =0A>R= FC 5673=C2=A0=0A>(draft-ietf-roll-indus-routing-reqs) Industrial Routing Re= quirements in Low-Power and Lossy Networks 2009-10 RFC 5673 (Informational)= Adrian Farrel =0A>RFC 5826=C2=A0=0A>(draft-ietf-roll-home-routing-reqs) = Home Automation Routing Requirements in Low-Power and Lossy Networks 2010-0= 4 RFC 5826 (Informational)=C2=A0=0A>Errata Adrian Farrel =0A>RFC 5867=C2= =A0=0A>(draft-ietf-roll-building-routing-reqs) Building Automation Routing = Requirements in Low-Power and Lossy Networks 2010-06 RFC 5867 (Informationa= l)=0A>=0A> =0A>=0A>[Jon] Which RFC?=C2=A0 Do you mean RFC 5826 or 5867 both= of which seem to need RPL P2P which looks like a new protocol?=C2=A0 Do yo= u mean RFC 5548 which seems to be the use case from EDF that is using a rea= ctive protocol (LOADng), or RFC5673 which no one has tried.=0A>=0A>Just bec= ause something was designed to do something you can't claim that it actuall= y will do it.=C2=A0 The Titanic was designed to be unsinkable...=C2=A0 But = I digress, since you did.=0A>=0A>It does appear that your objection is the = name ('cause it could confuse someone into think they could use this manet = protocol in an LLN - which as you said was their choice) and that there is = one small paragraph there it says that they might be able to use=0A this pr= otocol in their LLN.=0A>=0A>Really, this is what all the hub-bub is about.= =C2=A0 After all they really are both AODV++.=C2=A0 So we find a new name a= nd remove one paragraph.=0A>=0A>I think now the debate is what is the prope= r base from which to start.=C2=A0 Which document is clearer, and more stabl= e.=0A>=0A>Jon=0A>=0A>=0A>=0A>=0A>=0A> ---1725615817-87132766-1351958106=:93711 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
What so now you want = the draft to explicitly state that it cannot be used in a LLN?

This = is beside the point of any technical discussion related to the two drafts.<= br>
This group should stop getting sidetracked (and I have been also) on= the wrong topic.  We need to look at the two drafts and determine whi= ch is the best to continue to put working group effort behind.

Charl= ie has indicated and is working to improve DYMO.  This is great.
Ulrich and others have been making updates to LOADng.

This WG shou= ld read both draft with an eye on which is closer to implementation, stabil= ity and has the technical features for a Manet reactive protocol.

Th= e issue is not about could someone use whatever Manet publishes as reactive= protocol in an LLN.  Lets stop getting distracted from the necessary discussion.

I've read both drafts.  I find the LOADn= g draft more concise, and something I can implement.  I find the DYMO = draft less understandable, many more options and not in a state that I coul= d try to write code to implement it.

I obviously feel strongly that = we should use LOADng as the basis for the reactive protocol from Manet - wh= at ever the name eventually is (I don't care) and whatever the eventual app= licability.

To Joe and Stan, I really do think that we are not far f= rom agreement (save for few) if we look at the discussion with a filter on = just the technical merits of the two drafts and eliminate the rhetoric arou= nd where people can choose to use the protocol.

Jon

From: JP Vasseur (jvasseur) <jvasseur@cisco.com&= gt;
To: Jon Black <= jblack.ietf@yahoo.com>
Cc: Ulrich Herberg <ulrich@herberg.name>; Timothy J. Salo <sal= o@saloits.com>; "manet@ietf.org" <manet@ietf.org>
Sent: Saturday, November 3, 2012 2:18= AM
Subject: Re: [mane= t] LOADng works

=0A
=0A=0A =0A=0A
=0AO= nce again you always restart from scratch ignoring emails - I was providing= you the rationale on why you cannot use one=0A
deployment of LLN (not = even knowing any details) to claim that the protocol actually works, this i= s in reply to Ulrich's email.
=0A
If indeed, MANET designs a react= ive routing protocol for MANET including LLNs, since it was (finally) said = that this could work 
=0A
in very specific (restrained) = conditions, otherwise we would need to use the protocol the IETF has design= ed for LLN (RFC6550 
=0A
and companion) then let's speci= fically remove LLN (not implicitly, by removing a section or chaining a nam= e) from the protocol 
=0A
designed in MANET, and use that pro= tocol (RFC6550) for LLNs.
=0A

=0A
=0A
On Nov 2, 2= 012, at 5:23 PM, Jon Black wrote:
=0A
=0A
=0A
=0A
=0Asee line [Jon]
=0A

=0A=
=0A

=0A
=0A
=0A
=0A
=0A
=0AFrom: JP Vasseur (jvasseur) <jvasseur@cisco.com>
=0A
=0A
=0AHi Ulrich,=0A
=0A

=0A=0A
JP> Then if you recognize that reactive routing is an issue whe= n user traffic increases, this is a good start.
=0A
When do you pu= t the limit ?
=0A
By the way, the topology is another argument, so= does the bandwidth.
=0A

=0A
=0A
Let me be even more = specific:
=0A
* Case 1: 75KBits/s, P2MP traffic (not referring to = multicast), small broadcast domains, meter readout every 24h.
=0A
= Certainly you can deploy a reactive routing protocol ? Still I do not see w= hy you would not use a pro-active routing 
=0A
but this is an= other question
=0A
Now what if you move to case 2:
=0A
* = Unsolicited alarms using meters, DA, EV traffic for bill roaming ? Well you= do not have
=0A
a major problem and when designing protocol we ne= ed to take this into account. Please see RFC
=0A
=0A
=0A
=0A= =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A
=0ARFC 5548 
=0A(draft-ietf-roll-urb= an-routing-reqs)		= =0ARouting Requirements for Urban Low-Power and Lossy Networks=0A2009-05=0ARFC 5548 (Informational)=0A=0A=0AAdrian Farrel
=0ARFC 5673 
=0A= (draft-ietf-roll-indus-routing-reqs= )		=0AIndustrial Rou= ting Requirements in Low-Power and Lossy Networks=0A2009-10=0ARFC 5673 (Informational)=0A=0A=0AAdrian Farrel
=0ARFC 5826 
=0A= (draft-ietf-roll-home-routing-reqs)		=0AHome Automation = Routing Requirements in Low-Power and Lossy Networks=0A2010-04=0ARFC 5826 (Informational) 
=0AEr= rata		=0A= =0A=0A= =0ARFC 5867 
=0A(draft-ietf-roll-building-routing-reqs)		=0ABuilding Automation Routing Requirements i= n Low-Power and Lossy Networks=0A2010-06=0ARFC 5867 (Inf= ormational)
=0A
=0A
=0A
=0A
=0A[Jon] Which RFC?  Do you mean RFC 5826 or 5867 both of which = seem to need RPL P2P which looks like a new protocol?  Do you mean RFC= 5548 which seems to be the use case from EDF that is using a reactive prot= ocol (LOADng), or RFC5673 which no one has tried.
=0A
=0AJust because= something was designed to do something you can't claim that it actually wi= ll do it.  The Titanic was designed to be unsinkable...  But I di= gress, since you did.
=0A
=0AIt does appear that your objection is th= e name ('cause it could confuse someone into think they could use this mane= t protocol in an LLN - which as you said was their choice) and that there i= s one small paragraph there it says that they might be able to use=0A this = protocol in their LLN.
=0A
=0AReally, this is what all the hub-bub is= about.  After all they really are both AODV++.  So we find a new= name and remove one paragraph.
=0A
=0AI think now the debate is what= is the proper base from which to start.  Which document is clearer, a= nd more stable.
=0A
=0AJon
=0A

=0A
=0A
=0A
= =0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A=0A
=0A
=0A
=0A
=0A=0A


---1725615817-87132766-1351958106=:93711-- From jvasseur@cisco.com Sat Nov 3 08:57:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715BA21F9C89 for ; Sat, 3 Nov 2012 08:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.228 X-Spam-Level: X-Spam-Status: No, score=-10.228 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoMz-zmRRycJ for ; Sat, 3 Nov 2012 08:57:38 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B0E7E21F9C74 for ; Sat, 3 Nov 2012 08:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31498; q=dns/txt; s=iport; t=1351958258; x=1353167858; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=L3rKtJwtse/0vFTp6eK0j1UYKC+qwHG5XANbfVLRA2s=; b=k1DfYNcxrXn/4QxBRCqLNNDyWQL0bG4jj+FcdtU5SovqfU4DoSjyUh+T Wc7oA5vX6WuNaD4oHRWXcAXiTWZbYUwsj0Hf8Q+b3/wkT4muprTNRTOrd C7ZSaIydIsUzJLXEejfoYlET+niJZgzKmOgJDeBhndxZ/Ips2MEK477TD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAGY9lVCtJV2c/2dsb2JhbABEgkmDTqp1kS57gQiCHgEBAQQBAQEPARBLBgUQAgEIDgMEAQELHQMCAgIlCxMBCQgCBA4FCAwHB4dWAw8LmWONKJIqixloCgsFAQWFCTJhA5Qqgm2KF4MmgWuCb4FcCBce X-IronPort-AV: E=Sophos;i="4.80,705,1344211200"; d="scan'208,217";a="138460253" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 03 Nov 2012 15:57:37 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA3Fvbbe022625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 15:57:37 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 10:57:35 -0500 From: "JP Vasseur (jvasseur)" To: Jon Black Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuRrYLPVi/cSo/ES1hdb7zda62w== Date: Sat, 3 Nov 2012 15:57:34 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204E594@xmb-rcd-x02.cisco.com> References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <1351889394.5207.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204D666@xmb-rcd-x02.cisco.com> <1351957335.1256.YahooMailNeo@web160603.mail.bf1.yahoo.com> In-Reply-To: <1351957335.1256.YahooMailNeo@web160603.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.229] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--44.876100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204E594xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 15:57:39 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204E594xmbrcdx02ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGV0J3MgZm9sbG93IHRoZSBkaXJlY3Rpb25zIHN0YXRlZCBieSBKb2UuIFN0b3AgdGhlIHBvbGVt aWNzLiBIb3BpbmcgdG8gU0VFIHlvdSBmb3IgYSB0ZWNobmljYWwgZGlzY3Vzc2lvbi4NCg0KT24g Tm92IDMsIDIwMTIsIGF0IDExOjQyIEFNLCBKb24gQmxhY2sgd3JvdGU6DQoNCldoYXQgeW91IGNv bnRlbmQgaXMgdGhhdCBhIHJlYWN0aXZlIHByb3RvY29sIGNhbm5vdCBiZSB1c2VkIGluIGFuIExM TiAoSnVzdCBwbGFpbiB3cm9uZywgYnV0IHRoYXQgaXNuJ3QgdGhpcyBkaXNjdXNzaW9uLiAgWW91 IGRlcmFpbGVkIHRoZSBkaXNjdXNzaW9uIGJyaW5naW5nIGl0IHRvIHRoYXQuKSAgQnV0IHRoYXQg aXNuJ3QgdGhlIGlzc3VlIGJlZm9yZSB0aGUgZ3JvdXAuDQoNCllvdSBoYXZlIG5vIHN1YnN0YW50 aXZlIHRlY2huaWNhbCBhcmd1bWVudHMgb24gd2h5IHdlIHNob3VsZCBwcm9jZWVkIHdpdGggRFlN TyByYXRoZXIgdGhhbiBMT0FEbmcuDQoNCml0IGFwcGVhcnMgeW91IG9ubHkgcmVhbCBvYmplY3Rp b24gdG8gdGhlIExPQURuZyBkcmFmdCBpcyB0aGUgbmFtZSBhbmQgdGhhdCBpdCBzdWdnZXN0cyB0 aGF0IGl0IGNhbiBiZSB1c2VkIGluIExMTnMuICBZb3VyIGFjY2VwdGFuY2Ugb2YgdGhlIERZTU8g ZHJhZnQgaXMgbm90IGF0IGFsbCB0ZWNobmljYWwuIFtZb3VyIGNvbmNlcm5zIGFib3V0IExPQURu ZyB1c2VkIGluIExMTnMgYXBwbHkgZXF1YWxseSB0byBEWU1PLCBzbyB0aGVyZSBpcyBubyB0ZWNo bmljYWwgYXJndW1lbnQgYmV0d2VlbiBtb3ZpbmcgZm9yd2FyZCB3aXRoIERZTU8gb3IgTE9BRG5n XS4gIFlvdSBhY2NlcHQgRFlNTyBiZWNhdXNlIHRoZSBjdXJyZW50IGRyYWZ0IGRvZXMgbm90IGlu ZGljYXRlIHRoYXQgaXQgY2FuIGJlIHVzZWQgaW4gYW4gTExOLg0KDQpZb3UgZG9uJ3QgbGlrZSB0 aGUgbmFtZSBhbmQgeW91IGRvbid0IGxpa2UgdGhhdCB0aGUgYXV0aG9ycyBpbmRpY2F0ZWQgaXQg Y291bGQgYmUgdXNlZCBpbiBzb21lIExMTiBhcHBsaWNhdGlvbnMgKHdoaWNoIGl0IGNhbikuDQoN CkkgYW5kIG90aGVyIGhhdmUgc2FpZCB0aGF0IHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoZSBkcmFm dCBpcyB0aGF0IHRoZSBEWU1PIGRyYWZ0IG5lZWRzIGEgbG90IG9mIG1ham9yIHdvcmsgYW5kIHRo aW5ncyBoYXZlIHRvIGN1dCBkb3duIHRvIGdlbmVyYXRlIGEgZHJhZnQgdGhhdCBpcyBpbXBsZW1l bnRhYmxlLiAgV2UgaGF2ZSBzYWlkIHRoYXQgdGhlIExPQURuZyBkcmFmdCBhcHBlYXJzIHRvIGJl IGNsb3NlciB0byBzdGFibGUsIGlzIGltcGxlbWVudGFibGUgKHRoZXJlIGFyZSBtdWx0aXBsZSBp bXBsZW1lbnRhdGlvbnMpIGJ1dCBzdGlsbCBuZWVkcyB3b3JraW5nIGdyb3VwIGlucHV0IHRvIGNv bXBsZXRlLg0KDQpBbnkgZGlzY3Vzc2lvbiBvZiBpZiBhIHJlYWN0aXZlIHByb3RvY29sIGNvdWxk IGJlIG9yIHNob3VsZCBiZSB1c2VkIGluIGFuIExMTiBjYW4gYmUgdGFrZW4gdG8gUk9MTCBmb3Ig bm93IGFuZCBpbnRvIHRoZSBtYXJrZXQuDQoNClRoaXMgZGlzY3Vzc2lvbiBzaG91bGQgYmUgYWJv dXQgdGhlIGRpZmZlcmVuY2VzIGluIHRoZSBkcmFmdHMgKHdoaWNoIFVscmljaCBoYXMgcG9pbnRl ZCBvdXQpIGFuZCBvbmx5IHRoYXQgc28gdGhhdCB3ZSBjYW4gZmluZCB0aGUgYmVzdCBzdGFydGlu ZyBwb2ludC4NCg0KSWYgeW91IGhhdmUgc3BlY2lmaWMgcG9pbnRzIGluIHRoZSBkaWZmZXJlbmNl cyBiZXR3ZWVuIHRoZSBkcmFmdHMgYnJpbmcgdGhlbSB1cC4NCg0KV2Ugbm93IGtub3cgeW91IGRv bid0IGxpa2UgdGhlIG5hbWUgYW5kIHRoZSBwYXJhZ3JhcGggYWJvdXQgTExOcw0KDQpKb24NCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogSlAgVmFzc2V1ciAoanZh c3NldXIpIDxqdmFzc2V1ckBjaXNjby5jb208bWFpbHRvOmp2YXNzZXVyQGNpc2NvLmNvbT4+DQpU bzogSm9uIEJsYWNrIDxqYmxhY2suaWV0ZkB5YWhvby5jb208bWFpbHRvOmpibGFjay5pZXRmQHlh aG9vLmNvbT4+DQpDYzogVWxyaWNoIEhlcmJlcmcgPHVscmljaEBoZXJiZXJnLm5hbWU8bWFpbHRv OnVscmljaEBoZXJiZXJnLm5hbWU+PjsgIm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRm Lm9yZz4iIDxtYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+Pg0KU2VudDogU2F0 dXJkYXksIE5vdmVtYmVyIDMsIDIwMTIgMjoxMCBBTQ0KU3ViamVjdDogUmU6IFttYW5ldF0gUmVh Y3RpdmUgUHJvdG9jb2wgU2l0dWF0aW9uDQoNCkhpICJKb24iDQoNCllvdSBjYW4ga2VlcCBpZ25v cmluZyB3aGF0IEkgYW0gd3JpdGluZyDigKYgYnV0IHRoaXMgZG9lcyBub3QgaGVscC4gVGhlIGlz c3VlIGlzIG5vdCAidGhpcyIgcGFyYWdyYXBoIC0gSSBleHBsYWluZWQgd2h5IGEgbnVtYmVyIG9m IHRpbWVzLg0KQW5kIHByb3Bvc2VkIGEgd2F5IHRvIGdvLCBjYWxsIGl0IG9wdGlvbiAxLjUuDQoN Ck9uIE5vdiAyLCAyMDEyLCBhdCA0OjQ5IFBNLCBKb24gQmxhY2sgd3JvdGU6DQoNCkZyb206IEpQ IFZhc3NldXIgKGp2YXNzZXVyKSA8anZhc3NldXJAY2lzY28uY29tPG1haWx0bzpqdmFzc2V1ckBj aXNjby5jb20+Pg0KDQpPbiBOb3YgMiwgMjAxMiwgYXQgMTE6MDggQU0sIFVscmljaCBIZXJiZXJn IHdyb3RlOg0KSSB0aGluayBvbmUga2V5IHBvaW50IHRvIHN0cmVzcyBpcyBvbmUgdGhhdCBDaHJp cyBtZW50aW9uZWQ6DQpCb3RoIHByb3RvY29scyBhcmUgc2ltaWxhciBpbiB0aGVpciBvcGVyYXRp b24gYW5kIHBlcmZvcm1hbmNlLiBTbyBhbnlvbmUgYXJndWluZyBhZ2FpbnN0IHRoZSBwZXJmb3Jt YW5jZSBvZiBMT0FEbmcgaXMgYXV0b21hdGljYWxseSBhbHNvIG5vdCBpbnRlcmVzdGVkIGluIERZ TU8uDQoNCg0KU2VlIG15IHBvaW50IFVscmljaCDigKYgYW5kIEkgd3JvdGUgaXQgZG93biBzZXZl cmFsIHRpbWVzLiBUaGVyZSBhcmUgbWFqb3IgY29uY2VybnMgaW4gdXNpbmcgTG9hZC1uZyB3aXRo IExMTnMuIFF1b3RpbmcgTG9hZC1uZzoNCg0KDQozPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWNsYXVzZW4tbGxuLWxvYWRuZy0wNiNzZWN0aW9uLTM+LiAgQXBwbGljYWJpbGl0eSBT dGF0ZW1lbnQNCg0KDQogICBUaGlzIHByb3RvY29sOg0KDQogICBvICBJcyBhIHJlYWN0aXZlIHJv dXRpbmcgcHJvdG9jb2wgZm9yIE1vYmlsZSBBZCBob2MgTkVUd29ya3MNCiAgICAgIChNQU5FVHMp Lg0KDQogICBvICBJcyBkZXNpZ25lZCB0byB3b3JrIGluIG5ldHdvcmtzIHdpdGggZHluYW1pYyB0 b3BvbG9neSBpbiB3aGljaCB0aGUNCiAgICAgIGxpbmtzIG1heSBiZSBsb3NzeSBkdWUgdG8gY29s bGlzaW9ucyBvciB1bnN0YWJsZSBjaGFubmVsLiAgVGhlIHVzZQ0KICAgICAgY2FzZXMgaW5jbHVk ZSB2ZWhpY3VsYXIgbmV0d29ya3MsIGxvdyBwb3dlciBhbmQgbG9zc3kgbmV0d29ya3MsDQogICAg ICBjb21tdW5pdHkgbmV0d29ya3MsIG1pbGl0YXJ5IG5ldHdvcmtzLCBkaXNhc3RlciByZWNvdmVy eSBuZXR3b3JrcywNCiAgICAgIGV0Yy4NCg0KDQpUaGlzIGlzIHdoZXJlIEkgc3Ryb25nbHkgb2Jq ZWN0LCBhcyBzZXZlcmFsIG90aGVyIG9uZXMgb24gdGhpcyBtYWlsaW5nIGxpc3QuIE9uZSBjYW5u b3Qgc2ltcGx5IGZvcmdldCA0LTUgeWVhcnMgb2YgaGFyZCB3b3JrIGZyb20gYSBXRyB0aGF0IGZv Y3Vzc2VkDQpvbiB0aGlzIHVzZSBjYXNlIGFuZCBjb25jbHVkZWQgdGhhdCBzdWNoIHByb3RvY29s IGlzIG5vdCBhcHBsaWNhYmxlIHRvIExMTnMuDQoNCltKb25dIElzIHRoYXQgeW91ciB0cnVlIG9i amVjdGlvbiB0byB0aGUgTE9BRG5nIGRyYWZ0LiAgVGhlbiBJIHdvdWxkIHRoaW5rIHRoZSBzaW1w bGUgc29sdXRpb24gaXMgdG8gcmVtb3ZlIHRoaXMgb25lIHBhcmFncmFwaCBhbmQgbW92ZSBvbi4N CkRldmVsb3BlcnMgd2lsbCAgZGVjaWRlIHdoYXQgcHJvdG9jb2xzIGFyZSBhcHBsaWNhYmxlIHRv IHRoZWlyIGFwcGxpY2F0aW9uIGFzIHRoZXkgc2hvdWxkIC0gYXMgSSB3aWxsLg0KSSB3aWxsIGFz ayBpbiBST0xMIHdoZXJlIHRoZSBjb25jbHVzaW9uIHdhcyBkcmF3biB0aGF0IHlvdSBjYW5ub3Qg cG9zc2libHkgdXNlIGEgcmVhY3RpdmUgcHJvdG9jb2wgaW4gYW55IExMTiBhcHBsaWNhdGlvbi4g IFRoYXQgaXMgZm9yIGEgZGlzY3Vzc2lvbiBpbiBST0xMIG5vdCBoZXJlLg0KQWdhaW4gaWYgdGhp cyBvbmUgcGFyYWdyYXBoIGlzIGFsbCB0aGUgZnVzcyB0aGVuIGxldHMgcGxlYXNlIHJlYWNoIGNv bnNlbnN1cyB0byByZW1vdmUgdGhpcyBhbmQgbW92ZSBmb3J3YXJkLiAgR29zaCB0aGF0IHNlZW1z IHNpbXBsZS4NCg0KSm9uDQoNCg0KSG93ZXZlciwgTE9BRG5nIGlzIGZhciBjbG9zZXIgdG8gYmVj b21lIGFuIFJGQyBpbiB0ZXJtcyBvZiB0aGUgZG9jdW1lbnQgcXVhbGl0eS4gSWYgd2Ugc3RhcnQg dGhlIG5ldyByZWFjdGl2ZSBwcm90b2NvbCBvbiB0aGUgYmFzaXMgb2YgdGhlIExPQURuZyBkcmFm dCAoYW5kIEkgcGVyc29uYWxseSBkb24ndCBjYXJlIHdoYXQgd2UgbmFtZSB0aGF0IHByb3RvY29s IGlzKSwgd2UgY2FuIGNvbnRpbnVlIHRoZSB3b3JrIG9uIHRoZSByZWFjdGl2ZSBwcm90b2NvbCB0 b2dldGhlciBhbmQgZGlzY3VzcyB0aGUgbXVsdGlwbGUgb3B0aW9ucyB0aGF0IGFyZSBjdXJyZW50 bHkgaW4gRFlNTyBhbmQgc2VlIHdoZXRoZXIgdGhleSBzaG91bGQgYmUgZGlzY2FyZGVkLCBwdXQg aW50byBhIGNvbXBhbmlvbiBkb2N1bWVudCBvciBpbiB0aGUgY29yZSBzcGVjLg0KDQpCZXN0DQpV bHJpY2gNCg0KT24gTm92IDIsIDIwMTIsIGF0IDc6NTQsIFl1aWNoaSBJR0FSQVNISSA8eXVpY2hp LmlnYXJhc2hpLmhiQGhpdGFjaGkuY29tPG1haWx0bzp5dWljaGkuaWdhcmFzaGkuaGJAaGl0YWNo aS5jb20+PiB3cm90ZToNCg0KSGksDQoNCkkgYWdyZWUgd2l0aCBNYXJ0aW4gYW5kIEkgd291bGQg c3VwcG9ydCBvcHRpb24gMikgYXQgdGhpcyBzdGFnZS4NCg0KV2UgTE9BRG5nIGNvLWF1dGhvcnMg bWFkZSBlZmZvcnRzIHRvIHNpbXBsaWZ5IGNvcmUgc3BlY2lmaWNhdGlvbiBvZiB0aGUgcmVhY3Rp dmUgcHJvdG9jb2wgYW5kIHRvIGltcHJvdmUgdGhlIHJlYWRhYmlsaXR5IG9mIHRoZSBkcmFmdC4g SSB0aGluayB0aGlzIGFwcHJvYWNoIGlzIGltcG9ydGFudCBub3Qgb25seSBmb3IgYWxsIGltcGxl bWVudG9yIHRvIHNob3J0ZW4gdGhlIGRldmVsb3BtZW50IHRpbWUsIGJ1dCBhbHNvIGZvciBidXNp bmVzcyBvcGVyYXRvcnMgdG8gbWFrZSBtdWx0aS12ZW5kb3Igc3lzdGVtIGVhc2llciB0byBwcm92 aWRlLiBPZiBjb3Vyc2UsIEkgYWdyZWUgdGhhdCwgYXMgc2V2ZXJhbCBwZXJzb25zIHBvaW50ZWQg b3V0LCAidGhpcyBkcmFmdCIgbWF5IGxpbWl0IHVzZSBjYXNlLiBCdXQgd2UgbGVhdmUgc3VmZmlj aWVudCBzcGFjZSBmb3IgaW1wcm92aW5nIHBlcmZvcm1hbmNlL2FkZGluZyBmdW5jdGlvbnMgYnkg Y29tcGFuaW9uIGRyYWZ0cy4NCg0KSSBhbSByZWFsbHkgY29uY2VybmVkIGFib3V0IGNvbXBsZXhp dHkvZGlmZmljdWx0eSBvZiBndWFyYW50ZWVpbmcgb2YgaW50ZXJvcGVyYWJpbGl0eS4gSWYgdGhl IHByb3RvY29sIGJlY29tZXMgY29tcGxpY2F0ZWQsIHdlIG5lZWQgbXVjaCB0aW1lKG1hbnkgeWVh cnM/KSBmb3IgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0LiBJIHRoaW5rIHdlIHNob3VsZCBjb25zaWRl ciBib3RoIHRpbWUgcmVxdWlyZWQgZm9yIG1lcmdpbmcgZHJhZnRzIGFuZCBzaGFwZSBvZiBkb2N1 bWVudC4NCg0KQmVzdCByZWdhcmRzLA0KWXVpY2hpDQooMjAxMi8xMS8wMiAyMzowMSksIE1hcnRp biBIZXVzc2Ugd3JvdGU6DQoNCkknbSBzdGFuZGluZyBmb3Igb3B0aW9uIDIgKExPQURuZykuDQoN CkkgdGhpbmsgaXQncyBiZXR0ZXIgdG8gYWdyZWUgZmlyc3Qgb24gYSBzaW1wbGUgYmFzaWMgKHZl cnNhdGlsZT8pIHByb3RvY29sIGJlZm9yZSBwcm9wb3NpbmcgZXh0ZW5zaW9ucyB0byBpdDsgaW5z dGVhZCBvZiBzdGFydGluZyBmcm9tIGEgY29sbGVjdGlvbiBvZiBpZGVhcyB0aGF0IGNhbiBiZSB1 c2VkIG9yIG5vdCAoYW5kIHdlIGtub3cgdG9kYXkgd2hhdCBhcmUgdGhlIG9wdGlvbnMsIHRoYW5r IHRvIHRoZSBodWdlIGFtb3VudCBvZiB3b3JrIGRvbmUgb24gcmVhY3RpdmUgcm91dGluZyBkdXJp bmcgdGhlIHBhc3QgeWVhcnMpLiBDb252ZXJzZWx5LCBpdCB3b3VsZCBiZSBjZXJ0YWlubHkgZWFz aWVyIHRvIHJlYWNoIGEgY29uc2Vuc3VzIG9uIGEgc2V0IG9mIHZhcmlhbnRzIGJ1dCB3ZSBuZWVk IGEgZ29vZCByZWZlcmVuY2UgcG9pbnQsIGZpcnN0Lg0KDQpNb3Jlb3ZlciwgcmVhY3RpdmUgcm91 dGluZyBpcyBtb3N0IHByb2JhYmx5IHRoZSBhcHByb2FjaCB0aGF0IG9uZSB3b3VsZCBwaWNrIGZv ciBhIHNpbXBsZSBjYXNlLiBTbyBpdCBzaG91bGQgYmUgc2ltcGxlLi4uDQoNCk1hcnRpbg0KDQoN CkxlIDIgbm92LiAyMDEyIMOgIDAxOjU4LCBKb3lkZWVwIFRyaXBhdGhpIGEgw6ljcml0IDoNCg0K SSBjYW4gdW5kZXJzdGFuZCB0aGF0IGZvciBhbiBMTE4gaXQgbWF5IGJlIGJlbmVmaWNpYWwgZm9y IG5vdCBtYWludGFpbmluZyBhIHByZWN1cnNvciBsaXN0IG9yIGhhdmluZyBvbmx5IHRoZSBkZXN0 aW5hdGlvbiByZXBseSB0IG8gYSBSUkVRLCB0aGVyZSBjYW4gYmUgKGFuZCBhcmUpIG90aGVyIGlu c3RhbmNlcyBvZiBNQU5FVHMgd2hlcmUgaGF2aW5nIHRoZSBvcHRpb24gb2YgcHJlY3Vyc29yIGxp c3Qgd2lsbCBjb21lIGhhbmR5LiBUaGlzIGNhbiBzYXZlIG9uIGNvbnRyb2wgb3ZlcmhlYWQsIHVz aW5nIHNvbWUgc3RvcmFnZSBzcGFjZSBpbiB0aGUgbm9kZS4gTE9BRC1uZywgaW4gbW9zdCBjYXNl cyBkb2VzIG5vdCBwcm92aWRlIHRoaXMgZmxleGliaWxpdHkgdG8gdGhlIGRldmVsb3BlciB0byBj aG9zZSBiZXR3ZWVuIG9wdGlvbnMgZm9yIHNwZWNpZmljIGRlcGxveW1lbnQuIFNvbWUgTUFORVQg ZGVwbG95bWVudCBtYXkgYmUgbGVzcyBoYXJzaCB0aGFuIG90aGVycyBpbiBuYXR1cmUuIEhlbmNl LCBBT0RWdjIgaGF2aW5nIG1vcmUgb3BlbiBvcHRpb25zIHRoYW4gTE9BRC1uZywgaW4gbW9zdCBj YXNlcywgc2VlbSBiZW5lZmljaWFsIHRvIG1lLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9y ZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21hbmV0DQoNCg0KLS0NCkhpdGFjaGksIEx0ZC4sIFlva29oYW1hIFJlc2VhcmNoIExh Ym9yYXRvcnkNCklHQVJBU0hJIFl1aWNoaQ0KTWFpbO+8miB5dWljaGkuaWdhcmFzaGkuaGJAaGl0 YWNoaS5jb208bWFpbHRvOnl1aWNoaS5pZ2FyYXNoaS5oYkBoaXRhY2hpLmNvbT4NClRlbCDvvJog KzgxLSgwKTQ1LTg2MC0zMDgzDQpGQVgg77yaICs4MS0oMCk0NS04NjAtMTY3Mw0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlz dA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8 bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tYW5ldA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0K DQoNCg0KDQoNCg== --_000_03B78081B371D44390ED6E7BADBB4A772204E594xmbrcdx02ciscoc_ Content-Type: text/html; charset="utf-8" Content-ID: <66109A4001335946BB4AD0FFEBCD3C65@cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCkxldCdzIGZvbGxvdyB0aGUgZGlyZWN0aW9ucyBz dGF0ZWQgYnkgSm9lLiBTdG9wIHRoZSBwb2xlbWljcy4gSG9waW5nIHRvIFNFRSB5b3UgZm9yIGEg dGVjaG5pY2FsIGRpc2N1c3Npb24uDQo8ZGl2Pjxicj4NCjxkaXY+DQo8ZGl2Pk9uIE5vdiAzLCAy MDEyLCBhdCAxMTo0MiBBTSwgSm9uIEJsYWNrIHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBs ZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImNvbG9yOiMwMDA7IGJhY2tncm91bmQtY29sb3I6I2ZmZjsgZm9udC1mYW1p bHk6dGltZXMgbmV3IHJvbWFuLCBuZXcgeW9yaywgdGltZXMsIHNlcmlmO2ZvbnQtc2l6ZToxMnB0 Ij4NCldoYXQgeW91IGNvbnRlbmQgaXMgdGhhdCBhIHJlYWN0aXZlIHByb3RvY29sIGNhbm5vdCBi ZSB1c2VkIGluIGFuIExMTiAoSnVzdCBwbGFpbiB3cm9uZywgYnV0IHRoYXQgaXNuJ3QgdGhpcyBk aXNjdXNzaW9uLiZuYnNwOyBZb3UgZGVyYWlsZWQgdGhlIGRpc2N1c3Npb24gYnJpbmdpbmcgaXQg dG8gdGhhdC4pJm5ic3A7IEJ1dCB0aGF0IGlzbid0IHRoZSBpc3N1ZSBiZWZvcmUgdGhlIGdyb3Vw Ljxicj4NCjxicj4NCllvdSBoYXZlIG5vIHN1YnN0YW50aXZlIHRlY2huaWNhbCBhcmd1bWVudHMg b24gd2h5IHdlIHNob3VsZCBwcm9jZWVkIHdpdGggRFlNTyByYXRoZXIgdGhhbiBMT0FEbmcuPGJy Pg0KPGJyPg0KaXQgYXBwZWFycyB5b3Ugb25seSByZWFsIG9iamVjdGlvbiB0byB0aGUgTE9BRG5n IGRyYWZ0IGlzIHRoZSBuYW1lIGFuZCB0aGF0IGl0IHN1Z2dlc3RzIHRoYXQgaXQgY2FuIGJlIHVz ZWQgaW4gTExOcy4mbmJzcDsgWW91ciBhY2NlcHRhbmNlIG9mIHRoZSBEWU1PIGRyYWZ0IGlzIG5v dCBhdCBhbGwgdGVjaG5pY2FsLiBbWW91ciBjb25jZXJucyBhYm91dCBMT0FEbmcgdXNlZCBpbiBM TE5zIGFwcGx5IGVxdWFsbHkgdG8gRFlNTywgc28gdGhlcmUgaXMgbm8gdGVjaG5pY2FsDQogYXJn dW1lbnQgYmV0d2VlbiBtb3ZpbmcgZm9yd2FyZCB3aXRoIERZTU8gb3IgTE9BRG5nXS4mbmJzcDsg WW91IGFjY2VwdCBEWU1PIGJlY2F1c2UgdGhlIGN1cnJlbnQgZHJhZnQgZG9lcyBub3QgaW5kaWNh dGUgdGhhdCBpdCBjYW4gYmUgdXNlZCBpbiBhbiBMTE4uPGJyPg0KPGJyPg0KWW91IGRvbid0IGxp a2UgdGhlIG5hbWUgYW5kIHlvdSBkb24ndCBsaWtlIHRoYXQgdGhlIGF1dGhvcnMgaW5kaWNhdGVk IGl0IGNvdWxkIGJlIHVzZWQgaW4gc29tZSBMTE4gYXBwbGljYXRpb25zICh3aGljaCBpdCBjYW4p Ljxicj4NCjxicj4NCkkgYW5kIG90aGVyIGhhdmUgc2FpZCB0aGF0IHRoZSBjdXJyZW50IHN0YXRl IG9mIHRoZSBkcmFmdCBpcyB0aGF0IHRoZSBEWU1PIGRyYWZ0IG5lZWRzIGEgbG90IG9mIG1ham9y IHdvcmsgYW5kIHRoaW5ncyBoYXZlIHRvIGN1dCBkb3duIHRvIGdlbmVyYXRlIGEgZHJhZnQgdGhh dCBpcyBpbXBsZW1lbnRhYmxlLiZuYnNwOyBXZSBoYXZlIHNhaWQgdGhhdCB0aGUgTE9BRG5nIGRy YWZ0IGFwcGVhcnMgdG8gYmUgY2xvc2VyIHRvIHN0YWJsZSwgaXMgaW1wbGVtZW50YWJsZQ0KICh0 aGVyZSBhcmUgbXVsdGlwbGUgaW1wbGVtZW50YXRpb25zKSBidXQgc3RpbGwgbmVlZHMgd29ya2lu ZyBncm91cCBpbnB1dCB0byBjb21wbGV0ZS48YnI+DQo8YnI+DQpBbnkgZGlzY3Vzc2lvbiBvZiBp ZiBhIHJlYWN0aXZlIHByb3RvY29sIGNvdWxkIGJlIG9yIHNob3VsZCBiZSB1c2VkIGluIGFuIExM TiBjYW4gYmUgdGFrZW4gdG8gUk9MTCBmb3Igbm93IGFuZCBpbnRvIHRoZSBtYXJrZXQuPGJyPg0K PGJyPg0KVGhpcyBkaXNjdXNzaW9uIHNob3VsZCBiZSBhYm91dCB0aGUgZGlmZmVyZW5jZXMgaW4g dGhlIGRyYWZ0cyAod2hpY2ggVWxyaWNoIGhhcyBwb2ludGVkIG91dCkgYW5kIG9ubHkgdGhhdCBz byB0aGF0IHdlIGNhbiBmaW5kIHRoZSBiZXN0IHN0YXJ0aW5nIHBvaW50Ljxicj4NCjxicj4NCklm IHlvdSBoYXZlIHNwZWNpZmljIHBvaW50cyBpbiB0aGUgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGUg ZHJhZnRzIGJyaW5nIHRoZW0gdXAuPGJyPg0KPGJyPg0KV2Ugbm93IGtub3cgeW91IGRvbid0IGxp a2UgdGhlIG5hbWUgYW5kIHRoZSBwYXJhZ3JhcGggYWJvdXQgTExOczxicj4NCjxicj4NCkpvbjxi cj4NCjxkaXY+PHNwYW4+PGJyPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiB0aW1lcyBuZXcNCiByb21hbiwgbmV3IHlvcmssIHRpbWVz LCBzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogdGlt ZXMgbmV3IHJvbWFuLCBuZXcgeW9yaywgdGltZXMsIHNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij4N CjxkaXYgZGlyPSJsdHIiPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIj4NCjxociBzaXplPSIx Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkOyI+RnJvbTo8L3NwYW4+PC9iPiBK UCBWYXNzZXVyIChqdmFzc2V1cikgJmx0OzxhIGhyZWY9Im1haWx0bzpqdmFzc2V1ckBjaXNjby5j b20iPmp2YXNzZXVyQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OiBib2xkOyI+VG86PC9zcGFuPjwvYj4gSm9uIEJsYWNrICZsdDs8YSBocmVmPSJtYWls dG86amJsYWNrLmlldGZAeWFob28uY29tIj5qYmxhY2suaWV0ZkB5YWhvby5jb208L2E+Jmd0Ow0K PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+Q2M6PC9zcGFuPjwvYj4g VWxyaWNoIEhlcmJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzp1bHJpY2hAaGVyYmVyZy5uYW1lIj51 bHJpY2hAaGVyYmVyZy5uYW1lPC9hPiZndDs7ICZxdW90OzxhIGhyZWY9Im1haWx0bzptYW5ldEBp ZXRmLm9yZyI+bWFuZXRAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWFu ZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPiZndDsNCjxicj4NCjxiPjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDogYm9sZDsiPlNlbnQ6PC9zcGFuPjwvYj4gU2F0dXJkYXksIE5vdmVtYmVy IDMsIDIwMTIgMjoxMCBBTTxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsi PlN1YmplY3Q6PC9zcGFuPjwvYj4gUmU6IFttYW5ldF0gUmVhY3RpdmUgUHJvdG9jb2wgU2l0dWF0 aW9uPGJyPg0KPC9mb250PjwvZGl2Pg0KPGJyPg0KPG1ldGEgaHR0cC1lcXVpdj0ieC1kbnMtcHJl ZmV0Y2gtY29udHJvbCIgY29udGVudD0ib2ZmIj4NCjxkaXYgaWQ9Inlpdjk4MDMxNzI5Ij4NCjxk aXY+SGkgJnF1b3Q7Sm9uJnF1b3Q7DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Zb3UgY2FuIGtl ZXAgaWdub3Jpbmcgd2hhdCBJIGFtIHdyaXRpbmcg4oCmIGJ1dCB0aGlzIGRvZXMgbm90IGhlbHAu IFRoZSBpc3N1ZSBpcyBub3QgJnF1b3Q7dGhpcyZxdW90OyBwYXJhZ3JhcGggLSBJIGV4cGxhaW5l ZCB3aHkgYSBudW1iZXIgb2YgdGltZXMuPC9kaXY+DQo8ZGl2PkFuZCBwcm9wb3NlZCBhIHdheSB0 byBnbywgY2FsbCBpdCBvcHRpb24gMS41LjwvZGl2Pg0KPGRpdj48YnI+DQo8ZGl2Pg0KPGRpdj5P biBOb3YgMiwgMjAxMiwgYXQgNDo0OSBQTSwgSm9uIEJsYWNrIHdyb3RlOjwvZGl2Pg0KPGJyIGNs YXNzPSJ5aXY5ODAzMTcyOUFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IzAwMDtiYWNrZ3JvdW5kLWNv bG9yOiNmZmY7Zm9udC1mYW1pbHk6dGltZXMgbmV3IHJvbWFuLCBuZXcgeW9yaywgdGltZXMsIHNl cmlmO2ZvbnQtc2l6ZToxMnB0OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDo0MHB4OyI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQ7Ij5Gcm9tOjwvc3Bhbj48L2I+IEpQIFZhc3Nl dXIgKGp2YXNzZXVyKSAmbHQ7PGEgcmVsPSJub2ZvbGxvdyIgeW1haWx0bz0ibWFpbHRvOmp2YXNz ZXVyQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9Im1haWx0bzpqdmFzc2V1ckBjaXNj by5jb20iPmp2YXNzZXVyQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGJyPg0KT24gTm92IDIsIDIw MTIsIGF0IDExOjA4IEFNLCBVbHJpY2ggSGVyYmVyZyB3cm90ZTo8YnIgY2xhc3M9Inlpdjk4MDMx NzI5QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OnRpbWVzIG5ldyByb21hbiwgbmV3IHlvcmssIHRpbWVzLCBzZXJpZjtmb250LXNpemU6 MTJwdDsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6dGltZXMgbmV3IHJvbWFuLCBuZXcgeW9y aywgdGltZXMsIHNlcmlmO2ZvbnQtc2l6ZToxMnB0OyI+DQo8ZGl2IGlkPSJ5aXY5ODAzMTcyOSI+ DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDo0MHB4OyIgdHlw ZT0iY2l0ZSI+DQo8ZGl2PkkgdGhpbmsgb25lIGtleSBwb2ludCB0byBzdHJlc3MgaXMgb25lIHRo YXQgQ2hyaXMgbWVudGlvbmVkOjxicj4NCkJvdGggcHJvdG9jb2xzIGFyZSBzaW1pbGFyIGluIHRo ZWlyIG9wZXJhdGlvbiBhbmQgcGVyZm9ybWFuY2UuIFNvIGFueW9uZSBhcmd1aW5nIGFnYWluc3Qg dGhlIHBlcmZvcm1hbmNlIG9mIExPQURuZyBpcyBhdXRvbWF0aWNhbGx5IGFsc28gbm90IGludGVy ZXN0ZWQgaW4gRFlNTy4NCjxicj4NCjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6NDBweDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6NDBweDsiPlNlZSBteSBwb2ludCBVbHJpY2gg4oCmIGFuZCBJIHdyb3RlIGl0IGRvd24g c2V2ZXJhbCB0aW1lcy4gVGhlcmUgYXJlIG1ham9yIGNvbmNlcm5zIGluIHVzaW5nIExvYWQtbmcg d2l0aCBMTE5zLiBRdW90aW5nIExvYWQtbmc6PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDo0MHB4OyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDo0MHB4OyI+DQo8 cHJlIGNsYXNzPSJ5aXY5ODAzMTcyOW5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MWVtO21hcmdp bi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2NvbG9yOnJnYigwLCAwLCAwKTtmb250LXN0eWxl Om5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3Bh Y2luZzpub3JtYWw7bGluZS1oZWlnaHQ6bm9ybWFsO29ycGhhbnM6Mjt0ZXh0LWluZGVudDowcHg7 dGV4dC10cmFuc2Zvcm06bm9uZTt3aWRvd3M6Mjt3b3JkLXNwYWNpbmc6MHB4OyI+PHNwYW4gY2xh c3M9Inlpdjk4MDMxNzI5aDIiIHN0eWxlPSJsaW5lLWhlaWdodDowcHQ7ZGlzcGxheTppbmxpbmU7 d2hpdGUtc3BhY2U6cHJlO2ZvbnQtZmFtaWx5Om1vbm9zcGFjZTtmb250LXNpemU6MWVtO2ZvbnQt d2VpZ2h0OmJvbGQ7Ij48aDIgc3R5bGU9ImxpbmUtaGVpZ2h0OjBwdDtkaXNwbGF5OmlubGluZTt3 aGl0ZS1zcGFjZTpwcmU7Zm9udC1mYW1pbHk6bW9ub3NwYWNlO2ZvbnQtc2l6ZToxZW07Zm9udC13 ZWlnaHQ6Ym9sZDsiPjxhIHJlbD0ibm9mb2xsb3ciIGNsYXNzPSJ5aXY5ODAzMTcyOXNlbGZsaW5r IiBuYW1lPSJzZWN0aW9uLTMiIHRhcmdldD0iX2JsYW5rIiBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1jbGF1c2VuLWxsbi1sb2FkbmctMDYjc2VjdGlvbi0zIiBzdHlsZT0i Y29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij4zPC9hPi4gIEFwcGxpY2FiaWxpdHkg U3RhdGVtZW50PC9oMj48L3NwYW4+DQoNCiAgIFRoaXMgcHJvdG9jb2w6DQoNCiAgIG8gIElzIGEg cmVhY3RpdmUgcm91dGluZyBwcm90b2NvbCBmb3IgTW9iaWxlIEFkIGhvYyBORVR3b3Jrcw0KICAg ICAgKE1BTkVUcykuDQoNCiAgIG8gIElzIGRlc2lnbmVkIHRvIHdvcmsgaW4gbmV0d29ya3Mgd2l0 aCBkeW5hbWljIHRvcG9sb2d5IGluIHdoaWNoIHRoZQ0KICAgICAgbGlua3MgbWF5IGJlIGxvc3N5 IGR1ZSB0byBjb2xsaXNpb25zIG9yIHVuc3RhYmxlIGNoYW5uZWwuICBUaGUgdXNlDQogICAgICBj YXNlcyBpbmNsdWRlIHZlaGljdWxhciBuZXR3b3JrcywgbG93IHBvd2VyIGFuZCBsb3NzeSBuZXR3 b3JrcywNCiAgICAgIGNvbW11bml0eSBuZXR3b3JrcywgbWlsaXRhcnkgbmV0d29ya3MsIGRpc2Fz dGVyIHJlY292ZXJ5IG5ldHdvcmtzLA0KICAgICAgZXRjLg0KPC9wcmU+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5UaGlzIGlzIHdoZXJlIEkgc3Ryb25nbHkgb2JqZWN0LCBhcyBzZXZlcmFsIG90 aGVyIG9uZXMgb24gdGhpcyBtYWlsaW5nIGxpc3QuIE9uZSBjYW5ub3Qgc2ltcGx5IGZvcmdldCA0 LTUgeWVhcnMgb2YgaGFyZCB3b3JrIGZyb20gYSBXRyB0aGF0IGZvY3Vzc2VkJm5ic3A7PC9kaXY+ DQo8ZGl2Pm9uIHRoaXMgdXNlIGNhc2UmbmJzcDthbmQgY29uY2x1ZGVkIHRoYXQgc3VjaCBwcm90 b2NvbCBpcyBub3QgYXBwbGljYWJsZSB0byBMTE5zLjxicj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+ DQpbSm9uXSBJcyB0aGF0IHlvdXIgdHJ1ZSBvYmplY3Rpb24gdG8gdGhlIExPQURuZyBkcmFmdC4m bmJzcDsgVGhlbiBJIHdvdWxkIHRoaW5rIHRoZSBzaW1wbGUgc29sdXRpb24gaXMgdG8gcmVtb3Zl IHRoaXMgb25lIHBhcmFncmFwaCBhbmQgbW92ZSBvbi4mbmJzcDsNCjxicj4NCkRldmVsb3BlcnMg d2lsbCZuYnNwOyBkZWNpZGUgd2hhdCBwcm90b2NvbHMgYXJlIGFwcGxpY2FibGUgdG8gdGhlaXIg YXBwbGljYXRpb24gYXMgdGhleSBzaG91bGQgLSBhcyBJIHdpbGwuPGJyPg0KSSB3aWxsIGFzayBp biBST0xMIHdoZXJlIHRoZSBjb25jbHVzaW9uIHdhcyBkcmF3biB0aGF0IHlvdSBjYW5ub3QgcG9z c2libHkgdXNlIGEgcmVhY3RpdmUgcHJvdG9jb2wgaW4gYW55IExMTiBhcHBsaWNhdGlvbi4mbmJz cDsgVGhhdCBpcyBmb3IgYSBkaXNjdXNzaW9uIGluIFJPTEwgbm90IGhlcmUuPGJyPg0KQWdhaW4g aWYgdGhpcyBvbmUgcGFyYWdyYXBoIGlzIGFsbCB0aGUgZnVzcyB0aGVuIGxldHMgcGxlYXNlIHJl YWNoIGNvbnNlbnN1cyB0byByZW1vdmUgdGhpcyBhbmQgbW92ZSBmb3J3YXJkLiZuYnNwOyBHb3No IHRoYXQgc2VlbXMgc2ltcGxlLjxicj4NCjxicj4NCkpvbjxicj4NCjxkaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDo0MHB4OyI+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDo0MHB4OyI+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj4NCjxkaXY+SG93ZXZlciwgTE9BRG5nIGlzIGZhciBjbG9zZXIgdG8gYmVjb21l IGFuIFJGQyBpbiB0ZXJtcyBvZiB0aGUgZG9jdW1lbnQgcXVhbGl0eS4gSWYgd2Ugc3RhcnQgdGhl IG5ldyByZWFjdGl2ZSBwcm90b2NvbCBvbiB0aGUgYmFzaXMgb2YgdGhlIExPQURuZyBkcmFmdCAo YW5kIEkgcGVyc29uYWxseSBkb24ndCBjYXJlIHdoYXQgd2UgbmFtZSB0aGF0IHByb3RvY29sIGlz KSwgd2UgY2FuIGNvbnRpbnVlIHRoZSB3b3JrIG9uIHRoZSByZWFjdGl2ZQ0KIHByb3RvY29sIHRv Z2V0aGVyIGFuZCBkaXNjdXNzIHRoZSBtdWx0aXBsZSBvcHRpb25zIHRoYXQgYXJlIGN1cnJlbnRs eSBpbiBEWU1PIGFuZCBzZWUgd2hldGhlciB0aGV5IHNob3VsZCBiZSBkaXNjYXJkZWQsIHB1dCBp bnRvIGEgY29tcGFuaW9uIGRvY3VtZW50IG9yIGluIHRoZSBjb3JlIHNwZWMuDQo8YnI+DQo8YnI+ DQpCZXN0PGJyPg0KVWxyaWNoPGJyPg0KPGJyPg0KT24gTm92IDIsIDIwMTIsIGF0IDc6NTQsIFl1 aWNoaSBJR0FSQVNISSAmbHQ7PGEgcmVsPSJub2ZvbGxvdyIgeW1haWx0bz0ibWFpbHRvOnl1aWNo aS5pZ2FyYXNoaS5oYkBoaXRhY2hpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9Im1haWx0bzp5 dWljaGkuaWdhcmFzaGkuaGJAaGl0YWNoaS5jb20iPnl1aWNoaS5pZ2FyYXNoaS5oYkBoaXRhY2hp LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPkhp LDxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPkkgYWdyZWUgd2l0aCBNYXJ0aW4gYW5k IEkgd291bGQgc3VwcG9ydCBvcHRpb24gMikgYXQgdGhpcyBzdGFnZS48YnI+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj5XZSBMT0FEbmcgY28tYXV0aG9ycyBtYWRlIGVmZm9ydHMgdG8gc2lt cGxpZnkgY29yZSBzcGVjaWZpY2F0aW9uIG9mIHRoZSByZWFjdGl2ZSBwcm90b2NvbCBhbmQgdG8g aW1wcm92ZSB0aGUgcmVhZGFiaWxpdHkgb2YgdGhlIGRyYWZ0LiBJIHRoaW5rIHRoaXMgYXBwcm9h Y2ggaXMgaW1wb3J0YW50IG5vdCBvbmx5IGZvciBhbGwgaW1wbGVtZW50b3IgdG8gc2hvcnRlbiB0 aGUgZGV2ZWxvcG1lbnQgdGltZSwgYnV0DQogYWxzbyBmb3IgYnVzaW5lc3Mgb3BlcmF0b3JzIHRv IG1ha2UgbXVsdGktdmVuZG9yIHN5c3RlbSBlYXNpZXIgdG8gcHJvdmlkZS4gT2YgY291cnNlLCBJ IGFncmVlIHRoYXQsIGFzIHNldmVyYWwgcGVyc29ucyBwb2ludGVkIG91dCwgJnF1b3Q7dGhpcyBk cmFmdCZxdW90OyBtYXkgbGltaXQgdXNlIGNhc2UuIEJ1dCB3ZSBsZWF2ZSBzdWZmaWNpZW50IHNw YWNlIGZvciBpbXByb3ZpbmcgcGVyZm9ybWFuY2UvYWRkaW5nIGZ1bmN0aW9ucyBieSBjb21wYW5p b24gZHJhZnRzLjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxi cj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPkkgYW0gcmVhbGx5IGNv bmNlcm5lZCBhYm91dCBjb21wbGV4aXR5L2RpZmZpY3VsdHkgb2YgZ3VhcmFudGVlaW5nIG9mIGlu dGVyb3BlcmFiaWxpdHkuIElmIHRoZSBwcm90b2NvbCBiZWNvbWVzIGNvbXBsaWNhdGVkLCB3ZSBu ZWVkIG11Y2ggdGltZShtYW55IHllYXJzPykgZm9yIGludGVyb3BlcmFiaWxpdHkgdGVzdC4gSSB0 aGluayB3ZSBzaG91bGQgY29uc2lkZXIgYm90aCB0aW1lIHJlcXVpcmVkIGZvciBtZXJnaW5nDQog ZHJhZnRzIGFuZCBzaGFwZSBvZiBkb2N1bWVudC48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj5CZXN0IHJlZ2FyZHMsPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+WXVpY2hpPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ KDIwMTIvMTEvMDIgMjM6MDEpLCBNYXJ0aW4gSGV1c3NlIHdyb3RlOjxicj4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJy Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5JJ20gc3RhbmRpbmcgZm9yIG9wdGlvbiAyIChMT0FE bmcpLjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj5JIHRoaW5rIGl0J3MgYmV0dGVyIHRvIGFncmVlIGZpcnN0IG9uIGEgc2ltcGxlIGJhc2lj ICh2ZXJzYXRpbGU/KSBwcm90b2NvbCBiZWZvcmUgcHJvcG9zaW5nIGV4dGVuc2lvbnMgdG8gaXQ7 IGluc3RlYWQgb2Ygc3RhcnRpbmcgZnJvbSBhIGNvbGxlY3Rpb24gb2YgaWRlYXMgdGhhdCBjYW4g YmUgdXNlZCBvciBub3QgKGFuZCB3ZSBrbm93IHRvZGF5IHdoYXQgYXJlIHRoZSBvcHRpb25zLCB0 aGFuayB0byB0aGUNCiBodWdlIGFtb3VudCBvZiB3b3JrIGRvbmUgb24gcmVhY3RpdmUgcm91dGlu ZyBkdXJpbmcgdGhlIHBhc3QgeWVhcnMpLiBDb252ZXJzZWx5LCBpdCB3b3VsZCBiZSBjZXJ0YWlu bHkgZWFzaWVyIHRvIHJlYWNoIGEgY29uc2Vuc3VzIG9uIGEgc2V0IG9mIHZhcmlhbnRzIGJ1dCB3 ZSBuZWVkIGEgZ29vZCByZWZlcmVuY2UgcG9pbnQsIGZpcnN0Ljxicj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5Nb3Jlb3ZlciwgcmVhY3RpdmUg cm91dGluZyBpcyBtb3N0IHByb2JhYmx5IHRoZSBhcHByb2FjaCB0aGF0IG9uZSB3b3VsZCBwaWNr IGZvciBhIHNpbXBsZSBjYXNlLiBTbyBpdCBzaG91bGQgYmUgc2ltcGxlLi4uPGJyPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPk1hcnRpbjxicj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YnI+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPkxlIDIgbm92LiAyMDEyIMOgIDAxOjU4LCBKb3lkZWVw IFRyaXBhdGhpIGEgw6ljcml0IDo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5JIGNhbiB1bmRl cnN0YW5kIHRoYXQgZm9yIGFuIExMTiBpdCBtYXkgYmUgYmVuZWZpY2lhbCBmb3Igbm90IG1haW50 YWluaW5nIGEgcHJlY3Vyc29yIGxpc3Qgb3IgaGF2aW5nIG9ubHkgdGhlIGRlc3RpbmF0aW9uIHJl cGx5IHQgbyBhIFJSRVEsIHRoZXJlIGNhbiBiZSAoYW5kIGFyZSkgb3RoZXIgaW5zdGFuY2VzIG9m IE1BTkVUcyB3aGVyZSBoYXZpbmcgdGhlIG9wdGlvbiBvZiBwcmVjdXJzb3IgbGlzdCB3aWxsDQog Y29tZSBoYW5keS4gVGhpcyBjYW4gc2F2ZSBvbiBjb250cm9sIG92ZXJoZWFkLCB1c2luZyBzb21l IHN0b3JhZ2Ugc3BhY2UgaW4gdGhlIG5vZGUuIExPQUQtbmcsIGluIG1vc3QgY2FzZXMgZG9lcyBu b3QgcHJvdmlkZSB0aGlzIGZsZXhpYmlsaXR5IHRvIHRoZSBkZXZlbG9wZXIgdG8gY2hvc2UgYmV0 d2VlbiBvcHRpb25zIGZvciBzcGVjaWZpYyBkZXBsb3ltZW50LiBTb21lIE1BTkVUIGRlcGxveW1l bnQgbWF5IGJlIGxlc3MgaGFyc2ggdGhhbiBvdGhlcnMNCiBpbiBuYXR1cmUuIEhlbmNlLCBBT0RW djIgaGF2aW5nIG1vcmUgb3BlbiBvcHRpb25zIHRoYW4gTE9BRC1uZywgaW4gbW9zdCBjYXNlcywg c2VlbSBiZW5lZmljaWFsIHRvIG1lLjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ bWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YSByZWw9Im5v Zm9sbG93IiB5bWFpbHRvPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBo cmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PGEgcmVsPSJub2ZvbGxvdyIgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4t LSA8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5IaXRhY2hpLCBM dGQuLCBZb2tvaGFtYSBSZXNlYXJjaCBMYWJvcmF0b3J5PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+SUdBUkFTSEkgWXVpY2hpPGJyPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+TWFpbO+8miA8YSByZWw9Im5vZm9sbG93IiB5bWFpbHRv PSJtYWlsdG86eXVpY2hpLmlnYXJhc2hpLmhiQGhpdGFjaGkuY29tIiB0YXJnZXQ9Il9ibGFuayIg aHJlZj0ibWFpbHRvOnl1aWNoaS5pZ2FyYXNoaS5oYkBoaXRhY2hpLmNvbSI+DQp5dWljaGkuaWdh cmFzaGkuaGJAaGl0YWNoaS5jb208L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+VGVsIO+8miAmIzQzOzgxLSgwKTQ1LTg2MC0zMDgzPGJyPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+RkFYIO+8miAmIzQzOzgxLSgwKTQ1LTg2MC0x NjczPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5tYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YSByZWw9Im5vZm9sbG93IiB5bWFpbHRv PSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBocmVmPSJtYWlsdG86bWFu ZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxhIHJlbD0ibm9mb2xsb3ciIHRhcmdldD0iX2JsYW5rIiBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0Ij5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxicj4NCjwvYmxvY2txdW90ZT4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFu ZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgcmVsPSJub2ZvbGxvdyIgeW1haWx0bz0ibWFpbHRvOm1h bmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3Jn Ij5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSByZWw9Im5vZm9sbG93IiB0YXJnZXQ9Il9ibGFu ayIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48YnI+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFp bGluZyBsaXN0PGJyPg0KPGEgcmVsPSJub2ZvbGxvdyIgeW1haWx0bz0ibWFpbHRvOm1hbmV0QGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5l dEBpZXRmLm9yZzwvYT48YnI+DQo8YSByZWw9Im5vZm9sbG93IiB0YXJnZXQ9Il9ibGFuayIgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48YnI+DQo8YnI+DQo8YnI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPG1ldGEgaHR0cC1lcXVpdj0ieC1kbnMtcHJlZmV0 Y2gtY29udHJvbCIgY29udGVudD0ib24iPg0KPGJyPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_03B78081B371D44390ED6E7BADBB4A772204E594xmbrcdx02ciscoc_-- From jblack.ietf@yahoo.com Sat Nov 3 09:00:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F5721F9CA1 for ; Sat, 3 Nov 2012 09:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1qeQfrgpTrL for ; Sat, 3 Nov 2012 09:00:42 -0700 (PDT) Received: from nm26-vm0.bullet.mail.bf1.yahoo.com (nm26-vm0.bullet.mail.bf1.yahoo.com [98.139.213.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8BD21F9C83 for ; Sat, 3 Nov 2012 09:00:42 -0700 (PDT) Received: from [98.139.215.140] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 16:00:41 -0000 Received: from [98.139.212.236] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 16:00:41 -0000 Received: from [127.0.0.1] by omp1045.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 16:00:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 902476.78733.bm@omp1045.mail.bf1.yahoo.com Received: (qmail 15201 invoked by uid 60001); 3 Nov 2012 16:00:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351958441; bh=fjhQcTF/y7fdr8nnZQHcAcbY7lQzVtRzjcut+BZ3A9Y=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=wN1yXPSz7ifxQH/EvfoUeovjhYDFXYXSmooXfuAWZUJLsUL9qzHAZDQwB0t1nxEc1tvEztqcvZITl+/Kb+oE1og+QIjRU4HNVjWWX6NsjDyBJYJ1Lq3MGjOcaJbi52hjzIz9+wzjCgWWJUNe2DAuVitTHfK5uf7mQZ0MTc91eU8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=g9C6xO8jLXHudQlXvHPHcquBx7Nsw6qkIHeCfqJqsLonM1TYo4/eKQxtmhTQQWIggyyrouxiWrlLVtBVud3MPywaI8FRzoTUuhnkggthlHwb9q7oqiFrlpjscRvOG67rkVd6FurQB6eHSu7UyEyCbPcDZT98kB1vO2RKIiTOOcE=; X-YMail-OSG: pwuLrhgVM1kQoM7aBaypSPmssAd25EF45J.mnira4gXFKQz LUpPW6.kqkP8bqqg.zCJIprWRDYskjOtYvPFlSrzgM.GgMkCplrtkshk2dDG Pd0V9d2duy8pQagvalQMfWcEKf7XK_lSFJJIXOrQqiRLPy738zRiSzpp5M3a 7Df8VqC3PoQByyOdFmcs_aO3aN0Zbomwaau0FBq.H1AOKNS06MZtKORZChxK JsfV1Ln9hkUcRrFK_Y1QkkX4IM0pnrsgQLNaD00n1eI76HZnQA7Ay6Wqi_sh SAktxshRpg53WCLUIlo3C.lEhkeYt.fbqtAtuVMCQo3UaG7pLp4qi.b7I.Ia MRyuOQxOHxdNEw3xvrgeZw0T1BFmqd3mTs54gSYGm.AwkCaQbHOucIZ0pyG2 8mKZBVOxaC.HfmetTOD65WVs6.6mZ03drp8.WtuedJlGXIAFQGuJEIFlRR21 sv1uGmuFYuK9U Received: from [67.213.218.72] by web160603.mail.bf1.yahoo.com via HTTP; Sat, 03 Nov 2012 09:00:41 PDT X-Rocket-MIMEInfo: 001.001, WWVzLiB3ZSBzaG91bGQgdGFrZSB0aGlzIHRvIFJPTEwgd2hlcmUgd2UgY2FuIHRhbGsgYWJvdXQgaG93IHN0b3JpbmcgbW9kZSByZWFsbHkgZG9lc24ndCB3b3JrIGluIGNvbnN0cmFpbmVkIGRldmljZXMgYW5kIFJQTCBkb2VzIGRlcGVuZCBvbiB0cmFmZmljIGFuZCB0cmFmZmljIHBhdHRlcm5zLgpUaGF0IGlzIGFib3V0IFJQTCBhbmQgdGhpcyBpcyBhYm91dCBhIHJlYWN0aXZlIHByb3RvY29sIGZvciBNYW5ldHMuCgpKb24KCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBKUCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C638@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C877@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204CB91@xmb-rcd-x02.cisco.com> <1351891740.83248.YahooMailNeo@web160605.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204D717@xmb-rcd-x02.cisco.com> Message-ID: <1351958441.96668.YahooMailNeo@web160603.mail.bf1.yahoo.com> Date: Sat, 3 Nov 2012 09:00:41 -0700 (PDT) From: Jon Black To: "JP Vasseur \(jvasseur\)" In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204D717@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1886287700-1868023565-1351958441=:96668" Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 16:00:43 -0000 --1886287700-1868023565-1351958441=:96668 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes. we should take this to ROLL where we can talk about how storing mode r= eally doesn't work in constrained devices and RPL does depend on traffic an= d traffic patterns.=0AThat is about RPL and this is about a reactive protoc= ol for Manets.=0A=0AJon=0A=0A=0A=0A=0A________________________________=0A F= rom: JP Vasseur (jvasseur) =0ATo: Jon Black =0ACc: Henning Rogge ; "manet@ietf.org"= =0ASent: Saturday, November 3, 2012 2:25 AM=0ASubject: Re= : [manet] Reactive Protocol Situation=0A =0A=0AOK I will stop arguing here = -- If I may reread what you wrote, then read RFC6550 and you will quickly s= ee why you mis-undertood the protocol. =0AHint: think of DAG rooted at sour= ce of traffic, use address aggregation mapping to topologies, P2P, storing = of source routed paths.=0A=0A=0AOn Nov 2, 2012, at 5:29 PM, Jon Black wrote= :=0A=0AAh but now you mix apples and oranges.=C2=A0 Storing mode is not goo= d for highly constrained devices (they don't have the memory for storing mo= de) so for many LLNs you are stuck with non-storing mode which is poor with= P2MP, but still fine with MP2P.=C2=A0 And therefore Henning's point is val= id.=C2=A0 It depends on traffic.=0A>=0A>Jon=0A>=0A>=0A>=0A>=0A>=0A>=0A>____= ____________________________=0A> From: JP Vasseur (jvasseur) =0A>To: Henning Rogge =0A>Cc: "manet@ietf.org= " =0A>Sent: Friday, November 2, 2012 12:10 PM=0A>Subject: = Re: [manet] Reactive Protocol Situation=0A>=0A>Again your assumption are no= t correct - look at storing mode with OF to increase connectivity if requir= ed,=0A>for P2P. But again =E2=80=A6 not appropriate for this list.=0A>=0A>O= n Nov 2, 2012, at 6:58 PM, Henning Rogge wrote:=0A>=0A>> On Fri, Nov 2, 201= 2 at 6:39 PM, JP Vasseur (jvasseur)=0A>> wrote:=0A>>>>= By your own words the effectiveness/overhead of LoadNG in LLNs=0A>>>> comp= ared to other protocols will most likely depend on the traffic=0A>>>> patte= rns (which is also true for most other routing protocols,=0A>>>> especially= Ripple).=0A>>> =0A>>> JP> This is technically incorrect - RPL/OSPF/BGP =E2= =80=A6 performances are not directly a function=0A>>> of the user traffic.= =0A>> =0A>> Ripple is a tree-based routing protocol.=0A>> =0A>> its really = good when sending traffic towards the local root, not as=0A>> good (but sti= ll good) when sending traffic from the root to its nodes,=0A>> bad when you= send traffic between two nodes with the same root and=0A>> really bad when= sending traffic between nodes that are not part of the=0A>> same root tree= .=0A>> =0A>> I would say its performance depends on the user traffic patter= n.=0A>> =0A>> The overhead (as a comparison between control plane traffic a= nd data=0A>> plane traffic) is of course always different for each protocol= =0A>> depending on the user traffic.=0A>> =0A>> Henning Rogge=0A>> -- =0A>>= Steven Hawkings about cosmic inflation: "An increase of billions of=0A>> b= illions of percent in a tiny fraction of a second. Of course, that=0A>> was= before the present government."=0A>=0A>___________________________________= ____________=0A>manet mailing list=0A>manet@ietf.org=0A>https://www.ietf.or= g/mailman/listinfo/manet=0A>=0A>=0A> --1886287700-1868023565-1351958441=:96668 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes. we should take t= his to ROLL where we can talk about how storing mode really doesn't work in= constrained devices and RPL does depend on traffic and traffic patterns.That is about RPL and this is about a reactive protocol for Manets.
Jon


<= span style=3D"font-weight:bold;">From: JP Vasseur (jvasseur) <= ;jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: Henning Rogge <hrogge@googlemail.com>; "manet@ietf.org" <manet@ietf.org>
Sent: Saturday, November 3, 2012 2:25 AM
Subject: Re: [manet] Reactive Protoc= ol Situation

=0A
=0A=0A =0A=0A
=0AOK I= will stop arguing here -- If I may reread what you wrote, then read RFC655= 0 and you will quickly see why you mis-undertood the protocol.=0A
Hint:= think of DAG rooted at source of traffic, use address aggregation mapping = to topologies, P2P, storing of source routed paths.
=0A

=0A=0A
On Nov 2, 2012, at 5:29 PM, Jon Black wrote:
=0A
=0A
=0A=0A
=0AAh but now you mix apples= and oranges.  Storing mode is not good for highly constrained devices= (they don't have the memory for storing mode) so for many LLNs you are stu= ck with non-storing mode which is poor with P2MP, but still fine with MP2P.=   And therefore=0A Henning's point is valid.  It depends on traff= ic.
=0A
=0AJon
=0A

=0A
=0A

=0A=0A
=0A
=0A=0A
=0AAgain your assumption are not correct - l= ook at storing mode with OF to increase connectivity if required,
=0Afor= P2P. But again =E2=80=A6 not appropriate for this list.
=0A
=0AOn No= v 2, 2012, at 6:58 PM, Henning Rogge wrote:
=0A
=0A> On Fri, Nov 2= , 2012 at 6:39 PM, JP Vasseur (jvasseur)
=0A> <jvasseur@cisco.com> wrote:
=0A>>> By yo= ur own words the effectiveness/overhead of LoadNG in LLNs
=0A>>>= ; compared to other protocols will most likely depend on the traffic
=0A= >>> patterns (which is also true for most other routing protocols,=
=0A>>> especially Ripple).
=0A>>
=0A>> JP&g= t; This is technically incorrect - RPL/OSPF/BGP =E2=80=A6 performances are = not directly a function
=0A>> of the user traffic.
=0A>
= =0A> Ripple is a tree-based routing protocol.
=0A>
=0A> its= really good when sending traffic towards the local root, not as
=0A>= good (but still good) when sending traffic from the root to its nodes,
= =0A> bad when you send traffic between two nodes with the same root and<= br>=0A> really bad when sending traffic between nodes that are not part = of the
=0A> same root tree.
=0A>
=0A> I would say its pe= rformance depends on the user traffic pattern.
=0A>
=0A> The o= verhead (as a comparison between control plane traffic and data
=0A> = plane traffic) is of course always different for each protocol
=0A> d= epending on the user traffic.
=0A>
=0A> Henning Rogge
=0A&g= t; --
=0A> Steven Hawkings about cosmic inflation: "An increase of b= illions of
=0A> billions of percent in a tiny fraction of a second. O= f course, that
=0A> was before the present government."
=0A
=0A= _______________________________________________
=0Amanet mailing list=0Amanet@ietf.org
=0Aht= tps://www.ietf.org/mailman/listinfo/manet
=0A
=0A
=0A
=0A=
=0A
=0A
=0A
=0A
=0A
=0A
=0A
= =0A=0A

=
--1886287700-1868023565-1351958441=:96668-- From jblack.ietf@yahoo.com Sat Nov 3 09:03:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6078B21F9C53 for ; Sat, 3 Nov 2012 09:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7qx53OQXhSD for ; Sat, 3 Nov 2012 09:03:49 -0700 (PDT) Received: from nm37-vm7.bullet.mail.bf1.yahoo.com (nm37-vm7.bullet.mail.bf1.yahoo.com [72.30.238.207]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA8A21F9C5F for ; Sat, 3 Nov 2012 09:03:49 -0700 (PDT) Received: from [98.139.215.143] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 16:03:43 -0000 Received: from [98.139.212.192] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 16:03:43 -0000 Received: from [127.0.0.1] by omp1001.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 16:03:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 665151.72976.bm@omp1001.mail.bf1.yahoo.com Received: (qmail 62171 invoked by uid 60001); 3 Nov 2012 16:03:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351958623; bh=k+Sq6htSqWTPLXOeVIs0P1jIbFyaabWtkmfD/0gdBAI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=3S4OWvnmIdj9b4kinuJEF3uoR7Yj61hJRpKbaZX9UJ6ggW0rrwLk0lGO2/0MX09xsQpsXx5sYLOwQF5g8mqHgGRwBnf6Pb8bsHR7zO4IgoEuSHyXa0hCuGo6w1uWCvJx/nXK2uXi61McPGfQBGWRD7peMvNRHPFR5vqf6N3Ph+M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Ux4/ZiL90NIN/vbzNREB9SlovGdYpLvqimtamNS8EUqacfTtuFM2xLKyYutzbeBhGxclD9/nVUPi6M5Uqv4sibmXRErhvhh2VvAP8xP76wmXSh3Wd7BQgRXDx2KkSO4s2Z00mtPVzW8f6/QgVCkwBUFbkgV12ZbByrD0w1pjsP0=; X-YMail-OSG: D6zVwMwVM1ll0XxxKpLT.0jEySRXA5o_D0Z0Ytvz2a30YIO WLZN06TjMriovvX.u.n3.jQdn_nSefIuU6IpQuzZjwspfBckJsOxc7j9MS4F RIlD74EDiz26LK4OTIdXZBzRjg5oCL_cqCjh2cat6M6fMOLAmu.mSzXkXz4L rzPwO8neHbGe_61rPYWH100Uo1Pqcfegbpa3gSKS7n81ZMkNY5htzlNZj3Rp h6qjKHPXez94jJlSZRQx9sg0d5UwjSwClv2MRfQaJnFJVQTvV9BMVCz0lIu4 5gBscC7dSboyx6QquqwVAq4uOQqkoetbvu26yKDLvkrG6MYrWNk9IggkYpq0 Kpj0lFCdM8VYIIGvk1Q9kRLzhLcWnDsleCgjgXsOF_T9QRwmlLFlM9Ufun0d 2i5p2zVrbRjaTKgDaEQ_ZWfXzxqan0BMK0clR8KanCjP76jvAzu8vSqH2pfm IHZv2QA-- Received: from [67.213.218.72] by web160601.mail.bf1.yahoo.com via HTTP; Sat, 03 Nov 2012 09:03:43 PDT X-Rocket-MIMEInfo: 001.001, QmVjYXVzZSB0aGlzIHdhcyBub3QgZXhjZWxsZW50IHdvcmsuwqAgaXQgd2FzIG5ldmVyIHZldHRlZCBleGNlcHQgYnkgcGVvcGxlIHRoYXQgd2FudGVkIHRvIGNyZWF0ZSBhIG5ldyBwcm90b2NvbC4gCgpCdXQgYWdhaW4gdGhhdCBpc24ndCBhYm91dCB0aGlzIGRlYmF0ZS4gCgpKb24KCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBKUCBWYXNzZXVyIChqdmFzc2V1cikgPGp2YXNzZXVyQGNpc2NvLmNvbT4KVG86IEppYXppIFlJIDxpZXRmQGppYXppeWkuY29tPiAKQ2M6ICJtYW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D773@xmb-rcd-x02.cisco.com> Message-ID: <1351958623.55036.YahooMailNeo@web160601.mail.bf1.yahoo.com> Date: Sat, 3 Nov 2012 09:03:43 -0700 (PDT) From: Jon Black To: "JP Vasseur \(jvasseur\)" , Jiazi YI In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204D773@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1737431079-1528589680-1351958623=:55036" Cc: "Timothy J. Salo" , "manet@ietf.org List" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 16:03:51 -0000 --1737431079-1528589680-1351958623=:55036 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Because this was not excellent work.=C2=A0 it was never vetted except by pe= ople that wanted to create a new protocol. =0A=0ABut again that isn't about= this debate. =0A=0AJon=0A=0A=0A=0A=0A________________________________=0A F= rom: JP Vasseur (jvasseur) =0ATo: Jiazi YI =0ACc: "manet@ietf.org List" ; Timothy J. Salo =0ASent: Saturday, November 3, 2012 2:29 AM=0ASubject: Re: [m= anet] LOADng works=0A =0A=0A=0A=0AOn Nov 2, 2012, at 7:27 PM, Jiazi YI wrot= e:=0A=0AHi,=C2=A0=0A>=0A>=0A>I don't think citing a draft that has been exp= ired for 3 years actually says anything.=C2=A0=0A=0AWhy ignoring excellent = work ?=0A=0A=0A>=0A>best=0A>=0A>=0A>Jiazi=0A>=0A>=0A>=0A>On Nov 3, 2012, at= 12:19 AM, C Chauvenet wrote:=0A>=0A>HI,=C2=A0 = =0A>>See inline.=0A>>=0A>>=0A>>Le 2 nov. 2012 =C3=A0 18:22, Ulrich Herberg = a =C3=A9crit :=0A>>=0A>>JP,=0A>>>=0A>>>=0A>>>On Fri, Nov 2, 2012 at 10:09 A= M, JP Vasseur (jvasseur) wrote:=0A>>>=0A>>>=0A>>>>On N= ov 2, 2012, at 12:06 PM, Timothy J. Salo wrote:=0A>>>>=0A>>>>>>>> JP> This = is not just a question of "how large" it is =E2=80=A6 but also how=0A>>>>>>= >> dynamic. I could show you few hundreds (if not less number of nodes)=0A>= >>>>>>> not working if the traffic pattern is too dynamic. This is a=0A>>>>= >>>> fundamental problem.=0A>>>>>=0A>>>>> No, it is a fundamental and well-= known characteristic of reactive=0A>>>>> routing protocols. =C2=A0It is a p= roblem only when this behavior doesn't=0A>>>>> match the characteristics of= the network in which the reactive routing=0A>>>>> protocol is deployed.=0A= >>>>=0A>>>>=0AJP> Indeed =E2=80=A6 and this is why you have a fundamental i= ssue with you have extremely high BER, PDR,=0A>>>>low bandwidth =E2=80=A6 a= s we do in LLNs. Flooding in these networks is driven by user traffic and o= f course=0A>>>>is highly undesirable. Slightly increase the use traffic and= you will see the impact on the control plane ...=0A>>>>=0A>>>=0A>>>=0A>>>= =0A>>>=0A>>>Yes, but as Timothy mentioned, there are cases where you don't = have much user traffic. This is well known. If you have more user traffic, = then you may need a proactive protocol. You may not like the idea that some= people actually deploy reactive protocols in LLNs, but it's a fact.=C2=A0A= nd your argument, again, makes no sense that you think that DYMO is suitabl= e and LOADng is not.=0A>>>=0A>>>=0A>>>=C2=A0=0A>>>>=0A>>>>> We've known for= at least 15 years that reactive routing protocols are=0A>>>>> more appropr= iate for light traffic loads and that proactive routing=0A>>>>> protocols a= re more appropriate with heavier traffic loads.=0A>>>>=0A>>>>=0AJP> This is= over-simplying but I see what you mean.=0A>>>>=0A>>>>=0A>>>>> Dozens,=0A>>= >>> probably hundreds of research papers have reiterated this result.=0A>>>= >> I don't know of any that have contradicted this result, although=0A>>>>>= some researchers have tried to develop hybrid routing protocols=0A>>>>> (w= hich don't seem to have gained much traction, either in the IETF=0A>>>>> or= elsewhere).=0A>>>>>=0A>>>>> Claiming that reactive routing protocols don't= scale to heavier traffic=0A>>>>> loads is neither a new result nor particu= larly insightful -- this hasn't=0A>>>>> changed for at least 15 years.=0A>>= >>=0A>>>>=0AJP> Let me restate my point. Not sure of what you mean by "heav= ier" =E2=80=A6 but if you=0A>>>>flood the network with probes each time you= need to find a path in a LLN you have=0A>>>>a major problem. =0A>>>=0A>>>= =0A>>>Well, if you have few communication streams, the few floods are much = less heavy than having a proactive protocol exchange control traffic all da= y. Again, no argument in favor for DYMO and against LOADng. Note also that = you only talk about LLN, but we are the [manet] WG.=0A>>>=0A>>>=0A>>>=C2=A0= =0A>>>Of course, there are many ways to control flooding, use caches ..=0A>= >>>that are all well-known and by the way hard to tune. But overall, reacti= ve routing in=0A>>>>*these* networks is simply ill suited.=0A>>>>=0A>>>>=0A= >>>>>=0A>>>>> I haven't seen any evidence that _no_ LLN will experience the= sort of=0A>>>>> light traffic load that matches the characteristics of a r= eactive=0A>>>>> routing protocol. =C2=A0To the contrary, the deployment exp= erience with=0A>>>>> LOADng suggests that such do networks exist.=0A>>>>=0A= >>>>=0AJP> Once again it all depends on the traffic profile. Of course you = could make a=0A>>>>reactive routing protocol work on a LLN as long as the u= ser traffic has specific=0A>>>>characteristics.=0A>>>=0A>>>=0A>>>=0A>>>=0A>= >>Exactly! Thanks for pointing that out. That's the whole point why [manet]= is chartered to do both reactive and proactive protocols.=0A>>>=0A>>>=0A>>= >=C2=A0=0A>>>If you carefully analyze the user traffic characteristic in ne= tworks=0A>>>>such as smart metering (since this was mentioned on this list)= , and you incorporate=0A>>>>additional applications such as DA, .. to menti= on a few, you will see that in most of=0A>>>>these networks this simply doe= s not work =E2=80=A6 too many flooding, ending up not even=0A>>>>converging= in some cases, especially when the number of hops gets high with poor=0A>>= >>link quality.=0A>>>>=0A>>>=0A>>>=0A>>>You are not bringing up any new arg= ument that is not known to [manet] for the last 15 years. Reactive protocol= s only work for certain scenarios. We know that. We have never disputed tha= t.=0A>>>=0A>>>=0A>>>=C2=A0=0A>>>=0A>>>>>=0A>>>>> At the risk of arguing by = analogy, the argument that one can "prove"=0A>>>>> that reactive routing pr= otocols don't work (in LLNs or elsewhere) seems=0A>>>>> to =C2=A0make about= as much as sense as "proving" that OSPF doesn't work=0A>>>>> because it do= esn't behave well in dynamic environments. =C2=A0The failure of=0A>>>>> OSP= F in dynamic environments didn't cause us to abandon OSPF: there are=0A>>>>= > many environments in which it works well.=0A>>>>=0A>>>>=0AJP> Not sure th= at I would have used this analogy :-( OSPF was not designed for highly=0A>>= >>dynamic environment indeed *but* we could easily enhance it with fast fai= lure detection=0A>>>>(+ BFD), fast LSA generation, fast SPF and incremental= SPF, Local Fast Reroute, =E2=80=A6=0A>>>>because routers had lot of resour= ces, links were highly stable, =E2=80=A6 which is by far not the=0A>>>>case= of LLNs.=0A>>>>=0A>>>>=0A>>>>> Rather, we concluded that we=0A>>>>> needed= another routing protocol. =C2=A0In a similar manner, the MANET=0A>>>>> wor= king group, and as far as I have seen pretty much all of the=0A>>>>> resear= ch community, concluded that there is a need for both a=0A>>>>> reactive ro= uting protocol and a proactive routing protocol.=0A>>>>>=0A>>>>> Of course,= the ROLL working group can decide not to standardize=0A>>>>> a reactive ro= uting protocol. =C2=A0However, that doesn't prove that=0A>>>>> reactive rou= ting protocols don't work (when they match the=0A>>>>> traffic characterist= ics of the network), that reactive routing=0A>>>>> protocols won't work bet= ter than proactive routing protocols=0A>>>>> in some LLNs (based on the cha= racteristics of the traffic load),=0A>>>>> or that reactive routing protoco= ls won't be successfully deployed=0A>>>>> in LLNs.=0A>>>>=0A>>>>=0AJP> Well= =E2=80=A6 Think about this: when ROLL was formed, the IESG explicitly and = rightfully asked=0A>>>>the WG to first prove that none of the existing prot= ocol could be used, before standardizing a=0A>>>>new protocol (that was the= right choice !!).=0A>>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>Right, but that "pro= of" was never published by the IETF, and as such only an assertion. Moreove= r, we are not the ROLL WG.=0A>>=0A>>=0A>>I think=C2=A0http://tools.ietf.org= /html/draft-ietf-roll-protocols-survey-07=C2=A0is such a publication.=0A>>B= TW, it covers AODV and DYMO, and explains why it does not match general LLN= requirements (and so for any AODV-based protocols such as LOADng).=0A>>=0A= >>=0A>>But I agree that this is MANET list, so this should not be the place= to debate RPL here.=0A>>I think ROLL-ers came in the discussion because LO= ADng authors explicitly states that they want to use LOADng in LLNs, that i= s ROLL working space. Though, I think you agree that LOADng will not match = general LLN requirements and be limited to specific low traffic deployment.= =0A>>=0A>>=0A>>C=C3=A9dric.=0A>>=0A>>=C2=A0=0A>>>=0A>>>>Could then prove th= at the current protocol cannot be used in your environment before suggestin= g=0A>>>>to standardize a new one.=0A>>>>=0A>>>>Once again, if not applicabl= e to LLNs, I have no problem whatsoever.=0A>>>>=0A>>>=C2=A0=0A>>>=0A>>>=0A>= >>People have deployed reactive protocols as a matter of fact in LLNs. So, = is the only reason why you like DYMO and not LOADng, because LOADng mention= s the word LLN once in the introduction?=0A>>>=0A>>>=0A>>>Best regards=0A>>= >Ulrich=0A>>>=0A>>>=0A>>>=C2=A0=0A>>>=0A>>>>> If fact, the LOADng deploymen= t experience strongly=0A>>>>> suggests that reactive routing protocols _wil= l_ be deployed in=0A>>>>> some LLNs. =C2=A0And, they will be deployed regar= dless of the ROLL=0A>>>>> working group's decision to not standardize a rea= ctive routing=0A>>>>> protocol.=0A>>>>=0A>>>>=0AJP> And this is perfectly f= ine, people are free to use any protocol they want, including proprietary= =0A>>>>ones. This does not mean that the IETF should standardize them.=0A>>= >>=0A>>>>=0A>>>>>=0A>>>>> Claiming that reactive routing protocols don't wo= rk because they=0A>>>>> don't scale to higher traffic loads seems,=0A>>>>= =0A>>>>=0AJP> Then we need to characterize precisely the limits.=0A>>>>=0A>= >>>=0A>>>>> at best, a poor=0A>>>>> characterization of well-known research= results, and at worst=0A>>>>> a distraction from the question at hand: nam= ely how to proceed=0A>>>>> towards an Internet-standard reactive routing pr= otocol.=0A>>>>>=0A>>>>> -tjs=0A>>>>=0A>>>>_________________________________= ______________=0A>>>>manet mailing list=0A>>>>manet@ietf.org=0A>>>>https://= www.ietf.org/mailman/listinfo/manet=0A>>>>=0A>>>___________________________= ____________________=0A>>>manet mailing list=0A>>>manet@ietf.org=0A>>>https= ://www.ietf.org/mailman/listinfo/manet=0A>>>=0A>>=0A_______________________= ________________________=0A>>manet mailing list=0A>>manet@ietf.org=0A>>http= s://www.ietf.org/mailman/listinfo/manet=0A>>=0A>=0A________________________= _______________________=0A>manet mailing list=0A>manet@ietf.org=0A>https://= www.ietf.org/mailman/listinfo/manet=0A>=0A=0A______________________________= _________________=0Amanet mailing list=0Amanet@ietf.org=0Ahttps://www.ietf.= org/mailman/listinfo/manet --1737431079-1528589680-1351958623=:55036 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Because this was not = excellent work.  it was never vetted except by people that wanted to c= reate a new protocol.

But again that isn't about this debate.
<= br>Jon


= From: JP Vasseur (jvasseur) &l= t;jvasseur@cisco.com>
To: Jiazi YI <ietf@jiaziyi.com>
Cc: "manet@ietf.org List" <manet@ietf.org>; Timoth= y J. Salo <salo@saloits.com>
Sent: Saturday, November 3, 2012 2:29 AM
Subject: Re: [manet] LOADng works
=

=0A
=0A=0A =0A=0A
=0A
=0A
=0A
= On Nov 2, 2012, at 7:27 PM, Jiazi YI wrote:
=0A
=0A
=0A
=0A
Hi, 
=0A

=0A
=0A
I=0A don't think citing a draft th= at has been expired for 3 years actually says anything. 
= =0A
=0A
=0A

=0A
=0A
Why ignoring excellen= t work ?
=0A
=0A
=0A
=0A

=0A
=0A
be= st
=0A

=0A
=0A
Ji= azi
=0A
=0A
=0A
=0A
=0A
= On Nov 3, 2012, at 12:19 AM, C Chauvenet <c.chauvenet@watteco.com> wrote:
=0A
=0A
=0A=0AHI, =0A
See inline.
=0A<= div>
=0A
=0A
=0A
Le 2 nov. 2012 =C3=A0 18:22, Ulrich Herberg= a =C3=A9crit :
=0A
=0A
JP,
=0A
=0A
On Fri, Nov 2, 2012 at 10:09 AM, JP Vasseur (jvasseur) =0A<jvasseur@cisco.com&= gt; wrote:
=0A
=0A
=0AOn Nov 2, 2012, at 12:06 PM, Timothy J. Sa= lo wrote:
=0A
=0A>>>> JP> This is not just a question = of "how large" it is =E2=80=A6 but also how
=0A>>>> dynamic.= I could show you few hundreds (if not less number of nodes)
=0A>>= >> not working if the traffic pattern is too dynamic. This is a
= =0A>>>> fundamental problem.
=0A>
=0A> No, it is a = fundamental and well-known characteristic of reactive
=0A> routing pr= otocols.  It is a problem only when this behavior doesn't
=0A> m= atch the characteristics of the network in which the reactive routing
= =0A> protocol is deployed.
=0A
=0A
=0AJP> Indeed =E2=80=A6= and this is why you have a fundamental issue with you have extremely high = BER, PDR,
=0Alow bandwidth =E2=80=A6 as we do in LLNs. Flooding in these= networks is driven by user traffic and of course
=0Ais highly undesirab= le. Slightly increase the use traffic and you will see the impact on the co= ntrol plane ...
=0A
=0A

=0A
=0A

=0A=0A
Yes, but as Timothy mentioned, there are cases where you don't ha= ve much user traffic. This is well known. If you have more user traffic, th= en you may need a proactive protocol. You may not like the idea that some p= eople actually deploy reactive protocols=0A in LLNs, but it's a fact. = And your argument, again, makes no sense that you think that DYMO is suitab= le and LOADng is not.
=0A

=0A
=0A
 
=0A=0A
&g= t;
=0A> We've known for at least 15 years that reactive routing proto= cols are
=0A> more appropriate for light traffic loads and that proac= tive routing
=0A> protocols are more appropriate with heavier traffic= loads.
=0A
=0A
=0AJP> This is over-simplying but I see what = you mean.
=0A

=0A> Dozens,
=0A>= ; probably hundreds of research papers have reiterated this result.
=0A&= gt; I don't know of any that have contradicted this result, although
=0A= > some researchers have tried to develop hybrid routing protocols
=0A= > (which don't seem to have gained much traction, either in the IETF
= =0A> or elsewhere).
=0A>
=0A> Claiming that reactive routing= protocols don't scale to heavier traffic
=0A> loads is neither a new= result nor particularly insightful -- this hasn't
=0A> changed for a= t least 15 years.
=0A
=0A
=0AJP> Let me restate my point. Not= sure of what you mean by "heavier" =E2=80=A6 but if you
=0Aflood the ne= twork with probes each time you need to find a path in a LLN you have
= =0Aa major problem.
=0A

=0A
=0A
Well, if you = have few communication streams, the few floods are much less heavy than hav= ing a proactive protocol exchange control traffic all day. Again, no argume= nt in favor for DYMO and against LOADng. Note also that you only talk about= LLN, but we are=0A the [manet] WG.
=0A

=0A
=0A
 = ;
=0A
=0AOf course, there a= re many ways to control flooding, use caches ..
=0Athat are all well-kno= wn and by the way hard to tune. But overall, reactive routing in
=0A*the= se* networks is simply ill suited.
=0A

= =0A>
=0A> I haven't seen any evidence that _no_ LLN will experienc= e the sort of
=0A> light traffic load that matches the characteristic= s of a reactive
=0A> routing protocol.  To the contrary, the dep= loyment experience with
=0A> LOADng suggests that such do networks ex= ist.
=0A
=0A
=0AJP> Once again it all depends on the traffic = profile. Of course you could make a
=0Areactive routing protocol work on= a LLN as long as the user traffic has specific
=0Acharacteristics.=0A

=0A
=0A

=0A
=0A
Exactly! Thanks f= or pointing that out. That's the whole point why [manet] is chartered to do= both reactive and proactive protocols.
=0A

=0A
=0A
&= nbsp;
=0A
=0AIf you careful= ly analyze the user traffic characteristic in networks
=0Asuch as smart = metering (since this was mentioned on this list), and you incorporate
= =0Aadditional applications such as DA, .. to mention a few, you will see th= at in most of
=0Athese networks this simply does not work =E2=80=A6 too = many flooding, ending up not even
=0Aconverging in some cases, especiall= y when the number of hops gets high with poor
=0Alink quality.
=0A=0A

=0A
=0A
You are not bringing up any new argu= ment that is not known to [manet] for the last 15 years. Reactive protocols= only work for certain scenarios. We know that. We have never disputed that= .
=0A

=0A
=0A
 
=0A
=0A

=0A>
=0A>= At the risk of arguing by analogy, the argument that one can "prove"
= =0A> that reactive routing protocols don't work (in LLNs or elsewhere) s= eems
=0A> to  make about as much as sense as "proving" that OSPF= doesn't work
=0A> because it doesn't behave well in dynamic environm= ents.  The failure of
=0A> OSPF in dynamic environments didn't c= ause us to abandon OSPF: there are
=0A> many environments in which it= works well.
=0A
=0A
=0AJP> Not sure that I would have used t= his analogy :-( OSPF was not designed for highly
=0Adynamic environment = indeed *but* we could easily enhance it with fast failure detection
=0A(= + BFD), fast LSA generation, fast SPF and incremental SPF, Local Fast Rerou= te, =E2=80=A6
=0Abecause routers had lot of resources, links were highly= stable, =E2=80=A6 which is by far not the
=0Acase of LLNs.
=0A

=0A> Rather, we concluded that we
=0A>= needed another routing protocol.  In a similar manner, the MANET
= =0A> working group, and as far as I have seen pretty much all of the
= =0A> research community, concluded that there is a need for both a
= =0A> reactive routing protocol and a proactive routing protocol.
=0A&= gt;
=0A> Of course, the ROLL working group can decide not to standard= ize
=0A> a reactive routing protocol.  However, that doesn't pro= ve that
=0A> reactive routing protocols don't work (when they match t= he
=0A> traffic characteristics of the network), that reactive routin= g
=0A> protocols won't work better than proactive routing protocols=0A> in some LLNs (based on the characteristics of the traffic load),<= br>=0A> or that reactive routing protocols won't be successfully deploye= d
=0A> in LLNs.
=0A
=0A
=0AJP> Well =E2=80=A6 Think abo= ut this: when ROLL was formed, the IESG explicitly and rightfully asked
= =0Athe WG to first prove that none of the existing protocol could be used, = before standardizing a
=0Anew protocol (that was the right choice !!).=0A
=0A

=0A
=0A

=0A
=0A
Right, = but that "proof" was never published by the IETF, and as such only an asser= tion. Moreover, we are not the ROLL WG.
=0A
=0A
=0A
=0A
=0A=0A
BTW, it covers AODV and DYMO, and explains wh= y it does not match general LLN requirements (and so for any AODV-based pro= tocols such as LOADng).
=0A

=0A
=0A
But I agree that = this is MANET list, so this should not be the place to debate RPL here.=0A
I think ROLL-ers came in the discussion because LOADng authors ex= plicitly states that they want to use LOADng in LLNs, that is ROLL working = space. Though, I think you agree that LOADng will not match general LLN req= uirements and be limited to specific=0A low traffic deployment.
=0A
=0A
=0A
C=C3=A9dric.
=0A
=0A
=0A
=0A
 
=0A=0A
=0ACould then prove that the cur= rent protocol cannot be used in your environment before suggesting
=0Ato= standardize a new one.
=0A
=0AOnce again, if not applicable to LLNs,= I have no problem whatsoever.
=0A
=0A
 
=0A
=0A
=0A
People have deployed reactive protocols as a matter= of fact in LLNs. So, is the only reason why you like DYMO and not LOADng, = because LOADng mentions the word LLN once in the introduction?
=0A
=0A
=0A
Best regards
=0A
Ulrich
=0A

=0A=
=0A
 
=0A
= =0A

=0A> If fact, the LOADng deployment= experience strongly
=0A> suggests that reactive routing protocols _w= ill_ be deployed in
=0A> some LLNs.  And, they will be deployed = regardless of the ROLL
=0A> working group's decision to not standardi= ze a reactive routing
=0A> protocol.
=0A
=0A
=0AJP> And= this is perfectly fine, people are free to use any protocol they want, inc= luding proprietary
=0Aones. This does not mean that the IETF should stan= dardize them.
=0A

=0A>
=0A> Cl= aiming that reactive routing protocols don't work because they
=0A> d= on't scale to higher traffic loads seems,
=0A
=0A
=0AJP> Then= we need to characterize precisely the limits.
=0A
=0A

=0A> at best, a poor=0A> characterization of well-known research results, and at worst
= =0A> a distraction from the question at hand: namely how to proceed
= =0A> towards an Internet-standard reactive routing protocol.
=0A><= br>=0A> -tjs
=0A
=0A______________________________________________= _
=0Amanet mailing list
=0Amanet@ietf.org=
=0Ahttps://www.ietf.org/mailman/listinfo/manet<= br>=0A
=0A
=0A
=0A
=0A
=0A___________________= ____________________________
=0Amanet mailing list
=0Amanet@ietf.org
=0Ahttps://www.ietf.org/= mailman/listinfo/manet
=0A=0A
=0A
=0A
=0A<= /div>=0A=0A_______________________________________________
=0Amane= t mailing list
=0Amanet@ietf.org
=0A<= a rel=3D"nofollow" target=3D"_blank" href=3D"https://www.ietf.org/mailman/l= istinfo/manet">https://www.ietf.org/mailman/listinfo/manet
=0A=0A=0A
=0A=0A________________________________________= _______
=0Amanet mailing list
=0Amanet@ie= tf.org
=0Ahttps://www.ietf.org/mailman/listinfo/manet
=0A=0A=0A
=0A=0A=0A
_____________________________________________= __
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/list= info/manet


--1737431079-1528589680-1351958623=:55036-- From jblack.ietf@yahoo.com Sat Nov 3 09:09:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9429221F9C81 for ; Sat, 3 Nov 2012 09:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj8W61LjdYDL for ; Sat, 3 Nov 2012 09:09:42 -0700 (PDT) Received: from nm21-vm0.bullet.mail.bf1.yahoo.com (nm21-vm0.bullet.mail.bf1.yahoo.com [98.139.213.137]) by ietfa.amsl.com (Postfix) with ESMTP id 8204321F9C6B for ; Sat, 3 Nov 2012 09:09:41 -0700 (PDT) Received: from [98.139.215.142] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 16:09:38 -0000 Received: from [98.139.212.222] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 16:09:38 -0000 Received: from [127.0.0.1] by omp1031.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 16:09:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 274488.34256.bm@omp1031.mail.bf1.yahoo.com Received: (qmail 23616 invoked by uid 60001); 3 Nov 2012 16:09:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351958978; bh=Hk+A3xFfKRpRQfjnHk6yH63tHq+uA4qkAqd9Woe9/lg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Hn6IN/a1C0adIg7vfVo0mEuMqT+npbQJ7ERCg0Iw9jbemrn6V88BGBbJ0OSV92zCg3wkd4S54bT8J4hUxuXJosEOHLkMinquQ196IG9qMYak2hU4oCzisPJxUAdgXOC5rALRHKr1GG3KPQavEn5zG+mIwc+rAEj26GTpXtryGgo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=jU9VKNMnLGlmRFdEZYJVD20TbATB4kAYuIHp9dEMPO5h8onawk74DLpQXkk6MGtCijd6mqQcUTb9ufs/u4Y7NX29ABmfttFoXUnFxv7rQlPZpiyDVMUovRGXEwCks6m0Ru0QEkDr/T3J46DUAhgsBZYd1y4jYsGPIveWpV4+NKo=; X-YMail-OSG: JUrbNdkVM1knVZff4KU48uYMFAdYxT_6zEd9LFL03oNooLN chc0rCPzuRPyj.UMKQVKQi8qphacrIkwMdyx.ZSsS1Ll9R2RU8G5RdU9mf2u A8XoIBouHQ4bJu30dIVI3nJphol7uJc9e4xbk35QsExhgugMOHrzsDUkKvTR AXghdkBInStmZooHyTmA9jIJ6ZLaRV3Vp5U8d9RDhtjROTARdGaD67m5Q53Z 5_JWatgQ2DdzF4f72GlIyHpWVPgMKQlIqUPjVNovZE5_CiJaUDmiGHALTtaX 0IO8liWz6rZCtxnTQx2zJJAmj9kOyywnr0Ir8zxzWkMUESmfyORJmGq1Nv6F me.D_v4pC1GYTb3IVg.GUk5YGdTtkDTHk9___yvNHmNTzjx7mG_Ox9tlJ9RH a.6C6ObWt4hR5bJaFDOmO_1ty0wF3m99kq9pqGSchUjPvfZYFIkNcRPY14Sq ipjCauRo- Received: from [67.213.218.72] by web160603.mail.bf1.yahoo.com via HTTP; Sat, 03 Nov 2012 09:09:37 PDT X-Rocket-MIMEInfo: 001.001, T29wcyBzaG91bGQgaGF2ZSByZWFkIHRoaXMgZmlyc3QgYmVmb3JlIG15IHByZXZpb3VzIHJlcGxpZXMuCgpJIGFncmVlLsKgIE15IG9waW5pb24gaXMgYWxzbyBvYnZpb3VzLsKgIChJIHdpbGwgYXR0ZW1wdCB0byBiZSBxdWlldC4uLikKCldlJ3ZlIGhlYXJkIGZyb20gNiBvciA3IG9mIHRoZSBzYW1lIHBlb3BsZSwgd2hlcmUgaXMgdGhlIHJlc3Qgb2YgdGhlIG1haWxpbmcgbGlzdCBvbiB0aGlzLgoKSm9uCgoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IEpvc2VwaCBNYWNrZXIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> Message-ID: <1351958977.23565.YahooMailNeo@web160603.mail.bf1.yahoo.com> Date: Sat, 3 Nov 2012 09:09:37 -0700 (PDT) From: Jon Black To: Joseph Macker , "JP Vasseur \(jvasseur\)" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1886287700-1479226928-1351958977=:23565" Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 16:09:43 -0000 --1886287700-1479226928-1351958977=:23565 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Oops should have read this first before my previous replies.=0A=0AI agree.= =A0 My opinion is also obvious.=A0 (I will attempt to be quiet...)=0A=0AWe'= ve heard from 6 or 7 of the same people, where is the rest of the mailing l= ist on this.=0A=0AJon=0A=0A=0A=0A=0A=0A________________________________=0A = From: Joseph Macker =0ATo: JP Vasseur (jvasseur) =0ACc: Timothy J. Salo ; "manet@ietf.org" = =0ASent: Saturday, November 3, 2012 9:14 AM=0ASubject: Re:= [manet] LOADng works=0A =0A=0AAgain I would ask that we move ROLL and LLN = discussions to ROLL if people want to continue.=0AJP your opinion to the WG= chairs is pretty obvious.=0A=0AWe need some bandwidth to discuss quality o= f documents and authors agreement to various other WG issues.=0AI will prov= ide some questions to that effect shortly. Let us focus on our WG's challen= ges.=0A=0A-Joe=0A=0A=0A=0A=0AOn Sat, Nov 3, 2012 at 4:32 AM, JP Vasseur (jv= asseur) wrote:=0A=0A=0A>=0A>On Nov 2, 2012, at 7:29 PM= , Ulrich Herberg wrote:=0A>=0A>C=E9dric,=0A>>=0A>>=0A>>On Fri, Nov 2, 2012 = at 4:19 PM, C Chauvenet wrote:=0A>>=0A>>[...] =0A= >>>>=0A>>>>=0A>>>>Right, but that "proof" was never published by the IETF, = and as such only an assertion. Moreover, we are not the ROLL WG.=0A>>>=0A>>= >=0A>>>I think=A0http://tools.ietf.org/html/draft-ietf-roll-protocols-surve= y-07=A0is such a publication.=0A>>=0A>>=0A>>That is the draft I was talking= about. It is *not* a publication. It was never published by the IETF, even= though some claim it is a publication.=0A>=0A>=0A>JP> If you are "picky" a= bout IETF document state, you should then propose to select *the* MANET wor= king group document as a base: DYMO.=0A>=0A>=0A>=A0=0A>>=0A>>=0A>>BTW, it c= overs AODV and DYMO, and explains why it does not match general LLN require= ments (and so for any AODV-based protocols such as LOADng).=0A>>=0A>>=0A>>= =0A>>=0A>>The document was rejected for a reason. It is heavily flawed and = misleading, in my opinion.=0A>>=A0=0A>>=0A>>=0A>>=0A>>>=0A>>>But I agree th= at this is MANET list, so this should not be the place to debate RPL here.= =0A>>=0A>>=0A>>Right.=0A>>=0A>>=0A>>=A0=0A>>I think ROLL-ers came in the di= scussion because LOADng authors explicitly states that they want to use LOA= Dng in LLNs, that is ROLL working space. =0A>>=0A>>=0A>>And if that one wor= d in the introduction is the whole reason why you prefer DYMO over LOADng, = it is a pretty weak argument.=A0=0A>>And again, you cannot dispute the fact= that LOADng is used in such deployments. You may not like it, for business= or other reasons, but it's a fact.=0A>>=0A>>=0A>>=A0=0A>>Though, I think y= ou agree that LOADng will not match general LLN requirements and be limited= to specific low traffic deployment.=0A>>=A0=0A>>=0A>>=0A>>I agree that LOA= Dng (or DYMO for that matter) will not be suitable for all LLN deployments.= But it is, as a matter of fact, used in some such deployments. =0A>=0A>=0A= >JP> Do you know how proprietary or non IETF standards are used in the file= d for that matter ?=0A>The IETF is not here to standardize protocols used i= n the field because they have been chosen in some deployment.=0A>=0A>=0A>RP= L also does not fulfill all requirements of all kinds of LLNs, in my opinio= n, but that's another matter not to be discussed here.=0A>>=0A>>=0A>>Best= =0A>>Ulrich=0A>>=0A>>=0A>>=0A>>=0A>>=A0=0A>>=0A>>>=0A>>>C=E9dric.=0A>>>=0A>= >>=0A>>>=A0=0A>>>>=0A>>>>>Could then prove that the current protocol cannot= be used in your environment before suggesting=0A>>>>>to standardize a new = one.=0A>>>>>=0A>>>>>Once again, if not applicable to LLNs, I have no proble= m whatsoever.=0A>>>>>=0A>>>>=A0=0A>>>>=0A>>>>=0A>>>>People have deployed re= active protocols as a matter of fact in LLNs. So, is the only reason why yo= u like DYMO and not LOADng, because LOADng mentions the word LLN once in th= e introduction?=0A>>>>=0A>>>>=0A>>>>Best regards=0A>>>>Ulrich=0A>>>>=0A>>>>= =0A>>>>=A0=0A>>>>=0A>>>>>> If fact, the LOADng deployment experience strong= ly=0A>>>>>> suggests that reactive routing protocols _will_ be deployed in= =0A>>>>>> some LLNs. =A0And, they will be deployed regardless of the ROLL= =0A>>>>>> working group's decision to not standardize a reactive routing=0A= >>>>>> protocol.=0A>>>>>=0A>>>>>=0AJP> And this is perfectly fine, people a= re free to use any protocol they want, including proprietary=0A>>>>>ones. T= his does not mean that the IETF should standardize them.=0A>>>>>=0A>>>>>=0A= >>>>>>=0A>>>>>> Claiming that reactive routing protocols don't work because= they=0A>>>>>> don't scale to higher traffic loads seems,=0A>>>>>=0A>>>>>= =0AJP> Then we need to characterize precisely the limits.=0A>>>>>=0A>>>>>= =0A>>>>>> at best, a poor=0A>>>>>> characterization of well-known research = results, and at worst=0A>>>>>> a distraction from the question at hand: nam= ely how to proceed=0A>>>>>> towards an Internet-standard reactive routing p= rotocol.=0A>>>>>>=0A>>>>>> -tjs=0A>>>>>=0A>>>>>____________________________= ___________________=0A>>>>>manet mailing list=0A>>>>>manet@ietf.org=0A>>>>>= https://www.ietf.org/mailman/listinfo/manet=0A>>>>>=0A>>>>_________________= ______________________________=0A>>>>manet mailing list=0A>>>>manet@ietf.or= g=0A>>>>https://www.ietf.org/mailman/listinfo/manet=0A>>>>=0A>>>=0A>>=0A>= =0A>_______________________________________________=0A>manet mailing list= =0A>manet@ietf.org=0A>https://www.ietf.org/mailman/listinfo/manet=0A>=0A>= =0A=0A_______________________________________________=0Amanet mailing list= =0Amanet@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/manet --1886287700-1479226928-1351958977=:23565 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Oops should have read= this first before my previous replies.

I agree.  My opinion is= also obvious.  (I will attempt to be quiet...)

We've heard fro= m 6 or 7 of the same people, where is the rest of the mailing list on this.=

Jon



From: Joseph Macke= r <jpmacker@gmail.com>
To:<= /span> JP Vasseur (jvasseur) <jvasseur@cisco.com>
Cc: Timothy J. Salo <salo@saloits.= com>; "manet@ietf.org" <manet@ietf.org>
Sent: Saturday, November 3, 2012 9:14 AM
Subject: Re: [manet] LOADng works

=0A
Again I would ask that we move ROLL and L= LN discussions to ROLL if people want to continue.
JP your opinion to th= e WG chairs is pretty obvious.

We need some bandwidth to discuss qua= lity of documents and authors agreement to various other WG issues.
=0AI= will provide some questions to that effect shortly. Let us focus on our WG= 's challenges.

-Joe

On Sat, Nov 3, 2012 at 4:32 AM, JP= Vasseur (jvasseur) <jvasseur@cisco.com> wrote:
=0A
=0A=0A=0A=0A
=0A
= =0A
=0A
On Nov 2, 2012, at 7:29 PM, U= lrich Herberg wrote:
=0A
=0A
C=E9dric,
= =0A
=0A
On Fri, Nov 2, 2012 at 4:1= 9 PM, C Chauvenet =0A<c.chauvenet@watteco.com> wrote:
=0A=0A
= =0A
=0A
=0A
=0A
=0A
=0A
=0A=0A
[...]
=0A

=0A=0A
Right, but that "proof" was never published by the IETF, and as s= uch only an assertion. Moreover, we are not the ROLL WG.
=0A
=0A<= /blockquote>=0A

=0A
=0A
=0A
=0A
I think htt= p://tools.ietf.org/html/draft-ietf-roll-protocols-survey-07 is such a = publication.
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
That is the draft I was talking about. It is *not* = a publication. It was never published by the IETF, even though some claim i= t is a publication.
=0A
=0A
=0A

=0A
=0A<= /div>
JP> If you are "picky" about IETF document state, you should t= hen propose to select *the* MANET working group document as a base: DYMO.
=0A
=0A
=0A=0A
 
=0A

=0A=0A
=0A
=0A
=0A
=0A
=0A
BTW, it covers AODV and DYMO= , and explains why it does not match general LLN requirements (and so for a= ny AODV-based protocols such as LOADng).
=0A
=0A
=0A
= =0A
=0A
=0A

=0A
=0A

=0A
=0A
= The document was rejected for a reason. It is heavily flawed and misleading= , in my opinion.
=0A
 
=0A

=0A
=0A=0A
= =0A
=0A
=0A
=0A

=0A
=0A
But I agree that this = is MANET list, so this should not be the place to debate RPL here.
=0A=
=0A
=0A
=0A
=0A
=0A

=0A
=0ARight.
=0A

=0A
=0A
 
=0A
=0A
=0A=0A
=0A
=0A
I think ROLL-ers came in the discussion because LO= ADng authors explicitly states that they want to use LOADng in LLNs, that i= s ROLL working space.=0A
=0A
=0A
=0A
=0A
=0A=0A

=0A
=0A
And if that one word in the introductio= n is the whole reason why you prefer DYMO over LOADng, it is a pretty weak = argument. 
=0A
And again, you cannot dispute the fact that LO= ADng is used in such deployments. You may not like it, for business or othe= r reasons, but it's a fact.
=0A

=0A
=0A
 
= =0A
=0A
=0A
=0A
=0A
=0A
Though, I think you agree that = LOADng will not match general LLN requirements and be limited to specific l= ow traffic deployment.
=0A
=0A
=0A
=0A
=0A=0A
 
=0A

=0A
=0A
I agree that LOADng (= or DYMO for that matter) will not be suitable for all LLN deployments. But = it is, as a matter of fact, used in some such deployments.=0A
=0A=0A
=0A

=0A
=0A
JP> Do you know how = proprietary or non IETF standards are used in the filed for that matter ?=0A
The IETF is not here to standardize protocols used in the field= because they have been chosen in some deployment.
=0A

=0A
=0A
=0A
=0A
RPL also does not fulfill all requ= irements of all kinds of LLNs, in my opinion, but that's another matter not= to be discussed here.
=0A

=0A
=0A
Best
=0A
= Ulrich
=0A

=0A
=0A

=0A
=0A
 
= =0A
=0A
=0A
=0A
=0A
=0A

=0A
=0A
C=E9dric.<= /div>=0A
=0A

=0A
=0A
=0A
 
=0A
=0A
=0ACould then prove that the current protocol cannot be= used in your environment before suggesting
=0Ato standardize a new one.=
=0A
=0AOnce again, if not applicable to LLNs, I have no problem what= soever.
=0A
=0A
 
=0A

=0A
=0APeople have deployed reactive protocols as a matter of fact in LLNs. So, i= s the only reason why you like DYMO and not LOADng, because LOADng mentions= the word LLN once in the introduction?
=0A

=0A
=0A
B= est regards
=0A
Ulrich
=0A

=0A
=0A
 =0A
=0A

=0A> If fa= ct, the LOADng deployment experience strongly
=0A> suggests that reac= tive routing protocols _will_ be deployed in
=0A> some LLNs.  An= d, they will be deployed regardless of the ROLL
=0A> working group's = decision to not standardize a reactive routing
=0A> protocol.
=0A<= br>=0A
=0AJP> And this is perfectly fine, people are free to use an= y protocol they want, including proprietary
=0Aones. This does not mean = that the IETF should standardize them.
=0A

=0A>
=0A> Cl= aiming that reactive routing protocols don't work because they
=0A> d= on't scale to higher traffic loads seems,
=0A
=0A
=0AJP> Then= we need to characterize precisely the limits.
=0A
=0A

=0A&g= t; at best, a poor
=0A> characterization of well-known research resul= ts, and at worst
=0A> a distraction from the question at hand: namely= how to proceed
=0A> towards an Internet-standard reactive routing pr= otocol.
=0A>
=0A> -tjs
=0A
=0A___________________________= ____________________
=0Amanet mailing list
=0Amanet@ietf.org
=0Ahttps://www.ietf.org/mailman/= listinfo/manet
=0A
=0A
=0A
=0A
=0A
=0A= _______________________________________________
=0Amanet mailing list=0Amanet@ietf.org
=0Aht= tps://www.ietf.org/mailman/listinfo/manet
=0A
=0A
= =0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A
=0A=0A
___= ____________________________________________
=0Amanet mailing list
= =0Amanet@ietf.org
=0Ahtt= ps://www.ietf.org/mailman/listinfo/manet
=0A
<= br>
=0A

_______________________________________________
manet mailing list=
man= et@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--1886287700-1479226928-1351958977=:23565-- From jblack.ietf@yahoo.com Sat Nov 3 09:12:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956CF21F9C9A for ; Sat, 3 Nov 2012 09:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if6B6sSLlA0f for ; Sat, 3 Nov 2012 09:12:37 -0700 (PDT) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 09D2F21F9C87 for ; Sat, 3 Nov 2012 09:12:36 -0700 (PDT) Received: from [98.139.212.145] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 16:12:36 -0000 Received: from [98.139.212.231] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 16:12:36 -0000 Received: from [127.0.0.1] by omp1040.mail.bf1.yahoo.com with NNFMP; 03 Nov 2012 16:12:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 599506.4580.bm@omp1040.mail.bf1.yahoo.com Received: (qmail 13706 invoked by uid 60001); 3 Nov 2012 16:12:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351959156; bh=KBb04SNKvftCxD7EBAJANjQeOCTHa1s+b7r6KTvfwd4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HceLPODxN+kZ/p+3of15GL2MFAJ0F4KBVCK8S//WnQnuxfqTmATMrtWPHtOwQNJGHcKDRulsK1vQ1vqMvGDbCOBsjx8FHSCUobzNkT2eE5BpoSkkEQV3XYrsagTDzWz2ZPU7ig/XPKzMWPSAFGeNkOObFxmdftNHSLpQxYK9HOQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=vavSTXvSbDQyyH13MlltUQgApR1rpzeonv2afV9kO7/MA2L3LEmhSatWpbQ9K4sSCALjviyYqlTnys4y4d1E0dAhjKIXein54XDkIAI5NJryjsDsW0BEn6WrGEPSzNsEF3s1YFHwSsKmarXbcfi5i/MUg5LfIIj1aTKcwLeozns=; X-YMail-OSG: AJ82_d4VM1mraOscHMZBKzbUTkxWKvbcstl8.8DjVSndNH2 gfQ2LrdNPdO7HAJimqZdHt3uvaoM.zc1vj16SoTqC7sdBUwKFOtuuSYOnorh xDt52D3iNaqPIF8AnClPPfDTrJpCscE5TXWct5uvV2N3b.Lypo51EYvj4rv7 zs90qe9dQPsCuyXvOn1Kcwc.ru8JA8N2Le30ltB0UWLkThyCTBfuRvDyuE_H dVafCYSe.7K2VO6qijPkjEsrjJnule1DXyLgjLPLErh4sbMuZEfiNCTi.ebY TJtoMTO.0wznBAOPOrUNzi6TVRuvAla8.qBD58PZkXF6uxw4odLzzyJ4IoFe YQRqC4FSgNHDuhUF9E_UYO4tf.RUlvlwFgyHLIUZDQRfZpwfqSRMSfEy18zQ .qiGXPDIOH1Ha.phwNIvilzsc0Y7AcJeNZ0JYW8qwq.y7ThEfnfvu5DbMERi CsXM.qw-- Received: from [67.213.218.72] by web160602.mail.bf1.yahoo.com via HTTP; Sat, 03 Nov 2012 09:12:36 PDT X-Rocket-MIMEInfo: 001.001, TGFzdCBtZXNzYWdlIG9uIHRoaXMgcmVhbGx5Li4uwqAgCgpKUCAtIHJlcGx5aW5nIHRvIHlvdXIgc3RhdGVtZW50cyBhdHRhY2tpbmcgbXkgbWVzc2FnZSBpcyBoYXJkbHkgcG9sZW1pYy4KCkpvbgoKCgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogSlAgVmFzc2V1ciAoanZhc3NldXIpIDxqdmFzc2V1ckBjaXNjby5jb20.ClRvOiBKb24gQmxhY2sgPGpibGFjay5pZXRmQHlhaG9vLmNvbT4gCkNjOiBVbHJpY2ggSGVyYmVyZyA8dWxyaWNoQGhlcmJlcmcubmFtZT47ICJtYW5ldEABMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <1351889394.5207.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204D666@xmb-rcd-x02.cisco.com> <1351957335.1256.YahooMailNeo@web160603.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204E594@xmb-rcd-x02.cisco.com> Message-ID: <1351959156.13550.YahooMailNeo@web160602.mail.bf1.yahoo.com> Date: Sat, 3 Nov 2012 09:12:36 -0700 (PDT) From: Jon Black To: "JP Vasseur \(jvasseur\)" In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204E594@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1725615817-435127792-1351959156=:13550" Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 16:12:38 -0000 ---1725615817-435127792-1351959156=:13550 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Last message on this really...=C2=A0 =0A=0AJP - replying to your statements= attacking my message is hardly polemic.=0A=0AJon=0A=0A=0A=0A=0A=0A=0A_____= ___________________________=0A From: JP Vasseur (jvasseur) =0ATo: Jon Black =0ACc: Ulrich Herberg ; "manet@ietf.org" =0ASent: Saturday, Novembe= r 3, 2012 9:57 AM=0ASubject: Re: [manet] Reactive Protocol Situation=0A =0A= =0ALet's follow the directions stated by Joe. Stop the polemics. Hoping to = SEE you for a technical discussion. =0A=0A=0AOn Nov 3, 2012, at 11:42 AM, J= on Black wrote:=0A=0AWhat you contend is that a reactive protocol cannot be= used in an LLN (Just plain wrong, but that isn't this discussion.=C2=A0 Yo= u derailed the discussion bringing it to that.)=C2=A0 But that isn't the is= sue before the group.=0A>=0A>You have no substantive technical arguments on= why we should proceed with DYMO rather than LOADng.=0A>=0A>it appears you = only real objection to the LOADng draft is the name and that it suggests th= at it can be used in LLNs.=C2=A0 Your acceptance of the DYMO draft is not a= t all technical. [Your concerns about LOADng used in LLNs apply equally to = DYMO, so there is no technical=0A argument between moving forward with DYMO= or LOADng].=C2=A0 You accept DYMO because the current draft does not indic= ate that it can be used in an LLN.=0A>=0A>You don't like the name and you d= on't like that the authors indicated it could be used in some LLN applicati= ons (which it can).=0A>=0A>I and other have said that the current state of = the draft is that the DYMO draft needs a lot of major work and things have = to cut down to generate a draft that is implementable.=C2=A0 We have said t= hat the LOADng draft appears to be closer to stable, is implementable=0A (t= here are multiple implementations) but still needs working group input to c= omplete.=0A>=0A>Any discussion of if a reactive protocol could be or should= be used in an LLN can be taken to ROLL for now and into the market.=0A>=0A= >This discussion should be about the differences in the drafts (which Ulric= h has pointed out) and only that so that we can find the best starting poin= t.=0A>=0A>If you have specific points in the differences between the drafts= bring them up.=0A>=0A>We now know you don't like the name and the paragrap= h about LLNs=0A>=0A>Jon=0A>=0A>=0A>=0A>=0A>=0A>=0A>________________________= ________=0A> From: JP Vasseur (jvasseur) =0A>To: Jon Bl= ack =0A>Cc: Ulrich Herberg ; "= manet@ietf.org" =0A>Sent: Saturday, November 3, 2012 2:10 = AM=0A>Subject: Re: [manet] Reactive Protocol Situation=0A>=0A>=0A>Hi "Jon" = =0A>=0A>=0A>You can keep ignoring what I am writing =E2=80=A6 but this does= not help. The issue is not "this" paragraph - I explained why a number of = times.=0A>And proposed a way to go, call it option 1.5.=0A>=0A>=0A>On Nov 2= , 2012, at 4:49 PM, Jon Black wrote:=0A>=0A>From: JP Vasseur (jvasseur) =0A>>=0A>>On Nov 2, 2012, at 11:08 AM, Ulrich Herberg wrot= e:=0A>>=0A>>I think one key point to stress is one that Chris mentioned:=0A= >>>Both protocols are similar in their operation and performance. So anyone= arguing against the performance of LOADng is automatically also not intere= sted in DYMO. =0A>>>=0A>>>=0A>>=0A>>=0A>>See my point Ulrich =E2=80=A6 and = I wrote it down several times. There are major concerns in using Load-ng wi= th LLNs. Quoting Load-ng:=0A>>=0A>>=0A>>3. Applicability Statement This pr= otocol: o Is a reactive routing protocol for Mobile Ad hoc NETworks (MANET= s). o Is designed to work in networks with dynamic topology in which the l= inks may be lossy due to collisions or unstable channel. The use cases inc= lude vehicular networks, low power and lossy networks, community networks, = military networks, disaster recovery networks, etc. =0A>>=0A>>=0A>>This is = where I strongly object, as several other ones on this mailing list. One ca= nnot simply forget 4-5 years of hard work from a WG that focussed=C2=A0=0A>= >on this use case=C2=A0and concluded that such protocol is not applicable t= o LLNs.=0A>>=0A>>=0A[Jon] Is that your true objection to the LOADng draft.= =C2=A0 Then I would think the simple solution is to remove this one paragra= ph and move on.=C2=A0 =0A>>Developers will=C2=A0 decide what protocols are = applicable to their application as they should - as I will.=0A>>I will ask = in ROLL where the conclusion was drawn that you cannot possibly use a react= ive protocol in any LLN application.=C2=A0 That is for a discussion in ROLL= not here.=0A>>Again if this one paragraph is all the fuss then lets please= reach consensus to remove this and move forward.=C2=A0 Gosh that seems sim= ple.=0A>>=0A>>Jon=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>However, LOADng is far close= r to become an RFC in terms of the document quality. If we start the new re= active protocol on the basis of the LOADng draft (and I personally don't ca= re what we name that protocol is), we can continue the work on the reactive= protocol together and discuss the multiple options that are currently in D= YMO and see whether they should be discarded, put into a companion document= or in the core spec. =0A>>>=0A>>>Best=0A>>>Ulrich=0A>>>=0A>>>On Nov 2, 201= 2, at 7:54, Yuichi IGARASHI wrote:=0A>>>= =0A>>>=0A>>>Hi,=0A>>>>=0A>>>=0A>>>>=0A>>>I agree with Martin and I would su= pport option 2) at this stage.=0A>>>>=0A>>>=0A>>>>=0A>>>We LOADng co-author= s made efforts to simplify core specification of the reactive protocol and = to improve the readability of the draft. I think this approach is important= not only for all implementor to shorten the development time, but also for= business operators to make multi-vendor system easier to provide. Of cours= e, I agree that, as several persons pointed out, "this draft" may limit use= case. But we leave sufficient space for improving performance/adding funct= ions by companion drafts.=0A>>>>=0A>>>=0A>>>>=0A>>>I am really concerned ab= out complexity/difficulty of guaranteeing of interoperability. If the proto= col becomes complicated, we need much time(many years?) for interoperabilit= y test. I think we should consider both time required for merging drafts an= d shape of document.=0A>>>>=0A>>>=0A>>>>=0A>>>Best regards,=0A>>>>=0A>>>Yui= chi=0A>>>>=0A>>>(2012/11/02 23:01), Martin Heusse wrote:=0A>>>>=0A>>>=0A>>>= >>=0A>>>I'm standing for option 2 (LOADng).=0A>>>>>=0A>>>=0A>>>>>=0A>>>I th= ink it's better to agree first on a simple basic (versatile?) protocol befo= re proposing extensions to it; instead of starting from a collection of ide= as that can be used or not (and we know today what are the options, thank t= o the huge amount of work done on reactive routing during the past years). = Conversely, it would be certainly easier to reach a consensus on a set of v= ariants but we need a good reference point, first.=0A>>>>>=0A>>>=0A>>>>>=0A= >>>Moreover, reactive routing is most probably the approach that one would = pick for a simple case. So it should be simple...=0A>>>>>=0A>>>=0A>>>>>=0A>= >>Martin=0A>>>>>=0A>>>=0A>>>>>=0A>>>=0A>>>>>=0A>>>Le 2 nov. 2012 =C3=A0 01:= 58, Joydeep Tripathi a =C3=A9crit :=0A>>>>>=0A>>>=0A>>>>>=0A>>>I can unders= tand that for an LLN it may be beneficial for not maintaining a precursor l= ist or having only the destination reply t o a RREQ, there can be (and are)= other instances of MANETs where having the option of precursor list will c= ome handy. This can save on control overhead, using some storage space in t= he node. LOAD-ng, in most cases does not provide this flexibility to the de= veloper to chose between options for specific deployment. Some MANET deploy= ment may be less harsh than others in nature. Hence, AODVv2 having more ope= n options than LOAD-ng, in most cases, seem beneficial to me.=0A>>>>>>=0A>>= >=0A>>>>>=0A>>>_______________________________________________=0A>>>>>=0A>>= >manet mailing list=0A>>>>>=0A>>>manet@ietf.org=0A>>>>>=0A>>>https://www.ie= tf.org/mailman/listinfo/manet=0A>>>>>=0A>>>=0A>>>>>=0A>>>=0A>>>>=0A>>>-- = =0A>>>>=0A>>>Hitachi, Ltd., Yokohama Research Laboratory=0A>>>>=0A>>>IGARAS= HI Yuichi=0A>>>>=0A>>>Mail=EF=BC=9A yuichi.igarashi.hb@hitachi.com=0A>>>>= =0A>>>Tel =EF=BC=9A +81-(0)45-860-3083=0A>>>>=0A>>>FAX =EF=BC=9A +81-(0)45-= 860-1673=0A>>>>=0A>>>_______________________________________________=0A>>>>= =0A>>>manet mailing list=0A>>>>=0A>>>manet@ietf.org=0A>>>>=0A>>>https://www= .ietf.org/mailman/listinfo/manet=0A>>>>=0A_________________________________= ______________=0A>>>manet mailing list=0A>>>manet@ietf.org=0A>>>https://www= .ietf.org/mailman/listinfo/manet=0A>>>=0A>>=0A>>___________________________= ____________________=0A>>manet mailing list=0A>>manet@ietf.org=0A>>https://= www.ietf.org/mailman/listinfo/manet=0A>>=0A>>=0A>>=0A>=0A>=0A> ---1725615817-435127792-1351959156=:13550 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Last message on this = really... 

JP - replying to your statements attacking my messa= ge is hardly polemic.

Jon




From: JP Vasseur (jvasseur) <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.co= m>
Cc: Ulrich Herbe= rg <ulrich@herberg.name>; "manet@ietf.org" <manet@ietf.org> Sent: Saturday, November= 3, 2012 9:57 AM
Subject: Re: [mane= t] Reactive Protocol Situation

=0A
=0A= =0A =0A=0A
=0ALet's follow the directions stated by Joe. Stop the polem= ics. Hoping to SEE you for a technical discussion.=0A

=0A
=0AOn Nov 3, 2012, at 11:42 AM, Jon Black wrote:
=0A
=0A
=0A
=0A=
=0AWhat you contend is that a reac= tive protocol cannot be used in an LLN (Just plain wrong, but that isn't th= is discussion.  You derailed the discussion bringing it to that.) = ; But that isn't the issue before the group.
=0A
=0AYou have no subst= antive technical arguments on why we should proceed with DYMO rather than L= OADng.
=0A
=0Ait appears you only real objection to the LOADng draft = is the name and that it suggests that it can be used in LLNs.  Your ac= ceptance of the DYMO draft is not at all technical. [Your concerns about LO= ADng used in LLNs apply equally to DYMO, so there is no technical=0A argume= nt between moving forward with DYMO or LOADng].  You accept DYMO becau= se the current draft does not indicate that it can be used in an LLN.
= =0A
=0AYou don't like the name and you don't like that the authors indic= ated it could be used in some LLN applications (which it can).
=0A
= =0AI and other have said that the current state of the draft is that the DY= MO draft needs a lot of major work and things have to cut down to generate = a draft that is implementable.  We have said that the LOADng draft app= ears to be closer to stable, is implementable=0A (there are multiple implem= entations) but still needs working group input to complete.
=0A
=0AAn= y discussion of if a reactive protocol could be or should be used in an LLN= can be taken to ROLL for now and into the market.
=0A
=0AThis discus= sion should be about the differences in the drafts (which Ulrich has pointe= d out) and only that so that we can find the best starting point.
=0A=0AIf you have specific points in the differences between the drafts bring= them up.
=0A
=0AWe now know you don't like the name and the paragrap= h about LLNs
=0A
=0AJon
=0A

=0A
=0A
=
=0A
=0A
=0A
=0A
=0A
=0AFrom:= JP Vasseur (jvasseur) <j= vasseur@cisco.com>
=0ATo: Jon Black <jblack.iet= f@yahoo.com>=0A
=0ACc: Ulrich Herberg <ulrich@herbe= rg.name>; "manet@ietf.org" <manet@ietf.org>=0A
=0ASent: Saturday, November 3, 2012 2:10 AM
=0A= Subject: Re: [manet] Reacti= ve Protocol Situation
=0A
=0A
=0A =0A
=0A
Hi "Jon"=0A

=0A
=0A
You can keep ignoring wh= at I am writing =E2=80=A6 but this does not help. The issue is not "this" p= aragraph - I explained why a number of times.
=0A
And proposed a w= ay to go, call it option 1.5.
=0A

=0A
=0A
On Nov 2, 20= 12, at 4:49 PM, Jon Black wrote:
=0A
=0A
=0A
=0A
=0A
From: JP Vasseur (jvasseur) <jvasseur@cisco.com>
=0A
=0AOn Nov 2= , 2012, at 11:08 AM, Ulrich Herberg wrote:
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
I think one key point to stress is one that Chris mentioned:
= =0ABoth protocols are similar in their operation and performance. So anyone= arguing against the performance of LOADng is automatically also not intere= sted in DYMO.=0A
=0A
=0A
=0A
=0A

=0A
=0A
See my point = Ulrich =E2=80=A6 and I wrote it down several times. There are major concern= s in using Load-ng with LLNs. Quoting Load-ng:
=0A

=0A
=0A
=0A
3.  Appl=
icability Statement
=0A=0A   This protocol:=0A=0A   o  Is a reac=
tive routing protocol for Mobile Ad hoc NETworks=0A      (MANETs).=0A=0A   =
o  Is designed to work in networks with dynamic topology in which the=0A   =
   links may be lossy due to collisions or unstable channel.  The use=0A   =
   cases include vehicular networks, low power and lossy networks,=0A      =
community networks, military networks, disaster recovery networks,=0A      =
etc.=0A
=0A

=0A
=0A
This is where I strongly object, = as several other ones on this mailing list. One cannot simply forget 4-5 ye= ars of hard work from a WG that focussed 
=0A
on this use cas= e and concluded that such protocol is not applicable to LLNs.
=0A=0A
=0A
=0A[Jon] Is that your true objection to the LOADng draf= t.  Then I would think the simple solution is to remove this one parag= raph and move on. =0A
=0ADevelopers will  decide what protocol= s are applicable to their application as they should - as I will.
=0AI w= ill ask in ROLL where the conclusion was drawn that you cannot possibly use= a reactive protocol in any LLN application.  That is for a discussion= in ROLL not here.
=0AAgain if this one paragraph is all the fuss then l= ets please reach consensus to remove this and move forward.  Gosh that= seems simple.
=0A
=0AJon
=0A
=0A

=0A
=0A
= =0A
=0A

=0A
=0A
=0A
However, LOADng is far= closer to become an RFC in terms of the document quality. If we start the = new reactive protocol on the basis of the LOADng draft (and I personally do= n't care what we name that protocol is), we can continue the work on the re= active=0A protocol together and discuss the multiple options that are curre= ntly in DYMO and see whether they should be discarded, put into a companion= document or in the core spec.=0A
=0A
=0ABest
=0AUlrich
=0A
= =0AOn Nov 2, 2012, at 7:54, Yuichi IGARASHI <yuichi.igarashi.hb@hitachi.com> wro= te:
=0A
=0A
Hi,
=0A
=0A
=0A
=0A
I agre= e with Martin and I would support option 2) at this stage.
=0A=0A

=0A
=0A
We LOADng co-authors made efforts to simplify core specification of t= he reactive protocol and to improve the readability of the draft. I think t= his approach is important not only for all implementor to shorten the devel= opment time, but=0A also for business operators to make multi-vendor system= easier to provide. Of course, I agree that, as several persons pointed out= , "this draft" may limit use case. But we leave sufficient space for improv= ing performance/adding functions by companion drafts.
=0A
= =0A

=0A
=0A
I am really concerned about complexity/difficulty of guaranteeing of int= eroperability. If the protocol becomes complicated, we need much time(many = years?) for interoperability test. I think we should consider both time req= uired for merging=0A drafts and shape of document.
=0A
=0A
=0A
=0A
Be= st regards,
=0A
=0A
Yuichi
=0A=0A
(2012/11/02 23:01), Martin Heusse w= rote:
=0A
=0A
=0A

=0A
=0A
=0A
= =0A
I'm standing for option 2 (LOADng).
=0A=0A
=0A
=0A

=0A
=0A
=0A
= =0A
I think it's better to agree first on a simple= basic (versatile?) protocol before proposing extensions to it; instead of = starting from a collection of ideas that can be used or not (and we know to= day what are the options, thank to the=0A huge amount of work done on react= ive routing during the past years). Conversely, it would be certainly easie= r to reach a consensus on a set of variants but we need a good reference po= int, first.
=0A
=0A
=0A
=0A

=0A
=0A
=0A=0A
Moreover, reactive routing= is most probably the approach that one would pick for a simple case. So it= should be simple...
=0A
=0A
=0A
=0A

=0A
=0A
= =0A
=0A
Martin
=0A=0A
=0A
=0A

=0A
=0A
=0A
= =0A

=0A
=0A
=0A=0A
Le 2 nov. 2012 =C3=A0 01:58= , Joydeep Tripathi a =C3=A9crit :
=0A
=0A
=0A=0A

=0A
=0A=
=0A
=0A
=0A<= blockquote type=3D"cite">I can understand that for an LLN it may be benefic= ial for not maintaining a precursor list or having only the destination rep= ly t o a RREQ, there can be (and are) other instances of MANETs where havin= g the option of precursor list will=0A come handy. This can save on control= overhead, using some storage space in the node. LOAD-ng, in most cases doe= s not provide this flexibility to the developer to chose between options fo= r specific deployment. Some MANET deployment may be less harsh than others= =0A in nature. Hence, AODVv2 having more open options than LOAD-ng, in most= cases, seem beneficial to me.
=0A
=0A
=0A=0A
=0A

=0A=0A
=0A
=0A
_______________________________________________
=0A=0A
=0A
=0A
manet mailing list
=0A
=0A
=0A
=0A
manet@ie= tf.org
=0A
=0A
=0A
= =0A
https://www.ietf.org/mailman/l= istinfo/manet
=0A
=0A
=0A
=0A

=0A
=0A
=0A=

=0A
=0A
= --
=0A
=0A
Hitachi, Ltd., Yokohama= Research Laboratory
=0A
=0A
IGARAS= HI Yuichi
=0A
=0A
Mail=EF=BC=9A =0Ayuichi.igaras= hi.hb@hitachi.com
=0A
=0A
Tel = =EF=BC=9A +81-(0)45-860-3083
=0A
=0A
FAX =EF=BC=9A +81-(0)45-860-1673
=0A
=0A
_______________________________________________
=0A=0A
manet mailing list
=0A
=0Amanet@ietf.org
= =0A
=0A
https://www.ie= tf.org/mailman/listinfo/manet
=0A
=0A___________________= ____________________________
=0Amanet mailing list
=0Amanet@ietf.org
=0Ahttps://www.ietf.org/= mailman/listinfo/manet
=0A
=0A
=0A
=0A
=0A<= /div>=0A
=0A
=0A_______________________________________________
= =0Amanet mailing list
=0Amanet@ietf.org<= br>=0Ahttps://www.ietf.org/mailman/listinfo/manet
= =0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
= =0A
=0A
=0A
=0A
=0A =0A
=0A
=0A
=0A=0A=0A=0A=0A=0A
=0A=0A=0A=0A=

= ---1725615817-435127792-1351959156=:13550-- From philip.levis@gmail.com Sat Nov 3 09:40:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E090221F955F for ; Sat, 3 Nov 2012 09:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2qUTtAcOi3i for ; Sat, 3 Nov 2012 09:40:50 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 65EA821F930A for ; Sat, 3 Nov 2012 09:40:50 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so3069842pad.31 for ; Sat, 03 Nov 2012 09:40:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dmYFTKAG8vyfS43629Myo3aQDWLt4w5PuqJpyL9Yrjg=; b=pRYBxoyP7Y0T9JnZxkmS1YBP5rSa0F1IvkBKVQkNA8xwqgvSrbnyNreqozJvC795T0 S1Aaffk8uY4u0mZgG6SVHylSwtin03QnfznJSZak/Gby7hRuaG9COaBdIr5MgpZ8FaX3 ThF3iVV+sEqId4hBIoHM+ufcAagzBFGMTk0DnrFwgEjewxAITljmvY5qVtt/QAt22h8W fPDst0oHjapE22jyvJolFc/vfemJIgdwjQoCG6jdZ2eChkLJRT2sky8lNfaeSHusZ74F VTAGX6Zm0fjQUiMfBQCPXL6mkgWwPZDSzWjBXsLIPfD7ewGQIXfwNljJ/GGcFxF25tXo jAUQ== Received: by 10.66.84.131 with SMTP id z3mr15165898pay.34.1351960850238; Sat, 03 Nov 2012 09:40:50 -0700 (PDT) Received: from [192.168.0.106] ([76.14.66.110]) by mx.google.com with ESMTPS id us7sm7602134pbc.40.2012.11.03.09.40.48 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 03 Nov 2012 09:40:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: <5093EF93.70201@saloits.com> Date: Sat, 3 Nov 2012 09:40:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5E3CC77A-4FA1-4C15-9536-306917AA8B13@gmail.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> To: Timothy J. Salo X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Sat, 03 Nov 2012 11:00:45 -0700 Cc: "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 16:40:51 -0000 On Nov 2, 2012, at 9:06 AM, Timothy J. Salo wrote: >=20 > We've known for at least 15 years that reactive routing protocols are > more appropriate for light traffic loads and that proactive routing > protocols are more appropriate with heavier traffic loads. Dozens, > probably hundreds of research papers have reiterated this result. > I don't know of any that have contradicted this result, although > some researchers have tried to develop hybrid routing protocols > (which don't seem to have gained much traction, either in the IETF > or elsewhere). Timothy, I agree with your conclusion for MANETs. For LLNs, it's a bit more = complicated, due to the "low power" part. You see this tension in RPL, = where on one hand it's mostly proactive (continually maintains a = topology) but on the other it has reactive elements (datapath = validation, adaptive beaconing). The basic idea is that you make an = educated guess for a good route based on old information and fix it as = needed, rather than throw all that old information away and start from = scratch. But the community that researched LLN protocols in the 2000s = didn't generally come from a MANET background so didn't see such a hard = boundary between reactive and proactive solutions. Just my 2c, Phil From hrogge@googlemail.com Sat Nov 3 11:47:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8303221F9C34 for ; Sat, 3 Nov 2012 11:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRSqhIWUUzkQ for ; Sat, 3 Nov 2012 11:47:50 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 194A421F9C68 for ; Sat, 3 Nov 2012 11:47:50 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so2091552dan.31 for ; Sat, 03 Nov 2012 11:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JdGJP9avE/hbdmUjo8YvkEmMZJIV9XFZc+TYJefz3sg=; b=aO1yHv+Pl/mRW/B+MFjNbez15wezXS1b2QBLsp4ZR4TGHfNVpcuY/9mIoJL2aodfTj 9szyYMZSJzw4OAHTuOMXH6u7KLMFY15RLpDEeq970mkG8bNEzyib5AexW1LQ0EhkTqhV PZZ78qC1XcsrGVMGODmufGsu3ANjC7xzIIy3V4kDqi0/F6U9bSAEKl+y3CrKqDrMWS0T dKF2sGE4Hdtoy0VBLM9hvKVROdhv0OU6Asct5pO309fx3pIZqgjkuL1RhSKUVJRbopIJ 7Gt/AAbTxVbKvYT4Yyw8sXzpoPJvbJs8TMhUM5kO9rmR3hWNpVpclHAq1sVOgB6l7B/P v+Lg== Received: by 10.68.233.196 with SMTP id ty4mr17441247pbc.23.1351968469728; Sat, 03 Nov 2012 11:47:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Sat, 3 Nov 2012 11:47:29 -0700 (PDT) In-Reply-To: <005101cdb9d8$9a3ee4e0$cebcaea0$@olddog.co.uk> References: <005101cdb9d8$9a3ee4e0$cebcaea0$@olddog.co.uk> From: Henning Rogge Date: Sat, 3 Nov 2012 19:47:29 +0100 Message-ID: To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] End to end security [Was? Reactive routing protocols, what are the differences?] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 18:47:50 -0000 On Sat, Nov 3, 2012 at 4:33 PM, Adrian Farrel wrote: > Op 2 nov. 2012, om 13:01 heeft Henning Rogge het volgende geschreven: > >> (Does BGP have some ideas how to do end-to-end security? Its the only >> Distance Vector Protocol I know that is widely deployed.) > > Please be aware of the work in SIDR. I do not know much about BGP (just some basics)... do you think SIDR could be something that can be transfered to a reactive MANET protocol as a concept? Or would it be too much overhead? Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From jpmacker@gmail.com Sat Nov 3 12:02:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D46B21F9CCD for ; Sat, 3 Nov 2012 12:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UGXAxJdmJGJ for ; Sat, 3 Nov 2012 12:02:31 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD9A821F9CCE for ; Sat, 3 Nov 2012 12:02:30 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id b25so3373741qca.31 for ; Sat, 03 Nov 2012 12:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=pCAEujDTJrE+VwdcmxMvlcwpRJSquOLTOF6rdkk7gw0=; b=ZE9I46x2yBzgZBOriL5hnfemnTCoaGgsCHghjH+8NtF6JWc6W1VdRENF9vFEECYTHt N8N+4R5g1gjLNx3XdwRLlORjuiIFVP+O13dL5iFgGZnwL7yEjr9dETPGp9i+iHaB7biS zF2iVllaE43z5MZfjLkl9JDxuCfQ25lT4hI9URL1iuksGfCxQizCt5G+ceD0X36ugve5 f04dx7zCXNo8AbJN4TiftT94qnCCX4bSTwjzxyp9c9qlfO+xB1/XqpAxND83H+CE0jqg tXG53NNVRloJxrrSpJeSfh032sAlgS856+l9bwIuA0YZGtJyMqLh4zv1lDG1XPzP0Mra 5INg== Received: by 10.224.42.15 with SMTP id q15mr7748685qae.68.1351969350250; Sat, 03 Nov 2012 12:02:30 -0700 (PDT) Received: from ?IPv6:2002:458c:9704:1234:a1c7:6ddc:10a1:5d8? ([2002:458c:9704:1234:a1c7:6ddc:10a1:5d8]) by mx.google.com with ESMTPS id cu14sm6991057qab.1.2012.11.03.12.02.22 (version=SSLv3 cipher=OTHER); Sat, 03 Nov 2012 12:02:29 -0700 (PDT) References: <1351956773.4362.YahooMailClassic@web133201.mail.ir2.yahoo.com> Mime-Version: 1.0 (1.0) In-Reply-To: <1351956773.4362.YahooMailClassic@web133201.mail.ir2.yahoo.com> Content-Type: multipart/alternative; boundary=Apple-Mail-FF6FA45E-A4C8-4A55-843B-929FEBA1ACD3 Content-Transfer-Encoding: 7bit Message-Id: <22CA1781-92E5-4F46-9AA0-7D019BF9C9F7@gmail.com> X-Mailer: iPhone Mail (10A403) From: Joe Macker Date: Sat, 3 Nov 2012 15:03:20 -0400 To: Louiza Louiza Cc: "manet@ietf.org" Subject: Re: [manet] Send a request (Geographic routing). X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 19:02:31 -0000 --Apple-Mail-FF6FA45E-A4C8-4A55-843B-929FEBA1ACD3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable This mailing list is not for ns2 questions there is an ns2 mailing list for t= hat Sent from my iPhone On Nov 3, 2012, at 11:32 AM, Louiza Louiza wrote: >=20 > Hi manet mailling list members; > I'm a new ns-2 user, and i need your help please. >=20 > I'm simulating a network, where nodes are equipped by gps devices. > What i wont is sending a request to a node (source) that i knox his coordi= nates=20 >=20 > set xsource [$node_($NSource) set X_] > set ysource [$node_($NSource) set Y_] > set xid [$node_($Node_info($id)) set X_] > set yid [$node_($Node_info($id)) set Y_] >=20 > if {[getdist $xsource $ysource $xid $yid] <=3D $radius} { > # Send the request in one hop (directely) > ... > } else { > # Send the request to a node closer to the source node > ... > } >=20 > I dont know how i send the request ??????? >=20 >=20 > Thank you for helping me. > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-FF6FA45E-A4C8-4A55-843B-929FEBA1ACD3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
This mailing list is not for ns2 quest= ions there is an ns2 mailing list for that

Sent from my iPhone
<= div>
On Nov 3, 2012, at 11:32 AM, Louiza Louiza <loli_m1@yahoo.fr> wrote:

Hi manet mailling list mem= bers;
I'm a new ns-2 user, and i need your help please.

I'm simulating a network, where nodes are equipped by gps devices.<= /div>
What i wont is sending a request to a node (source) that i knox hi= s coordinates 

set xsource [$node_($NSour= ce) set X_]
set ysource [$node_($NSource) set Y_]
set xi= d [$node_($Node_info($id)) set X_]
set yid [$node_($Node_info($id)= ) set Y_]

if {[getdist $xsource $ysource= $xid $yid] <=3D $radius} {
# Send the request in one hop (dire= ctely)
...
} else {
# Send the request to a no= de closer to the source node
...
}

<= /div>
I dont know how i send the request ???????


Thank you for helping me.
<= div>_______________________________________________
ma= net mailing list
manet@iet= f.org
https://www.ietf.org/mailman/listinfo/manet
= --Apple-Mail-FF6FA45E-A4C8-4A55-843B-929FEBA1ACD3-- From jpmacker@gmail.com Sat Nov 3 12:22:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C56421F9C3D for ; Sat, 3 Nov 2012 12:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsD-RBLS79gP for ; Sat, 3 Nov 2012 12:22:37 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D248321F9C3A for ; Sat, 3 Nov 2012 12:22:36 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id b25so3379432qca.31 for ; Sat, 03 Nov 2012 12:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=G9OCY+4SjU3AR5mfQ12zxQpiUOug47varWdAUPpBcpM=; b=x/WxzoMwS9jgtat+3yFTqPijpKWznne0p+BPMhXajh4OmOC1c5voLjuBgEA7OH5D/T fhFjwYB3CrNizJNs7zTd7mqgtsIprQ0gwHNYgo8/GtQ3REWEMveLQPOVBXu/DiJ4V5Ga OzoWKrUOmGFi8KPuk+zRZqh7VcDK4PcsYABS6VYTQfg2/68iaZkpn2sN0WD9a1XxSH2Y S7iuifT1JXw7L8DM1YaFeyQ8KzxX1ro9qB7UjE+KL1bOz7YWc4+nGQ9XjiGdpO+oTUbY 6HhB6etcG4qry7bVWaZT9p/o27CQGwTFzjPpeVaG1P5B5GVyQ4LbRVtjHZ0fgnj5c1Fh yOpQ== Received: by 10.49.118.200 with SMTP id ko8mr8978590qeb.63.1351970556327; Sat, 03 Nov 2012 12:22:36 -0700 (PDT) Received: from [192.168.1.107] (c-69-140-151-4.hsd1.md.comcast.net. [69.140.151.4]) by mx.google.com with ESMTPS id z9sm6041655qeg.9.2012.11.03.12.22.35 (version=SSLv3 cipher=OTHER); Sat, 03 Nov 2012 12:22:36 -0700 (PDT) References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <5E3CC77A-4FA1-4C15-9536-306917AA8B13@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5E3CC77A-4FA1-4C15-9536-306917AA8B13@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9A087194-7787-4724-96FA-30511FE9DFC9@gmail.com> X-Mailer: iPhone Mail (10A403) From: Joe Macker Date: Sat, 3 Nov 2012 15:23:35 -0400 To: Philip Levis Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 19:22:37 -0000 Just as minor point I don't think the Manet community has ever had a hard bo= undary between reactive and proactive. Plenty of combined design work and I= Ds were done in the 90s. It was a question of what made sense for maturity a= nd engineering in the ietf at the time. With the more modern design element= s like adaptive timers etc it is easier to see an engineering convergence of= the two design elements for example a proactive becoming more reactive. We= were designing polymorphic protocols back in the 90s and there was even an i= rtf for this for a few years that we split off from the WG Sent from my iPhone On Nov 3, 2012, at 12:40 PM, Philip Levis wrote: > On Nov 2, 2012, at 9:06 AM, Timothy J. Salo wrote: >=20 >>=20 >> We've known for at least 15 years that reactive routing protocols are >> more appropriate for light traffic loads and that proactive routing >> protocols are more appropriate with heavier traffic loads. Dozens, >> probably hundreds of research papers have reiterated this result. >> I don't know of any that have contradicted this result, although >> some researchers have tried to develop hybrid routing protocols >> (which don't seem to have gained much traction, either in the IETF >> or elsewhere). >=20 > Timothy, >=20 > I agree with your conclusion for MANETs. For LLNs, it's a bit more complic= ated, due to the "low power" part. You see this tension in RPL, where on one= hand it's mostly proactive (continually maintains a topology) but on the ot= her it has reactive elements (datapath validation, adaptive beaconing). The b= asic idea is that you make an educated guess for a good route based on old i= nformation and fix it as needed, rather than throw all that old information a= way and start from scratch. But the community that researched LLN protocols i= n the 2000s didn't generally come from a MANET background so didn't see such= a hard boundary between reactive and proactive solutions. >=20 > Just my 2c, >=20 > Phil >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From adrian@olddog.co.uk Sat Nov 3 13:41:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958B821F9CBA for ; Sat, 3 Nov 2012 13:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpcBjke3eKFF for ; Sat, 3 Nov 2012 13:41:13 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id D601021F9CB9 for ; Sat, 3 Nov 2012 13:41:12 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id qA3Kf8Nv013109; Sat, 3 Nov 2012 20:41:08 GMT Received: from 950129200 ([130.129.19.181]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id qA3Kf1Yt013040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 3 Nov 2012 20:41:04 GMT From: "Adrian Farrel" To: "'Henning Rogge'" References: <005101cdb9d8$9a3ee4e0$cebcaea0$@olddog.co.uk> In-Reply-To: Date: Sat, 3 Nov 2012 20:40:55 -0000 Message-ID: <005b01cdba03$8dac4d00$a904e700$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHYTzcvs0keSOPUUZ3GLwtUTQVdfwI4ujnRl7GfRsA= Content-Language: en-gb Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org, 'Thomas Heide Clausen' Subject: Re: [manet] End to end security [Was? Reactive routing protocols, what are the differences?] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 20:41:13 -0000 I think that there has been some very useful discussion in SIDR of the security of e2e routing information in a hop-by-hop routing protocol. This has resulted in authentication for the root of the advertisement, and security for the hop-by-hop exchanges. We could learn from this separation, but we obviously have a slightly different hop-by-hop paradigm because nodes can more easily insert themselves into our networks. I think the lesson here is to place the strongest security on admission to the network. I am unsure about the concept of securing any other data because of the security relationships that are implied. We could probably also learn from the work being done in KARP and maybe we should engage them with the characteristics of our problem space. Adrian > -----Original Message----- > From: Henning Rogge [mailto:hrogge@googlemail.com] > Sent: 03 November 2012 18:47 > To: adrian@olddog.co.uk > Cc: Teco Boot; Dearlove, Christopher (UK); manet@ietf.org; Thomas Heide > Clausen > Subject: Re: End to end security [Was? Reactive routing protocols, what are the > differences?] > > On Sat, Nov 3, 2012 at 4:33 PM, Adrian Farrel wrote: > > Op 2 nov. 2012, om 13:01 heeft Henning Rogge het volgende geschreven: > > > >> (Does BGP have some ideas how to do end-to-end security? Its the only > >> Distance Vector Protocol I know that is widely deployed.) > > > > Please be aware of the work in SIDR. > > I do not know much about BGP (just some basics)... do you think SIDR > could be something that can be transfered to a reactive MANET protocol > as a concept? Or would it be too much overhead? > > Henning Rogge > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From hrogge@googlemail.com Sat Nov 3 13:51:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E008E21F9C68 for ; Sat, 3 Nov 2012 13:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiW7Hgt04voQ for ; Sat, 3 Nov 2012 13:51:30 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 73EAC21F9B53 for ; Sat, 3 Nov 2012 13:51:30 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so3119341pbb.31 for ; Sat, 03 Nov 2012 13:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6lEeliUj5hx9lCwmzlX8qJ1Q2wG8JFjAqCjJHxK0qvI=; b=Vz7RAkMdOQxvQHJmh4cDn7jzCMLVK7ZR1fwK1K6MfE8SmkNc3prb+CkONuvW1JjLoe w72spY+Ou95iWprB7XOeaWyEPsHumq6mf1aOk3mjITttqrqJVKnyWDytRAa0YgEQftR3 taLK+HQS7jmh/MDl5iu372aTHO+L0ntyXgsWwaWqM0GVs4bnif4FBEr6v8UXaHKaY/Y0 MmhEwToO4MJ0fwoY6WSWY2705L3GmhV1cVA/h3hqsgO3hG4MVfHkJ4mffYQQJN+Q4bBX IfSea0XlfYYx+myHyIvxEx0PeFV54NdmtMD3UVYy3H2WUf5zdqKvgsXIY+1jWgBrxYk9 PPag== Received: by 10.68.138.198 with SMTP id qs6mr17790633pbb.151.1351975890038; Sat, 03 Nov 2012 13:51:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Sat, 3 Nov 2012 13:51:09 -0700 (PDT) In-Reply-To: <005b01cdba03$8dac4d00$a904e700$@olddog.co.uk> References: <005101cdb9d8$9a3ee4e0$cebcaea0$@olddog.co.uk> <005b01cdba03$8dac4d00$a904e700$@olddog.co.uk> From: Henning Rogge Date: Sat, 3 Nov 2012 21:51:09 +0100 Message-ID: To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] End to end security [Was? Reactive routing protocols, what are the differences?] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 20:51:31 -0000 On Sat, Nov 3, 2012 at 9:40 PM, Adrian Farrel wrote: > I think that there has been some very useful discussion in SIDR of the security > of e2e routing information in a hop-by-hop routing protocol. > > This has resulted in authentication for the root of the advertisement, and > security for the hop-by-hop exchanges. Maybe we could do this by using a packet signature for hop-by-hop and an address signature that protects the address and the attached sequence number/validity-time (and maybe an extension of the sequence number to prevent replay attacks after the 2 byte overflow) ? (the second would prevent an attacker from making up node IDs that are not currently in the network) > We could learn from this separation, but we obviously have a slightly different > hop-by-hop paradigm because nodes can more easily insert themselves into our > networks. Yes. > I think the lesson here is to place the strongest security on admission to the > network. So we should use at least linklayer security and/or signatures on packet level to prove the fact that the neighbor is allowed to produce routing messages. > I am unsure about the concept of securing any other data because of the security > relationships that are implied. We could probably also learn from the work being > done in KARP and maybe we should engage them with the characteristics of our > problem space. Defining "sufficient" security without an attacker model is always difficult. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From alexandru.petrescu@gmail.com Sat Nov 3 14:07:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0F621F9CA5 for ; Sat, 3 Nov 2012 14:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiyQSh8dgQWW for ; Sat, 3 Nov 2012 14:07:41 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0302321F9B9F for ; Sat, 3 Nov 2012 14:07:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA3L7cLP017590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 3 Nov 2012 22:07:39 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA3L7csV017166 for ; Sat, 3 Nov 2012 22:07:38 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-24.intra.cea.fr [132.166.201.24]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA3L7YC4031956 for ; Sat, 3 Nov 2012 22:07:38 +0100 Message-ID: <50958796.8030409@gmail.com> Date: Sat, 03 Nov 2012 22:07:34 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: manet@ietf.org References: <005101cdb9d8$9a3ee4e0$cebcaea0$@olddog.co.uk> <005b01cdba03$8dac4d00$a904e700$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [manet] End to end security [Was? Reactive routing protocols, what are the differences?] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 21:07:42 -0000 Le 03/11/2012 21:51, Henning Rogge a écrit : > On Sat, Nov 3, 2012 at 9:40 PM, Adrian Farrel > wrote: >> I think that there has been some very useful discussion in SIDR of >> the security of e2e routing information in a hop-by-hop routing >> protocol. >> >> This has resulted in authentication for the root of the >> advertisement, and security for the hop-by-hop exchanges. > > Maybe we could do this by using a packet signature for hop-by-hop > and an address signature that protects the address For address signature there is this CGA and hash-based addresses work. Alex > and the attached sequence number/validity-time (and maybe an > extension of the sequence number to prevent replay attacks after the > 2 byte overflow) ? > > (the second would prevent an attacker from making up node IDs that > are not currently in the network) > >> We could learn from this separation, but we obviously have a >> slightly different hop-by-hop paradigm because nodes can more >> easily insert themselves into our networks. > > Yes. > >> I think the lesson here is to place the strongest security on >> admission to the network. > > So we should use at least linklayer security and/or signatures on > packet level to prove the fact that the neighbor is allowed to > produce routing messages. > >> I am unsure about the concept of securing any other data because of >> the security relationships that are implied. We could probably also >> learn from the work being done in KARP and maybe we should engage >> them with the characteristics of our problem space. > > Defining "sufficient" security without an attacker model is always > difficult. > > Henning Rogge > From hrogge@googlemail.com Sat Nov 3 14:09:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F46F21F9CC8 for ; Sat, 3 Nov 2012 14:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOsxXCU9nBmO for ; Sat, 3 Nov 2012 14:09:58 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE4221F9CBC for ; Sat, 3 Nov 2012 14:09:57 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so2116449dan.31 for ; Sat, 03 Nov 2012 14:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mc4K5UhVjyrnoUgQHZiaHIdJa7VqUzvRfuHrbxToTzc=; b=ZFK7sORlylFQS3YI5k2CEauF0pCrGr+nl/Ejvohzv138xABMxfK/tP+BPp3nhaMGl8 MVTIVHFbq26ORNkQNUQ63FfbgEA2vxTsd8IwoSbQQ6Rn/R06J+/kpWRNAHD8Snj/tZ2v 9BCf4Ip742Idm1hoCJjqYUETvDizuouf+2ods7QuMx70Dz28yE4zHWsSe+EQmMDWGTdm Olo+ymkrzZyUw7kT/qo7VXLamJhg1o/RwdcwoiE+nICDvEoHV8A8pJxLlSiyBxotg5xY IH6RWVBH5RU6APMCbDuec/brTPDywa9yic6Zlq9VflkFElI8sWoZT9I0f2lB1ACxN8se WRLA== Received: by 10.68.200.33 with SMTP id jp1mr17812138pbc.54.1351976997091; Sat, 03 Nov 2012 14:09:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Sat, 3 Nov 2012 14:09:36 -0700 (PDT) In-Reply-To: <50958796.8030409@gmail.com> References: <005101cdb9d8$9a3ee4e0$cebcaea0$@olddog.co.uk> <005b01cdba03$8dac4d00$a904e700$@olddog.co.uk> <50958796.8030409@gmail.com> From: Henning Rogge Date: Sat, 3 Nov 2012 22:09:36 +0100 Message-ID: To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] End to end security [Was? Reactive routing protocols, what are the differences?] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 21:09:58 -0000 On Sat, Nov 3, 2012 at 10:07 PM, Alexandru Petrescu wrote: >> Maybe we could do this by using a packet signature for hop-by-hop >> and an address signature that protects the address > > For address signature there is this CGA and hash-based addresses work. Address signatures as in RFC 6622 (packetbb-sec). I was talking about securing a part of a RFC5444 message. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From christopher.dearlove@googlemail.com Sat Nov 3 19:27:04 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8838621F949B for ; Sat, 3 Nov 2012 19:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.581 X-Spam-Level: X-Spam-Status: No, score=-1.581 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdwaKZ8k0MIN for ; Sat, 3 Nov 2012 19:27:04 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1247A21F9499 for ; Sat, 3 Nov 2012 19:27:04 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so2169650dan.31 for ; Sat, 03 Nov 2012 19:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=2oPPqWbkXTS5o4O/k4m0fITXY7/ZUV37tCOJTxWjEIA=; b=qgbr17F48HEtoNimKWADrh6RcXYETTqTp1S6I3IFNq/rfNqlk+uLUz6ZXJy/3pwAoh WVbYhOZl1coww3Ei2JxzVhJ/PgkqvIQ/UQEvJn9GaOxBwc97YdW7kWqTAIlpsCkBpdMT OzaR1dg1oUuqPxyMgpBsEBP6KttGcUpHibrsqvugrfYM9u0cJXErnYtMWFUvi84C6pE0 wIWBdEU9kvwRjIvuhmMnJPTgcZAJsasvFbQzDDNqKhnaOGROReRMBtc14i5FD6Q2SSSJ CGANsbDd6Kh27PzGCI5YUcoRfkJimuYHy/KRqswKE6t8R9w9rgROR2ImHj5WGHjiOcQC DXLQ== Received: by 10.66.81.163 with SMTP id b3mr11126235pay.49.1351996023846; Sat, 03 Nov 2012 19:27:03 -0700 (PDT) Received: from ?IPv6:2001:df8::64:226:4aff:fec4:6cdf? ([2001:df8:0:64:226:4aff:fec4:6cdf]) by mx.google.com with ESMTPS id lb3sm8196638pbc.73.2012.11.03.19.27.01 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 03 Nov 2012 19:27:03 -0700 (PDT) References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <5E3CC77A-4FA1-4C15-9536-306917AA8B13@gmail.com> <9A087194-7787-4724-96FA-30511FE9DFC9@gmail.com> In-Reply-To: <9A087194-7787-4724-96FA-30511FE9DFC9@gmail.com> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <76DC788D-9525-4C54-AC67-894E10C38CE3@gmail.com> X-Mailer: iPhone Mail (8B117) From: Christopher Dearlove Date: Sat, 3 Nov 2012 22:27:12 -0400 To: Joe Macker Cc: "Timothy J. Salo" , "manet@ietf.org" , Philip Levis Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 02:27:04 -0000 In order to avoid confusion, OLSRv2 and NHDP use the term responsive for thi= ngs that respond to circumstances. Not the same as reactive in the AODV sens= e, but (used in forms like exponentially backed off message intervals) not e= ntirely unrelated either. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) On 3 Nov 2012, at 15:23, Joe Macker wrote: > Just as minor point I don't think the Manet community has ever had a hard b= oundary between reactive and proactive. Plenty of combined design work and I= Ds were done in the 90s. It was a question of what made sense for maturity a= nd engineering in the ietf at the time. With the more modern design element= s like adaptive timers etc it is easier to see an engineering convergence of= the two design elements for example a proactive becoming more reactive. We= were designing polymorphic protocols back in the 90s and there was even an i= rtf for this for a few years that we split off from the WG >=20 > Sent from my iPhone >=20 > On Nov 3, 2012, at 12:40 PM, Philip Levis wrote: >=20 >> On Nov 2, 2012, at 9:06 AM, Timothy J. Salo wrote: >>=20 >>>=20 >>> We've known for at least 15 years that reactive routing protocols are >>> more appropriate for light traffic loads and that proactive routing >>> protocols are more appropriate with heavier traffic loads. Dozens, >>> probably hundreds of research papers have reiterated this result. >>> I don't know of any that have contradicted this result, although >>> some researchers have tried to develop hybrid routing protocols >>> (which don't seem to have gained much traction, either in the IETF >>> or elsewhere). >>=20 >> Timothy, >>=20 >> I agree with your conclusion for MANETs. For LLNs, it's a bit more compli= cated, due to the "low power" part. You see this tension in RPL, where on on= e hand it's mostly proactive (continually maintains a topology) but on the o= ther it has reactive elements (datapath validation, adaptive beaconing). The= basic idea is that you make an educated guess for a good route based on old= information and fix it as needed, rather than throw all that old informatio= n away and start from scratch. But the community that researched LLN protoco= ls in the 2000s didn't generally come from a MANET background so didn't see s= uch a hard boundary between reactive and proactive solutions. >>=20 >> Just my 2c, >>=20 >> Phil >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From c.chauvenet@watteco.com Sun Nov 4 00:42:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5357821F85AC for ; Sun, 4 Nov 2012 00:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.704 X-Spam-Level: X-Spam-Status: No, score=-3.704 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vx2RfpACE3-O for ; Sun, 4 Nov 2012 00:42:25 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCD021F85A3 for ; Sun, 4 Nov 2012 00:42:24 -0700 (PDT) Received: from mail30-db3-R.bigfish.com (10.3.81.232) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Sun, 4 Nov 2012 07:42:23 +0000 Received: from mail30-db3 (localhost [127.0.0.1]) by mail30-db3-R.bigfish.com (Postfix) with ESMTP id 198142E020B; Sun, 4 Nov 2012 07:42:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT005.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz98dI9371Ic89bhc85eh1432Izz1de0h1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received: from mail30-db3 (localhost.localdomain [127.0.0.1]) by mail30-db3 (MessageSwitch) id 1352014940531451_25225; Sun, 4 Nov 2012 07:42:20 +0000 (UTC) Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.249]) by mail30-db3.bigfish.com (Postfix) with ESMTP id 7E3FC40045; Sun, 4 Nov 2012 07:42:20 +0000 (UTC) Received: from DBXPRD0510HT005.eurprd05.prod.outlook.com (157.56.252.165) by DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 4 Nov 2012 07:42:20 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT005.eurprd05.prod.outlook.com ([10.255.67.168]) with mapi id 14.16.0233.002; Sun, 4 Nov 2012 07:42:19 +0000 From: C Chauvenet To: Jon Black Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNtvRAV6TKZOGU0EeXjdQ8Uxmd8pfVvJCAgADah4CAAA79AIAAA8CAgAAd8gCAAAFngIAABQyAgAABJwCAAATUgIAABRcAgAADbQCAADeEAIAAt1cAgAB/Q4CAAQcVgA== Date: Sun, 4 Nov 2012 07:42:19 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D2157610A@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C638@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C877@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204CB91@xmb-rcd-x02.cisco.com> <1351891740.83248.YahooMailNeo@web160605.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204D717@xmb-rcd-x02.cisco.com> <1351958441.96668.YahooMailNeo@web160603.mail.bf1.yahoo.com> In-Reply-To: <1351958441.96668.YahooMailNeo@web160603.mail.bf1.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.46.4] Content-Type: multipart/alternative; boundary="_000_97B69B30E0EF244B940B65EA541E3F2D2157610ADBXPRD0510MB395_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 07:42:37 -0000 --_000_97B69B30E0EF244B940B65EA541E3F2D2157610ADBXPRD0510MB395_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Mr Black, As asked by chairs, I won't argue further on this topic here, but I certain= ly do not agree with your last mails. You can certainly send a mail to the ROLL mailing list to discuss this. It seems that you never argue that before, as I don't find any traces from = you in ROLL (nor on any IETF archive before this debate BTW). C=E9dric. Le 3 nov. 2012 =E0 17:00, Jon Black a =E9crit : Yes. we should take this to ROLL where we can talk about how storing mode r= eally doesn't work in constrained devices and RPL does depend on traffic an= d traffic patterns. That is about RPL and this is about a reactive protocol for Manets. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: Henning Rogge >; "m= anet@ietf.org" > Sent: Saturday, November 3, 2012 2:25 AM Subject: Re: [manet] Reactive Protocol Situation OK I will stop arguing here -- If I may reread what you wrote, then read RF= C6550 and you will quickly see why you mis-undertood the protocol. Hint: think of DAG rooted at source of traffic, use address aggregation map= ping to topologies, P2P, storing of source routed paths. On Nov 2, 2012, at 5:29 PM, Jon Black wrote: Ah but now you mix apples and oranges. Storing mode is not good for highly= constrained devices (they don't have the memory for storing mode) so for m= any LLNs you are stuck with non-storing mode which is poor with P2MP, but s= till fine with MP2P. And therefore Henning's point is valid. It depends o= n traffic. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Henning Rogge > Cc: "manet@ietf.org" > Sent: Friday, November 2, 2012 12:10 PM Subject: Re: [manet] Reactive Protocol Situation Again your assumption are not correct - look at storing mode with OF to inc= rease connectivity if required, for P2P. But again =85 not appropriate for this list. On Nov 2, 2012, at 6:58 PM, Henning Rogge wrote: > On Fri, Nov 2, 2012 at 6:39 PM, JP Vasseur (jvasseur) > > wrote: >>> By your own words the effectiveness/overhead of LoadNG in LLNs >>> compared to other protocols will most likely depend on the traffic >>> patterns (which is also true for most other routing protocols, >>> especially Ripple). >> >> JP> This is technically incorrect - RPL/OSPF/BGP =85 performances are no= t directly a function >> of the user traffic. > > Ripple is a tree-based routing protocol. > > its really good when sending traffic towards the local root, not as > good (but still good) when sending traffic from the root to its nodes, > bad when you send traffic between two nodes with the same root and > really bad when sending traffic between nodes that are not part of the > same root tree. > > I would say its performance depends on the user traffic pattern. > > The overhead (as a comparison between control plane traffic and data > plane traffic) is of course always different for each protocol > depending on the user traffic. > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_97B69B30E0EF244B940B65EA541E3F2D2157610ADBXPRD0510MB395_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Mr Black, 

As asked by chairs, I won't argue further on this topic here, but I ce= rtainly do not agree with your last mails.

You can certainly send a mail to the ROLL mailing list to discuss this= . 
It seems that you never argue that before, as I don't find any tr= aces from you in ROLL (nor on any IETF archive before this debate BTW).

C=E9dric.

Le 3 nov. 2012 =E0 17:00, Jon Black a =E9crit :

Yes. we should take this to ROLL where we can talk about how storing mode r= eally doesn't work in constrained devices and RPL does depend on traffic an= d traffic patterns.
That is about RPL and this is about a reactive protocol for Manets.

Jon


From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: Henning Rogge <hrogge@googlemail.com>; "<= a href=3D"mailto:manet@ietf.org">manet@ietf.org" <manet@ietf.org>
Sent: Saturday, November 3= , 2012 2:25 AM
Subject: Re: [manet] React= ive Protocol Situation

OK I will stop arguing here -- If I may reread what you wrote, then re= ad RFC6550 and you will quickly see why you mis-undertood the protocol.
Hint: think of DAG rooted at source of traffic, use address aggregatio= n mapping to topologies, P2P, storing of source routed paths.

On Nov 2, 2012, at 5:29 PM, Jon Black wrote:

Ah but now you mix apples and oranges.  Storing mode is not good for h= ighly constrained devices (they don't have the memory for storing mode) so = for many LLNs you are stuck with non-storing mode which is poor with P2MP, = but still fine with MP2P.  And therefore Henning's point is valid.  It depends on traffic.

Jon


From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Henning Rogge <hrogge@googlemail.com>
Cc: "manet@ietf.org" <manet@i= etf.org>
Sent: Friday, November 2, 2= 012 12:10 PM
Subject: Re: [manet] Reacti= ve Protocol Situation

Again your assumption are not correct - look at storing mode with OF to inc= rease connectivity if required,
for P2P. But again =85 not appropriate for this list.

On Nov 2, 2012, at 6:58 PM, Henning Rogge wrote:

> On Fri, Nov 2, 2012 at 6:39 PM, JP Vasseur (jvasseur)
> <jvasseur@cisco.com> w= rote:
>>> By your own words the effectiveness/overhead of LoadNG in LLNs=
>>> compared to other protocols will most likely depend on the tra= ffic
>>> patterns (which is also true for most other routing protocols,=
>>> especially Ripple).
>>
>> JP> This is technically incorrect - RPL/OSPF/BGP =85 performanc= es are not directly a function
>> of the user traffic.
>
> Ripple is a tree-based routing protocol.
>
> its really good when sending traffic towards the local root, not as > good (but still good) when sending traffic from the root to its nodes,=
> bad when you send traffic between two nodes with the same root and
> really bad when sending traffic between nodes that are not part of the=
> same root tree.
>
> I would say its performance depends on the user traffic pattern.
>
> The overhead (as a comparison between control plane traffic and data > plane traffic) is of course always different for each protocol
> depending on the user traffic.
>
> Henning Rogge
> --
> Steven Hawkings about cosmic inflation: "An increase of billions = of
> billions of percent in a tiny fraction of a second. Of course, that > was before the present government."

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet





_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_97B69B30E0EF244B940B65EA541E3F2D2157610ADBXPRD0510MB395_-- From c.chauvenet@watteco.com Sun Nov 4 00:49:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89C421F86B2 for ; Sun, 4 Nov 2012 00:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.693 X-Spam-Level: X-Spam-Status: No, score=-3.693 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnG8g9RD0m2y for ; Sun, 4 Nov 2012 00:49:52 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id EBE1D21F86AF for ; Sun, 4 Nov 2012 00:49:51 -0700 (PDT) Received: from mail199-co1-R.bigfish.com (10.243.78.232) by CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id 14.1.225.23; Sun, 4 Nov 2012 07:49:50 +0000 Received: from mail199-co1 (localhost [127.0.0.1]) by mail199-co1-R.bigfish.com (Postfix) with ESMTP id C48E43801E1; Sun, 4 Nov 2012 07:49:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT005.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz98dI9371Ic89bh1454Ic85eh328cMzz1de0h1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received: from mail199-co1 (localhost.localdomain [127.0.0.1]) by mail199-co1 (MessageSwitch) id 1352015387230607_4776; Sun, 4 Nov 2012 07:49:47 +0000 (UTC) Received: from CO1EHSMHS028.bigfish.com (unknown [10.243.78.235]) by mail199-co1.bigfish.com (Postfix) with ESMTP id 34D2DD80057; Sun, 4 Nov 2012 07:49:47 +0000 (UTC) Received: from DBXPRD0510HT005.eurprd05.prod.outlook.com (157.56.252.165) by CO1EHSMHS028.bigfish.com (10.243.66.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 4 Nov 2012 07:49:46 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT005.eurprd05.prod.outlook.com ([10.255.67.168]) with mapi id 14.16.0233.002; Sun, 4 Nov 2012 07:49:45 +0000 From: C Chauvenet To: Jon Black Thread-Topic: [manet] LOADng works Thread-Index: AQHNuEYjLqnfvWsGTUKn5f9jVwDGQ5fVTi6AgACcCgCAAEpAgIAACHeAgACLqACAAojDgA== Date: Sun, 4 Nov 2012 07:49:44 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D2157619C@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204AED7@xmb-rcd-x02.cisco.com> <1351876062.61554.YahooMailNeo@web160602.mail.bf1.yahoo.com> In-Reply-To: <1351876062.61554.YahooMailNeo@web160602.mail.bf1.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.67.132] Content-Type: multipart/alternative; boundary="_000_97B69B30E0EF244B940B65EA541E3F2D2157619CDBXPRD0510MB395_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "manet@ietf.org List" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 07:49:53 -0000 --_000_97B69B30E0EF244B940B65EA541E3F2D2157619CDBXPRD0510MB395_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Inline, Le 2 nov. 2012 =E0 18:07, Jon Black a =E9crit : no - i have a conflict next week deploying a sensor network. Will it use LOADng ? It may add some material in this debate. C=E9dric. ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: "manet@ietf.org List" > Sent: Friday, November 2, 2012 2:47 AM Subject: Re: [manet] LOADng works Dear Jon, will you be at the next IETF meeting in MANET WG so that we can have a tech= nical discussion ? Thanks. JP. On Nov 2, 2012, at 4:17 AM, JP Vasseur (jvasseur) wrote: Hi Jon, On Nov 1, 2012, at 11:51 PM, Jon Black wrote: In line [Jon2] ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: "manet@ietf.org" > Sent: Thursday, November 1, 2012 12:33 PM Subject: Re: [manet] LOADng works Hi Jon, In line - JP2> On Nov 1, 2012, at 4:32 PM, Jon Black wrote: ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: "manet@ietf.org" >; "thierry.lys@erdfdistribution.fr" > Sent: Thursday, November 1, 2012 3:41 AM Subject: Re: [manet] (no subject) Hi Jon, On Nov 1, 2012, at 12:39 AM, Jon Black wrote: Yes it shows that it does work in a rather large deployment. JP> This is not just a question of "how large" it is =85 but also how dynam= ic. I could show you few hundreds (if not less number of nodes) not working if the traffic pattern is too dynamic. This is a fundamental pr= oblem. [Jon] Are you saying that their AMI PLC deployment was not dynamic? JP2> We do not have any details so I cannot comment on *that* deployment; m= y point was that you can easily show why the number of nodes is NOT the only issues with reactive routing protocols in LLNs. Ta= ke actual traces (which I personally did with actual deployed networks) and simulate the control plane traffic with moderate use traffic = demand and you will see the issue with such routing approach. In other words, even with a relatively small number of nodes, in contrast w= ith other proactive routing protocols, if the user traffic is moderate (not even very high), you clearly see why this reactive routing is ill suit= ed to LLNs. [Jon2] There are plenty of well working LLNs that use reactive protocols su= ch as AODV. I've built and deployed them so perhaps you can't but I can an= d the protocol and network work well. It depends on the type of traffic, n= odes, radio, ... To say that you can only build a working LLN using a proa= ctive protocol is just plain foolish. JP2> Let's try to be gentle and respectful. If you have built such networks= , feel free to share; But this is certainly not the conclusion the ROLL WG shared after 4 years of work. I have heard others say that it works in other deployments as well - just t= he same as you say RPL works in some deployments. JP> I do not not think that we should go in a RPL versus Load-NG debate but= rather try to find a good solution for MANET. That being said, RPL *for* LLNs the the result of a 4-year work with a DT, weekly call= s, interim WG meetings to make it work in LLNs. [Jon] I did not cast this as a RPL vs LOADng debate - you just did. I am s= aying that LOADng works in some scenarios and proof is the EDF deployment i= n their AMI network. JP2> I would be happy to see detailed results and especially the user traff= ic profiles for the reason exposed above. [Jon2] JP actually it doesn't matter! You say that you CANNOT build a work= ing LLN using a reactive protocol. EDF has proved that wrong. They built = one. You can continue to claim that you can't, but there is an existence p= roof. JP3> You keep ignoring my point. Of it matters. I would even make it work w= ith BGP-4. Would you recommend the use of BGP in LLN ? If you deploy a protocol in very specific conditions that do not apply to m= ost LLNs, then you may want to know it before making it an RFC. Please share your results. You keeps saying you will and you we keep askin= g you to - where's the results so they can be reviewed. JP> Once again, I would first like to hear chair's decision. PLEASE note th= at I would be happy to see Load's results too. And just be patient, I just need to find a bit of time to compile results and you will = get many results backing up my claims. Please also refer to the number of discussions prior to designing RPL that took place on the ROLL ma= iling list. Believe me there was a reason not NOT choosing a reactive protocol for LLN (again I am NOT against reactive routing for ot= her use cases at all). Would you ignore the findings of a WG that worked for 4 years on the subject matter ? I guess not =85 Just trying= to raise my voice (as many others on this list) to protect the Internet. [Jon] As others have said - you have it backwards. If you have data that w= ould show that LOADng or a reactive protocol will not work in MANETs please= share it. JP2> Please reread what I wrote ten times =85 I said "LLNs" not "MANET" in = general. On top of that, I do prefer the option 1) for the reasons exposed before (this is the WG document, Charlie made it compatible + other technic= al reasons). You did say LLNs but again you are wrong. There are plenty of LLNS that ha= ve been built using reactive (and proactive) protocols and will continue to= be built using reactive (and proactive protocols). There is no one size f= its all. I prefer to have a debate based on facts and not conjecture and based on te= chnical arguments. That would be very insightful and would help guide this discussion and decision. It woul= d not be prudent to make a decision and then bring out data that would try = to suggest that the decision was incorrect. What findings are you referring to? Where is there a WG document that docu= ments these findings? [Jon2] I noticed you skipped this. JP3> I do not skip anything. I am respectful of the question asked by the c= hair, knowing that their task is to say the least not easy. As soon as required, I will provide lots of data, at least the ones that ca= n be shared, if authorization is given by the owners of these networks. Thanks. JP. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Jon Black > Cc: "manet@ietf.org" >; "thierry.lys@erdfdistribution.fr" > Sent: Wednesday, October 31, 2012 4:09 PM Subject: Re: [manet] (no subject) On Oct 31, 2012, at 6:57 PM, Jon Black wrote: On October 31, 2012 Thierry.Lys wrote: I speak in the name of EDF group. We started first to use LOAD as a routing algorithm and deployed 2000 PLC-m= eters for smart grid purposes in 2011. Taking advantage of this field test,= we have been actively participating to the working group to adopt enhancem= ents in the LOADng specification. We are now extremely pleased with what LOADng is capable of and are confide= nt that future deployements will be equipped with it. This would seem to indicate that LOADng does work and in a rather large dep= loyment. JP> No this means that LoadNG works in *a* network. But the major technical= difference here is that reactive routing is highly impacted by the user traffic =85 If you poll a meter every 24 hours, it may work per= fectly well. Now if you start having more frequent traffic flows you can either cache paths (ending up with more frequent broken paths consi= dering how flappy these networks are, thus leading to more floods =85 very undesirable =85 especially when you have hundreds of meters= sharing a few Kbits/s) or you use short cache timers and you keep flooding :-( If you take actual traces of these networks (both using 1= 5.4g and P1901.2) and you start adjusting the user traffic rate you immediately see the issues in terms of scalability. Yes you can try to miti= gate the undesirable flooding effect to some extends but showing the limits in terms of scalability is easy to show. Note that I MOT against= reactive routing by any means, this is IMO just not applicable to LLNs unless the traffic flows are deterministic and very well knows =85 Les= sons from the past show us how difficult it is to predict user applications. We all started with meter reading to continue with that examp= le and now many utilities wants to use these smart metering networks for a number of applications which different SLA, =85 Hope this helps. Once again, when/if required I would be happy to share man= y results. "We believe in rough consensus and running code" rough consensus : Don't you think we have a rough consensus on LOADng compa= red to DYMO ? 10 authors and major companies are supporters of LOADng. running code : interoperability has been checked with 4 sources and other i= mplementations are in progress. Obviously from the list we don't have rough consensus. We have two alterna= tives each with proponents. The WG should weigh the technical benefits (de= sign, implementation/running code, maturity) of each and the group should = choose a path forward. In my opinion option 3 is not an option - this is the working group shirkin= g its responsibility. This is an option =85 since listed by the chairs. I agree that we should av= oid it, especially when I think we have a very reasonable solution (option1). JP. Jon _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_97B69B30E0EF244B940B65EA541E3F2D2157619CDBXPRD0510MB395_ Content-Type: text/html; charset="Windows-1252" Content-ID: <20D1B30F5419154CB4B79D98AB39785F@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi, 
Inline,

Le 2 nov. 2012 =E0 18:07, Jon Black a =E9crit :

no - i have a conflict next week deploying a sensor network.

Will it use LOADng ? It may add some material in this debate.

C=E9dric.


From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org List" <manet@ietf.org>
Sent: Friday, November 2, = 2012 2:47 AM
Subject: Re: [manet] LOADn= g works

Dear Jon,

will you be at the next IETF meeting in MANET WG so that we can have a= technical discussion ?

Thanks.

JP.

On Nov 2, 2012, at 4:17 AM, JP Vasseur (jvasseur) wrote:

Hi Jon,

On Nov 1, 2012, at 11:51 PM, Jon Black wrote:

In line [Jon2]


From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@i= etf.org>
Sent: Thursday, November 1,= 2012 12:33 PM
Subject: Re: [manet] LOADng= works

Hi Jon,

In line - JP2>

On Nov 1, 2012, at 4:32 PM, Jon Black wrote:



From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@i= etf.org>; "thierr= y.lys@erdfdistribution.fr" <thierry.lys@erdfdistribution.fr>
Sent: Thursday, November 1,= 2012 3:41 AM
Subject: Re: [manet] (no su= bject)

Hi Jon,

On Nov 1, 2012, at 12:39 AM, Jon Black wrote:

Yes it shows that it does work in a rather large deployment.&nbs= p;

JP> This is not just a question of "how large" it is =85 = but also how dynamic. I could show you few hundreds (if not less number of = nodes)
not working if the traffic pattern is too dynamic. This is a fundament= al problem.

[Jon] Are you saying that their AMI PLC deployment was not dynamic?

JP2> We do not have any details so I cannot comment on *that* deplo= yment; my point was that you can easily show why the number
of nodes is NOT the only issues with reactive routing protocols in LLN= s. Take actual traces (which I personally did with actual deployed
networks) and simulate the control plane traffic with moderate use tra= ffic demand and you will see the issue with such routing approach.
In other words, even with a relatively small number of nodes, in contr= ast with other proactive routing protocols, if the user traffic is moderate=
(not even very high), you clearly see why this reactive routing is ill= suited to LLNs.

[Jon2] There are plenty of well working LLNs that use reactive protocols su= ch as AODV.  I've built and deployed them so perhaps you can't but I c= an and the protocol and network work well.  It depends on the type of = traffic, nodes, radio, ...  To say that you can only build a working LLN using a proactive protocol is just plain fool= ish.

JP2> Let's try to be gentle and respectful. If you have built such = networks, feel free to share; But this is certainly not the conclusion the = ROLL
WG shared after 4 years of work.



I have heard others say that it works in other deployments as we= ll - just the same as you say RPL works in some deployments.


JP> I do not not think that we should go in a RPL versus Load-NG de= bate but rather try to find a good solution for MANET. That being
said, RPL *for* LLNs the the result of a 4-year work with a DT, weekly= calls, interim WG meetings to make it work in LLNs.

[Jon] I did not cast this as a RPL vs LOADng debate - you just did.  I= am saying that LOADng works in some scenarios and proof is the EDF deploym= ent in their AMI network.

JP2> I would be happy to see detailed results and especially the us= er traffic profiles for the reason exposed above.

[Jon2] JP actually it doesn't matter!  You say that you CANNOT build a= working LLN using a reactive protocol.  EDF has proved that wrong.&nb= sp; They built one.  You can continue to claim that you can't, but the= re is an existence proof.

JP3> You keep ignoring my point. Of it matters. I would even make i= t work with BGP-4. Would you recommend the use of BGP in LLN ?
If you deploy a protocol in very specific conditions that do not apply= to most LLNs, then you may want to know it before making it an RFC.



Please share your results.  You keeps saying you will and you we= keep asking you to - where's the results so they can be reviewed.


JP> Once again, I would first like to hear chair's decision. PLEASE= note that I would be happy to see Load's results too. And just be
patient, I just need to find a bit of time to compile results and you = will get many results backing up my claims. Please also refer to the
number of discussions prior to designing RPL that took place on the RO= LL mailing list. Believe me there was a reason not NOT choosing
a reactive protocol for LLN (again I am NOT against reactive routing f= or other use cases at all). Would you ignore the findings of a WG
that worked for 4 years on the subject matter ? I guess not =85 Just t= rying to raise my voice (as many others on this list) to protect the
Internet.

[Jon] As others have said - you have it backwards.  If you have data t= hat would show that LOADng or a reactive protocol will not work in MANETs p= lease share it. 

JP2> Please reread what I wrote ten times =85 I said "LLNs&quo= t; not "MANET" in general. On top of that, I do prefer the option= 1) for the reasons exposed 
before (this is the WG document, Charlie made it compatible + othe= r technical reasons).

You did say LLNs but again you are wrong.  There are plenty of LLNS th= at have been built using reactive (and proactive) protocols and will contin= ue to be built using reactive (and proactive protocols).  There is no = one size fits all.

I prefer to have a debate based on facts and not conjecture and based on te= chnical arguments.

That would be
very insightful and would help guide this discussion and decision.  It= would not be prudent to make a decision and then bring out data that would= try to suggest that the decision was incorrect.

What findings are you referring to?  Where is there a WG document that= documents these findings?

[Jon2] I noticed you skipped this. 

JP3> I do not skip anything. I am respectful of the question asked = by the chair, knowing that their task is to say the least not easy.
As soon as required, I will provide lots of data, at least the ones th= at can be shared, if authorization is given by the owners of these
networks.

 

Thanks.

JP.

Jon


From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@i= etf.org>; "thierr= y.lys@erdfdistribution.fr" <thierry.lys@erdfdistribution.fr>
Sent: Wednesday, October 31= , 2012 4:09 PM
Subject: Re: [manet] (no su= bject)


On Oct 31, 2012, at 6:57 PM, Jon Black wrote:

On October 31, 2012 Thierry.Lys wrote:

I speak in the name of EDF group.

We started first to use LOAD as a rout= ing algorithm and deployed 2000 PLC-meters for smart grid purposes in 2011.= Taking advantage of this field test, we have been actively participating t= o the working group to adopt enhancements in the LOADng specification.
We are now extremely pleased with what= LOADng is capable of and are confident that future deployements will be eq= uipped with it. 

This would seem to indicate that LOADng does work and in a rather large dep= loyment.

JP> No this means that LoadNG works in *a* network. But the major t= echnical difference here is that reactive routing is highly impacted
by the user traffic =85 If you poll a meter every 24 hours, it may wor= k perfectly well. Now if you start having more frequent traffic flows
you can either cache paths (ending up with more frequent broken paths = considering how flappy these networks are, thus leading to more
floods =85 very undesirable =85 especially when you have hundreds of m= eters sharing a few Kbits/s) or you use short cache timers and you
keep flooding :-( If you take actual traces of these networks (both us= ing 15.4g and P1901.2) and you start adjusting the user traffic rate you
immediately see the issues in terms of scalability. Yes you can try to= mitigate the undesirable flooding effect to some extends but showing =
the limits in terms of scalability is easy to show. Note that I MOT ag= ainst reactive routing by any means, this is IMO just not applicable to
LLNs unless the traffic flows are deterministic and very well knows = =85 Lessons from the past show us how difficult it is to predict user =
applications. We all started with meter reading to continue with that = example and now many utilities wants to use these smart metering 
networks for a number of applications which different SLA, =85 

Hope this helps. Once again, when/if required I would be happy to shar= e many results.



"We believe in rough consensus an= d running code"

rough consensus : Don't you think we h= ave a rough consensus on LOADng compared to DYMO ? 10 authors and major com= panies are supporters of LOADng.

running code : interoperability has be= en checked with 4 sources and other implementations are in progress.

Obviously from the list we don't ha= ve rough consensus.  We have two alternatives each with proponents.&nb= sp; The WG should weigh the technical benefits (design, implementation/runn= ing code, maturity)  of each and the group should choose a path forward.

In my opinion option 3 is not an option - this is the working group shirkin= g its responsibility.

This is an option =85 since listed by the chairs. I agree that we shou= ld avoid it, especially when I think we have a very reasonable solution
(option1).

JP.


Jon

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet






_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet




_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_97B69B30E0EF244B940B65EA541E3F2D2157619CDBXPRD0510MB395_-- From abdussalambaryun@gmail.com Sun Nov 4 04:43:28 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A848221F8453 for ; Sun, 4 Nov 2012 04:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.457 X-Spam-Level: X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNqMw32DSxgF for ; Sun, 4 Nov 2012 04:43:28 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B88121F8451 for ; Sun, 4 Nov 2012 04:43:28 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so5662237vbb.31 for ; Sun, 04 Nov 2012 04:43:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JQ6APv+lU0rlqy2ey0RYp4vgJDbmpSt0PcwA/fd4d6o=; b=TAW2Ii7vQoqpBwQAYVznNCqjzmO27ubdmti50JxyooRDheY36ycCLNSRRthU9rkeeF S/O4FcTAXBGQUyoBusq00ywz6J/28KAwlIJ//FvyTJ0Vi1XyvbnVuC4zwijs6mKvOvwT izBLU+LS7/30q7aTLhH2XsOg0U1d4CHXTG3XXRq6Pj8gPQUcpz9hLMxy28dcZD3DXiqQ OtY+7fZEJqLwJ+fZy6+F2E+O5xb9DhjqppTDgaCTbseT0eTbMfVvU+F1KjbrK/AVaMgu 4yEturhmoHRrkU9Kc3rG0OLV3MLhbs3JxeOgN+LT8uUSn2YRmcU9oFWpGRck88+1WG+c dXqw== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr6050620vdv.20.1352033007512; Sun, 04 Nov 2012 04:43:27 -0800 (PST) Received: by 10.220.204.9 with HTTP; Sun, 4 Nov 2012 04:43:26 -0800 (PST) In-Reply-To: <408541807.197885.1351941503916.JavaMail.root@mail17.pantherlink.uwm.edu> References: <0A918FF2-302F-4C6E-A8E3-85F357209DB6@gmail.com> <408541807.197885.1351941503916.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Sun, 4 Nov 2012 13:43:26 +0100 Message-ID: From: Abdussalam Baryun To: Mukul Goyal Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org List" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 12:43:28 -0000 I agree to focus on our work flow and give the priority/chance to the WG documents to process its progress without interrupts. There was no announcements of interrupts authority, there is no reason to rush nor to kill this valuable WG item. I agree to give chance to authors of Dymo and participants to make this WG draft better for progress (not later than 3 months). AB On 11/3/12, Mukul Goyal wrote: > Give Charlie a chance! It is not too hard, esp for some one lie Charlie, = to > significantly improve a document's readability etc. in one edit cycle. > > Thanks > Mukul > > ----- Original Message ----- > From: "Christopher Dearlove" > To: "JP Vasseur (jvasseur)" > Cc: "Axel Colin de Verdi=E8re" = , > "manet@ietf.org List" > Sent: Saturday, November 3, 2012 6:07:06 AM > Subject: Re: [manet] A proposal - differentiating the document > and the protocol > > > > Sunk cost fallacy. It's not important how much work was spent on a docume= nt. > What matters is what state the document is in. > > -- > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) > > On 3 Nov 2012, at 08:36, "JP Vasseur (jvasseur)" < jvasseur@cisco.com > > wrote: > > From abdussalambaryun@gmail.com Sun Nov 4 04:47:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3C321F86AD for ; Sun, 4 Nov 2012 04:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daC8VxGtLVvH for ; Sun, 4 Nov 2012 04:47:59 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0D621F8619 for ; Sun, 4 Nov 2012 04:47:58 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so5604095vcb.31 for ; Sun, 04 Nov 2012 04:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uR7BhIvfIl+mE8yOM5eAdA6h/RL+5bZl7i6+Xm39zuw=; b=SHTNaFXAirgkyIKpb57+U0H0nJq0SyXPxqexzRDjZ3rRFPNHv7Smxn0VOOWZQiTXrs YswlkRYm/3ULqOFuPYu2H1CNI8B+CPIO6OSJX04YM17YABiglaeE65f8z79yFdql0kxG Peo+fKovM51lZtDX9x2QTcDm9YA/1LQmAVK39g4ARXAMkUd/YF8ZtlVJAGH6Mhh7RjUb 0zOdAp8CIP5gyjUeMKYI90VwCYopQ5j7YixyBfRe7WUG54PVtrz9IWQqBhXoA1b4XE9X Fy5Q/mFeELzg71HTyYJBn3ipDTuEy7ivffOMZpSs40eiDm3gqO3wGp+9FS6/Q9g9TRir HtPQ== MIME-Version: 1.0 Received: by 10.220.142.8 with SMTP id o8mr6859821vcu.23.1352033278498; Sun, 04 Nov 2012 04:47:58 -0800 (PST) Received: by 10.220.204.9 with HTTP; Sun, 4 Nov 2012 04:47:58 -0800 (PST) In-Reply-To: <76DC788D-9525-4C54-AC67-894E10C38CE3@gmail.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <5E3CC77A-4FA1-4C15-9536-306917AA8B13@gmail.com> <9A087194-7787-4724-96FA-30511FE9DFC9@gmail.com> <76DC788D-9525-4C54-AC67-894E10C38CE3@gmail.com> Date: Sun, 4 Nov 2012 13:47:58 +0100 Message-ID: From: Abdussalam Baryun To: Christopher Dearlove Content-Type: text/plain; charset=ISO-8859-1 Cc: "Timothy J. Salo" , "manet@ietf.org" , Philip Levis Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 12:47:59 -0000 On 11/4/12, Christopher Dearlove wrote: > In order to avoid confusion, OLSRv2 and NHDP use the term responsive for > things that respond to circumstances. Not the same as reactive in the AODV > sense, but (used in forms like exponentially backed off message intervals) > not entirely unrelated either. > The confusion is because MANET WG still don't have a terminology RFC. The WG definitions states are dynamic or mobile like MANETs. AB From abdussalambaryun@gmail.com Sun Nov 4 04:57:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C5E21F850B for ; Sun, 4 Nov 2012 04:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYmcegYibr5C for ; Sun, 4 Nov 2012 04:57:10 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C4CD921F850A for ; Sun, 4 Nov 2012 04:57:10 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so5607861vcb.31 for ; Sun, 04 Nov 2012 04:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TdImbTftnNfujiw0fgbEokHRfoQan5iycV9FoBZG/Jg=; b=ZfRDKSd/J8RgusTDrxb+sd+h9IQppfcWmwWxWJK9khzo17HYljHwCdWdYyC7JtN/xm 4aAI6r7CJC8LVl0gLsHDvvAVaNcaAGMIIiMFH/GlaUAck/KeIzMmm2tqYVpj2NQbyz/d B7vZnjZgKZBc4nwtFkbMNqZ5sz8s5dF5jMa3OGhYjZV4xLjx0mUtqsYXHWzkzHYlSqnJ t59HgLQJBo8n1+ezqjfPDOUpnOZhlPGviZVPrLtRlixM6t3mBdH/Q0hPwBHsReKEyjOw ykUicNm4FDZHR4698B4ZrEe5xduJvx/R1vYBrDuxEtjQ9YGYmB73DviY9785Yn4nX62U cadA== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr6067440vdv.20.1352033830311; Sun, 04 Nov 2012 04:57:10 -0800 (PST) Received: by 10.220.204.9 with HTTP; Sun, 4 Nov 2012 04:57:10 -0800 (PST) In-Reply-To: References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> Date: Sun, 4 Nov 2012 13:57:10 +0100 Message-ID: From: Abdussalam Baryun To: Joseph Macker Content-Type: text/plain; charset=ISO-8859-1 Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 12:57:11 -0000 Hi Joe, My question was always as the subject claims; Where does LOADng Work, please give me a reference document of performance and practice? Please note that the authors were asked about this before in MANET WG but the answer was we cannot provide information because classified. This is confusing and without progress. I still don't beleive that LOADng deployments fit MANETs' applicabilities. Therefore, disagree with the subject claimed (i.e. LOADng works). Let us focus the question for our charter; Does the LOADng work with MANETs scenarios and applicabilities or does the LOADng work only for special cases of MANET scenarios. I remember your input to the LOADng presenter in one f2f meeting to include heterogeniety to this protocol. I think LOADng should be modified to be suitable without confusions to fit MANETs. AB On 11/3/12, Joseph Macker wrote: > Again I would ask that we move ROLL and LLN discussions to ROLL if people > want to continue. > JP your opinion to the WG chairs is pretty obvious. > > We need some bandwidth to discuss quality of documents and authors > agreement to various other WG issues. > I will provide some questions to that effect shortly. Let us focus on our > WG's challenges. > > -Joe > > From abdussalambaryun@gmail.com Sun Nov 4 05:08:27 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E8121F8446 for ; Sun, 4 Nov 2012 05:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61WWO536RXbb for ; Sun, 4 Nov 2012 05:08:27 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 53AB621F843D for ; Sun, 4 Nov 2012 05:08:27 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so5613343vcb.31 for ; Sun, 04 Nov 2012 05:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=eCmsXk/OH0kifgQdAZAtYvl5In+9RQjFjSoHABx/DxU=; b=IbU/HGFfpb/nfgRg9CF4uSDgo9C4nAFbscjLg81cTnwsKucKZ+k/Ussi9CihqCtQaR Akyj4eIq68qmQ9P9AE1Y7NXOeUmdfhwLbR4kNPkOLBywpwZ6RQ5KXDk0S2T1xKld6hz4 f61L6UeXEPKThXgyjMePVPYGpmP0tBREXOpYAIx7QLfUjWfu13S7huBRFXVSj90Obugj 0yyUaufTmeS3Vc3JAtvjpYGouwtYz+jU7mkxslixhQT0LGI1T11dl6ua4hGXpK8miBJT 6fLvxynHtEOJLKW69aGzsoQa7NAH2GKoFDBvp/M5aH+6Spv+FWZerl0OaBAZ4GLNUTrH d4dw== MIME-Version: 1.0 Received: by 10.58.143.12 with SMTP id sa12mr7041141veb.43.1352034506872; Sun, 04 Nov 2012 05:08:26 -0800 (PST) Received: by 10.220.204.9 with HTTP; Sun, 4 Nov 2012 05:08:26 -0800 (PST) Date: Sun, 4 Nov 2012 14:08:26 +0100 Message-ID: From: Abdussalam Baryun To: "jpmacker@gmail.com" , Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: [manet] DYMO Milestone date X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 13:08:28 -0000 Dear MANET Chairs, Please note that I already requested on the MANET-list to provide our WG draft dymo a milestone date, but still you did n't update or even respond. Please note that this will be my last reminder, and I will send a complain as procedure satates if you continue to ignore such input. Best Regards Abdussalam Baryun From abdussalambaryun@gmail.com Sun Nov 4 05:14:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5FB21F869A for ; Sun, 4 Nov 2012 05:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ev3IrL-4msV6 for ; Sun, 4 Nov 2012 05:14:26 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3577321F8698 for ; Sun, 4 Nov 2012 05:14:20 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so5675684vbb.31 for ; Sun, 04 Nov 2012 05:14:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dXfCGc03XxS0HcwD1Nsf4c/0VW0vJefbzXHBY6MGEn4=; b=iu09Ci7YLvgYqPI7GU4h4ND0Y5quc+I+KSggYPSo/OPrCc5LDEJ8TgkGF/ihW1k/7F cgEkjaSKw8DNPBPBTjcE6iCkWlqmUz96BzYqggCI7N0VQgM1ISaBKD95vsmlRCy0Lw9D vGtdHVQ+DwOaGusEDdtp/OPlDCpLNM9Z70hHe2vpZqnoSFSebLiz3tBgv89C0oHtBdqM kVE55XjAqyA1RNXrXRr6E3JtbCHBHh4cbZJvEY5kXLZS7CYr1H8OxCBkHXpX40+SizK4 Je0Lj4dYCF1iaEK5Q8DX3gV0vlhjxUYORWyOKYN6rbqVYIeMZ+tbz04Exd4oZkdMFsmI MsVw== MIME-Version: 1.0 Received: by 10.58.137.7 with SMTP id qe7mr7106775veb.23.1352034859754; Sun, 04 Nov 2012 05:14:19 -0800 (PST) Received: by 10.220.204.9 with HTTP; Sun, 4 Nov 2012 05:14:19 -0800 (PST) In-Reply-To: References: Date: Sun, 4 Nov 2012 14:14:19 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , Benoit Claise , manet@ietf.org Subject: Re: [manet] Management use cases for MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 13:14:27 -0000 Hi Ulrich, I support that each Mib draft to provide with its management use cases (within a section) for its MANETs applicability. Proactive applicabilities are not similar to Reactive applicabilities. AB On 11/2/12, Ulrich Herberg wrote: > Hi [manet] participants, > > I am forwarding an email from Benoit that was sent to coman@ietf.org, since > it concerns MANET. COMAN is a new activity (not yet a WG) relating to > management of constrained devices and networks. As I mentioned at the last > IETF, Benoit cleared his DISCUSS on the NHDP-MIB if we commit to write a > document about applicability and use cases of management of MANET routers. > > In COMAN, an individual ID was presented > (draft-ersue-constrained-mgmt) that discusses use cases of management. Note > that this is an early draft and will possibly be split in multiple drafts. > There is some discussion whether that should include mobility or not > (currently, MANET is excluded but mesh networks are not, which I think > needs some more discussion, as both are about dynamic topologies). Anyway, > similar to Benoit, it is unclear to me whether this draft or any work in > COMAN (if it was to become a WG) would satisfy the request for a use > case/applicability document, or if MANET should work on a separate draft. > > As the next OLSRv2-MIB revision will be submitted next Monday, (which I > consider ready for WGLC) this is something we need to seriously consider. > > Opinions? > > Thanks > Ulrich > > On Fri, Nov 2, 2012 at 4:45 AM, Benoit Claise wrote: > >> Hi, >> >> One point regarding MANET. >> I believe that it deserves its own document: "MANET network management >> considerations". Actually, when looking at draft-ietf-manet-nhdp-mib part >> of the IESG review, one of the outcome was that such a document was >> required. >> I cleared my DISCUSS on draft-ietf-manet-nhdp-mib with this COMMENT >> >> Note regarding the applicability statement: This is solved, as we >> discussed, but I'll keep this little sentence in one >> corner of my head "A fuller discussion of MANET network management use >> cases and challenges will be provided elsewhere." >> >> How/If this "MANET network management considerations" draft relates to >> the draft-ersue-constrained-mgmt, I'm not sure at this point in time. >> >> > From ulrich@herberg.name Sun Nov 4 05:17:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C7821F8698 for ; Sun, 4 Nov 2012 05:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1w9mWG9LFSut for ; Sun, 4 Nov 2012 05:17:52 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BDF1521F85F0 for ; Sun, 4 Nov 2012 05:17:51 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so5617676vcb.31 for ; Sun, 04 Nov 2012 05:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uO6gROAoXPNFvT55TYFUrlA53e1lvUNzCfP1XiaHTLE=; b=1+ku3JqPK8rIfI+RYAgbOsUOtZVHxCoLMpaOpOzl6adtxXj8msn+dvZ25g+kbrXmye r3WE4On+8mbQyDqso3UBTosn8zPkfqsOvxukeLHzy9W1IfANg5pjx3eoASJwkdgOSTbe TzEfUq//UkSX0g6de1PIhKFbrPz52otFRUfOk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=uO6gROAoXPNFvT55TYFUrlA53e1lvUNzCfP1XiaHTLE=; b=hUi5X9tZLr66sb6JK/OfUUP8hIMcDFHn3bymR/8sMXI/cTjsLeimF8AvldIRsemvLv WT1YhuTdIgOyYXFjdWySCiTJvZDyjHrFweCONjYjI3w99LZq9EVC6idjLmJgSh0RxIAy XvK0OKNeCJVJsgJzImRVXVxf16L/MdJX0zTVmNNVHxP+pyNOqnh/FmLkTp5XZWOLuGQp COYPPOMRYKZEx1fYDikL0/ZWENHU80TMxGr7M0omNzru9aUCev8mBf4K6uUgVfzIC3wo FgeOjLrnu3tTUVs85SR3nXmhNho4PrBfqxinzTP4ySjBQuuPnqPqxCr48SQ33CsEZeVQ 2yOA== MIME-Version: 1.0 Received: by 10.52.89.146 with SMTP id bo18mr5895572vdb.33.1352035071118; Sun, 04 Nov 2012 05:17:51 -0800 (PST) Received: by 10.58.94.103 with HTTP; Sun, 4 Nov 2012 05:17:51 -0800 (PST) In-Reply-To: References: Date: Sun, 4 Nov 2012 05:17:51 -0800 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=bcaec50162b5234dfc04cdab3255 X-Gm-Message-State: ALoCoQkrWUI0edw/RwXBZbwk308uSoBVt1fdRRVgVjM2vSiisEsoKi1M7V3/GQ2PFdE0z0IluHsI Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , Benoit Claise , manet@ietf.org Subject: Re: [manet] Management use cases for MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 13:17:53 -0000 --bcaec50162b5234dfc04cdab3255 Content-Type: text/plain; charset=ISO-8859-1 Abdussalam, Benoit's request was for a dedicated MANET use case draft *in addition* to a shorter applicability section in each MIB document. Best regards Ulrich On Sun, Nov 4, 2012 at 5:14 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Ulrich, > > I support that each Mib draft to provide with its management use cases > (within a section) for its MANETs applicability. Proactive > applicabilities are not similar to Reactive applicabilities. > > AB > > On 11/2/12, Ulrich Herberg wrote: > > Hi [manet] participants, > > > > I am forwarding an email from Benoit that was sent to coman@ietf.org, > since > > it concerns MANET. COMAN is a new activity (not yet a WG) relating to > > management of constrained devices and networks. As I mentioned at the > last > > IETF, Benoit cleared his DISCUSS on the NHDP-MIB if we commit to write a > > document about applicability and use cases of management of MANET > routers. > > > > In COMAN, an individual ID was presented > > (draft-ersue-constrained-mgmt) that discusses use cases of management. > Note > > that this is an early draft and will possibly be split in multiple > drafts. > > There is some discussion whether that should include mobility or not > > (currently, MANET is excluded but mesh networks are not, which I think > > needs some more discussion, as both are about dynamic topologies). > Anyway, > > similar to Benoit, it is unclear to me whether this draft or any work in > > COMAN (if it was to become a WG) would satisfy the request for a use > > case/applicability document, or if MANET should work on a separate draft. > > > > As the next OLSRv2-MIB revision will be submitted next Monday, (which I > > consider ready for WGLC) this is something we need to seriously consider. > > > > Opinions? > > > > Thanks > > Ulrich > > > > On Fri, Nov 2, 2012 at 4:45 AM, Benoit Claise wrote: > > > >> Hi, > >> > >> One point regarding MANET. > >> I believe that it deserves its own document: "MANET network management > >> considerations". Actually, when looking at draft-ietf-manet-nhdp-mib > part > >> of the IESG review, one of the outcome was that such a document was > >> required. > >> I cleared my DISCUSS on draft-ietf-manet-nhdp-mib with this COMMENT > >> > >> Note regarding the applicability statement: This is solved, as we > >> discussed, but I'll keep this little sentence in one > >> corner of my head "A fuller discussion of MANET network management use > >> cases and challenges will be provided elsewhere." > >> > >> How/If this "MANET network management considerations" draft relates to > >> the draft-ersue-constrained-mgmt, I'm not sure at this point in time. > >> > >> > > > --bcaec50162b5234dfc04cdab3255 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Abdussalam,

Benoit's request was for a dedicated MAN= ET use case draft *in addition* to a shorter applicability section in each = MIB document.

Best regards
Ulrich

On Sun, Nov 4, 2012 at 5:14 AM, Abdussalam B= aryun <abdussalambaryun@gmail.com> wrote:
Hi Ulrich,

I support that each Mib draft to provide with its management use cases
(within a section) for its MANETs applicability. Proactive
applicabilities are not similar to Reactive applicabilities.

AB

On 11/2/12, Ulrich Herberg <ulric= h@herberg.name> wrote:
> Hi [manet] participants,
>
> I am forwarding an email from Benoit that was sent to coman@ietf.org, since
> it concerns MANET. COMAN is a new activity (not yet a WG) relating to<= br> > management of constrained devices and networks. As I mentioned at the = last
> IETF, Benoit cleared his DISCUSS on the NHDP-MIB if we commit to write= a
> document about applicability and use cases of management of MANET rout= ers.
>
> In COMAN, an individual ID was presented
> (draft-ersue-constrained-mgmt) that discusses use cases of management.= Note
> that this is an early draft and will possibly be split in multiple dra= fts.
> There is some discussion whether that should include mobility or not > (currently, MANET is excluded but mesh networks are not, which I think=
> needs some more discussion, as both are about dynamic topologies). Any= way,
> similar to Benoit, it is unclear to me whether this draft or any work = in
> COMAN (if it was to become a WG) would satisfy the request for a use > case/applicability document, or if MANET should work on a separate dra= ft.
>
> As the next OLSRv2-MIB revision will be submitted next Monday, (which = I
> consider ready for WGLC) this is something we need to seriously consid= er.
>
> Opinions?
>
> Thanks
> Ulrich
>
> On Fri, Nov 2, 2012 at 4:45 AM, Benoit Claise <bclaise@cisco.com> wrote:
>
>> =A0Hi,
>>
>> One point regarding MANET.
>> I believe that it deserves its own document: "MANET network m= anagement
>> considerations". Actually, when looking at draft-ietf-manet-n= hdp-mib part
>> of the IESG review, one of the outcome was that such a document wa= s
>> required.
>> I cleared my DISCUSS on draft-ietf-manet-nhdp-mib with this COMMEN= T
>>
>> Note regarding the applicability statement: This is solved, as we<= br> >> discussed, but I'll keep this little sentence in one
>> corner of my head "A fuller discussion of MANET network manag= ement use
>> cases and challenges will be provided elsewhere."
>>
>> =A0How/If this "MANET network management considerations"= draft relates to
>> the draft-ersue-constrained-mgmt, I'm not sure at this point i= n time.
>>
>>
>

--bcaec50162b5234dfc04cdab3255-- From abdussalambaryun@gmail.com Sun Nov 4 05:33:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D8B21F85DD for ; Sun, 4 Nov 2012 05:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5stD3C+zDIFh for ; Sun, 4 Nov 2012 05:33:54 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 36C8021F8587 for ; Sun, 4 Nov 2012 05:33:54 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so5684697vbb.31 for ; Sun, 04 Nov 2012 05:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+a4m56toQ4xROJyTnRII6B24+Qa9WYR80yWTsRi8AZs=; b=h7/5E/olqKSit+sezmhSAvUS2IIb1zdmRVzZgSEcnyVtFqhJaWoRpwgUpzfcsn14od 7QbM8KvSVh9Z1RPW++mQLHub3QxBUbULZiS76O8pTtJG4Yzdxix6B7DvwGRZzcNyYqa9 dvzwojMVDidmTAaLpPyFWHNDU0pqZckO/0MoukPIBEJdTrizNsQUO0ajVcarWpA/OzWE MHoQQAQslOFHJzQMl7l3UjAVnbe3wT/gUOqHlL1usM/6nCyAZRSVWrFQ69HyIzLPs6pt kRgrVL/hidPr6xPNQ6pTGTFrlPuD7LiyAs4eC+uJ0YDiAf/1yzb0s5Bsg8AWYjUgUfNi fF4Q== MIME-Version: 1.0 Received: by 10.52.35.82 with SMTP id f18mr5939423vdj.99.1352036033721; Sun, 04 Nov 2012 05:33:53 -0800 (PST) Received: by 10.220.204.9 with HTTP; Sun, 4 Nov 2012 05:33:53 -0800 (PST) In-Reply-To: References: Date: Sun, 4 Nov 2012 14:33:53 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , Benoit Claise , manet@ietf.org Subject: Re: [manet] Management use cases for MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 13:33:55 -0000 Hi Ulrich, I think making one draft submitted for management of use case for MANETs is not suitable now until we finish the charter requirements of a standard Proactive and a standard Reactive. After that phase with both RFCs including RFC2501 we will be able to identify many related issues. I recommend the start but the WGLC of this draft should be only after finishing the both RFCs requirements. AB On 11/4/12, Ulrich Herberg wrote: > Abdussalam, > > Benoit's request was for a dedicated MANET use case draft *in addition* to > a shorter applicability section in each MIB document. > > Best regards > Ulrich > > On Sun, Nov 4, 2012 at 5:14 AM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> Hi Ulrich, >> >> I support that each Mib draft to provide with its management use cases >> (within a section) for its MANETs applicability. Proactive >> applicabilities are not similar to Reactive applicabilities. >> >> AB >> >> On 11/2/12, Ulrich Herberg wrote: >> > Hi [manet] participants, >> > >> > I am forwarding an email from Benoit that was sent to coman@ietf.org, >> since >> > it concerns MANET. COMAN is a new activity (not yet a WG) relating to >> > management of constrained devices and networks. As I mentioned at the >> last >> > IETF, Benoit cleared his DISCUSS on the NHDP-MIB if we commit to write >> > a >> > document about applicability and use cases of management of MANET >> routers. >> > >> > In COMAN, an individual ID was presented >> > (draft-ersue-constrained-mgmt) that discusses use cases of management. >> Note >> > that this is an early draft and will possibly be split in multiple >> drafts. >> > There is some discussion whether that should include mobility or not >> > (currently, MANET is excluded but mesh networks are not, which I think >> > needs some more discussion, as both are about dynamic topologies). >> Anyway, >> > similar to Benoit, it is unclear to me whether this draft or any work >> > in >> > COMAN (if it was to become a WG) would satisfy the request for a use >> > case/applicability document, or if MANET should work on a separate >> > draft. >> > >> > As the next OLSRv2-MIB revision will be submitted next Monday, (which I >> > consider ready for WGLC) this is something we need to seriously >> > consider. >> > >> > Opinions? >> > >> > Thanks >> > Ulrich >> > >> > On Fri, Nov 2, 2012 at 4:45 AM, Benoit Claise >> > wrote: >> > >> >> Hi, >> >> >> >> One point regarding MANET. >> >> I believe that it deserves its own document: "MANET network management >> >> considerations". Actually, when looking at draft-ietf-manet-nhdp-mib >> part >> >> of the IESG review, one of the outcome was that such a document was >> >> required. >> >> I cleared my DISCUSS on draft-ietf-manet-nhdp-mib with this COMMENT >> >> >> >> Note regarding the applicability statement: This is solved, as we >> >> discussed, but I'll keep this little sentence in one >> >> corner of my head "A fuller discussion of MANET network management use >> >> cases and challenges will be provided elsewhere." >> >> >> >> How/If this "MANET network management considerations" draft relates >> >> to >> >> the draft-ersue-constrained-mgmt, I'm not sure at this point in time. >> >> >> >> >> > >> > From drdanhe@gmail.com Sun Nov 4 05:35:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE3021F85DF for ; Sun, 4 Nov 2012 05:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIOFdPEqP-sC for ; Sun, 4 Nov 2012 05:35:13 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F38821F85DD for ; Sun, 4 Nov 2012 05:35:13 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id u46so2464391wey.31 for ; Sun, 04 Nov 2012 05:35:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UbCyPQv4DtS8++iEpA65JJtGhlxMoFW+p9JFFBapBLE=; b=pgFTP3PfMmkREjRLzb+pC4B6kN1/QvtAvB1SWczb7R+zI3x0hfjix6eiq8QD1EVYQl I0bL0av7AaDN6xMcJE39ie+H881f5BNMSpLX9g7a6igVlC+Ba/jmDc/78THk0WbC6OfC i7ffm7UCexXRrgrz0M5MYNevEw3HwykkFvddcZ9Z4Eka3tcnCv1CoBtMvJsINFSMPJqV ITODJjUoR9llL3ZevctDlw9h28GP3UsV11O60z1ZrLh1sVMcVWCHSG93bqRRsqZ1VMty COAJeHiiTQyk8xhOQDNUFJcJEQ/HK/1uiRmeU2q7DIRn9+6DOgqQSR+jRjE2VyCo2nTR aksg== MIME-Version: 1.0 Received: by 10.180.14.73 with SMTP id n9mr9491408wic.15.1352036112589; Sun, 04 Nov 2012 05:35:12 -0800 (PST) Received: by 10.194.59.71 with HTTP; Sun, 4 Nov 2012 05:35:12 -0800 (PST) In-Reply-To: References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> Date: Sun, 4 Nov 2012 13:35:12 +0000 Message-ID: From: Daniel He To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=f46d04138cbb36e51d04cdab706b Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 13:35:14 -0000 --f46d04138cbb36e51d04cdab706b Content-Type: text/plain; charset=ISO-8859-1 > I still don't beleive that LOADng deployments fit MANETs' > applicabilities. Therefore, disagree with the subject claimed (i.e. > LOADng works). > > I totally disagree! LOADng is fitting to MANET. fundamentally it is lightweighted AODV. --f46d04138cbb36e51d04cdab706b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I still don't beleive that LOADng deployments fit MANETs'
applicabilities. Therefore, disagree with the subject claimed (i.e.
LOADng works).

I totally disagree!=A0 LOADng is fitting to MANET. fu= ndamentally
it is lightweighted AODV.

--f46d04138cbb36e51d04cdab706b-- From jvasseur@cisco.com Sun Nov 4 06:16:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B2121F86C8 for ; Sun, 4 Nov 2012 06:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.435 X-Spam-Level: X-Spam-Status: No, score=-10.435 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lT3VW+rVSHcm for ; Sun, 4 Nov 2012 06:16:34 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5E14621F86C7 for ; Sun, 4 Nov 2012 06:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2562; q=dns/txt; s=iport; t=1352038594; x=1353248194; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vEJy8lTB1oYp1imqwrVKHHYzEfH13qHr6u0gseoYM/s=; b=fAX+t4aIArdlvyTXjVi/9corRhqQugGfCtDmt7yrH2ztsmulKUrl9R3g Uvz0jLmnh1idAsmTH35EhOAulfMeeByBzBzSrD8B0z02GKawb+veX9uwO IRkige/cARRXs0iQVIX1hCQrKDCT1tyh0vq0r/awsp7mivlDaXhY+zl29 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMt3llCtJXG//2dsb2JhbABEwzmBCIIfAQEEAQEBDwFbCxACAQgEAQkUHQcnCxQRAgQOBQgah2gLmTKMHpJwBIwBhVthA4glnC+Ba4Jvghk X-IronPort-AV: E=Sophos;i="4.80,710,1344211200"; d="scan'208,217";a="138659805" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 04 Nov 2012 14:16:30 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA4EGT1R031348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 Nov 2012 14:16:30 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 08:16:29 -0600 From: "JP Vasseur (jvasseur)" To: Daniel He Thread-Topic: [manet] LOADng works Thread-Index: AQHNuF9dW2UMul6sMEaXNf6TARakEQ== Date: Sun, 4 Nov 2012 14:16:28 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772205284E@xmb-rcd-x02.cisco.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.74.41] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19338.004 x-tm-as-result: No--36.921600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772205284Exmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 14:16:35 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772205284Exmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Nov 4, 2012, at 8:35 AM, Daniel He wrote: I still don't beleive that LOADng deployments fit MANETs' applicabilities. Therefore, disagree with the subject claimed (i.e. LOADng works). I totally disagree! LOADng is fitting to MANET. fundamentally it is lightweighted AODV. Here is my take on this; *if* there is a choice for option 1, 2 or may be a= brand new document related to reactive routing in MANET (protocol called AODVv20, and excluding LLNs, the= n I think that we do not have any issue. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772205284Exmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <2EBA56AC61CB404485916645A598CF06@cisco.com> Content-Transfer-Encoding: quoted-printable
On Nov 4, 2012, at 8:35 AM, Daniel He wrote:


I still don't beleive that LOADng deployments fit MANETs'
applicabilities. Therefore, disagree with the subject claimed (i.e.
LOADng works).

I totally disagree!  LOADng is fitting to MANET. fundamentally it is lightweighted AODV.

Here is my take on this; *if* there is a choice for option 1, 2 or may= be a brand new document related to
reactive routing in MANET (protocol called AODVv20, and excluding LLNs= , then I think that we do not 
have any issue.


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A772205284Exmbrcdx02ciscoc_-- From adrian@olddog.co.uk Sun Nov 4 06:28:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4493421F860D for ; Sun, 4 Nov 2012 06:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLxpTHgNL6TO for ; Sun, 4 Nov 2012 06:28:58 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC4621F85F0 for ; Sun, 4 Nov 2012 06:28:58 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id qA4ESqup015019; Sun, 4 Nov 2012 14:28:52 GMT Received: from 950129200 (dhcp-13b5.meeting.ietf.org [130.129.19.181]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id qA4ESkvI015005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 4 Nov 2012 14:28:50 GMT From: "Adrian Farrel" To: "'Abdussalam Baryun'" , , "'Stan Ratliff'" References: In-Reply-To: Date: Sun, 4 Nov 2012 14:28:47 -0000 Message-ID: <001001cdba98$b6b03910$2410ab30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGMZr/VpxB6vfMTepOesOMFZ6HeZJhcYczA Content-Language: en-gb Cc: 'manet' Subject: Re: [manet] DYMO Milestone date X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 14:28:59 -0000 Hey Abdussalam, You are right that a milestone will be needed. But do you think that it might be a good idea to wait for the resolution of the current WG discussion about AODVv2 before determining a milestone. For example, if option 3 is selected, we clearly don't need a milestone. And the choice of starting point is also going to affect the delivery. I see no value in setting an artificial project management deadline, and I see no value in setting it without being able to do the necessary planning tasks. Adrian > -----Original Message----- > From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: 04 November 2012 13:08. > To: jpmacker@gmail.com; Stan Ratliff > Cc: manet; adrian > Subject: DYMO Milestone date > > Dear MANET Chairs, > > Please note that I already requested on the MANET-list to provide our > WG draft dymo a milestone date, but still you did n't update or even > respond. Please note that this will be my last reminder, and I will > send a complain as procedure satates if you continue to ignore such > input. > > Best Regards > Abdussalam Baryun From drdanhe@gmail.com Sun Nov 4 06:58:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7354221F8452 for ; Sun, 4 Nov 2012 06:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6V7qMwZR3G0 for ; Sun, 4 Nov 2012 06:58:11 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92B1721F8451 for ; Sun, 4 Nov 2012 06:58:10 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id hq12so2025457wib.13 for ; Sun, 04 Nov 2012 06:58:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N13B3UhXtvJgyQtX+IqrZtiKsDyVfSJXcp/xP3VE5YU=; b=XB7zRdQ8xTEtzFM3vWNhZ3Y3IdkRWEGTyvU0UHdeTAEeNKPv6M9GwdWzSbGYNSkwIY 2LIsPUN38vGV4d2l5gxUENe+J56PwO7iKusuZrAJqEfsU7VqCxEqG7pQXJ4CkFhj4ZWC omvuBdNv/ufMRK3HBTeVHkyXPx8UZvfCZHYyM/JKQtyrJRRtRDF4eu1abwaHunqOEka5 cIL5aSf8BMTwxFSS+WaatxYqmhox6qNjh1/MBUBQTqzCG3Axl/YAGsbHnn1hg1igbMPZ Hqn7S54fqr2HK0ALiqNL7hGQa/bNK0Q56321jG5DIgQjCwZ37keVdD6IMryRNB4Z64Ka wx5w== MIME-Version: 1.0 Received: by 10.216.140.11 with SMTP id d11mr2280451wej.29.1352041089677; Sun, 04 Nov 2012 06:58:09 -0800 (PST) Received: by 10.194.59.71 with HTTP; Sun, 4 Nov 2012 06:58:09 -0800 (PST) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772205284E@xmb-rcd-x02.cisco.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772205284E@xmb-rcd-x02.cisco.com> Date: Sun, 4 Nov 2012 14:58:09 +0000 Message-ID: From: Daniel He To: "JP Vasseur (jvasseur)" Content-Type: multipart/alternative; boundary=0016e6ddab7bdf3b6404cdac98b6 Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 14:58:11 -0000 --0016e6ddab7bdf3b6404cdac98b6 Content-Type: text/plain; charset=ISO-8859-1 I think it is fair enought to replace the name. and I knew you don't like LLN at all. and I agree to LLN taken out of the context is reasonable and generized. Cheers, Dan On 4 November 2012 14:16, JP Vasseur (jvasseur) wrote: > > On Nov 4, 2012, at 8:35 AM, Daniel He wrote: > > > I still don't beleive that LOADng deployments fit MANETs' >> applicabilities. Therefore, disagree with the subject claimed (i.e. >> LOADng works). >> >> I totally disagree! LOADng is fitting to MANET. fundamentally > it is lightweighted AODV. > > > Here is my take on this; *if* there is a choice for option 1, 2 or may > be a brand new document related to > reactive routing in MANET (protocol called AODVv20, and excluding LLNs, > then I think that we do not > have any issue. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > -- Dan He --------------------- Tel: +44-788-686-3428 --0016e6ddab7bdf3b6404cdac98b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it is fair enought to replace the name. and I knew you don't li= ke LLN
at all. and I agree to LLN taken out of the context is reasonable= and generized.

Cheers,
Dan

On = 4 November 2012 14:16, JP Vasseur (jvasseur) <jvasseur@cisco.com>= wrote:

On Nov 4, 2012, at 8:35 AM, Daniel He wrote:


I still don't beleive that LOADng deployments fit MANETs'
applicabilities. Therefore, disagree with the subject claimed (i.e.
LOADng works).

I totally disagree!=A0 LOADng is fitting to MANET. fundamentally
it is lightweighted AODV.

Here is my take on this; *if* there is a choice for option= 1, 2 or may be a brand new document related to
reactive routing in MANET (protocol called AODVv20, and excluding LLNs= , then I think that we do not=A0
have any issue.


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet




--
Dan He
-------------= --------
Tel: +44-788-686-3428

--0016e6ddab7bdf3b6404cdac98b6-- From drdanhe@gmail.com Sun Nov 4 07:01:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B318021F84EC for ; Sun, 4 Nov 2012 07:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vm0cl0nf-f-b for ; Sun, 4 Nov 2012 07:01:17 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id F3B9521F8452 for ; Sun, 4 Nov 2012 07:01:16 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hr7so1999118wib.13 for ; Sun, 04 Nov 2012 07:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f51ceMk4/xWW6QgAzWO53OznGwaoxWtwgbFj/fnbA5g=; b=I7lyjbOGj2MnrQV3gy2irftT3ufk+k96dBeV8Bz/X+d2ytbswIOcXjO/InAx/QY0un i6vBz/kxSr9KZAkk2U+cVFl6Vx+yCkKrqsdLvu1LPx+w1gLCrlV1ZgboJevVOc+VHJ2A awrKx4JuLDJyNgREncK8Sd/qvqmITigNIK4j3vs9uyQIf+60Inh2UcYjvG7FDRrkmz2B KkIZOQEPcVqNR/SOBVgcOenWTWBCiWqipn3zqZkIIMTLxga8Zu6vS6Hm7qXiR+wje1zm rSkbWnLdMxtuckYtk5BPqd4dxZDd85++KzZ1h0eHveUi2z2I0OSol6e0GxlDJGpga2h0 FYlQ== MIME-Version: 1.0 Received: by 10.216.197.142 with SMTP id t14mr2289715wen.151.1352041276208; Sun, 04 Nov 2012 07:01:16 -0800 (PST) Received: by 10.194.59.71 with HTTP; Sun, 4 Nov 2012 07:01:16 -0800 (PST) In-Reply-To: <001001cdba98$b6b03910$2410ab30$@olddog.co.uk> References: <001001cdba98$b6b03910$2410ab30$@olddog.co.uk> Date: Sun, 4 Nov 2012 15:01:16 +0000 Message-ID: From: Daniel He To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=0016e6d9770bfd75ac04cdaca3a5 Cc: manet , Stan Ratliff Subject: Re: [manet] DYMO Milestone date X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 15:01:17 -0000 --0016e6d9770bfd75ac04cdaca3a5 Content-Type: text/plain; charset=ISO-8859-1 > I see no value in setting an artificial project management deadline, and I > see > no value in setting it without being able to do the necessary planning > tasks. > > Absolutely true! we are not doing EU projects. Dan > Adrian > > > -----Original Message----- > > From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > > Sent: 04 November 2012 13:08. > > To: jpmacker@gmail.com; Stan Ratliff > > Cc: manet; adrian > > Subject: DYMO Milestone date > > > > Dear MANET Chairs, > > > > Please note that I already requested on the MANET-list to provide our > > WG draft dymo a milestone date, but still you did n't update or even > > respond. Please note that this will be my last reminder, and I will > > send a complain as procedure satates if you continue to ignore such > > input. > > > > Best Regards > > Abdussalam Baryun > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Dan He --------------------- Tel: +44-788-686-3428 --0016e6d9770bfd75ac04cdaca3a5 Content-Type: text/html; charset=ISO-8859-1
I see no value in setting an artificial project management deadline, and I see
no value in setting it without being able to do the necessary planning tasks.

Absolutely true! we are not doing EU projects.

Dan
Adrian

> -----Original Message-----
> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
> Sent: 04 November 2012 13:08.
> To: jpmacker@gmail.com; Stan Ratliff
> Cc: manet; adrian
> Subject: DYMO Milestone date
>
> Dear MANET Chairs,
>
> Please note that I already requested on the MANET-list to provide our
> WG draft dymo a milestone date, but still you did n't update or even
> respond. Please note that this will be my last reminder, and I will
> send a complain as procedure satates if you continue to ignore such
> input.
>
> Best Regards
> Abdussalam Baryun

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



--
Dan He
---------------------
Tel: +44-788-686-3428

--0016e6d9770bfd75ac04cdaca3a5-- From adrian@olddog.co.uk Sun Nov 4 07:09:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C7321F8653 for ; Sun, 4 Nov 2012 07:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CacqJMsqNXwJ for ; Sun, 4 Nov 2012 07:09:38 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA5F21F8707 for ; Sun, 4 Nov 2012 07:09:38 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id qA4F9WLj029829; Sun, 4 Nov 2012 15:09:32 GMT Received: from 950129200 (dhcp-13b5.meeting.ietf.org [130.129.19.181]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id qA4F9TwG029773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 4 Nov 2012 15:09:30 GMT From: "Adrian Farrel" To: "'Abdussalam Baryun'" , "'Ulrich Herberg'" References: In-Reply-To: Date: Sun, 4 Nov 2012 15:09:30 -0000 Message-ID: <003101cdba9e$659253a0$30b6fae0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF4tQaqjIVy7Td32GgXwNMJL5zzCQI0BasSAjTjQ+EBoX2D6phTd18Q Content-Language: en-gb Cc: "'Ersue, Mehmet \(NSN - DE/Munich\)'" , 'Benoit Claise' , manet@ietf.org Subject: Re: [manet] Management use cases for MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 15:09:40 -0000 Abdussalam, Your thought is noted. However, several ADs have expressed a strong desire to see the WG discuss how MANETs are managed. This request was made during the review and discussion of the NHDP MIB module when two things emerged: - The authors of the MIB modules were adding function to the module on the assumption that the features were needed, but without a guiding framework - There was no common understanding of how MANETs are managed The OPS ADs basically allowed the NHDP MIB module to be approved conditional on the WG taking on a work item to resolve these issues. The alternative was that the MB module would be blocked pending this work, so I think we got a good deal, but we are now expected to follow through. Adrian > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: 04 November 2012 13:34 > To: Ulrich Herberg > Cc: Ersue, Mehmet (NSN - DE/Munich); Benoit Claise; manet@ietf.org > Subject: Re: [manet] Management use cases for MANETs > > Hi Ulrich, > > I think making one draft submitted for management of use case for > MANETs is not suitable now until we finish the charter requirements of > a standard Proactive and a standard Reactive. After that phase with > both RFCs including RFC2501 we will be able to identify many related > issues. I recommend the start but the WGLC of this draft should be > only after finishing the both RFCs requirements. > > AB > > On 11/4/12, Ulrich Herberg wrote: > > Abdussalam, > > > > Benoit's request was for a dedicated MANET use case draft *in addition* to > > a shorter applicability section in each MIB document. > > > > Best regards > > Ulrich > > > > On Sun, Nov 4, 2012 at 5:14 AM, Abdussalam Baryun < > > abdussalambaryun@gmail.com> wrote: > > > >> Hi Ulrich, > >> > >> I support that each Mib draft to provide with its management use cases > >> (within a section) for its MANETs applicability. Proactive > >> applicabilities are not similar to Reactive applicabilities. > >> > >> AB > >> > >> On 11/2/12, Ulrich Herberg wrote: > >> > Hi [manet] participants, > >> > > >> > I am forwarding an email from Benoit that was sent to coman@ietf.org, > >> since > >> > it concerns MANET. COMAN is a new activity (not yet a WG) relating to > >> > management of constrained devices and networks. As I mentioned at the > >> last > >> > IETF, Benoit cleared his DISCUSS on the NHDP-MIB if we commit to write > >> > a > >> > document about applicability and use cases of management of MANET > >> routers. > >> > > >> > In COMAN, an individual ID was presented > >> > (draft-ersue-constrained-mgmt) that discusses use cases of management. > >> Note > >> > that this is an early draft and will possibly be split in multiple > >> drafts. > >> > There is some discussion whether that should include mobility or not > >> > (currently, MANET is excluded but mesh networks are not, which I think > >> > needs some more discussion, as both are about dynamic topologies). > >> Anyway, > >> > similar to Benoit, it is unclear to me whether this draft or any work > >> > in > >> > COMAN (if it was to become a WG) would satisfy the request for a use > >> > case/applicability document, or if MANET should work on a separate > >> > draft. > >> > > >> > As the next OLSRv2-MIB revision will be submitted next Monday, (which I > >> > consider ready for WGLC) this is something we need to seriously > >> > consider. > >> > > >> > Opinions? > >> > > >> > Thanks > >> > Ulrich > >> > > >> > On Fri, Nov 2, 2012 at 4:45 AM, Benoit Claise > >> > wrote: > >> > > >> >> Hi, > >> >> > >> >> One point regarding MANET. > >> >> I believe that it deserves its own document: "MANET network > management > >> >> considerations". Actually, when looking at draft-ietf-manet-nhdp-mib > >> part > >> >> of the IESG review, one of the outcome was that such a document was > >> >> required. > >> >> I cleared my DISCUSS on draft-ietf-manet-nhdp-mib with this COMMENT > >> >> > >> >> Note regarding the applicability statement: This is solved, as we > >> >> discussed, but I'll keep this little sentence in one > >> >> corner of my head "A fuller discussion of MANET network management > use > >> >> cases and challenges will be provided elsewhere." > >> >> > >> >> How/If this "MANET network management considerations" draft relates > >> >> to > >> >> the draft-ersue-constrained-mgmt, I'm not sure at this point in time. > >> >> > >> >> > >> > > >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From james.huy.nguyen@gmail.com Sun Nov 4 11:18:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7A121F8679 for ; Sun, 4 Nov 2012 11:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moB7AYJNjl21 for ; Sun, 4 Nov 2012 11:18:42 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA8521F84CD for ; Sun, 4 Nov 2012 11:18:41 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so4312785iak.31 for ; Sun, 04 Nov 2012 11:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TN8RDYEh3l4c0E77V3f+NG9wUvyGI2mKlGbZz2gMPrQ=; b=cIqckGM+663wmTeyUmhqBpak4Wm4XqQV9top6bp/f/y0zviuhXil5J+1LQY5Hv37ge ybEDBx08OaXim98csQ7skD2ipcD8APwqpaDWLuVzqx4WRYaOhXEj7x3k+/NR/GJB9NyJ uqD8YP3AkmOyANH3lOFml6hFG/8KfI9yIz7NFlkHVfJgTE2WeQmbDpFUybPVQAy7SGvX T05Bc7LJuR94ePLcHjwRqzyI1LpASunxxyhodAmKI/8bBiE+//jJJm26jpkGKf5fdu2M fxlQrSzTPwBz1Le2Dxok43VO9ujjsmDr1P71xorIxUv3AyzhRC9lGF4yJGpIfj5+fviz ntaw== MIME-Version: 1.0 Received: by 10.43.7.132 with SMTP id oo4mr6660917icb.6.1352056721658; Sun, 04 Nov 2012 11:18:41 -0800 (PST) Received: by 10.42.155.196 with HTTP; Sun, 4 Nov 2012 11:18:41 -0800 (PST) In-Reply-To: References: Date: Sun, 4 Nov 2012 14:18:41 -0500 Message-ID: From: James Nguyen To: "Cole, Robert G CIV USARMY CERDEC (US)" Content-Type: multipart/alternative; boundary=bcaec50fe2df9c531a04cdb03c45 Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , Benoit Claise , "manet@ietf.org" Subject: Re: [manet] Management use cases for MANETs (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 19:18:43 -0000 --bcaec50fe2df9c531a04cdb03c45 Content-Type: text/plain; charset=UTF-8 Hi Ulrich, Please count me in if the WG agrees to draft a MANET use cases. James On Fri, Nov 2, 2012 at 3:46 PM, Cole, Robert G CIV USARMY CERDEC (US) < robert.g.cole.civ@mail.mil> wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > Ulrich, > > It was my understanding that, as you mentioned, Benoit had cleared the > discuss on the NHDP-MIB conditioned upon the working group drafting a MANET > management use case document. I know that you and James Nguyen had > contributed some material to Mehmet's draft. I would hope that you and > James could start to pull together a draft for the MANET WG for us to meet > our commitment to Benoit. I would be glad to help review and comment but > prefer not to edit. > > Thoughts? > > Thanks, Bob > > Robert G. Cole > Comm: 443.395.8744 > Email: robert.g.cole@us.army.mil > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Ulrich Herberg > Sent: Friday, November 02, 2012 3:18 PM > To: manet@ietf.org > Cc: Ersue, Mehmet (NSN - DE/Munich); Benoit Claise > Subject: [manet] Management use cases for MANETs > > Hi [manet] participants, > > I am forwarding an email from Benoit that was sent to coman@ietf.org, > since > it concerns MANET. COMAN is a new activity (not yet a WG) relating to > management of constrained devices and networks. As I mentioned at the last > IETF, Benoit cleared his DISCUSS on the NHDP-MIB if we commit to write a > document about applicability and use cases of management of MANET routers. > > In COMAN, an individual ID was presented (draft-ersue-constrained-mgmt) > that > discusses use cases of management. Note that this is an early draft and > will > possibly be split in multiple drafts. There is some discussion whether that > should include mobility or not (currently, MANET is excluded but mesh > networks are not, which I think needs some more discussion, as both are > about dynamic topologies). Anyway, similar to Benoit, it is unclear to me > whether this draft or any work in COMAN (if it was to become a WG) would > satisfy the request for a use case/applicability document, or if MANET > should work on a separate draft. > > As the next OLSRv2-MIB revision will be submitted next Monday, (which I > consider ready for WGLC) this is something we need to seriously consider. > > Opinions? > > Thanks > Ulrich > > > On Fri, Nov 2, 2012 at 4:45 AM, Benoit Claise wrote: > > > Hi, > > One point regarding MANET. > I believe that it deserves its own document: "MANET network > management considerations". Actually, when looking at > draft-ietf-manet-nhdp-mib part of the IESG review, one of the outcome was > that such a document was required. > I cleared my DISCUSS on draft-ietf-manet-nhdp-mib with this COMMENT > > > Note regarding the applicability statement: This is solved, > as we > discussed, but I'll keep this little sentence in one > corner of my head "A fuller discussion of MANET network > management use > cases and challenges will be provided elsewhere." > > How/If this "MANET network management considerations" draft relates > to the draft-ersue-constrained-mgmt, I'm not sure at this point in time. > > > > > Classification: UNCLASSIFIED > Caveats: NONE > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > -- James Nguyen Email: james.huy.nguyen@gmail.com --bcaec50fe2df9c531a04cdb03c45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ulrich,

Please count me in if the WG agrees to draft a MANET use cases.

James


On Fri, = Nov 2, 2012 at 3:46 PM, Cole, Robert G CIV USARMY CERDEC (US) <ro= bert.g.cole.civ@mail.mil> wrote:
Classification: UNCLASSIFIED
Caveats: NONE

Ulrich,

It was my understanding that, as you mentioned, Benoit had cleared the
discuss on the NHDP-MIB conditioned upon the working group drafting a MANET=
management use case document. =C2=A0I know that you and James Nguyen had contributed some material to Mehmet's draft. =C2=A0I would hope that yo= u and
James could start to pull together a draft for the MANET WG for us to meet<= br> our commitment to Benoit. =C2=A0I would be glad to help review and comment = but
prefer not to edit.

Thoughts?

Thanks, Bob

Robert G. Cole
Comm: =C2=A0443.395.874= 4
Email: robert.g.cole@us.army.m= il


-----Original Message-----
From: manet-bounces@ietf.org = [mailto:manet-bounces@ietf.org] On Behalf Of
Ulrich Herberg
Sent: Friday, November 02, 2012 3:18 PM
To: manet@ietf.org
Cc: Ersue, Mehmet (NSN - DE/Munich); Benoit Claise
Subject: [manet] Management use cases for MANETs

Hi [manet] participants,

I am forwarding an email from Benoit that was sent to coman@ietf.org, since
it concerns MANET. COMAN is a new activity (not yet a WG) relating to
management of constrained devices and networks. As I mentioned at the last<= br> IETF, Benoit cleared his DISCUSS on the NHDP-MIB if we commit to write a document about applicability and use cases of management of MANET routers.<= br>
In COMAN, an individual ID was presented (draft-ersue-constrained-mgmt) tha= t
discusses use cases of management. Note that this is an early draft and wil= l
possibly be split in multiple drafts. There is some discussion whether that=
should include mobility or not (currently, MANET is excluded but mesh
networks are not, which I think needs some more discussion, as both are
about dynamic topologies). Anyway, similar to Benoit, it is unclear to me whether this draft or any work in COMAN (if it was to become a WG) would satisfy the request for a use case/applicability document, or if MANET
should work on a separate draft.

As the next OLSRv2-MIB revision will be submitted next Monday, (which I
consider ready for WGLC) this is something we need to seriously consider.
Opinions?

Thanks
Ulrich


On Fri, Nov 2, 2012 at 4:45 AM, Benoit Claise <bclaise@cisco.com> wrote:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 One point regarding MANET.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I believe that it deserves its own document: &q= uot;MANET network
management considerations". Actually, when looking at
draft-ietf-manet-nhdp-mib part of the IESG review, one of the outcome was that such a document was required.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I cleared my DISCUSS on draft-ietf-manet-nhdp-m= ib with this COMMENT


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Note regarding the = applicability statement: This is solved,
as we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 discussed, but I= 9;ll keep this little sentence in one
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 corner of my head &= quot;A fuller discussion of MANET network
management use
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cases and challenge= s will be provided elsewhere."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 How/If this "MANET network management cons= iderations" draft relates
to the draft-ersue-constrained-mgmt, I'm not sure at this point in time= .




Classification: UNCLASSIFIED
Caveats: NONE



_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet




--
James Nguyen
Ema= il: james.huy.nguyen@gmail.co= m
--bcaec50fe2df9c531a04cdb03c45-- From jpmacker@gmail.com Sun Nov 4 12:40:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94E921F8812 for ; Sun, 4 Nov 2012 12:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYav8dc4H5Ze for ; Sun, 4 Nov 2012 12:40:49 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACB721F8805 for ; Sun, 4 Nov 2012 12:40:48 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so5887308vbb.31 for ; Sun, 04 Nov 2012 12:40:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XbUBTDmfaADXshgCVXH2kJJzAEEZIRaHlxuv+vYfmZE=; b=fdJPn4q66oc5kE8HLNnzKdWhF26BRCYQq1q9qYZXvi0EVL4AsZabui5IRldoSyFXft c32kK+rnDhr9Q/kO7SN9zoo2NxMHzRS0Zt3PVm5vK6y4N4s3QAz9DovtgOtyJxHplZSS UznyWrNzCjrFNI0L/vxKgSzbrPuvtOEPolaL/IrCb9KR8Jm3G1MsEqnhQAqNxxX8TR05 QryAjsUxkk/y6x/PSO8SZbPld55bH6Wr+SRQMB8p4AKY/ewo10DDfCJLg4091Mb4OMqY h41srNiaKQ6O0okBtitQkaM8IB3lrIJyqV2U1dL2OdqSnLZJaPxPuTeuE6qQe/fRFQne aq5Q== MIME-Version: 1.0 Received: by 10.52.35.82 with SMTP id f18mr6582643vdj.99.1352061647558; Sun, 04 Nov 2012 12:40:47 -0800 (PST) Received: by 10.58.161.206 with HTTP; Sun, 4 Nov 2012 12:40:47 -0800 (PST) In-Reply-To: References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> Date: Sun, 4 Nov 2012 15:40:47 -0500 Message-ID: From: Joseph Macker To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=20cf307c9fbe37961704cdb162a2 Cc: "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:40:50 -0000 --20cf307c9fbe37961704cdb162a2 Content-Type: text/plain; charset=ISO-8859-1 Since LOADng, DYMO, and AODV are about the same technically, in my opinion, are you claiming that AODV-based designs do not work for MANETs? Thats what I am hearing technically and I have no problem hearing that opinion but there seems to be a fallacy in the actual argument being made. In my opinon if LOADng is not appropriate for MANET then neither is AODV or DYMO since the design principles are basically the same. Back to #3 in that case. On Sun, Nov 4, 2012 at 7:57 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Joe, > > My question was always as the subject claims; Where does LOADng Work, > please give me a reference document of performance and practice? > Please note that the authors were asked about this before in MANET WG > but the answer was we cannot provide information because classified. > This is confusing and without progress. > > I still don't beleive that LOADng deployments fit MANETs' > applicabilities. Therefore, disagree with the subject claimed (i.e. > LOADng works). > > Let us focus the question for our charter; Does the LOADng work with > MANETs scenarios and applicabilities or does the LOADng work only for > special cases of MANET scenarios. I remember your input to the LOADng > presenter in one f2f meeting to include heterogeniety to this > protocol. I think LOADng should be modified to be suitable without > confusions to fit MANETs. > > AB > > On 11/3/12, Joseph Macker wrote: > > Again I would ask that we move ROLL and LLN discussions to ROLL if people > > want to continue. > > JP your opinion to the WG chairs is pretty obvious. > > > > We need some bandwidth to discuss quality of documents and authors > > agreement to various other WG issues. > > I will provide some questions to that effect shortly. Let us focus on our > > WG's challenges. > > > > -Joe > > > > > --20cf307c9fbe37961704cdb162a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Since LOADng, DYMO, and AODV are about the same technically, in my opinion,= are you claiming that AODV-based designs do not work for MANETs?=A0 Thats = what I am hearing technically and I have no problem hearing that opinion bu= t there seems to be a fallacy in the actual argument being made. In my opin= on if LOADng is not appropriate for MANET then neither is AODV or DYMO sinc= e the design principles are basically the same. Back to #3 in that case.


On Sun, Nov 4= , 2012 at 7:57 AM, Abdussalam Baryun <abdussalambaryun@gmail.com<= /a>> wrote:
Hi Joe,

My question was always as the subject claims; Where does LOADng Work,
please give me a reference document of performance and practice?
Please note that the authors were asked about this before in MANET WG
but the answer was we cannot provide information because classified.
This is confusing and without progress.

I still don't beleive that LOADng deployments fit MANETs'
applicabilities. Therefore, disagree with the subject claimed (i.e.
LOADng works).

Let us focus the question for our charter; Does the LOADng work with
MANETs scenarios and applicabilities or does the LOADng work only for
special cases of MANET scenarios. I remember your input to the LOADng
presenter in one f2f meeting to include heterogeniety to this
protocol. I think LOADng should be modified to be suitable without
confusions to fit MANETs.

AB

On 11/3/12, Joseph Macker <jpmacke= r@gmail.com> wrote:
> Again I would ask that we move ROLL and LLN discussions to ROLL if peo= ple
> want to continue.
> JP your opinion to the WG chairs is pretty obvious.
>
> We need some bandwidth to discuss quality of documents and authors
> agreement to various other WG issues.
> I will provide some questions to that effect shortly. Let us focus on = our
> WG's challenges.
>
> -Joe
>
>

--20cf307c9fbe37961704cdb162a2-- From jvasseur@cisco.com Sun Nov 4 17:38:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BC521F8613 for ; Sun, 4 Nov 2012 17:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ng+QGWKKRY4p for ; Sun, 4 Nov 2012 17:38:09 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 62B2D21F85D0 for ; Sun, 4 Nov 2012 17:38:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38478; q=dns/txt; s=iport; t=1352079489; x=1353289089; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=awj223lHoEkU4l42oHjaZHHecIQbiZFK2yC152FAS/g=; b=m/+I7MHQSjsEQREKtLsmkhSlDEmjyKMOMIjGeYo6OxRtgHpzn3fujqmE AdlJ6VP4wQCRq/ffvyT9ftaMOWabpkA0LHjbX6641DsYOYR1v1jvW+6rc v06zHm4B6glBdBggcowk2KpHxUw7u30d3aEYPgL/Farp+zq4rnVRW5o9F I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJwXl1CtJXG//2dsb2JhbABEwzaBCIIfAQEEAQEBDwEHUgEBCAMQAgEIEhAWAQYHIQYLFAMOAgQOBQgah1YDDwuZXJUlDYlQBIsZaBIOhTthA4gljAGNCIMmgWuCb4FcHx4 X-IronPort-AV: E=Sophos;i="4.80,712,1344211200"; d="scan'208,217";a="138741605" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 05 Nov 2012 01:38:08 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA51c8kc025389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 01:38:08 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 19:38:07 -0600 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuvY0LPVi/cSo/ES1hdb7zda62w== Date: Mon, 5 Nov 2012 01:38:06 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722052EFE@xmb-rcd-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.89.6] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19338.004 x-tm-as-result: No--44.049200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722052EFExmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 01:38:12 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7722052EFExmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, On Nov 1, 2012, at 9:39 PM, Ulrich Herberg wrote: Hi Joydeep, On Thu, Nov 1, 2012 at 5:58 PM, Joydeep Tripathi > wrote: Hi Joe and MANET WG, I was following the discussion on which route to take for a reactive protoc= ol standard very closely, and I think I should post my opinion also. I cham= pion for Option 1, and here is why : I have read both AODVv2 (DYMO) and LOAD-ng drafts, and I have simulated LOA= D-ng myself as well. This experience, I believe, puts me in a position to f= orm an opinion comparing these two protocols. That is valuable. Have you also implemented DYMO and compared it to LOADng? I certainly agree, option 3 is *not* an option I would like to be chosen. R= eactive protocols, though very much unsuitable for LLNs and Smart Grid AMI = meter networks, I differ on that, and so do some of the LOADng authors that work in that ar= ea. But that's not the point of the discussion here. may have some usefulness in certain networks for certain sparse traffic sce= nario, and the WG should have a standard for the same. I agree. Firstly, LOAD-ng is backed up by the argument that it has implementations a= nd interop documents. However, I have seen in the mailing list, that certai= n question on details of the 'practical' implementation of LOAD-ng has been= avoided. I don't see how. There was a description of the deployment and about the su= itability for LOADng in that. Note that for DYMO, there is no such deployme= nt (to my knowledge), which is why I think your conclusion for option 1 ins= tead of option 3 is surprising to me. A reactive protocol may do well in a 2000 nodes smart meter network, if the= data traffic to the base station or collector is 1-2 times a day. This kin= d of implementations, in my opinion, say nothing about usefulness of LOAD-n= g in Smart Grid networks or LLNs. It is well known (and also spelled out in DYMO), that reactive protocols ar= e more suitable for sparse traffic scenarios with few concurrent communicat= ion streams. That is well-known and understood in MANET, and a reasons to w= ork on a proactive protocol as well. Reactive protocols have their limitati= ons, but in certain MANET use cases are useful, which is why we are charter= ed to work on a reactive protocol. JP> We all agree, with a a non subtle nuance. I never said that reactive ro= uting was a bad idea. These protocol are very useful. They are just ill-suited to LLNs. If you design a protocol X in MANET and e= xplicitly mention that it would not be applicable to LLNs, then I would personally be fine. Now if you claim that a protocol such as L= oad could work in specify lightweight traffic use cases, then can you explain why existing LLN routing protocol do not work ? The id= ea is to avoid having two protocols if one is sufficient (once again for LLNs). Again, whether LLN may be considered as a subset of MANET or not is a diffe= rent question. But even then, deployed LOAD-ng in a 2000 node network may (= and in my opinion, will) fail if traffic is increased. That is possible. Both in DYMO and LOADng. Agreed, one size does not fit all. However, once we have multicast traffic = in a smart grid or multiple meters generating alert packets in a region at = the same time, a reactive protocol like LOAD-ng will lead to the break-down= of the network. Anyone can say multicast traffic or several meters reporti= ng emergency at the same time to the same station, is a very much likely si= tuation in smart grid. Were these situations considered during deployment? = Please note, I am NOT saying that AODVv2 / DYMO will be better in this case= than LOAD-ng. But why are you opting for option 1 then? That seems not logical. You argue= against reactive protocols in general. All what you say above is known to = MANET, long before ROLL and LLN even existed. JP> If I may express my opinion (not sure what Joydeep thinks about this) y= ou very well know that Load has been positioned as a lightweight reactive routing protocol for LLNs. The deployment that ha= s been mentioned on the list (without any details) is related to AMI over PLC, probably one of the most constrained LLN. There ar= e other reasons for opting for option 1. IMHO, any protocol can be shown 'working perfectly', if we provide a favora= ble atmosphere only for it to work. Yes, I agree. You say yourself, no-one-size-fits all, which is why MANET wo= rks on both reactive and proactive protocol. Looking at that perspective, I don't think, LOAD-ng working in one network = under one particular scenario should be considered a vital argument to disc= uss whether to go with AODVv2 or LOAD-ng. LOADng has one large-scale deployment, DYMO does not. LOADng has multiple r= ecent interoperable implementations, DYMO has not. LOADng is based on the s= ame mechanism of AODV that is known to work in certain MANET scenarios. JP> Along those lines, I could list a dozen of proprietary protocols deploy= ed in the field, still the IETF does not have to standardize them all. Not going to each point one by one, if the document ends up trying to be ap= plicable to LLNs, we would need to have it reviewed by a wider audience (ROLLE WG). Chair hat off, I would offer to write an ID list= ing the number of issues using reactive in LLNs. Thanks. JP. So why do you opt for 1) and not 3)? One can write a working code of AODVv2 in 2 days. The real question we shou= ld be asking, which protocol is better suited for general MANET overall, an= d if there really is a *necessity* of discarding a working group document. Secondly, LOAD-ng was devised keeping LLN scenario in mind. It was intended= for ROLL WG, and since it had not been adopted in the ROLL WG, it popped u= p in the MANET WG. The change that has been done to LOAD-ng after dragging = it to MANET WG, was really to change the message format to adhere to RFC 54= 44, That is true, the work was initiated from LLNs. However, as you say yoursel= f, it has adopted RFC5444 and other MANET requirements. Note that amongst t= he authors, there are a large part of the previous RFC editors of MANET pre= sented. We know MANETs and their requirements. Can you point out a specific= requirement that LOADng would not fulfill but DYMO would? and do a "find and replace" of the term LLN with 'MANET' along with changin= g the first 'L' of LOAD ng from 'LLN' to 'Lightweight'. Since the protocol = was designed for LLN at first, I do not think it would be able to cover the= broad spectrum that MANET includes. Why? And why does DYMO? I don't see a technical argument. Since we already have a WG document for a reactive protocol, I do not see a= ny strong reason to discard the current one in favor of an individual draft= , especially when even LOAD-ng authors agreed that this protocol will not o= ffer any notable performance difference compared to AODVv2. Yes, but the document is not aligned with the RFC5444 architecture, it is n= ot possible to secure, and it would be a lot more work to come to an RFC, i= n my opinion (lots of unclear and underspecified text, incomplete IANA sect= ion, unclear metrics, underspecified bidirectionality detection). At the same time, since I have read both drafts, I figured out that AODVv2 = is more generic to MANET than LOAD-ng. It offers the developer or the deplo= yment authority to chose form more than one options. Options may be fine, but they also affect interoperability if not carefully= designed. And they may, as for some of the options like iRREP, make it ver= y difficult or impossible to provide end-to-end security. For example, AODVv2 has the option (but it is not mandated) to use a precur= sor list or have an intermediate node to reply an RREQ. LOAD-ng does not su= pport either. That is not true. We opted to move these in companion document, as we have = not seen proof that these options would bring benefit in a general MANET ca= se. I can understand that for an LLN it may be beneficial for not maintaining a= precursor list or having only the destination reply t o a RREQ, there can = be (and are) other instances of MANETs where having the option of precursor= list will come handy. Which? Can you show results that this is beneficial in a general use case? This can save on control overhead, using some storage space in the node. LO= AD-ng, in most cases does not provide this flexibility to the developer to = chose between options for specific deployment. Again, not true. We provide TLVs, and extensions are possible in companion = documents. We have very carefully designed each RFC2119 word to make sure e= xtensions are allowed. Multiple options always carry a great risk of non-in= teroperability. Some MANET deployment may be less harsh than others in nature. Hence, AODVv= 2 having more open options than LOAD-ng, in most cases, seem beneficial to = me. "seems beneficial"? Have you proof for the use of the options? Of course, there are other technical differences between these protocols. B= ut I believe there is a separate thread created for that. I will wait for t= he draft authors to reply there first, and will reply with my points if all= those differences are not covered. There, I will re-iterate the necessity = of a protocol to be suited for MANET in general, not only 'some' kind of MA= NETs Lastly, I do not come from any industry, neither I have any company road-ma= p of deliverable here. Being a PhD candidate in a university, I tried to fa= irly judge the two options. So I read both drafts, and did not find a strong enough reason to discard a= current working group document. Whether a few companies backing up a proto= col over the other can be a decisive criteria to chose a standard protocol = or not, is in the WG and its chairs most capable hands. Also, I did not, ve= ry clearly understand how LOAD-ng, operating properly in a 2-5 routers test= -bed may be considered as proof of valid interoperability. Why not? What would it change to add 100 nodes? I have never seen any inter= op tests with more than a handful nodes. Again: interop tests are not perfo= rmance tests. By the way, I have not seen any such open interoperability tests during the= development of DYMO . I would very much appreciate feedback if I am wrong, since I am in my learn= ing phase :-) . I have my 2 cents here - a) AODVv2 offers more flexibility, As said, LOADng offers the same flexibility. Flexibility is nice, but one h= as to be very careful with interoperability. If LOADng were to be a WG docu= ment, of course the WG can discuss if certain options bring a general benef= it and don't harm interoperability, then we can include it. b) LOAD-ng does not offer enough advantage over AODVv2 to discard the later= , One major advantage is that it could be an RFC far quicker. In the current = shape, the SEC AD would certainly not accept DYMO, and it would require a l= ot more work to bring to a level that is acceptable for a standards track R= FC. c) LOAD-ng was not initially designed for MANET, I don't see the argument here (see above) and d) there are other technical differences that make AODVv2 more suitable= for MANETs over LOAD-ng (To be covered in separate thread). I am curious to see that. Best Ulrich My opinion - We should stick to current WG document (AODVv2) and improve it= and finish it as soon as possible. I hereby stand for Option 1. Thanks and Regards, Joydeep Tripathi PhD Candidate, Drexel University. On Tue, Oct 30, 2012 at 7:13 PM, Joseph Macker > wrote: Hello MANET working group (form Stan and Joe), As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common documen= t effort and given positive feedback at the time we the chairs thought this= was the best approach given the authors potential to come together and gai= n the best of both efforts. Since that period, there has been some fairly = strident and rancorous "at times" debate between the authors of the two doc= uments. During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts = and LOADng had fairly active authorship and implementation efforts. We prov= ided a co-editing proposal to the authors and gave them the timeframe of th= e Atlanta to come up with an answer back to us regarding this. As of this = writing, those discussions of a potential commonn document and authorship m= erger have failed. Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss= ue at the present time. We see only 3 possible paths forward: 1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2. 2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document). 3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus. The co-chairs request and need your opinions on the options. We have been = some silent collecting initial feedback and waiting for author feedback at = this point. Stan and I are both on travel prior to Atlanta so our response= s may be sparse and we will also likely be in a "receive mode" for a few da= ys. So send your opinions. -Joe _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7722052EFExmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Hi,

On Nov 1, 2012, at 9:39 PM, Ulrich Herberg wrote:

Hi Joydeep,

On Thu, Nov 1, 2012 at 5:58 PM, Joydeep Tripathi= <jt369@drexel.edu<= /a>> wrote:
Hi Joe and MANET WG,

I was following the discussion on which route to take for a reactive p= rotocol standard very closely, and I think I should post my opinion also. I= champion for Option 1, and here is why : 

I have read both AODVv2 (DYMO) and LOAD-ng drafts, and I have simulate= d LOAD-ng myself as well. This experience, I believe, puts me in a position= to form an opinion comparing these two protocols.

That is valuable. Have you also implemented DYMO and compared it to LO= ADng?

 
I certainly agree, option 3 is *not* an option I would like to be chos= en. Reactive protocols, though very much unsuitable for LLNs and Smart Grid= AMI meter networks,

I differ on that, and so do some of the LOADng authors that work in th= at area. But that's not the point of the discussion here.

 
may have some usefulness in certain networks for certain sparse traffi= c scenario, and the WG should have a standard for the same.

I agree.
 

Firstly, LOAD-ng is backed up by the argument that it has implementati= ons and interop documents. However, I have seen in the mailing list, that c= ertain question on details of the 'practical' implementation of LOAD-ng has= been avoided.

I don't see how. There was a description of the deployment and about t= he suitability for LOADng in that. Note that for DYMO, there is no such dep= loyment (to my knowledge), which is why I think your conclusion for option = 1 instead of option 3 is surprising to me.

 
A reactive protocol may do well in a 2000 nodes smart meter network, i= f the data traffic to the base station or collector is 1-2 times a day. Thi= s kind of implementations, in my opinion, say nothing about usefulness of L= OAD-ng in Smart Grid networks or LLNs.

It is well known (and also spelled out in DYMO), that reactive protoco= ls are more suitable for sparse traffic scenarios with few concurrent commu= nication streams. That is well-known and understood in MANET, and a reasons= to work on a proactive protocol as well. Reactive protocols have their limitations, but in certain MANET u= se cases are useful, which is why we are chartered to work on a reactive pr= otocol.

JP> We all agree, with a a non subtle nuance. I never said that rea= ctive routing was a bad idea. These protocol are very useful.
They are just ill-suited to LLNs. If you design a protocol X in MANET = and explicitly mention that it would not be applicable to LLNs,
then I would personally be fine. Now if you claim that a protocol such= as Load could work in specify lightweight traffic use cases, 
then can you explain why existing LLN routing protocol do not work ? T= he idea is to avoid having two protocols if one is sufficient
(once again for LLNs). 

 
Again, whether LLN may be considered as a subset of MANET or not is a = different question. But even then, deployed LOAD-ng in a 2000 node network = may (and in my opinion, will) fail if traffic is increased.

That is possible. Both in DYMO and LOADng.
 
Agreed, one size does not fit all. However, once we have multicast tra= ffic in a smart grid or multiple meters generating alert packets in a regio= n at the same time, a reactive protocol like LOAD-ng will lead to the break= -down of the network. Anyone can say multicast traffic or several meters reporting emergency at the same ti= me to the same station, is a very much likely situation in smart grid. Were= these situations considered during deployment? Please note, I am NOT sayin= g that AODVv2 / DYMO will be better in this case than LOAD-ng.

But why are you opting for option 1 then? That seems not logical. You = argue against reactive protocols in general. All what you say above is= known to MANET, long before ROLL and LLN even existed.

JP> If I may express my opinion (not sure what Joydeep thinks about= this) you very well know that Load has been positioned
as a lightweight reactive routing protocol for LLNs. The deployment th= at has been mentioned on the list (without any details) is 
related to AMI over PLC, probably one of the most constrained LLN= . There are other reasons for opting for option 1.


 
IMHO, any protocol can be shown 'working perfectly', if we provide a f= avorable atmosphere only for it to work.

Yes, I agree. You say yourself, no-one-size-fits all, which is why MAN= ET works on both reactive and proactive protocol.
 
Looking at that perspective, I don't think, LOAD-ng working in one = network under one particular scenario should be considered a vital argument= to discuss whether to go with AODVv2 or LOAD-ng.

LOADng has one large-scale deployment, DYMO does not. LOADng has multi= ple recent interoperable implementations, DYMO has not. LOADng is based on = the same mechanism of AODV that is known to work in certain MANET scenarios= .

JP> Along those lines, I could list a dozen of proprietary protocol= s deployed in the field, still the IETF does not have to standardize
them all.

Not going to each point one by one, if the document ends up trying to = be applicable to LLNs, we would need to have it reviewed by a
wider audience (ROLLE WG). Chair hat off, I would offer to write an ID= listing the number of issues using reactive in LLNs.

Thanks.

JP.

So why do you opt for 1) and not 3)?

 
 
One can write a working code of AODVv2 in 2 days. The real question we= should be asking, which protocol is better suited for general MANET overal= l, and if there really is a *necessity* of discarding a working group docum= ent.
 

Secondly, LOAD-ng was devised keeping LLN scenario in mind. It was int= ended for ROLL WG, and since it had not been adopted in the ROLL WG, it pop= ped up in the MANET WG. The change that has been done to LOAD-ng after drag= ging it to MANET WG, was really to change the message format to adhere to RFC 5444,

That is true, the work was initiated from LLNs. However, as you say yo= urself, it has adopted RFC5444 and other MANET requirements. Note that amon= gst the authors, there are a large part of the previous RFC editors of MANE= T presented. We know MANETs and their requirements. Can you point out a specific requirement that LOADng w= ould not fulfill but DYMO would?

 
and do a "find and replace" of the term LLN with 'MANET' alo= ng with changing the first 'L' of LOAD ng from 'LLN' to 'Lightweight'. Sinc= e the protocol was designed for LLN at first, I do not think it would be ab= le to cover the broad spectrum that MANET includes.

Why? And why does DYMO? I don't see a technical argument.

 
Since we already have a WG document for a reactive protocol, I do not = see any strong reason to discard the current one in favor of an individual = draft, especially when even LOAD-ng authors agreed that this protocol will = not offer any notable performance difference compared to AODVv2. 

Yes, but the document is not aligned with the RFC5444 architecture, it= is not possible to secure, and it would be a lot more work to come to an R= FC, in my opinion (lots of unclear and underspecified text, incomplete IANA= section, unclear metrics, underspecified bidirectionality detection).

 

At the same time, since I have read both drafts, I figured out that AO= DVv2 is more generic to MANET than LOAD-ng. It offers the developer or the = deployment authority to chose form more than one options.

Options may be fine, but they also affect interoperability if not care= fully designed. And they may, as for some of the options like iRREP, make i= t very difficult or impossible to provide end-to-end security.

 
For example, AODVv2 has the option (but it is not mandated) to use a p= recursor list or have an intermediate node to reply an RREQ. LOAD-ng does n= ot support either.

That is not true. We opted to move these in companion document, as we = have not seen proof that these options would bring benefit in a general MAN= ET case. 
 

I can understand that for an LLN it may be beneficial for not maintain= ing a precursor list or having only the destination reply t o a RREQ, there= can be (and are) other instances of MANETs where having the option of prec= ursor list will come handy.

Which? Can you show results that this is beneficial in a general use c= ase?

 
This can save on control overhead, using some storage space in the nod= e. LOAD-ng, in most cases does not provide this flexibility to the develope= r to chose between options for specific deployment.

Again, not true. We provide TLVs, and extensions are possible in compa= nion documents. We have very carefully designed each RFC2119 word to make s= ure extensions are allowed. Multiple options always carry a great risk of n= on-interoperability.

 
Some MANET deployment may be less harsh than others in nature. Hence, = AODVv2 having more open options than LOAD-ng, in most cases, seem beneficia= l to me.

"seems beneficial"? Have you proof for the use of the option= s?

 
Of course, there are other technical differences between these protoco= ls. But I believe there is a separate thread created for that. I will wait = for the draft authors to reply there first, and will reply with my points i= f all those differences are not covered. There, I will re-iterate the necessity of a protocol to be suited= for MANET in general, not only 'some' kind of MANETs 

Lastly, I do not come from any industry, neither I have any company ro= ad-map of deliverable here. Being a PhD candidate in a university= , I tried to fairly judge the two options. 

So I read both drafts, and did not find a strong enough reason to disc= ard a current working group document. Whether a few companies backing up a = protocol over the other can be a decisive criteria to chose a standard prot= ocol or not, is in the WG and its chairs most capable hands. Also, I did not, very clearly understand how LO= AD-ng, operating properly in a 2-5 routers test-bed may be consid= ered as proof of valid interoperability. 

Why not? What would it change to add 100 nodes? I have never seen any = interop tests with more than a handful nodes. Again: interop tests are not = performance tests. 
By the way, I have not seen any such open interoperability tests durin= g the development of DYMO .

 
I would very much appreciate feedback if I am wrong, since I am in my = learning phase :-) . I have my 2 cents here - a) AODVv2 offers more flexibi= lity,

As said, LOADng offers the same flexibility. Flexibility is nice, but = one has to be very careful with interoperability. If LOADng were to be= a WG document, of course the WG can discuss if certain options bring a gen= eral benefit and don't harm interoperability, then we can include it.

 
b) LOAD-ng does not offer enough advantage over AODVv2 to discard the = later,

One major advantage is that it could be an RFC far quicker. In the cur= rent shape, the SEC AD would certainly not accept DYMO, and it would requir= e a lot more work to bring to a level that is acceptable for a standards tr= ack RFC. 

 
c) LOAD-ng was not initially designed for MANET,

I don't see the argument here (see above)
 
and d) there are other technical differences that make AODVv2 more sui= table for MANETs over LOAD-ng (To be covered in separate thread).  

I am curious to see that.

Best
Ulrich
 
My opinion - We should stick to current WG document (AODVv2) and impro= ve it and finish it as soon as possible. I hereby stand for Option 1. 

Thanks and Regards,

Joydeep Tripathi
PhD Candidate, 
Drexel University.


On Tue, Oct 30, 2012 at 7:13 PM, Joseph Macker <jpmack= er@gmail.com> wrote:
Hello MANET working group (form Stan and Joe),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.  Sin= ce that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.

During IETF 84 in Vancouver, the co-chairs held a discuss= ion with some of the co-authors of the two documents. Our guidance to the c= o-authors was to find a way to merge the two documents into one, as it was = perceived that are not technically far apart and they both derive roughly from AODV concepts and LOADng had f= airly active authorship and implementation efforts. We provided a co-editin= g proposal to the authors and gave them the timeframe of the Atlanta to com= e up with an answer back to us regarding this.  As of this writing, those discussions of a potential commonn d= ocument and authorship merger have failed.

Therefore, we find ourselves at a crossroads. The authors= of the two documents are divided, and it is unlikely that progress on a me= rged document can be reached based upon recent author feedback. I have also= polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue at the present ti= me.  We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
2. Replace the existing DYMO document effort with the LOA= Dng related document effort, defusing ealier references to LLNs as recommen= ded in the last meeting minutes, and to focus more motivationally on genera= l MANET problem spaces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a reactive protoc= ol, effectively killing both documents, at least from a working group (WG) = standpoint. This would not be a reflection on the technology in either case= , just an admission that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the optio= ns.  We have been some silent collecting initial feedback and waiting = for author feedback at this point.  Stan and I are both on travel prio= r to Atlanta so our responses may be sparse and we will also likely be in a "receive mode" for a few days.&n= bsp; So send your opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A7722052EFExmbrcdx02ciscoc_-- From jvasseur@cisco.com Sun Nov 4 17:38:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23BB21F86B7 for ; Sun, 4 Nov 2012 17:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.696 X-Spam-Level: X-Spam-Status: No, score=-8.696 tagged_above=-999 required=5 tests=[AWL=-1.756, BAYES_20=-0.74, J_CHICKENPOX_43=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZBTitnI5Ed1 for ; Sun, 4 Nov 2012 17:38:12 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5D87921F85F3 for ; Sun, 4 Nov 2012 17:38:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=112101; q=dns/txt; s=iport; t=1352079491; x=1353289091; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+1U6T57yo9+y8Yk4Tidh37VxH/80cR9vhxIh+V2OdD4=; b=O1NACq7lSxNmsecj0B6ppe2CLBZpOLoI3zmiL/imZZFqmGvHd38KwswG 3K4YdhIkAS5MmT/n7ICOfcPvpX6FiQ2LrCDCxAzgOTjEG2D1djhbbD8PU jdTrURKSh+BB4jV+LfMBHfBrkvJLozL1JIjbhpmwHlMOGHSZHRyzFCQNX I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJwXl1CtJV2c/2dsb2JhbAA6AQYDwzaBCIIeAQEBAwEBAQEPAQcBHzQCAgcFCQICAQgHCxACEhAbBgYLFw4CBA4DAggahW6BaAMJBguZXJUlDYlUBIsVaBABAwELBIJugklhA4pJgQCHAIFdgnGFPYRagyaBa4JvP4EcAQgXBBo X-IronPort-AV: E=Sophos;i="4.80,712,1344211200"; d="scan'208";a="138741604" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 05 Nov 2012 01:38:08 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA51c8oD025546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 01:38:08 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 19:38:07 -0600 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] DYMO-23 review Thread-Index: AQHNuvY0WAnc9xz2TE+ovpDBRY+6iQ== Date: Mon, 5 Nov 2012 01:38:06 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722052F08@xmb-rcd-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.89.6] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19338.004 x-tm-as-result: No--48.975900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <1376B3AF4C2C1F41855345767EC05907@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] DYMO-23 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 01:38:18 -0000 Hi, I think that we can agree with some of your comments. Should we start opening tickets and address those points ? Thanks. JP. On Nov 1, 2012, at 5:38 PM, Ulrich Herberg wrote: > Hi, >=20 > during the discussion, I noticed that many just say "I like protocol > foo1 better than foo2", without any technical argument. That is not > very productive. >=20 > Here is my review of the latest DYMO 23 draft. >=20 > The main comments (as shown in detail below) are: > - The draft is still very difficult to read and is underspecified in > many occasions. For example, it is unclear how the blacklisting works, > how metrics are used, how the TLVs are associated with certain > addresses. Some of the parameters and TLVs specified in the IANA > section are not used. There are at least four timers for each route > entry, and it is unclear how they may affect each other. It is not > clearly specified how to update forward/reverse routes + the route to > the previous hop > - The use of metrics is not well defined; there is an optional > distance field. It is unclear how metrics are created, whether they > are additive, how they are formatted etc. What happens if some routers > now the Distance field, others don't use it. > - There are several extensions specified, but too few details to > assure interoperability. Some of them violate end-to-end security. > - As messages are modified in transit, end-to-end security is not > possible. The security considerations section does not fulfill the > requirements in RFC3552. > - Extensions, such as for security, cannot be hooked into AODVv2, as > there is no section to allow an external mechanism to provide > additional reasons to reject a message as invalid, such as done in > RFC6130. > - The IANA section is not correct. There are no requests, no new > registries or code points in existing registries, no allocation policy > is provided. > - There are some layer violations where tasks that are to be done by > the RFC5444 (de)multiplexer are handled in AODVv2. > - There is a mandated order of addresses in RFC5444 messages; I > think this is a bad idea if extensions want to add addresses. > - Originator address and sequence number are contained in address > block and address block TLV, instead of the message header, so there > is additional overhead. > - There is no RREP_ACK or other mechanism to verify bidirectionality > of links. > - It is unclear to me how the destination sequence number is used in > RREQ and what it serves for. > - Intermediate route replies are hard to secure with signatures >=20 > Best regards > Ulrich >=20 >=20 >=20 > Mobile Ad hoc Networks Working Group C. Perkins > Internet-Draft Futurewei > Intended status: Standards Track I. Chakeres > Expires: April 26, 2013 CenGen > October 23, 2012 >=20 >=20 > Dynamic MANET On-demand (AODVv2) Routing > draft-ietf-manet-dymo-23 >=20 > Abstract >=20 > The Dynamic MANET On-demand (AODVv2) routing protocol is intended for > use by mobile routers in wireless, multihop networks. >=20 > UH> It is really about dynamic topology, not "mobile routers". AODVv2 > may be used in non-mobile mesh networks with a dynamic topology. >=20 > AODVv2 > determines unicast routes among AODVv2 routers within the network in > an on-demand fashion, offering on-demand convergence in dynamic > topologies. >=20 > UH> What is on-demand convergence? >=20 > Status of this Memo >=20 > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. >=20 > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > This Internet-Draft will expire on April 26, 2013. >=20 > Copyright Notice >=20 > Copyright (c) 2012 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 1] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > described in the Simplified BSD License. >=20 >=20 > Table of Contents >=20 > 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 > 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 8 > 4.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 8 > 4.2. AODVv2 Message Structure and Information Elements . . . . 9 > 4.3. RteMsg-specific Protocol Elements . . . . . . . . . . . . 11 > 4.4. Route Error (RERR)-specific Protocol Elements . . . . . . 12 > 5. Detailed Operation for the Base Protocol . . . . . . . . . . . 13 > 5.1. AODVv2 Sequence Numbers . . . . . . . . . . . . . . . . . 13 > 5.1.1. Maintaining A Node's Own Sequence Number . . . . . . . 13 > 5.1.2. Actions After OwnSeqNum Loss . . . . . . . . . . . . . 13 > 5.2. AODVv2 Routing Table Operations . . . . . . . . . . . . . 13 > 5.2.1. Judging Routing Information's Usefulness . . . . . . . 13 > 5.2.2. Creating or Updating Route Table Entries . . . . . . . 15 > 5.2.3. Route Table Entry Timeouts . . . . . . . . . . . . . . 15 > 5.3. Routing Messages . . . . . . . . . . . . . . . . . . . . . 16 > 5.3.1. RREQ Creation . . . . . . . . . . . . . . . . . . . . 16 > 5.3.2. RREP Creation . . . . . . . . . . . . . . . . . . . . 17 > 5.3.3. RteMsg Handling . . . . . . . . . . . . . . . . . . . 18 > 5.4. Route Discovery . . . . . . . . . . . . . . . . . . . . . 20 > 5.5. Route Maintenance . . . . . . . . . . . . . . . . . . . . 21 > 5.5.1. Active Next-hop Router Adjacency Monitoring . . . . . 21 > 5.5.2. Updating Route Lifetimes During Packet Forwarding . . 22 > 5.5.3. RERR Generation . . . . . . . . . . . . . . . . . . . 22 > 5.5.4. RERR Handling . . . . . . . . . . . . . . . . . . . . 23 > 5.6. Unknown Message and TLV Types . . . . . . . . . . . . . . 24 > 5.7. Advertising Network Addresses . . . . . . . . . . . . . . 24 > 5.8. Simple Internet Attachment . . . . . . . . . . . . . . . . 24 > 5.9. Multiple Interfaces . . . . . . . . . . . . . . . . . . . 25 > 5.10. AODVv2 Control Packet/Message Generation Limits . . . . . 26 > 5.11. Optional Features . . . . . . . . . . . . . . . . . . . . 26 > 5.11.1. Expanding Rings Multicast . . . . . . . . . . . . . . 26 > 5.11.2. Intermediate RREP . . . . . . . . . . . . . . . . . . 27 > 5.11.3. Precursor Notification . . . . . . . . . . . . . . . . 27 > 5.11.4. Reporting Multiple Unreachable Nodes . . . . . . . . . 28 > 5.11.5. Message Aggregation . . . . . . . . . . . . . . . . . 28 > 5.11.6. Adding Additional Routing Information to a RteMsg . . 29 > 5.12. Administratively Configured Parameters and Timer Values . 30 > 5.13. IANA Considerations . . . . . . . . . . . . . . . . . . . 33 > 5.13.1. AODVv2 Message Types Specification . . . . . . . . . . 33 > 5.13.2. Message and Address Block TLV Type Specification . . . 33 > 5.13.3. Address Block TLV Specification . . . . . . . . . . . 34 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 2] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 5.14. Security Considerations . . . . . . . . . . . . . . . . . 34 > 5.15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 36 > 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 > 6.1. Normative References . . . . . . . . . . . . . . . . . . . 36 > 6.2. Informative References . . . . . . . . . . . . . . . . . . 37 > Appendix A. Changes since the Previous Version . . . . . . . . . 38 > Appendix B. Shifting Network Prefix Advertisement Between > AODVv2 Routers . . . . . . . . . . . . . . . . . . . 39 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 3] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 1. Overview >=20 > The Dynamic MANET On-demand (AODVv2) routing protocol [formerly named > DYMO] enables on-demand, multihop unicast routing among AODVv2 > routers in mobile ad hod networks [MANETs][RFC2119]. >=20 > UH> Why is RFC2119 cited here? >=20 > The basic > operations of the AODVv2 protocol are route discovery and route > maintenance. Route discovery is performed when an AODVv2 router must > transmit a packet towards a destination for which it does not have a > route. Route maintenance is performed to avoid dropping packets, > when a route being used to forward packets from the source to a > destination breaks, >=20 > UH> That is something that is unclear in the draft. Would data packets > be buffered on intermediate routers along their way? Would a new RREQ > be issed from intermediate routers? If not, packets would be dropped. >=20 > and to avoid prematurely expunging routes from > the route table. >=20 > During route discovery, an AODVv2 router initiates flooding of a > Route Request message (RREQ) throughout the network to find a route > to a particular destination, via the AODVv2 router responsible for > this destination. During this hop-by-hop flooding process, each > intermediate AODVv2 router receiving the RREQ message records a route > to the originator. When the target's AODVv2 router receives the > RREQ, it records a route to the originator and responds with a Route > Reply (RREP) unicast hop-by-hop toward the originating AODVv2 router. > Each intermediate AODVv2 router that receives the RREP creates a > route to the target, and then the RREP is unicast hop-by-hop toward > the originator. When the originator's AODVv2 router receives the > RREP, routes have then been established between the originating > AODVv2 router and the target AODVv2 router in both directions. >=20 > Route maintenance consists of two operations. In order to preserve > routes in use, AODVv2 routers extend route lifetimes upon > successfully forwarding a packet. In order to react to changes in > the network topology, AODVv2 routers monitor traffic being forwarded. > When a data packet is received for forwarding and a route for the > destination is not known or the route is broken, then the AODVv2 > router of the source of the packet is notified. A Route Error (RERR) > is transmitted to indicate the route to one or more affected > destination addresses is Broken >=20 > UH> s/Broken/broken/ >=20 > or missing. When the source's AODVv2 > router receives the RERR, it marks the route as broken. Before the > AODVv2 router can forward a packet to the same destination, it has to > perform route discovery again for that destination. >=20 > Similarly to AODV, AODVv2 uses sequence numbers to ensure loop > freedom [Perkins99]. >=20 > UH> Citation to AODV missing. Is AODVv2 updating or obsoleting AODV? >=20 > Sequence numbers enable AODVv2 routers to > determine the temporal order of AODVv2 route discovery messages, > thereby avoiding use of stale routing information. Also, AODVv2 uses > RFC 5444 message and TLV formats. >=20 > UH> As this is the successor to AODV, it would help to point out what > has been improved/changed compared to AODV. >=20 >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 4] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 2. Terminology >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > [RFC2119]. >=20 > Additionally, this document uses some terminology from [RFC5444]. >=20 > UH> Which one? >=20 > This document defines the following terminology: >=20 > Adjacency > A relationship between selected bi-directional neighboring routers > for the purpose of exchanging routing information. Not every pair > of neighboring routers will necessarily form an adjacency. > Neighboring routers may form an adjacency based on various > information or other protocols; for example, exchange of AODVv2 > routing messages, other protocols (e.g. NDP [RFC4861] or NHDP > [RFC6130]), or manual configuration. Loss of a routing adjacency > may also be based upon similar information; monitoring of > adjacencies where packets are being forwarded is required (see > Section 5.5.1). >=20 > Distance (Dist) > An unsigned integer which measures the distance a message or > information element has traversed. The minimum value of distance > is the number of IP hops traversed, 0 for local information. The > maximum value is 254. The value 255 is reserved to indicate that > the distance is unknown. >=20 > UH> Is this a metrics? Why integer and not float? Is this additive? > Why is it optional in the draft. Are there different metric types > supported in the same network? >=20 >=20 > AODVv2 Sequence Number (SeqNum) > An AODVv2 Sequence Number is an unsigned integer maintained by > each AODVv2 router. This sequence number guarantees the temporal > order of routing information to maintain loop-free routes. The > value zero (0) is reserved to indicate that the SeqNum for a > destination address is unknown. >=20 > UH> The last sentence is unclear. The first sentence said there is one > seq. number per router. The last sentence talks about sequence numbers > for destinations, which is a different thing. >=20 > reactive > A protocol operation is said to be "reactive" if it is performed > only in reaction to specific events. As used in this document, > "reactive" is essentially synonymous with "on-demand". >=20 > Router Client > An AODVv2 router may be configured with a list of other IP > addresses and networks which correspond to other non-router nodes > which require the services of the AODVv2 router for route > discovery and maintenance. An AODVv2 is always its own client, so > that the list of client IP addresses is never empty. corresponds >=20 > UH> s/corresponds/Corresponds/ >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 5] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > to the AODVv2 router process currently performing a calculation or > processing a message. >=20 > UH> I don't think it is a good idea to introduce that terminology. It > seems to be conflicting with the IP architecture of hosts and routers. > Is a Router Client a host? >=20 > Flooding > In this document, flooding a message refers to the process of > delivering the message to every AODVv2 router in the network. > This may be done according to methods specified in [RFC5148]. >=20 > UH> RFC5148 describes jitter in MANETs, not flooding methods. >=20 > Routable Unicast IP Address > A routable unicast IP address is a unicast IP address that when > put into the IP.SourceAddress or IP.DestinationAddress field is >=20 > UH> Notation not defined: "IP.x" >=20 > scoped sufficiently to be forwarded by a router. >=20 > UH> I am not quite sure what that means. Can you cite an RFC, maybe RFC40= 07? >=20 > Globally-scoped > unicast IP addresses and Unique Local Addresses (ULAs) [RFC6130] > are examples of routable unicast IP addresses. >=20 > UH> RFC6130 is NHDP, not ULA. ULA's are not globally routable and > cannot be accessed from outside a "site". >=20 > Originating Node (OrigNode) > The originating node is the data source node; if it is not itself > an AODVv2 router, its AODVv2 router creates a AODVv2 RREQ message > on its behalf in an effort to flood some routing information. The > originating node is also referred to as a particular message's > originator. >=20 > Target Node (TargetNode) > The TargetNode denotes the ultimate destination of a message. >=20 > UH> Is this for control packets only or for data traffic? Is that an IP a= ddress? >=20 > This Node (ThisNode) > ThisNode denotes the AODVv2 router currently processing an AODVv2 > message. >=20 > Route Error (RERR) > A RERR message is used to indicate that an AODVv2 router no longer > has a route to one or more particular destinations. >=20 > UH> Or it may have one, and data traffic was lost when sending it to > the next hop >=20 > Route Reply (RREP) > A RREP message is used to supply routing information about the > RREQ TargetNode to the RREQ OrigNode and the AODVv2 routers > between them. >=20 > Route Request (RREQ) > An AODVv2 router uses a RREQ message to discover a valid route to > a particular destination address, called the RREQ TargetNode. > When an AODVv2 router processes a RREQ, it learns routing > information on how to reach the RREQ OrigNode. >=20 > Type-Length-Value structure (TLV) > A generic way to represent information as specified in [RFC5444]. >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 6] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > Unreachable Node (UnreachableNode) > An UnreachableNode is a node for which a forwarding route is > unknown. >=20 > UH> Or to which data traffic has been lost while forwarding to the next h= op. >=20 >=20 > 3. Applicability Statement >=20 > The AODVv2 routing protocol is designed for stub (i.e., non-transit) > or disconnected (i.e., from the Internet) mobile ad hoc networks > (MANETs). AODVv2 handles a wide variety of mobility patterns by > dynamically determining routes on-demand. AODVv2 also handles a wide > variety of traffic patterns. In networks with a large number of > routers, AODVv2 is best suited for sparse traffic scenarios where any > particular router forwards packets to only a small percentage of the > AODVv2 routers in the network, due to the on-demand nature of route > discovery and route maintenance. >=20 > AODVv2 is applicable to memory constrained devices, since little > routing state is maintained in each AODVv2 router. Only routing > information related to routes between active sources and destinations > is maintained, in contrast to proactive routing protocols that > require routing information to all routers within the routing region > be maintained. >=20 > AODVv2 supports routers with multiple interfaces. In addition to > routing for their local processes, AODVv2 routers can also route on > behalf of other non-routing nodes (i.e., "hosts"), reachable via > those interfaces. Any such node which is not itself an AODVv2 router > SHOULD NOT be served by more than one AODVv2 router. >=20 > UH> I would rather not use RFC2119 in an applicability statement. This > is not normative. >=20 > Although AODVv2 > is closely related to AODV [RFC3561], and has some of the features of > DSR [RFC4728], AODVv2 is not interoperable with either of those other > two protocols. >=20 > AODVv2 routers perform route discovery to find a route to a > particular destination. Therefore, AODVv2 routers MUST must be > configured to respond to RREQs for a certain set of addresses. When > AODVv2 is the only protocol interacting with the forwarding table, > AODVv2 MAY be configured to perform route discovery for all unknown > unicast destinations. >=20 > At all times within an AODVv2 routing region, only one AODVv2 router > SHOULD be serve any routing client. The coordination among multiple > AODVv2 routers to distribute routing information correctly for a > shared address (i.e. an address that is advertised and can be reached > via multiple AODVv2 routers) is not described in this document. The > AODVv2 router operation of shifting responsibility for a routing > client from one AODVv2 router to another is mentioned in Appendix B >=20 > UH> I am not sure that it is a good idea to include multi-homing in a > short paragraph in Appendix B. I think this whole section can be > removed. >=20 >=20 > Each AODVv2 router, if serving router clients other than itself, is >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 7] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > configured with information about the IP addresses of its clients. > There is no requirement that an AODVv2 router have information about > the router clients of other AODVv2 routers. Address assignment > procedures are entirely out of scope for AODVv2. >=20 > AODVv2 only utilizes bidirectional links. In the case of possible > unidirectional links, either blacklists (see Section 5.13.2) or other > means (e.g. adjacency establishment with only neighboring routers > that have bidirectional communication as indicated by NHDP [RFC6130]) >=20 > UH> The blacklisting is not specified in this document. >=20 > of ensuring and monitoring bi-directionality is recommended. > Otherwise, persistent packet loss could occur. >=20 > The routing algorithm in AODVv2 may be operated at layers other than > the network layer, using layer-appropriate addresses. >=20 > UH> Yes, but the whole document is limited to IP. It is tied to IP > headers, UDP etc at multiple places. >=20 > The routing > algorithm makes >=20 > UH> + "use" >=20 > of some persistent state; if there is no persistent > storage available for this state, recovery can exact a performance > penalty in case of AODVv2 router reboots. >=20 >=20 > 4. Data Structures >=20 > UH> There is a mixture between information bases and message formats. > I would rather have two seperate sections for that. > UH> There are no other information sets that I believe are required > for AODV: blacklisted set, set of local interfaces, and a set of the > hosts that this router is responsible. >=20 > 4.1. Route Table Entry >=20 > The route table entry is a conceptual data structure. > Implementations may use any internal representation so long as it > provides access to the same information as specified below. >=20 > Conceptually, a route table entry has the following fields: >=20 > Route.Address > The (host or network) destination address of the node(s) > associated with the routing table entry. >=20 > Route.Prefix > The value is the length of the netmask/prefix. >=20 > UH> in octets? >=20 > If the value of > the Route.Prefix is different than the length of addresses in the > address family used by the AODVv2 routers, the associated address > is a routing prefix, rather than a host address. >=20 > Route.SeqNum > The AODVv2 SeqNum associated with a route table entry. >=20 > Route.NextHopAddress > An IP address of the adjacent AODVv2 router on the path toward the > Route.Address. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 8] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > Route.NextHopInterface > The interface used to send packets toward the Route.Address. >=20 > Route.Broken > A flag indicating whether this Route is broken. This flag is set > to true if the next-hop becomes unreachable or in response to > processing to a RERR (see Section 5.5.4). >=20 > The following field is optional: >=20 > Route.Dist > A dimensionless metric indicating the distance traversed before > reaching the Route.Address node. >=20 > UH> Why is this optional? It makes the whole specification more > complicated, in particular interoperability. I cannot imagine cases > where you are not interested in the distance. > UH> Is this metric additive? is it only integer? is it used in > addition to hop-count or instead? >=20 > Not including optional information may cause performance degradation, > but it will not prohibit the protocol from discovering valid routes. >=20 > In addition to a route table data structure, each route table entry > may have several timers associated with the information. Timers and > timeouts are discussed in Section 5.2.3. >=20 > UH> That forward link makes it difficult. Why not include the > expiration timers here, similar to OLSRv2? >=20 > 4.2. AODVv2 Message Structure and Information Elements >=20 > IP Protocol Number 138 (manet) has been reserved for MANET protocols > [RFC5498]. In addition to using this IP protocol number, AODVv2 may > use UDP at destination port 269 (manet) [RFC5498]. >=20 > UH> may or MAY? >=20 > AODVv2 messages are transmitted in packets that conform to the > generalized packet and message format as described in [RFC5444]. > Here is a brief description of the format. >=20 >=20 > A packet formatted according to RFC5444 contains zero or more > messages. >=20 >=20 > A message contains a message header, message TLV block, and zero > or more address blocks. >=20 >=20 > Each of the address blocks may also have an associated address TLV > block. >=20 > UH> Each address block *must* have a TLV block (it may be empty though). >=20 > All AODVv2 messages SHOULD be sent using the IP protocol number (138) > reserved for manet protocols [RFC5498]; or the UDP destination port > (269) reserved for manet protocols [RFC5498] and IP protocol number > for UDP. >=20 > UH> That is redundant to the first paragraph of this section. >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 9] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > Most AODVv2 messages are sent with the IP destination address set to > the link-local multicast address LL-MANET-Routers [RFC5498] unless > otherwise specified. Therefore, all AODVv2 routers SHOULD subscribe > to LL-MANET-Routers [RFC5498] to receiving AODVv2 messages. Note > that multicast packets MAY be sent via unicast. >=20 > UH> That sounds confusing: multicast packets MAY be sent via unicast. > First, what is a multicast packet? (you mean an IP packet with a > multicast destination address>). Why MAY? >=20 > For example, this > may occur for certain link-types (non broadcast mediums), for > manually configured router adjacencies, or in order to improve > robustness. >=20 > UH> How would one manually configure a router adjacency? >=20 > When describing AODVv2 protocol messages, it is necessary to refer to > fields in several distinct parts of the overall packet. >=20 > UH> Since there is an RFC5444 demultiplexer, AODVv2 would never see > the packet. So I think it's better not to use that term here. >=20 > These > locations include the IP header, the UDP header, and fields from > [RFC5444]. This document uses the notational conventions found in > table 1. >=20 > +---------------------------+-------------------+ > | Information Location | Notational Prefix | > +---------------------------+-------------------+ > | IP header | IP. | > | RFC5444 message header | MsgHdr. | > | RFC5444 message TLV | MsgTLV. | > | RFC5444 address blocks | AddBlk. | > | RFC5444 address block TLV | AddTLV. | > +---------------------------+-------------------+ >=20 > Table 1 >=20 > The IPv4 TTL (IPv6 Hop Limit) field for all packets containing AODVv2 > messages is set to 255. >=20 > UH> I think that's the job of the RFC5444 multiplexer. >=20 > If a packet is received with a value other > than 255, any AODVv2 message contained in the packet MUST be ignored > by AODVv2. >=20 > UH> No, the packet would never be received by AODVv2. Only a message woul= d. >=20 > This mechanism, known as "The Generalized TTL Security > Mechanism" (GTSM) [RFC5082] helps to ensure that packets have not > traversed any intermediate routers. >=20 > UH> Again, part of the RFC5444 multiplexer. >=20 > The length of an address (32 bits for IPv4 and 128 bits for IPv6) > inside an AODVv2 message depends on the msg-addr-length (MAL) in the > msg-header, as specified in [RFC5444]. >=20 > UH> Limitation of AODVv2 to IP addresses. It could also be used for > compressed (lowpan) addresses or MAC addresses. >=20 > IP packets containing AODVv2 protocol messages SHOULD be given > priority queuing and channel access. >=20 > UH> Not the task of AODVv2, but the RFC5444 multiplexer >=20 > AODVv2 messages require the following information: >=20 > IP.SourceAddress > The IP address of the node currently sending this packet. This > field is generally filled automatically by the operating system > and should not require special handling. >=20 > UH> An AODVv2 message cannot have an IP address. That's a different > layer. The IP packet that contains an RFC5444 packet (which the IP > layer received from the RFC5444 multiplexer) has that address. > Also, it is not necessarily the node currently sending this "packet"; > ThisNode could receive a message, then it is not sending this packet. >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 10] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > IP.DestinationAddress > The IP address of the packet destination. For multicast messages > the IP.DestinationAddress is set to LL-MANET-Routers [RFC5498]. > For unicast messages the IP.DestinationAddress is set to the > NextHopAddress toward the TargetNode. >=20 > MsgHdr.HopLimit > The remaining number of hops this message is allowed to traverse. > If an AODVv2 message within a RFC 5444 packet has exhausted its > hop limit, then it should be removed from the packet. >=20 > UH> This seems to be mixing normative protocol behavior with field > definitions. >=20 > 4.3. RteMsg-specific Protocol Elements >=20 > AODVv2 message types RREQ and RREP are denoted as Routing Messages > (RteMsgs) and used to flood routing information. >=20 > UH> RREPs are not flooded. >=20 > RREQ and RREP have > similar information and function, but have slightly different > handling rules. The main difference between the two messages is that > RREQ messages are generally broadcast to solicit a RREP, and > conversely a RREP is the unicast response to RREQ. RteMsg creation > and handling are described in Section 5.3. >=20 > Unicast AODVv2 RteMsgs (e.g. RREP) unless otherwise specified are > sent with the IP destination set to the Route.NextHopAddress of the > route to the TargetNode. >=20 > A RteMsg REQUIRES the following information in addition to the fields > indicated in Section 4.2: >=20 > UH> REQUIRES is not RFC2110, it's REQUIRED >=20 > AddBlk.TargetNode.Address > The IP address of the message TargetNode. In a RREQ the IP > address of the message TargetNode is the destination address for > which route discovery is being performed. In a RREP the > TargetNode is the RREQ OrigNode address. The TargetNode address > is the first address in a routing message. >=20 > UH> I don't think it's a good idea to mandate order of addresses. > Other extensions to the protocol may add addresses before. It would be > better to associate with an address block TLV. >=20 > AddBlk.OrigNode.Address > The IP address of the originator and its associated prefix length. > In a RREQ the OrigNode is the source's address and prefix. In a > RREP the OrigNode is the RREQ TargetNode's address and prefix for > which a RREP is being generated. This address is the second > address in the message for RREQ. >=20 > UH> Again, mandating address order is dangerous. >=20 > OrigNode.AddTLV.SeqNum > The AODVv2 sequence number of the originator's AODVv2 router. >=20 > UH> Why not use the message sequence number? This will save several > bytes. Or at least a message TLV. >=20 > A RteMsg may optionally include the following information: >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 11] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > TargetNode.AddTLV.SeqNum > The last known AODVv2 sequence number of the TargetNode. >=20 > UH> Using which TLV type? (reference to IANA section) >=20 > AddBlk.AdditionalNode.Address > The IP address of an additional node that can be reached via the > AODVv2 router adding this information. Each > AdditionalNode.Address MUST include its prefix. Each > AdditionalNode.Address MUST also have an associated Node.SeqNum in > the address TLV block. >=20 > UH> Is Node.foo defined before? >=20 > AdditionalNode.AddTLV.SeqNum > The AODVv2 sequence number associated with this routing > information. >=20 > UH> What is AdditionalNode? >=20 > OrigNode.AddTLV.Dist > A metric of the distance to reach the associated OrigNode.Address. > This field is incremented by at least one at each intermediate > AODVv2 router. >=20 > UH> Why not use a message TLV? >=20 > AdditionalNode.AddTLV.Dist > A metric of the distance to reach the associated > AdditionalNode.Address. This field is incremented by at least one > at each intermediate AODVv2 router. >=20 > 4.4. Route Error (RERR)-specific Protocol Elements >=20 > A RERR message is used to flood the information that a route is not > available for one or more particular addresses. >=20 > UH> RERR are mostly sent unicast, not flooded. >=20 > RERR creation and handling are described in Section 5.5. >=20 > A RERR requires the following information in addition to the field > indicated in Section 4.2: >=20 > AddBlk.UnreachableNode.Address > The address of an UnreachableNode and its associated prefix > length. Multiple unreachable addresses may be included in a RERR. >=20 > A Route Error may optionally include the following information: >=20 > UnreachableNode.AddTLV.SeqNum > The last known AODVv2 sequence number of the unreachable node. If > a SeqNum for an address is zero (0) or not included, it is assumed > to be unknown. This case occurs when a node receives a message to > forward to a destination for which it does not have any > information in its routing table. >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 12] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 5. Detailed Operation for the Base Protocol >=20 > 5.1. AODVv2 Sequence Numbers >=20 > AODVv2 sequence numbers allow AODVv2 routers to judge the freshness > of routing information and consequently ensure loop freedom. >=20 > 5.1.1. Maintaining A Node's Own Sequence Number >=20 > AODVv2 requires that each AODVv2 router in the network maintain its > own AODVv2 sequence number (OwnSeqNum). OwnSeqNum a 16-bit unsigned > integer. An AODVv2 router increments its OwnSeqNum under the > circumstances described in Section 5.3. >=20 > Incrementing an OwnSeqNum whose value is the largest largest possible > number representable as a 16-bit unsigned integer (i.e., 65,535), > MUST be set to one (1). In other words, the sequence number after > 65,535 is 1. >=20 > 5.1.2. Actions After OwnSeqNum Loss >=20 > An AODVv2 router SHOULD maintain its own sequence number in > persistent storage. >=20 > If an AODVv2 router's OwnSeqNum is lost, it MUST take certain actions > to avoid creating routing loops. To prevent this possibility after > OwnSeqNum loss an AODVv2 router MUST wait for at least > ROUTE_DELETE_TIMEOUT before fully participating in the AODVv2 routing > protocol. If an AODVv2 protocol message is received during this > waiting period, the AODVv2 router SHOULD perform normal route table > entry updates but MUST NOT transmit or retransmit any AODVv2 RREQ or > RREP messages. If a data packet is received for forwarding to > another destination during this waiting period, the AODVv2 router > MUST transmit a RERR message indicating that this route is not > available and reset its waiting timeout. At the end of the waiting > period the AODVv2 router sets its OwnSeqNum to one (1) and begin > participating. >=20 > The longest a node need wait is ROUTE_SEQNUM_AGE_MAX_TIMEOUT. At the > end of the maximum waiting period a node SHOULD set its OwnSeqNum to > one (1) and begins participating. >=20 > 5.2. AODVv2 Routing Table Operations >=20 > UH> This whole structure is unclear. Where do we come to this? > Wouldn't it be better to start of with message generation/processing > before saying how to update the routing tuples as a consequence to > received messages? >=20 > 5.2.1. Judging Routing Information's Usefulness >=20 > Given a route table entry (Route.SeqNum, Route.Dist, and > Route.Broken) >=20 > UH> A route table entry has more fields in section 4.1 >=20 > and incoming routing information for a particular >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 13] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > destination in a RteMsg (Node.SeqNum, Node.Dist, and RteMsg message > type - RREQ/RREP), the incoming routing information is classified as > follows: >=20 > 1. Stale (Node.SeqNum < Route.SeqNum) > If Node.SeqNum < Route.SeqNum (using signed 16-bit arithmetic) the > incoming information is stale. Using stale routing information is > not allowed, since that might result in routing loops. >=20 > UH> So what should my implementation then? Continue with the next > step? Discard the message? >=20 > 2. Not safe against loops > If Node.SeqNum =3D=3D Route.SeqNum, additional information MUST be > examined. If Route.Dist or Node.Dist is unknown or zero (0), or > if Node.Dist > Route.Dist + 1, then the incoming information is > not guaranteed to prevent routing loops. Using such incoming > routing information is not allowed. The following pseudocode is > offered to indicate the logical condition under which the incoming > information is not guaranteed to protect against loops. >=20 > (Node.SeqNum =3D=3D Route.SeqNum) AND > ((Node.Dist > Route.Dist + 1) OR >=20 > UH> Would cause a null-pointer exception in my implementation if Dist > is not contained in the message. >=20 > (Route.Dist is unknown) OR (Node.Dist is unknown)) >=20 > 3. Offers no improvement > In case of known equal SeqNum, the information is considered worse > than the existing route table information in multiple cases: (case > i) if Node.Dist > Route.Dist (it is a more expensive route) AND > Route.Broken =3D=3D false; (case ii) if Node.Dist =3D=3D Route.Dist = (equal > distance route) AND Route.Broken =3D=3D false AND this RteMsg is a > RREQ. Such RREQs offer no improvement and SHOULD NOT be > retransmitted. Updating route table entries using such incoming > routing information is not allowed. >=20 > ((Node.SeqNum =3D=3D Route.SeqNum) AND > (((Node.Dist > Route.Dist) AND (Route.Broken =3D=3D false)) OR > ((Node.Dist =3D=3D Route.Dist) AND > (RteMsg is RREQ) AND (Route.Broken =3D=3D false)))) >=20 > 4. Offers improvement > Incoming routing information that does not match any of the above > criteria is loop-free and better than the existing routing table > information. We provide the following pseudo-code to determine > whether incoming routing information should be used to update an > existing route table entry. >=20 > (/* signed 16-bit arithmetic */ Node.SeqNum - Route.SeqNum > 0) OR > ((Node.SeqNum =3D=3D Route.SeqNum) AND > [(Node.Dist < Route.Dist) OR > ((Route.Broken =3D=3D true) AND (Node.Dist <=3D Route.Dist + 1))= OR >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 14] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > ((RteMsg is RREP) AND (Node.Dist =3D=3D Route.Dist)] >=20 > 5.2.2. Creating or Updating Route Table Entries >=20 > Each route table entry is populated with the following information: >=20 > UH> Why "each" entry? When does this happen? It seems this only sets > the route to the previous hop; what happens with a route to the > originator? What happens if a route already exists and is only > updated? How are both forward and reverse routes updated? >=20 > 1. the Route.Address is set to Node.Address, >=20 > 2. the Route.Prefix is set to the Node.Prefix. >=20 > 3. the Route.SeqNum is set to the Node.SeqNum, >=20 > 4. the Route.NextHopAddress is set to the IP.SourceAddress (i.e., an > address of the node that last transmitted the RteMsg packet) >=20 > 5. the Route.NextHopInterface is set to the interface on which the > incoming AODVv2 packet was received, >=20 > 6. the Route.Broken flag is set to false, >=20 > 7. if known, the Route.Dist is set to the Node.Dist, >=20 > The timer for the minimum delete timeout (ROUTE_AGE_MIN) is set to > ROUTE_AGE_MIN_TIMEOUT. The timer for the maximum delete timeout > (ROUTE_SEQNUM_AGE_MAX) is set to Node.AddTLV.VALIDITY_TIME [RFC5497] > if included; otherwise, ROUTE_SEQNUM_AGE_MAX is set to > ROUTE_SEQNUM_AGE_MAX_TIMEOUT. The usage of these timers and others > are described in Section 5.2.3. >=20 > UH> I don't understand how a sequence number can expire. Also, in > section 4.1 there was no mention of the VALIDITY_TIME Tlv in a > message. What happens if it is not contained? >=20 > With these assignments to the route table entry, a route has been > created and the Route.Forwarding flag set. Afterward, the route can > be used to send any buffered data packets and to forward any incoming > data packets for Route.Address. This route also fulfills any > outstanding route discovery (RREQ) attempts for Node.Address. >=20 > 5.2.3. Route Table Entry Timeouts >=20 > 5.2.3.1. Minimum Delete Timeout (ROUTE_AGE_MIN) >=20 > When an AODVv2 router transmits a RteMsg, other AODVv2 routers expect > the transmitting AODVv2 router to have a forwarding route to the > RteMsg originator. A route table entry SHOULD be kept in the route > table for at least ROUTE_AGE_MIN after it has been updated. Failure > to maintain the route table entry might result in lost messages/ > packets, or several duplicate messages. >=20 > After the ROUTE_AGE_MIN timeout a route can safely be deleted. >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 15] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 5.2.3.2. Maximum Sequence Number Delete Timeout (ROUTE_SEQNUM_AGE_MAX) >=20 > Sequence number information for route table entries is time > sensitive, and MUST be deleted after a time in order to ensure loop- > free routing. >=20 > After the ROUTE_SEQNUM_AGE_MAX timeout a route's sequence number > information MUST be discarded. >=20 > UH> What does it mean to discard a sequence number information? To set > it to zero in the route entry? What are the relationships between > ROUTE_SEQNUM_AGE_MUX and ROUTE_AGE_MIN? (can one be smaller than the > other) >=20 > 5.2.3.3. Recently Used Timeout (ROUTE_USED) >=20 > When a route is used to forward data packets, this timer is set to > expire after ROUTE_USED_TIMEOUT, as discussed in Section 5.5.2. >=20 > If a route has not been used recently, then a timer for ROUTE_DELETE > is set to ROUTE_DELETE_TIMEOUT. >=20 > 5.2.3.4. Delete Information Timeout (ROUTE_DELETE) >=20 > As time progresses the likelihood that old routing information is > useful decreases, especially if the network nodes are mobile. > Therefore, old information SHOULD be deleted. >=20 > After the ROUTE_DELETE timeout if a forwarding route exists it SHOULD > be removed, and the routing table entry SHOULD also be deleted. >=20 > UH> There are quite a few timers, which is confusing. What happens if > one timer fires before the other? Do we really need that many timers? >=20 > 5.3. Routing Messages >=20 > 5.3.1. RREQ Creation >=20 > Before an AODVv2 router creates a RREQ it SHOULD increment its > OwnSeqNum by one (1) according to the rules specified in Section 5.1. >=20 > UH> Why not MUST? What happens if one does not increase it. In > general, there are many SHOULDs in the document, which probably should > be MUSTs. >=20 > Incrementing OwnSeqNum will ensure that all nodes with existing > routing information will consider this new information preferable to > existing routing table information. If the sequence number is not > incremented, certain AODVv2 routers might not consider this > information preferable, if they have existing better routing > information. >=20 > First, ThisNode adds the AddBlk.TargetNode.Address to the RREQ; the > unicast IP Destination Address for which a forwarding route does not > exist. >=20 > If a previous value of the TargetNode.SeqNum is known (from a routing > table entry using longest-prefix matching), it SHOULD be placed in > TargetNode.AddTLV.SeqNum in all but the last RREQ attempt. If a > TargetNode.SeqNum is not included, it is assumed to be unknown by > handling nodes. This operation ensures that no intermediate AODVv2 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 16] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > routers reply, and ensures that the TargetNode's AODVv2 router > increments its sequence number. >=20 > Next, ThisNode adds AddBlk.OrigNode.Address, its prefix, and the > OrigNode.AddTLV.SeqNum (OwnSeqNum) to the RteMsg. >=20 > The OrigNode.Address is the address of the source for which this > AODVv2 router is initiating this route discovery. The > OrigNode.Address MUST be a unicast address. This information will be > used by nodes to create a route toward the OrigNode, enabling > delivery of a RREP, and eventually used for proper forwarding of data > packets. >=20 > If OrigNode.Dist is included it is set to a number, greater than zero > (0), representing the distance between OrigNode and ThisNode. >=20 > The MsgHdr.HopLimit SHOULD be set to MSG_HOPLIMIT. >=20 > UH> Why SHOULD? >=20 > 5.3.2. RREP Creation >=20 > First, the AddBlk.TargetNode.Address is added to the RREP. The > TargetNode is the ultimate destination of this RREP; the RREQ > OrigNode.Address. >=20 > Next, AddBlk.OrigNode.Address and prefix are added to the RREP. The > AddBlk.OrigNode.Address is the RREQ TargetNode.Address. The > AddBlk.OrigNode.Address MUST be a unicast IP address. ThisNode > SHOULD advertise the largest known prefix containing > AddBlk.OrigNode.Address. >=20 > When the RteMsg TargetNode's AODVv2 router creates a RREP, if the > TargetNode.SeqNum was not included in the RREQ, ThisNode MUST > increment its OwnSeqNum by one (1) according to the rules specified > in Section 5.1. >=20 > If TargetNode.SeqNum was included in the RteMsg and TargetNode.SeqNum > - OwnSeqNum < 0 (using signed 16-bit arithmetic), OwnSeqNum SHOULD be > incremented by one (1) according to the rules specified in > Section 5.1. >=20 > If TargetNode.SeqNum is included in the RteMsg and TargetNode.SeqNum > =3D=3D OwnSeqNum (using signed 16-bit arithmetic) and OrigNode.Dist wil= l > not be included in the RREP being generated, OwnSeqNum SHOULD be > incremented by one (1) according to the rules specified in > Section 5.1. >=20 > If OwnSeqNum is not incremented the routing information might be > considered stale. In this case, the RREP might not reach the RREP >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 17] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > Target. >=20 > After any of the sequence number operations above, the RREP > OrigNode.AddTLV.SeqNum (OwnSeqNum) MUST also be added to the RREP. >=20 > Other AddTLVs in the RREP for the OrigNode and TargetNode SHOULD be > included and set accordingly. If OrigNode.Dist is included it is set > to a number greater than zero (0) and less than or equal to 254. The > Distance value will influence judgment of the routing information > (Section 5.2.1) against known information at other AODVv2 routers > that handle this RteMsg. >=20 > The MsgHdr.HopLimit is set to MSG_HOPLIMIT. >=20 > The IP.DestinationAddress for RREP is set to the IP address of the > Route.NextHopAddress for the route to the RREP TargetNode. >=20 > 5.3.3. RteMsg Handling >=20 > UH> Very difficult to parse this section. Not much RFC2119 language. >=20 > UH> Is there any check for invalid messages (similar to OLSRv2/NHDP?) > External mechanisms should be allowed to add reasons to reject a > message as invalid, e.g. a security mechanism. >=20 > First, ThisNode examines the RteMsg to ensure that it contains the > required information: MsgHdr.HopLimit, AddBlk.TargetNode.Address, > AddBlk.OrigNode.Address, and OrigNode.AddTLV.SeqNum. If the required > information does not exist, the message is discarded and further > processing stopped. >=20 > ThisNode MUST only handle AODVv2 messages from adjacent routers. >=20 > UH> What does that mean? >=20 > ThisNode checks if the AddBlk.OrigNode.Address is a valid routable > unicast address. >=20 > UH> How? >=20 > If not, the message is ignored and further > processing stopped. >=20 > ThisNode also checks whether AddBlk.OrigNode.Address is an address > handled by this AODVv2 router. >=20 > UH> How? >=20 > If this node is the originating > AODVv2 router, the RteMsg is dropped. >=20 > UH> Why not do this further above, before doing all the other checks? >=20 > ThisNode checks if the AddBlk.TargetNode.Address is a valid routable > unicast address. If the address is not a valid unicast address, the > message is discarded and further processing stopped. >=20 > Next, ThisNode checks whether its routing table has an entry to the > AddBlk.OrigNode.Address using longest-prefix matching [RFC1812]. >=20 > UH> RFC1812 is IPv4 only. >=20 > If > a route with a valid Route.SeqNum does not exist, >=20 > UH> What is a "valid" sequence number? >=20 > then the new > routing information is used to create a new route table entry is > created >=20 > UH> to "create" ... is "created" >=20 > and updated as described in Section 5.2.2. >=20 > UH> This jumping back is difficult to parse. >=20 > If a route table > entry does exists and it has a known Route.SeqNum, the incoming > routing information is compared with the route table entry following > the procedure described in Section 5.2.1. If the incoming routing > information is considered preferable, the route table entry is >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 18] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > updated as described in Section 5.2.2. >=20 > At this point, if the routing information for the OrigNode was not > preferable then this RteMsg SHOULD be discarded and no further > processing of this message SHOULD be performed. >=20 > UH> Why SHOULD? Why not MUST? >=20 > If the TargetNode is a router client of ThisNode this RteMsg is a > RREQ, then ThisNode responds with a RREP to the RREQ OrigNode (the > new RREP's TargetNode). The procedure for issuing a new RREP is > described in Section 5.3.2. Afterwards, ThisNode need not perform > any more operations for the RteMsg being processed. >=20 > As an alternative to issuing a RREP, ThisNode MAY choose to > distribute routing information about ThisNode (the RREQ TargetNode) > more widely. That is, ThisNode MAY optionally perform a route > discovery by issuing a RREQ with ThisNode listed as the TargetNode, > using the procedure in Section 5.3.1. At this point, ThisNode need > not perform any more operations for the RteMsg being processed. >=20 > UH> I don't understand the last paragraph. Is this some remainder of > intermediate route reply? In which conditions should a router send a > RREQ instead of a RREP? >=20 >=20 > For each address (except the TargetNode) in the RteMsg that includes > AddTLV.Dist information, the AddTLV.Dist information is incremented > by at least one (1). >=20 > UH> By how much then? >=20 > The updated Distance value will influence > judgment of the routing information (Section 5.2.1) against known > information at other AODVv2 routers that handle this RteMsg. >=20 > If the resulting Distance value for the OrigNode is greater than 254, > the message is discarded. If the resulting Distance value for > another node is greater than 254, >=20 > UH> Which other node? >=20 > the associated address and its > information are removed from the RteMsg. >=20 > UH> That makes end-to-end security impossible. >=20 > If the MsgHdr.HopLimit is > equal to one (1), then the message is discarded. Otherwise, the > MsgHdr.HopLimit is decremented by one (1). >=20 > If ThisNode is not the TargetNode, AND this RteMsg is a RREQ, then > the current RteMsg (as altered by the procedure defined above) SHOULD > be sent to the IP multicast address LL-MANET-Routers [RFC5498]. If > the RREQ is unicast, the IP.DestinationAddress is set to the > NextHopAddress. >=20 > UH> The unicast RREQ mechanism is not really explained anywhere. Where > is the nexthopaddress acquired from? >=20 >=20 > If ThisNode is not the TargetNode, AND this RteMsg is a RREP, then > the current RteMsg is sent to the Route.NextHopAddress for the RREP's > TargetNode.Address. If no forwarding route exists to > TargetNode.Address, then a RERR SHOULD be issued to the OrigNode of > the RREP. >=20 > By sending the updated RteMsg, ThisNode advertises that it will route > for addresses contained in the outgoing RteMsg based on the > information enclosed. ThisNode MAY choose not to send the RteMsg, > though not resending this RteMsg could decrease connectivity in the >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 19] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > network or result in a non-shortest distance path. >=20 > The circumstances under which ThisNode might choose to not re-issue a > RteMsg are not specified in this document. Some examples might > include the following: >=20 > o if ThisNode does not want to advertise routing for the contained > addresses because it is already heavily loaded >=20 > o if ThisNode has already issued identical routing information (e.g. > ThisNode had recently issued a RteMsg with the same distance) >=20 > o if ThisNode is low on energy and does not want to expend energy > for protocol message sending or packet forwarding >=20 > 5.4. Route Discovery >=20 > When an AODVv2 router needs to forward a data packet and it does not > have a forwarding route to the destination address, it sends a RREQ > (described in Section 5.3.1) to discover a route to the particular > destination (TargetNode). >=20 > After issuing a RREQ, the AODVv2 router (OrigNode) waits for a RREP > indicating the next hop for a route to the TargetNode. If a route is > not created within RREQ_WAIT_TIME, OrigNode may again try to discover > a route by issuing another RREQ using the procedure defined in > Section 5.3.1 again. Route discovery SHOULD be considered to have > failed after DISCOVERY_ATTEMPTS_MAX and the corresponding wait time > for a response to the final RREQ. >=20 > To reduce congestion in a network, repeated attempts at route > discovery for a particular TargetNode SHOULD utilize an binary > exponential backoff. >=20 > Data packets awaiting a route SHOULD be buffered by the source's > AODVv2 router. This buffer SHOULD have a fixed limited size > (BUFFER_SIZE_PACKETS or BUFFER_SIZE_BYTES). Determining which > packets to discard first is a matter of policy at each AODVv2 router; > in the absence of policy constraints, by default older data packets > SHOULD be discarded first. Buffering of data packets can have both > positive and negative effects, and therefore settings for buffering > (BUFFER_DURING_DISCOVERY) SHOULD be administratively configurable. > Nodes without sufficient memory available for buffering may be > configured with BUFFER_DURING_DISCOVERY =3D FALSE; this will affect the > latency required for launching TCP applications to new destinations. >=20 > UH> I am against including this buffering mechanism in this document. > This is a mixture of the routing plane and the data plane. There are > other forwarding mechanisms that would be affected by this > specification. >=20 > If a route discovery attempt has failed (i.e. an attempt or multiple > attempts have been made without receiving a RREP) to find a route to >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 20] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > the TargetNode, any data packets buffered for the corresponding > TargetNode MUST BE dropped and a Destination Unreachable ICMP message > (Type 3) SHOULD be delivered to the source of the data packet. The > code for the ICMP message is 1 (Host unreachable error). If the > AODVv2 router is not the source (OrigNode), then the ICMP is sent > over the interface from which the source sent the packet to the > AODVv2 router. >=20 > 5.5. Route Maintenance >=20 > A RERR SHOULD be issued if a data packet is to be forwarded and it > cannot be delivered to the next-hop because no forwarding route for > the IP.DestinationAddress exists; RERR generation is described in > Section 5.5.3. >=20 > Upon this condition, an ICMP Destination Unreachable message SHOULD > NOT be generated unless this router is responsible for the > IP.DestinationAddress and that IP.DestinationAddress is known to be > unreachable. >=20 > UH> How is that generated (with which content)? >=20 > In addition to inability to forward a data packet, a RERR SHOULD be > issued immediately after detecting a broken link (see Section 5.5.1) > of a forwarding route to quickly notify AODVv2 routers that certain > routes are no longer available. If a newly unavailable route has not > been used recently (indicated by ROUTE_USED), the RERR SHOULD NOT be > generated. >=20 > UH> SHOULD NOT or MUST NOT? What are the consequences of doing so when > using SHOULD NOT? >=20 > 5.5.1. Active Next-hop Router Adjacency Monitoring >=20 > Nodes SHOULD monitor connectivity to adjacent next-hop AODVv2 routers > on forwarding routes. This monitoring can be accomplished by one or > several mechanisms, including: >=20 > o Neighborhood discovery [RFC6130] >=20 > o Route timeout >=20 > o Lower layer trigger that a neighboring router is no longer > reachable >=20 > o Other monitoring mechanisms or heuristics >=20 > Upon determining that a next-hop AODVv2 router has become > unreachable, ThisNode MUST remove the affected forwarding routes > (those using the unreachable next-hop) and unset the Route.Forwarding > flag. ThisNode also flags the associated routes in AODVv2's routing > table as Broken. For each broken route the timer for ROUTE_DELETE is > set to ROUTE_DELETE_TIMEOUT. >=20 > UH> How can the flags be set if the routes are removed before? >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 21] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 5.5.2. Updating Route Lifetimes During Packet Forwarding >=20 > To avoid removing the forwarding route to reach an IP.SourceAddress, > ThisNode SHOULD set the "ROUTE_USED" timeout to the value > ROUTE_USED_TIMEOUT for the route to that IP.SourceAddress upon > receiving a data packet or an AODVv2 message. If the timer for > ROUTE_DELETE is set, that timer is removed. The Route.Broken flag is > unset. >=20 > To avoid removing the forwarding route to the IP.DestinationAddress > that is being used, ThisNode SHOULD set the "ROUTE_USED" timeout to > the value ROUTE_USED_TIMEOUT for the route to the > IP.DestinationAddress upon sending a data packet or an AODVv2 > message. If the timer for ROUTE_DELETE is set, it is removed. The > Route.Broken flag is unset. >=20 > 5.5.3. RERR Generation >=20 > When an AODVv2 router receives a packet (from PrevHopAddress), and > the router (ThisNode) does not have a route available for the > destination of the packet, ThisNode uses an RERR message is used to >=20 > UH> "uses".. ."is used" >=20 > inform one or more neighboring AODVv2 routers that its route to the > packet destination is no longer available. >=20 > When ThisNode creates a new RERR, the address of the first > UnreachableNode (IP.DestinationAddress from a data packet or > RREP.TargetNode.Address) is inserted into an Address Block > AddBlk.UnreachableNode.Address. If a prefix is known for the > UnreachableNode.Address, it SHOULD be included. Otherwise, the > UnreachableNode.Address is assumed to be a host address with a full > length prefix. If a value for the UnreachableNode's SeqNum > (UnreachableNode.AddTLV.SeqNum) is known, it SHOULD be placed in the > RERR. The MsgHdr.HopLimit SHOULD be set to MSG_HOPLIMIT. >=20 > If SeqNum information is not known or not included in the RERR, all > nodes handling the RERR will assume their routing information > associated with the UnreachableNode is no longer valid and flag those > routes as broken. >=20 > A RERR MAY be sent to the multicast address LL-MANET-Routers > [RFC5498], thus notifying all nearby AODVv2 routers that might depend > on the now broken link. If the RERR is unicast, the > IP.DestinationAddress is set to the PrevHopAddress. >=20 > After sending the RERR, ThisNode SHOULD discard the packet or message >=20 > UH> Why packet or message? Is this data traffic or control traffic? >=20 > that triggered generation of the RERR. >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 22] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 5.5.4. RERR Handling >=20 > First, ThisNode examines the incoming RERR to ensure that it contains > MsgHdr.HopLimit and AddBlk.UnreachableNode.Address. If the required > information does not exist, the incoming RERR message is discarded > and further processing stopped. >=20 > When an AODVv2 router handles a RERR, it examines the information for > each UnreachableNode. >=20 > UH> How exactly does it do that? Which information is used, and how? >=20 > The AODVv2 router removes the forwarding > route, unsets the Route.Forwarding flag, sets the Route.Broken flag, > and the timer for ROUTE_DELETE is set to ROUTE_DELETE_TIMEOUT for > each UnreachableNode.Address found using longest prefix matching that > meets all of the following conditions: >=20 > 1. The UnreachableNode.Address is a routable unicast address. >=20 > 2. The Route.NextHopAddress is the same as the RERR > IP.SourceAddress. >=20 > 3. The Route.NextHopInterface is the same as the interface on which > the RERR was received. >=20 > 4. The Route.SeqNum is zero (0), unknown, OR the > UnreachableNode.SeqNum is zero (0), unknown, OR Route.SeqNum - > UnreachableNode.SeqNum <=3D 0 (using signed 16-bit arithmetic). >=20 > If Route.SeqNum is zero (0) or unknown and UnreachableNode.SeqNum > exists in the RERR and is not zero (0), then Route.SeqNum SHOULD be > set to UnreachableNode.SeqNum. Setting Route.SeqNum can reduce > future RERR handling and forwarding. >=20 > UH> How? >=20 > Each UnreachableNode that did not result in marking a route table > entry as broken route is removed from the RERR, since propagation of > such information will not result in any benefit. >=20 > UH> Makes end-to-end security impossible. >=20 > Each UnreachableNode that did indicate a broken route SHOULD remain > in the RERR. >=20 > If any UnreachableNode was removed, all other information (AddTLVs) > associated with the UnreachableNode address(es) MUST also be removed. >=20 > If Route.SeqNum is known and an UnreachableNode.SeqNum is not > included in the RERR, then Route.SeqNum (i.e. > UnreachableNode.SeqNum) MAY be included with the RERR. Including > UnreachableNode.SeqNum can reduce future RERR handling and > forwarding. >=20 > If no UnreachableNode addresses remain in the RERR, or if the >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 23] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > MsgHdr.HopLimit is equal to one (1), then the RERR MUST be discarded. >=20 > Otherwise, the MsgHdr.HopLimit is decremented by one (1). The RERR > SHOULD be sent to the multicast address LL-MANET-Routers [RFC5498]. > Alternatively, if the RERR is unicast, the IP.DestinationAddress is > set to the PrevHopAddress. >=20 > 5.6. Unknown Message and TLV Types >=20 > If a message with an unknown type is received, the message is > ignored. >=20 > For handling of messages that contain unknown TLV types, ignore the > information for processing, preserve it unmodified for forwarding. >=20 > 5.7. Advertising Network Addresses >=20 > AODVv2 routers MAY specify a prefix length for each advertised > address. Any nodes (other than the advertising AODVv2 router) within > the advertised prefix MUST NOT participate in the AODVv2 protocol > directly. For example, advertising 192.0.2.1 with a prefix length of > 24 indicates that all nodes with the matching 192.0.2.X are reachable > through this AODVv2 router. An AODVv2 router MUST NOT advertise > network addresses unless it can guarantee its ability for forwarding > packets to any host address within the address range of the > corresponding network. >=20 > 5.8. Simple Internet Attachment >=20 > Simple Internet attachment consists of a stub (i.e., non-transit) > network of AODVv2 routers connected to the Internet via a single > Internet AODVv2 router (IAR). >=20 > UH> Why a new defition? Is that not just a border router? Also, it > does not matter if it's connected to the "Internet", just if it's a > border gateway with two interfaces, connecting two different routing > domains (which could still not be connected to the Internet). >=20 > As in any Internet-attached network, >=20 > UH> What's an Internet-attached network? Is that defined in an IP > architecture RFC? >=20 > AODVv2 routers, and hosts behind > these routers, wishing to be reachable from hosts on the Internet > MUST have IP addresses within the IAR's routable and topologically > correct prefix (e.g. 192.0.2.0/24). >=20 > The IAR is responsible for generating RREQ to find nodes within the > AODVv2 Region on behalf of nodes on the Internet, as well as > responding to route requests from the AODVv2 region on behalf of the > nodes on the Internet. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 24] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > /--------------------------\ > / Internet \ > \ / > \------------+-------------/ > | > Routable & | > Topologically | > Correct | > Prefix | > +-----+--------+ > | Internet | > /------| AODVv2 |-------\ > / | Router | \ > / |192.0.2.1/32 | \ > | |Responsible | | > | | for | | > | |AODVv2 Region | | > | |192.0.2.0/24 | | > | +--------------+ | > | +----------------+ | > | | AODVv2 Router | | > | | 192.0.2.2/32 | | > | +----------------+ | > | +----------------+ | > | | AODVv2 Router | | > | | 192.0.2.3/32 | | > \ +----------------+ / > \ / > \-----------------------------/ >=20 > Figure 1: Simple Internet Attachment Example >=20 > When an AODVv2 router within the AODVv2 Region wants to discover a > route to a node on the Internet, it uses the normal AODVv2 route > discovery for that IP Destination Address. The IAR MUST respond to > RREQ on behalf of the Internet destination. >=20 > UH> How? Where is that specified? >=20 > When a packet from a node on the Internet destined for a node in the > AODVv2 region reaches the IAR, if the IAR does not have a route to > that destination it will perform normal AODVv2 route discovery for > that destination. >=20 > UH> How? With which originator address, target etc? Where are RERRs / > ICMP unreachable sent to in case of a broken data traffic? >=20 > 5.9. Multiple Interfaces >=20 > AODVv2 may be used with multiple interfaces; therefore, the > particular interface over which packets arrive MUST be known whenever > a packet is received. Whenever a new route is created, the interface > through which the Route.Address can be reached is also recorded in >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 25] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > the route table entry. >=20 > When multiple interfaces are available, a node transmitting a > multicast packet with IP.DestinationAddress set to LL-MANET-Routers > SHOULD send the packet on all interfaces that have been configured > for AODVv2 operation. >=20 > Similarly, AODVv2 routers SHOULD subscribe to LL-MANET-Routers on all > their AODVv2 interfaces. >=20 > 5.10. AODVv2 Control Packet/Message Generation Limits >=20 > UH> There is no AODVv2 Control Packet. >=20 >=20 > To ensure predictable messaging overhead, AODVv2 router's rate of > packet/message generation SHOULD be limited. The rate and algorithm > for limiting messages (CONTROL_TRAFFIC_LIMITS) is left to the > implementor and should be administratively configurable. AODVv2 > messages SHOULD be discarded in the following order of preference: > RREQ, RREP, and finally RERR. >=20 > 5.11. Optional Features >=20 > Several optional features of AODVv2, and associated with AODV, are > not required by minimal implementations. These features are expected > to be useful in networks with greater mobility, or larger node > populations, or requiring shorter latency for application launches. > The optional features are as follows: >=20 > o Expanding Rings Multicast >=20 > o Intermediate RREPs (iRREPs): Without iRREP, only the destination > can respond to a RREQ. >=20 > o Precursor lists. >=20 > o Reporting Multiple Unreachable Nodes. An RERR message can carry > more than one Unreachable Destination node for cases when a single > link breakage causes multiple destinations to become unreachable > from an intermediate router. >=20 > UH> This seems to be different from section 5.11.6, which talks about > adding additional information to a RREQ. >=20 > UH> None of the extensions is sufficiently specified, and it is > unclear how it would affect interoperability if some nodes support the > extension and others don't. >=20 > 5.11.1. Expanding Rings Multicast >=20 > For multicast RREQ, the MsgHdr.HopLimit MAY be set in accordance with > an expanding ring search as described in [RFC3561] to limit the RREQ > propagation to a subset of the local network and possibly reduce > route discovery overhead. >=20 >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 26] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 5.11.2. Intermediate RREP >=20 > This specification has been published as a separate Internet Draft . >=20 > 5.11.3. Precursor Notification >=20 > The Dynamic MANET On-demand (AODVv2) routing protocol is intended for > use by mobile routers in wireless, multihop networks. AODVv2 > determines unicast routes among AODVv2 routers within the network in > an on-demand fashion, offering on-demand convergence in dynamic > topologies. This document specifies a simple modification to AODVv2 > (and possibly other reactive routing protocols) enabling faster > notifications to known sources of traffic upon determination that a > route for such traffic's destination has become Broken. >=20 > 5.11.3.1. Overview >=20 > If an AODVv2 router, while attempting to forward a packet to a > particular destination, determines that the next hop (one of its > neighbors) is no longer reachable, AODVv2 specifies that the router > notify the source of that packet that the route to the destination > has become Broken. In the existing specification, the notification > to the source is a unicast RERR message. >=20 > However, in many cases there will be several sources of of traffic > for that particular destination. In fact, the broken link for the > next hop in question may be a path component of numerous other routes > for other destinations, and in that case the node detecting the > broken link must mark as Broken multiple routes, one for each of the > newly unreachable destinations. Each route that uses the newly > broken link is no longer valid. For each such route, every node > along the way from the source using that route, to the node detecting > the broken link, is known as a "precursor" for the broken next hop. > All the precursors for a particular next hop should be notified about > the change in status of their route to a destination downstream from > the broken next hop. >=20 > 5.11.3.2. Precursor Notification >=20 > During normal operation, each node wishing to enable the improved > notification for precursors of any links to its next hop neighbors > has to keep track of the precursors. This is done by maintaining a > precursor table and updating the table whenever the node initiates or > relays a RREP message back to a node originating a RREQ message. > When the node transmits the RREP message, it is implicitly agreeing > to forward traffic from the RREQ originator towards the RREP > originator (i.e., along the next hop link to the neighbor from which > the RREP was received). The "other" next hop, which is the neighbor >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 27] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > along the way towards the originator of the RREQ message, is then the > next precursor for the route towards the destination requested by the > RREQ. >=20 > Each such precursor should then be recorded as a precursor for a > route along the next hop. The same next hop may be in service for > routes to multiple destinations, but for precursor list management it > is only important to keep track of precursors for a particular next > hop; the exact destination does not matter, only the particular next > hop towards the destination(s). >=20 > When a node observes that one of its neighbors is no longer > reachable, the node first checks to see whether the link to that > neighbor is a next hop for any more distant destination in its route > table. If not, then the node simply updates any relevant neighorhood > information and takes no further action. >=20 > Otherwise, for all destinations no longer reachable because of the > changed status of the next hop, the node first checks to see whether > the link to that neighbor is a next hop for any more distant > destination in its route table. If not, then the node simply updates > any relevant neighorhood information and takes no further action. >=20 > For each precursor of the next hop, the node MAY notify the precursor > in one of three ways: >=20 > o unicast RERR >=20 > o broadcast RERR >=20 > o multicast RERR to multicast group PRECURSOR_RERR_RECEIVERS >=20 > UH> I don't see an allocation request in the IANA section. >=20 >=20 > Each precursor then MAY execute the same procedure until all affected > traffic sources have received the RERR route maintenance information. >=20 > When a precursor receives a unicast RERR, the precursor MUST further > unicast the RERR message towards the affected traffic source. If a > precursor receives a broadcast or multicast RERR, the precursor MAY > further retransmit the RERR towards the traffic source. >=20 > 5.11.4. Reporting Multiple Unreachable Nodes >=20 > 5.11.5. Message Aggregation >=20 > The aggregation of multiple messages into a packet is not specified > in this document, but if aggregation does occur the IP.SourceAddress > and IP.DestinationAddress of all contained messages MUST be the same. >=20 > UH> That is part of the RFC5444 multiplexer and not of AODVv2. >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 28] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > Implementations MAY choose to temporarily delay transmission of > messages for the purpose of aggregation (into a single packet) or to > improve performance by using jitter [RFC5148]. >=20 > 5.11.6. Adding Additional Routing Information to a RteMsg >=20 > UH> This section is unclear to me. What is the purpose? What kind of > information would you add? How can this interoperate? By adding > information en-route, end-to-end security is not possible. >=20 > DSR [RFC4728] includes source routes as part of the data of its RREPs > and RREQs. Doign so allows additional topology information to be > flooded along with the RteMsg, and potentially allows updating for > stale routing information at MANET routers along new paths between > source and destination. To maintain this functionality, AODVv2 has > defined a somewhat more general method that enables inclusion of > source routes in RteMsgs. >=20 > Appending routing information can alleviate route discovery attempts > to the nodes whose information is included, if other AODVv2 routers > use this information to update their routing tables. >=20 > Note that, since the initial merger of DSR with AODV to create this > protocol, further experimentation has shown that including the > additional routing information is not always helpful. Sometimes it > seems to help, and other times it seems to reduct overall > performance. >=20 > AODVv2 routers can append routing information to a RteMsg. This is > controllable by an option (APPEND_INFORMATION) which SHOULD be > administratively configurable or controlled according to the traffic > characteristics of the network. >=20 > Prior to appending an address controlled by this AODVv2 router to a > RteMsg, ThisNode MAY increment its OwnSeqNum as defined in > Section 5.1. If OwnSeqNum is not incremented the appended routing > information might not be considered preferable, when received by > nodes with existing routing information. Incrementation of the > sequence number when appending information to a RteMsg in transit > (APPEND_INFORMATION_SEQNUM) SHOULD be administratively configurable. > Note that, during handling of this RteMsg OwnSeqNum may have already > been incremented; and in this case OwnSeqNum need not be incremented > again. >=20 > If an address controlled by this AODVv2 router includes > ThisNode.Dist, it is set to a number greater than zero (0). >=20 > For added addresses (and their prefixes) not controlled by this > AODVv2 router, Route.Dist can be included if known. >=20 > The VALIDITY_TIME of routing information for appended address(es) > MUST be included, to inform routers about when to delete this >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 29] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > information. The VALIDITY_TIME TLV is defined in Section 5.13.3. >=20 > Additional information (e.g. SeqNum and Dist) about any appended > address(es) SHOULD be included. >=20 > Note that the routing information about the TargetNode MUST NOT be > added. Also, duplicate address entries SHOULD NOT be added. > Instead, only the best routing information (Section 5.2.1) for a > particular address SHOULD be included. >=20 > Intermediate nodes obey the following procedures when processing > AddBlk.AdditionalNode.Address information and other associated TLVs > that are included with a RteMsg. For each address (except the > TargetNode) in the RteMsg that includes AddTLV.Dist information, the > AddTLV.Dist information MUST be incremented. If the resulting > Distance value for the OrigNode is greater than 254, the message is > discarded. If the resulting Distance value for another node is > greater than 254, the associated address and its information are > removed from the RteMsg. >=20 > After handling the OrigNode's routing information, then each address > that is not the TargetNode MAY be considered for creating and > updating routes. Creating and updating routes to other nodes can > eliminate RREQ for those IP destinations, in the event that data > needs to be forwarded to the IP destination(s) now or in the near > future. >=20 > For each of the additional addresses considered, ThisNode first > checks that the address is a routable unicast address. If the > address is not a unicast address, then the address and all related > information MUST be removed. >=20 > If the routing table does not have a matching route with a known > Route.SeqNum for this additional address using longest-prefix > matching, then a route MAY be created and updated as described in > Section 5.2.2. If a route table entry exists with a known > Route.SeqNum, the incoming routing information is compared with the > route table entry following the procedure described in Section 5.2.1. > If the incoming routing information is used, the route table entry > SHOULD be updated as described in Section 5.2.2. >=20 > If the routing information for an AdditionalNode.Address is not used, > then it is removed from the RteMsg. >=20 > 5.12. Administratively Configured Parameters and Timer Values >=20 > AODVv2 contains several parameters which MUST be administratively > configured. The list of these follows: >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 30] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > Required Administratively Configured Parameters >=20 > +------------------------+------------------------------------------+ > | Name | Description | > +------------------------+------------------------------------------+ > | RESPONSIBLE_ADDRESSES | List of addresses or routing prefixes, | > | | for which this AODVv2 router is | > | | responsible. If, RESPONSIBLE_ADDRESSES | > | | is zero, this AODVv2 router is only | > | | responsible for its own addresses. | > | AODVv2_INTERFACES | List of the interfaces participating in | > | | AODVv2 routing protocol. | > +------------------------+------------------------------------------+ >=20 > Table 2 >=20 > AODVv2 contains a number of timers. The default timing parameter > values follow: >=20 > Default Timing Parameter Values >=20 > +------------------------------+-------------------+ > | Name | Value | > +------------------------------+-------------------+ > | ROUTE_TIMEOUT | 5 seconds | > | ROUTE_AGE_MIN_TIMEOUT | 1 second | > | ROUTE_SEQNUM_AGE_MAX_TIMEOUT | 600 seconds | > | ROUTE_USED_TIMEOUT | ROUTE_TIMEOUT | > | ROUTE_DELETE_TIMEOUT | 2 * ROUTE_TIMEOUT | > | ROUTE_RREQ_WAIT_TIME | 2 seconds | > | UNICAST_MESSAGE_SENT_TIMEOUT | 1 second | >=20 > UH> UNICAST_MESSAGE_SENT_TIMEOUT is never used in this specification >=20 > +------------------------------+-------------------+ >=20 > Table 3 >=20 > The above timing parameter values work well for small and medium > well-connected networks with moderate topology changes. >=20 > UH> That also depends on the traffic patterns, on the lossy-ness of > the links, on the density of the routers etc. >=20 > The timing parameters SHOULD be administratively configurable for the > network where AODVv2 is used. Ideally, for networks with frequent > topology changes the AODVv2 parameters should be adjusted using > either experimentally determined values or dynamic adaptation. For > example, in networks with infrequent topology changes > ROUTE_USED_TIMEOUT may be set to a much larger value. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 31] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > Default Parameter Values >=20 > +------------------------+-------+----------------------------------+ > | Name | Value | Description | > +------------------------+-------+----------------------------------+ > | MSG_HOPLIMIT | 20 | This value MUST be larger than | > | | hops | the AODVv2 network diameter. | >=20 > UH> How would the network diameter be determined? >=20 > | | | Otherwise, routing messages may | > | | | not reach their intended | > | | | destinations. | > | DISCOVERY_ATTEMPTS_MAX | 3 | The number of route discovery | > | | | attempts to make before | > | | | indicating that a particular | > | | | address is not reachable. | > +------------------------+-------+----------------------------------+ >=20 > Table 4 >=20 > In addition to the above parameters and timing values, several > administrative options exist. These options have no influence on > correct routing behavior, although they may potentially reduce AODVv2 > protocol messaging in certain situations. The default behavior is to > NOT enable any of these options; and although many of these options > can be administratively controlled, they may be better served by > intelligent control. The following table enumerates several of the > options. >=20 > Administratively Controlled Options >=20 > +--------------------------+----------------------------------------+ > | Name | Description | > +--------------------------+----------------------------------------+ > | BUFFER_DURING_DISCOVERY | Whether and how much data to buffer | > | | during route discovery. | >=20 > UH> Whether and how much? Is it a boolean flag or a number? >=20 >=20 > | APPEND_EXTRA_UNREACHABLE | Whether to append additional | > | | Unreachable information to RERR. | > | CONTROL_TRAFFIC_LIMITS | AODVv2 messaging SHOULD be limited to | > | | avoid consuming all the network | > | | bandwidth. | >=20 > UH> What is the unit or the meaning of this? Bytes per second? >=20 > +--------------------------+----------------------------------------+ >=20 > Table 5 >=20 > Note: several fields have limited size (bits or bytes) these sizes > and their encoding may place specific limitations on the values that > can be set. For example, MsgHdr.HopLimit is a 8-bit field and > therefore MSG_HOPLIMIT cannot be larger than 255. >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 32] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 5.13. IANA Considerations >=20 > UH> This is not a valid IANA section. There are no requests for > registries or for TLV code points. There is no allocation policy. > Refer to RFC5526. >=20 >=20 > In its default mode of operation, AODVv2 uses the UDP port 269 > [RFC5498] to carry protocol packets. AODVv2 also uses the link-local > multicast address LL-MANET-Routers [RFC5498]. >=20 > This section specifies several message types, message tlv-types, and > address tlv-types. >=20 > 5.13.1. AODVv2 Message Types Specification >=20 > AODVv2 Message Types >=20 > +------------------------+----------+ > | Name | Type | > +------------------------+----------+ > | Route Request (RREQ) | 10 - TBD | > | Route Reply (RREP) | 11 - TBD | > | Route Error (RERR) | 12 - TBD | > +------------------------+----------+ >=20 > Table 6 >=20 > 5.13.2. Message and Address Block TLV Type Specification >=20 > Message TLV Types >=20 > +-------------------+------+--------+-------------------------------+ > | Name | Type | Length | Value | > +-------------------+------+--------+-------------------------------+ > | Unicast Response | 10 - | 0 | Indicates to the processing | > | Request | TBD | octets | node that the previous hop | > | | | | (IP.SourceAddress) expects a | > | | | | unicast reply message within | > | | | | UNICAST_MESSAGE_SENT_TIMEOUT. | > | | | | Any unicast packet will serve | > | | | | this purpose, and it MAY be | > | | | | an ICMP REPLY message. If | > | | | | the reply is not received, | > | | | | then the previous hop can | > | | | | assume that the link is | > | | | | unidirectional and MAY | > | | | | blacklist the link to this | > | | | | node. | > +-------------------+------+--------+-------------------------------+ >=20 > UH> It is never specified where and how to use this TLV? Is it a > message-specifid TLV? To which registry do you want to add it? What is > the allocation policy? What are the registered type extensions? >=20 > Table 7 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 33] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > 5.13.3. Address Block TLV Specification >=20 > Address Block TLV Types >=20 > +----------------+------------+----------+--------------------------+ > | Name | Type | Length | Value | > +----------------+------------+----------+--------------------------+ > | AODVv2 | 10 - TBD | up to 2 | The AODVv2 sequence num | > | Sequence | | octets | associated with this | > | Number | | | address. The sequence | > | (AODVv2SeqNum) | | | number may be the last | > | | | | known sequence number. | > | Distance | 11 - TBD | up to 2 | A metric of the distance | > | | | octets | traversed by the | > | | | | information associated | > | | | | with this address. | >=20 > UH> How is the distance formatted? >=20 > | VALIDITY_TIME | 1[RFC5497] | | The maximum amount of | > | | | | time that information | > | | | | can be maintained before | > | | | | being deleted. The | > | | | | VALIDITY_TIME TLV is | > | | | | defined in [RFC5497]. | > +----------------+------------+----------+--------------------------+ >=20 > Table 8 >=20 > 5.14. Security Considerations >=20 > UH> This will not suffice; see RFC3552 for guidelines how to write > security considerations. >=20 > UH> Notably, there is no mention of possible threats to AODVv2. Also, > there is some text to protect messages; but it is impossible to do so, > as messages are changed in transit. Also, since there is no way to > hook in security extensions (such as done in RFC6130) for rejecting > messages, there is currently no security possible for DYMO. >=20 >=20 > The objective of the AODVv2 protocol is for each router to > communicate reachability information to addresses for which it is > responsible. Positive routing information (i.e. a route exists) is > distributed via RteMsgs and negative routing information (i.e. a > route does not exist) via RERRs. AODVv2 routers that handle these > messages store the contained information to properly forward data > packets, and they generally provide this information to other AODVv2 > routers. >=20 > This section does not mandate any specific security measures. > Instead, this section describes various security considerations and > potential avenues to secure AODVv2 routing. >=20 > The most important security mechanisms for AODVv2 routing are > integrity/authentication and confidentiality. >=20 > In situations where routing information or router identity are > suspect, integrity and authentication techniques SHOULD be applied to > AODVv2 messages. >=20 > UH> How? Messages change in transit (addresses added or removed etc). >=20 > In these situations, routing information that is > distributed over multiple hops SHOULD also verify the integrity and >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 34] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > identity of information based on originator of the routing > information. >=20 > UH> How? >=20 > A digital signature could be used to identify the source of AODVv2 > messages and information, along with its authenticity. A nonce or > timestamp SHOULD also be used to protect against replay attacks. > S/MIME and OpenPGP are two authentication/integrity protocols that > could be adapted for this purpose. >=20 > In situations where confidentiality of AODVv2 messages is important, > cryptographic techniques can be applied. >=20 > In certain situations, for example sending a RREP or RERR, an AODVv2 > router could include proof that it has previously received valid > routing information to reach the destination, at one point of time in > the past. In situations where routers are suspected of transmitting > maliciously erroneous information, the original routing information > along with its security credentials SHOULD be included. >=20 > Note that if multicast is used, any confidentiality and integrity > algorithms used MUST permit multiple receivers to handle the message. >=20 > Routing protocols, however, are prime targets for impersonation > attacks. In networks where the node membership is not known, it is > difficult to determine the occurrence of impersonation attacks, and > security prevention techniques are difficult at best. However, when > the network membership is known and there is a danger of such > attacks, AODVv2 messages must be protected by the use of > authentication techniques, such as those involving generation of > unforgeable and cryptographically strong message digests or digital > signatures. While AODVv2 does not place restrictions on the > authentication mechanism used for this purpose, IPsec Authentication > Message (AH) is an appropriate choice for cases where the nodes share > an appropriate security association that enables the use of AH. >=20 > UH> That only works for a single hop, not end-to-end, as the IP > packets are not forwarded. >=20 > In particular, routing messages SHOULD be authenticated to avoid > creation of spurious routes to a destination. Otherwise, an attacker > could masquerade as that destination and maliciously deny service to > the destination and/or maliciously inspect and consume traffic > intended for delivery to the destination. RERR messages SHOULD be > authenticated in order to prevent malicious nodes from disrupting > active routes between communicating nodes. >=20 > If the mobile nodes in the ad hoc network have pre-established > security associations, the purposes for which the security > associations are created should include that of authorizing the > processing of AODVv2 control packets. Given this understanding, the > mobile nodes should be able to use the same authentication mechanisms >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 35] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > based on their IP addresses as they would have used otherwise. >=20 > 5.15. Acknowledgments >=20 > AODVv2 is a descendant of the design of previous MANET on-demand > protocols, especially AODV [RFC3561] and DSR [RFC4728]. Changes to > previous MANET on-demand protocols stem from research and > implementation experiences. Thanks to Elizabeth Belding-Royer for > her long time authorship of AODV. Additional thanks to Luke Klein- > Berndt, Pedro Ruiz, Fransisco Ros, Koojana Kuladinithi, Ramon > Caceres, Thomas Clausen, Christopher Dearlove, Seung Yi, Romain > Thouvenin, Tronje Krop, Henner Jakob, Alexandru Petrescu, Christoph > Sommer, Cong Yuan, Lars Kristensen, and Derek Atkins for reviewing of > AODVv2, as well as several specification suggestions. >=20 > This revision of AODVv2 isolates the minimal base specification and > other optional features to simplify the process of ensuring > compatibility with the existing LOADng specification > [I-D.clausen-lln-loadng] (minimal reactive routing protocol > specification). Thanks are due to T. Clausen, A. Colin de Verdiere, > J. Yi, A. Niktash, Y. Igarashi, Satoh. H., and U. Herberg for their > development of LOADng and sharing details for ensuring > appropriateness of AODVv2 for LLNs. >=20 >=20 > 6. References >=20 > 6.1. Normative References >=20 > [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", > RFC 1812, June 1995. >=20 > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. >=20 > [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. > Pignataro, "The Generalized TTL Security Mechanism > (GTSM)", RFC 5082, October 2007. >=20 > [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, > "Generalized Mobile Ad Hoc Network (MANET) Packet/Message > Format", RFC 5444, February 2009. >=20 > [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value > Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, > March 2009. >=20 > [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 36] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > (MANET) Protocols", RFC 5498, March 2009. >=20 > 6.2. Informative References >=20 > [I-D.clausen-lln-loadng] > Clausen, T., Verdiere, A., Yi, J., Niktash, A., Igarashi, > Y., Satoh, H., Herberg, U., Lavenu, C., Lys, T., and C. > Perkins, "The LLN On-demand Ad hoc Distance-vector Routing > Protocol - Next Generation (LOADng)", > draft-clausen-lln-loadng-05 (work in progress), July 2012. >=20 > [Perkins99] > Perkins, C. and E. Belding-Royer, "Ad hoc On-Demand > Distance Vector (AODV) Routing", Proceedings of the 2nd > IEEE Workshop on Mobile Computing Systems and > Applications, New Orleans, LA, pp. 90-100, February 1999. >=20 > [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. >=20 > [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking > (MANET): Routing Protocol Performance Issues and > Evaluation Considerations", RFC 2501, January 1999. >=20 > [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- > Demand Distance Vector (AODV) Routing", RFC 3561, > July 2003. >=20 > [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast > Addresses", RFC 4193, October 2005. >=20 > [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source > Routing Protocol (DSR) for Mobile Ad Hoc Networks for > IPv4", RFC 4728, February 2007. >=20 > [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, > "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, > September 2007. >=20 > [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter > Considerations in Mobile Ad Hoc Networks (MANETs)", > RFC 5148, February 2008. >=20 > [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF > for IPv6", RFC 5340, July 2008. >=20 > [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc > Network (MANET) Neighborhood Discovery Protocol (NHDP)", > RFC 6130, April 2011. >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 37] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- > Instance Extensions", RFC 6549, March 2012. >=20 > [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, > May 2012. >=20 >=20 > Appendix A. Changes since the Previous Version >=20 > o Internet-Facing AODVv2 router renamed to be IAR >=20 > o "Optional Features" section created to contain features not > required within base specification, including: >=20 > o >=20 > * Intermediate RREPs (iRREPs): Without iRREP, only the > destination can respond to a RREQ. >=20 > * Precursor lists. >=20 > * An RERR may reporting multiple unreachable nodes. >=20 > * Message Aggregation. >=20 > o Sequence number MUST (instead of SHOULD) be set to 1 after > rollover. >=20 > o ThisNode MUST (instead of SHOULD) only handle AODVv2 messages from > adjacent routers. >=20 > o Clarification that Additional Routing information in RteMsgs is > optional (MAY) to use. >=20 > o Clarification that if Additional Routing information in RteMsgs is > used, then the Route Table Entry SHOULD be updated using normal > procedures as described in Section 5.2.2. >=20 > o Clarification in Section 5.4 that nodes may be configured to > buffer zero packets. >=20 > o Clarification in Section 5.4 that buffered packets MUST be dropped > if route discovery fails. >=20 > o In Section 5.5.1, relax mandate for monitoring connectivity to > next-hop AODVv2 neighbors (from MUST to SHOULD), in order to allow > for minimal implementations >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 38] >=20 > Internet-Draft AODVv2 October 2012 >=20 >=20 > o Remove Route.Forwarding flag; identical to "NOT" Route.Broken. >=20 > o Routing Messages MUST be originated with the MsgHdr.HopLimit set > to MSG_HOPLIMIT. Previously, this was not mandated. >=20 > o Maximum hop count set to 254, with 255 reserved for "unknown". > Since the current draft only uses hop-count as distance, this is > also the current maximum distance. >=20 >=20 > Appendix B. Shifting Network Prefix Advertisement Between AODVv2 > Routers >=20 > Only one AODVv2 router within a routing region SHOULD be responsible > for a particular address at any time. If two AODVv2 routers > dynamically shift the advertisement of a network prefix, correct > AODVv2 routing behavior must be observed. The AODVv2 router adding > the new network prefix must wait for any existing routing information > about this network prefix to be purged from the network. Therefore, > it must wait at least ROUTER_SEQNUM_AGE_MAX_TIMEOUT after the > previous AODVv2 router for this address stopped advertising routing > information on its behalf. >=20 >=20 > Authors' Addresses >=20 > Charles E. Perkins > Futurewei Inc. > 2330 Central Expressway > Santa Clara, CA 95050 > USA >=20 > Phone: +1-408-330-5305 > Email: charliep@computer.org >=20 >=20 > Ian D Chakeres > CenGen > 9250 Bendix Road North > Columbia, Maryland 21045 > USA >=20 > Email: ian.chakeres@gmail.com > URI: http://www.ianchak.com/ >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Perkins & Chakeres Expires April 26, 2013 [Page 39] > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jblack.ietf@yahoo.com Sun Nov 4 17:56:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB88D21F8805 for ; Sun, 4 Nov 2012 17:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiUE8mcTt9kc for ; Sun, 4 Nov 2012 17:56:26 -0800 (PST) Received: from nm6-vm0.bullet.mail.bf1.yahoo.com (nm6-vm0.bullet.mail.bf1.yahoo.com [98.139.213.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFCF21F858E for ; Sun, 4 Nov 2012 17:56:26 -0800 (PST) Received: from [98.139.212.148] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2012 01:56:25 -0000 Received: from [98.139.212.198] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2012 01:56:25 -0000 Received: from [127.0.0.1] by omp1007.mail.bf1.yahoo.com with NNFMP; 05 Nov 2012 01:56:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 531687.84552.bm@omp1007.mail.bf1.yahoo.com Received: (qmail 64323 invoked by uid 60001); 5 Nov 2012 01:56:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352080585; bh=++zD/8L8fZQlq0XChzeWEHtBkr6AEac0KGVAcY2IzfI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=5ckVAkaD/vgbflzufKfQMuJWMSwrCIcQLl7Ecc7jwEMUqEAjCcy85WZp/wEIxPCJ1Jxp0n7G06H0MZtWrtTE5Px2DmOeU9psbnYTxcAX3X42NpWZN+ozkVJps14uMhnCPe4YUoaZpDqrpFPoaiNWDLoR2vYVuDXd/nzHfDS5g7Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VN9jyqUd/9nBqJEdVrC+W0XPuJd1ZucAUA0LoFbG3ahzQu9gLaznZL1Zl2wsqLGxnpvru12yax6U2eEwN4bJ1aQIbjXLvW0iQVOERIdYMvTStzgAFBthqmqMTbOukN8AU2tO5ZTFnGWtZ8WdsEaGGmXV31E4dHq01QgenC7BCME=; X-YMail-OSG: E2sqlb4VM1mKBI5Mn2BHy_vA.JoqusUTN3drOEgnmi_1E2G GZzi1TAHU_9etIfX1NbNhBNWejroYGstDsLeNMvnMnxeW4D0VADQvKgBmHbZ x.kcMO3UKY8fp6xZAfFeyeoaEPzC2o_hoY7eFILtWtJm78a7q8R12kzicQkT 30brX0ebDx5i75b6TtWUwXON5oFI_fK2zGDWvE.16vn6B2u.EYKs4AuVAVOW imLwysLC.t6xTEV8FTkrOE_oQpYfDUgBrWkJtCPaTC.oG3fSX3G15eSAZFAC _OAD8LlFcodep.edgnEOEXPXeL.2iQwE7Ia5CarO_lgUfwN6oZZmPza1bVoJ DmN1xtWyAUwYhcxjb0LJLg2luoYtydC66ZwBodWJbXuvmY7r85Og67AdWMpe ZkxAcnCVU9BSCDvJ84PlGttm9Ul3BEcSJBVbs6LOpRACN41WBO_YtkrSUXy_ 0bSOCzA-- Received: from [67.213.218.74] by web160602.mail.bf1.yahoo.com via HTTP; Sun, 04 Nov 2012 17:56:25 PST X-Rocket-MIMEInfo: 001.001, SXQgTE9BRG5nIGRvZXMgbm90IGZpdCBNQU5FVCdzIGFwcGxpY2FiaWxpdGllcyB0aGVuIERZTU8gY2FuJ3QgYW5kIHdlIGFyZSBhdCAjMy7CoCBUaGV5IGFyZSBib3RoIG1vZGlmaWNhdGlvbnMgdG8gQU9EViwgc28gZWl0aGVyIHRoZXkgYm90aCBhcmUgYXBwbGljYWJsZSB0byBNQU5FVHMgb3Igbm9uZSBvZiB0aGUgdGhyZWUgKGluY2x1ZGluZyBBT0RWKSBhcmUuCgpKb27CoCAKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBEYW5pZWwgSGUgPGRyZGFuaGVAZ21haWwuY29tPgoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> Message-ID: <1352080585.31689.YahooMailNeo@web160602.mail.bf1.yahoo.com> Date: Sun, 4 Nov 2012 17:56:25 -0800 (PST) From: Jon Black To: Daniel He , Abdussalam Baryun In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1725615817-1469148456-1352080585=:31689" Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 01:56:27 -0000 ---1725615817-1469148456-1352080585=:31689 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable It LOADng does not fit MANET's applicabilities then DYMO can't and we are a= t #3.=A0 They are both modifications to AODV, so either they both are appli= cable to MANETs or none of the three (including AODV) are.=0A=0AJon=A0 =0A= =0A=0A=0A=0A________________________________=0A From: Daniel He =0ATo: Abdussalam Baryun =0ACc: Timoth= y J. Salo ; "manet@ietf.org" =0ASent: Su= nday, November 4, 2012 6:35 AM=0ASubject: Re: [manet] LOADng works=0A =0A= =0A=0A=0AI still don't beleive that LOADng deployments fit MANETs'=0A>appli= cabilities. Therefore, disagree with the subject claimed (i.e.=0A>LOADng wo= rks).=0A>=0A>=0AI totally disagree!=A0 LOADng is fitting to MANET. fundamen= tally =0Ait is lightweighted AODV.=0A=0A=0A________________________________= _______________=0Amanet mailing list=0Amanet@ietf.org=0Ahttps://www.ietf.or= g/mailman/listinfo/manet ---1725615817-1469148456-1352080585=:31689 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
It LOADng does not fi= t MANET's applicabilities then DYMO can't and we are at #3.  They are = both modifications to AODV, so either they both are applicable to MANETs or= none of the three (including AODV) are.

Jon 

<= font face=3D"Arial" size=3D"2">
From: Daniel He <drdanhe@gmail.com>
To: Abdussalam Baryun <abdussa= lambaryun@gmail.com>
Cc: Timothy J. Salo <salo@saloits.com>; "manet@ietf.org" <manet@= ietf.org>
Sent: Sunday, Novemb= er 4, 2012 6:35 AM
Subject: Re: [manet] LOADng works

=0A

<= div class=3D"yiv1687367347gmail_quote">
=0AI still don't beleive that LOADng deployments fit MANETs'
= =0Aapplicabilities. Therefore, disagree with the subject claimed (i.e.
= =0ALOADng works).
=0A
I totally disagree!  LOA= Dng is fitting to MANET. fundamentally
it is lightweighted AODV.
=0A

_______________________________________________
manet mailin= g list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
=

---1725615817-1469148456-1352080585=:31689-- From jblack.ietf@yahoo.com Sun Nov 4 17:57:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D09C21F8844 for ; Sun, 4 Nov 2012 17:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obW09Ll0R1iz for ; Sun, 4 Nov 2012 17:57:35 -0800 (PST) Received: from nm34-vm6.bullet.mail.bf1.yahoo.com (nm34-vm6.bullet.mail.bf1.yahoo.com [72.30.239.78]) by ietfa.amsl.com (Postfix) with ESMTP id 96B6C21F8843 for ; Sun, 4 Nov 2012 17:57:35 -0800 (PST) Received: from [98.139.212.145] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2012 01:57:34 -0000 Received: from [98.139.212.235] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2012 01:57:34 -0000 Received: from [127.0.0.1] by omp1044.mail.bf1.yahoo.com with NNFMP; 05 Nov 2012 01:57:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 743321.41485.bm@omp1044.mail.bf1.yahoo.com Received: (qmail 65207 invoked by uid 60001); 5 Nov 2012 01:57:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352080654; bh=RkH3CkovOJoObG1JtozJlUq/bnp94RzPF7mw37QB++U=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kTPu64Nj1lUX/EzoPbm4XTujXd6ZCJdK+PfYfXsK2ZBD6k2q2H02GBwNZcZYNDFr5sCjBJ6dwgGBnbwTGS2dGovQhRxxwQRHtX2bNspT+3ThYzyGf3974WgL+7CjJr/csvFAMKFBQPTbQGgSnpOs7vueZeKJvNSXB6/Sxj1KVFA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hpIeD8bUI2E7C4PXhb97qNVJBUrls0TckHFLg+Y57ofSAmlS+8EVDplkrcQ1XlkU9jB3XEtt/bBIfSYLu9tgFDIZjt7AH+J2ipC51chf/k1228p5nT6f1jSacq4b+SeogvQqBZBqVZ3VVQ8FrHHQCtjabU2qB1PkQcYG3CChCmM=; X-YMail-OSG: bZHWxNAVM1nsHqH29dAVOUo8EZQVbD3_cblQ0ImlrvpmlT. lPbP23srY8D87k67eQH1ygk6DR1qMwOPilUpRXsW77KxDmYPDRbIPW34CUgQ A7_ekcfutgQUMW22o4oeS13Zzy4ixPA1KTLZ8ihUQKbConc3k2dInpz4Fk6b LLxkUAT0DVVPZiWyXGy3YvgtmOaO4Y0Vcf63w.nwNpQtNaLPyURnqUOemCGV rqZxyxbuRwjSMNXQOnBOL3AGnBNK_I4w33dGbXC7vwW1i8tEDp0V0_5anNFa Q.m2TdeuGBJNzrC26zXbAxVwcFK8mbHJRD3B9leLHfmcZdoM5GqB4AGW58FY biHjrv9YX63v23oFLmOYDDugdX8yInVHvb14m5tvp2qT1ybdeh9pgqzn.5UV w_Om0Tri1hc3qMpfx.YKVQEK597FF9j6Djvzw_P5d3M7G4YxKrAMX6QrMrMz W0KTS7g-- Received: from [67.213.218.74] by web160602.mail.bf1.yahoo.com via HTTP; Sun, 04 Nov 2012 17:57:34 PST X-Rocket-MIMEInfo: 001.001, V293IGFyZSB3ZSByZWFsbHkgdXAgdG8gdmVyc2lvbiAyMC7CoCBJIG1pc3NlZCAyIHRocm91Z2ggMTk_CgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogSlAgVmFzc2V1ciAoanZhc3NldXIpIDxqdmFzc2V1ckBjaXNjby5jb20.ClRvOiBEYW5pZWwgSGUgPGRyZGFuaGVAZ21haWwuY29tPiAKQ2M6IFRpbW90aHkgSi4gU2FsbyA8c2Fsb0BzYWxvaXRzLmNvbT47ICJtYW5ldEBpZXRmLm9yZyIgPG1hbmV0QGlldGYub3JnPiAKU2VudDogU3VuZGF5LCBOb3ZlbWJlciA0LCAyMDEyIDcBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772205284E@xmb-rcd-x02.cisco.com> Message-ID: <1352080654.23894.YahooMailNeo@web160602.mail.bf1.yahoo.com> Date: Sun, 4 Nov 2012 17:57:34 -0800 (PST) From: Jon Black To: "JP Vasseur \(jvasseur\)" , Daniel He In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772205284E@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1725615817-790766510-1352080654=:23894" Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 01:57:36 -0000 ---1725615817-790766510-1352080654=:23894 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Wow are we really up to version 20.=A0 I missed 2 through 19?=0A=0A=0A=0A= =0A________________________________=0A From: JP Vasseur (jvasseur) =0ATo: Daniel He =0ACc: Timothy J. Salo ; "manet@ietf.org" =0ASent: Sunday, Novembe= r 4, 2012 7:16 AM=0ASubject: Re: [manet] LOADng works=0A =0A=0A=0A=0AOn Nov= 4, 2012, at 8:35 AM, Daniel He wrote:=0A=0A=0A>=0A>I still don't beleive t= hat LOADng deployments fit MANETs'=0A>>applicabilities. Therefore, disagree= with the subject claimed (i.e.=0A>>LOADng works).=0A>>=0A>>=0A>I totally d= isagree!=A0 LOADng is fitting to MANET. fundamentally =0A>it is lightweight= ed AODV.=0A>=0A=0AHere is my take on this; *if* there is a choice for optio= n 1, 2 or may be a brand new document related to=0Areactive routing in MANE= T (protocol called AODVv20, and excluding LLNs, then I think that we do not= =A0=0Ahave any issue.=0A=0A=0A>=0A_________________________________________= ______=0A>manet mailing list=0A>manet@ietf.org=0A>https://www.ietf.org/mail= man/listinfo/manet=0A>=0A=0A_______________________________________________= =0Amanet mailing list=0Amanet@ietf.org=0Ahttps://www.ietf.org/mailman/listi= nfo/manet ---1725615817-790766510-1352080654=:23894 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Wow are we really up = to version 20.  I missed 2 through 19?

=

From= : JP Vasseur (jvasseur) <jvasseur@cisco.com>
To: Daniel He <drdanhe@gmail.com= >
Cc: Timothy J. Sa= lo <salo@saloits.com>; "manet@ietf.org" <manet@ietf.org>
<= b>Sent: Sunday, November 4, 2= 012 7:16 AM
Subject: R= e: [manet] LOADng works

=0A
=0A=0A =0A=0A
=0A
=0A=0A
On Nov 4, 2012, at 8:35 AM, Daniel He wrote:
=0A
=0A

= =0A
=0A
=0AI still don't beleive that LOADng deployments fit MANETs= '
=0Aapplicabilities. Therefore, disagree with the subject claimed (i.e.=
=0ALOADng works).
=0A
=0A
=0A
I totally disagree!=   LOADng is fitting to MANET. fundamentally
=0Ait is lightweighted= AODV.
=0A
=0A
=0A
=0A

=0A
=0A
He= re is my take on this; *if* there is a choice for option 1, 2 or may be a b= rand new document related to
=0A
reactive routing in MANET (protoc= ol called AODVv20, and excluding LLNs, then I think that we do not =0A
have any issue.
=0A
=0A
=0A=0A

=0A
=0A
=0A______= _________________________________________
=0Amanet mailing list
=0Amanet@ietf.org
=0Ahttps://www.ietf.org/ma= ilman/listinfo/manet
=0A=0A
=0A
=0A
=0A=0A
__________= _____________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


---1725615817-790766510-1352080654=:23894-- From jblack.ietf@yahoo.com Sun Nov 4 18:00:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503F121F8853 for ; Sun, 4 Nov 2012 18:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVj2fo5iScAm for ; Sun, 4 Nov 2012 18:00:39 -0800 (PST) Received: from nm32-vm1.bullet.mail.bf1.yahoo.com (nm32-vm1.bullet.mail.bf1.yahoo.com [72.30.239.137]) by ietfa.amsl.com (Postfix) with ESMTP id 599C821F87A1 for ; Sun, 4 Nov 2012 18:00:39 -0800 (PST) Received: from [98.139.212.146] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2012 02:00:38 -0000 Received: from [98.139.212.225] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2012 02:00:38 -0000 Received: from [127.0.0.1] by omp1034.mail.bf1.yahoo.com with NNFMP; 05 Nov 2012 02:00:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 733735.9580.bm@omp1034.mail.bf1.yahoo.com Received: (qmail 17272 invoked by uid 60001); 5 Nov 2012 02:00:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352080838; bh=+ZA0SEkCYfanfWfTKquEOJdbSpWT56cIAulZPxvkJeM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=39lAyRGvso763Xuy+W9NSgJeR5vMMArgZ2TmCWn8WkwWW6pMH9ldZvPs6fuSrm5o4YCPJ6GE10jJrW5DgDTrfYEhJ7a4Yk6riv1yc3VmxAQYno5voac4+i0S6wafnS58GKzcF7SnyR6oRXb6FW0BJQpM2+uNJonvZZW8BY0P3VQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kAHOY5msxlJN/2RKoTNfbTQ/UWO8jM/k6H9TwVF1fqe1xgnQFmKgyf3HSAGRgEYbjmLdhqMAPewmC2U8YT2UxOv3X1u23ZR+HzDSfBZCDnyV1k4OG05/R6xOk3YyKZKSWlwj9ACHcrhXiCJPcJGi9LnSm1jE5699E30e4lIdsMA=; X-YMail-OSG: ASwHi0YVM1lzYAxsqqRaxPG01QWsjdCthqQGlvHKUhsiugP PzjVJW1FOxPHjt8WrLypIScdGAbdajHsVHRO5shsoFLohhUvwD.b1MhVUKe4 IjgVVNeQGnnzSBkngSoWL_9PYKYqZY4v0uIsn3Kq5dFrTNr2UciNLHvYMBXL ajUcUJSB0LN1I4dtBXl7qu6gMDlJ9XeLanCM7mC93.koQsQu5Bz_.9bBb4dr Irk9uQqnTy5PAN_0ybTYEGURkT3a_YhycRcZZNUlqzp0bAx40Br0czoWVpDk gwnlGrGqnOMuKcw5HsO1i3j5t7vJhaPSeQKXWQTJ8feGWWkuVSIb0TrBNJ58 0LQ95WfU3cc5doxnXSQEI3tk21R79AvbTCu17xh7ssYmjElUD1ZZrGEPktYg 4tSIRoXC5wLmk61Px.TgNZtQcSgXfyhBbIAzictgJh4shWkU9PLAV454To8P oW8LyZi4- Received: from [67.213.218.74] by web160606.mail.bf1.yahoo.com via HTTP; Sun, 04 Nov 2012 18:00:38 PST X-Rocket-MIMEInfo: 001.001, VGhpcyBub3Qgbm90IHdoYXQgSlAgaXMgcmVxdWlyaW5nLsKgIEhlIGlzIG5vdCBzYXlpbmcgdGhhdCB0aGUgZG9jdW1lbnQgc2hvdWxkIG5vdCBtZW50aW9uIExMTnMsIGJ1dCBpbnN0ZWFkIGl0IHdvdWxkIGV4cGxpY2l0bHkgIml0IHNob3VsZCBub3QgYmUgdXNlIGluIExMTnMiLsKgIFRoaXMgaXMgc29tZXRoaW5nIHF1aXRlIGRpZmZlcmVudCBhbmQgdGVjaG5pY2FsbHkgYW5kIGludGVsbGVjdHVhbGx5IGRpc2hvbmVzdCwgYnV0IGFnYWluIEpQIGhhcyBoaWphY2tlZCB0aGUgY29udmVyc2F0aW9uLgoKSm8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772205284E@xmb-rcd-x02.cisco.com> Message-ID: <1352080838.3583.YahooMailNeo@web160606.mail.bf1.yahoo.com> Date: Sun, 4 Nov 2012 18:00:38 -0800 (PST) From: Jon Black To: Daniel He , "JP Vasseur \(jvasseur\)" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1874956439-1315087557-1352080838=:3583" Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 02:00:40 -0000 --1874956439-1315087557-1352080838=:3583 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable This not not what JP is requiring.=A0 He is not saying that the document sh= ould not mention LLNs, but instead it would explicitly "it should not be us= e in LLNs".=A0 This is something quite different and technically and intell= ectually dishonest, but again JP has hijacked the conversation.=0A=0AJon=A0= =0A=0A=0A=0A=0A________________________________=0A From: Daniel He =0ATo: JP Vasseur (jvasseur) =0ACc: Timoth= y J. Salo ; "manet@ietf.org" =0ASent: Su= nday, November 4, 2012 7:58 AM=0ASubject: Re: [manet] LOADng works=0A =0A= =0AI think it is fair enought to replace the name. and I knew you don't lik= e LLN=0Aat all. and I agree to LLN taken out of the context is reasonable a= nd generized.=0A=0ACheers,=0ADan=0A=0A=0AOn 4 November 2012 14:16, JP Vasse= ur (jvasseur) wrote:=0A=0A=0A>=0A>On Nov 4, 2012, at 8= :35 AM, Daniel He wrote:=0A>=0A>=0A>>=0A>>I still don't beleive that LOADng= deployments fit MANETs'=0A>>>applicabilities. Therefore, disagree with the= subject claimed (i.e.=0A>>>LOADng works).=0A>>>=0A>>>=0A>>I totally disagr= ee!=A0 LOADng is fitting to MANET. fundamentally =0A>>it is lightweighted A= ODV.=0A>>=0A>=0A>=0A>Here is my take on this; *if* there is a choice for op= tion 1, 2 or may be a brand new document related to=0A>reactive routing in = MANET (protocol called AODVv20, and excluding LLNs, then I think that we do= not=A0=0A>have any issue.=0A>=0A>=0A>=0A>>=0A_____________________________= __________________=0A>>manet mailing list=0A>>manet@ietf.org=0A>>https://ww= w.ietf.org/mailman/listinfo/manet=0A>>=0A>=0A=0A=0A-- =0ADan He=0A---------= ------------=0ATel: +44-788-686-3428=0A=0A=0A______________________________= _________________=0Amanet mailing list=0Amanet@ietf.org=0Ahttps://www.ietf.= org/mailman/listinfo/manet --1874956439-1315087557-1352080838=:3583 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
This not not what JP = is requiring.  He is not saying that the document should not mention L= LNs, but instead it would explicitly "it should not be use in LLNs".  = This is something quite different and technically and intellectually dishon= est, but again JP has hijacked the conversation.

Jon 
=

From: Daniel He <drdanhe@gmail.com>
= To: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
Cc: Timothy J. Salo <salo@saloits.com>; "manet@ietf.org" <manet@ietf.= org>
Sent: Sunday,= November 4, 2012 7:58 AM
Subject= : Re: [manet] LOADng works

=0A
= I think it is fair enought to replace the name. and I knew you don't like L= LN
at all. and I agree to LLN taken out of the context is reasonable and= generized.

Cheers,
Dan

On 4 November 2012 14:16, JP Vasseur (jvasseur) <= ;jvasseur@cisco.com> wrot= e:
=0A
=0A=0A=0A=0A
=0A
=0A
=0A
On Nov 4, 2012, at 8:35 AM, Daniel He wrote:
=0A
=0A
=0A
=0A=0AI still don't beleive that LO= ADng deployments fit MANETs'
=0Aapplicabilities. Therefore, disagree wit= h the subject claimed (i.e.
=0ALOADng works).
=0A
=0A
= =0A
I totally disagree!  LOADng is fitting to MANET. fundamentally=
=0Ait is lightweighted AODV.
=0A
=0A
=0A=0A<= div>
=0A
=0A
Here is my take on this; *if* there is= a choice for option 1, 2 or may be a brand new document related to
= =0A
reactive routing in MANET (protocol called AODVv20, and excluding L= LNs, then I think that we do not 
=0A
have any issue.
=0A
=0A
=0A
=0A

=0A
=0A
=0A_________= ______________________________________
=0Amanet mailing list
=0Amanet@ietf.org
=0Ahttps://ww= w.ietf.org/mailman/listinfo/manet
=0A
=0A
=0A=
=0A=0A=0A


--
Dan = He
---------------------
Tel: +44-788-686-3428

=0A
__________________= _____________________________
manet mailing list
manet@ietf.org
https:= //www.ietf.org/mailman/listinfo/manet


= --1874956439-1315087557-1352080838=:3583-- From jblack.ietf@yahoo.com Sun Nov 4 18:05:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C6721F8843 for ; Sun, 4 Nov 2012 18:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asLX5SCBW7i6 for ; Sun, 4 Nov 2012 18:05:54 -0800 (PST) Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) by ietfa.amsl.com (Postfix) with ESMTP id 951FE21F86C6 for ; Sun, 4 Nov 2012 18:05:53 -0800 (PST) Received: from [98.139.215.143] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2012 02:05:51 -0000 Received: from [98.139.212.197] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2012 02:05:51 -0000 Received: from [127.0.0.1] by omp1006.mail.bf1.yahoo.com with NNFMP; 05 Nov 2012 02:05:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 853122.60959.bm@omp1006.mail.bf1.yahoo.com Received: (qmail 24953 invoked by uid 60001); 5 Nov 2012 02:05:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352081151; bh=ZS4KHBvlxOH8eGvK1qHOUTjExEJVBJHu522FDNOZVhM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VncS0vl7ED5TNFSSRPxD+AHICWisSbP26g3jBJ8vSaI27A58RoEKDZwAiNvXTLt706ETEgVSOOGAHPdlCP2TZ7QJ38Hshooid1kJoH/q/X+lWoprTK5peAHxry5rw4VnNKJMf9DuyxoIzXtkagSXHomEOihYD8tg6QEmDemSEO8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HcEcSGIx6hdSHz9XEBZ07gpOl6odVaPZq0zbOKB1LN9WOaEy9LnQLj2FBq7P9QHlVvzQ81sY/iAHmrP0w12DqA9ZDN0Yu13ZapsjQQqYDLQ1wJWBp2ql3S3DNFU96wSwu9wHQaXjlt3VftP3N5rg92HO01yY1PO4QxF1sg9LwIY=; X-YMail-OSG: CZE4a8oVM1lM9tyHOZEvcmfZkRsapUzlLOf6DbOGL9Q1znk zPMmIOeStAr2UptY0tWg8HTfeoyJ.dCA42fWSrNcirQmXpSBRxBRywWnv7jL rpvnhEIbM39i6hez1oWcVBU8JjYPv_kmmZCFR_q31AekObTMapcLBAAODuQQ z8Q6qjeEeOP_4bxGuRgbGaKuEvrUW5bYKsepMsD7qf_x2.Vuenl9RnK9xoT9 nuzZP1SFDYzOh80PwR_3K8HSXUpha8RwcmdCEwwUsuOhluP.BG0HKt8WEXY0 8zZ_gg3SR2kNvsonJrhwbFISEoTCuLO3PWR1ivnbeF7KeCTC27vCbMcSIYZO AhIALGY_NclJ4709l6imY0qN5u3kCvIzkhresTtMejHvqpBq.Hg1J5px6s6R ONYNQ8dhI9zDisKeeO8ZGpG.ngGI.l4EPBI3LvUefkt3UMKsoOnTsfj5M.QR 38M9pOg-- Received: from [67.213.218.74] by web160606.mail.bf1.yahoo.com via HTTP; Sun, 04 Nov 2012 18:05:51 PST X-Rocket-MIMEInfo: 001.001, SlAsIG9uY2UgYWdhaW4geW91IGFyZSBkaXN0cmFjdGluZyB1cyBmcm9tIHRoZSB0b3BpY3MgdGhhdCBuZWVkcyB0byBiZSBkaXNjdXNzZWQuwqAgVGhpcyBpcyBub3QgYW5kIHNob3VsZCBub3QgYmUgYSBkZWJhdGUgb24gaWYgb3IgaWYgbm90IExMTnMgY2FuIHVzZSBhIHJlYWN0aXZlIHByb3RvY29sLgoKSXQgXElTLyBhIGRpc2N1c3Npb24gYWJvdXQgd2hpY2ggb2YgdGhlIHR3byBkb2N1bWVudHMgaXMgaW4gdGhlIGJlc3Qgc2hhcGUgZm9yIHRoaXMgd29ya2luZyBncm91cCB0byBtb3ZlIGZvcndhcmQgdG8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <03B78081B371D44390ED6E7BADBB4A7722052EFE@xmb-rcd-x02.cisco.com> Message-ID: <1352081151.19662.YahooMailNeo@web160606.mail.bf1.yahoo.com> Date: Sun, 4 Nov 2012 18:05:51 -0800 (PST) From: Jon Black To: "JP Vasseur \(jvasseur\)" , Ulrich Herberg In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722052EFE@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1874956439-657364848-1352081151=:19662" Cc: "" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 02:05:57 -0000 --1874956439-657364848-1352081151=:19662 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable JP, once again you are distracting us from the topics that needs to be disc= ussed.=A0 This is not and should not be a debate on if or if not LLNs can u= se a reactive protocol.=0A=0AIt \IS/ a discussion about which of the two do= cuments is in the best shape for this working group to move forward to comp= lete our charter item of producing a reactive routing protocol for MANETs.= =0A=0AWe know you think that RPL has the exclusive rights to routing in LLN= s.=A0 We got it.=0A=0ACan we please move to the necessary discussion.=A0 If= you have some specific items in the comparison between the DYMO draft and = the LOADng draft, please bring them up.=A0 You have not yet.=A0 Have you re= ad both drafts?=0A=0AJon=0A=0A=0A=0A=0A________________________________=0A = From: JP Vasseur (jvasseur) =0ATo: Ulrich Herberg =0ACc: "" =0ASent: Sunday= , November 4, 2012 6:38 PM=0ASubject: Re: [manet] Reactive Protocol Situati= on=0A =0A=0AHi, =0A=0A=0AOn Nov 1, 2012, at 9:39 PM, Ulrich Herberg wrote:= =0A=0AHi Joydeep,=0A>=0A>=0A>On Thu, Nov 1, 2012 at 5:58 PM, Joydeep Tripat= hi wrote:=0A>=0A>Hi Joe and MANET WG, =0A>>=0A>>=0A>>I w= as following the discussion on which route to take for a reactive protocol = standard very closely, and I think I should post my opinion also. I champio= n for Option 1, and here is why :=A0=0A>>=0A>>=0A>>I have read both AODVv2 = (DYMO) and LOAD-ng drafts, and I have simulated LOAD-ng myself as well. Thi= s experience, I believe, puts me in a position to form an opinion comparing= these two protocols. =0A>=0A>=0A>That is valuable. Have you also implement= ed DYMO and compared it to LOADng?=0A>=0A>=0A>=A0=0A>I certainly agree, opt= ion 3 is *not* an option I would like to be chosen. Reactive protocols, tho= ugh very much unsuitable for LLNs and Smart Grid AMI meter networks, =0A>= =0A>=0A>I differ on that, and so do some of the LOADng authors that work in= that area. But that's not the point of the discussion here.=0A>=0A>=0A>=A0= =0A>may have some usefulness in certain networks for certain sparse traffic= scenario, and the WG should have a standard for the same.=0A>=0A>=0A>I agr= ee.=0A>=A0=0A>=0A>>=0A>>Firstly, LOAD-ng is backed up by the argument that = it has implementations and interop documents. However, I have seen in the m= ailing list, that certain question on details of the 'practical' implementa= tion of LOAD-ng has been avoided. =0A>=0A>=0A>I don't see how. There was a = description of the deployment and about the suitability for LOADng in that.= Note that for DYMO, there is no such deployment (to my knowledge), which i= s why I think your conclusion for option 1 instead of option 3 is surprisin= g to me.=0A>=0A>=0A>=A0=0A>A reactive protocol may do well in a 2000 nodes = smart meter network, if the data traffic to the base station or collector i= s 1-2 times a day. This kind of implementations, in my opinion, say nothing= about usefulness of LOAD-ng in Smart Grid networks or LLNs. =0A>=0A>=0A>It= is well known (and also spelled out in DYMO), that reactive protocols are = more suitable for sparse traffic scenarios with few concurrent communicatio= n streams. That is well-known and understood in MANET, and a reasons to wor= k on a proactive protocol as well. Reactive protocols have their limitation= s, but in certain MANET use cases are useful, which is why we are chartered= to work on a reactive protocol.=0A=0AJP> We all agree, with a a non subtle= nuance. I never said that reactive routing was a bad idea. These protocol = are very useful.=0AThey are just ill-suited to LLNs. If you design a protoc= ol X in MANET and explicitly mention that it would not be applicable to LLN= s,=0Athen I would personally be fine. Now if you claim that a protocol such= as Load could work in specify lightweight traffic use cases,=A0=0Athen can= you explain why existing LLN routing protocol do not work ? The idea is to= avoid having two protocols if one is sufficient=0A(once again for LLNs).= =A0=0A=0A=A0=0A>Again, whether LLN may be considered as a subset of MANET o= r not is a different question. But even then, deployed LOAD-ng in a 2000 no= de network may (and in my opinion, will) fail if traffic is increased.=0A>= =0A>=0A>That is possible. Both in DYMO and LOADng.=0A>=A0=0A>Agreed, one si= ze does not fit all. However, once we have multicast traffic in a smart gri= d or multiple meters generating alert packets in a region at the same time,= a reactive protocol like LOAD-ng will lead to the break-down of the networ= k. Anyone can say multicast traffic or several meters reporting emergency a= t the same time to the same station, is a very much likely situation in sma= rt grid. Were these situations considered during deployment? Please note, I= am NOT saying that=A0AODVv2 / DYMO will be better in this case than LOAD-n= g.=0A>=0A>=0A>But why are you opting for option 1 then? That seems not logi= cal. You argue against reactive protocols in general.=A0All what you say ab= ove is known to MANET, long before ROLL and LLN even existed.=0A=0AJP> If I= may express my opinion (not sure what Joydeep thinks about this) you very = well know that Load has been positioned=0Aas a lightweight reactive routing= protocol for LLNs. The deployment that has been mentioned on the list (wit= hout any details) is=A0=0Arelated=A0to AMI over PLC, probably one of the mo= st constrained LLN. There are other reasons for opting for option 1.=0A=0A= =0A>=0A>=A0=0A>IMHO, any protocol can be shown 'working perfectly', if we p= rovide a favorable atmosphere only for it to work.=0A>=0A>=0A>Yes, I agree.= You say yourself, no-one-size-fits all, which is why MANET works on both r= eactive and proactive protocol.=0A>=A0=0A>Looking at that perspective, I do= n't think, LOAD-ng working in one network under one particular scenario sho= uld be considered a vital argument to discuss whether to go with AODVv2 or = LOAD-ng. =0A>=0A>=0A>LOADng has one large-scale deployment, DYMO does not. = LOADng has multiple recent interoperable implementations, DYMO has not. LOA= Dng is based on the same mechanism of AODV that is known to work in certain= MANET scenarios. =0A=0AJP> Along those lines, I could list a dozen of prop= rietary protocols deployed in the field, still the IETF does not have to st= andardize=0Athem all.=0A=0ANot going to each point one by one, if the docum= ent ends up trying to be applicable to LLNs, we would need to have it revie= wed by a=0Awider audience (ROLLE WG). Chair hat off, I would offer to write= an ID listing the number of issues using reactive in LLNs.=0A=0AThanks.=0A= =0AJP.=0A=0ASo why do you opt for 1) and not 3)?=0A>=0A>=0A>=A0=0A>=A0=0A>O= ne can write a working code of AODVv2 in 2 days. The real question we shoul= d be asking, which protocol is better suited for general MANET overall, and= if there really is a *necessity* of discarding a working group document.= =0A>=A0=0A>=0A>>=0A>>Secondly, LOAD-ng was devised keeping LLN scenario in = mind. It was intended for ROLL WG, and since it had not been adopted in the= ROLL WG, it popped up in the MANET WG. The change that has been done to LO= AD-ng after dragging it to MANET WG, was really to change the message forma= t to adhere to RFC 5444,=0A>=0A>=0A>That is true, the work was initiated fr= om LLNs. However, as you say yourself, it has adopted RFC5444 and other MAN= ET requirements. Note that amongst the authors, there are a large part of t= he previous RFC editors of MANET presented. We know MANETs and their requir= ements. Can you point out a specific requirement that LOADng would not fulf= ill but DYMO would?=0A>=0A>=0A>=A0=0A>and do a "find and replace" of the te= rm LLN with 'MANET' along with changing the first 'L' of LOAD ng from 'LLN'= to 'Lightweight'. Since the protocol was designed for LLN at first, I do n= ot think it would be able to cover the broad spectrum that MANET includes. = =0A>=0A>=0A>Why? And why does DYMO? I don't see a technical argument.=0A>= =0A>=0A>=A0=0A>Since we already have a WG document for a reactive protocol,= I do not see any strong reason to discard the current one in favor of an i= ndividual draft, especially when even LOAD-ng authors agreed that this prot= ocol will not offer any notable performance difference compared to AODVv2.= =A0=0A>=0A>=0A>Yes, but the document is not aligned with the RFC5444 archit= ecture, it is not possible to secure, and it would be a lot more work to co= me to an RFC, in my opinion (lots of unclear and underspecified text, incom= plete IANA section, unclear metrics, underspecified bidirectionality detect= ion).=0A>=0A>=0A>=A0=0A>=0A>>=0A>>At the same time, since I have read both = drafts, I figured out that AODVv2 is more generic to MANET than LOAD-ng. It= offers the developer or the deployment authority to chose form more than o= ne options.=0A>=0A>=0A>Options may be fine, but they also affect interopera= bility if not carefully designed. And they may, as for some of the options = like iRREP, make it very difficult or impossible to provide end-to-end secu= rity.=0A>=0A>=0A>=A0=0A>For example, AODVv2 has the option (but it is not m= andated) to use a precursor list or have an intermediate node to reply an R= REQ. LOAD-ng does not support either.=0A>=0A>=0A>That is not true. We opted= to move these in companion document, as we have not seen proof that these = options would bring benefit in a general MANET case.=A0=0A>=A0=0A>=0A>=0A>I= can understand that for an LLN it may be beneficial for not maintaining a = precursor list or having only the destination reply t o a RREQ, there can b= e (and are) other instances of MANETs where having the option of precursor = list will come handy. =0A>=0A>=0A>Which? Can you show results that this is = beneficial in a general use case?=0A>=0A>=0A>=A0=0A>This can save on contro= l overhead, using some storage space in the node. LOAD-ng, in most cases do= es not provide this flexibility to the developer to chose between options f= or specific deployment. =0A>=0A>=0A>Again, not true. We provide TLVs, and e= xtensions are possible in companion documents. We have very carefully desig= ned each RFC2119 word to make sure extensions are allowed. Multiple options= always carry a great risk of non-interoperability.=0A>=0A>=0A>=A0=0A>Some = MANET deployment may be less harsh than others in nature. Hence, AODVv2 hav= ing more open options than LOAD-ng, in most cases, seem beneficial to me. = =0A>=0A>=0A>"seems beneficial"? Have you proof for the use of the options?= =0A>=0A>=0A>=A0=0A>Of course, there are other technical differences between= these protocols. But I believe there is a separate thread created for that= . I will wait for the draft authors to reply there first, and will reply wi= th my points if all those differences are not covered. There, I will re-ite= rate the necessity of a protocol to be suited for MANET in general, not onl= y 'some' kind of MANETs=A0=0A>=0A>>=0A>>Lastly, I do not come from any indu= stry, neither I have any company road-map of=A0deliverable=A0here. Being a = PhD candidate in a university, I tried to fairly judge the two options.=A0= =0A>=0A>>=0A>So I read both drafts, and did not find a strong enough reason= to discard a current working group document. Whether a few companies backi= ng up a protocol over the other can be a decisive criteria to chose a stand= ard protocol or not, is in the WG and its chairs most capable hands. Also, = I did not, very clearly understand how LOAD-ng, operating properly in a 2-5= routers=A0test-bed=A0may be considered as proof of valid interoperability.= =A0=0A>=0A>=0A>Why not? What would it change to add 100 nodes? I have never= seen any interop tests with more than a handful nodes. Again: interop test= s are not performance tests.=A0=0A>By the way, I have not seen any such ope= n interoperability tests during the development of DYMO .=0A>=0A>=0A>=A0=0A= >I would very much appreciate feedback if I am wrong, since I am in my lear= ning phase :-) . I have my 2 cents here - a) AODVv2 offers more flexibility= , =0A>=0A>=0A>As said, LOADng offers the same flexibility. Flexibility is n= ice, but one has to be very careful with interoperability.=A0If LOADng were= to be a WG document, of course the WG can discuss if certain options bring= a general benefit and don't harm interoperability, then we can include it.= =0A>=0A>=0A>=A0=0A>b) LOAD-ng does not offer enough advantage over AODVv2 t= o discard the later,=0A>=0A>=0A>One major advantage is that it could be an = RFC far quicker. In the current shape, the SEC AD would certainly not accep= t DYMO, and it would require a lot more work to bring to a level that is ac= ceptable for a standards track RFC.=A0=0A>=0A>=0A>=A0=0A>c) LOAD-ng was not= initially designed for MANET,=0A>=0A>=0A>I don't see the argument here (se= e above)=0A>=A0=0A>and d) there are other technical differences that make A= ODVv2 more suitable for MANETs over LOAD-ng (To be covered in separate thre= ad). =A0=0A>=0A>=0A>I am curious to see that.=0A>=0A>=0A>Best=0A>Ulrich=0A>= =A0=0A>My opinion - We should stick to current WG document (AODVv2) and imp= rove it and finish it as soon as possible. I hereby stand for Option 1.=A0= =0A>>=0A>>=0A>>Thanks and Regards,=0A>>=0A>>=0A>>Joydeep Tripathi=0A>>PhD C= andidate,=A0=0A>>Drexel University.=0A>>=0A>>=0A>>=0A>>On Tue, Oct 30, 2012= at 7:13 PM, Joseph Macker wrote:=0A>>=0A>>Hello MANET= working group (form Stan and Joe),=0A>>>=0A>>>As you are all probably awar= e, there has been WG activity lately on competing drafts for a MANET reacti= ve protocol - DYMO (reviving the current working group document that was pa= rked due to inactivity), and LOADng. Many months ago there was a somewhat a= uthorship=0A led movement towards a common document effort and given positi= ve feedback at the time we the chairs thought this was the best approach gi= ven the authors potential to come together and gain the best of both effort= s.=A0 Since that period, there has been some fairly=0A strident and rancoro= us "at times" debate between the authors of the two documents.=0A>>>=0A>>>= =0A>>>During IETF 84 in Vancouver, the co-chairs held a discussion with som= e of the co-authors of the two documents. Our guidance to the co-authors wa= s to find a way to merge the two documents into one, as it was perceived th= at are not technically far apart and they both derive roughly from AODV con= cepts and LOADng had fairly active authorship and implementation efforts. W= e provided a co-editing proposal to the authors and gave them the timeframe= of the Atlanta to come up with an answer back to us regarding this.=A0 As = of this writing, those discussions of a potential commonn document and auth= orship merger have failed.=0A>>>=0A>>>=0A>>>Therefore, we find ourselves at= a crossroads. The authors of the two documents are divided, and it is unli= kely that progress on a merged document can be reached based upon recent au= thor feedback. I have also polled the earlier WG editor of DYMO, Ian Chaker= es, and he is somewhat disengaged on the issue at the present time.=A0 We s= ee only 3 possible paths forward:=0A>>>=0A>>>1. Continue the work on the DY= MO document, starting with whether there is consensus on its continued appr= oach and also the desire to rename it to AODVv2.=0A>>>=0A>>>2. Replace the = existing DYMO document effort with the LOADng related document effort, defu= sing ealier references to LLNs as recommended in the last meeting minutes, = and to focus more motivationally on general MANET problem spaces (the autho= rs seem to have agreed to this issue if its a WG document).=0A>>>=0A>>>3. R= emove the working group charter for a reactive protocol, effectively killin= g both documents, at least from a working group (WG) standpoint. This would= not be a reflection on the technology in either case, just an admission th= at we are not working together and reaching consensus.=0A>>>=0A>>>=0A>>>The= co-chairs request and need your opinions on the options.=A0 We have been s= ome silent collecting initial feedback and waiting for author feedback at t= his point.=A0 Stan and I are both on travel prior to Atlanta so our respons= es may be sparse and we will also likely be in a "receive mode" for a few d= ays.=A0 So send your opinions.=0A>>>=0A>>>-Joe=0A>>>=0A>>>_________________= ______________________________=0A>>>manet mailing list=0A>>>manet@ietf.org= =0A>>>https://www.ietf.org/mailman/listinfo/manet=0A>>>=0A>>>=0A>>=0A>>____= ___________________________________________=0A>>manet mailing list=0A>>mane= t@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/manet=0A>>=0A>>=0A>___= ____________________________________________=0A>manet mailing list=0A>manet= @ietf.org=0A>https://www.ietf.org/mailman/listinfo/manet=0A>=0A=0A_________= ______________________________________=0Amanet mailing list=0Amanet@ietf.or= g=0Ahttps://www.ietf.org/mailman/listinfo/manet --1874956439-657364848-1352081151=:19662 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
JP, once again you ar= e distracting us from the topics that needs to be discussed.  This is = not and should not be a debate on if or if not LLNs can use a reactive prot= ocol.

It \IS/ a discussion about which of the two documents is in th= e best shape for this working group to move forward to complete our charter= item of producing a reactive routing protocol for MANETs.

We know y= ou think that RPL has the exclusive rights to routing in LLNs.  We got= it.

Can we please move to the necessary discussion.  If you ha= ve some specific items in the comparison between the DYMO draft and the LOA= Dng draft, please bring them up.  You have not yet.  Have you rea= d both drafts?

Jon


<= div style=3D"font-family: times new roman, new york, times, serif; font-size: 12pt;">
From:<= /b> JP Vasseur (jvasseur) <jvasseur@cisco.com>
To: Ulrich Herberg <ulrich@herberg.name&g= t;
Cc: "<manet@ietf= .org>" <manet@ietf.org>
Sent: Sunday, November 4, 2012 6:38 PM
Subject: Re: [manet] Reactive Protocol Situati= on

=0A=0A =0A=0A
=0AHi,=0A

= =0A
=0A
On Nov 1, 2012, at 9:39 PM, Ulrich Herberg wrote:
=0A<= br class=3D"yiv1682214598Apple-interchange-newline">=0A
Hi Joydeep,
=0A
=0A
On T= hu, Nov 1, 2012 at 5:58 PM, Joydeep Tripathi =0A<jt369@drexel.edu> wrote:
=0A<= blockquote class=3D"yiv1682214598gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex;">=0AHi Joe and MANET WG,=0A
=
=0A
=0A
I was following the discussion on which route to take = for a reactive protocol standard very closely, and I think I should post my= opinion also. I champion for=0AOption 1, and here is why : =0A

=0A
=0A
I have read both AODVv2 (DYMO) and LOAD-ng = drafts, and I have simulated LOAD-ng myself as well. This experience, I bel= ieve, puts me in a position to form an opinion comparing these two protocol= s.=0A
=0A
=0A

=0A
=0A
That is valuable. H= ave you also implemented DYMO and compared it to LOADng?
=0A

= =0A
=0A
 
=0A
=0A

=0A
=0AFirstly, LOAD-ng is backed up by the argument that it has implementations= and interop documents. However, I have seen in the mailing list, that cert= ain question on details of the 'practical' implementation of LOAD-ng has be= en avoided.=0A
=0A=0A

=0A
=0A
I don't se= e how. There was a description of the deployment and about the suitability = for LOADng in that. Note that for DYMO, there is no such deployment (to my = knowledge), which is why I think your conclusion for option 1 instead of op= tion 3 is surprising=0A to me.
=0A

=0A
=0A
 =0A
=0A
A reactive protoc= ol may do well in a 2000 nodes smart meter network, if the data traffic to = the base station or collector is 1-2 times a day. This kind of implementati= ons, in my opinion, say nothing about usefulness of LOAD-ng in Smart Grid n= etworks or=0A LLNs.
=0A
=0A

=0A
=0A
It i= s well known (and also spelled out in DYMO), that reactive protocols are mo= re suitable for sparse traffic scenarios with few concurrent communication = streams. That is well-known and understood in MANET, and a reasons to work = on a proactive protocol=0A as well. Reactive protocols have their limitatio= ns, but in certain MANET use cases are useful, which is why we are chartere= d to work on a reactive protocol.
=0A
=0A=0A
=0A
=0A
JP> We all agree, with a a non subtle nuance. I never = said that reactive routing was a bad idea. These protocol are very useful.<= /div>=0A
They are just ill-suited to LLNs. If you design a protocol X i= n MANET and explicitly mention that it would not be applicable to LLNs,=0A
then I would personally be fine. Now if you claim that a protocol= such as Load could work in specify lightweight traffic use cases, =0A
then can you explain why existing LLN routing protocol do not wo= rk ? The idea is to avoid having two protocols if one is sufficient
= =0A
(once again for LLNs). 
=0A
=0A
=0A
=0A
 
=0A=0A
Again, whether LLN may be co= nsidered as a subset of MANET or not is a different question. But even then= , deployed LOAD-ng in a 2000 node network may (and in my opinion, will) fai= l if traffic is increased.
=0A
=0A

=0A
=0AThat is possible. Both in DYMO and LOADng.
=0A
 
=0A=0A
Agreed, one size does no= t fit all. However, once we have multicast traffic in a smart grid or multi= ple meters generating alert packets in a region at the same time, a reactiv= e protocol like LOAD-ng will lead to the break-down of the network. Anyone = can=0A say multicast traffic or several meters reporting emergency at the s= ame time to the same station, is a very much likely situation in smart grid= . Were these situations considered during deployment? Please note, I am NOT= saying that AODVv2 / DYMO will be better=0A in this case than LOAD-ng= .
=0A=0A

=0A
=0A
But why are you opting = for option 1 then? That seems not logical. You argue against reactive proto= cols in general. All what you say above is known to MANET, long before= ROLL and LLN even existed.
=0A
=0A=0A

=0A=0A
JP> If I may express my opinion (not sure what Joydeep think= s about this) you very well know that Load has been positioned
=0Aas a lightweight reactive routing protocol for LLNs. The deployment that h= as been mentioned on the list (without any details) is 
=0A
r= elated to AMI over PLC, probably one of the most constrained LLN. Ther= e are other reasons for opting for option 1.
=0A
=0A
=0A
=0A

=0A
= =0A
 
=0A
=0AIMHO, any protocol can be shown 'working perfectly', if we provide a favor= able atmosphere only for it to work.
=0A
=0A

=0A=0A
Yes, I agree. You say yourself, no-one-size-fits all, which is = why MANET works on both reactive and proactive protocol.
=0A
 = ;
=0A
=0A
Looking at t= hat perspective, I don't think, LOAD-ng working in one network under one= particular scenario should be considered a vital argument to discuss wheth= er to go with AODVv2 or LOAD-ng.=0A
=0A
=0A

= =0A
=0A
LOADng has one large-scale deployment, DYMO does not. LOAD= ng has multiple recent interoperable implementations, DYMO has not. LOADng = is based on the same mechanism of AODV that is known to work in certain MAN= ET scenarios.=0A
=0A
=0A=0A

=0A
=0AJP> Along those lines, I could list a dozen of proprietary protocols de= ployed in the field, still the IETF does not have to standardize
=0Athem all.
=0A

=0A
=0A
Not going to each point one = by one, if the document ends up trying to be applicable to LLNs, we would n= eed to have it reviewed by a
=0A
wider audience (ROLLE WG). Chair = hat off, I would offer to write an ID listing the number of issues using re= active in LLNs.
=0A

=0A
=0A
Thanks.
=0A

= =0A
=0A
JP.
=0A

=0A
=0A
=0A
=0A
So why do you opt for 1= ) and not 3)?
=0A

=0A
=0A
 
=0A
=0A
 
=0A
=0A=0A
One can write a working c= ode of AODVv2 in 2 days. The real question we should be asking, which proto= col is better suited for general MANET overall, and if there really is a *n= ecessity* of discarding a working group document.
=0A
=0A<= div> 
=0A
=0A
=0A
=0A
Secondly, LOAD-ng was devised keeping LLN scenario in min= d. It was intended for ROLL WG, and since it had not been adopted in the RO= LL WG, it popped up in the MANET WG. The change that has been done to LOAD-= ng after dragging it to MANET WG, was really=0A to change the message forma= t to adhere to RFC 5444,
=0A
=0A

=0A
=0A
= That is true, the work was initiated from LLNs. However, as you say yoursel= f, it has adopted RFC5444 and other MANET requirements. Note that amongst t= he authors, there are a large part of the previous RFC editors of MANET pre= sented. We know MANETs and=0A their requirements. Can you point out a speci= fic requirement that LOADng would not fulfill but DYMO would?
=0A
=
=0A
=0A
 
=0A
=0A
and do a "find and replace" of= the term LLN with 'MANET' along with changing the first 'L' of LOAD ng fro= m 'LLN' to 'Lightweight'. Since the protocol was designed for LLN at first,= I do not think it would be able to cover the broad spectrum that MANET=0A = includes.
=0A
=0A

=0A
=0A
Why? And why d= oes DYMO? I don't see a technical argument.
=0A

=0A
=0A 
=0A
=0A
Sinc= e we already have a WG document for a reactive protocol, I do not see any s= trong reason to discard the current one in favor of an individual draft, es= pecially when even LOAD-ng authors agreed that this protocol will not offer= any notable performance=0A difference compared to AODVv2. 
=0A=0A

=0A
=0A
Yes, but the document is not aligne= d with the RFC5444 architecture, it is not possible to secure, and it would= be a lot more work to come to an RFC, in my opinion (lots of unclear and u= nderspecified text, incomplete IANA section, unclear metrics, underspecifie= d=0A bidirectionality detection).
=0A

=0A
=0A
 <= /div>=0A
=0A

=0A
= =0A
At the same time, since I have read both drafts, I figured out that= AODVv2 is more generic to MANET than LOAD-ng. It offers the developer or t= he deployment authority to chose form more than one options.
=0A=0A

=0A
=0A
Options may be fine, but they also affe= ct interoperability if not carefully designed. And they may, as for some of= the options like iRREP, make it very difficult or impossible to provide en= d-to-end security.
=0A

=0A
=0A
 
=0A=0A
For example, AODVv2 has the o= ption (but it is not mandated) to use a precursor list or have an intermedi= ate node to reply an RREQ. LOAD-ng does not support either.
=0A=0A

=0A
=0A
That is not true. We opted to move these= in companion document, as we have not seen proof that these options would = bring benefit in a general MANET case. 
=0A
 
=0A
=0A
=0A
=0A
I c= an understand that for an LLN it may be beneficial for not maintaining a pr= ecursor list or having only the destination reply t o a RREQ, there can be = (and are) other instances of MANETs where having the option of precursor li= st will come handy.=0A
=0A
=0A

=0A
=0A
Wh= ich? Can you show results that this is beneficial in a general use case?=0A

=0A
=0A
 
=0A
=0A
This can save on control overhead, using some stor= age space in the node. LOAD-ng, in most cases does not provide this flexibi= lity to the developer to chose between options for specific deployment.=0A<= /div>=0A
=0A

=0A
=0A
Again, not true. We provi= de TLVs, and extensions are possible in companion documents. We have very c= arefully designed each RFC2119 word to make sure extensions are allowed. Mu= ltiple options always carry a great risk of non-interoperability.
=0A<= div>
=0A
=0A
 
=0A
=0A
Some MANET deployment may be less harsh than others in na= ture. Hence, AODVv2 having more open options than LOAD-ng, in most cases, s= eem beneficial to me.=0A
=0A
=0A

=0A
=0A
= "seems beneficial"? Have you proof for the use of the options?
=0A
=0A
=0A
 
=0A
=0A
Of course, there are other technical differences between the= se protocols. But I believe there is a separate thread created for that. I = will wait for the draft authors to reply there first, and will reply with m= y points if all those differences are not=0A covered. There, I will re-iter= ate the necessity of a protocol to be suited for MANET in general, not only= 'some' kind of MANETs 
=0A
=0A
=0A

=0A
=0A
Lastly, I do not come f= rom any industry, neither I have any company road-map of deliverable&n= bsp;here. Being a PhD candidate in a university, I tried to fairly judge th= e two options. 
=0A
=0A
=0A
=0A
=0A
=0A
So I read both drafts, and did not find a strong enough = reason to discard a current working group document. Whether a few companies= backing up a protocol over the other can be a decisive criteria to chose a= standard protocol or not, is in the WG and its=0A chairs most capable hand= s. Also, I did not, very clearly understand how LOAD-ng, operating properly= in a 2-5 routers test-bed may be considered as proof of valid in= teroperability. 
=0A
=0A

=0A
=0A
Why= not? What would it change to add 100 nodes? I have never seen any interop = tests with more than a handful nodes. Again: interop tests are not performa= nce tests. 
=0A
By the way, I have not seen any such open int= eroperability tests during the development of DYMO .
=0A

=0A=0A
 
=0A
=0A=
I would very much appreciate feedback if I am wrong, since I am in my = learning phase :-) . I have my 2 cents here - a) AODVv2 offers more flexibi= lity,=0A
=0A
=0A

=0A
=0A
As said, LOADng = offers the same flexibility. Flexibility is nice, but one has to be very ca= reful with interoperability. If LOADng were to be a WG document, of co= urse the WG can discuss if certain options bring a general benefit and don'= t harm interoperability,=0A then we can include it.
=0A

=0A=0A
 
=0A
=0A<= div>b) LOAD-ng does not offer enough advantage over AODVv2 to discard the l= ater,
=0A=0A

=0A
=0A
One major advantage= is that it could be an RFC far quicker. In the current shape, the SEC AD w= ould certainly not accept DYMO, and it would require a lot more work to bri= ng to a level that is acceptable for a standards track RFC. 
=0A<= div>
=0A
=0A
 
=0A
=0A
c) LOAD-ng was not initially designed for MANET,
=0A=
=0A

=0A
=0A
I don't see the argument here (se= e above)
=0A
 
=0A
=0A
and d) there are other technical differences that make AODVv= 2 more suitable for MANETs over LOAD-ng (To be covered in separate thread).=  
=0A
=0A

=0A
=0A
I am curious to s= ee that.
=0A

=0A
=0A
Best
=0A
Ulrich
= =0A
 
=0A
=0AMy opinion - We should stick to current WG document (AODVv2) and improve i= t and finish it as soon as possible. I hereby stand for=0AOption 1.&= nbsp;
=0A

=0A
=0A
Thanks and Regards,
=0A
=0A
=0A
Joydeep Tripathi
=0A
PhD Candidate, 
= =0A
Drexel University.
=0A
=
=0A
=0A
=0A
On Tue, Oct 30, 2012 at 7:13 PM, Joseph Macker <jpmacker@gmail.com> wrote:
=0A
=0A
=0AHello MANET working group (form Stan and Joe),<= br>=0A
=0AAs you are all probably aware, there has been WG activity late= ly on competing drafts for a MANET reactive protocol - DYMO (reviving the c= urrent working group document that was parked due to inactivity), and LOADn= g. Many months ago there was a somewhat authorship=0A led movement towards = a common document effort and given positive feedback at the time we the cha= irs thought this was the best approach given the authors potential to come = together and gain the best of both efforts.  Since that period, there = has been some fairly=0A strident and rancorous "at times" debate between th= e authors of the two documents.
=0A
=0A
=0A
During IETF 84 in Vancouver, the co-chairs held a discussion with= some of the co-authors of the two documents. Our guidance to the co-author= s was to find a way to merge the two documents into one, as it was perceive= d that are not technically=0A far apart and they both derive roughly from A= ODV concepts and LOADng had fairly active authorship and implementation eff= orts. We provided a co-editing proposal to the authors and gave them the ti= meframe of the Atlanta to come up with an answer back to us regarding=0A th= is.  As of this writing, those discussions of a potential commonn docu= ment and authorship merger have failed.
=0A
=0A
=0A
Therefore, we find ourselves at a crossroads. The authors= of the two documents are divided, and it is unlikely that progress on a me= rged document can be reached based upon recent author feedback. I have also= polled the earlier WG editor of DYMO,=0A Ian Chakeres, and he is somewhat = disengaged on the issue at the present time.  We see only 3 possible p= aths forward:
=0A
=0A1. Continue the work on the DYMO document, start= ing with whether there is consensus on its continued approach and also the = desire to rename it to AODVv2.
=0A
=0A
2. Replace the existing DYMO document effort with the LOADng related docu= ment effort, defusing ealier references to LLNs as recommended in the last = meeting minutes, and to focus more motivationally on general MANET problem = spaces (the authors=0A seem to have agreed to this issue if its a WG docume= nt).
=0A
=0A
3. Remove the working gr= oup charter for a reactive protocol, effectively killing both documents, at= least from a working group (WG) standpoint. This would not be a reflection= on the technology in either case, just an admission that we are not=0A wor= king together and reaching consensus.
=0A
=0A
=0A
The co-chairs request and need your opinions on the options= .  We have been some silent collecting initial feedback and waiting fo= r author feedback at this point.  Stan and I are both on travel prior = to Atlanta so our responses may be sparse=0A and we will also likely be in = a "receive mode" for a few days.  So send your opinions.
=0A
=0A= -Joe
=0A
=0A_______________________________________________
=0Aman= et mailing list
=0Amanet@ietf.org
=0A= https://www.ietf.org/mailman/listinfo/manet
=0A
= =0A
=0A=0A
=0A
=0A=0A
=0A_______________= ________________________________
=0Amanet mailing list
=0Amanet@ietf.org
=0Ahttps://www.ietf.= org/mailman/listinfo/manet
=0A
=0A=0A=0A
= =0A_______________________________________________
=0Amanet mailing list=
=0Amanet@ietf.org
=0Ahttps://www.iet= f.org/mailman/listinfo/manet
=0A=0A=0A
=0A= =0A=0A=0A
_______________________________________________
manet mailing l= ist
= manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--1874956439-657364848-1352081151=:19662-- From jblack.ietf@yahoo.com Sun Nov 4 18:07:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2591821F88C1 for ; Sun, 4 Nov 2012 18:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BU7hW7fpEkIo for ; Sun, 4 Nov 2012 18:07:18 -0800 (PST) Received: from nm23.bullet.mail.bf1.yahoo.com (nm23.bullet.mail.bf1.yahoo.com [98.139.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id C340721F8812 for ; Sun, 4 Nov 2012 18:07:17 -0800 (PST) Received: from [98.139.215.142] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2012 02:07:17 -0000 Received: from [98.139.212.217] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2012 02:07:16 -0000 Received: from [127.0.0.1] by omp1026.mail.bf1.yahoo.com with NNFMP; 05 Nov 2012 02:07:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 820172.38949.bm@omp1026.mail.bf1.yahoo.com Received: (qmail 74894 invoked by uid 60001); 5 Nov 2012 02:07:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352081236; bh=bQYVODkSwVvTiztnwIqJp+ElBsNDTEE6xfnoGmBxHDU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YB9SQnVeSJqjIxFa+4ubSxs7M+Gc2XUXQIkN+oI3QArXGgloqWB4NxIIjiO0zddTC43ZvI6prGEKlDAwx0BRIUgCVtiflEDAiM4vzmeGHzs91a8Xrqfk09W1vr7GOXD3QU9hRP+tu5Edcr7xEejptcCuk/ETG0NWbVcRYvYLgX4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nYxeQS2D3PLO/ezzTpZGspWvBWvuS85geZvfYsbIzGLtKPEpwUaqppooQepgo+/TAi554zV3H+WoUbJ1euAnNz7cq10bv7skawm7U6mA0+oyP1JLgRGruftIM9QZehA+VYIIjYcLQZB2as4tOV7zbh7F+wMSo3fp//3hnSZ0f70=; X-YMail-OSG: g_mH_4gVM1lZczxKbzPozFgYhqQtLxenE7uDSYOMrlKN6ID fS05SKE05Zm9oNBC..uAkVC3Jbt1L6lAchsTkhsMztisHHH4Pmsx5irAPs03 zs7NYWcc.N4MJYIqYYvfOiQ34BCh3rjWb7qyrRu1cNFHPHRC03gUBzVmAWA8 c.6xa.szCiHo_zdAe_4mqCa3tcMvZzTDLLcX0MUlF3PnHpn2WWIRs9dnz9Vw G_A_nmduCsLTxHRN6gK5jN1Qyodp52aYHeVqW6R6IunHbCUNIYaToCtseYnc rnLSq2F83HsPnEgf_EryMjHq4XyLqnv.zOEMjISjZwwvPHDM7Zz.ZhANVxLz Ti_kbE1TU5cJOHbm9Ds6okmpyF4TXVO4kvppQs8Yu8pVMl_e5hoCsMvV5cJ2 FPMtgkKGnD_oh_OFJkvq2RV.2CpCkJ62iEsqRY8LKGrxeEVBV12SG5r3z0Mp 7y63rtg-- Received: from [67.213.218.74] by web160602.mail.bf1.yahoo.com via HTTP; Sun, 04 Nov 2012 18:07:15 PST X-Rocket-MIMEInfo: 001.001, Tm8gd2Ugc2hvdWxkIG5vdC7CoCBUaGF0IHdvdWxkIGJlIGEgd2FzdGUgb2YgdGltZSBpZiB0aGUgV0cgZGVjaWRlZCB0byBtb3ZlIGZvcndhcmQgd2l0aCBMT0FEbmcuwqAgSSBkbyBub3QgYmVsaWV2ZSB0aGF0IHdlIGhhdmUgYXJyaXZlZCBhdCB0aGF0IGEgZGVjaXNpb24uCgpKb24KCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBKUCBWYXNzZXVyIChqdmFzc2V1cikgPGp2YXNzZXVyQGNpc2NvLmNvbT4KVG86IFVscmljaCBIZXJiZXJnIDx1bHJpY2hAaGVyYmVyZy5uYW1lPiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <03B78081B371D44390ED6E7BADBB4A7722052F08@xmb-rcd-x02.cisco.com> Message-ID: <1352081235.74797.YahooMailNeo@web160602.mail.bf1.yahoo.com> Date: Sun, 4 Nov 2012 18:07:15 -0800 (PST) From: Jon Black To: "JP Vasseur \(jvasseur\)" , Ulrich Herberg In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722052F08@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1725615817-289807619-1352081235=:74797" Cc: "" Subject: Re: [manet] DYMO-23 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 02:07:19 -0000 ---1725615817-289807619-1352081235=:74797 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable No we should not.=A0 That would be a waste of time if the WG decided to mov= e forward with LOADng.=A0 I do not believe that we have arrived at that a d= ecision.=0A=0AJon=0A=0A=0A=0A=0A________________________________=0A From: J= P Vasseur (jvasseur) =0ATo: Ulrich Herberg =0ACc: "" =0ASent: Sunday, Novem= ber 4, 2012 6:38 PM=0ASubject: Re: [manet] DYMO-23 review=0A =0AHi,=0A=0AI = think that we can agree with some of your comments.=0A=0AShould we start op= ening tickets and address those points ?=0A=0AThanks.=0A=0AJP.=0A=0AOn Nov = 1, 2012, at 5:38 PM, Ulrich Herberg wrote:=0A=0A> Hi,=0A> =0A> during the d= iscussion, I noticed that many just say "I like protocol=0A> foo1 better th= an foo2", without any technical argument. That is not=0A> very productive.= =0A> =0A> Here is my review of the latest DYMO 23 draft.=0A> =0A> The main = comments (as shown in detail below) are:=0A>=A0 - The draft is still very d= ifficult to read and is underspecified in=0A> many occasions. For example, = it is unclear how the blacklisting works,=0A> how metrics are used, how the= TLVs are associated with certain=0A> addresses. Some of the parameters and= TLVs specified in the IANA=0A> section are not used. There are at least fo= ur timers for each route=0A> entry, and it is unclear how they may affect e= ach other. It is not=0A> clearly specified how to update forward/reverse ro= utes + the route to=0A> the previous hop=0A>=A0 - The use of metrics is not= well defined; there is an optional=0A> distance field. It is unclear how m= etrics are created, whether they=0A> are additive, how they are formatted e= tc. What happens if some routers=0A> now the Distance field, others don't u= se it.=0A>=A0 - There are several extensions specified, but too few details= to=0A> assure interoperability. Some of them violate end-to-end security.= =0A>=A0 - As messages are modified in transit, end-to-end security is not= =0A> possible. The security considerations section does not fulfill the=0A>= requirements in RFC3552.=0A>=A0 - Extensions, such as for security, cannot= be hooked into AODVv2, as=0A> there is no section to allow an external mec= hanism to provide=0A> additional reasons to reject a message as invalid, su= ch as done in=0A> RFC6130.=0A>=A0 - The IANA section is not correct. There = are no requests, no new=0A> registries or code points in existing registrie= s, no allocation policy=0A> is provided.=0A>=A0 - There are some layer viol= ations where tasks that are to be done by=0A> the RFC5444 (de)multiplexer a= re handled in AODVv2.=0A>=A0 - There is a mandated order of addresses in RF= C5444 messages; I=0A> think this is a bad idea if extensions want to add ad= dresses.=0A>=A0 - Originator address and sequence number are contained in a= ddress=0A> block and address block TLV, instead of the message header, so t= here=0A> is additional overhead.=0A>=A0 - There is no RREP_ACK or other mec= hanism to verify bidirectionality=0A> of links.=0A>=A0 - It is unclear to m= e how the destination sequence number is used in=0A> RREQ and what it serve= s for.=0A>=A0 - Intermediate route replies are hard to secure with signatur= es=0A> =0A> Best regards=0A> Ulrich=0A> =0A> =0A> =0A> Mobile Ad hoc Networ= ks Working Group=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 C. Perk= ins=0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Futurewei=0A> Intended status:= Standards Track=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I.= Chakeres=0A> Expires: April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CenGen=0A>=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 October 23, 2012=0A> =0A> =0A>=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Dynamic MANET On-demand (AODVv2) Routing=0A>=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 draft-ietf-manet-dymo-23=0A> =0A> Abstract=0A> =0A= >=A0 The Dynamic MANET On-demand (AODVv2) routing protocol is intended for= =0A>=A0 use by mobile routers in wireless, multihop networks.=0A> =0A> UH>= It is really about dynamic topology, not "mobile routers". AODVv2=0A> may = be used in non-mobile mesh networks with a dynamic topology.=0A> =0A>=A0 = =A0 AODVv2=0A>=A0 determines unicast routes among AODVv2 routers within t= he network in=0A>=A0 an on-demand fashion, offering on-demand convergence = in dynamic=0A>=A0 topologies.=0A> =0A> UH> What is on-demand convergence?= =0A> =0A> Status of this Memo=0A> =0A>=A0 This Internet-Draft is submitted= in full conformance with the=0A>=A0 provisions of BCP 78 and BCP 79.=0A> = =0A>=A0 Internet-Drafts are working documents of the Internet Engineering= =0A>=A0 Task Force (IETF).=A0 Note that other groups may also distribute= =0A>=A0 working documents as Internet-Drafts.=A0 The list of current Inter= net-=0A>=A0 Drafts is at http://datatracker.ietf.org/drafts/current/.=0A> = =0A>=A0 Internet-Drafts are draft documents valid for a maximum of six mon= ths=0A>=A0 and may be updated, replaced, or obsoleted by other documents a= t any=0A>=A0 time.=A0 It is inappropriate to use Internet-Drafts as refere= nce=0A>=A0 material or to cite them other than as "work in progress."=0A> = =0A>=A0 This Internet-Draft will expire on April 26, 2013.=0A> =0A> Copyri= ght Notice=0A> =0A>=A0 Copyright (c) 2012 IETF Trust and the persons ident= ified as the=0A>=A0 document authors.=A0 All rights reserved.=0A> =0A>=A0 = This document is subject to BCP 78 and the IETF Trust's Legal=0A>=A0 Prov= isions Relating to IETF Documents=0A>=A0 (http://trustee.ietf.org/license-= info) in effect on the date of=0A>=A0 publication of this document.=A0 Ple= ase review these documents=0A>=A0 carefully, as they describe your rights = and restrictions with respect=0A>=A0 to this document.=A0 Code Components = extracted from this document must=0A>=A0 include Simplified BSD License te= xt as described in Section 4.e of=0A>=A0 the Trust Legal Provisions and ar= e provided without warranty as=0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0= =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 1]=0A> = =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A> =0A> =0A>=A0 described in th= e Simplified BSD License.=0A> =0A> =0A> Table of Contents=0A> =0A>=A0 1.= =A0 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .=A0 4=0A>= =A0 2.=A0 Terminology=A0 . . . . . . . . . . . . . . . . . . . . . . . . .= =A0 5=0A>=A0 3.=A0 Applicability Statement=A0 . . . . . . . . . . . . . . = . . . . .=A0 7=0A>=A0 4.=A0 Data Structures=A0 . . . . . . . . . . . . . .= . . . . . . . . .=A0 8=0A>=A0 =A0 4.1.=A0 Route Table Entry=A0 . . . . . = . . . . . . . . . . . . . . .=A0 8=0A>=A0 =A0 4.2.=A0 AODVv2 Message Struc= ture and Information Elements=A0 . . . .=A0 9=0A>=A0 =A0 4.3.=A0 RteMsg-sp= ecific Protocol Elements=A0 . . . . . . . . . . . . 11=0A>=A0 =A0 4.4.=A0 = Route Error (RERR)-specific Protocol Elements=A0 . . . . . . 12=0A>=A0 5.= =A0 Detailed Operation for the Base Protocol . . . . . . . . . . . 13=0A>= =A0 =A0 5.1.=A0 AODVv2 Sequence Numbers=A0 . . . . . . . . . . . . . . . .= . 13=0A>=A0 =A0 =A0 5.1.1.=A0 Maintaining A Node's Own Sequence Number . = . . . . . . 13=0A>=A0 =A0 =A0 5.1.2.=A0 Actions After OwnSeqNum Loss . . .= . . . . . . . . . . 13=0A>=A0 =A0 5.2.=A0 AODVv2 Routing Table Operations= =A0 . . . . . . . . . . . . . 13=0A>=A0 =A0 =A0 5.2.1.=A0 Judging Routing = Information's Usefulness . . . . . . . 13=0A>=A0 =A0 =A0 5.2.2.=A0 Creatin= g or Updating Route Table Entries . . . . . . . 15=0A>=A0 =A0 =A0 5.2.3.= =A0 Route Table Entry Timeouts . . . . . . . . . . . . . . 15=0A>=A0 =A0 5= .3.=A0 Routing Messages . . . . . . . . . . . . . . . . . . . . . 16=0A>=A0= =A0 =A0 5.3.1.=A0 RREQ Creation=A0 . . . . . . . . . . . . . . . . . . . = . 16=0A>=A0 =A0 =A0 5.3.2.=A0 RREP Creation=A0 . . . . . . . . . . . . . .= . . . . . . 17=0A>=A0 =A0 =A0 5.3.3.=A0 RteMsg Handling=A0 . . . . . . . = . . . . . . . . . . . . 18=0A>=A0 =A0 5.4.=A0 Route Discovery=A0 . . . . .= . . . . . . . . . . . . . . . . 20=0A>=A0 =A0 5.5.=A0 Route Maintenance= =A0 . . . . . . . . . . . . . . . . . . . . 21=0A>=A0 =A0 =A0 5.5.1.=A0 Ac= tive Next-hop Router Adjacency Monitoring=A0 . . . . . 21=0A>=A0 =A0 =A0 5= .5.2.=A0 Updating Route Lifetimes During Packet Forwarding=A0 . . 22=0A>=A0= =A0 =A0 5.5.3.=A0 RERR Generation=A0 . . . . . . . . . . . . . . . . . . = . 22=0A>=A0 =A0 =A0 5.5.4.=A0 RERR Handling=A0 . . . . . . . . . . . . . .= . . . . . . 23=0A>=A0 =A0 5.6.=A0 Unknown Message and TLV Types=A0 . . . = . . . . . . . . . . . 24=0A>=A0 =A0 5.7.=A0 Advertising Network Addresses= =A0 . . . . . . . . . . . . . . 24=0A>=A0 =A0 5.8.=A0 Simple Internet Atta= chment . . . . . . . . . . . . . . . . 24=0A>=A0 =A0 5.9.=A0 Multiple Inte= rfaces=A0 . . . . . . . . . . . . . . . . . . . 25=0A>=A0 =A0 5.10. AODVv2= Control Packet/Message Generation Limits=A0 . . . . . 26=0A>=A0 =A0 5.11.= Optional Features=A0 . . . . . . . . . . . . . . . . . . . . 26=0A>=A0 =A0= =A0 5.11.1. Expanding Rings Multicast=A0 . . . . . . . . . . . . . . 26= =0A>=A0 =A0 =A0 5.11.2. Intermediate RREP=A0 . . . . . . . . . . . . . . .= . . . 27=0A>=A0 =A0 =A0 5.11.3. Precursor Notification . . . . . . . . . = . . . . . . . 27=0A>=A0 =A0 =A0 5.11.4. Reporting Multiple Unreachable Nod= es . . . . . . . . . 28=0A>=A0 =A0 =A0 5.11.5. Message Aggregation=A0 . . = . . . . . . . . . . . . . . . 28=0A>=A0 =A0 =A0 5.11.6. Adding Additional = Routing Information to a RteMsg=A0 . . 29=0A>=A0 =A0 5.12. Administrativel= y Configured Parameters and Timer Values=A0 . 30=0A>=A0 =A0 5.13. IANA Con= siderations=A0 . . . . . . . . . . . . . . . . . . . 33=0A>=A0 =A0 =A0 5.1= 3.1. AODVv2 Message Types Specification . . . . . . . . . . 33=0A>=A0 =A0 = =A0 5.13.2. Message and Address Block TLV Type Specification . . . 33=0A>= =A0 =A0 =A0 5.13.3. Address Block TLV Specification=A0 . . . . . . . . . .= . 34=0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 =A0 Expires April 26, 2= 013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 2]=0A> =0A> Internet-Draft=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= October 2012=0A> =0A> =0A>=A0 =A0 5.14. Security Considerations=A0 . . .= . . . . . . . . . . . . . . 34=0A>=A0 =A0 5.15. Acknowledgments=A0 . . . = . . . . . . . . . . . . . . . . . . 36=0A>=A0 6.=A0 References . . . . . .= . . . . . . . . . . . . . . . . . . . . 36=0A>=A0 =A0 6.1.=A0 Normative R= eferences . . . . . . . . . . . . . . . . . . . 36=0A>=A0 =A0 6.2.=A0 Info= rmative References . . . . . . . . . . . . . . . . . . 37=0A>=A0 Appendix = A.=A0 Changes since the Previous Version=A0 . . . . . . . . . 38=0A>=A0 Ap= pendix B.=A0 Shifting Network Prefix Advertisement Between=0A>=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 AODVv2 Routers=A0 . . . . . . . . . . . . . . . . . . .= 39=0A>=A0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . = . . 39=0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A>= =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A>= =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> Perk= ins & Chakeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 [Page 3]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A> =0A> = =0A> 1.=A0 Overview=0A> =0A>=A0 The Dynamic MANET On-demand (AODVv2) routi= ng protocol [formerly named=0A>=A0 DYMO] enables on-demand, multihop unica= st routing among AODVv2=0A>=A0 routers in mobile ad hod networks [MANETs][= RFC2119].=0A> =0A> UH> Why is RFC2119 cited here?=0A> =0A>=A0 =A0 The basic= =0A>=A0 operations of the AODVv2 protocol are route discovery and route=0A= >=A0 maintenance.=A0 Route discovery is performed when an AODVv2 router mu= st=0A>=A0 transmit a packet towards a destination for which it does not ha= ve a=0A>=A0 route.=A0 Route maintenance is performed to avoid dropping pac= kets,=0A>=A0 when a route being used to forward packets from the source to= a=0A>=A0 destination breaks,=0A> =0A> UH> That is something that is uncle= ar in the draft. Would data packets=0A> be buffered on intermediate routers= along their way? Would a new RREQ=0A> be issed from intermediate routers? = If not, packets would be dropped.=0A> =0A>=A0 and to avoid prematurely exp= unging routes from=0A>=A0 the route table.=0A> =0A>=A0 During route disco= very, an AODVv2 router initiates flooding of a=0A>=A0 Route Request messag= e (RREQ) throughout the network to find a route=0A>=A0 to a particular des= tination, via the AODVv2 router responsible for=0A>=A0 this destination.= =A0 During this hop-by-hop flooding process, each=0A>=A0 intermediate AODV= v2 router receiving the RREQ message records a route=0A>=A0 to the origina= tor.=A0 When the target's AODVv2 router receives the=0A>=A0 RREQ, it recor= ds a route to the originator and responds with a Route=0A>=A0 Reply (RREP)= unicast hop-by-hop toward the originating AODVv2 router.=0A>=A0 Each inte= rmediate AODVv2 router that receives the RREP creates a=0A>=A0 route to th= e target, and then the RREP is unicast hop-by-hop toward=0A>=A0 the origin= ator.=A0 When the originator's AODVv2 router receives the=0A>=A0 RREP, rou= tes have then been established between the originating=0A>=A0 AODVv2 route= r and the target AODVv2 router in both directions.=0A> =0A>=A0 Route maint= enance consists of two operations.=A0 In order to preserve=0A>=A0 routes i= n use, AODVv2 routers extend route lifetimes upon=0A>=A0 successfully forw= arding a packet.=A0 In order to react to changes in=0A>=A0 the network top= ology, AODVv2 routers monitor traffic being forwarded.=0A>=A0 When a data = packet is received for forwarding and a route for the=0A>=A0 destination i= s not known or the route is broken, then the AODVv2=0A>=A0 router of the s= ource of the packet is notified.=A0 A Route Error (RERR)=0A>=A0 is transmi= tted to indicate the route to one or more affected=0A>=A0 destination addr= esses is Broken=0A> =0A> UH> s/Broken/broken/=0A> =0A>=A0 or missing.=A0 W= hen the source's AODVv2=0A>=A0 router receives the RERR, it marks the rout= e as broken.=A0 Before the=0A>=A0 AODVv2 router can forward a packet to th= e same destination, it has to=0A>=A0 perform route discovery again for tha= t destination.=0A> =0A>=A0 Similarly to AODV, AODVv2 uses sequence numbers= to ensure loop=0A>=A0 freedom [Perkins99].=0A> =0A> UH> Citation to AODV = missing. Is AODVv2 updating or obsoleting AODV?=0A> =0A>=A0 =A0 Sequence nu= mbers enable AODVv2 routers to=0A>=A0 determine the temporal order of AODV= v2 route discovery messages,=0A>=A0 thereby avoiding use of stale routing = information.=A0 Also, AODVv2 uses=0A>=A0 RFC 5444 message and TLV formats.= =0A> =0A> UH> As this is the successor to AODV, it would help to point out = what=0A> has been improved/changed compared to AODV.=0A> =0A> =0A> =0A> =0A= > =0A> =0A> Perkins & Chakeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 [Page 4]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October= 2012=0A> =0A> =0A> 2.=A0 Terminology=0A> =0A>=A0 The key words "MUST", "M= UST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A>=A0 "SHOULD", "SHOULD NOT",= "RECOMMENDED", "NOT RECOMMENDED", "MAY", and=0A>=A0 "OPTIONAL" in this do= cument are to be interpreted as described in=0A>=A0 [RFC2119].=0A> =0A>=A0= Additionally, this document uses some terminology from [RFC5444].=0A> =0A= > UH> Which one?=0A> =0A>=A0 This document defines the following terminolo= gy:=0A> =0A>=A0 Adjacency=0A>=A0 =A0 =A0 A relationship between selected b= i-directional neighboring routers=0A>=A0 =A0 =A0 for the purpose of exchang= ing routing information.=A0 Not every pair=0A>=A0 =A0 =A0 of neighboring ro= uters will necessarily form an adjacency.=0A>=A0 =A0 =A0 Neighboring router= s may form an adjacency based on various=0A>=A0 =A0 =A0 information or othe= r protocols; for example, exchange of AODVv2=0A>=A0 =A0 =A0 routing message= s, other protocols (e.g.=A0 NDP [RFC4861] or NHDP=0A>=A0 =A0 =A0 [RFC6130])= , or manual configuration.=A0 Loss of a routing adjacency=0A>=A0 =A0 =A0 ma= y also be based upon similar information; monitoring of=0A>=A0 =A0 =A0 adja= cencies where packets are being forwarded is required (see=0A>=A0 =A0 =A0 S= ection 5.5.1).=0A> =0A>=A0 Distance (Dist)=0A>=A0 =A0 =A0 An unsigned inte= ger which measures the distance a message or=0A>=A0 =A0 =A0 information ele= ment has traversed.=A0 The minimum value of distance=0A>=A0 =A0 =A0 is the = number of IP hops traversed, 0 for local information.=A0 The=0A>=A0 =A0 =A0= maximum value is 254.=A0 The value 255 is reserved to indicate that=0A>=A0= =A0 =A0 the distance is unknown.=0A> =0A> UH> Is this a metrics? Why integ= er and not float? Is this additive?=0A> Why is it optional in the draft. Ar= e there different metric types=0A> supported in the same network?=0A> =0A> = =0A>=A0 AODVv2 Sequence Number (SeqNum)=0A>=A0 =A0 =A0 An AODVv2 Sequence = Number is an unsigned integer maintained by=0A>=A0 =A0 =A0 each AODVv2 rout= er.=A0 This sequence number guarantees the temporal=0A>=A0 =A0 =A0 order of= routing information to maintain loop-free routes.=A0 The=0A>=A0 =A0 =A0 va= lue zero (0) is reserved to indicate that the SeqNum for a=0A>=A0 =A0 =A0 d= estination address is unknown.=0A> =0A> UH> The last sentence is unclear. T= he first sentence said there is one=0A> seq. number per router. The last se= ntence talks about sequence numbers=0A> for destinations, which is a differ= ent thing.=0A> =0A>=A0 reactive=0A>=A0 =A0 =A0 A protocol operation is sai= d to be "reactive" if it is performed=0A>=A0 =A0 =A0 only in reaction to sp= ecific events.=A0 As used in this document,=0A>=A0 =A0 =A0 "reactive" is es= sentially synonymous with "on-demand".=0A> =0A>=A0 Router Client=0A>=A0 = =A0 =A0 An AODVv2 router may be configured with a list of other IP=0A>=A0 = =A0 =A0 addresses and networks which correspond to other non-router nodes= =0A>=A0 =A0 =A0 which require the services of the AODVv2 router for route= =0A>=A0 =A0 =A0 discovery and maintenance.=A0 An AODVv2 is always its own c= lient, so=0A>=A0 =A0 =A0 that the list of client IP addresses is never empt= y. corresponds=0A> =0A> UH> s/corresponds/Corresponds/=0A> =0A> =0A> =0A> P= erkins & Chakeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 [Page 5]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A> =0A> = =0A>=A0 =A0 =A0 to the AODVv2 router process currently performing a calcula= tion or=0A>=A0 =A0 =A0 processing a message.=0A> =0A> UH> I don't think it = is a good idea to introduce that terminology. It=0A> seems to be conflictin= g with the IP architecture of hosts and routers.=0A> Is a Router Client a h= ost?=0A> =0A>=A0 Flooding=0A>=A0 =A0 =A0 In this document, flooding a mess= age refers to the process of=0A>=A0 =A0 =A0 delivering the message to every= AODVv2 router in the network.=0A>=A0 =A0 =A0 This may be done according to= methods specified in [RFC5148].=0A> =0A> UH> RFC5148 describes jitter in M= ANETs, not flooding methods.=0A> =0A>=A0 Routable Unicast IP Address=0A>= =A0 =A0 =A0 A routable unicast IP address is a unicast IP address that when= =0A>=A0 =A0 =A0 put into the IP.SourceAddress or IP.DestinationAddress fiel= d is=0A> =0A> UH> Notation not defined: "IP.x"=0A> =0A>=A0 =A0 =A0 scoped s= ufficiently to be forwarded by a router.=0A> =0A> UH> I am not quite sure w= hat that means. Can you cite an RFC, maybe RFC4007?=0A> =0A>=A0 =A0 =A0 =A0= Globally-scoped=0A>=A0 =A0 =A0 unicast IP addresses and Unique Local Addre= sses (ULAs) [RFC6130]=0A>=A0 =A0 =A0 are examples of routable unicast IP ad= dresses.=0A> =0A> UH> RFC6130 is NHDP, not ULA. ULA's are not globally rout= able and=0A> cannot be accessed from outside a "site".=0A> =0A>=A0 Origina= ting Node (OrigNode)=0A>=A0 =A0 =A0 The originating node is the data source= node; if it is not itself=0A>=A0 =A0 =A0 an AODVv2 router, its AODVv2 rout= er creates a AODVv2 RREQ message=0A>=A0 =A0 =A0 on its behalf in an effort = to flood some routing information.=A0 The=0A>=A0 =A0 =A0 originating node i= s also referred to as a particular message's=0A>=A0 =A0 =A0 originator.=0A>= =0A>=A0 Target Node (TargetNode)=0A>=A0 =A0 =A0 The TargetNode denotes th= e ultimate destination of a message.=0A> =0A> UH> Is this for control packe= ts only or for data traffic? Is that an IP address?=0A> =0A>=A0 This Node = (ThisNode)=0A>=A0 =A0 =A0 ThisNode denotes the AODVv2 router currently proc= essing an AODVv2=0A>=A0 =A0 =A0 message.=0A> =0A>=A0 Route Error (RERR)=0A= >=A0 =A0 =A0 A RERR message is used to indicate that an AODVv2 router no lo= nger=0A>=A0 =A0 =A0 has a route to one or more particular destinations.=0A>= =0A> UH> Or it may have one, and data traffic was lost when sending it to= =0A> the next hop=0A> =0A>=A0 Route Reply (RREP)=0A>=A0 =A0 =A0 A RREP mes= sage is used to supply routing information about the=0A>=A0 =A0 =A0 RREQ Ta= rgetNode to the RREQ OrigNode and the AODVv2 routers=0A>=A0 =A0 =A0 between= them.=0A> =0A>=A0 Route Request (RREQ)=0A>=A0 =A0 =A0 An AODVv2 router us= es a RREQ message to discover a valid route to=0A>=A0 =A0 =A0 a particular = destination address, called the RREQ TargetNode.=0A>=A0 =A0 =A0 When an AOD= Vv2 router processes a RREQ, it learns routing=0A>=A0 =A0 =A0 information o= n how to reach the RREQ OrigNode.=0A> =0A>=A0 Type-Length-Value structure = (TLV)=0A>=A0 =A0 =A0 A generic way to represent information as specified in= [RFC5444].=0A> =0A> =0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 =A0 Exp= ires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 6]=0A> =0A> Inter= net-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 October 2012=0A> =0A> =0A>=A0 Unreachable Node (Unreacha= bleNode)=0A>=A0 =A0 =A0 An UnreachableNode is a node for which a forwarding= route is=0A>=A0 =A0 =A0 unknown.=0A> =0A> UH> Or to which data traffic has= been lost while forwarding to the next hop.=0A> =0A> =0A> 3.=A0 Applicabil= ity Statement=0A> =0A>=A0 The AODVv2 routing protocol is designed for stub= (i.e., non-transit)=0A>=A0 or disconnected (i.e., from the Internet) mobi= le ad hoc networks=0A>=A0 (MANETs).=A0 AODVv2 handles a wide variety of mo= bility patterns by=0A>=A0 dynamically determining routes on-demand.=A0 AOD= Vv2 also handles a wide=0A>=A0 variety of traffic patterns.=A0 In networks= with a large number of=0A>=A0 routers, AODVv2 is best suited for sparse t= raffic scenarios where any=0A>=A0 particular router forwards packets to on= ly a small percentage of the=0A>=A0 AODVv2 routers in the network, due to = the on-demand nature of route=0A>=A0 discovery and route maintenance.=0A> = =0A>=A0 AODVv2 is applicable to memory constrained devices, since little= =0A>=A0 routing state is maintained in each AODVv2 router.=A0 Only routing= =0A>=A0 information related to routes between active sources and destinati= ons=0A>=A0 is maintained, in contrast to proactive routing protocols that= =0A>=A0 require routing information to all routers within the routing regi= on=0A>=A0 be maintained.=0A> =0A>=A0 AODVv2 supports routers with multipl= e interfaces.=A0 In addition to=0A>=A0 routing for their local processes, = AODVv2 routers can also route on=0A>=A0 behalf of other non-routing nodes = (i.e., "hosts"), reachable via=0A>=A0 those interfaces.=A0 Any such node w= hich is not itself an AODVv2 router=0A>=A0 SHOULD NOT be served by more th= an one AODVv2 router.=0A> =0A> UH> I would rather not use RFC2119 in an app= licability statement. This=0A> is not normative.=0A> =0A>=A0 Although AODV= v2=0A>=A0 is closely related to AODV [RFC3561], and has some of the featur= es of=0A>=A0 DSR [RFC4728], AODVv2 is not interoperable with either of tho= se other=0A>=A0 two protocols.=0A> =0A>=A0 AODVv2 routers perform route d= iscovery to find a route to a=0A>=A0 particular destination.=A0 Therefore,= AODVv2 routers MUST must be=0A>=A0 configured to respond to RREQs for a c= ertain set of addresses.=A0 When=0A>=A0 AODVv2 is the only protocol intera= cting with the forwarding table,=0A>=A0 AODVv2 MAY be configured to perfor= m route discovery for all unknown=0A>=A0 unicast destinations.=0A> =0A>=A0= At all times within an AODVv2 routing region, only one AODVv2 router=0A>= =A0 SHOULD be serve any routing client.=A0 The coordination among multiple= =0A>=A0 AODVv2 routers to distribute routing information correctly for a= =0A>=A0 shared address (i.e. an address that is advertised and can be reac= hed=0A>=A0 via multiple AODVv2 routers) is not described in this document.= =A0 The=0A>=A0 AODVv2 router operation of shifting responsibility for a ro= uting=0A>=A0 client from one AODVv2 router to another is mentioned in Appe= ndix B=0A> =0A> UH> I am not sure that it is a good idea to include multi-h= oming in a=0A> short paragraph in Appendix B. I think this whole section ca= n be=0A> removed.=0A> =0A> =0A>=A0 Each AODVv2 router, if serving router c= lients other than itself, is=0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 = =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 7]=0A> = =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A> =0A> =0A>=A0 configured with= information about the IP addresses of its clients.=0A>=A0 There is no req= uirement that an AODVv2 router have information about=0A>=A0 the router cl= ients of other AODVv2 routers.=A0 Address assignment=0A>=A0 procedures are= entirely out of scope for AODVv2.=0A> =0A>=A0 AODVv2 only utilizes bidire= ctional links.=A0 In the case of possible=0A>=A0 unidirectional links, eit= her blacklists (see Section 5.13.2) or other=0A>=A0 means (e.g. adjacency = establishment with only neighboring routers=0A>=A0 that have bidirectional= communication as indicated by NHDP [RFC6130])=0A> =0A> UH> The blacklistin= g is not specified in this document.=0A> =0A>=A0 of ensuring and monitorin= g bi-directionality is recommended.=0A>=A0 Otherwise, persistent packet lo= ss could occur.=0A> =0A>=A0 The routing algorithm in AODVv2 may be operate= d at layers other than=0A>=A0 the network layer, using layer-appropriate a= ddresses.=0A> =0A> UH> Yes, but the whole document is limited to IP. It is = tied to IP=0A> headers, UDP etc at multiple places.=0A> =0A>=A0 =A0 The ro= uting=0A>=A0 algorithm makes=0A> =0A> UH> + "use"=0A> =0A>=A0 of some per= sistent state; if there is no persistent=0A>=A0 storage available for this= state, recovery can exact a performance=0A>=A0 penalty in case of AODVv2 = router reboots.=0A> =0A> =0A> 4.=A0 Data Structures=0A> =0A> UH> There is a= mixture between information bases and message formats.=0A> I would rather = have two seperate sections for that.=0A> UH> There are no other information= sets that I believe are required=0A> for AODV: blacklisted set, set of loc= al interfaces, and a set of the=0A> hosts that this router is responsible.= =0A> =0A> 4.1.=A0 Route Table Entry=0A> =0A>=A0 The route table entry is a= conceptual data structure.=0A>=A0 Implementations may use any internal re= presentation so long as it=0A>=A0 provides access to the same information = as specified below.=0A> =0A>=A0 Conceptually, a route table entry has the = following fields:=0A> =0A>=A0 Route.Address=0A>=A0 =A0 =A0 The (host or ne= twork) destination address of the node(s)=0A>=A0 =A0 =A0 associated with th= e routing table entry.=0A> =0A>=A0 Route.Prefix=0A>=A0 =A0 =A0 The value i= s the length of the netmask/prefix.=0A> =0A> UH> in octets?=0A> =0A>=A0 =A0= =A0 If the value of=0A>=A0 =A0 =A0 the Route.Prefix is different than the= length of addresses in the=0A>=A0 =A0 =A0 address family used by the AODVv= 2 routers, the associated address=0A>=A0 =A0 =A0 is a routing prefix, rathe= r than a host address.=0A> =0A>=A0 Route.SeqNum=0A>=A0 =A0 =A0 The AODVv2 = SeqNum associated with a route table entry.=0A> =0A>=A0 Route.NextHopAddre= ss=0A>=A0 =A0 =A0 An IP address of the adjacent AODVv2 router on the path t= oward the=0A>=A0 =A0 =A0 Route.Address.=0A> =0A> =0A> =0A> =0A> =0A> =0A> = =0A> Perkins & Chakeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 [Page 8]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A= > =0A> =0A>=A0 Route.NextHopInterface=0A>=A0 =A0 =A0 The interface used to= send packets toward the Route.Address.=0A> =0A>=A0 Route.Broken=0A>=A0 = =A0 =A0 A flag indicating whether this Route is broken.=A0 This flag is set= =0A>=A0 =A0 =A0 to true if the next-hop becomes unreachable or in response = to=0A>=A0 =A0 =A0 processing to a RERR (see Section 5.5.4).=0A> =0A>=A0 Th= e following field is optional:=0A> =0A>=A0 Route.Dist=0A>=A0 =A0 =A0 A dim= ensionless metric indicating the distance traversed before=0A>=A0 =A0 =A0 r= eaching the Route.Address node.=0A> =0A> UH> Why is this optional? It makes= the whole specification more=0A> complicated, in particular interoperabili= ty. I cannot imagine cases=0A> where you are not interested in the distance= .=0A> UH> Is this metric additive? is it only integer? is it used in=0A> ad= dition to hop-count or instead?=0A> =0A>=A0 Not including optional informa= tion may cause performance degradation,=0A>=A0 but it will not prohibit th= e protocol from discovering valid routes.=0A> =0A>=A0 In addition to a rou= te table data structure, each route table entry=0A>=A0 may have several ti= mers associated with the information.=A0 Timers and=0A>=A0 timeouts are di= scussed in Section 5.2.3.=0A> =0A> UH> That forward link makes it difficult= . Why not include the=0A> expiration timers here, similar to OLSRv2?=0A> = =0A> 4.2.=A0 AODVv2 Message Structure and Information Elements=0A> =0A>=A0 = IP Protocol Number 138 (manet) has been reserved for MANET protocols=0A>= =A0 [RFC5498].=A0 In addition to using this IP protocol number, AODVv2 may= =0A>=A0 use UDP at destination port 269 (manet) [RFC5498].=0A> =0A> UH> ma= y or MAY?=0A> =0A>=A0 AODVv2 messages are transmitted in packets that conf= orm to the=0A>=A0 generalized packet and message format as described in [R= FC5444].=0A>=A0 Here is a brief description of the format.=0A> =0A> =0A>= =A0 =A0 =A0 A packet formatted according to RFC5444 contains zero or more= =0A>=A0 =A0 =A0 messages.=0A> =0A> =0A>=A0 =A0 =A0 A message contains a mes= sage header, message TLV block, and zero=0A>=A0 =A0 =A0 or more address blo= cks.=0A> =0A> =0A>=A0 =A0 =A0 Each of the address blocks may also have an a= ssociated address TLV=0A>=A0 =A0 =A0 block.=0A> =0A> UH> Each address block= *must* have a TLV block (it may be empty though).=0A> =0A>=A0 All AODVv2 = messages SHOULD be sent using the IP protocol number (138)=0A>=A0 reserved= for manet protocols [RFC5498]; or the UDP destination port=0A>=A0 (269) r= eserved for manet protocols [RFC5498] and IP protocol number=0A>=A0 for UD= P.=0A> =0A> UH> That is redundant to the first paragraph of this section.= =0A> =0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 =A0 Expires April 26, 2= 013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 9]=0A> =0A> Internet-Draft=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= October 2012=0A> =0A> =0A>=A0 Most AODVv2 messages are sent with the IP = destination address set to=0A>=A0 the link-local multicast address LL-MANE= T-Routers [RFC5498] unless=0A>=A0 otherwise specified.=A0 Therefore, all A= ODVv2 routers SHOULD subscribe=0A>=A0 to LL-MANET-Routers [RFC5498] to rec= eiving AODVv2 messages.=A0 Note=0A>=A0 that multicast packets MAY be sent = via unicast.=0A> =0A> UH> That sounds confusing: multicast packets MAY be s= ent via unicast.=0A> First, what is a multicast packet? (you mean an IP pac= ket with a=0A> multicast destination address>). Why MAY?=0A> =0A>=A0 =A0 F= or example, this=0A>=A0 may occur for certain link-types (non broadcast me= diums), for=0A>=A0 manually configured router adjacencies, or in order to = improve=0A>=A0 robustness.=0A> =0A> UH> How would one manually configure a= router adjacency?=0A> =0A>=A0 When describing AODVv2 protocol messages, i= t is necessary to refer to=0A>=A0 fields in several distinct parts of the = overall packet.=0A> =0A> UH> Since there is an RFC5444 demultiplexer, AODVv= 2 would never see=0A> the packet. So I think it's better not to use that te= rm here.=0A> =0A>=A0 =A0 These=0A>=A0 locations include the IP header, the= UDP header, and fields from=0A>=A0 [RFC5444].=A0 This document uses the n= otational conventions found in=0A>=A0 table 1.=0A> =0A>=A0 =A0 =A0 =A0 =A0= =A0 +---------------------------+-------------------+=0A>=A0 =A0 =A0 =A0 = =A0 =A0 |=A0 =A0 Information Location=A0 | Notational Prefix |=0A>=A0 =A0= =A0 =A0 =A0 =A0 +---------------------------+-------------------+=0A>=A0 = =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 IP header=A0 =A0 =A0 =A0 |=A0 =A0 = =A0 =A0 IP.=A0 =A0 =A0 =A0 |=0A>=A0 =A0 =A0 =A0 =A0 =A0 |=A0 RFC5444 mess= age header=A0 |=A0 =A0 =A0 MsgHdr.=A0 =A0 =A0 |=0A>=A0 =A0 =A0 =A0 =A0 =A0 = |=A0 =A0 RFC5444 message TLV=A0 =A0 |=A0 =A0 =A0 MsgTLV.=A0 =A0 =A0 |=0A>= =A0 =A0 =A0 =A0 =A0 =A0 |=A0 RFC5444 address blocks=A0 |=A0 =A0 =A0 AddBl= k.=A0 =A0 =A0 |=0A>=A0 =A0 =A0 =A0 =A0 =A0 | RFC5444 address block TLV |= =A0 =A0 =A0 AddTLV.=A0 =A0 =A0 |=0A>=A0 =A0 =A0 =A0 =A0 =A0 +-------------= --------------+-------------------+=0A> =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Table 1=0A> =0A>=A0 The IPv4 TTL (IPv= 6 Hop Limit) field for all packets containing AODVv2=0A>=A0 messages is se= t to 255.=0A> =0A> UH> I think that's the job of the RFC5444 multiplexer.= =0A> =0A>=A0 =A0 If a packet is received with a value other=0A>=A0 than 25= 5, any AODVv2 message contained in the packet MUST be ignored=0A>=A0 by AO= DVv2.=0A> =0A> UH> No, the packet would never be received by AODVv2. Only a= message would.=0A> =0A>=A0 =A0 This mechanism, known as "The Generalized = TTL Security=0A>=A0 Mechanism" (GTSM) [RFC5082] helps to ensure that packe= ts have not=0A>=A0 traversed any intermediate routers.=0A> =0A> UH> Again,= part of the RFC5444 multiplexer.=0A> =0A>=A0 The length of an address (32= bits for IPv4 and 128 bits for IPv6)=0A>=A0 inside an AODVv2 message depe= nds on the msg-addr-length (MAL) in the=0A>=A0 msg-header, as specified in= [RFC5444].=0A> =0A> UH> Limitation of AODVv2 to IP addresses. It could als= o be used for=0A> compressed (lowpan) addresses or MAC addresses.=0A> =0A>= =A0 IP packets containing AODVv2 protocol messages SHOULD be given=0A>=A0 = priority queuing and channel access.=0A> =0A> UH> Not the task of AODVv2, = but the RFC5444 multiplexer=0A> =0A>=A0 AODVv2 messages require the follow= ing information:=0A> =0A>=A0 IP.SourceAddress=0A>=A0 =A0 =A0 The IP addres= s of the node currently sending this packet.=A0 This=0A>=A0 =A0 =A0 field i= s generally filled automatically by the operating system=0A>=A0 =A0 =A0 and= should not require special handling.=0A> =0A> UH> An AODVv2 message cannot= have an IP address. That's a different=0A> layer. The IP packet that conta= ins an RFC5444 packet (which the IP=0A> layer received from the RFC5444 mul= tiplexer) has that address.=0A> Also, it is not necessarily the node curren= tly sending this "packet";=0A> ThisNode could receive a message, then it is= not sending this packet.=0A> =0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0= =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 10]=0A> = =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A> =0A> =0A>=A0 IP.DestinationA= ddress=0A>=A0 =A0 =A0 The IP address of the packet destination.=A0 For mult= icast messages=0A>=A0 =A0 =A0 the IP.DestinationAddress is set to LL-MANET-= Routers [RFC5498].=0A>=A0 =A0 =A0 For unicast messages the IP.DestinationAd= dress is set to the=0A>=A0 =A0 =A0 NextHopAddress toward the TargetNode.=0A= > =0A>=A0 MsgHdr.HopLimit=0A>=A0 =A0 =A0 The remaining number of hops this= message is allowed to traverse.=0A>=A0 =A0 =A0 If an AODVv2 message within= a RFC 5444 packet has exhausted its=0A>=A0 =A0 =A0 hop limit, then it shou= ld be removed from the packet.=0A> =0A> UH> This seems to be mixing normati= ve protocol behavior with field=0A> definitions.=0A> =0A> 4.3.=A0 RteMsg-sp= ecific Protocol Elements=0A> =0A>=A0 AODVv2 message types RREQ and RREP ar= e denoted as Routing Messages=0A>=A0 (RteMsgs) and used to flood routing i= nformation.=0A> =0A> UH> RREPs are not flooded.=0A> =0A>=A0 =A0 RREQ and R= REP have=0A>=A0 similar information and function, but have slightly differ= ent=0A>=A0 handling rules.=A0 The main difference between the two messages= is that=0A>=A0 RREQ messages are generally broadcast to solicit a RREP, a= nd=0A>=A0 conversely a RREP is the unicast response to RREQ.=A0 RteMsg cre= ation=0A>=A0 and handling are described in Section 5.3.=0A> =0A>=A0 Unica= st AODVv2 RteMsgs (e.g.=A0 RREP) unless otherwise specified are=0A>=A0 sen= t with the IP destination set to the Route.NextHopAddress of the=0A>=A0 ro= ute to the TargetNode.=0A> =0A>=A0 A RteMsg REQUIRES the following informa= tion in addition to the fields=0A>=A0 indicated in Section 4.2:=0A> =0A> U= H> REQUIRES is not RFC2110, it's REQUIRED=0A> =0A>=A0 AddBlk.TargetNode.Ad= dress=0A>=A0 =A0 =A0 The IP address of the message TargetNode.=A0 In a RREQ= the IP=0A>=A0 =A0 =A0 address of the message TargetNode is the destination= address for=0A>=A0 =A0 =A0 which route discovery is being performed.=A0 In= a RREP the=0A>=A0 =A0 =A0 TargetNode is the RREQ OrigNode address.=A0 The = TargetNode address=0A>=A0 =A0 =A0 is the first address in a routing message= .=0A> =0A> UH> I don't think it's a good idea to mandate order of addresses= .=0A> Other extensions to the protocol may add addresses before. It would b= e=0A> better to associate with an address block TLV.=0A> =0A>=A0 AddBlk.Or= igNode.Address=0A>=A0 =A0 =A0 The IP address of the originator and its asso= ciated prefix length.=0A>=A0 =A0 =A0 In a RREQ the OrigNode is the source's= address and prefix.=A0 In a=0A>=A0 =A0 =A0 RREP the OrigNode is the RREQ T= argetNode's address and prefix for=0A>=A0 =A0 =A0 which a RREP is being gen= erated.=A0 This address is the second=0A>=A0 =A0 =A0 address in the message= for RREQ.=0A> =0A> UH> Again, mandating address order is dangerous.=0A> = =0A>=A0 OrigNode.AddTLV.SeqNum=0A>=A0 =A0 =A0 The AODVv2 sequence number o= f the originator's AODVv2 router.=0A> =0A> UH> Why not use the message sequ= ence number? This will save several=0A> bytes. Or at least a message TLV.= =0A> =0A>=A0 A RteMsg may optionally include the following information:=0A= > =0A> =0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 =A0 Expires April 26,= 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 11]=0A> =0A> Internet-Draft=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 October 2012=0A> =0A> =0A>=A0 TargetNode.AddTLV.SeqNum=0A>=A0 =A0 =A0= The last known AODVv2 sequence number of the TargetNode.=0A> =0A> UH> Usin= g which TLV type? (reference to IANA section)=0A> =0A>=A0 AddBlk.Additiona= lNode.Address=0A>=A0 =A0 =A0 The IP address of an additional node that can = be reached via the=0A>=A0 =A0 =A0 AODVv2 router adding this information.=A0= Each=0A>=A0 =A0 =A0 AdditionalNode.Address MUST include its prefix.=A0 Eac= h=0A>=A0 =A0 =A0 AdditionalNode.Address MUST also have an associated Node.S= eqNum in=0A>=A0 =A0 =A0 the address TLV block.=0A> =0A> UH> Is Node.foo def= ined before?=0A> =0A>=A0 AdditionalNode.AddTLV.SeqNum=0A>=A0 =A0 =A0 The A= ODVv2 sequence number associated with this routing=0A>=A0 =A0 =A0 informati= on.=0A> =0A> UH> What is AdditionalNode?=0A> =0A>=A0 OrigNode.AddTLV.Dist= =0A>=A0 =A0 =A0 A metric of the distance to reach the associated OrigNode.A= ddress.=0A>=A0 =A0 =A0 This field is incremented by at least one at each in= termediate=0A>=A0 =A0 =A0 AODVv2 router.=0A> =0A> UH> Why not use a message= TLV?=0A> =0A>=A0 AdditionalNode.AddTLV.Dist=0A>=A0 =A0 =A0 A metric of th= e distance to reach the associated=0A>=A0 =A0 =A0 AdditionalNode.Address.= =A0 This field is incremented by at least one=0A>=A0 =A0 =A0 at each interm= ediate AODVv2 router.=0A> =0A> 4.4.=A0 Route Error (RERR)-specific Protocol= Elements=0A> =0A>=A0 A RERR message is used to flood the information that= a route is not=0A>=A0 available for one or more particular addresses.=0A>= =0A> UH> RERR are mostly sent unicast, not flooded.=0A> =0A>=A0 RERR crea= tion and handling are described in Section 5.5.=0A> =0A>=A0 A RERR require= s the following information in addition to the field=0A>=A0 indicated in S= ection 4.2:=0A> =0A>=A0 AddBlk.UnreachableNode.Address=0A>=A0 =A0 =A0 The = address of an UnreachableNode and its associated prefix=0A>=A0 =A0 =A0 leng= th.=A0 Multiple unreachable addresses may be included in a RERR.=0A> =0A>= =A0 A Route Error may optionally include the following information:=0A> = =0A>=A0 UnreachableNode.AddTLV.SeqNum=0A>=A0 =A0 =A0 The last known AODVv2= sequence number of the unreachable node.=A0 If=0A>=A0 =A0 =A0 a SeqNum for= an address is zero (0) or not included, it is assumed=0A>=A0 =A0 =A0 to be= unknown.=A0 This case occurs when a node receives a message to=0A>=A0 =A0 = =A0 forward to a destination for which it does not have any=0A>=A0 =A0 =A0 = information in its routing table.=0A> =0A> =0A> =0A> =0A> =0A> Perkins & Ch= akeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [P= age 12]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A> =0A> =0A> 5.=A0 D= etailed Operation for the Base Protocol=0A> =0A> 5.1.=A0 AODVv2 Sequence Nu= mbers=0A> =0A>=A0 AODVv2 sequence numbers allow AODVv2 routers to judge th= e freshness=0A>=A0 of routing information and consequently ensure loop fre= edom.=0A> =0A> 5.1.1.=A0 Maintaining A Node's Own Sequence Number=0A> =0A>= =A0 AODVv2 requires that each AODVv2 router in the network maintain its=0A= >=A0 own AODVv2 sequence number (OwnSeqNum).=A0 OwnSeqNum a 16-bit unsigne= d=0A>=A0 integer.=A0 An AODVv2 router increments its OwnSeqNum under the= =0A>=A0 circumstances described in Section 5.3.=0A> =0A>=A0 Incrementing = an OwnSeqNum whose value is the largest largest possible=0A>=A0 number rep= resentable as a 16-bit unsigned integer (i.e., 65,535),=0A>=A0 MUST be set= to one (1).=A0 In other words, the sequence number after=0A>=A0 65,535 is= 1.=0A> =0A> 5.1.2.=A0 Actions After OwnSeqNum Loss=0A> =0A>=A0 An AODVv2 = router SHOULD maintain its own sequence number in=0A>=A0 persistent storag= e.=0A> =0A>=A0 If an AODVv2 router's OwnSeqNum is lost, it MUST take certa= in actions=0A>=A0 to avoid creating routing loops.=A0 To prevent this poss= ibility after=0A>=A0 OwnSeqNum loss an AODVv2 router MUST wait for at leas= t=0A>=A0 ROUTE_DELETE_TIMEOUT before fully participating in the AODVv2 rou= ting=0A>=A0 protocol.=A0 If an AODVv2 protocol message is received during = this=0A>=A0 waiting period, the AODVv2 router SHOULD perform normal route = table=0A>=A0 entry updates but MUST NOT transmit or retransmit any AODVv2 = RREQ or=0A>=A0 RREP messages.=A0 If a data packet is received for forwardi= ng to=0A>=A0 another destination during this waiting period, the AODVv2 ro= uter=0A>=A0 MUST transmit a RERR message indicating that this route is not= =0A>=A0 available and reset its waiting timeout.=A0 At the end of the wait= ing=0A>=A0 period the AODVv2 router sets its OwnSeqNum to one (1) and begi= n=0A>=A0 participating.=0A> =0A>=A0 The longest a node need wait is ROUTE= _SEQNUM_AGE_MAX_TIMEOUT.=A0 At the=0A>=A0 end of the maximum waiting perio= d a node SHOULD set its OwnSeqNum to=0A>=A0 one (1) and begins participati= ng.=0A> =0A> 5.2.=A0 AODVv2 Routing Table Operations=0A> =0A> UH> This whol= e structure is unclear. Where do we come to this?=0A> Wouldn't it be better= to start of with message generation/processing=0A> before saying how to up= date the routing tuples as a consequence to=0A> received messages?=0A> =0A>= 5.2.1.=A0 Judging Routing Information's Usefulness=0A> =0A>=A0 Given a ro= ute table entry (Route.SeqNum, Route.Dist, and=0A>=A0 Route.Broken)=0A> = =0A> UH> A route table entry has more fields in section 4.1=0A> =0A>=A0 an= d incoming routing information for a particular=0A> =0A> =0A> =0A> Perkins = & Chakeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 [Page 13]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A= ODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A> =0A> =0A>=A0= destination in a RteMsg (Node.SeqNum, Node.Dist, and RteMsg message=0A>= =A0 type - RREQ/RREP), the incoming routing information is classified as= =0A>=A0 follows:=0A> =0A>=A0 1. Stale (Node.SeqNum < Route.SeqNum)=0A>=A0= =A0 =A0 If Node.SeqNum < Route.SeqNum (using signed 16-bit arithmetic) the= =0A>=A0 =A0 =A0 incoming information is stale.=A0 Using stale routing infor= mation is=0A>=A0 =A0 =A0 not allowed, since that might result in routing lo= ops.=0A> =0A> UH> So what should my implementation then? Continue with the = next=0A> step? Discard the message?=0A> =0A>=A0 2. Not safe against loops= =0A>=A0 =A0 =A0 If Node.SeqNum =3D=3D Route.SeqNum, additional information = MUST be=0A>=A0 =A0 =A0 examined.=A0 If Route.Dist or Node.Dist is unknown o= r zero (0), or=0A>=A0 =A0 =A0 if Node.Dist > Route.Dist + 1, then the incom= ing information is=0A>=A0 =A0 =A0 not guaranteed to prevent routing loops.= =A0 Using such incoming=0A>=A0 =A0 =A0 routing information is not allowed.= =A0 The following pseudocode is=0A>=A0 =A0 =A0 offered to indicate the logi= cal condition under which the incoming=0A>=A0 =A0 =A0 information is not gu= aranteed to protect against loops.=0A> =0A>=A0 =A0 =A0 (Node.SeqNum =3D=3D = Route.SeqNum) AND=0A>=A0 =A0 =A0 ((Node.Dist > Route.Dist + 1) OR=0A> =0A> = UH> Would cause a null-pointer exception in my implementation if Dist=0A> i= s not contained in the message.=0A> =0A>=A0 =A0 =A0 (Route.Dist is unknown= ) OR (Node.Dist is unknown))=0A> =0A>=A0 3. Offers no improvement=0A>=A0 = =A0 =A0 In case of known equal SeqNum, the information is considered worse= =0A>=A0 =A0 =A0 than the existing route table information in multiple cases= : (case=0A>=A0 =A0 =A0 i) if Node.Dist > Route.Dist (it is a more expensive= route) AND=0A>=A0 =A0 =A0 Route.Broken =3D=3D false; (case ii) if Node.Dis= t =3D=3D Route.Dist (equal=0A>=A0 =A0 =A0 distance route) AND Route.Broken = =3D=3D false AND this RteMsg is a=0A>=A0 =A0 =A0 RREQ.=A0 Such RREQs offer = no improvement and SHOULD NOT be=0A>=A0 =A0 =A0 retransmitted.=A0 Updating = route table entries using such incoming=0A>=A0 =A0 =A0 routing information = is not allowed.=0A> =0A>=A0 =A0 =A0 ((Node.SeqNum =3D=3D Route.SeqNum) AND= =0A>=A0 =A0 =A0 =A0 =A0 (((Node.Dist > Route.Dist) AND (Route.Broken =3D=3D= false)) OR=0A>=A0 =A0 =A0 =A0 =A0 =A0 ((Node.Dist =3D=3D Route.Dist) AND= =0A>=A0 =A0 =A0 =A0 =A0 =A0 (RteMsg is RREQ) AND (Route.Broken =3D=3D fals= e))))=0A> =0A>=A0 4. Offers improvement=0A>=A0 =A0 =A0 Incoming routing in= formation that does not match any of the above=0A>=A0 =A0 =A0 criteria is l= oop-free and better than the existing routing table=0A>=A0 =A0 =A0 informat= ion.=A0 We provide the following pseudo-code to determine=0A>=A0 =A0 =A0 wh= ether incoming routing information should be used to update an=0A>=A0 =A0 = =A0 existing route table entry.=0A> =0A>=A0 =A0 =A0 (/* signed 16-bit arith= metic */ Node.SeqNum - Route.SeqNum > 0) OR=0A>=A0 =A0 =A0 ((Node.SeqNum = =3D=3D Route.SeqNum) AND=0A>=A0 =A0 =A0 =A0 =A0 [(Node.Dist < Route.Dist) O= R=0A>=A0 =A0 =A0 =A0 =A0 ((Route.Broken =3D=3D true) AND (Node.Dist <=3D Ro= ute.Dist + 1)) OR=0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 =A0 Expires= April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 14]=0A> =0A> Internet-= Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 October 2012=0A> =0A> =0A>=A0 =A0 =A0 =A0 =A0 ((RteMsg is RRE= P) AND (Node.Dist =3D=3D Route.Dist)]=0A> =0A> 5.2.2.=A0 Creating or Updati= ng Route Table Entries=0A> =0A>=A0 Each route table entry is populated wit= h the following information:=0A> =0A> UH> Why "each" entry? When does this = happen? It seems this only sets=0A> the route to the previous hop; what hap= pens with a route to the=0A> originator? What happens if a route already ex= ists and is only=0A> updated? How are both forward and reverse routes updat= ed?=0A> =0A>=A0 1.=A0 the Route.Address is set to Node.Address,=0A> =0A>= =A0 2.=A0 the Route.Prefix is set to the Node.Prefix.=0A> =0A>=A0 3.=A0 t= he Route.SeqNum is set to the Node.SeqNum,=0A> =0A>=A0 4.=A0 the Route.Nex= tHopAddress is set to the IP.SourceAddress (i.e., an=0A>=A0 =A0 =A0 addres= s of the node that last transmitted the RteMsg packet)=0A> =0A>=A0 5.=A0 t= he Route.NextHopInterface is set to the interface on which the=0A>=A0 =A0 = =A0 incoming AODVv2 packet was received,=0A> =0A>=A0 6.=A0 the Route.Brok= en flag is set to false,=0A> =0A>=A0 7.=A0 if known, the Route.Dist is set= to the Node.Dist,=0A> =0A>=A0 The timer for the minimum delete timeout (R= OUTE_AGE_MIN) is set to=0A>=A0 ROUTE_AGE_MIN_TIMEOUT.=A0 The timer for the= maximum delete timeout=0A>=A0 (ROUTE_SEQNUM_AGE_MAX) is set to Node.AddTL= V.VALIDITY_TIME [RFC5497]=0A>=A0 if included; otherwise, ROUTE_SEQNUM_AGE_= MAX is set to=0A>=A0 ROUTE_SEQNUM_AGE_MAX_TIMEOUT.=A0 The usage of these t= imers and others=0A>=A0 are described in Section 5.2.3.=0A> =0A> UH> I don= 't understand how a sequence number can expire. Also, in=0A> section 4.1 th= ere was no mention of the VALIDITY_TIME Tlv in a=0A> message. What happens = if it is not contained?=0A> =0A>=A0 With these assignments to the route ta= ble entry, a route has been=0A>=A0 created and the Route.Forwarding flag s= et.=A0 Afterward, the route can=0A>=A0 be used to send any buffered data p= ackets and to forward any incoming=0A>=A0 data packets for Route.Address.= =A0 This route also fulfills any=0A>=A0 outstanding route discovery (RREQ)= attempts for Node.Address.=0A> =0A> 5.2.3.=A0 Route Table Entry Timeouts= =0A> =0A> 5.2.3.1.=A0 Minimum Delete Timeout (ROUTE_AGE_MIN)=0A> =0A>=A0 W= hen an AODVv2 router transmits a RteMsg, other AODVv2 routers expect=0A>=A0= the transmitting AODVv2 router to have a forwarding route to the=0A>=A0 = RteMsg originator.=A0 A route table entry SHOULD be kept in the route=0A>= =A0 table for at least ROUTE_AGE_MIN after it has been updated.=A0 Failure= =0A>=A0 to maintain the route table entry might result in lost messages/= =0A>=A0 packets, or several duplicate messages.=0A> =0A>=A0 After the ROU= TE_AGE_MIN timeout a route can safely be deleted.=0A> =0A> =0A> =0A> =0A> P= erkins & Chakeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 [Page 15]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A> =0A> = =0A> 5.2.3.2.=A0 Maximum Sequence Number Delete Timeout (ROUTE_SEQNUM_AGE_M= AX)=0A> =0A>=A0 Sequence number information for route table entries is tim= e=0A>=A0 sensitive, and MUST be deleted after a time in order to ensure lo= op-=0A>=A0 free routing.=0A> =0A>=A0 After the ROUTE_SEQNUM_AGE_MAX timeo= ut a route's sequence number=0A>=A0 information MUST be discarded.=0A> =0A= > UH> What does it mean to discard a sequence number information? To set=0A= > it to zero in the route entry? What are the relationships between=0A> ROU= TE_SEQNUM_AGE_MUX and ROUTE_AGE_MIN? (can one be smaller than the=0A> other= )=0A> =0A> 5.2.3.3.=A0 Recently Used Timeout (ROUTE_USED)=0A> =0A>=A0 When= a route is used to forward data packets, this timer is set to=0A>=A0 expi= re after ROUTE_USED_TIMEOUT, as discussed in Section 5.5.2.=0A> =0A>=A0 If= a route has not been used recently, then a timer for ROUTE_DELETE=0A>=A0 = is set to ROUTE_DELETE_TIMEOUT.=0A> =0A> 5.2.3.4.=A0 Delete Information Tim= eout (ROUTE_DELETE)=0A> =0A>=A0 As time progresses the likelihood that old= routing information is=0A>=A0 useful decreases, especially if the network= nodes are mobile.=0A>=A0 Therefore, old information SHOULD be deleted.=0A= > =0A>=A0 After the ROUTE_DELETE timeout if a forwarding route exists it S= HOULD=0A>=A0 be removed, and the routing table entry SHOULD also be delete= d.=0A> =0A> UH> There are quite a few timers, which is confusing. What happ= ens if=0A> one timer fires before the other? Do we really need that many ti= mers?=0A> =0A> 5.3.=A0 Routing Messages=0A> =0A> 5.3.1.=A0 RREQ Creation=0A= > =0A>=A0 Before an AODVv2 router creates a RREQ it SHOULD increment its= =0A>=A0 OwnSeqNum by one (1) according to the rules specified in Section 5= .1.=0A> =0A> UH> Why not MUST? What happens if one does not increase it. In= =0A> general, there are many SHOULDs in the document, which probably should= =0A> be MUSTs.=0A> =0A>=A0 Incrementing OwnSeqNum will ensure that all nod= es with existing=0A>=A0 routing information will consider this new informa= tion preferable to=0A>=A0 existing routing table information.=A0 If the se= quence number is not=0A>=A0 incremented, certain AODVv2 routers might not = consider this=0A>=A0 information preferable, if they have existing better = routing=0A>=A0 information.=0A> =0A>=A0 First, ThisNode adds the AddBlk.T= argetNode.Address to the RREQ; the=0A>=A0 unicast IP Destination Address f= or which a forwarding route does not=0A>=A0 exist.=0A> =0A>=A0 If a previ= ous value of the TargetNode.SeqNum is known (from a routing=0A>=A0 table e= ntry using longest-prefix matching), it SHOULD be placed in=0A>=A0 TargetN= ode.AddTLV.SeqNum in all but the last RREQ attempt.=A0 If a=0A>=A0 TargetN= ode.SeqNum is not included, it is assumed to be unknown by=0A>=A0 handling= nodes.=A0 This operation ensures that no intermediate AODVv2=0A> =0A> =0A>= =0A> Perkins & Chakeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 [Page 16]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A= > =0A> =0A>=A0 routers reply, and ensures that the TargetNode's AODVv2 rou= ter=0A>=A0 increments its sequence number.=0A> =0A>=A0 Next, ThisNode add= s AddBlk.OrigNode.Address, its prefix, and the=0A>=A0 OrigNode.AddTLV.SeqN= um (OwnSeqNum) to the RteMsg.=0A> =0A>=A0 The OrigNode.Address is the addr= ess of the source for which this=0A>=A0 AODVv2 router is initiating this r= oute discovery.=A0 The=0A>=A0 OrigNode.Address MUST be a unicast address.= =A0 This information will be=0A>=A0 used by nodes to create a route toward= the OrigNode, enabling=0A>=A0 delivery of a RREP, and eventually used for= proper forwarding of data=0A>=A0 packets.=0A> =0A>=A0 If OrigNode.Dist i= s included it is set to a number, greater than zero=0A>=A0 (0), representi= ng the distance between OrigNode and ThisNode.=0A> =0A>=A0 The MsgHdr.HopL= imit SHOULD be set to MSG_HOPLIMIT.=0A> =0A> UH> Why SHOULD?=0A> =0A> 5.3.2= .=A0 RREP Creation=0A> =0A>=A0 First, the AddBlk.TargetNode.Address is add= ed to the RREP.=A0 The=0A>=A0 TargetNode is the ultimate destination of th= is RREP; the RREQ=0A>=A0 OrigNode.Address.=0A> =0A>=A0 Next, AddBlk.OrigN= ode.Address and prefix are added to the RREP.=A0 The=0A>=A0 AddBlk.OrigNod= e.Address is the RREQ TargetNode.Address.=A0 The=0A>=A0 AddBlk.OrigNode.Ad= dress MUST be a unicast IP address.=A0 ThisNode=0A>=A0 SHOULD advertise th= e largest known prefix containing=0A>=A0 AddBlk.OrigNode.Address.=0A> =0A>= =A0 When the RteMsg TargetNode's AODVv2 router creates a RREP, if the=0A>= =A0 TargetNode.SeqNum was not included in the RREQ, ThisNode MUST=0A>=A0 = increment its OwnSeqNum by one (1) according to the rules specified=0A>=A0 = in Section 5.1.=0A> =0A>=A0 If TargetNode.SeqNum was included in the RteM= sg and TargetNode.SeqNum=0A>=A0 - OwnSeqNum < 0 (using signed 16-bit arith= metic), OwnSeqNum SHOULD be=0A>=A0 incremented by one (1) according to the= rules specified in=0A>=A0 Section 5.1.=0A> =0A>=A0 If TargetNode.SeqNum = is included in the RteMsg and TargetNode.SeqNum=0A>=A0 =3D=3D OwnSeqNum (u= sing signed 16-bit arithmetic) and OrigNode.Dist will=0A>=A0 not be includ= ed in the RREP being generated, OwnSeqNum SHOULD be=0A>=A0 incremented by = one (1) according to the rules specified in=0A>=A0 Section 5.1.=0A> =0A>= =A0 If OwnSeqNum is not incremented the routing information might be=0A>= =A0 considered stale.=A0 In this case, the RREP might not reach the RREP= =0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 =A0 Expires April 26, 2013= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 17]=0A> =0A> Internet-Draft=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = October 2012=0A> =0A> =0A>=A0 Target.=0A> =0A>=A0 After any of the seque= nce number operations above, the RREP=0A>=A0 OrigNode.AddTLV.SeqNum (OwnSe= qNum) MUST also be added to the RREP.=0A> =0A>=A0 Other AddTLVs in the RRE= P for the OrigNode and TargetNode SHOULD be=0A>=A0 included and set accord= ingly.=A0 If OrigNode.Dist is included it is set=0A>=A0 to a number greate= r than zero (0) and less than or equal to 254.=A0 The=0A>=A0 Distance valu= e will influence judgment of the routing information=0A>=A0 (Section 5.2.1= ) against known information at other AODVv2 routers=0A>=A0 that handle thi= s RteMsg.=0A> =0A>=A0 The MsgHdr.HopLimit is set to MSG_HOPLIMIT.=0A> =0A>= =A0 The IP.DestinationAddress for RREP is set to the IP address of the=0A>= =A0 Route.NextHopAddress for the route to the RREP TargetNode.=0A> =0A> 5.= 3.3.=A0 RteMsg Handling=0A> =0A> UH> Very difficult to parse this section. = Not much RFC2119 language.=0A> =0A> UH> Is there any check for invalid mess= ages (similar to OLSRv2/NHDP?)=0A> External mechanisms should be allowed to= add reasons to reject a=0A> message as invalid, e.g. a security mechanism.= =0A> =0A>=A0 First, ThisNode examines the RteMsg to ensure that it contain= s the=0A>=A0 required information: MsgHdr.HopLimit, AddBlk.TargetNode.Addr= ess,=0A>=A0 AddBlk.OrigNode.Address, and OrigNode.AddTLV.SeqNum.=A0 If the= required=0A>=A0 information does not exist, the message is discarded and = further=0A>=A0 processing stopped.=0A> =0A>=A0 ThisNode MUST only handle = AODVv2 messages from adjacent routers.=0A> =0A> UH> What does that mean?=0A= > =0A>=A0 ThisNode checks if the AddBlk.OrigNode.Address is a valid routab= le=0A>=A0 unicast address.=0A> =0A> UH> How?=0A> =0A>=A0 =A0 If not, the m= essage is ignored and further=0A>=A0 processing stopped.=0A> =0A>=A0 This= Node also checks whether AddBlk.OrigNode.Address is an address=0A>=A0 hand= led by this AODVv2 router.=0A> =0A> UH> How?=0A> =0A>=A0 =A0 If this node = is the originating=0A>=A0 AODVv2 router, the RteMsg is dropped.=0A> =0A> U= H> Why not do this further above, before doing all the other checks?=0A> = =0A>=A0 ThisNode checks if the AddBlk.TargetNode.Address is a valid routab= le=0A>=A0 unicast address.=A0 If the address is not a valid unicast addres= s, the=0A>=A0 message is discarded and further processing stopped.=0A> =0A= >=A0 Next, ThisNode checks whether its routing table has an entry to the= =0A>=A0 AddBlk.OrigNode.Address using longest-prefix matching [RFC1812].= =0A> =0A> UH> RFC1812 is IPv4 only.=0A> =0A>=A0 =A0 If=0A>=A0 a route wit= h a valid Route.SeqNum does not exist,=0A> =0A> UH> What is a "valid" seque= nce number?=0A> =0A>=A0 then the new=0A>=A0 routing information is used t= o create a new route table entry is=0A>=A0 created=0A> =0A> UH> to "create= " ... is "created"=0A> =0A>=A0 and updated as described in Section 5.2.2.= =0A> =0A> UH> This jumping back is difficult to parse.=0A> =0A>=A0 =A0 If a= route table=0A>=A0 entry does exists and it has a known Route.SeqNum, the= incoming=0A>=A0 routing information is compared with the route table entr= y following=0A>=A0 the procedure described in Section 5.2.1.=A0 If the inc= oming routing=0A>=A0 information is considered preferable, the route table= entry is=0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 =A0 Expires April 2= 6, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 18]=0A> =0A> Internet-Draft=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 October 2012=0A> =0A> =0A>=A0 updated as described in Section 5.2.2.= =0A> =0A>=A0 At this point, if the routing information for the OrigNode wa= s not=0A>=A0 preferable then this RteMsg SHOULD be discarded and no furthe= r=0A>=A0 processing of this message SHOULD be performed.=0A> =0A> UH> Why = SHOULD? Why not MUST?=0A> =0A>=A0 If the TargetNode is a router client of = ThisNode this RteMsg is a=0A>=A0 RREQ, then ThisNode responds with a RREP = to the RREQ OrigNode (the=0A>=A0 new RREP's TargetNode).=A0 The procedure = for issuing a new RREP is=0A>=A0 described in Section 5.3.2.=A0 Afterwards= , ThisNode need not perform=0A>=A0 any more operations for the RteMsg bein= g processed.=0A> =0A>=A0 As an alternative to issuing a RREP, ThisNode MAY= choose to=0A>=A0 distribute routing information about ThisNode (the RREQ = TargetNode)=0A>=A0 more widely.=A0 That is, ThisNode MAY optionally perfor= m a route=0A>=A0 discovery by issuing a RREQ with ThisNode listed as the T= argetNode,=0A>=A0 using the procedure in Section 5.3.1.=A0 At this point, = ThisNode need=0A>=A0 not perform any more operations for the RteMsg being = processed.=0A> =0A> UH> I don't understand the last paragraph. Is this some= remainder of=0A> intermediate route reply? In which conditions should a ro= uter send a=0A> RREQ instead of a RREP?=0A> =0A> =0A>=A0 For each address = (except the TargetNode) in the RteMsg that includes=0A>=A0 AddTLV.Dist inf= ormation, the AddTLV.Dist information is incremented=0A>=A0 by at least on= e (1).=0A> =0A> UH> By how much then?=0A> =0A>=A0 =A0 The updated Distance= value will influence=0A>=A0 judgment of the routing information (Section = 5.2.1) against known=0A>=A0 information at other AODVv2 routers that handl= e this RteMsg.=0A> =0A>=A0 If the resulting Distance value for the OrigNod= e is greater than 254,=0A>=A0 the message is discarded.=A0 If the resultin= g Distance value for=0A>=A0 another node is greater than 254,=0A> =0A> UH>= Which other node?=0A> =0A>=A0 the associated address and its=0A>=A0 info= rmation are removed from the RteMsg.=0A> =0A> UH> That makes end-to-end sec= urity impossible.=0A> =0A>=A0 If the MsgHdr.HopLimit is=0A>=A0 equal to o= ne (1), then the message is discarded.=A0 Otherwise, the=0A>=A0 MsgHdr.Hop= Limit is decremented by one (1).=0A> =0A>=A0 If ThisNode is not the Target= Node, AND this RteMsg is a RREQ, then=0A>=A0 the current RteMsg (as altere= d by the procedure defined above) SHOULD=0A>=A0 be sent to the IP multicas= t address LL-MANET-Routers [RFC5498].=A0 If=0A>=A0 the RREQ is unicast, th= e IP.DestinationAddress is set to the=0A>=A0 NextHopAddress.=0A> =0A> UH> = The unicast RREQ mechanism is not really explained anywhere. Where=0A> is t= he nexthopaddress acquired from?=0A> =0A> =0A>=A0 If ThisNode is not the T= argetNode, AND this RteMsg is a RREP, then=0A>=A0 the current RteMsg is se= nt to the Route.NextHopAddress for the RREP's=0A>=A0 TargetNode.Address.= =A0 If no forwarding route exists to=0A>=A0 TargetNode.Address, then a RER= R SHOULD be issued to the OrigNode of=0A>=A0 the RREP.=0A> =0A>=A0 By sen= ding the updated RteMsg, ThisNode advertises that it will route=0A>=A0 for= addresses contained in the outgoing RteMsg based on the=0A>=A0 informatio= n enclosed.=A0 ThisNode MAY choose not to send the RteMsg,=0A>=A0 though n= ot resending this RteMsg could decrease connectivity in the=0A> =0A> =0A> = =0A> Perkins & Chakeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 [Page 19]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A= > =0A> =0A>=A0 network or result in a non-shortest distance path.=0A> =0A>= =A0 The circumstances under which ThisNode might choose to not re-issue a= =0A>=A0 RteMsg are not specified in this document.=A0 Some examples might= =0A>=A0 include the following:=0A> =0A>=A0 o=A0 if ThisNode does not want= to advertise routing for the contained=0A>=A0 =A0 =A0 addresses because it= is already heavily loaded=0A> =0A>=A0 o=A0 if ThisNode has already issued= identical routing information (e.g.=0A>=A0 =A0 =A0 ThisNode had recently i= ssued a RteMsg with the same distance)=0A> =0A>=A0 o=A0 if ThisNode is low= on energy and does not want to expend energy=0A>=A0 =A0 =A0 for protocol m= essage sending or packet forwarding=0A> =0A> 5.4.=A0 Route Discovery=0A> = =0A>=A0 When an AODVv2 router needs to forward a data packet and it does n= ot=0A>=A0 have a forwarding route to the destination address, it sends a R= REQ=0A>=A0 (described in Section 5.3.1) to discover a route to the particu= lar=0A>=A0 destination (TargetNode).=0A> =0A>=A0 After issuing a RREQ, th= e AODVv2 router (OrigNode) waits for a RREP=0A>=A0 indicating the next hop= for a route to the TargetNode.=A0 If a route is=0A>=A0 not created within= RREQ_WAIT_TIME, OrigNode may again try to discover=0A>=A0 a route by issu= ing another RREQ using the procedure defined in=0A>=A0 Section 5.3.1 again= .=A0 Route discovery SHOULD be considered to have=0A>=A0 failed after DISC= OVERY_ATTEMPTS_MAX and the corresponding wait time=0A>=A0 for a response t= o the final RREQ.=0A> =0A>=A0 To reduce congestion in a network, repeated = attempts at route=0A>=A0 discovery for a particular TargetNode SHOULD util= ize an binary=0A>=A0 exponential backoff.=0A> =0A>=A0 Data packets awaiti= ng a route SHOULD be buffered by the source's=0A>=A0 AODVv2 router.=A0 Thi= s buffer SHOULD have a fixed limited size=0A>=A0 (BUFFER_SIZE_PACKETS or B= UFFER_SIZE_BYTES).=A0 Determining which=0A>=A0 packets to discard first is= a matter of policy at each AODVv2 router;=0A>=A0 in the absence of policy= constraints, by default older data packets=0A>=A0 SHOULD be discarded fir= st.=A0 Buffering of data packets can have both=0A>=A0 positive and negativ= e effects, and therefore settings for buffering=0A>=A0 (BUFFER_DURING_DISC= OVERY) SHOULD be administratively configurable.=0A>=A0 Nodes without suffi= cient memory available for buffering may be=0A>=A0 configured with BUFFER_= DURING_DISCOVERY =3D FALSE; this will affect the=0A>=A0 latency required f= or launching TCP applications to new destinations.=0A> =0A> UH> I am agains= t including this buffering mechanism in this document.=0A> This is a mixtur= e of the routing plane and the data plane. There are=0A> other forwarding m= echanisms that would be affected by this=0A> specification.=0A> =0A>=A0 If= a route discovery attempt has failed (i.e. an attempt or multiple=0A>=A0 = attempts have been made without receiving a RREP) to find a route to=0A> = =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 [Page 20]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October= 2012=0A> =0A> =0A>=A0 the TargetNode, any data packets buffered for the c= orresponding=0A>=A0 TargetNode MUST BE dropped and a Destination Unreachab= le ICMP message=0A>=A0 (Type 3) SHOULD be delivered to the source of the d= ata packet.=A0 The=0A>=A0 code for the ICMP message is 1 (Host unreachable= error).=A0 If the=0A>=A0 AODVv2 router is not the source (OrigNode), then= the ICMP is sent=0A>=A0 over the interface from which the source sent the= packet to the=0A>=A0 AODVv2 router.=0A> =0A> 5.5.=A0 Route Maintenance=0A= > =0A>=A0 A RERR SHOULD be issued if a data packet is to be forwarded and = it=0A>=A0 cannot be delivered to the next-hop because no forwarding route = for=0A>=A0 the IP.DestinationAddress exists; RERR generation is described = in=0A>=A0 Section 5.5.3.=0A> =0A>=A0 Upon this condition, an ICMP Destina= tion Unreachable message SHOULD=0A>=A0 NOT be generated unless this router= is responsible for the=0A>=A0 IP.DestinationAddress and that IP.Destinati= onAddress is known to be=0A>=A0 unreachable.=0A> =0A> UH> How is that gene= rated (with which content)?=0A> =0A>=A0 In addition to inability to forwar= d a data packet, a RERR SHOULD be=0A>=A0 issued immediately after detectin= g a broken link (see Section 5.5.1)=0A>=A0 of a forwarding route to quickl= y notify AODVv2 routers that certain=0A>=A0 routes are no longer available= .=A0 If a newly unavailable route has not=0A>=A0 been used recently (indic= ated by ROUTE_USED), the RERR SHOULD NOT be=0A>=A0 generated.=0A> =0A> UH>= SHOULD NOT or MUST NOT? What are the consequences of doing so when=0A> usi= ng SHOULD NOT?=0A> =0A> 5.5.1.=A0 Active Next-hop Router Adjacency Monitori= ng=0A> =0A>=A0 Nodes SHOULD monitor connectivity to adjacent next-hop AODV= v2 routers=0A>=A0 on forwarding routes.=A0 This monitoring can be accompli= shed by one or=0A>=A0 several mechanisms, including:=0A> =0A>=A0 o=A0 Nei= ghborhood discovery [RFC6130]=0A> =0A>=A0 o=A0 Route timeout=0A> =0A>=A0 = o=A0 Lower layer trigger that a neighboring router is no longer=0A>=A0 =A0 = =A0 reachable=0A> =0A>=A0 o=A0 Other monitoring mechanisms or heuristics= =0A> =0A>=A0 Upon determining that a next-hop AODVv2 router has become=0A>= =A0 unreachable, ThisNode MUST remove the affected forwarding routes=0A>= =A0 (those using the unreachable next-hop) and unset the Route.Forwarding= =0A>=A0 flag.=A0 ThisNode also flags the associated routes in AODVv2's rou= ting=0A>=A0 table as Broken.=A0 For each broken route the timer for ROUTE_= DELETE is=0A>=A0 set to ROUTE_DELETE_TIMEOUT.=0A> =0A> UH> How can the fla= gs be set if the routes are removed before?=0A> =0A> =0A> =0A> Perkins & Ch= akeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [P= age 21]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A> =0A> =0A> 5.5.2.= =A0 Updating Route Lifetimes During Packet Forwarding=0A> =0A>=A0 To avoid= removing the forwarding route to reach an IP.SourceAddress,=0A>=A0 ThisNo= de SHOULD set the "ROUTE_USED" timeout to the value=0A>=A0 ROUTE_USED_TIME= OUT for the route to that IP.SourceAddress upon=0A>=A0 receiving a data pa= cket or an AODVv2 message.=A0 If the timer for=0A>=A0 ROUTE_DELETE is set,= that timer is removed.=A0 The Route.Broken flag is=0A>=A0 unset.=0A> =0A>= =A0 To avoid removing the forwarding route to the IP.DestinationAddress=0A= >=A0 that is being used, ThisNode SHOULD set the "ROUTE_USED" timeout to= =0A>=A0 the value ROUTE_USED_TIMEOUT for the route to the=0A>=A0 IP.Desti= nationAddress upon sending a data packet or an AODVv2=0A>=A0 message.=A0 I= f the timer for ROUTE_DELETE is set, it is removed.=A0 The=0A>=A0 Route.Br= oken flag is unset.=0A> =0A> 5.5.3.=A0 RERR Generation=0A> =0A>=A0 When an= AODVv2 router receives a packet (from PrevHopAddress), and=0A>=A0 the rou= ter (ThisNode) does not have a route available for the=0A>=A0 destination = of the packet, ThisNode uses an RERR message is used to=0A> =0A> UH> "uses"= .. ."is used"=0A> =0A>=A0 inform one or more neighboring AODVv2 routers th= at its route to the=0A>=A0 packet destination is no longer available.=0A> = =0A>=A0 When ThisNode creates a new RERR, the address of the first=0A>=A0 = UnreachableNode (IP.DestinationAddress from a data packet or=0A>=A0 RREP.= TargetNode.Address) is inserted into an Address Block=0A>=A0 AddBlk.Unreac= hableNode.Address.=A0 If a prefix is known for the=0A>=A0 UnreachableNode.= Address, it SHOULD be included.=A0 Otherwise, the=0A>=A0 UnreachableNode.A= ddress is assumed to be a host address with a full=0A>=A0 length prefix.= =A0 If a value for the UnreachableNode's SeqNum=0A>=A0 (UnreachableNode.Ad= dTLV.SeqNum) is known, it SHOULD be placed in the=0A>=A0 RERR.=A0 The MsgH= dr.HopLimit SHOULD be set to MSG_HOPLIMIT.=0A> =0A>=A0 If SeqNum informati= on is not known or not included in the RERR, all=0A>=A0 nodes handling the= RERR will assume their routing information=0A>=A0 associated with the Unr= eachableNode is no longer valid and flag those=0A>=A0 routes as broken.=0A= > =0A>=A0 A RERR MAY be sent to the multicast address LL-MANET-Routers=0A>= =A0 [RFC5498], thus notifying all nearby AODVv2 routers that might depend= =0A>=A0 on the now broken link.=A0 If the RERR is unicast, the=0A>=A0 IP.= DestinationAddress is set to the PrevHopAddress.=0A> =0A>=A0 After sending= the RERR, ThisNode SHOULD discard the packet or message=0A> =0A> UH> Why p= acket or message? Is this data traffic or control traffic?=0A> =0A>=A0 tha= t triggered generation of the RERR.=0A> =0A> =0A> =0A> =0A> =0A> Perkins & = Chakeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = [Page 22]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv= 2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A> =0A> =0A> 5.5.4.= =A0 RERR Handling=0A> =0A>=A0 First, ThisNode examines the incoming RERR t= o ensure that it contains=0A>=A0 MsgHdr.HopLimit and AddBlk.UnreachableNod= e.Address.=A0 If the required=0A>=A0 information does not exist, the incom= ing RERR message is discarded=0A>=A0 and further processing stopped.=0A> = =0A>=A0 When an AODVv2 router handles a RERR, it examines the information = for=0A>=A0 each UnreachableNode.=0A> =0A> UH> How exactly does it do that?= Which information is used, and how?=0A> =0A>=A0 The AODVv2 router removes= the forwarding=0A>=A0 route, unsets the Route.Forwarding flag, sets the R= oute.Broken flag,=0A>=A0 and the timer for ROUTE_DELETE is set to ROUTE_DE= LETE_TIMEOUT for=0A>=A0 each UnreachableNode.Address found using longest p= refix matching that=0A>=A0 meets all of the following conditions:=0A> =0A>= =A0 1.=A0 The UnreachableNode.Address is a routable unicast address.=0A> = =0A>=A0 2.=A0 The Route.NextHopAddress is the same as the RERR=0A>=A0 =A0 = =A0 IP.SourceAddress.=0A> =0A>=A0 3.=A0 The Route.NextHopInterface is the= same as the interface on which=0A>=A0 =A0 =A0 the RERR was received.=0A> = =0A>=A0 4.=A0 The Route.SeqNum is zero (0), unknown, OR the=0A>=A0 =A0 =A0= UnreachableNode.SeqNum is zero (0), unknown, OR Route.SeqNum -=0A>=A0 =A0= =A0 UnreachableNode.SeqNum <=3D 0 (using signed 16-bit arithmetic).=0A> = =0A>=A0 If Route.SeqNum is zero (0) or unknown and UnreachableNode.SeqNum= =0A>=A0 exists in the RERR and is not zero (0), then Route.SeqNum SHOULD b= e=0A>=A0 set to UnreachableNode.SeqNum.=A0 Setting Route.SeqNum can reduce= =0A>=A0 future RERR handling and forwarding.=0A> =0A> UH> How?=0A> =0A>=A0= Each UnreachableNode that did not result in marking a route table=0A>=A0 = entry as broken route is removed from the RERR, since propagation of=0A>= =A0 such information will not result in any benefit.=0A> =0A> UH> Makes en= d-to-end security impossible.=0A> =0A>=A0 Each UnreachableNode that did in= dicate a broken route SHOULD remain=0A>=A0 in the RERR.=0A> =0A>=A0 If an= y UnreachableNode was removed, all other information (AddTLVs)=0A>=A0 asso= ciated with the UnreachableNode address(es) MUST also be removed.=0A> =0A>= =A0 If Route.SeqNum is known and an UnreachableNode.SeqNum is not=0A>=A0 = included in the RERR, then Route.SeqNum (i.e.=0A>=A0 UnreachableNode.SeqNu= m) MAY be included with the RERR.=A0 Including=0A>=A0 UnreachableNode.SeqN= um can reduce future RERR handling and=0A>=A0 forwarding.=0A> =0A>=A0 If = no UnreachableNode addresses remain in the RERR, or if the=0A> =0A> =0A> = =0A> Perkins & Chakeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 [Page 23]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A= > =0A> =0A>=A0 MsgHdr.HopLimit is equal to one (1), then the RERR MUST be = discarded.=0A> =0A>=A0 Otherwise, the MsgHdr.HopLimit is decremented by on= e (1).=A0 The RERR=0A>=A0 SHOULD be sent to the multicast address LL-MANET= -Routers [RFC5498].=0A>=A0 Alternatively, if the RERR is unicast, the IP.D= estinationAddress is=0A>=A0 set to the PrevHopAddress.=0A> =0A> 5.6.=A0 Un= known Message and TLV Types=0A> =0A>=A0 If a message with an unknown type = is received, the message is=0A>=A0 ignored.=0A> =0A>=A0 For handling of m= essages that contain unknown TLV types, ignore the=0A>=A0 information for = processing, preserve it unmodified for forwarding.=0A> =0A> 5.7.=A0 Adverti= sing Network Addresses=0A> =0A>=A0 AODVv2 routers MAY specify a prefix len= gth for each advertised=0A>=A0 address.=A0 Any nodes (other than the adver= tising AODVv2 router) within=0A>=A0 the advertised prefix MUST NOT partici= pate in the AODVv2 protocol=0A>=A0 directly.=A0 For example, advertising 1= 92.0.2.1 with a prefix length of=0A>=A0 24 indicates that all nodes with t= he matching 192.0.2.X are reachable=0A>=A0 through this AODVv2 router.=A0 = An AODVv2 router MUST NOT advertise=0A>=A0 network addresses unless it can= guarantee its ability for forwarding=0A>=A0 packets to any host address w= ithin the address range of the=0A>=A0 corresponding network.=0A> =0A> 5.8.= =A0 Simple Internet Attachment=0A> =0A>=A0 Simple Internet attachment cons= ists of a stub (i.e., non-transit)=0A>=A0 network of AODVv2 routers connec= ted to the Internet via a single=0A>=A0 Internet AODVv2 router (IAR).=0A> = =0A> UH> Why a new defition? Is that not just a border router? Also, it=0A>= does not matter if it's connected to the "Internet", just if it's a=0A> bo= rder gateway with two interfaces, connecting two different routing=0A> doma= ins (which could still not be connected to the Internet).=0A> =0A>=A0 As i= n any Internet-attached network,=0A> =0A> UH> What's an Internet-attached n= etwork? Is that defined in an IP=0A> architecture RFC?=0A> =0A>=A0 =A0 AODV= v2 routers, and hosts behind=0A>=A0 these routers, wishing to be reachable= from hosts on the Internet=0A>=A0 MUST have IP addresses within the IAR's= routable and topologically=0A>=A0 correct prefix (e.g. 192.0.2.0/24).=0A>= =0A>=A0 The IAR is responsible for generating RREQ to find nodes within t= he=0A>=A0 AODVv2 Region on behalf of nodes on the Internet, as well as=0A>= =A0 responding to route requests from the AODVv2 region on behalf of the= =0A>=A0 nodes on the Internet.=0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A>= =0A> Perkins & Chakeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 [Page 24]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A= > =0A> =0A>=A0 =A0 =A0 =A0 /--------------------------\=0A>=A0 =A0 =A0 =A0= /=A0 =A0 =A0 =A0 =A0 Internet=A0 =A0 =A0 =A0 =A0 \=0A>=A0 =A0 =A0 =A0 \=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /=0A>=A0 =A0 =A0 =A0 = \------------+-------------/=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= |=0A>=A0 =A0 =A0 Routable &=A0 =A0 |=0A>=A0 =A0 =A0 Topologically=A0 |= =0A>=A0 =A0 =A0 Correct=A0 =A0 =A0 =A0 |=0A>=A0 =A0 =A0 Prefix=A0 =A0 =A0= =A0 |=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +-----+--------+=0A>=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |=A0 Internet=A0 =A0 |=0A>=A0 =A0 =A0 =A0 /------|=A0 = AODVv2=A0 =A0 =A0 |-------\=0A>=A0 =A0 =A0 =A0 /=A0 =A0 =A0 |=A0 Router=A0= =A0 =A0 |=A0 =A0 =A0 =A0 \=0A>=A0 =A0 =A0 /=A0 =A0 =A0 =A0 |192.0.2.1/32= =A0 |=A0 =A0 =A0 =A0 \=0A>=A0 =A0 =A0 |=A0 =A0 =A0 =A0 |Responsible=A0 |= =A0 =A0 =A0 =A0 |=0A>=A0 =A0 =A0 |=A0 =A0 =A0 =A0 |=A0 for=A0 =A0 =A0 =A0= |=A0 =A0 =A0 =A0 |=0A>=A0 =A0 =A0 |=A0 =A0 =A0 =A0 |AODVv2 Region |=A0 = =A0 =A0 =A0 |=0A>=A0 =A0 =A0 |=A0 =A0 =A0 =A0 |192.0.2.0/24=A0 |=A0 =A0 = =A0 =A0 |=0A>=A0 =A0 =A0 |=A0 =A0 =A0 =A0 +--------------+=A0 =A0 =A0 =A0= |=0A>=A0 =A0 =A0 | +----------------+=A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A>= =A0 =A0 =A0 | | AODVv2 Router=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A>=A0 =A0= =A0 | | 192.0.2.2/32=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A>=A0 =A0 =A0 |= +----------------+=A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A>=A0 =A0 =A0 |=A0 =A0 = =A0 =A0 =A0 =A0 =A0 +----------------+ |=0A>=A0 =A0 =A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 | AODVv2 Router=A0 | |=0A>=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0= =A0 | 192.0.2.3/32=A0 | |=0A>=A0 =A0 =A0 \=A0 =A0 =A0 =A0 =A0 =A0 =A0 +-= ---------------+ /=0A>=A0 =A0 =A0 =A0 \=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 /=0A>=A0 =A0 =A0 =A0 \---------------------------= --/=0A> =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 Figure 1: Simple Internet Attachme= nt Example=0A> =0A>=A0 When an AODVv2 router within the AODVv2 Region want= s to discover a=0A>=A0 route to a node on the Internet, it uses the normal= AODVv2 route=0A>=A0 discovery for that IP Destination Address.=A0 The IAR= MUST respond to=0A>=A0 RREQ on behalf of the Internet destination.=0A> = =0A> UH> How? Where is that specified?=0A> =0A>=A0 When a packet from a no= de on the Internet destined for a node in the=0A>=A0 AODVv2 region reaches= the IAR, if the IAR does not have a route to=0A>=A0 that destination it w= ill perform normal AODVv2 route discovery for=0A>=A0 that destination.=0A>= =0A> UH> How? With which originator address, target etc? Where are RERRs /= =0A> ICMP unreachable sent to in case of a broken data traffic?=0A> =0A> 5.= 9.=A0 Multiple Interfaces=0A> =0A>=A0 AODVv2 may be used with multiple int= erfaces; therefore, the=0A>=A0 particular interface over which packets arr= ive MUST be known whenever=0A>=A0 a packet is received.=A0 Whenever a new = route is created, the interface=0A>=A0 through which the Route.Address can= be reached is also recorded in=0A> =0A> =0A> =0A> Perkins & Chakeres=A0 = =A0 =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 25]=0A= > =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A> =0A> =0A>=A0 the route tabl= e entry.=0A> =0A>=A0 When multiple interfaces are available, a node transm= itting a=0A>=A0 multicast packet with IP.DestinationAddress set to LL-MANE= T-Routers=0A>=A0 SHOULD send the packet on all interfaces that have been c= onfigured=0A>=A0 for AODVv2 operation.=0A> =0A>=A0 Similarly, AODVv2 rout= ers SHOULD subscribe to LL-MANET-Routers on all=0A>=A0 their AODVv2 interf= aces.=0A> =0A> 5.10.=A0 AODVv2 Control Packet/Message Generation Limits=0A>= =0A> UH> There is no AODVv2 Control Packet.=0A> =0A> =0A>=A0 To ensure pr= edictable messaging overhead, AODVv2 router's rate of=0A>=A0 packet/messag= e generation SHOULD be limited.=A0 The rate and algorithm=0A>=A0 for limit= ing messages (CONTROL_TRAFFIC_LIMITS) is left to the=0A>=A0 implementor an= d should be administratively configurable.=A0 AODVv2=0A>=A0 messages SHOUL= D be discarded in the following order of preference:=0A>=A0 RREQ, RREP, an= d finally RERR.=0A> =0A> 5.11.=A0 Optional Features=0A> =0A>=A0 Several op= tional features of AODVv2, and associated with AODV, are=0A>=A0 not requir= ed by minimal implementations.=A0 These features are expected=0A>=A0 to be= useful in networks with greater mobility, or larger node=0A>=A0 populatio= ns, or requiring shorter latency for application launches.=0A>=A0 The opti= onal features are as follows:=0A> =0A>=A0 o=A0 Expanding Rings Multicast= =0A> =0A>=A0 o=A0 Intermediate RREPs (iRREPs): Without iRREP, only the des= tination=0A>=A0 =A0 =A0 can respond to a RREQ.=0A> =0A>=A0 o=A0 Precursor = lists.=0A> =0A>=A0 o=A0 Reporting Multiple Unreachable Nodes.=A0 An RERR m= essage can carry=0A>=A0 =A0 =A0 more than one Unreachable Destination node = for cases when a single=0A>=A0 =A0 =A0 link breakage causes multiple destin= ations to become unreachable=0A>=A0 =A0 =A0 from an intermediate router.=0A= > =0A> UH> This seems to be different from section 5.11.6, which talks abou= t=0A> adding additional information to a RREQ.=0A> =0A> UH> None of the ext= ensions is sufficiently specified, and it is=0A> unclear how it would affec= t interoperability if some nodes support the=0A> extension and others don't= .=0A> =0A> 5.11.1.=A0 Expanding Rings Multicast=0A> =0A>=A0 For multicast = RREQ, the MsgHdr.HopLimit MAY be set in accordance with=0A>=A0 an expandin= g ring search as described in [RFC3561] to limit the RREQ=0A>=A0 propagati= on to a subset of the local network and possibly reduce=0A>=A0 route disco= very overhead.=0A> =0A> =0A> =0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 = =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 26]=0A> = =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A> =0A> =0A> 5.11.2.=A0 Intermed= iate RREP=0A> =0A>=A0 This specification has been published as a separate = Internet Draft .=0A> =0A> 5.11.3.=A0 Precursor Notification=0A> =0A>=A0 Th= e Dynamic MANET On-demand (AODVv2) routing protocol is intended for=0A>=A0 = use by mobile routers in wireless, multihop networks.=A0 AODVv2=0A>=A0 de= termines unicast routes among AODVv2 routers within the network in=0A>=A0 = an on-demand fashion, offering on-demand convergence in dynamic=0A>=A0 top= ologies.=A0 This document specifies a simple modification to AODVv2=0A>=A0 = (and possibly other reactive routing protocols) enabling faster=0A>=A0 no= tifications to known sources of traffic upon determination that a=0A>=A0 r= oute for such traffic's destination has become Broken.=0A> =0A> 5.11.3.1.= =A0 Overview=0A> =0A>=A0 If an AODVv2 router, while attempting to forward = a packet to a=0A>=A0 particular destination, determines that the next hop = (one of its=0A>=A0 neighbors) is no longer reachable, AODVv2 specifies tha= t the router=0A>=A0 notify the source of that packet that the route to the= destination=0A>=A0 has become Broken.=A0 In the existing specification, t= he notification=0A>=A0 to the source is a unicast RERR message.=0A> =0A>= =A0 However, in many cases there will be several sources of of traffic=0A>= =A0 for that particular destination.=A0 In fact, the broken link for the= =0A>=A0 next hop in question may be a path component of numerous other rou= tes=0A>=A0 for other destinations, and in that case the node detecting the= =0A>=A0 broken link must mark as Broken multiple routes, one for each of t= he=0A>=A0 newly unreachable destinations.=A0 Each route that uses the newl= y=0A>=A0 broken link is no longer valid.=A0 For each such route, every nod= e=0A>=A0 along the way from the source using that route, to the node detec= ting=0A>=A0 the broken link, is known as a "precursor" for the broken next= hop.=0A>=A0 All the precursors for a particular next hop should be notifi= ed about=0A>=A0 the change in status of their route to a destination downs= tream from=0A>=A0 the broken next hop.=0A> =0A> 5.11.3.2.=A0 Precursor Not= ification=0A> =0A>=A0 During normal operation, each node wishing to enable= the improved=0A>=A0 notification for precursors of any links to its next = hop neighbors=0A>=A0 has to keep track of the precursors.=A0 This is done = by maintaining a=0A>=A0 precursor table and updating the table whenever th= e node initiates or=0A>=A0 relays a RREP message back to a node originatin= g a RREQ message.=0A>=A0 When the node transmits the RREP message, it is i= mplicitly agreeing=0A>=A0 to forward traffic from the RREQ originator towa= rds the RREP=0A>=A0 originator (i.e., along the next hop link to the neigh= bor from which=0A>=A0 the RREP was received).=A0 The "other" next hop, whi= ch is the neighbor=0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 =A0 Expire= s April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 27]=0A> =0A> Internet= -Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 October 2012=0A> =0A> =0A>=A0 along the way towards the o= riginator of the RREQ message, is then the=0A>=A0 next precursor for the r= oute towards the destination requested by the=0A>=A0 RREQ.=0A> =0A>=A0 Ea= ch such precursor should then be recorded as a precursor for a=0A>=A0 rout= e along the next hop.=A0 The same next hop may be in service for=0A>=A0 ro= utes to multiple destinations, but for precursor list management it=0A>=A0 = is only important to keep track of precursors for a particular next=0A>=A0= hop; the exact destination does not matter, only the particular next=0A>= =A0 hop towards the destination(s).=0A> =0A>=A0 When a node observes that= one of its neighbors is no longer=0A>=A0 reachable, the node first checks= to see whether the link to that=0A>=A0 neighbor is a next hop for any mor= e distant destination in its route=0A>=A0 table.=A0 If not, then the node = simply updates any relevant neighorhood=0A>=A0 information and takes no fu= rther action.=0A> =0A>=A0 Otherwise, for all destinations no longer reacha= ble because of the=0A>=A0 changed status of the next hop, the node first c= hecks to see whether=0A>=A0 the link to that neighbor is a next hop for an= y more distant=0A>=A0 destination in its route table.=A0 If not, then the = node simply updates=0A>=A0 any relevant neighorhood information and takes = no further action.=0A> =0A>=A0 For each precursor of the next hop, the nod= e MAY notify the precursor=0A>=A0 in one of three ways:=0A> =0A>=A0 o=A0 = unicast RERR=0A> =0A>=A0 o=A0 broadcast RERR=0A> =0A>=A0 o=A0 multicast R= ERR to multicast group PRECURSOR_RERR_RECEIVERS=0A> =0A> UH> I don't see an= allocation request in the IANA section.=0A> =0A> =0A>=A0 Each precursor t= hen MAY execute the same procedure until all affected=0A>=A0 traffic sourc= es have received the RERR route maintenance information.=0A> =0A>=A0 When = a precursor receives a unicast RERR, the precursor MUST further=0A>=A0 uni= cast the RERR message towards the affected traffic source.=A0 If a=0A>=A0 = precursor receives a broadcast or multicast RERR, the precursor MAY=0A>=A0 = further retransmit the RERR towards the traffic source.=0A> =0A> 5.11.4.= =A0 Reporting Multiple Unreachable Nodes=0A> =0A> 5.11.5.=A0 Message Aggreg= ation=0A> =0A>=A0 The aggregation of multiple messages into a packet is no= t specified=0A>=A0 in this document, but if aggregation does occur the IP.= SourceAddress=0A>=A0 and IP.DestinationAddress of all contained messages M= UST be the same.=0A> =0A> UH> That is part of the RFC5444 multiplexer and n= ot of AODVv2.=0A> =0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 =A0 Expire= s April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 28]=0A> =0A> Internet= -Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 October 2012=0A> =0A> =0A>=A0 Implementations MAY choose = to temporarily delay transmission of=0A>=A0 messages for the purpose of ag= gregation (into a single packet) or to=0A>=A0 improve performance by using= jitter [RFC5148].=0A> =0A> 5.11.6.=A0 Adding Additional Routing Informatio= n to a RteMsg=0A> =0A> UH> This section is unclear to me. What is the purpo= se? What kind of=0A> information would you add? How can this interoperate? = By adding=0A> information en-route, end-to-end security is not possible.=0A= > =0A>=A0 DSR [RFC4728] includes source routes as part of the data of its = RREPs=0A>=A0 and RREQs.=A0 Doign so allows additional topology information= to be=0A>=A0 flooded along with the RteMsg, and potentially allows updati= ng for=0A>=A0 stale routing information at MANET routers along new paths b= etween=0A>=A0 source and destination.=A0 To maintain this functionality, A= ODVv2 has=0A>=A0 defined a somewhat more general method that enables inclu= sion of=0A>=A0 source routes in RteMsgs.=0A> =0A>=A0 Appending routing in= formation can alleviate route discovery attempts=0A>=A0 to the nodes whose= information is included, if other AODVv2 routers=0A>=A0 use this informat= ion to update their routing tables.=0A> =0A>=A0 Note that, since the initi= al merger of DSR with AODV to create this=0A>=A0 protocol, further experim= entation has shown that including the=0A>=A0 additional routing informatio= n is not always helpful.=A0 Sometimes it=0A>=A0 seems to help, and other t= imes it seems to reduct overall=0A>=A0 performance.=0A> =0A>=A0 AODVv2 ro= uters can append routing information to a RteMsg.=A0 This is=0A>=A0 contro= llable by an option (APPEND_INFORMATION) which SHOULD be=0A>=A0 administra= tively configurable or controlled according to the traffic=0A>=A0 characte= ristics of the network.=0A> =0A>=A0 Prior to appending an address controll= ed by this AODVv2 router to a=0A>=A0 RteMsg, ThisNode MAY increment its Ow= nSeqNum as defined in=0A>=A0 Section 5.1.=A0 If OwnSeqNum is not increment= ed the appended routing=0A>=A0 information might not be considered prefera= ble, when received by=0A>=A0 nodes with existing routing information.=A0 I= ncrementation of the=0A>=A0 sequence number when appending information to = a RteMsg in transit=0A>=A0 (APPEND_INFORMATION_SEQNUM) SHOULD be administr= atively configurable.=0A>=A0 Note that, during handling of this RteMsg Own= SeqNum may have already=0A>=A0 been incremented; and in this case OwnSeqNu= m need not be incremented=0A>=A0 again.=0A> =0A>=A0 If an address control= led by this AODVv2 router includes=0A>=A0 ThisNode.Dist, it is set to a nu= mber greater than zero (0).=0A> =0A>=A0 For added addresses (and their pre= fixes) not controlled by this=0A>=A0 AODVv2 router, Route.Dist can be incl= uded if known.=0A> =0A>=A0 The VALIDITY_TIME of routing information for ap= pended address(es)=0A>=A0 MUST be included, to inform routers about when t= o delete this=0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 =A0 Expires Apr= il 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 29]=0A> =0A> Internet-Draf= t=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 October 2012=0A> =0A> =0A>=A0 information.=A0 The VALIDITY_TIME = TLV is defined in Section 5.13.3.=0A> =0A>=A0 Additional information (e.g.= =A0 SeqNum and Dist) about any appended=0A>=A0 address(es) SHOULD be inclu= ded.=0A> =0A>=A0 Note that the routing information about the TargetNode MU= ST NOT be=0A>=A0 added.=A0 Also, duplicate address entries SHOULD NOT be a= dded.=0A>=A0 Instead, only the best routing information (Section 5.2.1) fo= r a=0A>=A0 particular address SHOULD be included.=0A> =0A>=A0 Intermediat= e nodes obey the following procedures when processing=0A>=A0 AddBlk.Additi= onalNode.Address information and other associated TLVs=0A>=A0 that are inc= luded with a RteMsg.=A0 For each address (except the=0A>=A0 TargetNode) in= the RteMsg that includes AddTLV.Dist information, the=0A>=A0 AddTLV.Dist = information MUST be incremented.=A0 If the resulting=0A>=A0 Distance value= for the OrigNode is greater than 254, the message is=0A>=A0 discarded.=A0= If the resulting Distance value for another node is=0A>=A0 greater than 2= 54, the associated address and its information are=0A>=A0 removed from the= RteMsg.=0A> =0A>=A0 After handling the OrigNode's routing information, th= en each address=0A>=A0 that is not the TargetNode MAY be considered for cr= eating and=0A>=A0 updating routes.=A0 Creating and updating routes to othe= r nodes can=0A>=A0 eliminate RREQ for those IP destinations, in the event = that data=0A>=A0 needs to be forwarded to the IP destination(s) now or in = the near=0A>=A0 future.=0A> =0A>=A0 For each of the additional addresses = considered, ThisNode first=0A>=A0 checks that the address is a routable un= icast address.=A0 If the=0A>=A0 address is not a unicast address, then the= address and all related=0A>=A0 information MUST be removed.=0A> =0A>=A0 = If the routing table does not have a matching route with a known=0A>=A0 Ro= ute.SeqNum for this additional address using longest-prefix=0A>=A0 matchin= g, then a route MAY be created and updated as described in=0A>=A0 Section = 5.2.2.=A0 If a route table entry exists with a known=0A>=A0 Route.SeqNum, = the incoming routing information is compared with the=0A>=A0 route table e= ntry following the procedure described in Section 5.2.1.=0A>=A0 If the inc= oming routing information is used, the route table entry=0A>=A0 SHOULD be = updated as described in Section 5.2.2.=0A> =0A>=A0 If the routing informat= ion for an AdditionalNode.Address is not used,=0A>=A0 then it is removed f= rom the RteMsg.=0A> =0A> 5.12.=A0 Administratively Configured Parameters an= d Timer Values=0A> =0A>=A0 AODVv2 contains several parameters which MUST b= e administratively=0A>=A0 configured.=A0 The list of these follows:=0A> = =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 [Page 30]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October= 2012=0A> =0A> =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 Required Administratively Co= nfigured Parameters=0A> =0A>=A0 +------------------------+----------------= --------------------------+=0A>=A0 |=A0 =A0 =A0 =A0 =A0 Name=A0 =A0 =A0 = =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Description=A0 =A0 =A0 =A0 =A0 =A0= =A0 |=0A>=A0 +------------------------+---------------------------------= ---------+=0A>=A0 |=A0 RESPONSIBLE_ADDRESSES |=A0 List of addresses or rou= ting prefixes,=A0 |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 |=A0 =A0 =A0 for which this AODVv2 router is=A0 =A0 |=0A>=A0 |=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 responsible.=A0 If, RESPONSIB= LE_ADDRESSES |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |= =A0 =A0 is zero, this AODVv2 router is only=A0 |=0A>=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 responsible for its own addresses.= =A0 =A0 |=0A>=A0 |=A0 =A0 AODVv2_INTERFACES=A0 |=A0 List of the interface= s participating in |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 |=A0 =A0 =A0 =A0 AODVv2 routing protocol.=A0 =A0 =A0 =A0 |=0A>=A0 +-= -----------------------+------------------------------------------+=0A> =0A= >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Table = 2=0A> =0A>=A0 AODVv2 contains a number of timers.=A0 The default timing pa= rameter=0A>=A0 values follow:=0A> =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Default Timing Parameter Values=0A> =0A>=A0 =A0 =A0 =A0 =A0 +-----= -------------------------+-------------------+=0A>=A0 =A0 =A0 =A0 =A0 |=A0= =A0 =A0 =A0 =A0 =A0 Name=A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 Value=A0 = =A0 =A0 |=0A>=A0 =A0 =A0 =A0 =A0 +------------------------------+--------= -----------+=0A>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 ROUTE_TIMEOUT=A0 =A0= =A0 =A0 |=A0 =A0 5 seconds=A0 =A0 |=0A>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 RO= UTE_AGE_MIN_TIMEOUT=A0 =A0 |=A0 =A0 =A0 1 second=A0 =A0 |=0A>=A0 =A0 =A0 = =A0 =A0 | ROUTE_SEQNUM_AGE_MAX_TIMEOUT |=A0 =A0 600 seconds=A0 =A0 |=0A>= =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 ROUTE_USED_TIMEOUT=A0 =A0 =A0 |=A0 ROUTE= _TIMEOUT=A0 |=0A>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 ROUTE_DELETE_TIMEOUT=A0 = =A0 | 2 * ROUTE_TIMEOUT |=0A>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 ROUTE_RREQ_WAI= T_TIME=A0 =A0 |=A0 =A0 2 seconds=A0 =A0 |=0A>=A0 =A0 =A0 =A0 =A0 | UNIC= AST_MESSAGE_SENT_TIMEOUT |=A0 =A0 =A0 1 second=A0 =A0 |=0A> =0A> UH> UNICA= ST_MESSAGE_SENT_TIMEOUT is never used in this specification=0A> =0A>=A0 =A0= =A0 =A0 =A0 +------------------------------+-------------------+=0A> =0A>= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Table 3= =0A> =0A>=A0 The above timing parameter values work well for small and med= ium=0A>=A0 well-connected networks with moderate topology changes.=0A> =0A= > UH> That also depends on the traffic patterns, on the lossy-ness of=0A> t= he links, on the density of the routers etc.=0A> =0A>=A0 The timing parame= ters SHOULD be administratively configurable for the=0A>=A0 network where = AODVv2 is used.=A0 Ideally, for networks with frequent=0A>=A0 topology cha= nges the AODVv2 parameters should be adjusted using=0A>=A0 either experime= ntally determined values or dynamic adaptation.=A0 For=0A>=A0 example, in = networks with infrequent topology changes=0A>=A0 ROUTE_USED_TIMEOUT may be= set to a much larger value.=0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> Perkins= & Chakeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 [Page 31]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A= ODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A> =0A> =0A>=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Default Parameter Values=0A> = =0A>=A0 +------------------------+-------+--------------------------------= --+=0A>=A0 |=A0 =A0 =A0 =A0 =A0 Name=A0 =A0 =A0 =A0 =A0 | Value |=A0 =A0 = =A0 =A0 =A0 =A0 Description=A0 =A0 =A0 =A0 =A0 |=0A>=A0 +----------------= --------+-------+----------------------------------+=0A>=A0 |=A0 =A0 =A0 M= SG_HOPLIMIT=A0 =A0 =A0 |=A0 20=A0 |=A0 This value MUST be larger than=A0 |= =0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 hops |=A0 t= he AODVv2 network diameter.=A0 |=0A> =0A> UH> How would the network diamet= er be determined?=0A> =0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 |=A0 Otherwise, routing messages may |=0A>=A0 |=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 |=A0 =A0 not reach t= heir intended=A0 =A0 |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 |=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 destinations.=A0 =A0 =A0 =A0 = =A0 |=0A>=A0 | DISCOVERY_ATTEMPTS_MAX |=A0 3=A0 |=A0 The number of rout= e discovery=A0 |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |= =A0 =A0 =A0 |=A0 =A0 =A0 attempts to make before=A0 =A0 |=0A>=A0 |=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 |=A0 indicating = that a particular=A0 |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 |=A0 =A0 =A0 |=A0 =A0 address is not reachable.=A0 =A0 |=0A>=A0 = +------------------------+-------+----------------------------------+=0A> = =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tab= le 4=0A> =0A>=A0 In addition to the above parameters and timing values, se= veral=0A>=A0 administrative options exist.=A0 These options have no influe= nce on=0A>=A0 correct routing behavior, although they may potentially redu= ce AODVv2=0A>=A0 protocol messaging in certain situations.=A0 The default = behavior is to=0A>=A0 NOT enable any of these options; and although many o= f these options=0A>=A0 can be administratively controlled, they may be bet= ter served by=0A>=A0 intelligent control.=A0 The following table enumerate= s several of the=0A>=A0 options.=0A> =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Administratively Controlled Options=0A> =0A>=A0 +-----------------= ---------+----------------------------------------+=0A>=A0 |=A0 =A0 =A0 = =A0 =A0 Name=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 Description= =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A>=A0 +--------------------------+---------= -------------------------------+=0A>=A0 |=A0 BUFFER_DURING_DISCOVERY |=A0 = Whether and how much data to buffer=A0 |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 during route discovery.=A0 = =A0 =A0 =A0 |=0A> =0A> UH> Whether and how much? Is it a boolean flag or a = number?=0A> =0A> =0A>=A0 | APPEND_EXTRA_UNREACHABLE |=A0 =A0 =A0 Whether t= o append additional=A0 =A0 =A0 |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |=A0 =A0 Unreachable information to RERR.=A0 =A0 |=0A>= =A0 |=A0 CONTROL_TRAFFIC_LIMITS=A0 |=A0 AODVv2 messaging SHOULD be limited= to |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0= avoid consuming all the network=A0 =A0 |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 bandwidth.=A0 = =A0 =A0 =A0 =A0 =A0 =A0 |=0A> =0A> UH> What is the unit or the meaning of = this? Bytes per second?=0A> =0A>=A0 +--------------------------+----------= ------------------------------+=0A> =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Table 5=0A> =0A>=A0 Note: several fields = have limited size (bits or bytes) these sizes=0A>=A0 and their encoding ma= y place specific limitations on the values that=0A>=A0 can be set.=A0 For = example, MsgHdr.HopLimit is a 8-bit field and=0A>=A0 therefore MSG_HOPLIMI= T cannot be larger than 255.=0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 = =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 32]=0A> = =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A> =0A> =0A> 5.13.=A0 IANA Consi= derations=0A> =0A> UH> This is not a valid IANA section. There are no reque= sts for=0A> registries or for TLV code points. There is no allocation polic= y.=0A> Refer to RFC5526.=0A> =0A> =0A>=A0 In its default mode of operation= , AODVv2 uses the UDP port 269=0A>=A0 [RFC5498] to carry protocol packets.= =A0 AODVv2 also uses the link-local=0A>=A0 multicast address LL-MANET-Rout= ers [RFC5498].=0A> =0A>=A0 This section specifies several message types, m= essage tlv-types, and=0A>=A0 address tlv-types.=0A> =0A> 5.13.1.=A0 AODVv2= Message Types Specification=0A> =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 AODVv2 Message Types=0A> =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 +------------------------+----------+=0A>=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 Name=A0 =A0 =A0 =A0 =A0 |=A0 Type=A0 |= =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +------------------------+--------= --+=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 Route Request (RREQ)=A0 | = 10 - TBD |=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 Route Reply (RREP)= =A0 | 11 - TBD |=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 Route Error= (RERR)=A0 | 12 - TBD |=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +---------= ---------------+----------+=0A> =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 Table 6=0A> =0A> 5.13.2.=A0 Message and Addres= s Block TLV Type Specification=0A> =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 Message TLV Types=0A> =0A>=A0 +-------------------+--= ----+--------+-------------------------------+=0A>=A0 |=A0 =A0 =A0 =A0 Nam= e=A0 =A0 =A0 | Type | Length | Value=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |=0A>=A0 +-------------------+------+--------+---------------= ----------------+=0A>=A0 |=A0 Unicast Response | 10 - |=A0 =A0 0=A0 | Ind= icates to the processing=A0 |=0A>=A0 |=A0 =A0 =A0 Request=A0 =A0 =A0 |=A0= TBD | octets | node that the previous hop=A0 =A0 |=0A>=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 |=A0 =A0 =A0 =A0 | (IP.SourceAddress)= expects a=A0 |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = |=A0 =A0 =A0 =A0 | unicast reply message within=A0 |=0A>=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 |=A0 =A0 =A0 =A0 | UNICAST_MESSAGE_SE= NT_TIMEOUT. |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 |= =A0 =A0 =A0 =A0 | Any unicast packet will serve |=0A>=A0 |=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 |=A0 =A0 =A0 =A0 | this purpose, and it M= AY be=A0 |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 |=A0= =A0 =A0 =A0 | an ICMP REPLY message.=A0 If=A0 =A0 |=0A>=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 |=A0 =A0 =A0 =A0 | the reply is not r= eceived,=A0 =A0 |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 = =A0 |=A0 =A0 =A0 =A0 | then the previous hop can=A0 =A0 |=0A>=A0 |=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 |=A0 =A0 =A0 =A0 | assume that t= he link is=A0 =A0 =A0 |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0= =A0 =A0 |=A0 =A0 =A0 =A0 | unidirectional and MAY=A0 =A0 =A0 =A0 |=0A>=A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 |=A0 =A0 =A0 =A0 | blac= klist the link to this=A0 =A0 |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 |=A0 =A0 =A0 |=A0 =A0 =A0 =A0 | node.=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |=0A>=A0 +-------------------+------+--------+-----------= --------------------+=0A> =0A> UH> It is never specified where and how to u= se this TLV? Is it a=0A> message-specifid TLV? To which registry do you wan= t to add it? What is=0A> the allocation policy? What are the registered typ= e extensions?=0A> =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 Table 7=0A> =0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 = =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 33]=0A> = =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A> =0A> =0A> 5.13.3.=A0 Address = Block TLV Specification=0A> =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 Address Block TLV Types=0A> =0A>=A0 +----------------+-----------= -+----------+--------------------------+=0A>=A0 |=A0 =A0 =A0 Name=A0 =A0 = =A0 |=A0 =A0 Type=A0 =A0 |=A0 Length=A0 | Value=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |=0A>=A0 +----------------+------------+----------+-----------= ---------------+=0A>=A0 |=A0 =A0 AODVv2=A0 =A0 |=A0 10 - TBD=A0 |=A0 up = to 2 | The AODVv2 sequence num=A0 |=0A>=A0 |=A0 =A0 Sequence=A0 =A0 |=A0 = =A0 =A0 =A0 =A0 =A0 |=A0 octets=A0 | associated with this=A0 =A0 |=0A>=A0 = |=A0 =A0 Number=A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 | a= ddress.=A0 The sequence=A0 |=0A>=A0 | (AODVv2SeqNum) |=A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 | number may be the last=A0 |=0A>=A0 |=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 | kno= wn sequence number.=A0 |=0A>=A0 |=A0 =A0 Distance=A0 =A0 |=A0 11 - TBD=A0= |=A0 up to 2 | A metric of the distance |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 |=A0 octets=A0 | traversed by the=A0 =A0 = =A0 =A0 |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 = =A0 |=A0 =A0 =A0 =A0 =A0 | information associated=A0 |=0A>=A0 |=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 | wit= h this address.=A0 =A0 =A0 |=0A> =0A> UH> How is the distance formatted?= =0A> =0A>=A0 |=A0 VALIDITY_TIME | 1[RFC5497] |=A0 =A0 =A0 =A0 =A0 | The ma= ximum amount of=A0 =A0 |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 = =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 | time that information=A0 =A0 |=0A>= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0= =A0 =A0 | can be maintained before |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 |=A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 | being deleted.=A0 The= =A0 =A0 =A0 |=0A>=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 | VALIDITY_TIME TLV is=A0 =A0 |=0A>=A0 |=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 | de= fined in [RFC5497].=A0 =A0 |=0A>=A0 +----------------+------------+-------= ---+--------------------------+=0A> =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Table 8=0A> =0A> 5.14.=A0 Security Conside= rations=0A> =0A> UH> This will not suffice; see RFC3552 for guidelines how = to write=0A> security considerations.=0A> =0A> UH> Notably, there is no men= tion of possible threats to AODVv2. Also,=0A> there is some text to protect= messages; but it is impossible to do so,=0A> as messages are changed in tr= ansit. Also, since there is no way to=0A> hook in security extensions (such= as done in RFC6130) for rejecting=0A> messages, there is currently no secu= rity possible for DYMO.=0A> =0A> =0A>=A0 The objective of the AODVv2 proto= col is for each router to=0A>=A0 communicate reachability information to a= ddresses for which it is=0A>=A0 responsible.=A0 Positive routing informati= on (i.e. a route exists) is=0A>=A0 distributed via RteMsgs and negative ro= uting information (i.e. a=0A>=A0 route does not exist) via RERRs.=A0 AODVv= 2 routers that handle these=0A>=A0 messages store the contained informatio= n to properly forward data=0A>=A0 packets, and they generally provide this= information to other AODVv2=0A>=A0 routers.=0A> =0A>=A0 This section doe= s not mandate any specific security measures.=0A>=A0 Instead, this section= describes various security considerations and=0A>=A0 potential avenues to= secure AODVv2 routing.=0A> =0A>=A0 The most important security mechanisms= for AODVv2 routing are=0A>=A0 integrity/authentication and confidentialit= y.=0A> =0A>=A0 In situations where routing information or router identity = are=0A>=A0 suspect, integrity and authentication techniques SHOULD be appl= ied to=0A>=A0 AODVv2 messages.=0A> =0A> UH> How? Messages change in transi= t (addresses added or removed etc).=0A> =0A>=A0 In these situations, routi= ng information that is=0A>=A0 distributed over multiple hops SHOULD also v= erify the integrity and=0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 =A0 E= xpires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 34]=0A> =0A> Int= ernet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 October 2012=0A> =0A> =0A>=A0 identity of information= based on originator of the routing=0A>=A0 information.=0A> =0A> UH> How?= =0A> =0A>=A0 A digital signature could be used to identify the source of A= ODVv2=0A>=A0 messages and information, along with its authenticity.=A0 A n= once or=0A>=A0 timestamp SHOULD also be used to protect against replay att= acks.=0A>=A0 S/MIME and OpenPGP are two authentication/integrity protocols= that=0A>=A0 could be adapted for this purpose.=0A> =0A>=A0 In situations= where confidentiality of AODVv2 messages is important,=0A>=A0 cryptograph= ic techniques can be applied.=0A> =0A>=A0 In certain situations, for examp= le sending a RREP or RERR, an AODVv2=0A>=A0 router could include proof tha= t it has previously received valid=0A>=A0 routing information to reach the= destination, at one point of time in=0A>=A0 the past.=A0 In situations wh= ere routers are suspected of transmitting=0A>=A0 maliciously erroneous inf= ormation, the original routing information=0A>=A0 along with its security = credentials SHOULD be included.=0A> =0A>=A0 Note that if multicast is used= , any confidentiality and integrity=0A>=A0 algorithms used MUST permit mul= tiple receivers to handle the message.=0A> =0A>=A0 Routing protocols, howe= ver, are prime targets for impersonation=0A>=A0 attacks.=A0 In networks wh= ere the node membership is not known, it is=0A>=A0 difficult to determine = the occurrence of impersonation attacks, and=0A>=A0 security prevention te= chniques are difficult at best.=A0 However, when=0A>=A0 the network member= ship is known and there is a danger of such=0A>=A0 attacks, AODVv2 message= s must be protected by the use of=0A>=A0 authentication techniques, such a= s those involving generation of=0A>=A0 unforgeable and cryptographically s= trong message digests or digital=0A>=A0 signatures.=A0 While AODVv2 does n= ot place restrictions on the=0A>=A0 authentication mechanism used for this= purpose, IPsec Authentication=0A>=A0 Message (AH) is an appropriate choic= e for cases where the nodes share=0A>=A0 an appropriate security associati= on that enables the use of AH.=0A> =0A> UH> That only works for a single ho= p, not end-to-end, as the IP=0A> packets are not forwarded.=0A> =0A>=A0 In= particular, routing messages SHOULD be authenticated to avoid=0A>=A0 crea= tion of spurious routes to a destination.=A0 Otherwise, an attacker=0A>=A0 = could masquerade as that destination and maliciously deny service to=0A>= =A0 the destination and/or maliciously inspect and consume traffic=0A>=A0 = intended for delivery to the destination.=A0 RERR messages SHOULD be=0A>= =A0 authenticated in order to prevent malicious nodes from disrupting=0A>= =A0 active routes between communicating nodes.=0A> =0A>=A0 If the mobile = nodes in the ad hoc network have pre-established=0A>=A0 security associati= ons, the purposes for which the security=0A>=A0 associations are created s= hould include that of authorizing the=0A>=A0 processing of AODVv2 control = packets.=A0 Given this understanding, the=0A>=A0 mobile nodes should be ab= le to use the same authentication mechanisms=0A> =0A> =0A> =0A> Perkins & C= hakeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [= Page 35]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A> =0A> =0A>=A0 bas= ed on their IP addresses as they would have used otherwise.=0A> =0A> 5.15.= =A0 Acknowledgments=0A> =0A>=A0 AODVv2 is a descendant of the design of pr= evious MANET on-demand=0A>=A0 protocols, especially AODV [RFC3561] and DSR= [RFC4728].=A0 Changes to=0A>=A0 previous MANET on-demand protocols stem f= rom research and=0A>=A0 implementation experiences.=A0 Thanks to Elizabeth= Belding-Royer for=0A>=A0 her long time authorship of AODV.=A0 Additional = thanks to Luke Klein-=0A>=A0 Berndt, Pedro Ruiz, Fransisco Ros, Koojana Ku= ladinithi, Ramon=0A>=A0 Caceres, Thomas Clausen, Christopher Dearlove, Seu= ng Yi, Romain=0A>=A0 Thouvenin, Tronje Krop, Henner Jakob, Alexandru Petre= scu, Christoph=0A>=A0 Sommer, Cong Yuan, Lars Kristensen, and Derek Atkins= for reviewing of=0A>=A0 AODVv2, as well as several specification suggesti= ons.=0A> =0A>=A0 This revision of AODVv2 isolates the minimal base specifi= cation and=0A>=A0 other optional features to simplify the process of ensur= ing=0A>=A0 compatibility with the existing LOADng specification=0A>=A0 [I= -D.clausen-lln-loadng] (minimal reactive routing protocol=0A>=A0 specifica= tion).=A0 Thanks are due to T. Clausen, A. Colin de Verdiere,=0A>=A0 J. Yi= , A. Niktash, Y. Igarashi, Satoh.=A0 H., and U. Herberg for their=0A>=A0 d= evelopment of LOADng and sharing details for ensuring=0A>=A0 appropriatene= ss of AODVv2 for LLNs.=0A> =0A> =0A> 6.=A0 References=0A> =0A> 6.1.=A0 Norm= ative References=0A> =0A>=A0 [RFC1812]=A0 Baker, F., "Requirements for IP = Version 4 Routers",=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 RFC 1812, June 1995.=0A>= =0A>=A0 [RFC2119]=A0 Bradner, S., "Key words for use in RFCs to Indicate= =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 Requirement Levels", BCP 14, RFC 2119, Marc= h 1997.=0A> =0A>=A0 [RFC5082]=A0 Gill, V., Heasley, J., Meyer, D., Savola,= P., and C.=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 Pignataro, "The Generalized TTL = Security Mechanism=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 (GTSM)", RFC 5082, Octobe= r 2007.=0A> =0A>=A0 [RFC5444]=A0 Clausen, T., Dearlove, C., Dean, J., and = C. Adjih,=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 "Generalized Mobile Ad Hoc Network= (MANET) Packet/Message=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 Format", RFC 5444, F= ebruary 2009.=0A> =0A>=A0 [RFC5497]=A0 Clausen, T. and C. Dearlove, "Repre= senting Multi-Value=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 Time in Mobile Ad Hoc Ne= tworks (MANETs)", RFC 5497,=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 March 2009.=0A> = =0A>=A0 [RFC5498]=A0 Chakeres, I., "IANA Allocations for Mobile Ad Hoc Net= work=0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 =A0 Expires April 26, 20= 13=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 36]=0A> =0A> Internet-Draft=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = October 2012=0A> =0A> =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 (MANET) Protocols", = RFC 5498, March 2009.=0A> =0A> 6.2.=A0 Informative References=0A> =0A>=A0 = [I-D.clausen-lln-loadng]=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 Clausen, T., Verdie= re, A., Yi, J., Niktash, A., Igarashi,=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 Y., S= atoh, H., Herberg, U., Lavenu, C., Lys, T., and C.=0A>=A0 =A0 =A0 =A0 =A0 = =A0 =A0 Perkins, "The LLN On-demand Ad hoc Distance-vector Routing=0A>=A0 = =A0 =A0 =A0 =A0 =A0 =A0 Protocol - Next Generation (LOADng)",=0A>=A0 =A0 = =A0 =A0 =A0 =A0 =A0 draft-clausen-lln-loadng-05 (work in progress), July 20= 12.=0A> =0A>=A0 [Perkins99]=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 Perkins, C. and= E. Belding-Royer, "Ad hoc On-Demand=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 Distanc= e Vector (AODV) Routing", Proceedings of the 2nd=0A>=A0 =A0 =A0 =A0 =A0 =A0= =A0 IEEE Workshop on Mobile Computing Systems and=0A>=A0 =A0 =A0 =A0 =A0 = =A0 =A0 Applications, New Orleans, LA, pp. 90-100, February 1999.=0A> =0A>= =A0 [RFC2328]=A0 Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.= =0A> =0A>=A0 [RFC2501]=A0 Corson, M. and J. Macker, "Mobile Ad hoc Network= ing=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 (MANET): Routing Protocol Performance Is= sues and=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 Evaluation Considerations", RFC 250= 1, January 1999.=0A> =0A>=A0 [RFC3561]=A0 Perkins, C., Belding-Royer, E., = and S. Das, "Ad hoc On-=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 Demand Distance Vect= or (AODV) Routing", RFC 3561,=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 July 2003.=0A>= =0A>=A0 [RFC4193]=A0 Hinden, R. and B. Haberman, "Unique Local IPv6 Unica= st=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 Addresses", RFC 4193, October 2005.=0A> = =0A>=A0 [RFC4728]=A0 Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Sourc= e=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 Routing Protocol (DSR) for Mobile Ad Hoc N= etworks for=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 IPv4", RFC 4728, February 2007.= =0A> =0A>=A0 [RFC4861]=A0 Narten, T., Nordmark, E., Simpson, W., and H. So= liman,=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 "Neighbor Discovery for IP version 6 = (IPv6)", RFC 4861,=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 September 2007.=0A> =0A>= =A0 [RFC5148]=A0 Clausen, T., Dearlove, C., and B. Adamson, "Jitter=0A>=A0= =A0 =A0 =A0 =A0 =A0 =A0 Considerations in Mobile Ad Hoc Networks (MANETs)"= ,=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 RFC 5148, February 2008.=0A> =0A>=A0 [RFC= 5340]=A0 Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF=0A>=A0 =A0= =A0 =A0 =A0 =A0 =A0 for IPv6", RFC 5340, July 2008.=0A> =0A>=A0 [RFC6130]= =A0 Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc=0A>=A0 =A0 =A0 = =A0 =A0 =A0 =A0 Network (MANET) Neighborhood Discovery Protocol (NHDP)",=0A= >=A0 =A0 =A0 =A0 =A0 =A0 =A0 RFC 6130, April 2011.=0A> =0A> =0A> =0A> Perki= ns & Chakeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 [Page 37]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 2012=0A> =0A> =0A>= =A0 [RFC6549]=A0 Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-=0A>= =A0 =A0 =A0 =A0 =A0 =A0 =A0 Instance Extensions", RFC 6549, March 2012.=0A>= =0A>=A0 [RFC6621]=A0 Macker, J., "Simplified Multicast Forwarding", RFC 6= 621,=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 May 2012.=0A> =0A> =0A> Appendix A.=A0 = Changes since the Previous Version=0A> =0A>=A0 o=A0 Internet-Facing AODVv2= router renamed to be IAR=0A> =0A>=A0 o=A0 "Optional Features" section cre= ated to contain features not=0A>=A0 =A0 =A0 required within base specificat= ion, including:=0A> =0A>=A0 o=0A> =0A>=A0 =A0 =A0 *=A0 Intermediate RREPs = (iRREPs): Without iRREP, only the=0A>=A0 =A0 =A0 =A0 destination can respo= nd to a RREQ.=0A> =0A>=A0 =A0 =A0 *=A0 Precursor lists.=0A> =0A>=A0 =A0 =A0= *=A0 An RERR may reporting multiple unreachable nodes.=0A> =0A>=A0 =A0 =A0= *=A0 Message Aggregation.=0A> =0A>=A0 o=A0 Sequence number MUST (instead = of SHOULD) be set to 1 after=0A>=A0 =A0 =A0 rollover.=0A> =0A>=A0 o=A0 Thi= sNode MUST (instead of SHOULD) only handle AODVv2 messages from=0A>=A0 =A0 = =A0 adjacent routers.=0A> =0A>=A0 o=A0 Clarification that Additional Routi= ng information in RteMsgs is=0A>=A0 =A0 =A0 optional (MAY) to use.=0A> =0A>= =A0 o=A0 Clarification that if Additional Routing information in RteMsgs i= s=0A>=A0 =A0 =A0 used, then the Route Table Entry SHOULD be updated using n= ormal=0A>=A0 =A0 =A0 procedures as described in Section 5.2.2.=0A> =0A>=A0 = o=A0 Clarification in Section 5.4 that nodes may be configured to=0A>=A0 = =A0 =A0 buffer zero packets.=0A> =0A>=A0 o=A0 Clarification in Section 5.4= that buffered packets MUST be dropped=0A>=A0 =A0 =A0 if route discovery fa= ils.=0A> =0A>=A0 o=A0 In Section 5.5.1, relax mandate for monitoring conne= ctivity to=0A>=A0 =A0 =A0 next-hop AODVv2 neighbors (from MUST to SHOULD), = in order to allow=0A>=A0 =A0 =A0 for minimal implementations=0A> =0A> =0A> = =0A> =0A> Perkins & Chakeres=A0 =A0 =A0 Expires April 26, 2013=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 [Page 38]=0A> =0A> Internet-Draft=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 AODVv2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 201= 2=0A> =0A> =0A>=A0 o=A0 Remove Route.Forwarding flag; identical to "NOT" R= oute.Broken.=0A> =0A>=A0 o=A0 Routing Messages MUST be originated with the= MsgHdr.HopLimit set=0A>=A0 =A0 =A0 to MSG_HOPLIMIT.=A0 Previously, this wa= s not mandated.=0A> =0A>=A0 o=A0 Maximum hop count set to 254, with 255 re= served for "unknown".=0A>=A0 =A0 =A0 Since the current draft only uses hop-= count as distance, this is=0A>=A0 =A0 =A0 also the current maximum distance= .=0A> =0A> =0A> Appendix B.=A0 Shifting Network Prefix Advertisement Betwee= n AODVv2=0A>=A0 =A0 =A0 =A0 =A0 =A0 Routers=0A> =0A>=A0 Only one AODVv2 r= outer within a routing region SHOULD be responsible=0A>=A0 for a particula= r address at any time.=A0 If two AODVv2 routers=0A>=A0 dynamically shift t= he advertisement of a network prefix, correct=0A>=A0 AODVv2 routing behavi= or must be observed.=A0 The AODVv2 router adding=0A>=A0 the new network pr= efix must wait for any existing routing information=0A>=A0 about this netw= ork prefix to be purged from the network.=A0 Therefore,=0A>=A0 it must wai= t at least ROUTER_SEQNUM_AGE_MAX_TIMEOUT after the=0A>=A0 previous AODVv2 = router for this address stopped advertising routing=0A>=A0 information on = its behalf.=0A> =0A> =0A> Authors' Addresses=0A> =0A>=A0 Charles E. Perkin= s=0A>=A0 Futurewei Inc.=0A>=A0 2330 Central Expressway=0A>=A0 Santa Clar= a, CA=A0 95050=0A>=A0 USA=0A> =0A>=A0 Phone: +1-408-330-5305=0A>=A0 Emai= l: charliep@computer.org=0A> =0A> =0A>=A0 Ian D Chakeres=0A>=A0 CenGen=0A= >=A0 9250 Bendix Road North=0A>=A0 Columbia, Maryland=A0 21045=0A>=A0 US= A=0A> =0A>=A0 Email: ian.chakeres@gmail.com=0A>=A0 URI:=A0 http://www.ian= chak.com/=0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> Perkins & Chakeres=A0 =A0 = =A0 Expires April 26, 2013=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 39]=0A> __= _____________________________________________=0A> manet mailing list=0A> ma= net@ietf.org=0A> https://www.ietf.org/mailman/listinfo/manet=0A=0A_________= ______________________________________=0Amanet mailing list=0Amanet@ietf.or= g=0Ahttps://www.ietf.org/mailman/listinfo/manet ---1725615817-289807619-1352081235=:74797 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
No we should not.&nbs= p; That would be a waste of time if the WG decided to move forward with LOA= Dng.  I do not believe that we have arrived at that a decision.
Jon


From: JP Vasseur (jvasseur) <= jvasseur@cisco.com>
To:= Ulrich Herberg <ulrich@herberg.name>
Cc: "<manet@ietf.org>" <manet@ietf.org&g= t;
Sent: Sunday, Nove= mber 4, 2012 6:38 PM
Subject: Re: = [manet] DYMO-23 review

Hi,

I think that we ca= n agree with some of your comments.

Should we start opening tickets = and address those points ?

Thanks.

JP.

On Nov 1, 2012,= at 5:38 PM, Ulrich Herberg wrote:

> Hi,
>
> during = the discussion, I noticed that many just say "I like protocol
> foo1 = better than foo2", without any technical argument. That is not
> very= productive.
>
> Here is my review of the latest DYMO 23 draft= .
>
> The main comments (as shown in detail below) are:
>= ;  - The draft is still very difficult to read and is underspecified i= n
> many occasions. For example, it is unclear how the blacklisting w= orks,
> how metrics are used, how the TLVs are associated with certai= n
> addresses. Some of the parameters and TLVs specified in the IANA
> section are not used. There are at least four timers for each= route
> entry, and it is unclear how they may affect each other. It = is not
> clearly specified how to update forward/reverse routes + the= route to
> the previous hop
>  - The use of metrics is no= t well defined; there is an optional
> distance field. It is unclear = how metrics are created, whether they
> are additive, how they are fo= rmatted etc. What happens if some routers
> now the Distance field, o= thers don't use it.
>  - There are several extensions specified,= but too few details to
> assure interoperability. Some of them viola= te end-to-end security.
>  - As messages are modified in transit= , end-to-end security is not
> possible. The security considerations = section does not fulfill the
> requirements in RFC3552.
> = - Extensions, such as for security, cannot be hooked into AODVv2, as
> there is no section to allow an external mechanism to provide> additional reasons to reject a message as invalid, such as done in> RFC6130.
>  - The IANA section is not correct. There are = no requests, no new
> registries or code points in existing registrie= s, no allocation policy
> is provided.
>  - There are some= layer violations where tasks that are to be done by
> the RFC5444 (d= e)multiplexer are handled in AODVv2.
>  - There is a mandated or= der of addresses in RFC5444 messages; I
> think this is a bad idea if= extensions want to add addresses.
>  - Originator address and s= equence number are contained in address
> block and address block TLV= , instead of the message header, so there
> is additional overhead.>  - There is no RREP_ACK or other mechanism to verify bidirectio= nality
> of links.
>  - It is unclear to me how the destination sequence number is used in
> RREQ and what it serves for= .
>  - Intermediate route replies are hard to secure with signat= ures
>
> Best regards
> Ulrich
>
>
>=
> Mobile Ad hoc Networks Working Group        &= nbsp;                 C. Perkins> Internet-Draft               =                     &nbs= p;           Futurewei
> Intended status: S= tandards Track                 = ;           I. Chakeres
> Expires: April 26= , 2013                   =                     &nbs= p; CenGen
>                                  &nbs= p;                     Oc= tober 23, 2012
>
>
>          =       Dynamic MANET On-demand (AODVv2) Routing
> =                     &nbs= p; draft-ietf-manet-dymo-23
>
> Abstract
>
> = ; The Dynamic MANET On-demand (AODVv2) routing protocol is intended for>  use by mobile routers in wireless, multihop networks.
> =
> UH> It is really about dynamic topology, not "mobile routers". = AODVv2
> may be used in non-mobile mesh networks with a dynamic topol= ogy.
>
>    AODVv2
>  determines unicas= t routes among AODVv2 routers within the network in
>  an on-de= mand fashion, offering on-demand convergence in dynamic
>  topologies.
>
> UH> What is on-dema= nd convergence?
>
> Status of this Memo
>
> = This Internet-Draft is submitted in full conformance with the
>&nbs= p; provisions of BCP 78 and BCP 79.
>
>  Internet-Draft= s are working documents of the Internet Engineering
>  Task For= ce (IETF).  Note that other groups may also distribute
>  = working documents as Internet-Drafts.  The list of current Internet->  Drafts is at http://datatracker.ietf.org/drafts/current/.<= br>>
>  Internet-Drafts are draft documents valid for a max= imum of six months
>  and may be updated, replaced, or obsolete= d by other documents at any
>  time.  It is inappropriate = to use Internet-Drafts as reference
>  material or to cite them other than as "work in progress."
>
>  This Intern= et-Draft will expire on April 26, 2013.
>
> Copyright Notice>
>  Copyright (c) 2012 IETF Trust and the persons identi= fied as the
>  document authors.  All rights reserved.
= >
>  This document is subject to BCP 78 and the IETF Trust'= s Legal
>  Provisions Relating to IETF Documents
>  = (http:/= /trustee.ietf.org/license-info) in effect on the date of
>  = publication of this document.  Please review these documents
>&= nbsp; carefully, as they describe your rights and restrictions with respec= t
>  to this document.  Code Components extracted from thi= s document must
>  include Simplified BSD License text as descr= ibed in Section 4.e of
>  the Trust Legal Provisions and are provided without warranty as
>
>
>
> Perkins &a= mp; Chakeres      Expires April 26, 2013     = ;           [Page 1]
>
> Internet-Dr= aft                  AODVv2&n= bsp;                   Octobe= r 2012
>
>
>  described in the Simplified BSD Lic= ense.
>
>
> Table of Contents
>
>  1= .  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . = ; 4
>  2.  Terminology  . . . . . . . . . . . . . . .= . . . . . . . . . .  5
>  3.  Applicability Statemen= t  . . . . . . . . . . . . . . . . . . .  7
>  4.&nbs= p; Data Structures  . . . . . . . . . . . . . . . . . . . . . . . = ; 8
>    4.1.  Route Table Entry  . . . . . . . . . . . . . . . . . . . .  8
>    4.2.  A= ODVv2 Message Structure and Information Elements  . . . .  9
&= gt;    4.3.  RteMsg-specific Protocol Elements  . . . = . . . . . . . . . 11
>    4.4.  Route Error (RERR)-sp= ecific Protocol Elements  . . . . . . 12
>  5.  Detai= led Operation for the Base Protocol . . . . . . . . . . . 13
>  =   5.1.  AODVv2 Sequence Numbers  . . . . . . . . . . . . . = . . . . 13
>      5.1.1.  Maintaining A Node's O= wn Sequence Number . . . . . . . 13
>      5.1.2.&nbs= p; Actions After OwnSeqNum Loss . . . . . . . . . . . . . 13
>  =   5.2.  AODVv2 Routing Table Operations  . . . . . . . . . = . . . . 13
>      5.2.1.  Judging Routing Inform= ation's Usefulness . . . . . . . 13
>     =20 5.2.2.  Creating or Updating Route Table Entries . . . . . . . 15
= >      5.2.3.  Route Table Entry Timeouts . . . . .= . . . . . . . . . 15
>    5.3.  Routing Messages . .= . . . . . . . . . . . . . . . . . . . 16
>      5.3.= 1.  RREQ Creation  . . . . . . . . . . . . . . . . . . . . 16
= >      5.3.2.  RREP Creation  . . . . . . . . = . . . . . . . . . . . . 17
>      5.3.3.  RteMsg= Handling  . . . . . . . . . . . . . . . . . . . 18
>  &nbs= p; 5.4.  Route Discovery  . . . . . . . . . . . . . . . . . . . = . . 20
>    5.5.  Route Maintenance  . . . . . .= . . . . . . . . . . . . . . 21
>      5.5.1.  A= ctive Next-hop Router Adjacency Monitoring  . . . . . 21
> =     5.5.2.  Updating Route Lifetimes During Packet Forwarding  . . 22
>      5.5.3.  RERR Gen= eration  . . . . . . . . . . . . . . . . . . . 22
>   =   5.5.4.  RERR Handling  . . . . . . . . . . . . . . . . .= . . . 23
>    5.6.  Unknown Message and TLV Types&nb= sp; . . . . . . . . . . . . . . 24
>    5.7.  Adverti= sing Network Addresses  . . . . . . . . . . . . . . 24
>  &= nbsp; 5.8.  Simple Internet Attachment . . . . . . . . . . . . . . . = . 24
>    5.9.  Multiple Interfaces  . . . . . .= . . . . . . . . . . . . . 25
>    5.10. AODVv2 Control Pa= cket/Message Generation Limits  . . . . . 26
>    5.1= 1. Optional Features  . . . . . . . . . . . . . . . . . . . . 26
&g= t;      5.11.1. Expanding Rings Multicast  . . . . . .= . . . . . . . . 26
>      5.11.2. Intermediate RREP  . . . . . . . . . . . . . . . . . . 27
>&nbs= p;     5.11.3. Precursor Notification . . . . . . . . . . . . . = . . . 27
>      5.11.4. Reporting Multiple Unreachabl= e Nodes . . . . . . . . . 28
>      5.11.5. Message A= ggregation  . . . . . . . . . . . . . . . . . 28
>    =   5.11.6. Adding Additional Routing Information to a RteMsg  . .= 29
>    5.12. Administratively Configured Parameters and = Timer Values  . 30
>    5.13. IANA Considerations&nbs= p; . . . . . . . . . . . . . . . . . . . 33
>      5.= 13.1. AODVv2 Message Types Specification . . . . . . . . . . 33
>&nbs= p;     5.13.2. Message and Address Block TLV Type Specification = . . . 33
>      5.13.3. Address Block TLV Specificati= on  . . . . . . . . . . . 34
>
>
>
> Perkins & Chakeres      Expires April 26, 2013  &= nbsp;             [Page 2]
>
> = Internet-Draft                 = ; AODVv2                  &nb= sp; October 2012
>
>
>    5.14. Security Co= nsiderations  . . . . . . . . . . . . . . . . . 34
>   = ; 5.15. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . 36=
>  6.  References . . . . . . . . . . . . . . . . . . . .= . . . . . . 36
>    6.1.  Normative References . . .= . . . . . . . . . . . . . . . . 36
>    6.2.  Inform= ative References . . . . . . . . . . . . . . . . . . 37
>  Appe= ndix A.  Changes since the Previous Version  . . . . . . . . . 38=
>  Appendix B.  Shifting Network Prefix Advertisement Between
>            &nb= sp;   AODVv2 Routers  . . . . . . . . . . . . . . . . . . . 39>  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .= . . 39
>
>
>
>
>
>
>
&= gt;
>
>
>
>
>
>
>
>=
>
>
>
>
>
>
>
> >
>
>
>
>
>
>
>
&= gt;
>
>
>
>
>
>
>
>=
>
> Perkins & Chakeres      Expires Apri= l 26, 2013                [Page 3]=
>
> Internet-Draft            &= nbsp;     AODVv2             =       October 2012
>
>
> 1.  Overview
>
>  The Dynamic MANET On-demand (AOD= Vv2) routing protocol [formerly named
>  DYMO] enables on-deman= d, multihop unicast routing among AODVv2
>  routers in mobile a= d hod networks [MANETs][RFC2119].
>
> UH> Why is RFC2119 ci= ted here?
>
>    The basic
>  operations= of the AODVv2 protocol are route discovery and route
>  mainte= nance.  Route discovery is performed when an AODVv2 router must
>= ;  transmit a packet towards a destination for which it does not have= a
>  route.  Route maintenance is performed to avoid drop= ping packets,
>  when a route being used to forward packets fro= m the source to a
>  destination breaks,
>
> UH>= ; That is something that is unclear in the draft. Would data packets
>= ; be buffered on intermediate routers along their way? Would a new RREQ
> be issed from intermediate routers? If not, packets would be = dropped.
>
>  and to avoid prematurely expunging routes = from
>  the route table.
>
>  During route d= iscovery, an AODVv2 router initiates flooding of a
>  Route Req= uest message (RREQ) throughout the network to find a route
>  t= o a particular destination, via the AODVv2 router responsible for
>&n= bsp; this destination.  During this hop-by-hop flooding process, each=
>  intermediate AODVv2 router receiving the RREQ message recor= ds a route
>  to the originator.  When the target's AODVv2= router receives the
>  RREQ, it records a route to the origina= tor and responds with a Route
>  Reply (RREP) unicast hop-by-ho= p toward the originating AODVv2 router.
>  Each intermediate AO= DVv2 router that receives the RREP creates a
>  route to the target, and then the RREP is unicast hop-by-hop toward
>  = the originator.  When the originator's AODVv2 router receives the
&= gt;  RREP, routes have then been established between the originating<= br>>  AODVv2 router and the target AODVv2 router in both direction= s.
>
>  Route maintenance consists of two operations.&nb= sp; In order to preserve
>  routes in use, AODVv2 routers exten= d route lifetimes upon
>  successfully forwarding a packet.&nbs= p; In order to react to changes in
>  the network topology, AOD= Vv2 routers monitor traffic being forwarded.
>  When a data pac= ket is received for forwarding and a route for the
>  destinati= on is not known or the route is broken, then the AODVv2
>  rout= er of the source of the packet is notified.  A Route Error (RERR)
&= gt;  is transmitted to indicate the route to one or more affected
>  destination addresses is Broken
>
> U= H> s/Broken/broken/
>
>  or missing.  When the s= ource's AODVv2
>  router receives the RERR, it marks the route = as broken.  Before the
>  AODVv2 router can forward a pack= et to the same destination, it has to
>  perform route discover= y again for that destination.
>
>  Similarly to AODV, AO= DVv2 uses sequence numbers to ensure loop
>  freedom [Perkins99= ].
>
> UH> Citation to AODV missing. Is AODVv2 updating or = obsoleting AODV?
>
>    Sequence numbers enable AODV= v2 routers to
>  determine the temporal order of AODVv2 route d= iscovery messages,
>  thereby avoiding use of stale routing inf= ormation.  Also, AODVv2 uses
>  RFC 5444 message and TLV f= ormats.
>
> UH> As this is the successor to AODV, it would help to point out what
> has been improved/changed compared to= AODV.
>
>
>
>
>
>
> Perkin= s & Chakeres      Expires April 26, 2013    &= nbsp;           [Page 4]
>
> Interne= t-Draft                  AODV= v2                    Oc= tober 2012
>
>
> 2.  Terminology
>
>&= nbsp; The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",<= br>>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "M= AY", and
>  "OPTIONAL" in this document are to be interpreted a= s described in
>  [RFC2119].
>
>  Additional= ly, this document uses some terminology from [RFC5444].
>
> UH= > Which one?
>
>  This document defines the following terminology:
>
>  Adjacency
>  &nb= sp;   A relationship between selected bi-directional neighboring route= rs
>      for the purpose of exchanging routing inform= ation.  Not every pair
>      of neighboring rout= ers will necessarily form an adjacency.
>      Neighbo= ring routers may form an adjacency based on various
>    &n= bsp; information or other protocols; for example, exchange of AODVv2
>= ;      routing messages, other protocols (e.g.  NDP [RF= C4861] or NHDP
>      [RFC6130]), or manual configurat= ion.  Loss of a routing adjacency
>      may also= be based upon similar information; monitoring of
>    &nbs= p; adjacencies where packets are being forwarded is required (see
>&n= bsp;     Section 5.5.1).
>
>  Distance (Dist)
>      An unsigned integer which measures the = distance a message or
>      information element has t= raversed.  The minimum value of distance
>      i= s the number of IP hops traversed, 0 for local information.  The
&g= t;      maximum value is 254.  The value 255 is reserve= d to indicate that
>      the distance is unknown.
= >
> UH> Is this a metrics? Why integer and not float? Is this = additive?
> Why is it optional in the draft. Are there different metr= ic types
> supported in the same network?
>
>
>&n= bsp; AODVv2 Sequence Number (SeqNum)
>      An AODVv2= Sequence Number is an unsigned integer maintained by
>    =   each AODVv2 router.  This sequence number guarantees the tempor= al
>      order of routing information to maintain loop-free routes.  The
>      value zer= o (0) is reserved to indicate that the SeqNum for a
>    &n= bsp; destination address is unknown.
>
> UH> The last sente= nce is unclear. The first sentence said there is one
> seq. number pe= r router. The last sentence talks about sequence numbers
> for destin= ations, which is a different thing.
>
>  reactive
>= ;      A protocol operation is said to be "reactive" if it i= s performed
>      only in reaction to specific events= .  As used in this document,
>      "reactive" is= essentially synonymous with "on-demand".
>
>  Router Cl= ient
>      An AODVv2 router may be configured with a = list of other IP
>      addresses and networks which c= orrespond to other non-router nodes
>      which require the services of the AODVv2 router for route
>  &n= bsp;   discovery and maintenance.  An AODVv2 is always its own cl= ient, so
>      that the list of client IP addresses i= s never empty. corresponds
>
> UH> s/corresponds/Correspond= s/
>
>
>
> Perkins & Chakeres    &= nbsp; Expires April 26, 2013            &nbs= p;   [Page 5]
>
> Internet-Draft      &nb= sp;           AODVv2        &= nbsp;           October 2012
>
> >      to the AODVv2 router process currently performing= a calculation or
>      processing a message.
>=
> UH> I don't think it is a good idea to introduce that terminol= ogy. It
> seems to be conflicting with the IP architecture of hosts and routers.
> Is a Router Client a host?
>
>&nbs= p; Flooding
>      In this document, flooding a messa= ge refers to the process of
>      delivering the mess= age to every AODVv2 router in the network.
>      This= may be done according to methods specified in [RFC5148].
>
> = UH> RFC5148 describes jitter in MANETs, not flooding methods.
> >  Routable Unicast IP Address
>      A rou= table unicast IP address is a unicast IP address that when
>  &n= bsp;   put into the IP.SourceAddress or IP.DestinationAddress field is=
>
> UH> Notation not defined: "IP.x"
>
> = ;     scoped sufficiently to be forwarded by a router.
> > UH> I am not quite sure what that means. Can you cite an RFC, may= be RFC4007?
>
>        Globally-scoped
>      unicast IP addresses and Uniqu= e Local Addresses (ULAs) [RFC6130]
>      are examples= of routable unicast IP addresses.
>
> UH> RFC6130 is NHDP,= not ULA. ULA's are not globally routable and
> cannot be accessed fr= om outside a "site".
>
>  Originating Node (OrigNode)>      The originating node is the data source node; if = it is not itself
>      an AODVv2 router, its AODVv2 r= outer creates a AODVv2 RREQ message
>      on its beha= lf in an effort to flood some routing information.  The
>  =     originating node is also referred to as a particular message'= s
>      originator.
>
>  Target No= de (TargetNode)
>      The TargetNode denotes the ulti= mate destination of a message.
>
> UH> Is this for control packets only or for data traffic? Is that an IP address?
> <= br>>  This Node (ThisNode)
>      ThisNode de= notes the AODVv2 router currently processing an AODVv2
>   =   message.
>
>  Route Error (RERR)
>  &= nbsp;   A RERR message is used to indicate that an AODVv2 router no lo= nger
>      has a route to one or more particular dest= inations.
>
> UH> Or it may have one, and data traffic was = lost when sending it to
> the next hop
>
>  Route = Reply (RREP)
>      A RREP message is used to supply r= outing information about the
>      RREQ TargetNode to= the RREQ OrigNode and the AODVv2 routers
>      betwe= en them.
>
>  Route Request (RREQ)
>    =   An AODVv2 router uses a RREQ message to discover a valid route to
>      a particular destination address, cal= led the RREQ TargetNode.
>      When an AODVv2 router = processes a RREQ, it learns routing
>      information= on how to reach the RREQ OrigNode.
>
>  Type-Length-Val= ue structure (TLV)
>      A generic way to represent i= nformation as specified in [RFC5444].
>
>
>
> >
> Perkins & Chakeres      Expires April 2= 6, 2013                [Page 6]>
> Internet-Draft            &nbs= p;     AODVv2              &n= bsp;     October 2012
>
>
>  Unreachab= le Node (UnreachableNode)
>      An UnreachableNode is= a node for which a forwarding route is
>      unknown.
>
> UH> Or to which data traffic has been lost wh= ile forwarding to the next hop.
>
>
> 3.  Applicab= ility Statement
>
>  The AODVv2 routing protocol is desi= gned for stub (i.e., non-transit)
>  or disconnected (i.e., fro= m the Internet) mobile ad hoc networks
>  (MANETs).  AODVv= 2 handles a wide variety of mobility patterns by
>  dynamically= determining routes on-demand.  AODVv2 also handles a wide
>&nbs= p; variety of traffic patterns.  In networks with a large number of>  routers, AODVv2 is best suited for sparse traffic scenarios w= here any
>  particular router forwards packets to only a small = percentage of the
>  AODVv2 routers in the network, due to the = on-demand nature of route
>  discovery and route maintenance.>
>  AODVv2 is applicable to memory constrained devices, since little
>  routing state is maintained in each A= ODVv2 router.  Only routing
>  information related to rout= es between active sources and destinations
>  is maintained, in= contrast to proactive routing protocols that
>  require routin= g information to all routers within the routing region
>  be ma= intained.
>
>  AODVv2 supports routers with multiple int= erfaces.  In addition to
>  routing for their local proces= ses, AODVv2 routers can also route on
>  behalf of other non-ro= uting nodes (i.e., "hosts"), reachable via
>  those interfaces.=   Any such node which is not itself an AODVv2 router
>  SH= OULD NOT be served by more than one AODVv2 router.
>
> UH> = I would rather not use RFC2119 in an applicability statement. This
> = is not normative.
>
>  Although AODVv2
>  is closely related to AODV [RFC3561], and has some o= f the features of
>  DSR [RFC4728], AODVv2 is not interoperable= with either of those other
>  two protocols.
>
>&= nbsp; AODVv2 routers perform route discovery to find a route to a
>&= nbsp; particular destination.  Therefore, AODVv2 routers MUST must be=
>  configured to respond to RREQs for a certain set of address= es.  When
>  AODVv2 is the only protocol interacting with = the forwarding table,
>  AODVv2 MAY be configured to perform ro= ute discovery for all unknown
>  unicast destinations.
> =
>  At all times within an AODVv2 routing region, only one AODV= v2 router
>  SHOULD be serve any routing client.  The coor= dination among multiple
>  AODVv2 routers to distribute routing= information correctly for a
>  shared address (i.e. an address that is advertised and can be reached
>  via multiple = AODVv2 routers) is not described in this document.  The
>  = AODVv2 router operation of shifting responsibility for a routing
>&n= bsp; client from one AODVv2 router to another is mentioned in Appendix B>
> UH> I am not sure that it is a good idea to include mult= i-homing in a
> short paragraph in Appendix B. I think this whole sec= tion can be
> removed.
>
>
>  Each AODVv2 r= outer, if serving router clients other than itself, is
>
> >
> Perkins & Chakeres      Expires April 26= , 2013                [Page 7]
= >
> Internet-Draft             = ;     AODVv2              &nb= sp;     October 2012
>
>
> =20 configured with information about the IP addresses of its clients.
>=   There is no requirement that an AODVv2 router have information abou= t
>  the router clients of other AODVv2 routers.  Address = assignment
>  procedures are entirely out of scope for AODVv2.<= br>>
>  AODVv2 only utilizes bidirectional links.  In = the case of possible
>  unidirectional links, either blacklists= (see Section 5.13.2) or other
>  means (e.g. adjacency establi= shment with only neighboring routers
>  that have bidirectional= communication as indicated by NHDP [RFC6130])
>
> UH> The = blacklisting is not specified in this document.
>
>  of = ensuring and monitoring bi-directionality is recommended.
>  Ot= herwise, persistent packet loss could occur.
>
>  The ro= uting algorithm in AODVv2 may be operated at layers other than
>  the network layer, using layer-appropriate addresses.<= br>>
> UH> Yes, but the whole document is limited to IP. It is= tied to IP
> headers, UDP etc at multiple places.
>
>&n= bsp;   The routing
>  algorithm makes
>
> UH= > + "use"
>
>  of some persistent state; if there is = no persistent
>  storage available for this state, recovery can= exact a performance
>  penalty in case of AODVv2 router reboot= s.
>
>
> 4.  Data Structures
>
> UH&g= t; There is a mixture between information bases and message formats.
>= ; I would rather have two seperate sections for that.
> UH> There = are no other information sets that I believe are required
> for AODV:= blacklisted set, set of local interfaces, and a set of the
> hosts t= hat this router is responsible.
>
> 4.1.  Route Table Entry
>
>  The route table entry is a conceptual = data structure.
>  Implementations may use any internal represe= ntation so long as it
>  provides access to the same informatio= n as specified below.
>
>  Conceptually, a route table e= ntry has the following fields:
>
>  Route.Address
>= ;      The (host or network) destination address of the node= (s)
>      associated with the routing table entry.>
>  Route.Prefix
>      The value is= the length of the netmask/prefix.
>
> UH> in octets?
&g= t;
>      If the value of
>     = ; the Route.Prefix is different than the length of addresses in the
>=       address family used by the AODVv2 routers, the associa= ted address
>      is a routing prefix, rather than a host address.
>
>  Route.SeqNum
>  &n= bsp;   The AODVv2 SeqNum associated with a route table entry.
> =
>  Route.NextHopAddress
>      An IP addr= ess of the adjacent AODVv2 router on the path toward the
>  &nbs= p;   Route.Address.
>
>
>
>
>
&g= t;
>
> Perkins & Chakeres      Expires Ap= ril 26, 2013                [Page = 8]
>
> Internet-Draft           =       AODVv2            &nbs= p;       October 2012
>
>
>  Rout= e.NextHopInterface
>      The interface used to send p= ackets toward the Route.Address.
>
>  Route.Broken
&g= t;      A flag indicating whether this Route is broken.  This flag is set
>      to true if the = next-hop becomes unreachable or in response to
>      = processing to a RERR (see Section 5.5.4).
>
>  The follo= wing field is optional:
>
>  Route.Dist
>  &n= bsp;   A dimensionless metric indicating the distance traversed before=
>      reaching the Route.Address node.
>
&= gt; UH> Why is this optional? It makes the whole specification more
&= gt; complicated, in particular interoperability. I cannot imagine cases
= > where you are not interested in the distance.
> UH> Is this m= etric additive? is it only integer? is it used in
> addition to hop-c= ount or instead?
>
>  Not including optional information= may cause performance degradation,
>  but it will not prohibit= the protocol from discovering valid routes.
>
> =20 In addition to a route table data structure, each route table entry
>= ;  may have several timers associated with the information.  Tim= ers and
>  timeouts are discussed in Section 5.2.3.
> > UH> That forward link makes it difficult. Why not include the
&= gt; expiration timers here, similar to OLSRv2?
>
> 4.2.  = AODVv2 Message Structure and Information Elements
>
>  I= P Protocol Number 138 (manet) has been reserved for MANET protocols
>=   [RFC5498].  In addition to using this IP protocol number, AODV= v2 may
>  use UDP at destination port 269 (manet) [RFC5498].>
> UH> may or MAY?
>
>  AODVv2 messages a= re transmitted in packets that conform to the
>  generalized pa= cket and message format as described in [RFC5444].
>  Here is a= brief description of the format.
>
>
>      A packet formatted according to RFC5444 contains zero or mor= e
>      messages.
>
>
>  &nb= sp;   A message contains a message header, message TLV block, and zero=
>      or more address blocks.
>
>
&= gt;      Each of the address blocks may also have an associa= ted address TLV
>      block.
>
> UH> = Each address block *must* have a TLV block (it may be empty though).
>= ;
>  All AODVv2 messages SHOULD be sent using the IP protocol = number (138)
>  reserved for manet protocols [RFC5498]; or the = UDP destination port
>  (269) reserved for manet protocols [RFC= 5498] and IP protocol number
>  for UDP.
>
> UH>= ; That is redundant to the first paragraph of this section.
>
>= ;
>
>
> Perkins & Chakeres      Expires April 26, 2013            &n= bsp;   [Page 9]
>
> Internet-Draft      &= nbsp;           AODVv2       =             October 2012
>
> <= br>>  Most AODVv2 messages are sent with the IP destination addres= s set to
>  the link-local multicast address LL-MANET-Routers [= RFC5498] unless
>  otherwise specified.  Therefore, all AO= DVv2 routers SHOULD subscribe
>  to LL-MANET-Routers [RFC5498] = to receiving AODVv2 messages.  Note
>  that multicast pack= ets MAY be sent via unicast.
>
> UH> That sounds confusing:= multicast packets MAY be sent via unicast.
> First, what is a multic= ast packet? (you mean an IP packet with a
> multicast destination add= ress>). Why MAY?
>
>    For example, this
>  may occur for certain link-types (non broadcast medium= s), for
>  manually configured router adjacencies, or in order = to improve
>  robustness.
>
> UH> How would one= manually configure a router adjacency?
>
>  When descri= bing AODVv2 protocol messages, it is necessary to refer to
>  f= ields in several distinct parts of the overall packet.
>
> UH&= gt; Since there is an RFC5444 demultiplexer, AODVv2 would never see
>= the packet. So I think it's better not to use that term here.
>
= >    These
>  locations include the IP header, the= UDP header, and fields from
>  [RFC5444].  This document = uses the notational conventions found in
>  table 1.
> >            +-------------------------= --+-------------------+
>            |    Information Location  | Notational Prefix |>            +-------------------------= --+-------------------+
>            |=         IP header        |  =       IP.        |
>    =         |  RFC5444 message header  |  =     MsgHdr.      |
>      &nb= sp;     |    RFC5444 message TLV    |  =     MsgTLV.      |
>      &nb= sp;     |  RFC5444 address blocks  |    &nb= sp; AddBlk.      |
>         =   | RFC5444 address block TLV |      AddTLV.  &n= bsp;   |
>           =20 +---------------------------+-------------------+
>
>  &= nbsp;                    =           Table 1
>
>  The IPv= 4 TTL (IPv6 Hop Limit) field for all packets containing AODVv2
> = ; messages is set to 255.
>
> UH> I think that's the job o= f the RFC5444 multiplexer.
>
>    If a packet is rec= eived with a value other
>  than 255, any AODVv2 message contai= ned in the packet MUST be ignored
>  by AODVv2.
>
>= ; UH> No, the packet would never be received by AODVv2. Only a message w= ould.
>
>    This mechanism, known as "The Generali= zed TTL Security
>  Mechanism" (GTSM) [RFC5082] helps to ensure= that packets have not
>  traversed any intermediate routers.>
> UH> Again, part of the RFC5444 multiplexer.
>
>  The length of an address (32 bits for= IPv4 and 128 bits for IPv6)
>  inside an AODVv2 message depend= s on the msg-addr-length (MAL) in the
>  msg-header, as specifi= ed in [RFC5444].
>
> UH> Limitation of AODVv2 to IP address= es. It could also be used for
> compressed (lowpan) addresses or MAC = addresses.
>
>  IP packets containing AODVv2 protocol me= ssages SHOULD be given
>  priority queuing and channel access.<= br>>
> UH> Not the task of AODVv2, but the RFC5444 multiplexer=
>
>  AODVv2 messages require the following information:=
>
>  IP.SourceAddress
>      The I= P address of the node currently sending this packet.  This
>&nbs= p;     field is generally filled automatically by the operating s= ystem
>      and should not require special handling.
>
> UH> An AODVv2 message cannot have an IP addr= ess. That's a different
> layer. The IP packet that contains an RFC54= 44 packet (which the IP
> layer received from the RFC5444 multiplexer= ) has that address.
> Also, it is not necessarily the node currently = sending this "packet";
> ThisNode could receive a message, then it is= not sending this packet.
>
>
>
>
> Perki= ns & Chakeres      Expires April 26, 2013    =             [Page 10]
>
> Intern= et-Draft                  AOD= Vv2                    O= ctober 2012
>
>
>  IP.DestinationAddress
>&= nbsp;     The IP address of the packet destination.  For mul= ticast messages
>      the IP.DestinationAddress is set to LL-MANET-Routers [RFC5498].
>  =     For unicast messages the IP.DestinationAddress is set to the<= br>>      NextHopAddress toward the TargetNode.
> <= br>>  MsgHdr.HopLimit
>      The remaining nu= mber of hops this message is allowed to traverse.
>    &nbs= p; If an AODVv2 message within a RFC 5444 packet has exhausted its
>&= nbsp;     hop limit, then it should be removed from the packet.>
> UH> This seems to be mixing normative protocol behavior = with field
> definitions.
>
> 4.3.  RteMsg-specific= Protocol Elements
>
>  AODVv2 message types RREQ and RR= EP are denoted as Routing Messages
>  (RteMsgs) and used to flo= od routing information.
>
> UH> RREPs are not flooded.
&= gt;
>    RREQ and RREP have
>  similar information and function, but have slightly different
>  handl= ing rules.  The main difference between the two messages is that
&g= t;  RREQ messages are generally broadcast to solicit a RREP, and
&= gt;  conversely a RREP is the unicast response to RREQ.  RteMsg = creation
>  and handling are described in Section 5.3.
> =
>  Unicast AODVv2 RteMsgs (e.g.  RREP) unless otherwise s= pecified are
>  sent with the IP destination set to the Route.N= extHopAddress of the
>  route to the TargetNode.
>
&g= t;  A RteMsg REQUIRES the following information in addition to the fi= elds
>  indicated in Section 4.2:
>
> UH> REQUI= RES is not RFC2110, it's REQUIRED
>
>  AddBlk.TargetNode= .Address
>      The IP address of the message TargetNo= de.  In a RREQ the IP
>      address of the message TargetNode is the destination address for
>   =   which route discovery is being performed.  In a RREP the
&g= t;      TargetNode is the RREQ OrigNode address.  The T= argetNode address
>      is the first address in a rou= ting message.
>
> UH> I don't think it's a good idea to man= date order of addresses.
> Other extensions to the protocol may add a= ddresses before. It would be
> better to associate with an address bl= ock TLV.
>
>  AddBlk.OrigNode.Address
>  &nbs= p;   The IP address of the originator and its associated prefix length= .
>      In a RREQ the OrigNode is the source's addres= s and prefix.  In a
>      RREP the OrigNode is t= he RREQ TargetNode's address and prefix for
>      whi= ch a RREP is being generated.  This address is the second
>      address in the message for RREQ.
>= ;
> UH> Again, mandating address order is dangerous.
>
= >  OrigNode.AddTLV.SeqNum
>      The AODVv2 s= equence number of the originator's AODVv2 router.
>
> UH> W= hy not use the message sequence number? This will save several
> byte= s. Or at least a message TLV.
>
>  A RteMsg may optional= ly include the following information:
>
>
>
> >
> Perkins & Chakeres      Expires April 2= 6, 2013                [Page 11]>
> Internet-Draft            &nbs= p;     AODVv2              &n= bsp;     October 2012
>
>
>  TargetNod= e.AddTLV.SeqNum
>      The last known AODVv2 sequence number of the TargetNode.
>
> UH> Using which TLV= type? (reference to IANA section)
>
>  AddBlk.Additiona= lNode.Address
>      The IP address of an additional n= ode that can be reached via the
>      AODVv2 router a= dding this information.  Each
>      AdditionalNo= de.Address MUST include its prefix.  Each
>      = AdditionalNode.Address MUST also have an associated Node.SeqNum in
>&= nbsp;     the address TLV block.
>
> UH> Is Node.= foo defined before?
>
>  AdditionalNode.AddTLV.SeqNum>      The AODVv2 sequence number associated with this r= outing
>      information.
>
> UH> Wha= t is AdditionalNode?
>
>  OrigNode.AddTLV.Dist
>&n= bsp;     A metric of the distance to reach the associated OrigNode.Address.
>      This field is incremented by= at least one at each intermediate
>      AODVv2 route= r.
>
> UH> Why not use a message TLV?
>
> = ; AdditionalNode.AddTLV.Dist
>      A metric of the d= istance to reach the associated
>      AdditionalNode.= Address.  This field is incremented by at least one
>  &nbs= p;   at each intermediate AODVv2 router.
>
> 4.4.  R= oute Error (RERR)-specific Protocol Elements
>
>  A RERR= message is used to flood the information that a route is not
> = available for one or more particular addresses.
>
> UH> R= ERR are mostly sent unicast, not flooded.
>
>  RERR crea= tion and handling are described in Section 5.5.
>
>  A R= ERR requires the following information in addition to the field
>  indicated in Section 4.2:
>
>  Add= Blk.UnreachableNode.Address
>      The address of an U= nreachableNode and its associated prefix
>      length= .  Multiple unreachable addresses may be included in a RERR.
> <= br>>  A Route Error may optionally include the following informati= on:
>
>  UnreachableNode.AddTLV.SeqNum
>  &nb= sp;   The last known AODVv2 sequence number of the unreachable node.&n= bsp; If
>      a SeqNum for an address is zero (0) or = not included, it is assumed
>      to be unknown. = ; This case occurs when a node receives a message to
>    &= nbsp; forward to a destination for which it does not have any
> =     information in its routing table.
>
>
> =
>
>
> Perkins & Chakeres      Expires April 26, 2013            &n= bsp;   [Page 12]
>
> Internet-Draft      &= nbsp;           AODVv2       =             October 2012
>
> <= br>> 5.  Detailed Operation for the Base Protocol
>
> = 5.1.  AODVv2 Sequence Numbers
>
>  AODVv2 sequence = numbers allow AODVv2 routers to judge the freshness
>  of routi= ng information and consequently ensure loop freedom.
>
> 5.1.1= .  Maintaining A Node's Own Sequence Number
>
>  AO= DVv2 requires that each AODVv2 router in the network maintain its
>&n= bsp; own AODVv2 sequence number (OwnSeqNum).  OwnSeqNum a 16-bit unsi= gned
>  integer.  An AODVv2 router increments its OwnSeqNu= m under the
>  circumstances described in Section 5.3.
>
>  Incrementing an OwnSeqNum whose value is the = largest largest possible
>  number representable as a 16-bit un= signed integer (i.e., 65,535),
>  MUST be set to one (1). = In other words, the sequence number after
>  65,535 is 1.
&= gt;
> 5.1.2.  Actions After OwnSeqNum Loss
>
>&nbs= p; An AODVv2 router SHOULD maintain its own sequence number in
>&nbs= p; persistent storage.
>
>  If an AODVv2 router's OwnSe= qNum is lost, it MUST take certain actions
>  to avoid creating= routing loops.  To prevent this possibility after
>  OwnS= eqNum loss an AODVv2 router MUST wait for at least
>  ROUTE_DEL= ETE_TIMEOUT before fully participating in the AODVv2 routing
>  = protocol.  If an AODVv2 protocol message is received during this
&= gt;  waiting period, the AODVv2 router SHOULD perform normal route table
>  entry updates but MUST NOT transmit or retransm= it any AODVv2 RREQ or
>  RREP messages.  If a data packet = is received for forwarding to
>  another destination during thi= s waiting period, the AODVv2 router
>  MUST transmit a RERR mes= sage indicating that this route is not
>  available and reset i= ts waiting timeout.  At the end of the waiting
>  period t= he AODVv2 router sets its OwnSeqNum to one (1) and begin
>  par= ticipating.
>
>  The longest a node need wait is ROUTE_S= EQNUM_AGE_MAX_TIMEOUT.  At the
>  end of the maximum waiti= ng period a node SHOULD set its OwnSeqNum to
>  one (1) and beg= ins participating.
>
> 5.2.  AODVv2 Routing Table Operati= ons
>
> UH> This whole structure is unclear. Where do we co= me to this?
> Wouldn't it be better to start of with message generation/processing
> before saying how to update the routing tupl= es as a consequence to
> received messages?
>
> 5.2.1.&n= bsp; Judging Routing Information's Usefulness
>
>  Given= a route table entry (Route.SeqNum, Route.Dist, and
>  Route.Br= oken)
>
> UH> A route table entry has more fields in sectio= n 4.1
>
>  and incoming routing information for a partic= ular
>
>
>
> Perkins & Chakeres   =   Expires April 26, 2013            &n= bsp;   [Page 13]
>
> Internet-Draft      &= nbsp;           AODVv2       =             October 2012
>
> <= br>>  destination in a RteMsg (Node.SeqNum, Node.Dist, and RteMsg = message
>  type - RREQ/RREP), the incoming routing information is classified as
>  follows:
>
> = ; 1. Stale (Node.SeqNum < Route.SeqNum)
>      If = Node.SeqNum < Route.SeqNum (using signed 16-bit arithmetic) the
>&= nbsp;     incoming information is stale.  Using stale routin= g information is
>      not allowed, since that might = result in routing loops.
>
> UH> So what should my implemen= tation then? Continue with the next
> step? Discard the message?
&= gt;
>  2. Not safe against loops
>      I= f Node.SeqNum =3D=3D Route.SeqNum, additional information MUST be
>&n= bsp;     examined.  If Route.Dist or Node.Dist is unknown or= zero (0), or
>      if Node.Dist > Route.Dist + 1,= then the incoming information is
>      not guarantee= d to prevent routing loops.  Using such incoming
>      routing information is not allowed.  The following pseu= docode is
>      offered to indicate the logical condi= tion under which the incoming
>      information is no= t guaranteed to protect against loops.
>
>     = (Node.SeqNum =3D=3D Route.SeqNum) AND
>      ((Node.D= ist > Route.Dist + 1) OR
>
> UH> Would cause a null-poin= ter exception in my implementation if Dist
> is not contained in the = message.
>
>      (Route.Dist is unknown) OR (= Node.Dist is unknown))
>
>  3. Offers no improvement
= >      In case of known equal SeqNum, the information is = considered worse
>      than the existing route table = information in multiple cases: (case
>      i) if Node= .Dist > Route.Dist (it is a more expensive route) AND
>      Route.Broken =3D=3D false; (case ii) if Node.Dist =3D=3D Rou= te.Dist (equal
>      distance route) AND Route.Broken= =3D=3D false AND this RteMsg is a
>      RREQ.  = Such RREQs offer no improvement and SHOULD NOT be
>    &nbs= p; retransmitted.  Updating route table entries using such incoming>      routing information is not allowed.
>
&= gt;      ((Node.SeqNum =3D=3D Route.SeqNum) AND
> = ;         (((Node.Dist > Route.Dist) AND (Route.Brok= en =3D=3D false)) OR
>            ((Nod= e.Dist =3D=3D Route.Dist) AND
>          &nb= sp; (RteMsg is RREQ) AND (Route.Broken =3D=3D false))))
>
>&n= bsp; 4. Offers improvement
>      Incoming routing in= formation that does not match any of the above
>      = criteria is loop-free and better than the existing routing table
>      inf= ormation.  We provide the following pseudo-code to determine
>&n= bsp;     whether incoming routing information should be used to u= pdate an
>      existing route table entry.
> >      (/* signed 16-bit arithmetic */ Node.SeqNum - Ro= ute.SeqNum > 0) OR
>      ((Node.SeqNum =3D=3D Rout= e.SeqNum) AND
>          [(Node.Dist < Ro= ute.Dist) OR
>          ((Route.Broken =3D= =3D true) AND (Node.Dist <=3D Route.Dist + 1)) OR
>
>
&= gt;
> Perkins & Chakeres      Expires April 26, = 2013                [Page 14]
&g= t;
> Internet-Draft              =     AODVv2               = ;     October 2012
>
>
>      =     ((RteMsg is RREP) AND (Node.Dist =3D=3D Route.Dist)]
> =
> 5.2.2.  Creating or Updating Route Table Entries
>
= >  Each route table entry is populated with the following informat= ion:
>
> UH> Why "each" entry? When does this happen? It se= ems this only sets
> the route to the previous hop; what happens with= a route to the
> originator? What happens if a route already exists = and is only
> updated? How are both forward and reverse routes update= d?
>
>  1.  the Route.Address is set to Node.Addres= s,
>
>  2.  the Route.Prefix is set to the Node.Pre= fix.
>
>  3.  the Route.SeqNum is set to the Node.S= eqNum,
>
>  4.  the Route.NextHopAddress is set to = the IP.SourceAddress (i.e., an
>      address of the node that last transmitted the RteMsg packet)
>
>  = 5.  the Route.NextHopInterface is set to the interface on which the>      incoming AODVv2 packet was received,
> >  6.  the Route.Broken flag is set to false,
>
&g= t;  7.  if known, the Route.Dist is set to the Node.Dist,
>= ;
>  The timer for the minimum delete timeout (ROUTE_AGE_MIN) = is set to
>  ROUTE_AGE_MIN_TIMEOUT.  The timer for the max= imum delete timeout
>  (ROUTE_SEQNUM_AGE_MAX) is set to Node.Ad= dTLV.VALIDITY_TIME [RFC5497]
>  if included; otherwise, ROUTE_S= EQNUM_AGE_MAX is set to
>  ROUTE_SEQNUM_AGE_MAX_TIMEOUT.  = The usage of these timers and others
>  are described in Sectio= n 5.2.3.
>
> UH> I don't understand how a sequence number c= an expire. Also, in
> section 4.1 there was no mention of the VALIDITY_TIME Tlv in a
> message. What happens if it is not containe= d?
>
>  With these assignments to the route table entry,= a route has been
>  created and the Route.Forwarding flag set.=   Afterward, the route can
>  be used to send any buffered= data packets and to forward any incoming
>  data packets for R= oute.Address.  This route also fulfills any
>  outstanding= route discovery (RREQ) attempts for Node.Address.
>
> 5.2.3.&= nbsp; Route Table Entry Timeouts
>
> 5.2.3.1.  Minimum De= lete Timeout (ROUTE_AGE_MIN)
>
>  When an AODVv2 router = transmits a RteMsg, other AODVv2 routers expect
>  the transmit= ting AODVv2 router to have a forwarding route to the
>  RteMsg = originator.  A route table entry SHOULD be kept in the route
>&n= bsp; table for at least ROUTE_AGE_MIN after it has been updated.  Failure
>  to maintain the route table entry mi= ght result in lost messages/
>  packets, or several duplicate m= essages.
>
>  After the ROUTE_AGE_MIN timeout a route ca= n safely be deleted.
>
>
>
>
> Perkins &a= mp; Chakeres      Expires April 26, 2013     = ;           [Page 15]
>
> Internet-Dr= aft                  AODVv2&n= bsp;                   Octobe= r 2012
>
>
> 5.2.3.2.  Maximum Sequence Number Del= ete Timeout (ROUTE_SEQNUM_AGE_MAX)
>
>  Sequence number = information for route table entries is time
>  sensitive, and M= UST be deleted after a time in order to ensure loop-
>  free ro= uting.
>
>  After the ROUTE_SEQNUM_AGE_MAX timeout a route's sequence number
>  information MUST be disca= rded.
>
> UH> What does it mean to discard a sequence numbe= r information? To set
> it to zero in the route entry? What are the r= elationships between
> ROUTE_SEQNUM_AGE_MUX and ROUTE_AGE_MIN? (can o= ne be smaller than the
> other)
>
> 5.2.3.3.  Recen= tly Used Timeout (ROUTE_USED)
>
>  When a route is used = to forward data packets, this timer is set to
>  expire after R= OUTE_USED_TIMEOUT, as discussed in Section 5.5.2.
>
>  I= f a route has not been used recently, then a timer for ROUTE_DELETE
>=   is set to ROUTE_DELETE_TIMEOUT.
>
> 5.2.3.4.  Del= ete Information Timeout (ROUTE_DELETE)
>
>  As time prog= resses the likelihood that old routing information is
>  useful= decreases, especially if the network nodes are mobile.
>  Therefore, old information SHOULD be deleted.
&g= t;
>  After the ROUTE_DELETE timeout if a forwarding route exi= sts it SHOULD
>  be removed, and the routing table entry SHOULD= also be deleted.
>
> UH> There are quite a few timers, whi= ch is confusing. What happens if
> one timer fires before the other? = Do we really need that many timers?
>
> 5.3.  Routing Mes= sages
>
> 5.3.1.  RREQ Creation
>
>  B= efore an AODVv2 router creates a RREQ it SHOULD increment its
> = OwnSeqNum by one (1) according to the rules specified in Section 5.1.
= >
> UH> Why not MUST? What happens if one does not increase it= . In
> general, there are many SHOULDs in the document, which probabl= y should
> be MUSTs.
>
>  Incrementing OwnSeqNum w= ill ensure that all nodes with existing
>  routing information will consider this new information preferable to
> = existing routing table information.  If the sequence number is not>  incremented, certain AODVv2 routers might not consider this>  information preferable, if they have existing better routing<= br>>  information.
>
>  First, ThisNode adds th= e AddBlk.TargetNode.Address to the RREQ; the
>  unicast IP Dest= ination Address for which a forwarding route does not
>  exist.=
>
>  If a previous value of the TargetNode.SeqNum is kn= own (from a routing
>  table entry using longest-prefix matchin= g), it SHOULD be placed in
>  TargetNode.AddTLV.SeqNum in all b= ut the last RREQ attempt.  If a
>  TargetNode.SeqNum is no= t included, it is assumed to be unknown by
>  handling nodes.&n= bsp; This operation ensures that no intermediate AODVv2
>
>
>
> Perkins & Chakeres      Exp= ires April 26, 2013                = [Page 16]
>
> Internet-Draft         =         AODVv2          &nbs= p;         October 2012
>
>
> = ; routers reply, and ensures that the TargetNode's AODVv2 router
>&n= bsp; increments its sequence number.
>
>  Next, ThisNod= e adds AddBlk.OrigNode.Address, its prefix, and the
>  OrigNode= .AddTLV.SeqNum (OwnSeqNum) to the RteMsg.
>
>  The OrigN= ode.Address is the address of the source for which this
>  AODV= v2 router is initiating this route discovery.  The
>  Orig= Node.Address MUST be a unicast address.  This information will be
&= gt;  used by nodes to create a route toward the OrigNode, enabling
>  delivery of a RREP, and eventually used for proper= forwarding of data
>  packets.
>
>  If Orig= Node.Dist is included it is set to a number, greater than zero
> = ; (0), representing the distance between OrigNode and ThisNode.
> >  The MsgHdr.HopLimit SHOULD be set to MSG_HOPLIMIT.
> > UH> Why SHOULD?
>
> 5.3.2.  RREP Creation
&g= t;
>  First, the AddBlk.TargetNode.Address is added to the RRE= P.  The
>  TargetNode is the ultimate destination of this = RREP; the RREQ
>  OrigNode.Address.
>
>  Nex= t, AddBlk.OrigNode.Address and prefix are added to the RREP.  The
&= gt;  AddBlk.OrigNode.Address is the RREQ TargetNode.Address.  Th= e
>  AddBlk.OrigNode.Address MUST be a unicast IP address. = ; ThisNode
>  SHOULD advertise the largest known prefix containing
>  AddBlk.OrigNode.Address.
>
>  = When the RteMsg TargetNode's AODVv2 router creates a RREP, if the
>&= nbsp; TargetNode.SeqNum was not included in the RREQ, ThisNode MUST
>= ;  increment its OwnSeqNum by one (1) according to the rules specifie= d
>  in Section 5.1.
>
>  If TargetNode.SeqN= um was included in the RteMsg and TargetNode.SeqNum
>  - OwnSeq= Num < 0 (using signed 16-bit arithmetic), OwnSeqNum SHOULD be
>&nb= sp; incremented by one (1) according to the rules specified in
>&nbs= p; Section 5.1.
>
>  If TargetNode.SeqNum is included i= n the RteMsg and TargetNode.SeqNum
>  =3D=3D OwnSeqNum (using s= igned 16-bit arithmetic) and OrigNode.Dist will
>  not be inclu= ded in the RREP being generated, OwnSeqNum SHOULD be
>  increme= nted by one (1) according to the rules specified in
> =20 Section 5.1.
>
>  If OwnSeqNum is not incremented the r= outing information might be
>  considered stale.  In this = case, the RREP might not reach the RREP
>
>
>
> = Perkins & Chakeres      Expires April 26, 2013  &n= bsp;             [Page 17]
>
> I= nternet-Draft                 = AODVv2                  &nbs= p; October 2012
>
>
>  Target.
>
>&= nbsp; After any of the sequence number operations above, the RREP
>&= nbsp; OrigNode.AddTLV.SeqNum (OwnSeqNum) MUST also be added to the RREP.>
>  Other AddTLVs in the RREP for the OrigNode and Targe= tNode SHOULD be
>  included and set accordingly.  If OrigN= ode.Dist is included it is set
>  to a number greater than zero (0) and less than or equal to 254.  The
>  Dist= ance value will influence judgment of the routing information
> = (Section 5.2.1) against known information at other AODVv2 routers
>=   that handle this RteMsg.
>
>  The MsgHdr.HopLimi= t is set to MSG_HOPLIMIT.
>
>  The IP.DestinationAddress= for RREP is set to the IP address of the
>  Route.NextHopAddre= ss for the route to the RREP TargetNode.
>
> 5.3.3.  RteM= sg Handling
>
> UH> Very difficult to parse this section. N= ot much RFC2119 language.
>
> UH> Is there any check for in= valid messages (similar to OLSRv2/NHDP?)
> External mechanisms should= be allowed to add reasons to reject a
> message as invalid, e.g. a s= ecurity mechanism.
>
>  First, ThisNode examines the Rte= Msg to ensure that it contains the
>  required information: MsgHdr.HopLimit, AddBlk.TargetNode.Address,
>  Ad= dBlk.OrigNode.Address, and OrigNode.AddTLV.SeqNum.  If the required>  information does not exist, the message is discarded and furth= er
>  processing stopped.
>
>  ThisNode MUST= only handle AODVv2 messages from adjacent routers.
>
> UH>= What does that mean?
>
>  ThisNode checks if the AddBlk= .OrigNode.Address is a valid routable
>  unicast address.
&g= t;
> UH> How?
>
>    If not, the message i= s ignored and further
>  processing stopped.
>
>&n= bsp; ThisNode also checks whether AddBlk.OrigNode.Address is an address>  handled by this AODVv2 router.
>
> UH> How?>
>    If this node is the originating
>  = AODVv2 router, the RteMsg is dropped.
>
> UH> Why not do this further above, before doing all the other checks?
>
= >  ThisNode checks if the AddBlk.TargetNode.Address is a valid rou= table
>  unicast address.  If the address is not a valid u= nicast address, the
>  message is discarded and further process= ing stopped.
>
>  Next, ThisNode checks whether its rout= ing table has an entry to the
>  AddBlk.OrigNode.Address using = longest-prefix matching [RFC1812].
>
> UH> RFC1812 is IPv4 = only.
>
>    If
>  a route with a valid= Route.SeqNum does not exist,
>
> UH> What is a "valid" seq= uence number?
>
>  then the new
>  routing i= nformation is used to create a new route table entry is
>  crea= ted
>
> UH> to "create" ... is "created"
>
>&n= bsp; and updated as described in Section 5.2.2.
>
> UH> This jumping back is difficult to parse.
>
>  &nb= sp; If a route table
>  entry does exists and it has a known Ro= ute.SeqNum, the incoming
>  routing information is compared wit= h the route table entry following
>  the procedure described in= Section 5.2.1.  If the incoming routing
>  information is= considered preferable, the route table entry is
>
>
> =
> Perkins & Chakeres      Expires April 26, 2013=                 [Page 18]
> <= br>> Internet-Draft              &nbs= p;   AODVv2                &n= bsp;   October 2012
>
>
>  updated as descr= ibed in Section 5.2.2.
>
>  At this point, if the routin= g information for the OrigNode was not
>  preferable then this RteMsg SHOULD be discarded and no further
>  process= ing of this message SHOULD be performed.
>
> UH> Why SHOULD= ? Why not MUST?
>
>  If the TargetNode is a router clien= t of ThisNode this RteMsg is a
>  RREQ, then ThisNode responds = with a RREP to the RREQ OrigNode (the
>  new RREP's TargetNode)= .  The procedure for issuing a new RREP is
>  described in= Section 5.3.2.  Afterwards, ThisNode need not perform
>  = any more operations for the RteMsg being processed.
>
>  = As an alternative to issuing a RREP, ThisNode MAY choose to
>  = distribute routing information about ThisNode (the RREQ TargetNode)
>= ;  more widely.  That is, ThisNode MAY optionally perform a rout= e
>  discovery by issuing a RREQ with ThisNode listed as the Ta= rgetNode,
>  using the procedure in Section 5.3.1.  At this point, ThisNode need
>  not perform any more operation= s for the RteMsg being processed.
>
> UH> I don't understan= d the last paragraph. Is this some remainder of
> intermediate route = reply? In which conditions should a router send a
> RREQ instead of a= RREP?
>
>
>  For each address (except the Target= Node) in the RteMsg that includes
>  AddTLV.Dist information, t= he AddTLV.Dist information is incremented
>  by at least one (1= ).
>
> UH> By how much then?
>
>    = The updated Distance value will influence
>  judgment of the r= outing information (Section 5.2.1) against known
>  information= at other AODVv2 routers that handle this RteMsg.
>
>  I= f the resulting Distance value for the OrigNode is greater than 254,
>= ;  the message is discarded.  If the resulting Distance value for
>  another node is greater than 254,
>
>= ; UH> Which other node?
>
>  the associated address a= nd its
>  information are removed from the RteMsg.
>
= > UH> That makes end-to-end security impossible.
>
>&nbs= p; If the MsgHdr.HopLimit is
>  equal to one (1), then the mes= sage is discarded.  Otherwise, the
>  MsgHdr.HopLimit is d= ecremented by one (1).
>
>  If ThisNode is not the Targe= tNode, AND this RteMsg is a RREQ, then
>  the current RteMsg (a= s altered by the procedure defined above) SHOULD
>  be sent to = the IP multicast address LL-MANET-Routers [RFC5498].  If
> = the RREQ is unicast, the IP.DestinationAddress is set to the
> = ; NextHopAddress.
>
> UH> The unicast RREQ mechanism is no= t really explained anywhere. Where
> is the nexthopaddress acquired from?
>
>
>  If ThisNode is not the Tar= getNode, AND this RteMsg is a RREP, then
>  the current RteMsg = is sent to the Route.NextHopAddress for the RREP's
>  TargetNod= e.Address.  If no forwarding route exists to
>  TargetNode= .Address, then a RERR SHOULD be issued to the OrigNode of
>  th= e RREP.
>
>  By sending the updated RteMsg, ThisNode adv= ertises that it will route
>  for addresses contained in the ou= tgoing RteMsg based on the
>  information enclosed.  ThisN= ode MAY choose not to send the RteMsg,
>  though not resending = this RteMsg could decrease connectivity in the
>
>
> > Perkins & Chakeres      Expires April 26, 2013&n= bsp;               [Page 19]
> > Internet-Draft                  AODVv2              &nbs= p;     October 2012
>
>
>  network or = result in a non-shortest distance path.
>
>  The circums= tances under which ThisNode might choose to not re-issue a
>  R= teMsg are not specified in this document.  Some examples might
>=   include the following:
>
>  o  if ThisNode = does not want to advertise routing for the contained
>    &= nbsp; addresses because it is already heavily loaded
>
> = o  if ThisNode has already issued identical routing information (e.g= .
>      ThisNode had recently issued a RteMsg with th= e same distance)
>
>  o  if ThisNode is low on ener= gy and does not want to expend energy
>      for proto= col message sending or packet forwarding
>
> 5.4.  Route Discovery
>
>  When an AODVv2 router needs to for= ward a data packet and it does not
>  have a forwarding route t= o the destination address, it sends a RREQ
>  (described in Sec= tion 5.3.1) to discover a route to the particular
>  destinatio= n (TargetNode).
>
>  After issuing a RREQ, the AODVv2 ro= uter (OrigNode) waits for a RREP
>  indicating the next hop for= a route to the TargetNode.  If a route is
>  not created = within RREQ_WAIT_TIME, OrigNode may again try to discover
>  a = route by issuing another RREQ using the procedure defined in
>  = Section 5.3.1 again.  Route discovery SHOULD be considered to have>  failed after DISCOVERY_ATTEMPTS_MAX and the corresponding wait= time
>  for a response to the final RREQ.
>
>&nbs= p; To reduce congestion in a network, repeated attempts at route
>  discovery for a particular TargetNode SHOULD utilize = an binary
>  exponential backoff.
>
>  Data = packets awaiting a route SHOULD be buffered by the source's
>  = AODVv2 router.  This buffer SHOULD have a fixed limited size
>&n= bsp; (BUFFER_SIZE_PACKETS or BUFFER_SIZE_BYTES).  Determining which>  packets to discard first is a matter of policy at each AODVv2= router;
>  in the absence of policy constraints, by default ol= der data packets
>  SHOULD be discarded first.  Buffering = of data packets can have both
>  positive and negative effects,= and therefore settings for buffering
>  (BUFFER_DURING_DISCOVE= RY) SHOULD be administratively configurable.
>  Nodes without s= ufficient memory available for buffering may be
>  configured w= ith BUFFER_DURING_DISCOVERY =3D FALSE; this will affect the
>  latency required for launching TCP applications to new = destinations.
>
> UH> I am against including this buffering= mechanism in this document.
> This is a mixture of the routing plane= and the data plane. There are
> other forwarding mechanisms that wou= ld be affected by this
> specification.
>
>  If a = route discovery attempt has failed (i.e. an attempt or multiple
>&nbs= p; attempts have been made without receiving a RREP) to find a route to>
>
>
> Perkins & Chakeres     = Expires April 26, 2013              &n= bsp; [Page 20]
>
> Internet-Draft        &= nbsp;         AODVv2         =           October 2012
>
>
>=   the TargetNode, any data packets buffered for the corresponding
>  TargetNode MUST BE dropped and a Destination = Unreachable ICMP message
>  (Type 3) SHOULD be delivered to the= source of the data packet.  The
>  code for the ICMP mess= age is 1 (Host unreachable error).  If the
>  AODVv2 route= r is not the source (OrigNode), then the ICMP is sent
>  over t= he interface from which the source sent the packet to the
>  AO= DVv2 router.
>
> 5.5.  Route Maintenance
>
>=   A RERR SHOULD be issued if a data packet is to be forwarded and it<= br>>  cannot be delivered to the next-hop because no forwarding ro= ute for
>  the IP.DestinationAddress exists; RERR generation is= described in
>  Section 5.5.3.
>
>  Upon th= is condition, an ICMP Destination Unreachable message SHOULD
>  = NOT be generated unless this router is responsible for the
>  IP.DestinationAddress and that IP.DestinationAddress is= known to be
>  unreachable.
>
> UH> How is tha= t generated (with which content)?
>
>  In addition to in= ability to forward a data packet, a RERR SHOULD be
>  issued im= mediately after detecting a broken link (see Section 5.5.1)
>  = of a forwarding route to quickly notify AODVv2 routers that certain
>=   routes are no longer available.  If a newly unavailable route = has not
>  been used recently (indicated by ROUTE_USED), the RE= RR SHOULD NOT be
>  generated.
>
> UH> SHOULD N= OT or MUST NOT? What are the consequences of doing so when
> using SH= OULD NOT?
>
> 5.5.1.  Active Next-hop Router Adjacency Mo= nitoring
>
>  Nodes SHOULD monitor connectivity to adjac= ent next-hop AODVv2 routers
>  on forwarding routes.  This monitoring can be accomplished by one or
>  = several mechanisms, including:
>
>  o  Neighborhoo= d discovery [RFC6130]
>
>  o  Route timeout
>=
>  o  Lower layer trigger that a neighboring router is n= o longer
>      reachable
>
>  o&nb= sp; Other monitoring mechanisms or heuristics
>
>  Upon = determining that a next-hop AODVv2 router has become
>  unreach= able, ThisNode MUST remove the affected forwarding routes
>  (t= hose using the unreachable next-hop) and unset the Route.Forwarding
>=   flag.  ThisNode also flags the associated routes in AODVv2's r= outing
>  table as Broken.  For each broken route the time= r for ROUTE_DELETE is
>  set to ROUTE_DELETE_TIMEOUT.
> <= br>> UH> How can the flags be set if the routes are removed before?
>
>
>
> Perkins & Chakeres  &n= bsp;   Expires April 26, 2013           = ;     [Page 21]
>
> Internet-Draft    &nbs= p;             AODVv2      &n= bsp;             October 2012
>
&g= t;
> 5.5.2.  Updating Route Lifetimes During Packet Forwarding<= br>>
>  To avoid removing the forwarding route to reach an = IP.SourceAddress,
>  ThisNode SHOULD set the "ROUTE_USED" timeo= ut to the value
>  ROUTE_USED_TIMEOUT for the route to that IP.= SourceAddress upon
>  receiving a data packet or an AODVv2 mess= age.  If the timer for
>  ROUTE_DELETE is set, that timer = is removed.  The Route.Broken flag is
>  unset.
> >  To avoid removing the forwarding route to the IP.DestinationAddress
>  that is being used, ThisNode SHOULD s= et the "ROUTE_USED" timeout to
>  the value ROUTE_USED_TIMEOUT = for the route to the
>  IP.DestinationAddress upon sending a da= ta packet or an AODVv2
>  message.  If the timer for ROUTE= _DELETE is set, it is removed.  The
>  Route.Broken flag i= s unset.
>
> 5.5.3.  RERR Generation
>
>&nbs= p; When an AODVv2 router receives a packet (from PrevHopAddress), and
&= gt;  the router (ThisNode) does not have a route available for the>  destination of the packet, ThisNode uses an RERR message is us= ed to
>
> UH> "uses".. ."is used"
>
>  i= nform one or more neighboring AODVv2 routers that its route to the
>&= nbsp; packet destination is no longer available.
>
>  W= hen ThisNode creates a new RERR, the address of the first
>  UnreachableNode (IP.DestinationAddress from a data pa= cket or
>  RREP.TargetNode.Address) is inserted into an Address= Block
>  AddBlk.UnreachableNode.Address.  If a prefix is = known for the
>  UnreachableNode.Address, it SHOULD be included= .  Otherwise, the
>  UnreachableNode.Address is assumed to= be a host address with a full
>  length prefix.  If a val= ue for the UnreachableNode's SeqNum
>  (UnreachableNode.AddTLV.= SeqNum) is known, it SHOULD be placed in the
>  RERR.  The= MsgHdr.HopLimit SHOULD be set to MSG_HOPLIMIT.
>
>  If = SeqNum information is not known or not included in the RERR, all
>&nb= sp; nodes handling the RERR will assume their routing information
>&= nbsp; associated with the UnreachableNode is no longer valid and flag thos= e
>  routes as broken.
>
>  A RERR MAY be sent to the multicast address LL-MANET-Routers
>  [RFC5= 498], thus notifying all nearby AODVv2 routers that might depend
>&nb= sp; on the now broken link.  If the RERR is unicast, the
> = ; IP.DestinationAddress is set to the PrevHopAddress.
>
>&nbs= p; After sending the RERR, ThisNode SHOULD discard the packet or message>
> UH> Why packet or message? Is this data traffic or contr= ol traffic?
>
>  that triggered generation of the RERR.<= br>>
>
>
>
>
> Perkins & Chakeres=       Expires April 26, 2013        &nb= sp;       [Page 22]
>
> Internet-Draft  &n= bsp;               AODVv2    =                 October 2012
&g= t;
>
> 5.5.4.  RERR Handling
>
>  First, ThisNode examines the incoming RERR to ensure that = it contains
>  MsgHdr.HopLimit and AddBlk.UnreachableNode.Addre= ss.  If the required
>  information does not exist, the in= coming RERR message is discarded
>  and further processing stop= ped.
>
>  When an AODVv2 router handles a RERR, it exami= nes the information for
>  each UnreachableNode.
>
&g= t; UH> How exactly does it do that? Which information is used, and how?<= br>>
>  The AODVv2 router removes the forwarding
>&nb= sp; route, unsets the Route.Forwarding flag, sets the Route.Broken flag,>  and the timer for ROUTE_DELETE is set to ROUTE_DELETE_TIMEOUT= for
>  each UnreachableNode.Address found using longest prefix= matching that
>  meets all of the following conditions:
>= ;
>  1.  The UnreachableNode.Address is a routable unicast address.
>
>  2.  The Route.NextHopAddress= is the same as the RERR
>      IP.SourceAddress.
= >
>  3.  The Route.NextHopInterface is the same as the= interface on which
>      the RERR was received.
= >
>  4.  The Route.SeqNum is zero (0), unknown, OR the=
>      UnreachableNode.SeqNum is zero (0), unknown, = OR Route.SeqNum -
>      UnreachableNode.SeqNum <= =3D 0 (using signed 16-bit arithmetic).
>
>  If Route.Se= qNum is zero (0) or unknown and UnreachableNode.SeqNum
>  exist= s in the RERR and is not zero (0), then Route.SeqNum SHOULD be
> = ; set to UnreachableNode.SeqNum.  Setting Route.SeqNum can reduce
= >  future RERR handling and forwarding.
>
> UH> Ho= w?
>
>  Each UnreachableNode that did not result in marking a route table
>  entry as broken route is removed from= the RERR, since propagation of
>  such information will not re= sult in any benefit.
>
> UH> Makes end-to-end security impo= ssible.
>
>  Each UnreachableNode that did indicate a br= oken route SHOULD remain
>  in the RERR.
>
> = If any UnreachableNode was removed, all other information (AddTLVs)
&g= t;  associated with the UnreachableNode address(es) MUST also be remo= ved.
>
>  If Route.SeqNum is known and an UnreachableNod= e.SeqNum is not
>  included in the RERR, then Route.SeqNum (i.e= .
>  UnreachableNode.SeqNum) MAY be included with the RERR.&nbs= p; Including
>  UnreachableNode.SeqNum can reduce future RERR h= andling and
>  forwarding.
>
>  If no Unreac= hableNode addresses remain in the RERR, or if the
>
>
>
> Perkins & Chakeres      Expires Apri= l 26, 2013                [Page 23]=
>
> Internet-Draft            &= nbsp;     AODVv2             =       October 2012
>
>
>  MsgHdr= .HopLimit is equal to one (1), then the RERR MUST be discarded.
> >  Otherwise, the MsgHdr.HopLimit is decremented by one (1). = ; The RERR
>  SHOULD be sent to the multicast address LL-MANET-= Routers [RFC5498].
>  Alternatively, if the RERR is unicast, th= e IP.DestinationAddress is
>  set to the PrevHopAddress.
>= ;
> 5.6.  Unknown Message and TLV Types
>
>  = If a message with an unknown type is received, the message is
> = ; ignored.
>
>  For handling of messages that contain unknown TLV types, ignore the
>  information for proce= ssing, preserve it unmodified for forwarding.
>
> 5.7.  A= dvertising Network Addresses
>
>  AODVv2 routers MAY spe= cify a prefix length for each advertised
>  address.  Any = nodes (other than the advertising AODVv2 router) within
>  the = advertised prefix MUST NOT participate in the AODVv2 protocol
> = directly.  For example, advertising 192.0.2.1 with a prefix length o= f
>  24 indicates that all nodes with the matching 192.0.2.X ar= e reachable
>  through this AODVv2 router.  An AODVv2 rout= er MUST NOT advertise
>  network addresses unless it can guaran= tee its ability for forwarding
>  packets to any host address w= ithin the address range of the
>  corresponding network.
>= ;
> 5.8.  Simple Internet Attachment
>
>  Simple Internet attachment consists of a stub (i.e., non-t= ransit)
>  network of AODVv2 routers connected to the Internet = via a single
>  Internet AODVv2 router (IAR).
>
> = UH> Why a new defition? Is that not just a border router? Also, it
&g= t; does not matter if it's connected to the "Internet", just if it's a
&= gt; border gateway with two interfaces, connecting two different routing> domains (which could still not be connected to the Internet).
>=
>  As in any Internet-attached network,
>
> UH&g= t; What's an Internet-attached network? Is that defined in an IP
> ar= chitecture RFC?
>
>    AODVv2 routers, and hosts beh= ind
>  these routers, wishing to be reachable from hosts on the= Internet
>  MUST have IP addresses within the IAR's routable a= nd topologically
>  correct prefix (e.g. 192.0.2.0/24).
>
>  The IAR is responsible for generati= ng RREQ to find nodes within the
>  AODVv2 Region on behalf of = nodes on the Internet, as well as
>  responding to route reques= ts from the AODVv2 region on behalf of the
>  nodes on the Inte= rnet.
>
>
>
>
>
>
>
>= ;
>
> Perkins & Chakeres      Expires Apr= il 26, 2013                [Page 24= ]
>
> Internet-Draft            =       AODVv2             = ;       October 2012
>
>
>   =     /--------------------------\
>      &n= bsp; /          Internet       = ;   \
>        \                          &nbs= p; /
>        \------------+-------------/
&g= t;                    &nb= sp; |
>      Routable &    |
>&n= bsp;     Topologically  |
>      Corr= ect        |
>      Prefix  =       |
>            &n= bsp;   +-----+--------+
>          &nbs= p;     |  Internet    |
>     = ;   /------|  AODVv2      |-------\
> =       /      |  Router    &n= bsp; |        \
>      /  &n= bsp;     |192.0.2.1/32  |       =20 \
>      |        |Responsible&n= bsp; |        |
>      |  =       |  for        |   =     |
>      |       = |AODVv2 Region |        |
>     = |        |192.0.2.0/24  |      &n= bsp; |
>      |        +--------= ------+        |
>      | +-----= -----------+              |
> = ;     | | AODVv2 Router  |         = ;     |
>      | | 192.0.2.2/32  |&nb= sp;             |
>     = | +----------------+              |
>      |          =     +----------------+ |
>      |  &nb= sp;           | AODVv2 Router  | |
>&nb= sp;     |              | 192.= 0.2.3/32  | |
>      \      &nbs= p;       +----------------+ /
>      &n= bsp; \                   =           /
>        = \-----------------------------/
>
>       =       Figure 1: Simple Internet Attachment Example
>=
>  When an AODVv2 router within the AODVv2 Region wants to di= scover a
>  route to a node on the Internet, it uses the normal= AODVv2 route
>  discovery for that IP Destination Address.  The IAR MUST respond to
>  RREQ on behalf of th= e Internet destination.
>
> UH> How? Where is that specifie= d?
>
>  When a packet from a node on the Internet destin= ed for a node in the
>  AODVv2 region reaches the IAR, if the I= AR does not have a route to
>  that destination it will perform= normal AODVv2 route discovery for
>  that destination.
>=
> UH> How? With which originator address, target etc? Where are = RERRs /
> ICMP unreachable sent to in case of a broken data traffic?<= br>>
> 5.9.  Multiple Interfaces
>
>  AOD= Vv2 may be used with multiple interfaces; therefore, the
>  par= ticular interface over which packets arrive MUST be known whenever
>&= nbsp; a packet is received.  Whenever a new route is created, the int= erface
>  through which the Route.Address can be reached is also recorded in
>
>
>
> Perkins & Chake= res      Expires April 26, 2013        =         [Page 25]
>
> Internet-Draft =                 AODVv2  &nbs= p;                 October 2012>
>
>  the route table entry.
>
> = ; When multiple interfaces are available, a node transmitting a
>&nb= sp; multicast packet with IP.DestinationAddress set to LL-MANET-Routers>  SHOULD send the packet on all interfaces that have been config= ured
>  for AODVv2 operation.
>
>  Similarly= , AODVv2 routers SHOULD subscribe to LL-MANET-Routers on all
>  = their AODVv2 interfaces.
>
> 5.10.  AODVv2 Control Packe= t/Message Generation Limits
>
> UH> There is no AODVv2 Control Packet.
>
>
>  To ensure predicta= ble messaging overhead, AODVv2 router's rate of
>  packet/messa= ge generation SHOULD be limited.  The rate and algorithm
> = for limiting messages (CONTROL_TRAFFIC_LIMITS) is left to the
>&nbs= p; implementor and should be administratively configurable.  AODVv2>  messages SHOULD be discarded in the following order of prefer= ence:
>  RREQ, RREP, and finally RERR.
>
> 5.11.&n= bsp; Optional Features
>
>  Several optional features of= AODVv2, and associated with AODV, are
>  not required by minim= al implementations.  These features are expected
>  to be = useful in networks with greater mobility, or larger node
>  pop= ulations, or requiring shorter latency for application launches.
>&nb= sp; The optional features are as follows:
>
> =20 o  Expanding Rings Multicast
>
>  o  Intermed= iate RREPs (iRREPs): Without iRREP, only the destination
>  &nbs= p;   can respond to a RREQ.
>
>  o  Precursor = lists.
>
>  o  Reporting Multiple Unreachable Nodes= .  An RERR message can carry
>      more than one= Unreachable Destination node for cases when a single
>    =   link breakage causes multiple destinations to become unreachable
= >      from an intermediate router.
>
> UH&g= t; This seems to be different from section 5.11.6, which talks about
>= ; adding additional information to a RREQ.
>
> UH> None of = the extensions is sufficiently specified, and it is
> unclear how it = would affect interoperability if some nodes support the
> extension a= nd others don't.
>
> 5.11.1.  Expanding Rings Multicast
>
>  For multicast RREQ, the MsgHdr.HopLimit = MAY be set in accordance with
>  an expanding ring search as de= scribed in [RFC3561] to limit the RREQ
>  propagation to a subs= et of the local network and possibly reduce
>  route discovery = overhead.
>
>
>
>
>
>
> Per= kins & Chakeres      Expires April 26, 2013   = ;             [Page 26]
>
> Inte= rnet-Draft                  A= ODVv2                    = October 2012
>
>
> 5.11.2.  Intermediate RREP
= >
>  This specification has been published as a separate In= ternet Draft .
>
> 5.11.3.  Precursor Notification
>= ;
>  The Dynamic MANET On-demand (AODVv2) routing protocol is intended for
>  use by mobile routers in wireless,= multihop networks.  AODVv2
>  determines unicast routes a= mong AODVv2 routers within the network in
>  an on-demand fashi= on, offering on-demand convergence in dynamic
>  topologies.&nb= sp; This document specifies a simple modification to AODVv2
>  = (and possibly other reactive routing protocols) enabling faster
>&nbs= p; notifications to known sources of traffic upon determination that a
= >  route for such traffic's destination has become Broken.
>=
> 5.11.3.1.  Overview
>
>  If an AODVv2 rou= ter, while attempting to forward a packet to a
>  particular de= stination, determines that the next hop (one of its
>  neighbor= s) is no longer reachable, AODVv2 specifies that the router
>  = notify the source of that packet that the route to the destination
>  has become Broken.  In the existing specif= ication, the notification
>  to the source is a unicast RERR me= ssage.
>
>  However, in many cases there will be several= sources of of traffic
>  for that particular destination. = ; In fact, the broken link for the
>  next hop in question may = be a path component of numerous other routes
>  for other desti= nations, and in that case the node detecting the
>  broken link= must mark as Broken multiple routes, one for each of the
>  ne= wly unreachable destinations.  Each route that uses the newly
>&= nbsp; broken link is no longer valid.  For each such route, every nod= e
>  along the way from the source using that route, to the nod= e detecting
>  the broken link, is known as a "precursor" for t= he broken next hop.
>  All the precursors for a particular next hop should be notified about
>  the change in = status of their route to a destination downstream from
>  the b= roken next hop.
>
> 5.11.3.2.  Precursor Notification
= >
>  During normal operation, each node wishing to enable t= he improved
>  notification for precursors of any links to its = next hop neighbors
>  has to keep track of the precursors. = ; This is done by maintaining a
>  precursor table and updating= the table whenever the node initiates or
>  relays a RREP mess= age back to a node originating a RREQ message.
>  When the node= transmits the RREP message, it is implicitly agreeing
>  to fo= rward traffic from the RREQ originator towards the RREP
>  orig= inator (i.e., along the next hop link to the neighbor from which
>&nb= sp; the RREP was received).  The "other" next hop, which is the neighbor
>
>
>
> Perkins & Chakeres&nbs= p;     Expires April 26, 2013          =       [Page 27]
>
> Internet-Draft   =               AODVv2    &nbs= p;               October 2012
> <= br>>
>  along the way towards the originator of the RREQ me= ssage, is then the
>  next precursor for the route towards the = destination requested by the
>  RREQ.
>
>  E= ach such precursor should then be recorded as a precursor for a
>&nbs= p; route along the next hop.  The same next hop may be in service for=
>  routes to multiple destinations, but for precursor list man= agement it
>  is only important to keep track of precursors for= a particular next
>  hop; the exact destination does not matter, only the particular next
>  hop towards the destin= ation(s).
>
>  When a node observes that one of its neig= hbors is no longer
>  reachable, the node first checks to see w= hether the link to that
>  neighbor is a next hop for any more = distant destination in its route
>  table.  If not, then t= he node simply updates any relevant neighorhood
>  information = and takes no further action.
>
>  Otherwise, for all des= tinations no longer reachable because of the
>  changed status = of the next hop, the node first checks to see whether
>  the li= nk to that neighbor is a next hop for any more distant
>  desti= nation in its route table.  If not, then the node simply updates
&g= t;  any relevant neighorhood information and takes no further action.=
>
>  For each precursor of the next hop, the node MAY notify the precursor
>  in one of three ways:
>=
>  o  unicast RERR
>
>  o  broad= cast RERR
>
>  o  multicast RERR to multicast group= PRECURSOR_RERR_RECEIVERS
>
> UH> I don't see an allocation= request in the IANA section.
>
>
>  Each precurs= or then MAY execute the same procedure until all affected
>  tr= affic sources have received the RERR route maintenance information.
>=
>  When a precursor receives a unicast RERR, the precursor MU= ST further
>  unicast the RERR message towards the affected tra= ffic source.  If a
>  precursor receives a broadcast or mu= lticast RERR, the precursor MAY
>  further retransmit the RERR = towards the traffic source.
>
> 5.11.4.  Reporting Multip= le Unreachable Nodes
>
> 5.11.5.  Message Aggregation
>
>  The aggregation of multiple messages i= nto a packet is not specified
>  in this document, but if aggre= gation does occur the IP.SourceAddress
>  and IP.DestinationAdd= ress of all contained messages MUST be the same.
>
> UH> Th= at is part of the RFC5444 multiplexer and not of AODVv2.
>
> <= br>>
>
> Perkins & Chakeres      Expir= es April 26, 2013                [P= age 28]
>
> Internet-Draft          &= nbsp;       AODVv2           =         October 2012
>
>
>  = Implementations MAY choose to temporarily delay transmission of
>&nb= sp; messages for the purpose of aggregation (into a single packet) or to>  improve performance by using jitter [RFC5148].
>
> 5.11.6.  Adding Additional Routing Information to a RteMsg>
> UH> This section is unclear to me. What is the purpose? = What kind of
> information would you add? How can this interoperate? = By adding
> information en-route, end-to-end security is not possible= .
>
>  DSR [RFC4728] includes source routes as part of t= he data of its RREPs
>  and RREQs.  Doign so allows additi= onal topology information to be
>  flooded along with the RteMs= g, and potentially allows updating for
>  stale routing informa= tion at MANET routers along new paths between
>  source and des= tination.  To maintain this functionality, AODVv2 has
>  d= efined a somewhat more general method that enables inclusion of
>&nbs= p; source routes in RteMsgs.
>
>  Appending routing inf= ormation can alleviate route discovery attempts
>  to the nodes whose information is included, if other AODVv2 routers
>&n= bsp; use this information to update their routing tables.
>
>=   Note that, since the initial merger of DSR with AODV to create this=
>  protocol, further experimentation has shown that including = the
>  additional routing information is not always helpful.&nb= sp; Sometimes it
>  seems to help, and other times it seems to = reduct overall
>  performance.
>
>  AODVv2 r= outers can append routing information to a RteMsg.  This is
>&nb= sp; controllable by an option (APPEND_INFORMATION) which SHOULD be
>=   administratively configurable or controlled according to the traffi= c
>  characteristics of the network.
>
>  Pr= ior to appending an address controlled by this AODVv2 router to a
>&n= bsp; RteMsg, ThisNode MAY increment its OwnSeqNum as defined in
>  Section 5.1.  If OwnSeqNum is not incremented the a= ppended routing
>  information might not be considered preferab= le, when received by
>  nodes with existing routing information= .  Incrementation of the
>  sequence number when appending= information to a RteMsg in transit
>  (APPEND_INFORMATION_SEQN= UM) SHOULD be administratively configurable.
>  Note that, duri= ng handling of this RteMsg OwnSeqNum may have already
>  been i= ncremented; and in this case OwnSeqNum need not be incremented
> = ; again.
>
>  If an address controlled by this AODVv2 r= outer includes
>  ThisNode.Dist, it is set to a number greater = than zero (0).
>
>  For added addresses (and their prefi= xes) not controlled by this
>  AODVv2 router, Route.Dist can be= included if known.
>
>  The VALIDITY_TIME of routing information for appended address(es)
>  MUST be includ= ed, to inform routers about when to delete this
>
>
> <= br>> Perkins & Chakeres      Expires April 26, 2013&= nbsp;               [Page 29]
> > Internet-Draft               = ;   AODVv2                &nb= sp;   October 2012
>
>
>  information. = ; The VALIDITY_TIME TLV is defined in Section 5.13.3.
>
> = ; Additional information (e.g.  SeqNum and Dist) about any appended>  address(es) SHOULD be included.
>
>  Note = that the routing information about the TargetNode MUST NOT be
> = added.  Also, duplicate address entries SHOULD NOT be added.
>=   Instead, only the best routing information (Section 5.2.1) for a
>  particular address SHOULD be included.
>
&g= t;  Intermediate nodes obey the following procedures when processing<= br>>  AddBlk.AdditionalNode.Address information and other associat= ed TLVs
>  that are included with a RteMsg.  For each addr= ess (except the
>  TargetNode) in the RteMsg that includes AddT= LV.Dist information, the
>  AddTLV.Dist information MUST be inc= remented.  If the resulting
>  Distance value for the Orig= Node is greater than 254, the message is
>  discarded.  If= the resulting Distance value for another node is
>  greater th= an 254, the associated address and its information are
>  remov= ed from the RteMsg.
>
>  After handling the OrigNode's r= outing information, then each address
>  that is not the Target= Node MAY be considered for creating and
>  updating routes.  Creating and updating routes to other nodes can
> = ; eliminate RREQ for those IP destinations, in the event that data
>=   needs to be forwarded to the IP destination(s) now or in the near>  future.
>
>  For each of the additional ad= dresses considered, ThisNode first
>  checks that the address i= s a routable unicast address.  If the
>  address is not a = unicast address, then the address and all related
>  informatio= n MUST be removed.
>
>  If the routing table does not ha= ve a matching route with a known
>  Route.SeqNum for this addit= ional address using longest-prefix
>  matching, then a route MA= Y be created and updated as described in
>  Section 5.2.2. = ; If a route table entry exists with a known
>  Route.SeqNum, t= he incoming routing information is compared with the
> =20 route table entry following the procedure described in Section 5.2.1.
&= gt;  If the incoming routing information is used, the route table ent= ry
>  SHOULD be updated as described in Section 5.2.2.
> =
>  If the routing information for an AdditionalNode.Address is= not used,
>  then it is removed from the RteMsg.
>
&= gt; 5.12.  Administratively Configured Parameters and Timer Values
= >
>  AODVv2 contains several parameters which MUST be admin= istratively
>  configured.  The list of these follows:
= >
>
>
> Perkins & Chakeres      = Expires April 26, 2013              &nb= sp; [Page 30]
>
> Internet-Draft        &n= bsp;         AODVv2          =           October 2012
>
>
>              Required Administ= ratively Configured Parameters
>
>  +-------------------= -----+------------------------------------------+
>  |  &n= bsp;       Name          |  &n= bsp;             Description    &nb= sp;         |
>  +------------------------= +------------------------------------------+
>  |  RESPONS= IBLE_ADDRESSES |  List of addresses or routing prefixes,  |
&g= t;  |                  &= nbsp;     |      for which this AODVv2 router is&n= bsp;   |
>  |            &n= bsp;           |  responsible.  If, RESP= ONSIBLE_ADDRESSES |
>  |                        |    is = zero, this AODVv2 router is only  |
>  |    &nb= sp;                   |  =   responsible for its own addresses.    |
>  |&n= bsp;   AODVv2_INTERFACES  |  List of the interfaces partici= pating in |
>  |             = ;           |        AODVv2 r= outing protocol.        |
>  +------------= ------------+------------------------------------------+
>
>&n= bsp;                     =             Table 2
>
>  A= ODVv2 contains a number of timers.  The default timing parameter
&g= t;  values follow:
>
>                      Default Timing Parameter = Values
>
>          +---------------= ---------------+-------------------+
>        &nb= sp; |            Name      &= nbsp;     |      Value      |>          +------------------------------+--= -----------------+
>          |   = ;     ROUTE_TIMEOUT        |    5= seconds    |
>          | =   ROUTE_AGE_MIN_TIMEOUT    |      1 second&= nbsp;   |
>          | ROUTE_SEQNUM_A= GE_MAX_TIMEOUT |    600 seconds    |
>  &nbs= p;       |      ROUTE_USED_TIMEOUT      |  ROUTE_TIMEOUT  |
= >          |    ROUTE_DELETE_TIMEOU= T    | 2 * ROUTE_TIMEOUT |
>        &n= bsp; |    ROUTE_RREQ_WAIT_TIME    |    2 = seconds    |
>          | UNICAS= T_MESSAGE_SENT_TIMEOUT |      1 second    |
&g= t;
> UH> UNICAST_MESSAGE_SENT_TIMEOUT is never used in this speci= fication
>
>          +-------------= -----------------+-------------------+
>
>     =                     &nbs= p;       Table 3
>
>  The above timing pa= rameter values work well for small and medium
>  well-connected= networks with moderate topology changes.
>
> UH> That also depends on the traffic patterns, on the lossy-ness of
> th= e links, on the density of the routers etc.
>
>  The tim= ing parameters SHOULD be administratively configurable for the
> = ; network where AODVv2 is used.  Ideally, for networks with frequent<= br>>  topology changes the AODVv2 parameters should be adjusted us= ing
>  either experimentally determined values or dynamic adapt= ation.  For
>  example, in networks with infrequent topolo= gy changes
>  ROUTE_USED_TIMEOUT may be set to a much larger va= lue.
>
>
>
>
>
>
>
>= Perkins & Chakeres      Expires April 26, 2013  &= nbsp;             [Page 31]
>
> = Internet-Draft                 = ; AODVv2                    October 2012
>
>
>      =                   Default Par= ameter Values
>
>  +------------------------+-------+---= -------------------------------+
>  |       = ;   Name          | Value |    &nbs= p;       Description          |>  +------------------------+-------+----------------------------= ------+
>  |      MSG_HOPLIMIT    &nbs= p; |  20  |  This value MUST be larger than  |
>=   |                  &nb= sp;     |  hops |  the AODVv2 network diameter.  = |
>
> UH> How would the network diameter be determined?>
>  |                        |      |  O= therwise, routing messages may |
>  |       = ;                 |    &n= bsp; |    not reach their intended    |
> = ; |                    &= nbsp;   |      |          de= stinations.          |
>  | DISCOVERY_= ATTEMPTS_MAX |  3  |  The number of route discovery = |
>  |                =         |      |      at= tempts to make before    |
>  |      =                   |  &nbs= p;   |  indicating that a particular =20 |
>  |                =         |      |    address = is not reachable.    |
>  +------------------------+-= ------+----------------------------------+
>
>    &n= bsp;                     =         Table 4
>
>  In addition to = the above parameters and timing values, several
>  administrati= ve options exist.  These options have no influence on
>  c= orrect routing behavior, although they may potentially reduce AODVv2
>= ;  protocol messaging in certain situations.  The default behavi= or is to
>  NOT enable any of these options; and although many = of these options
>  can be administratively controlled, they ma= y be better served by
>  intelligent control.  The following table enumerates several of the
>  options.
> =
>                  &nbs= p; Administratively Controlled Options
>
>  +-----------= ---------------+----------------------------------------+
>  |&= nbsp;         Name          = |              Description   =           |
>  +---------------------= -----+----------------------------------------+
>  |  BUFF= ER_DURING_DISCOVERY |  Whether and how much data to buffer  |>  |                 = ;         |        during route di= scovery.        |
>
> UH> Whether and h= ow much? Is it a boolean flag or a number?
>
>
>  | APPEND_EXTRA_UNREACHABLE |      Whether t= o append additional      |
>  |    &nb= sp;                     |=     Unreachable information to RERR.    |
> = |  CONTROL_TRAFFIC_LIMITS  |  AODVv2 messaging SHOULD be l= imited to |
>  |             = ;             |    avoid consuming= all the network    |
>  |       =                   |  &nb= sp;           bandwidth.      &nbs= p;       |
>
> UH> What is the unit or the = meaning of this? Bytes per second?
>
>  +---------------= -----------+----------------------------------------+
>
>                  &nb= sp;               Table 5
>
&g= t;  Note: several fields have limited size (bits or bytes) these size= s
>  and their encoding may place specific limitations on the v= alues that
>  can be set.  For example, MsgHdr.HopLimit is= a 8-bit field and
>  therefore MSG_HOPLIMIT cannot be larger t= han 255.
>
>
>
> Perkins & Chakeres  &n= bsp;   Expires April 26, 2013           = ;     [Page 32]
>
> Internet-Draft    &nbs= p;             AODVv2      &n= bsp;             October 2012
>
&g= t;
> 5.13.  IANA Considerations
>
> UH> This is= not a valid IANA section. There are no requests for
> registries or for TLV code points. There is no allocation policy.
> = Refer to RFC5526.
>
>
>  In its default mode of o= peration, AODVv2 uses the UDP port 269
>  [RFC5498] to carry pr= otocol packets.  AODVv2 also uses the link-local
>  multic= ast address LL-MANET-Routers [RFC5498].
>
>  This sectio= n specifies several message types, message tlv-types, and
>  ad= dress tlv-types.
>
> 5.13.1.  AODVv2 Message Types Specif= ication
>
>              &n= bsp;           AODVv2 Message Types
>
&= gt;                  +-------= -----------------+----------+
>          &nb= sp;       |          Name  &n= bsp;       |  Type  |
>                  +----------------= --------+----------+
>             = ;     |  Route Request (RREQ)  | 10 - TBD |
>&nb= sp;                 |  Route= Reply (RREP)  | 11 - TBD |
>         =         |  Route Error (RERR)  | 12 - TBD= |
>                  += ------------------------+----------+
>
>      &= nbsp;                    =       Table 6
>
> 5.13.2.  Message and Ad= dress Block TLV Type Specification
>
>      &nb= sp;                     = Message TLV Types
>
> =20 +-------------------+------+--------+-------------------------------+
&= gt;  |        Name      | Type | = Length | Value                 = ;       |
>  +-------------------+------+------= --+-------------------------------+
>  |  Unicast Response= | 10 - |    0  | Indicates to the processing  |
&= gt;  |      Request      |  TBD | = octets | node that the previous hop    |
>  |  &= nbsp;               |    &nbs= p; |        | (IP.SourceAddress) expects a  |
&= gt;  |                  = |      |        | unicast reply message= within  |
>  |                  |      |      &= nbsp; | UNICAST_MESSAGE_SENT_TIMEOUT. |
>  |     = ;             |      |  =       | Any unicast packet will serve |
>  |&nbs= p;                 |    =   |        | this purpose, and it MAY be  |<= br>>  |                &nb= sp; |      |        | an ICMP REPLY mes= sage.  If    |
>  |        &= nbsp;         |      |    &nb= sp;   | the reply is not received,    |
>  |&nbs= p;                 |    =   |        | then the previous hop can    |
>  |          &nb= sp;       |      |       = ; | assume that the link is      |
>  |  &= nbsp;               |    &nbs= p; |        | unidirectional and MAY     = ;   |
>  |             =     |      |        | blackl= ist the link to this    |
>  |      &n= bsp;           |      |  &nbs= p;     | node.              &n= bsp;         |
>  +-------------------+---= ---+--------+-------------------------------+
>
> UH> It is= never specified where and how to use this TLV? Is it a
> message-specifid TLV? To which registry do you want to add it? What is
= > the allocation policy? What are the registered type extensions?
>= ;
>                  &n= bsp;               Table 7
>
&= gt;
>
>
> Perkins & Chakeres      = Expires April 26, 2013              &nbs= p; [Page 33]
>
> Internet-Draft        &nb= sp;         AODVv2          &= nbsp;         October 2012
>
>
> 5= .13.3.  Address Block TLV Specification
>
>    =                      = ; Address Block TLV Types
>
>  +----------------+-------= -----+----------+--------------------------+
>  |      Name      |    Type    |&= nbsp; Length  | Value              =       |
>  +----------------+------------+------= ----+--------------------------+
>  |    AODVv2 = ;   |  10 - TBD  |  up to 2 | The AODVv2 sequence num&= nbsp; |
>  |    Sequence    |    =         |  octets  | associated with this&nbs= p;   |
>  |    Number    |  &n= bsp;         |          | addr= ess.  The sequence  |
>  | (AODVv2SeqNum) |  &n= bsp;         |          | numb= er may be the last  |
>  |        &nb= sp;       |            |          | known sequence number.  |
&= gt;  |    Distance    |  11 - TBD  |&nb= sp; up to 2 | A metric of the distance |
>  |    &nbs= p;           |          &= nbsp; |  octets  | traversed by the        |=
>  |                |&= nbsp;           |         = ; | information associated  |
>  |      &n= bsp;         |           = |          | with this address.    &nbs= p; |
>
> UH> How is the distance formatted?
>
&g= t;  |  VALIDITY_TIME | 1[RFC5497] |        &= nbsp; | The maximum amount of    |
>  |                |      &nb= sp;     |          | time that informati= on    |
>  |           =     |            |    &n= bsp;     | can be maintained before |
>  |  &nbs= p;             |        &= nbsp;   |          | being deleted.  The=       |
>  |          &= nbsp;     |            |  &nbs= p;       | VALIDITY_TIME TLV is    |
> = ; |                |    =         |          | defined i= n [RFC5497].    |
> =20 +----------------+------------+----------+--------------------------+
&= gt;
>                  =                 Table 8
> > 5.14.  Security Considerations
>
> UH> This will= not suffice; see RFC3552 for guidelines how to write
> security cons= iderations.
>
> UH> Notably, there is no mention of possibl= e threats to AODVv2. Also,
> there is some text to protect messages; = but it is impossible to do so,
> as messages are changed in transit. = Also, since there is no way to
> hook in security extensions (such as= done in RFC6130) for rejecting
> messages, there is currently no sec= urity possible for DYMO.
>
>
>  The objective of = the AODVv2 protocol is for each router to
>  communicate reacha= bility information to addresses for which it is
> =20 responsible.  Positive routing information (i.e. a route exists) is>  distributed via RteMsgs and negative routing information (i.e= . a
>  route does not exist) via RERRs.  AODVv2 routers th= at handle these
>  messages store the contained information to = properly forward data
>  packets, and they generally provide th= is information to other AODVv2
>  routers.
>
>&nbs= p; This section does not mandate any specific security measures.
>&n= bsp; Instead, this section describes various security considerations and>  potential avenues to secure AODVv2 routing.
>
>&= nbsp; The most important security mechanisms for AODVv2 routing are
>= ;  integrity/authentication and confidentiality.
>
>&nbs= p; In situations where routing information or router identity are
>&= nbsp; suspect, integrity and authentication techniques SHOULD be applied to
>  AODVv2 messages.
>
> UH> How? Me= ssages change in transit (addresses added or removed etc).
>
>=   In these situations, routing information that is
>  dis= tributed over multiple hops SHOULD also verify the integrity and
> >
>
> Perkins & Chakeres      Expire= s April 26, 2013                [Pa= ge 34]
>
> Internet-Draft          &n= bsp;       AODVv2            =         October 2012
>
>
>  = identity of information based on originator of the routing
>  i= nformation.
>
> UH> How?
>
>  A digital = signature could be used to identify the source of AODVv2
>  mes= sages and information, along with its authenticity.  A nonce or
>  timestamp SHOULD also be used to protect against replay = attacks.
>  S/MIME and OpenPGP are two authentication/integrity= protocols that
>  could be adapted for this purpose.
> <= br>>  In situations where confidentiality of AODVv2 messages is im= portant,
>  cryptographic techniques can be applied.
> >  In certain situations, for example sending a RREP or RERR, an= AODVv2
>  router could include proof that it has previously re= ceived valid
>  routing information to reach the destination, a= t one point of time in
>  the past.  In situations where r= outers are suspected of transmitting
>  maliciously erroneous i= nformation, the original routing information
>  along with its = security credentials SHOULD be included.
>
>  Note that = if multicast is used, any confidentiality and integrity
>  algorithms used MUST permit multiple receivers to= handle the message.
>
>  Routing protocols, however, ar= e prime targets for impersonation
>  attacks.  In networks= where the node membership is not known, it is
>  difficult to = determine the occurrence of impersonation attacks, and
>  secur= ity prevention techniques are difficult at best.  However, when
>= ;  the network membership is known and there is a danger of such
&= gt;  attacks, AODVv2 messages must be protected by the use of
>=   authentication techniques, such as those involving generation of>  unforgeable and cryptographically strong message digests or di= gital
>  signatures.  While AODVv2 does not place restrict= ions on the
>  authentication mechanism used for this purpose, = IPsec Authentication
>  Message (AH) is an appropriate choice for cases where the nodes share
>  an appropriate secur= ity association that enables the use of AH.
>
> UH> That on= ly works for a single hop, not end-to-end, as the IP
> packets are no= t forwarded.
>
>  In particular, routing messages SHOULD= be authenticated to avoid
>  creation of spurious routes to a = destination.  Otherwise, an attacker
>  could masquerade a= s that destination and maliciously deny service to
>  the desti= nation and/or maliciously inspect and consume traffic
>  intend= ed for delivery to the destination.  RERR messages SHOULD be
>&n= bsp; authenticated in order to prevent malicious nodes from disrupting
= >  active routes between communicating nodes.
>
>&nbs= p; If the mobile nodes in the ad hoc network have pre-established
>&= nbsp; security associations, the purposes for which the security
>  associations are created should include that of au= thorizing the
>  processing of AODVv2 control packets.  Gi= ven this understanding, the
>  mobile nodes should be able to u= se the same authentication mechanisms
>
>
>
> Pe= rkins & Chakeres      Expires April 26, 2013  &nbs= p;             [Page 35]
>
> Int= ernet-Draft                  = AODVv2                   = October 2012
>
>
>  based on their IP addresses= as they would have used otherwise.
>
> 5.15.  Acknowledg= ments
>
>  AODVv2 is a descendant of the design of previ= ous MANET on-demand
>  protocols, especially AODV [RFC3561] and= DSR [RFC4728].  Changes to
>  previous MANET on-demand protocols stem from research and
>  implementation e= xperiences.  Thanks to Elizabeth Belding-Royer for
>  her = long time authorship of AODV.  Additional thanks to Luke Klein-
>= ;  Berndt, Pedro Ruiz, Fransisco Ros, Koojana Kuladinithi, Ramon
&= gt;  Caceres, Thomas Clausen, Christopher Dearlove, Seung Yi, Romain<= br>>  Thouvenin, Tronje Krop, Henner Jakob, Alexandru Petrescu, Ch= ristoph
>  Sommer, Cong Yuan, Lars Kristensen, and Derek Atkins= for reviewing of
>  AODVv2, as well as several specification s= uggestions.
>
>  This revision of AODVv2 isolates the mi= nimal base specification and
>  other optional features to simp= lify the process of ensuring
>  compatibility with the existing= LOADng specification
>  [I-D.clausen-lln-loadng] (minimal reac= tive routing protocol
>  specification).  Thanks are due to T. Clausen, A. Colin de Verdiere,
>  J. Yi, A. Nikt= ash, Y. Igarashi, Satoh.  H., and U. Herberg for their
>  = development of LOADng and sharing details for ensuring
>  appro= priateness of AODVv2 for LLNs.
>
>
> 6.  Reference= s
>
> 6.1.  Normative References
>
>  = [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
>=               RFC 1812, June 1995.
&g= t;
>  [RFC2119]  Bradner, S., "Key words for use in RFCs = to Indicate
>              Require= ment Levels", BCP 14, RFC 2119, March 1997.
>
>  [RFC508= 2]  Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
> =             Pignataro, "The Generalized TTL = Security Mechanism
>              (GTSM)", RFC 5082, October 2007.
>
>  [RFC5444]&= nbsp; Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
>  &nbs= p;           "Generalized Mobile Ad Hoc Network (M= ANET) Packet/Message
>             = ; Format", RFC 5444, February 2009.
>
>  [RFC5497] = Clausen, T. and C. Dearlove, "Representing Multi-Value
>   = ;           Time in Mobile Ad Hoc Networks (MANETs= )", RFC 5497,
>              March= 2009.
>
>  [RFC5498]  Chakeres, I., "IANA Allocati= ons for Mobile Ad Hoc Network
>
>
>
> Perkins &a= mp; Chakeres      Expires April 26, 2013     = ;           [Page 36]
>
> Internet-Dr= aft                 =20 AODVv2                   = ; October 2012
>
>
>         =     (MANET) Protocols", RFC 5498, March 2009.
>
> 6= .2.  Informative References
>
>  [I-D.clausen-lln-l= oadng]
>              Clausen, T.,= Verdiere, A., Yi, J., Niktash, A., Igarashi,
>      &= nbsp;       Y., Satoh, H., Herberg, U., Lavenu, C., Lys, T.,= and C.
>              Perkins, "T= he LLN On-demand Ad hoc Distance-vector Routing
>     =         Protocol - Next Generation (LOADng)",
>&= nbsp;             draft-clausen-lln-loadng-05= (work in progress), July 2012.
>
>  [Perkins99]
>=               Perkins, C. and E. Belding-Royer, "Ad hoc On-Demand
>         =     Distance Vector (AODV) Routing", Proceedings of the 2nd
&= gt;              IEEE Workshop on Mobile= Computing Systems and
>            &nb= sp; Applications, New Orleans, LA, pp. 90-100, February 1999.
>
&= gt;  [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, Apr= il 1998.
>
>  [RFC2501]  Corson, M. and J. Macker, = "Mobile Ad hoc Networking
>            =   (MANET): Routing Protocol Performance Issues and
>   = ;           Evaluation Considerations", RFC 2501, = January 1999.
>
>  [RFC3561]  Perkins, C., Belding-= Royer, E., and S. Das, "Ad hoc On-
>         = ;     Demand Distance Vector (AODV) Routing", RFC 3561,
>              July 2003.>
>  [RFC4193]  Hinden, R. and B. Haberman, "Unique = Local IPv6 Unicast
>              = Addresses", RFC 4193, October 2005.
>
>  [RFC4728] = Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source
>   = ;           Routing Protocol (DSR) for Mobile Ad H= oc Networks for
>              IPv= 4", RFC 4728, February 2007.
>
>  [RFC4861]  Narten= , T., Nordmark, E., Simpson, W., and H. Soliman,
>     = ;         "Neighbor Discovery for IP version 6 (IPv6)",= RFC 4861,
>              Septembe= r 2007.
>
>  [RFC5148]  Clausen, T., Dearlove, C., = and B. Adamson, "Jitter
>              Considerations in Mobile Ad Hoc Networks (MANETs)",
>&= nbsp;             RFC 5148, February 2008.>
>  [RFC5340]  Coltun, R., Ferguson, D., Moy, J., an= d A. Lindem, "OSPF
>              = for IPv6", RFC 5340, July 2008.
>
>  [RFC6130]  Cla= usen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
>    &n= bsp;         Network (MANET) Neighborhood Discovery Pro= tocol (NHDP)",
>              RFC = 6130, April 2011.
>
>
>
> Perkins & Chakeres=       Expires April 26, 2013        &nb= sp;       [Page 37]
>
> Internet-Draft  &n= bsp;               AODVv2    =                 October 2012
>
>
>  [RFC6549]  Lindem, A., Roy, A.,= and S. Mirtorabi, "OSPFv2 Multi-
>         =     Instance Extensions", RFC 6549, March 2012.
>
>=   [RFC6621]  Macker, J., "Simplified Multicast Forwarding", RFC = 6621,
>              May 2012.
= >
>
> Appendix A.  Changes since the Previous Version=
>
>  o  Internet-Facing AODVv2 router renamed to b= e IAR
>
>  o  "Optional Features" section created t= o contain features not
>      required within base spe= cification, including:
>
>  o
>
>  &nb= sp;   *  Intermediate RREPs (iRREPs): Without iRREP, only the
= >        destination can respond to a RREQ.
>=
>      *  Precursor lists.
>
>      *  An RERR may reporting multiple unreac= hable nodes.
>
>      *  Message Aggregati= on.
>
>  o  Sequence number MUST (instead of SHOULD= ) be set to 1 after
>      rollover.
>
>&= nbsp; o  ThisNode MUST (instead of SHOULD) only handle AODVv2 message= s from
>      adjacent routers.
>
> = o  Clarification that Additional Routing information in RteMsgs is>      optional (MAY) to use.
>
>  o=   Clarification that if Additional Routing information in RteMsgs is>      used, then the Route Table Entry SHOULD be updat= ed using normal
>      procedures as described in Sect= ion 5.2.2.
>
>  o  Clarification in Section 5.4 tha= t nodes may be configured to
>      buffer zero packets.
>
>  o  Clarification in Section 5.4 that= buffered packets MUST be dropped
>      if route disc= overy fails.
>
>  o  In Section 5.5.1, relax mandat= e for monitoring connectivity to
>      next-hop AODVv= 2 neighbors (from MUST to SHOULD), in order to allow
>    &= nbsp; for minimal implementations
>
>
>
>
&g= t; Perkins & Chakeres      Expires April 26, 2013 =               [Page 38]
>
>= ; Internet-Draft                &nb= sp; AODVv2                  &= nbsp; October 2012
>
>
>  o  Remove Route.F= orwarding flag; identical to "NOT" Route.Broken.
>
>  o&= nbsp; Routing Messages MUST be originated with the MsgHdr.HopLimit set
>      to MSG_HOPLIMIT.  Previously, this wa= s not mandated.
>
>  o  Maximum hop count set to 25= 4, with 255 reserved for "unknown".
>      Since the c= urrent draft only uses hop-count as distance, this is
>    =   also the current maximum distance.
>
>
> Appendi= x B.  Shifting Network Prefix Advertisement Between AODVv2
>&nbs= p;           Routers
>
>  Only= one AODVv2 router within a routing region SHOULD be responsible
>&nb= sp; for a particular address at any time.  If two AODVv2 routers
&= gt;  dynamically shift the advertisement of a network prefix, correct=
>  AODVv2 routing behavior must be observed.  The AODVv2 = router adding
>  the new network prefix must wait for any exist= ing routing information
>  about this network prefix to be purged from the network.  Therefore,
>  it must wait a= t least ROUTER_SEQNUM_AGE_MAX_TIMEOUT after the
>  previous AOD= Vv2 router for this address stopped advertising routing
>  info= rmation on its behalf.
>
>
> Authors' Addresses
>=
>  Charles E. Perkins
>  Futurewei Inc.
>&n= bsp; 2330 Central Expressway
>  Santa Clara, CA  95050>  USA
>
>  Phone: +1-408-330-5305
>&nbs= p; Email: charliep@computer.org
>
>
> = Ian D Chakeres
>  CenGen
>  9250 Bendix Road Nort= h
>  Columbia, Maryland  21045
>  USA
> =
>  Email: ian.chakeres@gmail.com
> =20 URI:  http://w= ww.ianchak.com/
>
>
>
>
>
> >
> Perkins & Chakeres      Expires April 2= 6, 2013                [Page 39]> _______________________________________________
> manet mailing= list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/mane= t

_______________________________________________
manet maili= ng list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

---1725615817-289807619-1352081235=:74797-- From salo@saloits.com Sun Nov 4 18:13:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4804B21F8935 for ; Sun, 4 Nov 2012 18:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gQTeLbsh0Wq for ; Sun, 4 Nov 2012 18:13:56 -0800 (PST) Received: from server.saloits.com (saloits.com [208.42.140.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9518321F88CD for ; Sun, 4 Nov 2012 18:13:54 -0800 (PST) Received: from [192.168.254.101] (mpls.saloits.com [216.243.132.62]) by server.saloits.com (8.14.4/8.14.3) with ESMTP id qA52Dp3e007258; Sun, 4 Nov 2012 20:13:52 -0600 Message-ID: <509720D7.6050300@saloits.com> Date: Sun, 04 Nov 2012 20:13:43 -0600 From: "Timothy J. Salo" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 To: "" References: <03B78081B371D44390ED6E7BADBB4A7722052EFE@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722052EFE@xmb-rcd-x02.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 02:13:57 -0000 On 11/4/2012 7:38 PM, JP Vasseur (jvasseur) wrote: > JP> We all agree, with a a non subtle nuance. I never said that reactive > routing was a bad idea. These protocol are very useful. > They are just ill-suited to LLNs. If you design a protocol X in MANET > and explicitly mention that it would not be applicable to LLNs, > then I would personally be fine. Now if you claim that a protocol such > as Load could work in specify lightweight traffic use cases, > then can you explain why existing LLN routing protocol do not work ? The > idea is to avoid having two protocols if one is sufficient > (once again for LLNs). I don't believe that there is working group consensus on this point. And, there even appears to be some evidence to the contrary. As far as I can tell, only one person has expressed this opinion, although he has repeated it dozens of times. I would like to think that working group consensus is determined by the number of people supporting a position, not by the number of email messages that a single person can generate. -tjs From anupamjamatia@gmail.com Sun Nov 4 18:21:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5AA21F8937 for ; Sun, 4 Nov 2012 18:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZMZiqDGyKJO for ; Sun, 4 Nov 2012 18:21:54 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 69CC521F88EB for ; Sun, 4 Nov 2012 18:21:54 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so4036586lam.31 for ; Sun, 04 Nov 2012 18:21:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Gvc/hIV2SkbW3ZADJdra0OA3nhpadtAAqJj4g9mzjt4=; b=HfthY7rW1dlH2Oayg3myUIXcVlIZ9+1lEelh2JXl9zPqVHc73v37pFXzxoXuULs4Ke laHap/7204HZxzWL1CO/eylyG3Wu8WySNzcCvmy2e0Lj3StK301H5VK+GeavB2P9OFoI 4XWLjiuUmK0ysGv6nA9/+d4iRc4pu2iP090j7L3o0Mx2B1TJf2TUlS+vSIuKlyR6qjr2 oulYnj3lUyHFlIo8wRlNzJeOPtGPQb4IkI+0v3fdBfSg8hKgkCkjbhDCJV0fGwEIwUf0 KohlRWYAfTe0vHCRG9GG1Utc1l4hCf1NNDhhkNVvsXm1c1fJoQU5wP4VYzKIz+f8NIAc F/LA== Received: by 10.152.47.148 with SMTP id d20mr7738003lan.42.1352082113205; Sun, 04 Nov 2012 18:21:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.70.169 with HTTP; Sun, 4 Nov 2012 18:21:32 -0800 (PST) From: Anupam Jamatia Date: Mon, 5 Nov 2012 07:51:32 +0530 Message-ID: To: manet@ietf.org Content-Type: multipart/alternative; boundary=bcaec550ac561093cb04cdb62660 Subject: [manet] VANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 02:21:55 -0000 --bcaec550ac561093cb04cdb62660 Content-Type: text/plain; charset=UTF-8 Hi , Can any one suggest how to count the last node/vehicle (VANET enabled) in the line. AJ --bcaec550ac561093cb04cdb62660 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi , Can any one suggest how to count the last node/vehicle (VANET ena= bled) in the line.

AJ

--bcaec550ac561093cb04cdb62660-- From salo@saloits.com Sun Nov 4 19:15:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4838E21F8980 for ; Sun, 4 Nov 2012 19:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5TvSEERpMrD for ; Sun, 4 Nov 2012 19:15:19 -0800 (PST) Received: from server.saloits.com (saloits.com [208.42.140.127]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2FF21F897F for ; Sun, 4 Nov 2012 19:15:18 -0800 (PST) Received: from [192.168.254.101] (mpls.saloits.com [216.243.132.62]) by server.saloits.com (8.14.4/8.14.3) with ESMTP id qA53FFiT007382; Sun, 4 Nov 2012 21:15:16 -0600 Message-ID: <50972F44.5040901@saloits.com> Date: Sun, 04 Nov 2012 21:15:16 -0600 From: "Timothy J. Salo" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 CC: "manet@ietf.org" References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C638@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C877@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204CB91@xmb-rcd-x02.cisco.com> <1351891740.83248.YahooMailNeo@web160605.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204D717@xmb-rcd-x02.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 03:15:20 -0000 > Let us concentrate on LOADng and DYMO documents and find a way forward. I believe that it _may_ make sense to _consider_ two documents: one document that specifies a core reactive protocol for MANETs and another document that specifies extensions to the core reactive protocol. This approach _may_ have the benefit of enabling the core protocol specification to move more quickly towards an Internet standard. In particular, I am concerned that a specification that contains a number of extensions or options may lead to difficulties in finding two interoperable implementations. I vaguely recall instances in the past were the available implementations didn't implement all of the options specified in a draft standard. I forget the result of these discussions, and whether there is a consistent answer. But, I though that some standards-track documents have been revised to exclude options for which there were not two independent implementations. Might it be prudent to avoid this situation by splitting the reactive protocol specification into two documents? Of course, the approach of base and extensions documents does pose some risks. First, we might not agree on what the base protocol is, and whether the LOADng document accurately reflects that group consensus on what ought be be in the base protocol. Second, the base protocol might not accurately reflect the experience of the available modeling and field deployment experience. This might give rise to some risk that the working group might select the wrong functionality for inclusion in a base protocol specification. My concerns would be somewhat alleviated if there are good prospect that two interoperable implementations of the DYMO-based (base+extensions) approach exist and that their developers are committed to upgrading them to whatever protocol (including options/extensions) the working group finally agrees upon. I think that it would be useful to have more information about the state of DYMO and LOADng implementations, including the prospects that these implementations will conform to the eventual working group consensus. In my view, the working group really ought to have detailed information about the current and prospective implementations before deciding on an approach -- I would be surprised if this information could be pulled together in sufficient detail by the Atlanta meetings. -tjs From trac+manet@trac.tools.ietf.org Sun Nov 4 20:52:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B956821F8A0A for ; Sun, 4 Nov 2012 20:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCg+sT4XlueL for ; Sun, 4 Nov 2012 20:52:44 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 195F921F89B1 for ; Sun, 4 Nov 2012 20:52:44 -0800 (PST) Received: from localhost ([127.0.0.1]:44453 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVEfl-0001wi-VZ; Mon, 05 Nov 2012 05:52:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "manet issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Mon, 05 Nov 2012 04:52:29 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/5 Message-ID: <061.db3c48158682d65cd854a9d5c40c741f@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: [manet] #5: Reorganizing the route table entry timeout management X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 04:52:44 -0000 #5: Reorganizing the route table entry timeout management The current set of route timeouts and concepts is confusing. Instead, one can view a route table entry as having a normal lifetime progressing through the following stages: Active --> Idle --> Expired --> Expunged. Alternatively a route can be prematurely invalidated if one of its path components breaks (i.e., the link to a next hop breaks). By reorganizing route lifetime information in this way, a much simpler description can be given. The following proposed text should make this approach clearer. Instead of previous manifest constants for various timeout information, the new approach only requires ACTIVE_INTERVAL, MAX_IDLETIME, and MAX_SEQNUM_LIFETIME. The following text has been (provisionally) added to Section 4.1. ======================================================================== A route table entry (i.e., a route) may be in one of the following states: Active An Active route is in current use for forwarding packets Idle An Idle route can be used for forwarding packets, even though it is not in current use Expired After a route has been idle for too long, it expires, and may no longer be used for forwarding packets Broken A route marked as Broken cannot be used for forwarding packets but still has valid destination sequence number information. The route's state determines the operations that can be performed on the route table entry. During use, an Active route is maintained continuously by AODVv2 and is considered to remain active as long as it is used at least once every ACTIVE_INTERVAL. When a route is no longer Active, it becomes an Idle route. After a route remains Idle for MAX_IDLETIME, it becomes an Expired route; after that, the route is not used for forwarding, but the sequence number information is maintained until the destination sequence number has had no updates for MAX_SEQNUM_LIFETIME. After MAX_SEQNUM_LIFETIME, old sequence number information is considered no longer valuable and the route is expunged. MAX_SEQNUM_LIFETIME is the time after a reboot during which an AODVv2 router MUST NOT transmit any routing messages. Thus, if all other AODVv2 routers expunge routes to the rebooted router after that time interval, the rebooted AODVv2 router's sequence number will not be considered stale by any other AODVv2 router in the MANET. When the link to a route's next hop is broken, the route is in the Broken state, and it may no longer be used. ======================================================================== Note that if (ACTIVE_INTERVAL + MAX_IDLETIME) == MAX_SEQNUM_LIFETIME, then a route has to be expunged as soon as it has been idle too long. This has little negative impact on the base protocol but may eliminate the possibility for some optional features related to route repair. -- --------------------------------+----------------------------- Reporter: charliep@… | Owner: Charlie Perkins Type: defect | Status: new Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Keywords: route timeouts --------------------------------+----------------------------- Ticket URL: manet From trac+manet@trac.tools.ietf.org Sun Nov 4 21:07:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B527F21F8A47 for ; Sun, 4 Nov 2012 21:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWGqZNvKBH2Y for ; Sun, 4 Nov 2012 21:07:47 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 12C8721F8954 for ; Sun, 4 Nov 2012 21:07:47 -0800 (PST) Received: from localhost ([127.0.0.1]:46552 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVEuN-0005Or-4L; Mon, 05 Nov 2012 06:07:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "manet issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Mon, 05 Nov 2012 05:07:35 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/6 Message-ID: <061.132760a1d00e99fedcf3e89100775c1a@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: [manet] #6: sequence number incrementation mandate X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 05:07:47 -0000 #6: sequence number incrementation mandate Previous versions of DYMO *strongly recommend* incrementation of !OwnSeqNum upon generation of every new RREQ or RREP message, but do not impose a strict mandate. This leads to some uncertainty about whether there are cases when the incrementation should not be performed. Demonstrations have been made in the past about the differences, but it is not clear that these differences have caused any performance degradation. For the purposes of making the current document more readable, and since there seems to be little downside, it is proposed to change "SHOULD" increment to "MUST" increment in all relevant cases, including RREQ retries. If future studies illustrate the circumstances under which sequence number incrementation may be avoided, description of those circumstances should be added to the document and the specification changed in those circumstances. -- --------------------------------+---------------------------------------- Reporter: charliep@… | Owner: Charlie Perkins Type: enhancement | Status: new Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Keywords: Sequence number management --------------------------------+---------------------------------------- Ticket URL: manet From charliep@computer.org Sun Nov 4 21:56:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAAC521F86E7 for ; Sun, 4 Nov 2012 21:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLl1mbxdc8rG for ; Sun, 4 Nov 2012 21:56:49 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7368B21F88D9 for ; Sun, 4 Nov 2012 21:56:40 -0800 (PST) Received: from [130.129.66.42] by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TVFfh-0006qR-6U; Mon, 05 Nov 2012 00:56:29 -0500 Message-ID: <5097550A.9010300@computer.org> Date: Sun, 04 Nov 2012 21:56:26 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "manet@ietf.org" References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C638@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C877@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204CB91@xmb-rcd-x02.cisco.com> <1351891740.83248.YahooMailNeo@web160605.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204D717@xmb-rcd-x02.cisco.com> <50972F44.5040901@saloits.com> In-Reply-To: <50972F44.5040901@saloits.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad867a0ccac5890239375ec1173cd2703160350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.66.42 Cc: "Timothy J. Salo" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 05:56:51 -0000 Hello folks, I'm working away on a new revision. The terminology has been significantly improved. I need to respond to many email messages, but there are so many! The feature descriptions in the previous specifications has become much more clear. I've got RFC 5444 packet formats to add to the spec, probably will finish this tomorrow. The text for the reorganized route timeouts is much more compact and understandable than the previous revisions. There is a small reduction in flexibility compared to previous versions, but it takes a very close reading (which I have done) to figure out where. I'm pretty sure the extra bits of flexibility regarding route timeouts will never be missed. This email caught my attention: On 11/4/2012 7:15 PM, Timothy J. Salo wrote: > > Of course, the approach of base and extensions documents does > pose some risks. First, we might not agree on what the base protocol > is, and whether the LOADng document accurately reflects that group > consensus on what ought be be in the base protocol. Second, the > base protocol might not accurately reflect the experience of the > available modeling and field deployment experience. This might > give rise to some risk that the working group might select the > wrong functionality for inclusion in a base protocol specification. > > My concerns would be somewhat alleviated if there are good prospect > that two interoperable implementations of the DYMO-based > (base+extensions) approach exist and that their developers are > committed to upgrading them to whatever protocol (including > options/extensions) the working group finally agrees upon. I remain ever more confident that this can (and *should*) be done. Certain features (intermediate RREP as just one example) need to be considered so that they have a natural fit with the "base protocol". > > I think that it would be useful to have more information about the > state of DYMO and LOADng implementations, including the prospects > that these implementations will conform to the eventual working > group consensus. In my view, the working group really ought to > have detailed information about the current and prospective > implementations before deciding on an approach -- I would be > surprised if this information could be pulled together in sufficient > detail by the Atlanta meetings. I will try to make as much information available as possible, and in particular to make available a next revision that does not have so many hasty inconsistencies as the last two (after ...-21.txt). And the ...-21.txt revision had its various inconsistencies that I have been repairing . Please keep in mind that the revision process since I resumed editorial duties has been "alloted" less than a month of my time, and I am sure you will notice rapid progress since then. -- Regards, Charlie P. From charliep@computer.org Sun Nov 4 22:01:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B45821F8AA7 for ; Sun, 4 Nov 2012 22:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3knsV6wdVOT8 for ; Sun, 4 Nov 2012 22:01:14 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id C6D7721F8A9F for ; Sun, 4 Nov 2012 22:01:14 -0800 (PST) Received: from [130.129.66.42] by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TVFkI-0005iW-D5 for manet@ietf.org; Mon, 05 Nov 2012 01:01:14 -0500 Message-ID: <50975629.4050301@computer.org> Date: Sun, 04 Nov 2012 22:01:13 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86826f6f96128ea712b5e78952b5fc1c39350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.66.42 Subject: [manet] DSR X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 06:01:15 -0000 Hello folks, When the reactive work was chartered, it was considered important to support both DSR and AODV. How many people on this list know about DSR? How many people care about supporting a Proposed Standard reactive protocol that enables deployment of DSR features as optional features? Please note that DSR has had much study and many deployments and even some availability from Microsoft. If the aim and purpose of the original charter item are to be contravened, due to lack of interest in DSR, then certain design points about AODVv2 can be re-examined. Otherwise, I am confident that the optional features needed to support DSR-like protocol can be designed in a way still compatible with the needs of LOADng. -- Regards, Charlie P. From hrogge@googlemail.com Sun Nov 4 23:20:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC6621F8B07 for ; Sun, 4 Nov 2012 23:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlFwwfvfeuop for ; Sun, 4 Nov 2012 23:20:06 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD51321F8B04 for ; Sun, 4 Nov 2012 23:20:06 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so3711042pad.31 for ; Sun, 04 Nov 2012 23:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=edShuwef1uvFuEY5TfgI27kgf5ihOIbF/VWpedO15jQ=; b=eBuj4/yUFrtByk1YdVsbx6/dBpNoQmwaxJWhfwQP1fTzTAJsJIEcymCM+t7qq+Ac3j 50dP7cbttyol4MOkY+gOQOqZmrmaUTudwsxo/mf3qmWPpMrnwtTnjBykSRZaH1x8kTCY lUc0MP0XTg6MAWBhqQhBLUcLVDpCaLo5e2oGaErR8BGMte6KnvQ8I8bO0/1c3gVGbJ9v PfHev+BxS3rG0p0l0aTHka+sqAng/rUOYldAwQHDtVF2Qcp0GjnOZbBV+ysHygDhVw7N ps9kmaoaE5mEk9sDsh4gt5d0sdcognn1rtGouhRsNEd9p5AA2Wsi6tFwTjBzTY9Dh4xm iwwQ== Received: by 10.66.77.105 with SMTP id r9mr25970005paw.76.1352100006454; Sun, 04 Nov 2012 23:20:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Sun, 4 Nov 2012 23:19:46 -0800 (PST) In-Reply-To: References: From: Henning Rogge Date: Mon, 5 Nov 2012 08:19:46 +0100 Message-ID: To: Anupam Jamatia Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] VANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 07:20:07 -0000 Hi AJ, maybe you can deliver a little bit more context about your question? Henning Rogge On Mon, Nov 5, 2012 at 3:21 AM, Anupam Jamatia wrote: > Hi , Can any one suggest how to count the last node/vehicle (VANET enabled) > in the line. -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From hrogge@googlemail.com Sun Nov 4 23:21:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4960D21F8B22 for ; Sun, 4 Nov 2012 23:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wy+bskgkathQ for ; Sun, 4 Nov 2012 23:21:52 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id CDD4D21F8B07 for ; Sun, 4 Nov 2012 23:21:52 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so2548442dan.31 for ; Sun, 04 Nov 2012 23:21:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VlBK/O7MHV03MEZ7JxB8EeEOoRCXq4FILZhkewApS4s=; b=XXibDXthKP4AAVsRbPNHGjabF1JgvyQawgv7PEB4aFxCg7aoaD7XJ1Mt1RlD7oELai zyi+n9iZFBHPiq8Zik74jW5CYzMTADaGW7RL0Frfx8XUskRbY+E3pVcj3h8iH1NOwHSH uq2FyusaJPtR0229WUXKjgK7UstXk7H0384C+gumiodq+Q/8OGssNwpJWsj6OBL8y/eo E+/FEVgP/5Qcx1T+N2l2aGpVJYNfr0PNp/1nIyhgDj+EWhzbdG+A3O87eHR2MIP42WX6 ViJCbzVleDDNMj6pchiEpV7eYItn4tNdEp6iDBFBylNf1cY7MF4kaef1+ZtjSVF3RAre 35ow== Received: by 10.68.138.198 with SMTP id qs6mr27990609pbb.151.1352100112525; Sun, 04 Nov 2012 23:21:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Sun, 4 Nov 2012 23:21:32 -0800 (PST) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722052EFE@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A7722052EFE@xmb-rcd-x02.cisco.com> From: Henning Rogge Date: Mon, 5 Nov 2012 08:21:32 +0100 Message-ID: To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 07:21:53 -0000 On Mon, Nov 5, 2012 at 2:38 AM, JP Vasseur (jvasseur) wrote: > JP> We all agree, with a a non subtle nuance. I never said that reactive > routing was a bad idea. These protocol are very useful. > They are just ill-suited to LLNs. At least that is your personal opinion. We got this, no need to repeat it again. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From anupamjamatia@gmail.com Sun Nov 4 23:46:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D2721F8AFC for ; Sun, 4 Nov 2012 23:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_00=-2.599, DEAR_SOMETHING=1.605, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53r2nk-FhwtO for ; Sun, 4 Nov 2012 23:46:38 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C9B2F21F8AD1 for ; Sun, 4 Nov 2012 23:46:37 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so4188387lbo.31 for ; Sun, 04 Nov 2012 23:46:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=N4jCb4H0sqDiCizH/Y4I4GWSLDv1zGT4wOF6dgSJw40=; b=t/6lEPfX22bq5RU29k2u6zBYm4Tkm5ytp8Y9RN8rImkGegfIne/ZgmsB/8Y/XL4Pbi e3S40syiAWXBJbeg2GKVBPVbIRaEwoLwy3mKtsJlBLB2R9DjiTN9EsOERFDL3CegvLmz 9IIw3KBH9wXJusYbRphfGnF9T8G+0sJ7eQ8mn8AN5f+BijxNH5m9DQgG3fqM9UH9oWSf BKCkjZtfTTPoMi5crEE3AF8nyL0X/4ExDjkNlgPZiOD6vFMfcOkj+hHiqOkU3xiCWQLm oqTQuquSIf1Ifm7NoqVOE+bl+7F7hEXY0b2O4M2rB9HOqRh4w6b7hDxUdgJ/ZwClkhJ4 bUZA== Received: by 10.112.41.2 with SMTP id b2mr3542865lbl.5.1352101596768; Sun, 04 Nov 2012 23:46:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.70.169 with HTTP; Sun, 4 Nov 2012 23:46:16 -0800 (PST) In-Reply-To: References: From: Anupam Jamatia Date: Mon, 5 Nov 2012 13:16:16 +0530 Message-ID: To: Henning Rogge , manet@ietf.org Content-Type: multipart/alternative; boundary=e0cb4efe2a28602ad104cdbaaf9b Subject: Re: [manet] VANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 07:46:38 -0000 --e0cb4efe2a28602ad104cdbaaf9b Content-Type: text/plain; charset=UTF-8 | On Mon, Nov 5, 2012 at 12:49 PM, Henning Rogge wrote: | Hi AJ, | maybe you can deliver a little bit more context about your question? \-- Dear Sir , Actually I am trying to find the possible ways which will count the last node/vehicle in the line of vehicle/node using WAVE technology. Thanks & Regards AJ --e0cb4efe2a28602ad104cdbaaf9b Content-Type: text/html; charset=UTF-8
| On Mon, Nov 5, 2012 at 12:49 PM, Henning Rogge <hrogge@googlemail.com> wrote:
| Hi AJ,
| maybe you can deliver a little bit more context about your question?
\--

Dear Sir , Actually I am trying to find the possible ways which will count the last node/vehicle in the line of vehicle/node using WAVE technology.
Thanks & Regards
AJ

--e0cb4efe2a28602ad104cdbaaf9b-- From c.chauvenet@watteco.com Mon Nov 5 01:29:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EA421F8992 for ; Mon, 5 Nov 2012 01:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.685 X-Spam-Level: X-Spam-Status: No, score=-3.685 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhWMg9+uWNAA for ; Mon, 5 Nov 2012 01:29:54 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 621D321F88BB for ; Mon, 5 Nov 2012 01:29:53 -0800 (PST) Received: from mail190-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Mon, 5 Nov 2012 09:29:52 +0000 Received: from mail190-ch1 (localhost [127.0.0.1]) by mail190-ch1-R.bigfish.com (Postfix) with ESMTP id D6D083800CD; Mon, 5 Nov 2012 09:29:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz98dI9371Ic89bhc85dh1418Izz1de0h1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received: from mail190-ch1 (localhost.localdomain [127.0.0.1]) by mail190-ch1 (MessageSwitch) id 1352107790434962_24740; Mon, 5 Nov 2012 09:29:50 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241]) by mail190-ch1.bigfish.com (Postfix) with ESMTP id 635C3320054; Mon, 5 Nov 2012 09:29:50 +0000 (UTC) Received: from DBXPRD0510HT001.eurprd05.prod.outlook.com (157.56.252.165) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 5 Nov 2012 09:29:48 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT001.eurprd05.prod.outlook.com ([10.255.67.164]) with mapi id 14.16.0233.002; Mon, 5 Nov 2012 09:29:43 +0000 From: C Chauvenet To: Jon Black Thread-Topic: [manet] LOADng works Thread-Index: AQHNuEYjLqnfvWsGTUKn5f9jVwDGQ5fVTi6AgACcCgCAAEpAgIAAgxWAgAARjwCAAAO+gIAAY4+AgAAC8gCAAJezgIAAcB4AgAFsFQCAAAqgAIAAC4gAgAALpYCAALkZAIAAfXuA Date: Mon, 5 Nov 2012 09:29:42 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D215775D9@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772205284E@xmb-rcd-x02.cisco.com> <1352080838.3583.YahooMailNeo@web160606.mail.bf1.yahoo.com> In-Reply-To: <1352080838.3583.YahooMailNeo@web160606.mail.bf1.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.42.4] Content-Type: multipart/alternative; boundary="_000_97B69B30E0EF244B940B65EA541E3F2D215775D9DBXPRD0510MB395_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 09:29:55 -0000 --_000_97B69B30E0EF244B940B65EA541E3F2D215775D9DBXPRD0510MB395_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Le 5 nov. 2012 =E0 03:00, Jon Black a =E9crit : This not not what JP is requiring. He is not saying that the document shou= ld not mention LLNs, but instead it would explicitly "it should not be use = in LLNs". This is something quite different and technically and intellectu= ally dishonest Don't agree, as I already got exactly the same "intellectually dishonest" r= emark, but from a different author... C=E9dric. , but again JP has hijacked the conversation. Jon ________________________________ From: Daniel He > To: JP Vasseur (jvasseur) > Cc: Timothy J. Salo >; "manet@iet= f.org" > Sent: Sunday, November 4, 2012 7:58 AM Subject: Re: [manet] LOADng works I think it is fair enought to replace the name. and I knew you don't like L= LN at all. and I agree to LLN taken out of the context is reasonable and gener= ized. Cheers, Dan On 4 November 2012 14:16, JP Vasseur (jvasseur) > wrote: On Nov 4, 2012, at 8:35 AM, Daniel He wrote: I still don't beleive that LOADng deployments fit MANETs' applicabilities. Therefore, disagree with the subject claimed (i.e. LOADng works). I totally disagree! LOADng is fitting to MANET. fundamentally it is lightweighted AODV. Here is my take on this; *if* there is a choice for option 1, 2 or may be a= brand new document related to reactive routing in MANET (protocol called AODVv20, and excluding LLNs, the= n I think that we do not have any issue. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet -- Dan He --------------------- Tel: +44-788-686-3428 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_97B69B30E0EF244B940B65EA541E3F2D215775D9DBXPRD0510MB395_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Le 5 nov. 2012 =E0 03:00, Jon Black a =E9crit :

This not not what JP is requiring.  He is not saying that the document= should not mention LLNs, but instead it would explicitly "it should n= ot be use in LLNs".  This is something quite different and techni= cally and intellectually dishonest

Don't agree, as I already got exactly the same "intellectually dishonest" remark, bu= t from a different author...

C=E9dric.

, but again JP has hijacked the conversation.

Jon 


From: Daniel He <drdanhe@gmail.com>
To: JP Vasseur (jvasseur) = <jvasseur@cisco.com>
Cc: Timothy J. Salo <salo@saloits.com>; "manet@ietf.org" <manet@ietf.org>
Sent: Sunday, November 4, = 2012 7:58 AM
Subject: Re: [manet] LOADn= g works

I think it is fair enought to replace the name. a= nd I knew you don't like LLN
at all. and I agree to LLN taken out of the context is reasonable and gener= ized.

Cheers,
Dan

On 4 November 2012 14:16, JP Vasseu= r (jvasseur) <jvasseur@cisco.co= m> wrote:

On Nov 4, 2012, at 8:35 AM, Daniel He wrote:


I still don't beleive that LOADng deployments fit MANETs'
applicabilities. Therefore, disagree with the subject claimed (i.e.
LOADng works).

I totally disagree!  LOADng is fitting to MANET. fundamentally it is lightweighted AODV.

Here is my take on this; *if* there is a choice for option 1, 2 or may= be a brand new document related to
reactive routing in MANET (protocol called AODVv20, and excluding LLNs= , then I think that we do not 
have any issue.


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet




--
Dan He
---------------------
Tel: +44-788-686-3428


_______________________________________________
manet mailing list
manet@i= etf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_97B69B30E0EF244B940B65EA541E3F2D215775D9DBXPRD0510MB395_-- From c.chauvenet@watteco.com Mon Nov 5 01:50:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5903221F85A0 for ; Mon, 5 Nov 2012 01:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.677 X-Spam-Level: X-Spam-Status: No, score=-3.677 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kF8LnpGUfKWD for ; Mon, 5 Nov 2012 01:50:54 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 47BD121F84E6 for ; Mon, 5 Nov 2012 01:50:54 -0800 (PST) Received: from mail74-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Mon, 5 Nov 2012 09:50:53 +0000 Received: from mail74-ch1 (localhost [127.0.0.1]) by mail74-ch1-R.bigfish.com (Postfix) with ESMTP id 995161401E7; Mon, 5 Nov 2012 09:50:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz98dI9371Ic89bhc85dh1418Izz1de0h1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received: from mail74-ch1 (localhost.localdomain [127.0.0.1]) by mail74-ch1 (MessageSwitch) id 1352109051266574_2125; Mon, 5 Nov 2012 09:50:51 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail74-ch1.bigfish.com (Postfix) with ESMTP id 366AC320049; Mon, 5 Nov 2012 09:50:51 +0000 (UTC) Received: from DBXPRD0510HT001.eurprd05.prod.outlook.com (157.56.252.165) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 5 Nov 2012 09:50:51 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT001.eurprd05.prod.outlook.com ([10.255.67.164]) with mapi id 14.16.0233.002; Mon, 5 Nov 2012 09:50:49 +0000 From: C Chauvenet To: Jon Black Thread-Topic: [manet] LOADng works Thread-Index: AQHNuEYjLqnfvWsGTUKn5f9jVwDGQ5fVTi6AgACcCgCAAEpAgIAAgxWAgAARjwCAAAO+gIAAY4+AgAAC8gCAAJezgIAAcB4AgAFsFQCAAAqgAIAAC4gAgAALpYCAALkZAIAAg2CA Date: Mon, 5 Nov 2012 09:50:49 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D215776F6@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772205284E@xmb-rcd-x02.cisco.com> <1352080838.3583.YahooMailNeo@web160606.mail.bf1.yahoo.com> In-Reply-To: <1352080838.3583.YahooMailNeo@web160606.mail.bf1.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.42.4] Content-Type: multipart/alternative; boundary="_000_97B69B30E0EF244B940B65EA541E3F2D215776F6DBXPRD0510MB395_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 09:50:55 -0000 --_000_97B69B30E0EF244B940B65EA541E3F2D215776F6DBXPRD0510MB395_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jon Black, Overall, I don't understand your enthusiasm for LOADng. Do you have some experiments with this protocol ? BTW, I notice that your time-window activity slipped from a few hours. Did you finally moved toward Atlanta to defend your opinion ? Last but not least, it seems that one of the main LOADng authors did not st= ate his opinion in this debate ? C=E9dric. Le 5 nov. 2012 =E0 03:00, Jon Black a =E9crit : This not not what JP is requiring. He is not saying that the document shou= ld not mention LLNs, but instead it would explicitly "it should not be use = in LLNs". This is something quite different and technically and intellectu= ally dishonest, but again JP has hijacked the conversation. Jon ________________________________ From: Daniel He > To: JP Vasseur (jvasseur) > Cc: Timothy J. Salo >; "manet@iet= f.org" > Sent: Sunday, November 4, 2012 7:58 AM Subject: Re: [manet] LOADng works I think it is fair enought to replace the name. and I knew you don't like L= LN at all. and I agree to LLN taken out of the context is reasonable and gener= ized. Cheers, Dan On 4 November 2012 14:16, JP Vasseur (jvasseur) > wrote: On Nov 4, 2012, at 8:35 AM, Daniel He wrote: I still don't beleive that LOADng deployments fit MANETs' applicabilities. Therefore, disagree with the subject claimed (i.e. LOADng works). I totally disagree! LOADng is fitting to MANET. fundamentally it is lightweighted AODV. Here is my take on this; *if* there is a choice for option 1, 2 or may be a= brand new document related to reactive routing in MANET (protocol called AODVv20, and excluding LLNs, the= n I think that we do not have any issue. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet -- Dan He --------------------- Tel: +44-788-686-3428 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_97B69B30E0EF244B940B65EA541E3F2D215776F6DBXPRD0510MB395_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <962E8EF09BC39343BA048D2302DC5AB4@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Jon Black, 

Overall, I don't understand your enthusiasm for LOADng.
Do you have some experiments with this protocol ?

BTW, I notice that your time-window activity slipped from a few hours.=
Did you finally moved toward Atlanta to defend your opinion ?

Last but not least, it seems that one of the main LOADng authors did n= ot state his opinion in this debate ?

C=E9dric.

Le 5 nov. 2012 =E0 03:00, Jon Black a =E9crit :

This not not what JP is requiring.  He is not saying that the document= should not mention LLNs, but instead it would explicitly "it should n= ot be use in LLNs".  This is something quite different and techni= cally and intellectually dishonest, but again JP has hijacked the conversation.

Jon 


From: Daniel He <drdanhe@gmail.com>
To: JP Vasseur (jvasseur) = <jvasseur@cisco.com>
Cc: Timothy J. Salo <salo@saloits.com>; "manet@ietf.org" <manet@ietf.org>
Sent: Sunday, November 4, = 2012 7:58 AM
Subject: Re: [manet] LOADn= g works

I think it is fair enought to replace the name. a= nd I knew you don't like LLN
at all. and I agree to LLN taken out of the context is reasonable and gener= ized.

Cheers,
Dan

On 4 November 2012 14:16, JP Vasseu= r (jvasseur) <jvasseur@cisco.co= m> wrote:

On Nov 4, 2012, at 8:35 AM, Daniel He wrote:


I still don't beleive that LOADng deployments fit MANETs'
applicabilities. Therefore, disagree with the subject claimed (i.e.
LOADng works).

I totally disagree!  LOADng is fitting to MANET. fundamentally it is lightweighted AODV.

Here is my take on this; *if* there is a choice for option 1, 2 or may= be a brand new document related to
reactive routing in MANET (protocol called AODVv20, and excluding LLNs= , then I think that we do not 
have any issue.


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet




--
Dan He
---------------------
Tel: +44-788-686-3428


_______________________________________________
manet mailing list
manet@i= etf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_97B69B30E0EF244B940B65EA541E3F2D215776F6DBXPRD0510MB395_-- From abdussalambaryun@gmail.com Mon Nov 5 04:05:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7608821F8482 for ; Mon, 5 Nov 2012 04:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zzj4NH2CF6o2 for ; Mon, 5 Nov 2012 04:05:02 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44DF121F8487 for ; Mon, 5 Nov 2012 04:05:01 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so6412731vcb.31 for ; Mon, 05 Nov 2012 04:05:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B+DoSS43Otqzhb8bSBoihp7yjHavGO8oL4UDlFVwg88=; b=RQx4Nt0L2pTAFgRu5I8K+Ht8uByaBfdB/cizUjM4lpCzuuEXui3r8dQ+HnkCpp88zb ec8rcLKHfrRYtfLafYps4O13MbdtBGGdWt33bYxxkjQvHpdlaTcN1zVdBjs+LXOw3IQv y+/nSZIhJi/LA5D4FXGOrEvSI6ym1f8ZS2cayA7G4ObVeSMFj0u/DT4cGodzipayhxzZ 6rfLglEc0w3ZtsZkHV7lYnl55pYo9/ACLdYURnop7gBNXlMJq14jnYIxVOse+qjCtZFM d3MKp8CNyaj/3T3lQuvifaNB5nMlAs+4yeRkY3ahrI6Ru6hV61lJtYOP3zDU2Y9/Ifdq JlTg== MIME-Version: 1.0 Received: by 10.52.90.99 with SMTP id bv3mr7876495vdb.125.1352117100737; Mon, 05 Nov 2012 04:05:00 -0800 (PST) Received: by 10.220.204.9 with HTTP; Mon, 5 Nov 2012 04:05:00 -0800 (PST) In-Reply-To: <50975629.4050301@computer.org> References: <50975629.4050301@computer.org> Date: Mon, 5 Nov 2012 13:05:00 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] DSR X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 12:05:02 -0000 I am already in work on the DSRv2 started before months (announced on list), planned to submit to ietf in january and share your interest in DSR, thanking you, AB On 11/5/12, Charles E. Perkins wrote: > > Hello folks, > > When the reactive work was chartered, it was considered > important to support both DSR and AODV. > > How many people on this list know about DSR? > > How many people care about supporting a Proposed Standard > reactive protocol that enables deployment of DSR features as > optional features? > > Please note that DSR has had much study and many > deployments and even some availability from Microsoft. > > If the aim and purpose of the original charter item are > to be contravened, due to lack of interest in DSR, then > certain design points about AODVv2 can be re-examined. > > Otherwise, I am confident that the optional features > needed to support DSR-like protocol can be designed > in a way still compatible with the needs of LOADng. > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Mon Nov 5 04:11:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CF221F85D3 for ; Mon, 5 Nov 2012 04:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pj6s04CxAkam for ; Mon, 5 Nov 2012 04:11:07 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1BC21F8531 for ; Mon, 5 Nov 2012 04:11:06 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so6480554vbb.31 for ; Mon, 05 Nov 2012 04:11:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vQAosh971zEqtd0E/q28wLKEcDKXnB7NGRNTnC4qaXU=; b=ASG7K6hE8+wi85C2d4wWHAklvtF6sIXzojvzxQyLtKKqNyKbh4+1swDtl2hlKrZO+H yCmDjPOc96rJyl8plMf9vDZXblfM60y2oidsU5Udcst5WEYVSJ3HAdASXTZSsUFS5eZb 2BIZu3l18xNqH7HY2hx8hYFLK63kuGKd2SY5faJvzyUb7zwCQQdhxUXp28ShQerej+5d Etx+mmImaiaa6lAdQG/r8gBl9qBAoMiQ3rTOORhjgKb+N6mGFav1jTc1zskcYAxXm27L 82QMGIFNCUv1Rwd97Uj0G/CtnqPTpeeQTA7QOaJF37sqQ5x/ByGbUEa/UgCpFDAyhXD9 D0Bg== MIME-Version: 1.0 Received: by 10.52.77.101 with SMTP id r5mr8014726vdw.25.1352117465597; Mon, 05 Nov 2012 04:11:05 -0800 (PST) Received: by 10.220.204.9 with HTTP; Mon, 5 Nov 2012 04:11:05 -0800 (PST) In-Reply-To: <001001cdba98$b6b03910$2410ab30$@olddog.co.uk> References: <001001cdba98$b6b03910$2410ab30$@olddog.co.uk> Date: Mon, 5 Nov 2012 13:11:05 +0100 Message-ID: From: Abdussalam Baryun To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] DYMO Milestone date X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 12:11:07 -0000 Hi Adrian, I just needed a respond from management of the WG relating to the our draft. If managers don't respond to some inputs, then I think there is no value at all in participating. I think you agree with my concerns. Thanks for your respond, AB On 11/4/12, Adrian Farrel wrote: > Hey Abdussalam, > > You are right that a milestone will be needed. > > But do you think that it might be a good idea to wait for the resolution of > the > current WG discussion about AODVv2 before determining a milestone. For > example, > if option 3 is selected, we clearly don't need a milestone. And the choice > of > starting point is also going to affect the delivery. > > I see no value in setting an artificial project management deadline, and I > see > no value in setting it without being able to do the necessary planning > tasks. > > Adrian > >> -----Original Message----- >> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >> Sent: 04 November 2012 13:08. >> To: jpmacker@gmail.com; Stan Ratliff >> Cc: manet; adrian >> Subject: DYMO Milestone date >> >> Dear MANET Chairs, >> >> Please note that I already requested on the MANET-list to provide our >> WG draft dymo a milestone date, but still you did n't update or even >> respond. Please note that this will be my last reminder, and I will >> send a complain as procedure satates if you continue to ignore such >> input. >> >> Best Regards >> Abdussalam Baryun > > From abdussalambaryun@gmail.com Mon Nov 5 04:32:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2A321F85DF for ; Mon, 5 Nov 2012 04:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hhy08KeWzhth for ; Mon, 5 Nov 2012 04:32:51 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2807821F85BC for ; Mon, 5 Nov 2012 04:32:51 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so6504029vbb.31 for ; Mon, 05 Nov 2012 04:32:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fYJ9Ox49O8Q8dgsl9RZngNu496OtUDGcf3XEbYdraFk=; b=a/NEUM16mjZTkeJuoEriaTZT+Rb9Gcq8f9EMc6RkPMg7ti2RJ1bCRWyCFPdTPsjmXZ e+A67xNgNjvNVC9oNYailXLlbeqKUNA7IGPWTNSAKSwcjV1IvuQJsY210wFCrVVwgGm/ 13n3BwcyYFJ6k96LGUrZnkeH4AEBJdSpQLIrkNwGypQc2gdahdwfb33beSTDxSJ8soCA IpF1H5V0AHHdxoErE7SwfzmZd/bpSrmiMpaUGNdBr68eJE2l1MCRJNvVkORj2a6/zWmN 4zByGH8r5Nrq/a4yE4p2ZVPhrt6oUh8P7nnyhrUXW4kHp1S0/1nujbjfOOACrvLxL5+F 3xqw== MIME-Version: 1.0 Received: by 10.52.35.82 with SMTP id f18mr7939834vdj.99.1352118770599; Mon, 05 Nov 2012 04:32:50 -0800 (PST) Received: by 10.220.204.9 with HTTP; Mon, 5 Nov 2012 04:32:49 -0800 (PST) In-Reply-To: References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> Date: Mon, 5 Nov 2012 13:32:49 +0100 Message-ID: From: Abdussalam Baryun To: Joseph Macker Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 12:32:51 -0000 Hi Joe, I agree that AODV and DYMO are applicable for MANET (there are references to such protocol for MANETs), because the MANETs include all dynamic networks' requirements and tests. The LOADng protocol was tested for LLNs, we should not ignore facts/practices and history of such protocols. The LOADng implementations are different than AODV and DYMO implementations, therefore, I suggest LOADng is not similar to AODV performance. IMHO, the output performance of such protocols will judge thoes protocols. LOADng can be modified to cover all MANET scenarios or LOADng needs to be proved that it works within all MANET scenarios (still waiting for a reference from any participant). AB ++++++++++++ On 11/4/12, Joseph Macker wrote: > Since LOADng, DYMO, and AODV are about the same technically, in my opinion, > are you claiming that AODV-based designs do not work for MANETs? Thats > what I am hearing technically and I have no problem hearing that opinion > but there seems to be a fallacy in the actual argument being made. In my > opinon if LOADng is not appropriate for MANET then neither is AODV or DYMO > since the design principles are basically the same. Back to #3 in that > case. > > > On Sun, Nov 4, 2012 at 7:57 AM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> Hi Joe, >> >> My question was always as the subject claims; Where does LOADng Work, >> please give me a reference document of performance and practice? >> Please note that the authors were asked about this before in MANET WG >> but the answer was we cannot provide information because classified. >> This is confusing and without progress. >> >> I still don't beleive that LOADng deployments fit MANETs' >> applicabilities. Therefore, disagree with the subject claimed (i.e. >> LOADng works). >> >> Let us focus the question for our charter; Does the LOADng work with >> MANETs scenarios and applicabilities or does the LOADng work only for >> special cases of MANET scenarios. I remember your input to the LOADng >> presenter in one f2f meeting to include heterogeniety to this >> protocol. I think LOADng should be modified to be suitable without >> confusions to fit MANETs. >> >> AB >> >> On 11/3/12, Joseph Macker wrote: >> > Again I would ask that we move ROLL and LLN discussions to ROLL if >> > people >> > want to continue. >> > JP your opinion to the WG chairs is pretty obvious. >> > >> > We need some bandwidth to discuss quality of documents and authors >> > agreement to various other WG issues. >> > I will provide some questions to that effect shortly. Let us focus on >> > our >> > WG's challenges. >> > >> > -Joe >> > >> > >> > From abdussalambaryun@gmail.com Mon Nov 5 05:33:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D764921F87AA for ; Mon, 5 Nov 2012 05:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScqLu8mfbMzB for ; Mon, 5 Nov 2012 05:33:33 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE7921F8699 for ; Mon, 5 Nov 2012 05:33:32 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so6515249vcb.31 for ; Mon, 05 Nov 2012 05:33:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3rxczGgM6q/753YsJSmtRI9h87yVNQ+XVvwuRQFLRNo=; b=mZW71lK+426lO8hCeLE3kW37ypoZAD2z31fo6Jk4VG4WaMDhOAELO83hL1zI4JxtB1 slLf9ZgIf1NJ7Uzk1k/xNu94DPlTsPw4FwpOzxk/koJlZ9bdgftSjqGhQCRyMlGgLnpj t4CxManDdVHm85QLTMV3Jrw+pPji4pNG0uVJOBq3OB6V0x1TRhj2wZ6dV3AGtp59y5IK T1VUm0nRHycp3RXLAncQhCpXFPB+K0AWTpXAeJS7+Uq47deOcm7LCp0ZMQfRLLLruoOq TouPQM2vI71jaLnJexip3uztDk4MrdHJFXRorIyJzEL2uiZSByzunaipsQPh4cYldG6n J18w== MIME-Version: 1.0 Received: by 10.58.198.135 with SMTP id jc7mr9403523vec.51.1352122412515; Mon, 05 Nov 2012 05:33:32 -0800 (PST) Received: by 10.220.204.9 with HTTP; Mon, 5 Nov 2012 05:33:32 -0800 (PST) In-Reply-To: <50856DA8.1090707@computer.org> References: <50856DA8.1090707@computer.org> Date: Mon, 5 Nov 2012 14:33:32 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] AODVv2, or DYMO, Is WG I-D X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 13:33:34 -0000 Hello Charlie, I thank you for the updates to our WG draft, I support the work and updates for WG progress, Regards Abdussalam Baryun University of Glamorgan, UK On 10/22/12, Charles E. Perkins wrote: > > Hello Abdussalam, > > There has been a lot of discussion about how to proceed with the > [manet] WG reactive protocol document. The discussion hasn't > resulted in a resolution, but the uncertainty about it did inhibit > me from responding. I hope that the draft which I will submit > this afternoon will represent a very positive step forward, to be > continued without further interruption until all the comments are > resolved and the specification completed. > > Regards, > Charlie P. > > > On 10/17/2012 2:04 AM, Abdussalam Baryun wrote: >>> Or use >>> draft-ietf-manet-dymo-23 placeholder. >>> >> I did not understand why we still not seen our I-D reactive protocol >> renewed. I don't agree to replace it with any other, please note no >> one allowed to replace including the dymo-authors only after the WG >> permission, >> >> AB >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > -- > Regards, > Charlie P. > > From robert.g.cole.civ@mail.mil Mon Nov 5 06:15:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5E721F8701 for ; Mon, 5 Nov 2012 06:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBnk8hKr3bN3 for ; Mon, 5 Nov 2012 06:15:24 -0800 (PST) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id CA97F21F85D7 for ; Mon, 5 Nov 2012 06:15:23 -0800 (PST) Received: from UCOLHP3B.easf.csd.disa.mil (131.64.100.151) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 5 Nov 2012 14:15:04 +0000 Received: from UCOLHP9K.easf.csd.disa.mil ([169.254.4.61]) by UCOLHP3B.easf.csd.disa.mil ([131.64.100.151]) with mapi id 14.02.0309.003; Mon, 5 Nov 2012 14:15:03 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: Abdussalam Baryun , Ulrich Herberg Thread-Topic: [manet] Management use cases for MANETs (UNCLASSIFIED) Thread-Index: AQHNuS7C2q7K+4zf8kCx+huIU7Wi3ZfZqjqAgAGin6A= Date: Mon, 5 Nov 2012 14:15:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A2_01CDBB36.06FD3CE0" MIME-Version: 1.0 Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , Benoit Claise , "manet@ietf.org" Subject: Re: [manet] Management use cases for MANETs (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:15:25 -0000 ------=_NextPart_000_00A2_01CDBB36.06FD3CE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE Abdussalam, Our agreement with Benoit was that each MIB document would have a short applicability statement (where specific protocol mgmt considerations could be highlighted), but that a more general MANET management use case draft would be developed to capture broader issue and futures. Thanks, Bob Robert G. Cole Comm: 443.395.8744 Email: robert.g.cole@us.army.mil -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun Sent: Sunday, November 04, 2012 8:14 AM To: Ulrich Herberg Cc: Ersue, Mehmet (NSN - DE/Munich); Benoit Claise; manet@ietf.org Subject: Re: [manet] Management use cases for MANETs Hi Ulrich, I support that each Mib draft to provide with its management use cases (within a section) for its MANETs applicability. Proactive applicabilities are not similar to Reactive applicabilities. AB On 11/2/12, Ulrich Herberg wrote: > Hi [manet] participants, > > I am forwarding an email from Benoit that was sent to coman@ietf.org, > since it concerns MANET. COMAN is a new activity (not yet a WG) > relating to management of constrained devices and networks. As I > mentioned at the last IETF, Benoit cleared his DISCUSS on the NHDP-MIB > if we commit to write a document about applicability and use cases of management of MANET routers. > > In COMAN, an individual ID was presented > (draft-ersue-constrained-mgmt) that discusses use cases of management. > Note that this is an early draft and will possibly be split in multiple drafts. > There is some discussion whether that should include mobility or not > (currently, MANET is excluded but mesh networks are not, which I think > needs some more discussion, as both are about dynamic topologies). > Anyway, similar to Benoit, it is unclear to me whether this draft or > any work in COMAN (if it was to become a WG) would satisfy the request > for a use case/applicability document, or if MANET should work on a separate draft. > > As the next OLSRv2-MIB revision will be submitted next Monday, (which > I consider ready for WGLC) this is something we need to seriously consider. > > Opinions? > > Thanks > Ulrich > > On Fri, Nov 2, 2012 at 4:45 AM, Benoit Claise wrote: > >> Hi, >> >> One point regarding MANET. >> I believe that it deserves its own document: "MANET network >> management considerations". Actually, when looking at >> draft-ietf-manet-nhdp-mib part of the IESG review, one of the outcome >> was that such a document was required. >> I cleared my DISCUSS on draft-ietf-manet-nhdp-mib with this COMMENT >> >> Note regarding the applicability statement: This is solved, as we >> discussed, but I'll keep this little sentence in one corner of my >> head "A fuller discussion of MANET network management use cases and >> challenges will be provided elsewhere." >> >> How/If this "MANET network management considerations" draft relates >> to the draft-ersue-constrained-mgmt, I'm not sure at this point in time. >> >> > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_00A2_01CDBB36.06FD3CE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIS3DCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEwTCCA6mgAwIBAgIDDNszMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcN MTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJP QkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKU7 jo5hPKcK6V92Cni9Bu445V7UQJBLIu1eX3brV/yB6uFNd+lIdV5n6RBpE1QcsIUEyS1GVDvTR/Qs kbUInPJC8ioZCX/V5Y2J8nRNidXoLX4SdeQ3Gc6jLPn+1W8KHRdATHy+SYGcrHnePyRAhTO73rN3 97CqgOaxnS4wo/Eanw9Re5UGq70cN/G7376Oxa7A2xdtY9w8gLUilFmcYXuwR7FGxcnDhsqAW3fv tgM18ZWn/hioEhmRZz514jXPnHCvSPAkofjb4Mjucnku8uNowu+PMw5Yqv9wimBEitvQGPnyac41 MNtsflnmVqWswTwhzVzIGdodKZTw2h6byTcCAwEAAaOCAWwwggFoMB8GA1UdIwQYMBaAFFSqcyrH s3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCGLmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0 Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/BAQDAgUgMCMGA1UdIAQcMBowCwYJYIZI AWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUyGOLOF3I71SMIzwNIujoox8W0CowbQYIKwYB BQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3JsLmRpc2EubWlsL2dldHNpZ24/RE9EJTIw RU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwJAYDVR0RBB0w G4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVT MA0GCSqGSIb3DQEBBQUAA4IBAQAVD+rqDKxhGbV78baC+EUC3jiDUO6C41wsmB4ckt5akJPvVrB4 mjlnoG0lm19qovC98eO0vPQMUx1F6/jP9/xg32W2Ks2HZUR3ipZWBEqVi8i20Wz4sVFgXHkJjoP5 bju0XvJk/d6wze65iZqFuILuPplugaHg7iC5B/NAMELTGx8hoK3LVqmIIyMpEFlrxTygIkyuI+NK IqcbLtBOEW0bP7TNyBh/VShmtrXAtpPP0AAi+kaUURcG1x2xdPCR3cD2bjWYkfxQYeZRl2zTuOMg Mpr9pG3MuImao/C+v6IaXGuAU8xS8hSEbHGNLrXjJ9UIxw0K45WxjR7CrPFIJ4R5MIIFDDCCA/Sg AwIBAgIDDNswMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcNMTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UE CxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJPQkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOsVn1k8Ax7kkzWXvrNf7oI7iy5zEeLACdGKrODL9riDBNUF HvD4JtafUcwq03s4Daq0tscNL8J1ONDeML5s0X8UeNfCyexrkSpPwY9g/zVO6mJmG4OunTz/7fc2 G0ZR64VYlEBZeQ88JIMIs6bYXiO9SxuOCS47aGx/CGqdpFwt713bBAQvzAjLUSWBvjZN2bviTQrY wAg1/1AnlxY6Zl4YPBSV9c1TbtTQNjbRyFRabiqNMh0XaQ0ZHxQgsGOqNwfyMlmadL2m3ILhKpFh oMfOV01at2eDj8+wFvDXLXAL1f3HAQKv5W5GEoBYNDqp/ULDBJcXVPT8mYWzxMkca/MCAwEAAaOC AbcwggGzMB8GA1UdIwQYMBaAFFSqcyrHs3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCG Lmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/ BAQDAgbAMCMGA1UdIAQcMBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUBeVx RkqbKuf17SKV2ZZOsCXLQ+gwbQYIKwYBBQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3Js LmRpc2EubWlsL2dldHNpZ24/RE9EJTIwRU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDov L29jc3AuZGlzYS5taWwwRAYDVR0RBD0wO4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbKAeBgor BgEEAYI3FAIDoBAMDjEzNjY1NjAzOTBAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMw KQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUA A4IBAQBhwXMphuaV+lhIZbI35yGpZ7zy/uXNyr41+/dibahnAIisIIHFSTeEk9GFepxqV45hagTo //0UycQ/ShOIHzV/+u3l/97k+l8imMdbjhgklb2UFROSz7TJzhO3w4S7g7DpU+GTxE2Uax+iD2t0 Bmio3ut9fr/dWvi6OTYVFMTW7M6pd8gOPqmg8ADGdljGsSotMAhXzFJgAPtnsca5HfyYpGi0NQj0 ucT/sWUGwnnjlqtYyP+SY2pOPpbN9gACkv8UKJMkik5GEFobaHbI8KWr4FFOXAIAauW1DvGFq5Pe WdDgj39r6PkdOLg3v+B9/hnkP6uOyH5Oi9pcHb+d/hPuMIIFjzCCBHegAwIBAgIBRTANBgkqhkiG 9w0BAQUFADBbMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQL EwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNRG9EIFJvb3QgQ0EgMjAeFw0wOTAxMjYyMDI2 MTVaFw0xNTAxMjUyMDI2MTVaMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1l bnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClLlh6od7mmlv2AvHV1Nw1I5p7bihkdBpw PJYdzMKfdAQ8DDmSIQgNEk6g1zeo0snGJ50o+lXXshcEGc4yvPB5nvVoqy7MzzcEsvgKZZpJIBQl wbwSaqBCbRsItIehQiKrE5naAgE5H14IV2tg3hN+aGp+QfWJgDh6/Zey0uKWSzaAYrbsJbvQD6ej zVGo99J5VZA0JqPkXM27aCZ0CTeh5q/N5D6ZR/9/wke8ZYS6MimjDvDColt66rJKfQvGw26svRB/ T6l2Oj0CASwqMLT3yKDSmDp8CNBaiQ+1ioL6DTAeftbRx7ZDJ7EoqQzjswd432JkmkWMTs2vDq6c WDbfAgMBAAGjggJaMIICVjAOBgNVHQ8BAf8EBAMCAYYwHwYDVR0jBBgwFoAUSXS7DF66ev4CVO97 oMaVxgmAcJYwHQYDVR0OBBYEFFSqcyrHs3fqzSJAeUh7EfunmSKCMAwGA1UdJAQFMAOAAQAwEgYD VR0TAQH/BAgwBgEB/wIBADCBnwYDVR0gBIGXMIGUMAsGCWCGSAFlAgELBTALBglghkgBZQIBCwkw CwYJYIZIAWUCAQsKMAsGCWCGSAFlAgELEjALBglghkgBZQIBCxMwCwYJYIZIAWUCAQsUMAwGCmCG SAFlAwIBAwYwDAYKYIZIAWUDAgEDBzAMBgpghkgBZQMCAQMIMAwGCmCGSAFlAwIBAw0wDAYKYIZI AWUDAgEDETA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLmRpc2EubWlsL2dldGNybD9Eb0Ql MjBSb290JTIwQ0ElMjAyMIH+BggrBgEFBQcBAQSB8TCB7jA/BggrBgEFBQcwAoYzaHR0cDovL2Ny bC5kaXNhLm1pbC9nZXRJc3N1ZWRUbz9Eb0QlMjBSb290JTIwQ0ElMjAyMCAGCCsGAQUFBzABhhRo dHRwOi8vb2NzcC5kaXNhLm1pbDCBiAYIKwYBBQUHMAKGfGxkYXA6Ly9jcmwuZ2RzLmRpc2EubWls L2NuJTNkRG9EJTIwUm9vdCUyMENBJTIwMiUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5T LiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwDQYJKoZIhvcNAQEF BQADggEBAHIW3DlzY02T6Tccz7LtnNhN9wwySomes8q68wSscWYxpiq9un1U2C8JY0qICOhsE6Hs XntWFzAtyNLt141HRGnPEW/L2OdSdbVRyKodafAZHzDwB8c2vc4M3jt2/QrOy7YTutaFi/FcEpHK r+h/EqisLYvWdlCU7Db6ow/fxjLqx3NG/IQami/E6CccSMJGNvYX7O1nMg+4ouC30l6QBhOUIWFD bH3zO2tl7ePbqP/Fm7KS5+tf7u+/8zmMs/UX0obVw2xKOmw/nq/oWx02W6YmFUYLRmvH1ICq564c uCtO+iFyn1+fga+07lvJlymJfOnceOJO4HSf0oZ4ZqLHmKgxggL+MIIC+gIBATBkMF0xCzAJBgNV BAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMD UEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQCAwzbMDAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjExMDUxNDE0NThaMCMGCSqGSIb3 DQEJBDEWBBQ94KUkXxtugAi2sZ+5y0jm2xHIAzAkBgkqhkiG9w0BCQ8xFzAVMAoGCCqGSIb3DQMH MAcGBSsOAwIaMHMGCSsGAQQBgjcQBDFmMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJ TCBDQS0yNAIDDNszMHUGCyqGSIb3DQEJEAILMWagZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP VS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9E IEVNQUlMIENBLTI0AgMM2zMwDQYJKoZIhvcNAQEBBQAEggEAEVJQVbwgMpeZ1H3sI+qlmrioobdQ zIKoaXGRTe7you1TS0KwlFgdlMRPT0iSeRxVtqcArME51J2y9+HVtiE0HccuZJ4hXlqOBfv6vvGC 1EO5VtypR1zjP8gn3ABDKDrdShpAKyobzadvE9fPPIo/SXppF1Xs6ZxIQBVJFCmNTtCchrfmxOzh B1DpJuV7iGxT6P6VXKipr2Ptf1JntyhDpDKZVjRBxjuN/pqJZXAVpR3fNVtytktNHM9GUOQsDRE7 DSGEq00n26QRuhCnUlKEl9yLCkuVoq4BQtOZzHAfviIfR/PD68ByXSgwkZ5XIOG4OQtOiGhuu1zb 9XlQ7khWMAAAAAAAAA== ------=_NextPart_000_00A2_01CDBB36.06FD3CE0-- From robert.g.cole.civ@mail.mil Mon Nov 5 06:19:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48D921F84D7 for ; Mon, 5 Nov 2012 06:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mK9fo2KSvQLW for ; Mon, 5 Nov 2012 06:19:30 -0800 (PST) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7111D21F849A for ; Mon, 5 Nov 2012 06:19:30 -0800 (PST) Received: from UCOLHP3G.easf.csd.disa.mil (131.64.100.146) by UCOLHP4Z.easf.csd.disa.mil (131.64.100.6) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 5 Nov 2012 14:19:23 +0000 Received: from UCOLHP9K.easf.csd.disa.mil ([169.254.4.61]) by UCOLHP3G.easf.csd.disa.mil ([131.64.100.146]) with mapi id 14.02.0309.003; Mon, 5 Nov 2012 14:19:23 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: "adrian@olddog.co.uk" , 'Abdussalam Baryun' , 'Ulrich Herberg' Thread-Topic: [manet] Management use cases for MANETs (UNCLASSIFIED) Thread-Index: AQHNuS7C2q7K+4zf8kCx+huIU7Wi3ZfZqjqAgAAA/YCAAAR7gIAAGrcAgAGDi+A= Date: Mon, 5 Nov 2012 14:19:22 +0000 Message-ID: References: <003101cdba9e$659253a0$30b6fae0$@olddog.co.uk> In-Reply-To: <003101cdba9e$659253a0$30b6fae0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A7_01CDBB36.A33092B0" MIME-Version: 1.0 Cc: "'Ersue, Mehmet \(NSN - DE/Munich\)'" , 'Benoit Claise' , "manet@ietf.org" Subject: Re: [manet] Management use cases for MANETs (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:19:34 -0000 ------=_NextPart_000_00A7_01CDBB36.A33092B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE Adrian, I agree, we did get a good deal. Also, there are folks in the WG who have expressed interest in working on the draft and helping in review. Thx, Bob Robert G. Cole Comm: 443.395.8744 Email: robert.g.cole@us.army.mil -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Sunday, November 04, 2012 10:09 AM To: 'Abdussalam Baryun'; 'Ulrich Herberg' Cc: 'Ersue, Mehmet (NSN - DE/Munich)'; 'Benoit Claise'; manet@ietf.org Subject: Re: [manet] Management use cases for MANETs Abdussalam, Your thought is noted. However, several ADs have expressed a strong desire to see the WG discuss how MANETs are managed. This request was made during the review and discussion of the NHDP MIB module when two things emerged: - The authors of the MIB modules were adding function to the module on the assumption that the features were needed, but without a guiding framework - There was no common understanding of how MANETs are managed The OPS ADs basically allowed the NHDP MIB module to be approved conditional on the WG taking on a work item to resolve these issues. The alternative was that the MB module would be blocked pending this work, so I think we got a good deal, but we are now expected to follow through. Adrian > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Abdussalam Baryun > Sent: 04 November 2012 13:34 > To: Ulrich Herberg > Cc: Ersue, Mehmet (NSN - DE/Munich); Benoit Claise; manet@ietf.org > Subject: Re: [manet] Management use cases for MANETs > > Hi Ulrich, > > I think making one draft submitted for management of use case for > MANETs is not suitable now until we finish the charter requirements of > a standard Proactive and a standard Reactive. After that phase with > both RFCs including RFC2501 we will be able to identify many related > issues. I recommend the start but the WGLC of this draft should be > only after finishing the both RFCs requirements. > > AB > > On 11/4/12, Ulrich Herberg wrote: > > Abdussalam, > > > > Benoit's request was for a dedicated MANET use case draft *in > > addition* to a shorter applicability section in each MIB document. > > > > Best regards > > Ulrich > > > > On Sun, Nov 4, 2012 at 5:14 AM, Abdussalam Baryun < > > abdussalambaryun@gmail.com> wrote: > > > >> Hi Ulrich, > >> > >> I support that each Mib draft to provide with its management use > >> cases (within a section) for its MANETs applicability. Proactive > >> applicabilities are not similar to Reactive applicabilities. > >> > >> AB > >> > >> On 11/2/12, Ulrich Herberg wrote: > >> > Hi [manet] participants, > >> > > >> > I am forwarding an email from Benoit that was sent to > >> > coman@ietf.org, > >> since > >> > it concerns MANET. COMAN is a new activity (not yet a WG) > >> > relating to management of constrained devices and networks. As I > >> > mentioned at the > >> last > >> > IETF, Benoit cleared his DISCUSS on the NHDP-MIB if we commit to > >> > write a document about applicability and use cases of management > >> > of MANET > >> routers. > >> > > >> > In COMAN, an individual ID was presented > >> > (draft-ersue-constrained-mgmt) that discusses use cases of management. > >> Note > >> > that this is an early draft and will possibly be split in > >> > multiple > >> drafts. > >> > There is some discussion whether that should include mobility or > >> > not (currently, MANET is excluded but mesh networks are not, > >> > which I think needs some more discussion, as both are about dynamic topologies). > >> Anyway, > >> > similar to Benoit, it is unclear to me whether this draft or any > >> > work in COMAN (if it was to become a WG) would satisfy the > >> > request for a use case/applicability document, or if MANET should > >> > work on a separate draft. > >> > > >> > As the next OLSRv2-MIB revision will be submitted next Monday, > >> > (which I consider ready for WGLC) this is something we need to > >> > seriously consider. > >> > > >> > Opinions? > >> > > >> > Thanks > >> > Ulrich > >> > > >> > On Fri, Nov 2, 2012 at 4:45 AM, Benoit Claise > >> > wrote: > >> > > >> >> Hi, > >> >> > >> >> One point regarding MANET. > >> >> I believe that it deserves its own document: "MANET network > management > >> >> considerations". Actually, when looking at > >> >> draft-ietf-manet-nhdp-mib > >> part > >> >> of the IESG review, one of the outcome was that such a document > >> >> was required. > >> >> I cleared my DISCUSS on draft-ietf-manet-nhdp-mib with this > >> >> COMMENT > >> >> > >> >> Note regarding the applicability statement: This is solved, as > >> >> we discussed, but I'll keep this little sentence in one corner > >> >> of my head "A fuller discussion of MANET network management > use > >> >> cases and challenges will be provided elsewhere." > >> >> > >> >> How/If this "MANET network management considerations" draft > >> >> relates to the draft-ersue-constrained-mgmt, I'm not sure at > >> >> this point in time. > >> >> > >> >> > >> > > >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_00A7_01CDBB36.A33092B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIS3DCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEwTCCA6mgAwIBAgIDDNszMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcN MTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJP QkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKU7 jo5hPKcK6V92Cni9Bu445V7UQJBLIu1eX3brV/yB6uFNd+lIdV5n6RBpE1QcsIUEyS1GVDvTR/Qs kbUInPJC8ioZCX/V5Y2J8nRNidXoLX4SdeQ3Gc6jLPn+1W8KHRdATHy+SYGcrHnePyRAhTO73rN3 97CqgOaxnS4wo/Eanw9Re5UGq70cN/G7376Oxa7A2xdtY9w8gLUilFmcYXuwR7FGxcnDhsqAW3fv tgM18ZWn/hioEhmRZz514jXPnHCvSPAkofjb4Mjucnku8uNowu+PMw5Yqv9wimBEitvQGPnyac41 MNtsflnmVqWswTwhzVzIGdodKZTw2h6byTcCAwEAAaOCAWwwggFoMB8GA1UdIwQYMBaAFFSqcyrH s3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCGLmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0 Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/BAQDAgUgMCMGA1UdIAQcMBowCwYJYIZI AWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUyGOLOF3I71SMIzwNIujoox8W0CowbQYIKwYB BQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3JsLmRpc2EubWlsL2dldHNpZ24/RE9EJTIw RU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwJAYDVR0RBB0w G4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVT MA0GCSqGSIb3DQEBBQUAA4IBAQAVD+rqDKxhGbV78baC+EUC3jiDUO6C41wsmB4ckt5akJPvVrB4 mjlnoG0lm19qovC98eO0vPQMUx1F6/jP9/xg32W2Ks2HZUR3ipZWBEqVi8i20Wz4sVFgXHkJjoP5 bju0XvJk/d6wze65iZqFuILuPplugaHg7iC5B/NAMELTGx8hoK3LVqmIIyMpEFlrxTygIkyuI+NK IqcbLtBOEW0bP7TNyBh/VShmtrXAtpPP0AAi+kaUURcG1x2xdPCR3cD2bjWYkfxQYeZRl2zTuOMg Mpr9pG3MuImao/C+v6IaXGuAU8xS8hSEbHGNLrXjJ9UIxw0K45WxjR7CrPFIJ4R5MIIFDDCCA/Sg AwIBAgIDDNswMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcNMTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UE CxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJPQkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOsVn1k8Ax7kkzWXvrNf7oI7iy5zEeLACdGKrODL9riDBNUF HvD4JtafUcwq03s4Daq0tscNL8J1ONDeML5s0X8UeNfCyexrkSpPwY9g/zVO6mJmG4OunTz/7fc2 G0ZR64VYlEBZeQ88JIMIs6bYXiO9SxuOCS47aGx/CGqdpFwt713bBAQvzAjLUSWBvjZN2bviTQrY wAg1/1AnlxY6Zl4YPBSV9c1TbtTQNjbRyFRabiqNMh0XaQ0ZHxQgsGOqNwfyMlmadL2m3ILhKpFh oMfOV01at2eDj8+wFvDXLXAL1f3HAQKv5W5GEoBYNDqp/ULDBJcXVPT8mYWzxMkca/MCAwEAAaOC AbcwggGzMB8GA1UdIwQYMBaAFFSqcyrHs3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCG Lmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/ BAQDAgbAMCMGA1UdIAQcMBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUBeVx RkqbKuf17SKV2ZZOsCXLQ+gwbQYIKwYBBQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3Js LmRpc2EubWlsL2dldHNpZ24/RE9EJTIwRU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDov L29jc3AuZGlzYS5taWwwRAYDVR0RBD0wO4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbKAeBgor BgEEAYI3FAIDoBAMDjEzNjY1NjAzOTBAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMw KQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUA A4IBAQBhwXMphuaV+lhIZbI35yGpZ7zy/uXNyr41+/dibahnAIisIIHFSTeEk9GFepxqV45hagTo //0UycQ/ShOIHzV/+u3l/97k+l8imMdbjhgklb2UFROSz7TJzhO3w4S7g7DpU+GTxE2Uax+iD2t0 Bmio3ut9fr/dWvi6OTYVFMTW7M6pd8gOPqmg8ADGdljGsSotMAhXzFJgAPtnsca5HfyYpGi0NQj0 ucT/sWUGwnnjlqtYyP+SY2pOPpbN9gACkv8UKJMkik5GEFobaHbI8KWr4FFOXAIAauW1DvGFq5Pe WdDgj39r6PkdOLg3v+B9/hnkP6uOyH5Oi9pcHb+d/hPuMIIFjzCCBHegAwIBAgIBRTANBgkqhkiG 9w0BAQUFADBbMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQL EwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNRG9EIFJvb3QgQ0EgMjAeFw0wOTAxMjYyMDI2 MTVaFw0xNTAxMjUyMDI2MTVaMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1l bnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClLlh6od7mmlv2AvHV1Nw1I5p7bihkdBpw PJYdzMKfdAQ8DDmSIQgNEk6g1zeo0snGJ50o+lXXshcEGc4yvPB5nvVoqy7MzzcEsvgKZZpJIBQl wbwSaqBCbRsItIehQiKrE5naAgE5H14IV2tg3hN+aGp+QfWJgDh6/Zey0uKWSzaAYrbsJbvQD6ej zVGo99J5VZA0JqPkXM27aCZ0CTeh5q/N5D6ZR/9/wke8ZYS6MimjDvDColt66rJKfQvGw26svRB/ T6l2Oj0CASwqMLT3yKDSmDp8CNBaiQ+1ioL6DTAeftbRx7ZDJ7EoqQzjswd432JkmkWMTs2vDq6c WDbfAgMBAAGjggJaMIICVjAOBgNVHQ8BAf8EBAMCAYYwHwYDVR0jBBgwFoAUSXS7DF66ev4CVO97 oMaVxgmAcJYwHQYDVR0OBBYEFFSqcyrHs3fqzSJAeUh7EfunmSKCMAwGA1UdJAQFMAOAAQAwEgYD VR0TAQH/BAgwBgEB/wIBADCBnwYDVR0gBIGXMIGUMAsGCWCGSAFlAgELBTALBglghkgBZQIBCwkw CwYJYIZIAWUCAQsKMAsGCWCGSAFlAgELEjALBglghkgBZQIBCxMwCwYJYIZIAWUCAQsUMAwGCmCG SAFlAwIBAwYwDAYKYIZIAWUDAgEDBzAMBgpghkgBZQMCAQMIMAwGCmCGSAFlAwIBAw0wDAYKYIZI AWUDAgEDETA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLmRpc2EubWlsL2dldGNybD9Eb0Ql MjBSb290JTIwQ0ElMjAyMIH+BggrBgEFBQcBAQSB8TCB7jA/BggrBgEFBQcwAoYzaHR0cDovL2Ny bC5kaXNhLm1pbC9nZXRJc3N1ZWRUbz9Eb0QlMjBSb290JTIwQ0ElMjAyMCAGCCsGAQUFBzABhhRo dHRwOi8vb2NzcC5kaXNhLm1pbDCBiAYIKwYBBQUHMAKGfGxkYXA6Ly9jcmwuZ2RzLmRpc2EubWls L2NuJTNkRG9EJTIwUm9vdCUyMENBJTIwMiUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5T LiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwDQYJKoZIhvcNAQEF BQADggEBAHIW3DlzY02T6Tccz7LtnNhN9wwySomes8q68wSscWYxpiq9un1U2C8JY0qICOhsE6Hs XntWFzAtyNLt141HRGnPEW/L2OdSdbVRyKodafAZHzDwB8c2vc4M3jt2/QrOy7YTutaFi/FcEpHK r+h/EqisLYvWdlCU7Db6ow/fxjLqx3NG/IQami/E6CccSMJGNvYX7O1nMg+4ouC30l6QBhOUIWFD bH3zO2tl7ePbqP/Fm7KS5+tf7u+/8zmMs/UX0obVw2xKOmw/nq/oWx02W6YmFUYLRmvH1ICq564c uCtO+iFyn1+fga+07lvJlymJfOnceOJO4HSf0oZ4ZqLHmKgxggL+MIIC+gIBATBkMF0xCzAJBgNV BAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMD UEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQCAwzbMDAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjExMDUxNDE5MjBaMCMGCSqGSIb3 DQEJBDEWBBTXgEP2Wp862c4vDynycPPkjbC65TAkBgkqhkiG9w0BCQ8xFzAVMAoGCCqGSIb3DQMH MAcGBSsOAwIaMHMGCSsGAQQBgjcQBDFmMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJ TCBDQS0yNAIDDNszMHUGCyqGSIb3DQEJEAILMWagZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP VS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9E IEVNQUlMIENBLTI0AgMM2zMwDQYJKoZIhvcNAQEBBQAEggEA6oAn79x+JhXp2fOukI87XyuDssei BEZWZLZ+ZpbsgIgBuo3s350PIGmRkGVPf5D0lUfb9zREzGuH3kHP8koiSRNPAtAbJ2MZTDNeLTEG jxtgo7qnEcKr5YY4v6E51NHwlyljB6CI/TYYTw+zqHa1pqdC0VmzPLdWW0dW1mnK4jsvxsZRqW1E Mzh8HtbA3+eYuKM15UhFBOsWTijlSjAOMYjsYmy6D3nDktmWnkQtnPmQqYxkhQmmQlfspgzgcGAT gw1yySR2d2u71nXSfF5w15JQFj2C2dszm1GRiyxxLMnA4sDvm5S1nFntolbGH0JT5r9itsQzaaXq g2ZrF5B6CgAAAAAAAA== ------=_NextPart_000_00A7_01CDBB36.A33092B0-- From alexandru.petrescu@gmail.com Mon Nov 5 06:49:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E6621F86E4 for ; Mon, 5 Nov 2012 06:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.447 X-Spam-Level: X-Spam-Status: No, score=-9.447 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_00=-2.599, DEAR_SOMETHING=1.605, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsUp0hxppSLB for ; Mon, 5 Nov 2012 06:49:52 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB4921F86A5 for ; Mon, 5 Nov 2012 06:49:51 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA5Eno5f000868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 5 Nov 2012 15:49:50 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA5EnmeL022034 for ; Mon, 5 Nov 2012 15:49:48 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-57.intra.cea.fr [132.166.201.57]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA5EnP7e014015 for ; Mon, 5 Nov 2012 15:49:46 +0100 Message-ID: <5097D1F4.7080109@gmail.com> Date: Mon, 05 Nov 2012 15:49:24 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: manet@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [manet] VANET and traceroute X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:49:52 -0000 Le 05/11/2012 08:46, Anupam Jamatia a écrit : > | On Mon, Nov 5, 2012 at 12:49 PM, Henning Rogge > > wrote: | Hi > AJ, | maybe you can deliver a little bit more context about your > question? \-- > > Dear Sir , Actually I am trying to find the possible ways which will > count the last node/vehicle in the line of vehicle/node using WAVE > technology. Hello, I think WAVE considers the link layer IEEE 802.11p and is specific to North America (as compared to CALM elsewhere). In the MANET WG there is probably few protocols that consider specifically vehicular communications, like you mention - VANET. But in the MANET WG there is strong consideration for IP protocols (as opposed to WAVE which is probably more a link layer thing). If one considers a row of vehicles that may be using IP, and with an IP subnet between each pair of two successive vehicles, then one may use the 'traceroute' unix tool to find out the last vehicle (precisely as one would use traceroute to count the number of hops to another end node in the Internet). Henning asked about context of your question - please provide more. Something like - is this simulation with ns or protocol implementation? Is it for a deployment of WAVE? What is WAVE in your perspective? Is there a list of primitive WAVE operations that you wonder how to combine? Alex > Thanks & Regards AJ > > > > _______________________________________________ manet mailing list > manet@ietf.org https://www.ietf.org/mailman/listinfo/manet > From thomas@thomasclausen.org Mon Nov 5 06:57:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EE221F8797 for ; Mon, 5 Nov 2012 06:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXfy5JAMQtqw for ; Mon, 5 Nov 2012 06:57:41 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0A61A21F8786 for ; Mon, 5 Nov 2012 06:57:41 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 92E7E557FA5 for ; Mon, 5 Nov 2012 06:57:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8B3801C0842; Mon, 5 Nov 2012 06:57:38 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [130.129.67.119] (dhcp-4377.meeting.ietf.org [130.129.67.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 30BFC1C052C; Mon, 5 Nov 2012 06:57:38 -0800 (PST) References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772205284E@xmb-rcd-x02.cisco.com> <1352080838.3583.YahooMailNeo@web160606.mail.bf1.yahoo.com> <97B69B30E0EF244B940B65EA541E3F2D215776F6@DBXPRD0510MB395.eurprd05.prod.outlook.com> In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D215776F6@DBXPRD0510MB395.eurprd05.prod.outlook.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-B190429C-6AA0-4E24-A899-B20DC5BBE483 Message-Id: <27B14D82-F865-4234-9F0F-28196507A1A6@thomasclausen.org> X-Mailer: iPad Mail (10A523) From: Thomas Heide Clausen Date: Mon, 5 Nov 2012 09:57:39 -0500 To: C Chauvenet Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:57:42 -0000 --Apple-Mail-B190429C-6AA0-4E24-A899-B20DC5BBE483 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5 nov. 2012, at 04:50, C Chauvenet wrote: > Jon Black,=20 >=20 > Overall, I don't understand your enthusiasm for LOADng. > Do you have some experiments with this protocol ? >=20 > BTW, I notice that your time-window activity slipped from a few hours. > Did you finally moved toward Atlanta to defend your opinion ? >=20 > Last but not least, it seems that one of the main LOADng authors did not s= tate his opinion in this debate ? Not sure if you're targeting me in this last sentence, Cedric (I am just one= among many LOADng authors), but I believe that I have nothing to add to wha= t has already been said so far in this "debate". Thomas > C=C3=A9dric. >=20 > Le 5 nov. 2012 =C3=A0 03:00, Jon Black a =C3=A9crit : >=20 >> This not not what JP is requiring. He is not saying that the document sh= ould not mention LLNs, but instead it would explicitly "it should not be use= in LLNs". This is something quite different and technically and intellectu= ally dishonest, but again JP has hijacked the conversation. >>=20 >> Jon =20 >>=20 >>=20 >> From: Daniel He >> To: JP Vasseur (jvasseur) =20 >> Cc: Timothy J. Salo ; "manet@ietf.org" = =20 >> Sent: Sunday, November 4, 2012 7:58 AM >> Subject: Re: [manet] LOADng works >>=20 >> I think it is fair enought to replace the name. and I knew you don't like= LLN >> at all. and I agree to LLN taken out of the context is reasonable and gen= erized. >>=20 >> Cheers, >> Dan >>=20 >> On 4 November 2012 14:16, JP Vasseur (jvasseur) wrot= e: >>=20 >> On Nov 4, 2012, at 8:35 AM, Daniel He wrote: >>=20 >>>=20 >>> I still don't beleive that LOADng deployments fit MANETs' >>> applicabilities. Therefore, disagree with the subject claimed (i.e. >>> LOADng works). >>>=20 >>> I totally disagree! LOADng is fitting to MANET. fundamentally=20 >>> it is lightweighted AODV. >>=20 >> Here is my take on this; *if* there is a choice for option 1, 2 or may be= a brand new document related to >> reactive routing in MANET (protocol called AODVv20, and excluding LLNs, t= hen I think that we do not=20 >> have any issue. >>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >>=20 >> --=20 >> Dan He >> --------------------- >> Tel: +44-788-686-3428 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-B190429C-6AA0-4E24-A899-B20DC5BBE483 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 5 nov. 2012, at 04:5= 0, C Chauvenet <c.chauvenet@wa= tteco.com> wrote:

Jon Black, 

Overall, I don't understand your enthusiasm for LOADng.
Do you have some experiments with this protocol ?

BTW, I notice that your time-window activity slipped from a few hours.<= /div>
Did you finally moved toward Atlanta to defend your opinion ?

Last but not least, it seems that one of the main LOADng authors did no= t state his opinion in this debate ?

= Not sure if you're targeting me in this last sentence, Cedric (I am just one= among many LOADng authors), but I believe that I have nothing to add t= o what has already been said so far in this "debate".

Thomas

C=C3=A9dric.

Le 5 nov. 2012 =C3=A0 03:00, Jon Black a =C3=A9crit :

This not not what JP is requiring.  He is not saying that the document s= hould not mention LLNs, but instead it would explicitly "it should not be us= e in LLNs".  This is something quite different and technically and inte= llectually dishonest, but again JP has hijacked the conversation.

Jon 


From: Daniel He <drdanhe@gmail.com>
To: JP Vasseur (jvasseur) &= lt;jvasseur@cisco.com>
Cc: Timothy J. Salo <salo@saloits.com>; "manet@ietf.org" <m= anet@ietf.org>
Sent: Sunday, November 4, 2= 012 7:58 AM
Subject: Re: [manet] LOADng= works


_______________________________________________
manet mailing list
manet@ie= tf.org
ht= tps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org= /mailman/listinfo/manet

____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-B190429C-6AA0-4E24-A899-B20DC5BBE483-- From c.chauvenet@watteco.com Mon Nov 5 07:16:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC1921F881E for ; Mon, 5 Nov 2012 07:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.671 X-Spam-Level: X-Spam-Status: No, score=-3.671 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qii9lAu0qmyl for ; Mon, 5 Nov 2012 07:16:17 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 1571121F8555 for ; Mon, 5 Nov 2012 07:16:09 -0800 (PST) Received: from mail219-ch1-R.bigfish.com (10.43.68.226) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Mon, 5 Nov 2012 15:16:08 +0000 Received: from mail219-ch1 (localhost [127.0.0.1]) by mail219-ch1-R.bigfish.com (Postfix) with ESMTP id A14951601F2; Mon, 5 Nov 2012 15:16:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz98dI9371Ic89bhc85dh1418Izz1de0h1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received: from mail219-ch1 (localhost.localdomain [127.0.0.1]) by mail219-ch1 (MessageSwitch) id 1352128565481790_32239; Mon, 5 Nov 2012 15:16:05 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.228]) by mail219-ch1.bigfish.com (Postfix) with ESMTP id 69DE91A0238; Mon, 5 Nov 2012 15:16:05 +0000 (UTC) Received: from DBXPRD0510HT001.eurprd05.prod.outlook.com (157.56.252.165) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 5 Nov 2012 15:16:04 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT001.eurprd05.prod.outlook.com ([10.255.67.164]) with mapi id 14.16.0233.002; Mon, 5 Nov 2012 15:15:55 +0000 From: C Chauvenet To: Thomas Heide Clausen Thread-Topic: [manet] LOADng works Thread-Index: AQHNuEYjLqnfvWsGTUKn5f9jVwDGQ5fVTi6AgACcCgCAAEpAgIAAgxWAgAARjwCAAAO+gIAAY4+AgAAC8gCAAJezgIAAcB4AgAFsFQCAAAqgAIAAC4gAgAALpYCAALkZAIAAg2CAgABVuICAAAUdgA== Date: Mon, 5 Nov 2012 15:15:54 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D215782EA@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.ciscoCAK=bVC9YdSXPzqKHg7+2gXxxCA6eajdiqxQLV_BqLW8C0rUW-w@mail.gmail.com> <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772205284E@xmb-rcd-x02.cisco.com> <1352080838.3583.YahooMailNeo@web160606.mail.bf1.yahoo.com> <97B69B30E0EF244B940B65EA541E3F2D215776F6@DBXPRD0510MB395.eurprd05.prod.outlook.com> <27B14D82-F865-4234-9F0F-28196507A1A6@thomasclausen.org> In-Reply-To: <27B14D82-F865-4234-9F0F-28196507A1A6@thomasclausen.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.42.4] Content-Type: multipart/alternative; boundary="_000_97B69B30E0EF244B940B65EA541E3F2D215782EADBXPRD0510MB395_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:16:19 -0000 --_000_97B69B30E0EF244B940B65EA541E3F2D215782EADBXPRD0510MB395_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Le 5 nov. 2012 =E0 15:57, Thomas Heide Clausen a =E9crit : On 5 nov. 2012, at 04:50, C Chauvenet > wrote: Jon Black, Overall, I don't understand your enthusiasm for LOADng. Do you have some experiments with this protocol ? BTW, I notice that your time-window activity slipped from a few hours. Did you finally moved toward Atlanta to defend your opinion ? Last but not least, it seems that one of the main LOADng authors did not st= ate his opinion in this debate ? Not sure if you're targeting me in this last sentence, Cedric (I am just on= e among many LOADng authors), but I believe that I have nothing to add to w= hat has already been said so far in this "debate". Noted! C=E9dric. Thomas C=E9dric. Le 5 nov. 2012 =E0 03:00, Jon Black a =E9crit : This not not what JP is requiring. He is not saying that the document shou= ld not mention LLNs, but instead it would explicitly "it should not be use = in LLNs". This is something quite different and technically and intellectu= ally dishonest, but again JP has hijacked the conversation. Jon ________________________________ From: Daniel He > To: JP Vasseur (jvasseur) > Cc: Timothy J. Salo >; "manet@iet= f.org" > Sent: Sunday, November 4, 2012 7:58 AM Subject: Re: [manet] LOADng works I think it is fair enought to replace the name. and I knew you don't like L= LN at all. and I agree to LLN taken out of the context is reasonable and gener= ized. Cheers, Dan On 4 November 2012 14:16, JP Vasseur (jvasseur) > wrote: On Nov 4, 2012, at 8:35 AM, Daniel He wrote: I still don't beleive that LOADng deployments fit MANETs' applicabilities. Therefore, disagree with the subject claimed (i.e. LOADng works). I totally disagree! LOADng is fitting to MANET. fundamentally it is lightweighted AODV. Here is my take on this; *if* there is a choice for option 1, 2 or may be a= brand new document related to reactive routing in MANET (protocol called AODVv20, and excluding LLNs, the= n I think that we do not have any issue. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet -- Dan He --------------------- Tel: +44-788-686-3428 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_97B69B30E0EF244B940B65EA541E3F2D215782EADBXPRD0510MB395_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <285662C10DFC5946B06F5D1A14161CB6@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Le 5 nov. 2012 =E0 15:57, Thomas Heide Clausen a =E9crit :


On 5 nov. 2012, at 04:50, C Chauvenet <c.chauvenet@watteco.com> wrote:

Jon Black, 

Overall, I don't understand your enthusiasm for LOADng.
Do you have some experiments with this protocol ?

BTW, I notice that your time-window activity slipped from a few hours.=
Did you finally moved toward Atlanta to defend your opinion ?

Last but not least, it seems that one of the main LOADng authors did n= ot state his opinion in this debate ?

Not sure if you're targeting me in this last sentence, Cedric (I am just on= e among many LOADng authors), but I believe that I have nothing to add= to what has already been said so far in this "debate".=

Noted!

C=E9dric.

Thomas

C=E9dric.

Le 5 nov. 2012 =E0 03:00, Jon Black a =E9crit :

This not not what JP is requiring.  He is not saying that the document= should not mention LLNs, but instead it would explicitly "it should n= ot be use in LLNs".  This is something quite different and techni= cally and intellectually dishonest, but again JP has hijacked the conversation.

Jon 


From: Daniel He <drdanhe@gmail.com>
To: JP Vasseur (jvasseur) = <jvasseur@cisco.com>
Cc: Timothy J. Salo <salo@saloits.com>; "manet@ietf.org" <manet@ietf.org>
Sent: Sunday, November 4, = 2012 7:58 AM
Subject: Re: [manet] LOADn= g works

I think it is fair enought to replace the name. a= nd I knew you don't like LLN
at all. and I agree to LLN taken out of the context is reasonable and gener= ized.

Cheers,
Dan

On 4 November 2012 14:16, JP Vasseu= r (jvasseur) <jvasseur@cisco.co= m> wrote:

On Nov 4, 2012, at 8:35 AM, Daniel He wrote:


I still don't beleive that LOADng deployments fit MANETs'
applicabilities. Therefore, disagree with the subject claimed (i.e.
LOADng works).

I totally disagree!  LOADng is fitting to MANET. fundamentally it is lightweighted AODV.

Here is my take on this; *if* there is a choice for option 1, 2 or may= be a brand new document related to
reactive routing in MANET (protocol called AODVv20, and excluding LLNs= , then I think that we do not 
have any issue.


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet




--
Dan He
---------------------
Tel: +44-788-686-3428


_______________________________________________
manet mailing list
manet@i= etf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.i= etf.org/mailman/listinfo/manet

--_000_97B69B30E0EF244B940B65EA541E3F2D215782EADBXPRD0510MB395_-- From internet-drafts@ietf.org Mon Nov 5 07:29:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D6121F8738; Mon, 5 Nov 2012 07:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwkeeqUtUniA; Mon, 5 Nov 2012 07:29:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F116821F8776; Mon, 5 Nov 2012 07:29:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121105152936.26667.35571.idtracker@ietfa.amsl.com> Date: Mon, 05 Nov 2012 07:29:36 -0800 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-mib-05.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:29:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Definition of Managed Objects for the Optimized Link St= ate Routing Protocol version 2 Author(s) : Ulrich Herberg Robert G. Cole Thomas Heide Clausen Filename : draft-ietf-manet-olsrv2-mib-05.txt Pages : 75 Date : 2012-11-05 Abstract: This document defines the Management Information Base (MIB) module for configuring and managing the Optimized Link State Routing protocol version 2 (OLSRv2). The OLSRv2-MIB module is structured into state information, performance metrics, and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues of the routing protocol. Different levels of compliance allow implementers to use smaller subsets of all defined objects, allowing for this MIB module to be deployed on more constrained routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-mib-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sratliff@cisco.com Mon Nov 5 08:11:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA9921F87C9 for ; Mon, 5 Nov 2012 08:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QJtmMOMzYXZ for ; Mon, 5 Nov 2012 08:11:04 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3158221F894D for ; Mon, 5 Nov 2012 08:11:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5031; q=dns/txt; s=iport; t=1352131863; x=1353341463; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sI4/AiDfuoso5up1rDyuQuMeGOoeJnhteaYCMXr36e4=; b=nKdzjV7jQ/Q8sgebCzJlkv21peFf6exABZchYyoUPCDcyYGad188SqxG 4xiFNPcGpSg8yhcITVhNpLL6+lRQWMOElR/E6K/GHpBIVRbG1Hugi06vt PAxec3RYlusLqp6Vgpf3Iv2QOqtM871zOj1P2lv/nCE190VnR4PJKXGA0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIjkl1CtJXG8/2dsb2JhbABEDsMqgQiCHgEBAQIBAQEBAQ8BWwsFCwIBCA4KCiQnCyUCBA4FCBqHYgYLmn6fcYwBG4VAYQOXF409gWuCMj2CGQ X-IronPort-AV: E=Sophos;i="4.80,715,1344211200"; d="scan'208";a="138911306" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 05 Nov 2012 16:11:02 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA5GB2p1013991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 16:11:02 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 10:11:01 -0600 From: "Stan Ratliff (sratliff)" To: Philip Levis Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNt4/7m2UGqbYkx0mlf2X+4G5a1JfUECmAgAA+HwCAAAPVgIABLOgAgAZWugA= Date: Mon, 5 Nov 2012 16:11:01 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F425C0A@xmb-aln-x03.cisco.com> References: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220465DF@xmb-rcd-x02.cisco.com> <3D320804-EE40-42FB-BF08-3F662B3F9542@axelcdv.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.249.96] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--50.741200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <7AB12F8DCDDCD04EA9F99554ED3982B9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:11:05 -0000 Phil,=20 Where were you during the OSPF MANET discussions???? ;-) ;-) That is *exact= ly* what we argued at the time.=20 Regards, Stan On Nov 1, 2012, at 12:23 PM, Philip Levis wrote: > Simulations of wireless networks using unit disc, time invariant models h= ave zero relevance to reality. Any results from such simulations MUST NOT b= e used as evidence of the performance of protocols. :) >=20 > Phil >=20 > On Oct 31, 2012, at 3:26 PM, Axel Colin de Verdi=E8re wrote: >=20 >> Hi JP, >>=20 >> As usual, there isn't just one situation, be it in MANETs in general or = in LLNs in particular. The simulations shown did make some assumptions on t= he traffic, and some other assumptions might show different results, but th= at's true of any protocol. Which is why I would also be interested in your = results concerning LOADng in LLNs. >>=20 >> Best, >>=20 >> Axel >>=20 >> Le 31 oct. 2012 =E0 15:12, JP Vasseur (jvasseur) a = =E9crit : >>=20 >>> Hi Bo, >>>=20 >>> We need to be very careful there =85 these documents provide results th= at CANNOT be generalized to say the least. >>> Hypothesis made on traffic flows are such that you get the results that= you would like to see =85 >>>=20 >>> Thanks >>>=20 >>> JP. >>>=20 >>> On Oct 31, 2012, at 7:29 PM, Bo Berry wrote: >>>=20 >>>>=20 >>>> For background and perspective, ran across these two docs on the origi= n=20 >>>> and performance of Loadng. The WG may find helpful. >>>>=20 >>>> -Bo >>>>=20 >>>>=20 >>>> The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Gener= ation (LOADng)=09 >>>> By T. Clausen. A. Colin de Verdiere.=20 >>>> Published in INRIA Research Report 7692 on 2011-07-25. >>>> http://hipercom.thomasclausen.net/resteam/data/publications/414efa79c4= c772e5af46f426e77ca581.pdf >>>>=20 >>>>=20 >>>> A Comparative Performance Study of the Routing Protocols LOAD and RPL = with Bi-Directional Traffic in Low-power and Lossy Networks (LLN)=09 >>>> By T. Clausen, U. Herberg.=20 >>>> Published in INRIA Research Report 7637 on 2011-06-01. >>>> http://hipercom.thomasclausen.net/resteam/data/publications/49eaae3228= cf686a462108aef8332ceb.pdf >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Oct 31, 2012, at 1:48 PM, Jon Black wrote: >>>>=20 >>>>> Certainly smart meters are one of the types of networks that are MANE= Ts. Just because houses do not move it does not mean that the connectivity= between those meters isn't changing. A smart meter network is most certai= nly a MANET. [One could argue that it is not an LLN since at least from th= e electrical power there is no lack of power.] >>>>>=20 >>>>> Totally agree that one size does not fit all. >>>>>=20 >>>>> Jon >>>>>=20 >>>>> On October 31, 2012 John.Dowdell wrote: >>>>>=20 >>>>> While I am very pleased for you and your co-authors that the LOADng w= ork has been so fruitful, I am not really sure that smart meters are really= the kind of MANET devices that the working group was intended to address. = I have been party to the conversations for only a year or two, so I am very= happy to be corrected by those with longer histories, but MANET to me mean= s dynamically moving nodes, with links being established and broken often a= nd without prior warning. Examples may be communications networks built out= of nodes contained in cars, trucks and aircraft of all sizes. I appreciate= a comment on the list a while back that the RF environment for smart meter= ing is actually more difficult than one would think, but I would suggest to= the chairs that unless LOADng has applications in this dynamically mobile = environment (and I have to admit I have not read the spec in enough detail = to determine if this is the case), then we come to the conclusion that the = DYMO/AODVv2 path sh >>>> ould be followed unless we collectively feel that such a direction is = not worth pursuing (and note I am definitely not proposing that view). >>>>>=20 >>>>> In the two years or so that I have been working with MANETs, the only= conclusion I have come to is that very many use cases exist, and that one = size does not fit all. >>>>>=20 >>>>> Regards >>>>>=20 >>>>> John >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jblack.ietf@yahoo.com Mon Nov 5 08:41:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFC821F87E9 for ; Mon, 5 Nov 2012 08:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnziizxlZZcx for ; Mon, 5 Nov 2012 08:41:09 -0800 (PST) Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (nm24-vm0.bullet.mail.bf1.yahoo.com [98.139.213.161]) by ietfa.amsl.com (Postfix) with ESMTP id B8EF721F87E8 for ; Mon, 5 Nov 2012 08:41:08 -0800 (PST) Received: from [98.139.212.151] by nm24.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2012 16:41:08 -0000 Received: from [98.139.212.213] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2012 16:41:08 -0000 Received: from [127.0.0.1] by omp1022.mail.bf1.yahoo.com with NNFMP; 05 Nov 2012 16:41:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 227777.14623.bm@omp1022.mail.bf1.yahoo.com Received: (qmail 22652 invoked by uid 60001); 5 Nov 2012 16:41:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352133668; bh=tslwTlOXe6+CEJJPLlMI8K78RA4xax9ZJyJSiIucyOI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=zdCH19A4b9FUWbJQd4n3fKF9HnVVXlRKHHqvW35WLjj3bxlFz8Z3G2FDdRP/BvoBA60XIYDTsjVn8iu2QJqLcdt4AhIg4soorSyE1XO9gYa99LZeB8WL12Z49/ZgI4AkQflpCE5dUJquanv6LARApFmvOxnw6klQwBIEPTWJXkw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AxbEdRZr/m62WM9XBLD2cbh3EgKC1hDCZHh7wl18T2mtI6lzgeVrBvD5RyalG560Uxzy+Ot5Hrkpqz/O/t4Qb0tpjZgTdvUVob9z3hJotPPikTs8yHPxtrsYY6t2tuRwLuvt9H03ytmEd3y4PisN6Q6aEw+J5H0V728sdJa+XwM=; X-YMail-OSG: HZJKod0VM1m3XrhDQks_VHYZMB_ftcQcSJdtg.5ziQvjU1g qNwNPsHLzU4KZtsB36c_MiI7g_K5NnHMikUdin1tNThf6pMch_vqB4.vVZ05 O5Uhwg9wQjAYy4y3zx9L7RJ85DyL00umiI9Edp03Sc1F9N1l0pV6rIONWdgo SXInD7Qn1PfMhNFs5SO0gwAGWU2SS2Rd9h0tY8xLF5K7mNKsVqEMr3Mri8AH 1b7Cs.sZG9kyL_YxL.yIPKM5DOLA88y1c0n6BZTFQ5ERcxrbpj6kbHmTyEB6 U6MMmAyoj29.P9mZKGpgeOYn0d.GpMTFDh2l_tjlv2HWCb6X91D8GhpIEIzx 30TgVaRlWJ1dx_LlT0_wolf36AUCABOHlBpjZREs6az91eYk1XcyDogLSXcd k4BdmL3rrraSxefvZhqsRkE9W6SscfIIT1hetlnI0wHpkmGuRmtw1MiE8a45 .O_ln6Q-- Received: from [67.213.218.74] by web160603.mail.bf1.yahoo.com via HTTP; Mon, 05 Nov 2012 08:41:08 PST X-Rocket-MIMEInfo: 001.001, SSBoYXZlIG5vdCB5ZXQgYXR0ZW1wdGVkIHRvIGltcGxlbWVudCBMT0FEbmcuwqAgTXkgImVudGh1c2lhc20iIGFzIHlvdSBjYWxsIGl0IGRldmVsb3BlZCBmcm9tIHJlYWRpbmcgdGhlIHR3byBkcmFmdHMgYW5kIGZpbmRpbmcgdGhlIExPQURuZyB0byBiZSBjbG9zZXIgdG8gc29tZXRoaW5nIHRoYXQgSSBjb3VsZCByZWFkIGFuZCBpbXBsZW1lbnQuwqAgSXQgaXMgbW9zdGx5IGJhc2VkIG9uIG15IHJlYWRpbmcsIGJ1dCBhbHNvIGZyb20gd2hhdCBJJ3ZlIGhlYXJkIGFib3V0IG90aGVyIGltcGxlbWVudGF0aW8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772205284E@xmb-rcd-x02.cisco.com> <1352080838.3583.YahooMailNeo@web160606.mail.bf1.yahoo.com> <97B69B30E0EF244B940B65EA541E3F2D215776F6@DBXPRD0510MB395.eurprd05.prod.outlook.com> Message-ID: <1352133668.20345.YahooMailNeo@web160603.mail.bf1.yahoo.com> Date: Mon, 5 Nov 2012 08:41:08 -0800 (PST) From: Jon Black To: C Chauvenet In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D215776F6@DBXPRD0510MB395.eurprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1886287700-876111049-1352133668=:20345" Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:41:11 -0000 --1886287700-876111049-1352133668=:20345 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I have not yet attempted to implement LOADng.=A0 My "enthusiasm" as you cal= l it developed from reading the two drafts and finding the LOADng to be clo= ser to something that I could read and implement.=A0 It is mostly based on = my reading, but also from what I've heard about other implementations being= available, tested and deployed.=0A=0AI find the DYMO document still confus= ing and not something that I could read and write code from.=0A=0AWhere doe= s your enthusiasm for DYMO come from?=A0 I haven't heard from anyone that h= as implemented it yet.=0A=0AJon=0A=0A=0A=0A=0A_____________________________= ___=0A From: C Chauvenet =0ATo: Jon Black =0ACc: Daniel He ; JP Vasseur (jvasseur)= ; Timothy J. Salo ; "manet@ietf.org"= =0ASent: Monday, November 5, 2012 2:50 AM=0ASubject: Re: = [manet] LOADng works=0A =0A=0AJon Black,=A0 =0A=0AOverall, I don't understa= nd your enthusiasm for LOADng.=0ADo you have some experiments with this pro= tocol ?=0A=0ABTW, I notice that your time-window activity slipped from a fe= w hours.=0ADid you finally moved toward Atlanta to defend your opinion ?=0A= =0ALast but not least, it seems that one of the main LOADng authors did not= state his opinion in this debate ?=0A=0AC=E9dric.=0A=0A=0ALe 5 nov. 2012 = =E0 03:00, Jon Black a =E9crit :=0A=0AThis not not what JP is requiring.=A0= He is not saying that the document should not mention LLNs, but instead it= would explicitly "it should not be use in LLNs".=A0 This is something quit= e different and technically and intellectually dishonest, but again JP has = hijacked the conversation.=0A>=0A>Jon=A0 =0A>=0A>=0A>=0A>=0A>=0A>=0A>______= __________________________=0A> From: Daniel He =0A>To: J= P Vasseur (jvasseur) =0A>Cc: Timothy J. Salo ; "manet@ietf.org" =0A>Sent: Sunday, November 4, = 2012 7:58 AM=0A>Subject: Re: [manet] LOADng works=0A>=0A>=0A>I think it is = fair enought to replace the name. and I knew you don't like LLN=0A>at all. = and I agree to LLN taken out of the context is reasonable and generized.=0A= >=0A>Cheers,=0A>Dan=0A>=0A>=0A>On 4 November 2012 14:16, JP Vasseur (jvasse= ur) wrote:=0A>=0A>=0A>>=0A>>On Nov 4, 2012, at 8:35 AM= , Daniel He wrote:=0A>>=0A>>=0A>>>=0A>>>I still don't beleive that LOADng d= eployments fit MANETs'=0A>>>>applicabilities. Therefore, disagree with the = subject claimed (i.e.=0A>>>>LOADng works).=0A>>>>=0A>>>>=0A>>>I totally dis= agree!=A0 LOADng is fitting to MANET. fundamentally =0A>>>it is lightweight= ed AODV.=0A>>>=0A>>=0A>>=0A>>Here is my take on this; *if* there is a choic= e for option 1, 2 or may be a brand new document related to=0A>>reactive ro= uting in MANET (protocol called AODVv20, and excluding LLNs, then I think t= hat we do not=A0=0A>>have any issue.=0A>>=0A>>=0A>>=0A>>>=0A_______________= ________________________________=0A>>>manet mailing list=0A>>>manet@ietf.or= g=0A>>>https://www.ietf.org/mailman/listinfo/manet=0A>>>=0A>>=0A>=0A>=0A>--= =0A>Dan He=0A>---------------------=0A>Tel: +44-788-686-3428=0A>=0A>=0A>__= _____________________________________________=0A>manet mailing list=0A>mane= t@ietf.org=0A>https://www.ietf.org/mailman/listinfo/manet=0A>=0A>=0A>=0A___= ____________________________________________=0A>manet mailing list=0A>manet= @ietf.org=0A>https://www.ietf.org/mailman/listinfo/manet=0A> --1886287700-876111049-1352133668=:20345 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I have not yet attemp= ted to implement LOADng.  My "enthusiasm" as you call it developed fro= m reading the two drafts and finding the LOADng to be closer to something t= hat I could read and implement.  It is mostly based on my reading, but= also from what I've heard about other implementations being available, tes= ted and deployed.

I find the DYMO document still confusing and not s= omething that I could read and write code from.

Where does your enth= usiasm for DYMO come from?  I haven't heard from anyone that has imple= mented it yet.

Jon


<= div style=3D"font-family: times new roman, new york, times, serif; font-siz= e: 12pt;">
<= hr size=3D"1"> From: C Chauv= enet <c.chauvenet@watteco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: Daniel He <drdanhe@gmail.com>= ;; JP Vasseur (jvasseur) <jvasseur@cisco.com>; Timothy J. Salo <sa= lo@saloits.com>; "manet@ietf.org" <manet@ietf.org>
Sent: Monday, November 5, 2012 2:50 = AM
Subject: Re: [manet= ] LOADng works

=0A
=0A=0A =0A=0A
=0AJo= n Black, =0A

=0A
=0A
Overall, I don't understand your= enthusiasm for LOADng.
=0A
Do you have some experiments with this= protocol ?
=0A

=0A
=0A
BTW, I notice that your time-= window activity slipped from a few hours.
=0A
Did you finally move= d toward Atlanta to defend your opinion ?
=0A

=0A
=0ALast but not least, it seems that one of the main LOADng authors did not s= tate his opinion in this debate ?
=0A

=0A
=0A
C=E9dri= c.
=0A

=0A
=0A
Le 5 nov. 2012 =E0 03:00, Jon Black a = =E9crit :
=0A
=0A<= blockquote type=3D"cite">=0A
=0A
=0A
=0AJon 
=0A

=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0AFrom: Daniel He <drdanhe@gmail.com<= /a>>
=0ATo: JP Vasseu= r (jvasseur) <jvasseur@cisco.com= >=0A
=0ACc: Timothy J= . Salo <salo@saloits.com>; "manet@ietf.org" <manet@ietf.org>=0A
=0ASe= nt: Sunday, November 4, 2012 7:58 AM
=0ASubject: Re: [manet] LOADng works
=0A<= /div>=0A
=0A =0A
I think it is fair enought to = replace the name. and I knew you don't like LLN
=0Aat all. and I agree t= o LLN taken out of the context is reasonable and generized.
=0A
=0ACh= eers,
=0ADan
=0A
=0A
On 4 N= ovember 2012 14:16, JP Vasseur (jvasseur)=0A<jvasseur@cisco.com> wrote:
=0A<= blockquote class=3D"yiv1913964188gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex;">=0A

=0A
=0A
=0A
=0A
On N= ov 4, 2012, at 8:35 AM, Daniel He wrote:
=0A
=0A

=0A
=0A
=0AI still don't beleive that LOADng deployment= s fit MANETs'
=0Aapplicabilities. Therefore, disagree with the subject c= laimed (i.e.
=0ALOADng works).
=0A
=0A
=0A
I total= ly disagree!  LOADng is fitting to MANET. fundamentally
=0Ait is l= ightweighted AODV.
=0A
=0A
=0A
=0A

=0A=0A
=0A
=0A
Here is my take on this; *if* there is a choice= for option 1, 2 or may be a brand new document related to
=0A
rea= ctive routing in MANET (protocol called AODVv20, and excluding LLNs, then I= think that we do not 
=0A
have any issue.
=0A

=0A
=0A
=0A

=0A
=0A
=0A____________________= ___________________________
=0Amanet mailing list
=0Amanet@ietf.org
=0Ahttps://www.ietf.org/m= ailman/listinfo/manet
=0A
=0A
=0A
=0A
=0A=0A=0A
=0A
=0A
=0A
=0A--
= =0ADan He
=0A---------------------
=0ATel: +44-788-686-3428
=0A=0A
=0A =0A
=0A_______________________________________________
= =0Amanet mailing list
=0Amanet@ietf.org<= br>=0Ahttps://www.ietf.org/mailman/listinfo/manet
= =0A
=0A
=0A
=0A
=0A
=0A
=0A______________________= _________________________
=0Amanet mailing list
=0Amanet@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/ma= net
=0A=0A
=0A
=0A
=0A
=0A=0A


=
--1886287700-876111049-1352133668=:20345-- From anupamjamatia@gmail.com Mon Nov 5 08:48:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE2F21F8487 for ; Mon, 5 Nov 2012 08:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uwwkWzoZJRQ for ; Mon, 5 Nov 2012 08:48:10 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDDF21F8451 for ; Mon, 5 Nov 2012 08:48:09 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so4600709lam.31 for ; Mon, 05 Nov 2012 08:48:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Te9kgoNjgarpSgxuHvvUMyI5sd0rjgY2F+k0xykbojI=; b=gud5EzDyCH0+wPUwwKqmqIA1/AY2MF0P5JyfSqXzWaC9UKFjxyLac8c0pEC5fmiJik JDO2GenV8+KPrT2zQi3oPdEaYR891TB10ZYO8hh68kydU7w7w1utF4AxRYOHi7/+U0DJ 8e8s3seozwPmylvOVuVdz8/CGL3FYYGJcskLVouLScgvFBDNZ28+tzw2InDlNavypUka SCvT6yl0TL+oKAcjEqa0iKOWHlp4QiO7S3yB51SNDaKAd9bi3i0s0O3s8EPX+4dOm/g1 TuD+FKxVLYBIizeyEq6lXEkODfw8TAhJSAoaCoBDyqyrGwkmuemZ7l4Gr1sF8gy9m+xQ mCMA== Received: by 10.112.14.107 with SMTP id o11mr4189283lbc.98.1352134088395; Mon, 05 Nov 2012 08:48:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.70.169 with HTTP; Mon, 5 Nov 2012 08:47:48 -0800 (PST) From: Anupam Jamatia Date: Mon, 5 Nov 2012 22:17:48 +0530 Message-ID: To: alexandru.petrescu@gmail.com, manet@ietf.org Content-Type: multipart/alternative; boundary=f46d0401689b070d7804cdc24042 Subject: [manet] VANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:48:10 -0000 --f46d0401689b070d7804cdc24042 Content-Type: text/plain; charset=UTF-8 | Henning asked about context of your question - please provide more. | Something like - is this simulation with ns or protocol implementation? | Is it for a deployment of WAVE? What is WAVE in your perspective? Is | there a list of primitive WAVE operations that you wonder how to combine? \-- Hi , Actually I am trying to figure out the possible ways to count vehicles or to know the actual position when the vehicles are in stopping position in VANET using WAVE technologies. One possible ways is from RSU to OBU a PDU can be sent and then OBU to OBU until the last vehicle . Every vehicle periodically advertises this information to its neighbor vehicles and a vehicle is thus informed about all other vehicles located within its direct communication range. If a vehicle intends to send data to a known target geographic location, it chooses another vehicle as a message relay, which is located in the direction towards the target position. The same procedure is executed by every vehicle on the multihop path until the destination is reached and then again from Destination to source.This can be require to implement in parking booking. ANY OTHER WAY TO COUNT ? Next generation vehicles are expected to exchange information not only beyond their immediate surroundings and line-of-sight with other vehicles, but also with the road infrastructure and Internet databases. Not yet decided the simulation with ns or other tools like NCTUns. I am very novice in this field. Regards -- AJ --f46d0401689b070d7804cdc24042 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable | Henning asked abou= t context of your question - please provide more.
| Something like - i= s this simulation with ns or protocol implementation?
| Is it for a deploy= ment of WAVE? =C2=A0What is WAVE in your perspective? =C2=A0Is
|= =C2=A0there a list o= f primitive WAVE operations that you wonder how to combine?
\--

Hi= , Actually I am trying to figure out the =C2=A0possible ways to count vehicles or to know t= he actual position when the vehicles are in stopping position =C2=A0in VANE= T =C2=A0using WAVE technologies. One possible ways is from RSU to =C2=A0OBU= a PDU can be sent and then OBU to OBU until the last vehicle .=C2=A0Every vehicle periodically advertises this information to its neighbor veh= icles and a vehicle is thus informed about=C2=A0all other vehicles located = within its direct communication range. If a vehicle intends=C2=A0to send da= ta to a known target geographic location, it chooses another vehicle as a
message relay, which is located in the direction towards the target po= sition. The same=C2=A0procedure is executed by every vehicle on the multiho= p path until the destination is=C2=A0reached and then again from Destinatio= n to source.This can be require to implement in parking booking. ANY OTHER = WAY TO COUNT ? Next generation vehicles are expected to exchange informatio= n not only beyond their=C2=A0immediate surroundings and line-of-sight with = other vehicles, but also with the road=C2=A0infrastructure and Internet dat= abases. Not yet decided the simulation with ns or other tools like NCTUns. = I am very novice in this field.

Regards
--
AJ
--f46d0401689b070d7804cdc24042-- From internet-drafts@ietf.org Mon Nov 5 08:58:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E35A21F8744; Mon, 5 Nov 2012 08:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHQn+JoD+eKQ; Mon, 5 Nov 2012 08:58:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B186D21F870B; Mon, 5 Nov 2012 08:58:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121105165801.12198.97984.idtracker@ietfa.amsl.com> Date: Mon, 05 Nov 2012 08:58:01 -0800 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-report-mib-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:58:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Definition of Managed Objects for Performance Reporting Author(s) : Robert G. Cole Joseph Macker Andy Bierman Filename : draft-ietf-manet-report-mib-03.txt Pages : 29 Date : 2012-11-05 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring autonomous report generation on any device that supports MIBs containing counter and gauge objects for performance monitoring. This allows a management station to instruct a device to build off-line reports to be collected asynchronously by the management station. Further, this REPORT-SAMPLED-MIB can be configured in a proxy configuration where the report generation is performed on a device in close network proximity to the device containing the referenced counter objects. Hence, this capability allows network operators to reduce the SNMP polling traffic burden on Mobile Ad-Hoc and Disruption Tolerant Networks which is typical of SNMP performance management applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-report-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-report-mib-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-report-mib-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Nov 5 08:58:28 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6032721F84EB; Mon, 5 Nov 2012 08:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fadeX-rRjQFJ; Mon, 5 Nov 2012 08:58:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395D321F84ED; Mon, 5 Nov 2012 08:58:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121105165822.12192.49495.idtracker@ietfa.amsl.com> Date: Mon, 05 Nov 2012 08:58:22 -0800 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-smf-mib-05.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:58:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Definition of Managed Objects for the Manet Simplified M= ulticast Framework Relay Set Process Author(s) : Robert G. Cole Joseph Macker Brian Adamson Filename : draft-ietf-manet-smf-mib-05.txt Pages : 60 Date : 2012-11-05 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc Networks (MANETs). The SMF-MIB also reports state information, performance metrics, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-smf-mib-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-smf-mib-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From c.chauvenet@watteco.com Mon Nov 5 09:01:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2530D21F87E9 for ; Mon, 5 Nov 2012 09:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.666 X-Spam-Level: X-Spam-Status: No, score=-3.666 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NULLxFF7GS-n for ; Mon, 5 Nov 2012 09:01:30 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 676EF21F866F for ; Mon, 5 Nov 2012 09:01:19 -0800 (PST) Received: from mail106-am1-R.bigfish.com (10.3.201.243) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Mon, 5 Nov 2012 17:01:17 +0000 Received: from mail106-am1 (localhost [127.0.0.1]) by mail106-am1-R.bigfish.com (Postfix) with ESMTP id D5BCE180172; Mon, 5 Nov 2012 17:01:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT002.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz98dI9371Ic89bhc85dh1418Izz1de0h1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received: from mail106-am1 (localhost.localdomain [127.0.0.1]) by mail106-am1 (MessageSwitch) id 1352134875626703_25199; Mon, 5 Nov 2012 17:01:15 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.245]) by mail106-am1.bigfish.com (Postfix) with ESMTP id 8FBCA401CB; Mon, 5 Nov 2012 17:01:15 +0000 (UTC) Received: from DBXPRD0510HT002.eurprd05.prod.outlook.com (157.56.252.165) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 5 Nov 2012 17:01:13 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT002.eurprd05.prod.outlook.com ([10.255.67.165]) with mapi id 14.16.0233.002; Mon, 5 Nov 2012 17:01:12 +0000 From: C Chauvenet To: Jon Black Thread-Topic: [manet] LOADng works Thread-Index: AQHNuEYjLqnfvWsGTUKn5f9jVwDGQ5fVTi6AgACcCgCAAEpAgIAAgxWAgAARjwCAAAO+gIAAY4+AgAAC8gCAAJezgIAAcB4AgAFsFQCAAAqgAIAAC4gAgAALpYCAALkZAIAAg2CAgAByogCAAAWeAA== Date: Mon, 5 Nov 2012 17:01:11 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D21578812@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772205284E@xmb-rcd-x02.cisco.com> <1352080838.3583.YahooMailNeo@web160606.mail.bf1.yahoo.com> <97B69B30E0EF244B940B65EA541E3F2D215776F6@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1352133668.20345.YahooMailNeo@web160603.mail.bf1.yahoo.com> In-Reply-To: <1352133668.20345.YahooMailNeo@web160603.mail.bf1.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.42.4] Content-Type: multipart/alternative; boundary="_000_97B69B30E0EF244B940B65EA541E3F2D21578812DBXPRD0510MB395_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 17:01:31 -0000 --_000_97B69B30E0EF244B940B65EA541E3F2D21578812DBXPRD0510MB395_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Le 5 nov. 2012 =E0 17:41, Jon Black a =E9crit : I have not yet attempted to implement LOADng. So your current sensor network deployment is working without LOADng ? My "enthusiasm" as you call it developed from reading the two drafts and fi= nding the LOADng to be closer to something that I could read and implement.= It is mostly based on my reading, but also from what I've heard about oth= er implementations being available, tested and deployed. I find the DYMO document still confusing and not something that I could rea= d and write code from. Where does your enthusiasm for DYMO come from? I haven't heard from anyone= that has implemented it yet. I stated my opinion earlier in reply to the chairs question, as requested. I won't copy them here again, to avoid flooding ;-) C=E9dric. Jon ________________________________ From: C Chauvenet > To: Jon Black > Cc: Daniel He >; JP Vasseur (jv= asseur) >; Timothy J. Salo >; "manet@ietf.org" > Sent: Monday, November 5, 2012 2:50 AM Subject: Re: [manet] LOADng works Jon Black, Overall, I don't understand your enthusiasm for LOADng. Do you have some experiments with this protocol ? BTW, I notice that your time-window activity slipped from a few hours. Did you finally moved toward Atlanta to defend your opinion ? Last but not least, it seems that one of the main LOADng authors did not st= ate his opinion in this debate ? C=E9dric. Le 5 nov. 2012 =E0 03:00, Jon Black a =E9crit : This not not what JP is requiring. He is not saying that the document shou= ld not mention LLNs, but instead it would explicitly "it should not be use = in LLNs". This is something quite different and technically and intellectu= ally dishonest, but again JP has hijacked the conversation. Jon ________________________________ From: Daniel He > To: JP Vasseur (jvasseur) > Cc: Timothy J. Salo >; "manet@iet= f.org" > Sent: Sunday, November 4, 2012 7:58 AM Subject: Re: [manet] LOADng works I think it is fair enought to replace the name. and I knew you don't like L= LN at all. and I agree to LLN taken out of the context is reasonable and gener= ized. Cheers, Dan On 4 November 2012 14:16, JP Vasseur (jvasseur) > wrote: On Nov 4, 2012, at 8:35 AM, Daniel He wrote: I still don't beleive that LOADng deployments fit MANETs' applicabilities. Therefore, disagree with the subject claimed (i.e. LOADng works). I totally disagree! LOADng is fitting to MANET. fundamentally it is lightweighted AODV. Here is my take on this; *if* there is a choice for option 1, 2 or may be a= brand new document related to reactive routing in MANET (protocol called AODVv20, and excluding LLNs, the= n I think that we do not have any issue. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet -- Dan He --------------------- Tel: +44-788-686-3428 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_97B69B30E0EF244B940B65EA541E3F2D21578812DBXPRD0510MB395_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Le 5 nov. 2012 =E0 17:41, Jon Black a =E9crit :

I have not yet attempted to implement LOADng. 

So your current sensor network deployment is working without LOADng ?<= /div>

My "enthusiasm" as you call it developed from reading the two dra= fts and finding the LOADng to be closer to something that I could read and = implement.  It is mostly based on my reading, but also from what I've = heard about other implementations being available, tested and deployed.

I find the DYMO document still confusing and not something that I could rea= d and write code from.

Where does your enthusiasm for DYMO come from?  I haven't heard from a= nyone that has implemented it yet.

I stated my opinion earlier in reply to the chairs question, as reques= ted.
I won't copy them here again, to avoid flooding ;-)

C=E9dric.


Jon


From: C Chauvenet <c.chauvenet@watteco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Cc: Daniel He <drdanhe@gmail.com>; JP Vasseur (jvasse= ur) <jvasseur@cisco.com>; T= imothy J. Salo <salo@saloits.com= >; "manet@ietf.org" <manet@ietf.org>
Sent: Monday, November 5, = 2012 2:50 AM
Subject: Re: [manet] LOADn= g works

Jon Black, 

Overall, I don't understand your enthusiasm for LOADng.
Do you have some experiments with this protocol ?

BTW, I notice that your time-window activity slipped from a few hours.=
Did you finally moved toward Atlanta to defend your opinion ?

Last but not least, it seems that one of the main LOADng authors did n= ot state his opinion in this debate ?

C=E9dric.

Le 5 nov. 2012 =E0 03:00, Jon Black a =E9crit :

This not not what JP is requiring.  He is not saying that the document= should not mention LLNs, but instead it would explicitly "it should n= ot be use in LLNs".  This is something quite different and techni= cally and intellectually dishonest, but again JP has hijacked the conversation.

Jon 


From: Daniel He <drdanhe@gmail.com>
To: JP Vasseur (jvasseur) &= lt;jvasseur@cisco.com>
Cc: Timothy J. Salo <salo@saloits.com>; "manet@ietf.org" <manet@ietf.org>
Sent: Sunday, November 4, 2= 012 7:58 AM
Subject: Re: [manet] LOADng= works

I think it is fair enought to replace the name. a= nd I knew you don't like LLN
at all. and I agree to LLN taken out of the context is reasonable and gener= ized.

Cheers,
Dan

On 4 November 2012 14:16, JP Vasseu= r (jvasseur) <jvasseur@cisco.co= m> wrote:

On Nov 4, 2012, at 8:35 AM, Daniel He wrote:


I still don't beleive that LOADng deployments fit MANETs'
applicabilities. Therefore, disagree with the subject claimed (i.e.
LOADng works).

I totally disagree!  LOADng is fitting to MANET. fundamentally it is lightweighted AODV.

Here is my take on this; *if* there is a choice for option 1, 2 or may= be a brand new document related to
reactive routing in MANET (protocol called AODVv20, and excluding LLNs= , then I think that we do not 
have any issue.


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet




--
Dan He
---------------------
Tel: +44-788-686-3428


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet




--_000_97B69B30E0EF244B940B65EA541E3F2D21578812DBXPRD0510MB395_-- From hrogge@googlemail.com Mon Nov 5 09:47:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F21121F842D for ; Mon, 5 Nov 2012 09:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzDJ+gd5uOI7 for ; Mon, 5 Nov 2012 09:47:47 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 224A521F89FF for ; Mon, 5 Nov 2012 09:47:47 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so2773807dan.31 for ; Mon, 05 Nov 2012 09:47:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qkC+3/ofY4ts6psQXjARrUA7opdujTCtlIsN//XVaIY=; b=fQxqxxmVAMjbsVsKMXievNu+oBUL/onKDXBatKxyYcjwwk1Fk6i6wthNmqNKfW53PI g50cCBWCISjZ9JbyU3e/8f8di5LhHMToZ5TDAJa75ig87FZHnURYrkBuM3dzSLA/ITA1 tozR0yUCM55nFlMJZXpamAk2Yq7avZMzxvqBw/ZdS/uQIX31EZ5uG6aWRPZ6z6ByY6RA BVS0l0ownVpLx+7ZolfjuHQHDMrZgTdRXJkKaZefFEOnMhXaaPNegIHqIsz2H3NPvuZO RVuOCOn/78uxcuv09yMGp3Oc7UBw8oTs0TObu2xvYKvxbfTlHK7aSfhKlPsbyIYsAyg7 JPzg== Received: by 10.68.219.163 with SMTP id pp3mr32119279pbc.13.1352137667020; Mon, 05 Nov 2012 09:47:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Mon, 5 Nov 2012 09:47:26 -0800 (PST) In-Reply-To: <5088E2B5.60102@fkie.fraunhofer.de> References: <3416819E-1188-4AE9-9454-84421FF65A9F@nasa.gov> <508641F2.9050100@fkie.fraunhofer.de> <5088E2B5.60102@fkie.fraunhofer.de> From: Henning Rogge Date: Mon, 5 Nov 2012 18:47:26 +0100 Message-ID: To: MANET IETF Content-Type: text/plain; charset=ISO-8859-1 Cc: Bo Berry Subject: Re: [manet] DLEP and modem Link Property Advertisements X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 17:47:47 -0000 On Thu, Oct 25, 2012 at 8:56 AM, Henning Rogge wrote: > Hi, > > I have uploaded my draft document to our eu-project webpage. I cannot upload > it to the IETF tracker at the moment because of the coming IETF. Now that the submission block period is over, I have also uploaded the draft properly to the IETF as a personal draft: https://datatracker.ietf.org/doc/draft-rogge-stateless-rfc5444-dlep/ Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From charliep@computer.org Mon Nov 5 10:05:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E86321F84BA for ; Mon, 5 Nov 2012 10:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIGuRjwEkkiQ for ; Mon, 5 Nov 2012 10:04:59 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAD721F871E for ; Mon, 5 Nov 2012 10:04:59 -0800 (PST) Received: from [130.129.66.42] by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TVR2g-0006A6-TM; Mon, 05 Nov 2012 13:04:58 -0500 Message-ID: <5097FFC7.9000700@computer.org> Date: Mon, 05 Nov 2012 10:04:55 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Joseph Macker References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <97B69B30E0EF244B940B65EA541E3F2D21573150@DBXPRD0510MB395.eurprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A772204D7AE@xmb-rcd-x02.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86fb2a3b8eb8c9e1384b277e8e24b81ceb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.66.42 Cc: "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 18:05:00 -0000 Hello Joe, I have a very slight observation about this. On 11/4/2012 12:40 PM, Joseph Macker wrote: > Since LOADng, DYMO, and AODV are about the same technically, in my > opinion, are you claiming that AODV-based designs do not work for > MANETs? Thats what I am hearing technically and I have no problem > hearing that opinion but there seems to be a fallacy in the actual > argument being made. In my opinon if LOADng is not appropriate for > MANET then neither is AODV or DYMO since the design principles are > basically the same. Back to #3 in that case. LOADng, AODVv2, and AODV are all reactive protocols, and they are related. But that doesn't mean they're "about the same" except at a high level of abstraction. I think that the design principles do exhibit significant differences. -- Regards, Charlie P. From pal@cs.stanford.edu Mon Nov 5 10:17:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4713521F8937 for ; Mon, 5 Nov 2012 10:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALw0Y7aFwAkO for ; Mon, 5 Nov 2012 10:17:01 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id B764621F8935 for ; Mon, 5 Nov 2012 10:17:01 -0800 (PST) Received: from [12.199.7.82] (helo=[172.16.1.87]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TVREH-0004S4-G8; Mon, 05 Nov 2012 10:17:01 -0800 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Mon, 5 Nov 2012 06:56:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <92086B00-D5AA-4141-8AB1-2B1A912E5F9A@cs.stanford.edu> References: <03B78081B371D44390ED6E7BADBB4A7722052EFE@xmb-rcd-x02.cisco.com> To: Henning Rogge X-Mailer: Apple Mail (2.1283) X-Scan-Signature: d3e02c565cd5ac634b2ff74b6ba3e13d Cc: "manet@ietf.org List" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 18:17:02 -0000 On Nov 4, 2012, at 11:21 PM, Henning Rogge wrote: > On Mon, Nov 5, 2012 at 2:38 AM, JP Vasseur (jvasseur) > wrote: >> JP> We all agree, with a a non subtle nuance. I never said that = reactive >> routing was a bad idea. These protocol are very useful. >> They are just ill-suited to LLNs. >=20 > At least that is your personal opinion. We got this, no need to repeat = it again. >=20 > Henning Rogge Henning, At this point, I'm unsure what the difference between "proactive" and = "reactive" is. I'm going to interpret "reactive" as "uses scoped floods = to discover routes." That is, route request, route reply, etc. If I'm = mistaken, then my comment below might be off the mark. There's a lot of experimental evidence supporting the claim that using = floods or scoped floods to discover routes is ill-suited to low-power = and lossy networks (LLNs). This is due to the low-power requirement. In = low-power wireless networks, broadcast packets usually cost much more to = transmit than unicast ones. This is one of the reasons why RPL uses a = Trickle timer to regulate its beaconing interval, so that if the current = routes are operating well the broadcast rate approaches zero. Requiring = a scoped flood every time a route breaks or is needed can be very = costly. If you want, I can walk you through the issues and a bibliography of = low-power link layer and protocol designs. There's about a decade of = work. If I were to recommend 3 papers to explain the issues and = tradeoffs low power wireless introduces, then I'd suggest B-MAC = (Polastre, SenSys 2004), X-MAC (Buettner, SenSys 2006) and A-MAC (Dutta, = SenSys 2010). For protocol design, 3 papers I'd suggest Dozer (Burri, = IPSN 2007), CTP (Gnawali, 2009), and a complete low power IP layer that = greatly informed RPL's design (Hui, SenSys 2008). I realize there are a lot of opinions on these topics. But there's = thankfully also a lot of science and engineering. Let's not let the = former get in the way of the latter. Phil= From trac+manet@trac.tools.ietf.org Mon Nov 5 10:38:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EE021F89D2 for ; Mon, 5 Nov 2012 10:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qw+ZvB8i0Z5B for ; Mon, 5 Nov 2012 10:38:06 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4943621F8946 for ; Mon, 5 Nov 2012 10:38:06 -0800 (PST) Received: from localhost ([127.0.0.1]:39396 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVRYU-00030k-7G; Mon, 05 Nov 2012 19:38:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "manet issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Mon, 05 Nov 2012 18:37:50 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/5#comment:1 Message-ID: <076.f37caab1b3e18ec54869239fcc169766@trac.tools.ietf.org> References: <061.db3c48158682d65cd854a9d5c40c741f@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <061.db3c48158682d65cd854a9d5c40c741f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: Re: [manet] #5: Reorganizing the route table entry timeout management X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 18:38:07 -0000 #5: Reorganizing the route table entry timeout management Comment (by charliep@…): It is possible for incoming !RteMsg information to supply a VALIDITY_TIME for the information, which has the effect of creating additional state for the relevant route table entry. VALIDITY_TIME amounts to a respecification of (ACTIVE_INTERVAL + MAX_IDLETIME) for the routing information, in that a route MUST be expired after the route table entry was maintained for the VALIDITY_TIME. A proposal is to do this by adding a "validity_expiration" field to the route table entry. -- --------------------------------+------------------------------ Reporter: charliep@… | Owner: Charlie Perkins Type: defect | Status: new Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: Keywords: route timeouts | --------------------------------+------------------------------ Ticket URL: manet From trac+manet@trac.tools.ietf.org Mon Nov 5 12:15:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A373E21F84F3 for ; Mon, 5 Nov 2012 12:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haTf5S1rcv1Q for ; Mon, 5 Nov 2012 12:15:30 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id E6DFB21F87F1 for ; Mon, 5 Nov 2012 12:15:29 -0800 (PST) Received: from localhost ([127.0.0.1]:48971 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVT4i-00072b-Qy; Mon, 05 Nov 2012 21:15:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "manet issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Mon, 05 Nov 2012 20:15:12 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/7 Message-ID: <061.f6d9e0fa28b46c77085c2605af4906fb@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: [manet] #7: Top level document organization X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 20:15:31 -0000 #7: Top level document organization Previous revisions have collected together various sections describing base protocol features into a top-level section entitled "Detailed Operation for the Base Protocol". However, this does not seem to provide very much guidance for finding appropriate sections of the document, and some of the subsections seem better suited to be described in their own high-level sections. There is another section devoted to Optional Features, and it seems that already provides a pretty good way to separate Base features from Optional features. It is proposed to eliminate the abovementioned top-level section and promote its subsections to be top- level sections. Here is a snapshot of the Table of Contents, still subject to minor changes: {{{ Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 8 4.2. AODVv2 Message Structure and Information Elements . . . . 10 4.3. RteMsg-specific Protocol Elements . . . . . . . . . . . . 13 4.4. Route Error (RERR)-specific Protocol Elements . . . . . . 14 5. AODVv2 Sequence Numbers . . . . . . . . . . . . . . . . . . . 14 6. AODVv2 Operations on Route Table Entries . . . . . . . . . . . 15 6.1. Evaluating Incoming Routing Information . . . . . . . . . 15 6.2. Creating or Updating Route Table Entries . . . . . . . . . 17 6.3. Route Table Entry Timeouts . . . . . . . . . . . . . . . . 17 7. Routing Messages . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. RREQ Creation . . . . . . . . . . . . . . . . . . . . . . 18 7.2. RREP Creation . . . . . . . . . . . . . . . . . . . . . . 19 7.3. Handling a Received RteMsg . . . . . . . . . . . . . . . . 19 8. Route Discovery, Retries, and Buffering . . . . . . . . . . . 21 9. Route Maintenance . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Active Next-hop Router Adjacency Monitoring . . . . . . . 22 9.2. Handling Route Lifetimes During Packet Forwarding . . . . 23 9.3. RERR Generation . . . . . . . . . . . . . . . . . . . . . 23 9.4. Receiving and Handling RERR Messages . . . . . . . . . . . 24 10. Unknown Message and TLV Types . . . . . . . . . . . . . . . . 25 11. Advertising Network Addresses . . . . . . . . . . . . . . . . 25 12. Simple Internet Attachment . . . . . . . . . . . . . . . . . . 25 13. Multiple Interfaces . . . . . . . . . . . . . . . . . . . . . 27 14. AODVv2 Control Packet/Message Generation Limits . . . . . . . 27 15. Optional Features . . . . . . . . . . . . . . . . . . . . . . 27 15.1. Expanding Rings Multicast . . . . . . . . . . . . . . . . 28 15.2. Intermediate RREP . . . . . . . . . . . . . . . . . . . . 28 15.3. Precursor Notification . . . . . . . . . . . . . . . . . . 28 15.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 28 15.3.2. Precursor Notification . . . . . . . . . . . . . . . 28 15.4. Reporting Multiple Unreachable Nodes . . . . . . . . . . . 30 15.5. Message Aggregation . . . . . . . . . . . . . . . . . . . 30 15.6. Adding Additional Routing Information to a RteMsg . . . . 30 16. Administratively Configured Parameters and Timer Values . . . 32 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 17.1. AODVv2 Message Types Specification . . . . . . . . . . . . 35 17.2. Message and Address Block TLV Type Specification . . . . . 35 17.3. Address Block TLV Specification . . . . . . . . . . . . . 36 18. Security Considerations . . . . . . . . . . . . . . . . . . . 36 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 20.1. Normative References . . . . . . . . . . . . . . . . . . . 38 20.2. Informative References . . . . . . . . . . . . . . . . . . 39 Appendix A. Changes since the Previous Version . . . . . . . . . 40 Appendix B. Shifting Network Prefix Advertisement Between AODVv2 Routers . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 }}} -- --------------------------------+----------------------------- Reporter: charliep@… | Owner: Charlie Perkins Type: enhancement | Status: new Priority: minor | Milestone: Component: dymo | Version: Severity: Active WG Document | Keywords: --------------------------------+----------------------------- Ticket URL: manet From jvasseur@cisco.com Mon Nov 5 12:48:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A790521F84FF for ; Mon, 5 Nov 2012 12:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.441 X-Spam-Level: X-Spam-Status: No, score=-10.441 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ET445xEo5aUu for ; Mon, 5 Nov 2012 12:48:26 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A71B321F849D for ; Mon, 5 Nov 2012 12:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44425; q=dns/txt; s=iport; t=1352148505; x=1353358105; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=R9pDGsKekb0t8Croiy3uuwXvtuUiGQkKIQ87vHfqleE=; b=g+updwx6xOkp1ChV7659+JcUtG3+E7SwWM+RIDq2O7X0qkZatvpDKo6+ GQoCl2CjdVHh12IipjNQI+ZHkQclAcJ/idNQjOS+rnFBZBQOQOwXzkWkn 77p2M4OG+KyncpZyumMBDiLKs1Biq4uDfuuR+Rhef/qY7vrGzXm3IXnGA I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANokmFCtJXG9/2dsb2JhbABEgknAa4EIgh4BAQEEAQEBDwEHAVEBAQgDEAIBCA4DAQMBAQsWAQYHIQYLFAMGCAIEDgUIGodWAw8LmnCWMA2JUASLGWgSDoU7YQOUJo0IgyaBa4JvgVwfHg X-IronPort-AV: E=Sophos;i="4.80,716,1344211200"; d="scan'208,217";a="139068821" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 05 Nov 2012 20:48:17 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA5KmH09026185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 20:48:17 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 14:48:17 -0600 From: "JP Vasseur (jvasseur)" To: Jon Black Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuvY0LPVi/cSo/ES1hdb7zda62w== Date: Mon, 5 Nov 2012 20:48:16 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722056AB0@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A7722052EFE@xmb-rcd-x02.cisco.com> <1352081151.19662.YahooMailNeo@web160606.mail.bf1.yahoo.com> In-Reply-To: <1352081151.19662.YahooMailNeo@web160606.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.116.56] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--59.593500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722056AB0xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 20:48:30 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7722056AB0xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Nov 4, 2012, at 9:05 PM, Jon Black wrote: JP, once again you are distracting us from the topics that needs to be disc= ussed. This is not and should not be a debate on if or if not LLNs can use= a reactive protocol. JP> As long as LLNs are not involved (which is not what is documented in th= e Load specification) =85 It \IS/ a discussion about which of the two documents is in the best shape = for this working group to move forward to complete our charter item of prod= ucing a reactive routing protocol for MANETs. We know you think that RPL has the exclusive rights to routing in LLNs. We= got it. Can we please move to the necessary discussion. If you have some specific = items in the comparison between the DYMO draft and the LOADng draft, please= bring them up. You have not yet. Have you read both drafts? JP> I wish that we could meet to discuss here in Atlanta. Thanks. JP. Jon ________________________________ From: JP Vasseur (jvasseur) > To: Ulrich Herberg > Cc: ">" > Sent: Sunday, November 4, 2012 6:38 PM Subject: Re: [manet] Reactive Protocol Situation Hi, On Nov 1, 2012, at 9:39 PM, Ulrich Herberg wrote: Hi Joydeep, On Thu, Nov 1, 2012 at 5:58 PM, Joydeep Tripathi > wrote: Hi Joe and MANET WG, I was following the discussion on which route to take for a reactive protoc= ol standard very closely, and I think I should post my opinion also. I cham= pion for Option 1, and here is why : I have read both AODVv2 (DYMO) and LOAD-ng drafts, and I have simulated LOA= D-ng myself as well. This experience, I believe, puts me in a position to f= orm an opinion comparing these two protocols. That is valuable. Have you also implemented DYMO and compared it to LOADng? I certainly agree, option 3 is *not* an option I would like to be chosen. R= eactive protocols, though very much unsuitable for LLNs and Smart Grid AMI = meter networks, I differ on that, and so do some of the LOADng authors that work in that ar= ea. But that's not the point of the discussion here. may have some usefulness in certain networks for certain sparse traffic sce= nario, and the WG should have a standard for the same. I agree. Firstly, LOAD-ng is backed up by the argument that it has implementations a= nd interop documents. However, I have seen in the mailing list, that certai= n question on details of the 'practical' implementation of LOAD-ng has been= avoided. I don't see how. There was a description of the deployment and about the su= itability for LOADng in that. Note that for DYMO, there is no such deployme= nt (to my knowledge), which is why I think your conclusion for option 1 ins= tead of option 3 is surprising to me. A reactive protocol may do well in a 2000 nodes smart meter network, if the= data traffic to the base station or collector is 1-2 times a day. This kin= d of implementations, in my opinion, say nothing about usefulness of LOAD-n= g in Smart Grid networks or LLNs. It is well known (and also spelled out in DYMO), that reactive protocols ar= e more suitable for sparse traffic scenarios with few concurrent communicat= ion streams. That is well-known and understood in MANET, and a reasons to w= ork on a proactive protocol as well. Reactive protocols have their limitati= ons, but in certain MANET use cases are useful, which is why we are charter= ed to work on a reactive protocol. JP> We all agree, with a a non subtle nuance. I never said that reactive ro= uting was a bad idea. These protocol are very useful. They are just ill-suited to LLNs. If you design a protocol X in MANET and e= xplicitly mention that it would not be applicable to LLNs, then I would personally be fine. Now if you claim that a protocol such as L= oad could work in specify lightweight traffic use cases, then can you explain why existing LLN routing protocol do not work ? The id= ea is to avoid having two protocols if one is sufficient (once again for LLNs). Again, whether LLN may be considered as a subset of MANET or not is a diffe= rent question. But even then, deployed LOAD-ng in a 2000 node network may (= and in my opinion, will) fail if traffic is increased. That is possible. Both in DYMO and LOADng. Agreed, one size does not fit all. However, once we have multicast traffic = in a smart grid or multiple meters generating alert packets in a region at = the same time, a reactive protocol like LOAD-ng will lead to the break-down= of the network. Anyone can say multicast traffic or several meters reporti= ng emergency at the same time to the same station, is a very much likely si= tuation in smart grid. Were these situations considered during deployment? = Please note, I am NOT saying that AODVv2 / DYMO will be better in this case= than LOAD-ng. But why are you opting for option 1 then? That seems not logical. You argue= against reactive protocols in general. All what you say above is known to = MANET, long before ROLL and LLN even existed. JP> If I may express my opinion (not sure what Joydeep thinks about this) y= ou very well know that Load has been positioned as a lightweight reactive routing protocol for LLNs. The deployment that ha= s been mentioned on the list (without any details) is related to AMI over PLC, probably one of the most constrained LLN. There ar= e other reasons for opting for option 1. IMHO, any protocol can be shown 'working perfectly', if we provide a favora= ble atmosphere only for it to work. Yes, I agree. You say yourself, no-one-size-fits all, which is why MANET wo= rks on both reactive and proactive protocol. Looking at that perspective, I don't think, LOAD-ng working in one network = under one particular scenario should be considered a vital argument to disc= uss whether to go with AODVv2 or LOAD-ng. LOADng has one large-scale deployment, DYMO does not. LOADng has multiple r= ecent interoperable implementations, DYMO has not. LOADng is based on the s= ame mechanism of AODV that is known to work in certain MANET scenarios. JP> Along those lines, I could list a dozen of proprietary protocols deploy= ed in the field, still the IETF does not have to standardize them all. Not going to each point one by one, if the document ends up trying to be ap= plicable to LLNs, we would need to have it reviewed by a wider audience (ROLLE WG). Chair hat off, I would offer to write an ID list= ing the number of issues using reactive in LLNs. Thanks. JP. So why do you opt for 1) and not 3)? One can write a working code of AODVv2 in 2 days. The real question we shou= ld be asking, which protocol is better suited for general MANET overall, an= d if there really is a *necessity* of discarding a working group document. Secondly, LOAD-ng was devised keeping LLN scenario in mind. It was intended= for ROLL WG, and since it had not been adopted in the ROLL WG, it popped u= p in the MANET WG. The change that has been done to LOAD-ng after dragging = it to MANET WG, was really to change the message format to adhere to RFC 54= 44, That is true, the work was initiated from LLNs. However, as you say yoursel= f, it has adopted RFC5444 and other MANET requirements. Note that amongst t= he authors, there are a large part of the previous RFC editors of MANET pre= sented. We know MANETs and their requirements. Can you point out a specific= requirement that LOADng would not fulfill but DYMO would? and do a "find and replace" of the term LLN with 'MANET' along with changin= g the first 'L' of LOAD ng from 'LLN' to 'Lightweight'. Since the protocol = was designed for LLN at first, I do not think it would be able to cover the= broad spectrum that MANET includes. Why? And why does DYMO? I don't see a technical argument. Since we already have a WG document for a reactive protocol, I do not see a= ny strong reason to discard the current one in favor of an individual draft= , especially when even LOAD-ng authors agreed that this protocol will not o= ffer any notable performance difference compared to AODVv2. Yes, but the document is not aligned with the RFC5444 architecture, it is n= ot possible to secure, and it would be a lot more work to come to an RFC, i= n my opinion (lots of unclear and underspecified text, incomplete IANA sect= ion, unclear metrics, underspecified bidirectionality detection). At the same time, since I have read both drafts, I figured out that AODVv2 = is more generic to MANET than LOAD-ng. It offers the developer or the deplo= yment authority to chose form more than one options. Options may be fine, but they also affect interoperability if not carefully= designed. And they may, as for some of the options like iRREP, make it ver= y difficult or impossible to provide end-to-end security. For example, AODVv2 has the option (but it is not mandated) to use a precur= sor list or have an intermediate node to reply an RREQ. LOAD-ng does not su= pport either. That is not true. We opted to move these in companion document, as we have = not seen proof that these options would bring benefit in a general MANET ca= se. I can understand that for an LLN it may be beneficial for not maintaining a= precursor list or having only the destination reply t o a RREQ, there can = be (and are) other instances of MANETs where having the option of precursor= list will come handy. Which? Can you show results that this is beneficial in a general use case? This can save on control overhead, using some storage space in the node. LO= AD-ng, in most cases does not provide this flexibility to the developer to = chose between options for specific deployment. Again, not true. We provide TLVs, and extensions are possible in companion = documents. We have very carefully designed each RFC2119 word to make sure e= xtensions are allowed. Multiple options always carry a great risk of non-in= teroperability. Some MANET deployment may be less harsh than others in nature. Hence, AODVv= 2 having more open options than LOAD-ng, in most cases, seem beneficial to = me. "seems beneficial"? Have you proof for the use of the options? Of course, there are other technical differences between these protocols. B= ut I believe there is a separate thread created for that. I will wait for t= he draft authors to reply there first, and will reply with my points if all= those differences are not covered. There, I will re-iterate the necessity = of a protocol to be suited for MANET in general, not only 'some' kind of MA= NETs Lastly, I do not come from any industry, neither I have any company road-ma= p of deliverable here. Being a PhD candidate in a university, I tried to fa= irly judge the two options. So I read both drafts, and did not find a strong enough reason to discard a= current working group document. Whether a few companies backing up a proto= col over the other can be a decisive criteria to chose a standard protocol = or not, is in the WG and its chairs most capable hands. Also, I did not, ve= ry clearly understand how LOAD-ng, operating properly in a 2-5 routers test= -bed may be considered as proof of valid interoperability. Why not? What would it change to add 100 nodes? I have never seen any inter= op tests with more than a handful nodes. Again: interop tests are not perfo= rmance tests. By the way, I have not seen any such open interoperability tests during the= development of DYMO . I would very much appreciate feedback if I am wrong, since I am in my learn= ing phase :-) . I have my 2 cents here - a) AODVv2 offers more flexibility, As said, LOADng offers the same flexibility. Flexibility is nice, but one h= as to be very careful with interoperability. If LOADng were to be a WG docu= ment, of course the WG can discuss if certain options bring a general benef= it and don't harm interoperability, then we can include it. b) LOAD-ng does not offer enough advantage over AODVv2 to discard the later= , One major advantage is that it could be an RFC far quicker. In the current = shape, the SEC AD would certainly not accept DYMO, and it would require a l= ot more work to bring to a level that is acceptable for a standards track R= FC. c) LOAD-ng was not initially designed for MANET, I don't see the argument here (see above) and d) there are other technical differences that make AODVv2 more suitable= for MANETs over LOAD-ng (To be covered in separate thread). I am curious to see that. Best Ulrich My opinion - We should stick to current WG document (AODVv2) and improve it= and finish it as soon as possible. I hereby stand for Option 1. Thanks and Regards, Joydeep Tripathi PhD Candidate, Drexel University. On Tue, Oct 30, 2012 at 7:13 PM, Joseph Macker > wrote: Hello MANET working group (form Stan and Joe), As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common documen= t effort and given positive feedback at the time we the chairs thought this= was the best approach given the authors potential to come together and gai= n the best of both efforts. Since that period, there has been some fairly = strident and rancorous "at times" debate between the authors of the two doc= uments. During IETF 84 in Vancouver, the co-chairs held a discussion with some of t= he co-authors of the two documents. Our guidance to the co-authors was to f= ind a way to merge the two documents into one, as it was perceived that are= not technically far apart and they both derive roughly from AODV concepts = and LOADng had fairly active authorship and implementation efforts. We prov= ided a co-editing proposal to the authors and gave them the timeframe of th= e Atlanta to come up with an answer back to us regarding this. As of this = writing, those discussions of a potential commonn document and authorship m= erger have failed. Therefore, we find ourselves at a crossroads. The authors of the two docume= nts are divided, and it is unlikely that progress on a merged document can = be reached based upon recent author feedback. I have also polled the earlie= r WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the iss= ue at the present time. We see only 3 possible paths forward: 1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2. 2. Replace the existing DYMO document effort with the LOADng related docume= nt effort, defusing ealier references to LLNs as recommended in the last me= eting minutes, and to focus more motivationally on general MANET problem sp= aces (the authors seem to have agreed to this issue if its a WG document). 3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus. The co-chairs request and need your opinions on the options. We have been = some silent collecting initial feedback and waiting for author feedback at = this point. Stan and I are both on travel prior to Atlanta so our response= s may be sparse and we will also likely be in a "receive mode" for a few da= ys. So send your opinions. -Joe _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7722056AB0xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Nov 4, 2012, at 9:05 PM, Jon Black wrote:

JP, once again you are distracting us from the topics that needs to be disc= ussed.  This is not and should not be a debate on if or if not LLNs ca= n use a reactive protocol.


JP> As long as LLNs are not involved (which is not what is document= ed in the Load specification) =85 

It \IS/ a discussion about which of the two documents is in the best shape = for this working group to move forward to complete our charter item of prod= ucing a reactive routing protocol for MANETs.

We know you think that RPL has the exclusive rights to routing in LLNs.&nbs= p; We got it.

Can we please move to the necessary discussion.  If you have some spec= ific items in the comparison between the DYMO draft and the LOADng draft, p= lease bring them up.  You have not yet.  Have you read both draft= s?

JP> I wish that we could meet to discuss here in Atlanta.

Thanks.

JP.


Jon


From: JP Vasseur (jvasseur)= <jvasseur@cisco.com>
To: Ulrich Herberg <ulrich@herberg.name>
Cc: "<manet@ietf.org>" <manet@ietf.org>
Sent: Sunday, November 4, = 2012 6:38 PM
Subject: Re: [manet] React= ive Protocol Situation

Hi,

On Nov 1, 2012, at 9:39 PM, Ulrich Herberg wrote:

Hi Joydeep,

On Thu, Nov 1, 2012 at 5:58 PM, Joy= deep Tripathi <jt369@drexel.edu&= gt; wrote:
Hi Joe and MANET WG,

I was following the discussion on which route to take for a reactive p= rotocol standard very closely, and I think I should post my opinion also. I= champion for Option 1, and here is why : 

I have read both AODVv2 (DYMO) and LOAD-ng drafts, and I have simulate= d LOAD-ng myself as well. This experience, I believe, puts me in a position= to form an opinion comparing these two protocols.

That is valuable. Have you also implemented DYMO and compared it to LO= ADng?

 
I certainly agree, option 3 is *not* an option I would like to be chos= en. Reactive protocols, though very much unsuitable for LLNs and Smart Grid= AMI meter networks,

I differ on that, and so do some of the LOADng authors that work in th= at area. But that's not the point of the discussion here.

 
may have some usefulness in certain networks for certain sparse traffi= c scenario, and the WG should have a standard for the same.

I agree.
 

Firstly, LOAD-ng is backed up by the argument that it has implementati= ons and interop documents. However, I have seen in the mailing list, that c= ertain question on details of the 'practical' implementation of LOAD-ng has= been avoided.

I don't see how. There was a description of the deployment and about t= he suitability for LOADng in that. Note that for DYMO, there is no such dep= loyment (to my knowledge), which is why I think your conclusion for option = 1 instead of option 3 is surprising to me.

 
A reactive protocol may do well in a 2000 nodes smart meter network, i= f the data traffic to the base station or collector is 1-2 times a day. Thi= s kind of implementations, in my opinion, say nothing about usefulness of L= OAD-ng in Smart Grid networks or LLNs.

It is well known (and also spelled out in DYMO), that reactive protoco= ls are more suitable for sparse traffic scenarios with few concurrent commu= nication streams. That is well-known and understood in MANET, and a reasons= to work on a proactive protocol as well. Reactive protocols have their limitations, but in certain MANET u= se cases are useful, which is why we are chartered to work on a reactive pr= otocol.

JP> We all agree, with a a non subtle nuance. I never said that rea= ctive routing was a bad idea. These protocol are very useful.
They are just ill-suited to LLNs. If you design a protocol X in MANET = and explicitly mention that it would not be applicable to LLNs,
then I would personally be fine. Now if you claim that a protocol such= as Load could work in specify lightweight traffic use cases, 
then can you explain why existing LLN routing protocol do not work ? T= he idea is to avoid having two protocols if one is sufficient
(once again for LLNs). 

 
Again, whether LLN may be considered as a subset of MANET or not is a = different question. But even then, deployed LOAD-ng in a 2000 node network = may (and in my opinion, will) fail if traffic is increased.

That is possible. Both in DYMO and LOADng.
 
Agreed, one size does not fit all. However, once we have multicast tra= ffic in a smart grid or multiple meters generating alert packets in a regio= n at the same time, a reactive protocol like LOAD-ng will lead to the break= -down of the network. Anyone can say multicast traffic or several meters reporting emergency at the same ti= me to the same station, is a very much likely situation in smart grid. Were= these situations considered during deployment? Please note, I am NOT sayin= g that AODVv2 / DYMO will be better in this case than LOAD-ng.

But why are you opting for option 1 then? That seems not logical. You = argue against reactive protocols in general. All what you say above is= known to MANET, long before ROLL and LLN even existed.

JP> If I may express my opinion (not sure what Joydeep thinks about= this) you very well know that Load has been positioned
as a lightweight reactive routing protocol for LLNs. The deployment th= at has been mentioned on the list (without any details) is 
related to AMI over PLC, probably one of the most constrained LLN= . There are other reasons for opting for option 1.


 
IMHO, any protocol can be shown 'working perfectly', if we provide a f= avorable atmosphere only for it to work.

Yes, I agree. You say yourself, no-one-size-fits all, which is why MAN= ET works on both reactive and proactive protocol.
 
Looking at that perspective, I don't think, LOAD-ng working in one = network under one particular scenario should be considered a vital argument= to discuss whether to go with AODVv2 or LOAD-ng.

LOADng has one large-scale deployment, DYMO does not. LOADng has multi= ple recent interoperable implementations, DYMO has not. LOADng is based on = the same mechanism of AODV that is known to work in certain MANET scenarios= .

JP> Along those lines, I could list a dozen of proprietary protocol= s deployed in the field, still the IETF does not have to standardize
them all.

Not going to each point one by one, if the document ends up trying to = be applicable to LLNs, we would need to have it reviewed by a
wider audience (ROLLE WG). Chair hat off, I would offer to write an ID= listing the number of issues using reactive in LLNs.

Thanks.

JP.

So why do you opt for 1) and not 3)?

 
 
One can write a working code of AODVv2 in 2 days. The real question we= should be asking, which protocol is better suited for general MANET overal= l, and if there really is a *necessity* of discarding a working group docum= ent.
 

Secondly, LOAD-ng was devised keeping LLN scenario in mind. It was int= ended for ROLL WG, and since it had not been adopted in the ROLL WG, it pop= ped up in the MANET WG. The change that has been done to LOAD-ng after drag= ging it to MANET WG, was really to change the message format to adhere to RFC 5444,

That is true, the work was initiated from LLNs. However, as you say yo= urself, it has adopted RFC5444 and other MANET requirements. Note that amon= gst the authors, there are a large part of the previous RFC editors of MANE= T presented. We know MANETs and their requirements. Can you point out a specific requirement that LOADng w= ould not fulfill but DYMO would?

 
and do a "find and replace" of the term LLN with 'MANET' alo= ng with changing the first 'L' of LOAD ng from 'LLN' to 'Lightweight'. Sinc= e the protocol was designed for LLN at first, I do not think it would be ab= le to cover the broad spectrum that MANET includes.

Why? And why does DYMO? I don't see a technical argument.

 
Since we already have a WG document for a reactive protocol, I do not = see any strong reason to discard the current one in favor of an individual = draft, especially when even LOAD-ng authors agreed that this protocol will = not offer any notable performance difference compared to AODVv2. 

Yes, but the document is not aligned with the RFC5444 architecture, it= is not possible to secure, and it would be a lot more work to come to an R= FC, in my opinion (lots of unclear and underspecified text, incomplete IANA= section, unclear metrics, underspecified bidirectionality detection).

 

At the same time, since I have read both drafts, I figured out that AO= DVv2 is more generic to MANET than LOAD-ng. It offers the developer or the = deployment authority to chose form more than one options.

Options may be fine, but they also affect interoperability if not care= fully designed. And they may, as for some of the options like iRREP, make i= t very difficult or impossible to provide end-to-end security.

 
For example, AODVv2 has the option (but it is not mandated) to use a p= recursor list or have an intermediate node to reply an RREQ. LOAD-ng does n= ot support either.

That is not true. We opted to move these in companion document, as we = have not seen proof that these options would bring benefit in a general MAN= ET case. 
 

I can understand that for an LLN it may be beneficial for not maintain= ing a precursor list or having only the destination reply t o a RREQ, there= can be (and are) other instances of MANETs where having the option of prec= ursor list will come handy.

Which? Can you show results that this is beneficial in a general use c= ase?

 
This can save on control overhead, using some storage space in the nod= e. LOAD-ng, in most cases does not provide this flexibility to the develope= r to chose between options for specific deployment.

Again, not true. We provide TLVs, and extensions are possible in compa= nion documents. We have very carefully designed each RFC2119 word to make s= ure extensions are allowed. Multiple options always carry a great risk of n= on-interoperability.

 
Some MANET deployment may be less harsh than others in nature. Hence, = AODVv2 having more open options than LOAD-ng, in most cases, seem beneficia= l to me.

"seems beneficial"? Have you proof for the use of the option= s?

 
Of course, there are other technical differences between these protoco= ls. But I believe there is a separate thread created for that. I will wait = for the draft authors to reply there first, and will reply with my points i= f all those differences are not covered. There, I will re-iterate the necessity of a protocol to be suited= for MANET in general, not only 'some' kind of MANETs 

Lastly, I do not come from any industry, neither I have any company ro= ad-map of deliverable here. Being a PhD candidate in a university= , I tried to fairly judge the two options. 

So I read both drafts, and did not find a strong enough reason to disc= ard a current working group document. Whether a few companies backing up a = protocol over the other can be a decisive criteria to chose a standard prot= ocol or not, is in the WG and its chairs most capable hands. Also, I did not, very clearly understand how LO= AD-ng, operating properly in a 2-5 routers test-bed may be consid= ered as proof of valid interoperability. 

Why not? What would it change to add 100 nodes? I have never seen any = interop tests with more than a handful nodes. Again: interop tests are not = performance tests. 
By the way, I have not seen any such open interoperability tests durin= g the development of DYMO .

 
I would very much appreciate feedback if I am wrong, since I am in my = learning phase :-) . I have my 2 cents here - a) AODVv2 offers more flexibi= lity,

As said, LOADng offers the same flexibility. Flexibility is nice, but = one has to be very careful with interoperability. If LOADng were to be= a WG document, of course the WG can discuss if certain options bring a gen= eral benefit and don't harm interoperability, then we can include it.

 
b) LOAD-ng does not offer enough advantage over AODVv2 to discard the = later,

One major advantage is that it could be an RFC far quicker. In the cur= rent shape, the SEC AD would certainly not accept DYMO, and it would requir= e a lot more work to bring to a level that is acceptable for a standards tr= ack RFC. 

 
c) LOAD-ng was not initially designed for MANET,

I don't see the argument here (see above)
 
and d) there are other technical differences that make AODVv2 more sui= table for MANETs over LOAD-ng (To be covered in separate thread).  

I am curious to see that.

Best
Ulrich
 
My opinion - We should stick to current WG document (AODVv2) and impro= ve it and finish it as soon as possible. I hereby stand for Option 1. 

Thanks and Regards,

Joydeep Tripathi
PhD Candidate, 
Drexel University.


On Tue, Oct 30, 2012 at 7:13 PM, Joseph Mack= er <jpmacker@gmail.com> w= rote:
Hello MANET working group (form Stan and Joe= ),

As you are all probably aware, there has been WG activity lately on competi= ng drafts for a MANET reactive protocol - DYMO (reviving the current workin= g group document that was parked due to inactivity), and LOADng. Many month= s ago there was a somewhat authorship led movement towards a common document effort and given positive feedback = at the time we the chairs thought this was the best approach given the auth= ors potential to come together and gain the best of both efforts.  Sin= ce that period, there has been some fairly strident and rancorous "at times" debate between the authors of = the two documents.

During IETF 84 in Vancouver, the co-chairs h= eld a discussion with some of the co-authors of the two documents. Our guid= ance to the co-authors was to find a way to merge the two documents into on= e, as it was perceived that are not technically far apart and they both derive roughly from AODV concepts and = LOADng had fairly active authorship and implementation efforts. We provided= a co-editing proposal to the authors and gave them the timeframe of the At= lanta to come up with an answer back to us regarding this.  As of this writing, those discussions of = a potential commonn document and authorship merger have failed.

Therefore, we find ourselves at a crossroads= . The authors of the two documents are divided, and it is unlikely that pro= gress on a merged document can be reached based upon recent author feedback= . I have also polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the issue a= t the present time.  We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there is c= onsensus on its continued approach and also the desire to rename it to AODV= v2.
2. Replace the existing DYMO document effort= with the LOADng related document effort, defusing ealier references to LLN= s as recommended in the last meeting minutes, and to focus more motivationa= lly on general MANET problem spaces (the authors seem to have agreed to this issue if its a WG document).
3. Remove the working group charter for a re= active protocol, effectively killing both documents, at least from a workin= g group (WG) standpoint. This would not be a reflection on the technology i= n either case, just an admission that we are not working together and reaching consensus.

The co-chairs request and need your opinions= on the options.  We have been some silent collecting initial feedback= and waiting for author feedback at this point.  Stan and I are both o= n travel prior to Atlanta so our responses may be sparse and we will also likely be in a "receive mode" for a f= ew days.  So send your opinions.

-Joe

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@i= etf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



--_000_03B78081B371D44390ED6E7BADBB4A7722056AB0xmbrcdx02ciscoc_-- From william.d.ivancic@nasa.gov Mon Nov 5 13:31:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A5821F8510 for ; Mon, 5 Nov 2012 13:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLtSeNtTTyiZ for ; Mon, 5 Nov 2012 13:31:56 -0800 (PST) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1903421F87C7 for ; Mon, 5 Nov 2012 13:31:56 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 880F6A800D for ; Mon, 5 Nov 2012 15:31:55 -0600 (CST) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt04.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id qA5LVtnB019977 for ; Mon, 5 Nov 2012 15:31:55 -0600 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Mon, 5 Nov 2012 15:31:54 -0600 From: "Ivancic, William D. (GRC-RHN0)" To: "manet@ietf.org" Date: Mon, 5 Nov 2012 15:31:53 -0600 Thread-Topic: New Version Notification for draft-ivancic-manet-modemlpa-00.txt Thread-Index: Ac27nPnhLmvF08dFQdWUN9y6qJXu2Q== Message-ID: References: <20121105212854.4905.95804.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C1CAD1B53AD0420C99CBD97D45AE7C2Anasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-11-05_03:2012-11-05, 2012-11-05, 1970-01-01 signatures=0 Subject: [manet] New Version Notification for draft-ivancic-manet-modemlpa-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 21:31:57 -0000 --_000_C1CAD1B53AD0420C99CBD97D45AE7C2Anasagov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I uploaded the modemlpa draft. Unfortunately, I cannot be at the meeting t= his week. - Will A new version of I-D, draft-ivancic-manet-modemlpa-00.txt has been successfully submitted by William Ivancic and posted to the IETF repository. Filename: draft-ivancic-manet-modemlpa Revision: 00 Title: Modem Link Properties Advertisement Protocol Creation date: 2012-11-05 WG ID: Individual Submission Number of pages: 20 URL: http://www.ietf.org/internet-drafts/draft-ivancic-manet-mo= demlpa-00.txt Status: http://datatracker.ietf.org/doc/draft-ivancic-manet-modeml= pa Htmlized: http://tools.ietf.org/html/draft-ivancic-manet-modemlpa-00 Abstract: Nework devices and applications are increasingly connected to a variety of smart modems whose incoming and outgoing link rates can be varied over time to suit the channel characteristics. Such rate changes can result from use of adaptive coding and modulation. The link rate and conditions offered by the modem to connected devices therefore vary. In order for connected devices and applications to get the most out of the modem's link capacity, it is necessary for the applications and connected devices to condition traffic. Thus, they need some knowledge of the modem's link conditions. This document describes one simple method for a modem to advertise link rate and other characteristics, via UDP messages, and discusses alternative approaches to communicating this information. While the mechanism in this document is described in the context of a modem, it can also be broadly applied to other scenarios such as cryptographic devices. --_000_C1CAD1B53AD0420C99CBD97D45AE7C2Anasagov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I uploaded the modemlpa draft.  Unfortunately, I cannot be at the mee= ting this week.

- Will


A new version of I-D, dr= aft-ivancic-manet-modemlpa-00.txt
has been successfully submitted= by William Ivancic and posted to the
IETF repository.
=
Fi= lename: dr= aft-ivancic-manet-modemlpa
Revision: 00
Title: Modem Link Properties Advertisement Pr= otocol
Creation date: 2012-11-05
WG ID: Individual Submission
Number of pag= es: 20


Abstract:=
  Nework devices and applications are increasingly connecte= d to a
  variety of smart modems whose incoming and outgoing= link rates can be
  varied over time to suit the channel ch= aracteristics.  Such rate
  changes can result from use= of adaptive coding and modulation.  The
  link rate an= d conditions offered by the modem to connected devices
  the= refore vary.  In order for connected devices and applications to
=
  get the most out of the modem's link capacity, it is necessary = for
  the applications and connected devices to condition tr= affic.  Thus,
  they need some knowledge of the modem's= link conditions.  This
  document describes one simple= method for a modem to advertise link
  rate and other chara= cteristics, via UDP messages, and discusses
  alternative ap= proaches to communicating this information.  While the
 = ; mechanism in this document is described in the context of a modem, it
  can also be broadly applied to other scenarios such as crypto= graphic
  devices.


= --_000_C1CAD1B53AD0420C99CBD97D45AE7C2Anasagov_-- From jvasseur@cisco.com Mon Nov 5 17:07:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D365C21F873D for ; Mon, 5 Nov 2012 17:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnqmkVOFbsYy for ; Mon, 5 Nov 2012 17:07:08 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 38EAE21F872A for ; Mon, 5 Nov 2012 17:07:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=724; q=dns/txt; s=iport; t=1352164028; x=1353373628; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ykzw/OnW4/CzCiL6w238zGEa1Aoq2762TcxiwByd/jE=; b=iZd5D41Ulj4zB48aV6J1QA/MtQ3JjPZ7FTx952G/rJGP7HmcicVKenDn EbBskbDLhJ5vEwkXRPd4leMktRSFSv82S1Zkw2Xp6k0m7vEv6Gs1WhA1f jihCnFCBYP8mGq2D3fQSrxmvYdvoFSItrzhNT5kNxBp6Nfsa7ICwSRh3C 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAERhmFCtJV2d/2dsb2JhbABEhVC9Y4EIgh4BAQEDARIBZgULAgEIDgoKJDIlAgQOBQgah2IGmwKPZJA4i3yFdGEDiCWcL4Frgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,719,1344211200"; d="scan'208";a="139107318" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 06 Nov 2012 01:07:07 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA6177r5022211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 01:07:07 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 19:07:07 -0600 From: "JP Vasseur (jvasseur)" To: Henning Rogge Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuvY0LPVi/cSo/ES1hdb7zda62w== Date: Tue, 6 Nov 2012 01:07:06 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722057B99@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A7722052EFE@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.113.118] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--31.732700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 01:07:09 -0000 Thanks - FYI, an I-D in the works, spelling out technical details backing u= p my statement. On Nov 5, 2012, at 2:21 AM, Henning Rogge wrote: > On Mon, Nov 5, 2012 at 2:38 AM, JP Vasseur (jvasseur) > wrote: >> JP> We all agree, with a a non subtle nuance. I never said that reactive >> routing was a bad idea. These protocol are very useful. >> They are just ill-suited to LLNs. >=20 > At least that is your personal opinion. We got this, no need to repeat it= again. >=20 > Henning Rogge >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From jvasseur@cisco.com Mon Nov 5 17:15:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D92011E80B8 for ; Mon, 5 Nov 2012 17:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.477 X-Spam-Level: X-Spam-Status: No, score=-10.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFg6mMmHO9wj for ; Mon, 5 Nov 2012 17:15:51 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7429111E80AE for ; Mon, 5 Nov 2012 17:15:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16425; q=dns/txt; s=iport; t=1352164551; x=1353374151; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GmUcdxEJWaGNh8uey1tX/egi+J88ZpQE/tdCAL1KlbE=; b=XOuqkT71toDleB7Vm10aOaknjG+9h7arSWf3TqZZY473+0tArsvMSsmH zqblR4Q+twbbfL1Xm4LhyfEs0alBA2wzTLoAxdC2ZY+dMfoBwpzUWYr5L II9f3/PO6MW76BllCateprOGFphsai+6rys9pNI9GpCJqe5B3ckqbXBPH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMFAIJjmFCtJXHA/2dsb2JhbAAqGoJJrniJAQGIcIEIgh8BAQQBAQEPAVsLEAIBCCIdBycLFBECBA4FCBqHaAstmk6PZJA4i3wbCYVQYQOXF409gWuCb3KBJw X-IronPort-AV: E=Sophos;i="4.80,719,1344211200"; d="scan'208,217";a="139088177" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 06 Nov 2012 01:15:50 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA61Fo7A005053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 01:15:50 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 19:15:50 -0600 From: "JP Vasseur (jvasseur)" To: "manet@ietf.org List" Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuvY0LPVi/cSo/ES1hdb7zda62w== Date: Tue, 6 Nov 2012 01:15:49 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722057C24@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A7722052EFE@xmb-rcd-x02.cisco.com> <92086B00-D5AA-4141-8AB1-2B1A912E5F9A@cs.stanford.edu> In-Reply-To: <92086B00-D5AA-4141-8AB1-2B1A912E5F9A@cs.stanford.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.113.118] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--42.624000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722057C24xmbrcdx02ciscoc_" MIME-Version: 1.0 Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 01:15:52 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7722057C24xmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Nov 5, 2012, at 9:56 AM, Philip Levis wrote: On Nov 4, 2012, at 11:21 PM, Henning Rogge wrote: On Mon, Nov 5, 2012 at 2:38 AM, JP Vasseur (jvasseur) > wrote: JP> We all agree, with a a non subtle nuance. I never said that reactive routing was a bad idea. These protocol are very useful. They are just ill-suited to LLNs. At least that is your personal opinion. We got this, no need to repeat it a= gain. Henning Rogge Henning, At this point, I'm unsure what the difference between "proactive" and "reac= tive" is. I'm going to interpret "reactive" as "uses scoped floods to disco= ver routes." That is, route request, route reply, etc. If I'm mistaken, the= n my comment below might be off the mark. There's a lot of experimental evidence supporting the claim that using floo= ds or scoped floods to discover routes is ill-suited to low-power and lossy= networks (LLNs). This is due to the low-power requirement. In low-power wi= reless networks, broadcast packets usually cost much more to transmit than = unicast ones. This is one of the reasons why RPL uses a Trickle timer to re= gulate its beaconing interval, so that if the current routes are operating = well the broadcast rate approaches zero. Requiring a scoped flood every tim= e a route breaks or is needed can be very costly. If you want, I can walk you through the issues and a bibliography of low-po= wer link layer and protocol designs. There's about a decade of work. If I w= ere to recommend 3 papers to explain the issues and tradeoffs low power wir= eless introduces, then I'd suggest B-MAC (Polastre, SenSys 2004), X-MAC (Bu= ettner, SenSys 2006) and A-MAC (Dutta, SenSys 2010). For protocol design, 3= papers I'd suggest Dozer (Burri, IPSN 2007), CTP (Gnawali, 2009), and a co= mplete low power IP layer that greatly informed RPL's design (Hui, SenSys 2= 008). I realize there are a lot of opinions on these topics. But there's thankful= ly also a lot of science and engineering. Let's not let the former get in t= he way of the latter. Fully agreeing with Phil. For the ones interested, please also refer to all tickets opened during the= discussion about the design of routing protocol for LLN during the course of 4 years of work in ROLL. There is also quite a bit of background in RFC6= 550 on the fundamental design principles of RPL for LLN. Last but not least, you may all also be interested in the 4 uses case requirements of ro= uting protocols for LLNs: RFC 5548 (draft-ietf-roll-urban-routing-reqs) Routing Requirements for Urban Low-Pow= er and Lossy Networks 2009-05 RFC 5548 (Informational) = Adrian Farrel RFC 5673 (draft-ietf-roll-indus-routing-reqs) Industrial Routing Requirements in Low= -Power and Lossy Networks 2009-10 RFC 5673 (Informational) = Adrian Farrel RFC 5826 (draft-ietf-roll-home-routing-reqs) Home Automation Routing Requirements in Low-Po= wer and Lossy Networks 2010-04 RFC 5826 (Informational) Errata = Adrian Farrel RFC 5867 (draft-ietf-roll-building-routing-reqs) Building Automation Routing Requiremen= ts in Low-Power and Lossy Networks 2010-06 RFC 5867 (Informational) = Adrian Farrel Phil _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7722057C24xmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <1505AEBBE6180D4D8C1DB9180A590ACE@cisco.com> Content-Transfer-Encoding: quoted-printable
On Nov 5, 2012, at 9:56 AM, Philip Levis wrote:

On Nov 4, 2012, at 11:21 PM, Henning Rogge wrote:

On Mon, Nov 5, 2012 at 2:38 AM, JP Vasseur (jvass= eur)
<jvasseu= r@cisco.com> wrote:
JP> We all agree, with a a non subtle nuance. = I never said that reactive
routing was a bad idea. These protocol are very u= seful.
They are just ill-suited to LLNs.

At least that is your personal opinion. We got th= is, no need to repeat it again.

Henning Rogge

Henning,

At this point, I'm unsure what the difference between "proactive"= and "reactive" is. I'm going to interpret "reactive" a= s "uses scoped floods to discover routes." That is, route request= , route reply, etc. If I'm mistaken, then my comment below might be off the mark.

There's a lot of experimental evidence supporting the claim that using floo= ds or scoped floods to discover routes is ill-suited to low-power and lossy= networks (LLNs). This is due to the low-power requirement. In low-power wi= reless networks, broadcast packets usually cost much more to transmit than unicast ones. This is one of the r= easons why RPL uses a Trickle timer to regulate its beaconing interval, so = that if the current routes are operating well the broadcast rate approaches= zero. Requiring a scoped flood every time a route breaks or is needed can be very costly.

If you want, I can walk you through the issues and a bibliography of low-po= wer link layer and protocol designs. There's about a decade of work. If I w= ere to recommend 3 papers to explain the issues and tradeoffs low power wir= eless introduces, then I'd suggest B-MAC (Polastre, SenSys 2004), X-MAC (Buettner, SenSys 2006) and A-MAC (Du= tta, SenSys 2010). For protocol design, 3 papers I'd suggest Dozer (Burri, = IPSN 2007), CTP (Gnawali, 2009), and a complete low power IP layer that gre= atly informed RPL's design (Hui, SenSys 2008).

I realize there are a lot of opinions on these topics. But there's thankful= ly also a lot of science and engineering. Let's not let the former get in t= he way of the latter.

Fully agreeing with Phil.

For the ones interested, please also refer to all tickets opened durin= g the discussion about the design of routing protocol for LLN during the co= urse
of 4 years of work in ROLL. There is also quite a bit of background in= RFC6550 on the fundamental design principles of RPL for LLN. Last but not<= /div>
least, you may all also be interested in the 4 uses case requirem= ents of routing protocols for LLNs: 

RFC 5548 
(draft-ietf-roll-urban-routing-reqs)		 Routing Requirements for Urban Low-Power and Lossy Networks 2009-05 RFC 5548 (Informational) Adrian Farrel
RFC 5673 
(draft-ietf-roll-indus-routing-reqs)		 Industrial Routing Requirements in Low-Power and Lossy Networks 2009-10 RFC 5673 (Informational) Adrian Farrel
RFC 5826 
(draft-ietf-roll-home-routing-reqs)		 Home Automation Routing Requirements in Low-Power and Lossy Networks 2010-04 RFC 5826 (Informational) 
Errata		 Adrian Farrel
RFC 5867 
(draft-ietf-roll-building-routing-reqs)		 Building Automation Routing Requirements in Low-Power and Lossy Networks 2010-06 RFC 5867 (Informational) Adrian Farrel



Phil
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_03B78081B371D44390ED6E7BADBB4A7722057C24xmbrcdx02ciscoc_-- From jpmacker@gmail.com Mon Nov 5 18:20:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0A011E80C5 for ; Mon, 5 Nov 2012 18:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lZYHfIYxBlZ for ; Mon, 5 Nov 2012 18:20:07 -0800 (PST) Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C9BF011E80AE for ; Mon, 5 Nov 2012 18:20:06 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id 56so1152104yhq.31 for ; Mon, 05 Nov 2012 18:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=rSjSjB+C4Z5JOaVgTSmSoFCR2SeR7IOxy9faPwrTFxA=; b=G5cF5Nc4jix/XgzoZTcNO/NIw9NWa2IKL7FAeD0Af9Hvg1+dpcwueqzQ3a+rZ+6Og2 jr4x7SYoNMPdnZswif9MySiYgjzFFZAkyjI8neeb/9zyIMKYwjwfY2fxFHBaNhh7yBiG UqBuwGhIWXlD5Td2adUxa9jHYK1fj98dAjlw+JghTfuQ1CNBqsUHx3d1EvxTmVVqcp6T CJM9/oZVIw+/YgkTu393/4v97PdI2dEHbWQOpdLG1TjNmDjqLNNwccBQBaoweSu4rMUl +o51ktWTnwaP9k3mXTZ9iWVlxvQifsDYgmQgT00MeWHmVz19xv95Ifl8z1eO2jUdnWow HbDQ== Received: by 10.236.141.78 with SMTP id f54mr11138680yhj.92.1352168406398; Mon, 05 Nov 2012 18:20:06 -0800 (PST) Received: from [10.64.95.194] ([166.205.50.213]) by mx.google.com with ESMTPS id j8sm17665925ank.21.2012.11.05.18.20.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Nov 2012 18:20:05 -0800 (PST) References: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220465DF@xmb-rcd-x02.cisco.com> <3D320804-EE40-42FB-BF08-3F662B3F9542@axelcdv.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F425C0A@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F425C0A@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <04739911-F6C2-4380-9433-15BC10F1EA7D@gmail.com> X-Mailer: iPad Mail (10A523) From: jpmacker Date: Mon, 5 Nov 2012 21:20:02 -0500 To: "Stan Ratliff (sratliff)" Cc: " List" , "Bo Berry \(boberry\)" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 02:20:08 -0000 agreed dynamic unit disc graph (udg) analyses are often misleading even in f= irst order effects. its just not reality. this is well known old manet street knowledge, not a bad thing to start with= but not comprehensive, i have a particular paper on this regarding cds backbone= flooding. Sent from my iPad On Nov 5, 2012, at 11:11 AM, "Stan Ratliff (sratliff)" w= rote: > Phil,=20 >=20 > Where were you during the OSPF MANET discussions???? ;-) ;-) That is *exac= tly* what we argued at the time.=20 >=20 > Regards, > Stan >=20 > On Nov 1, 2012, at 12:23 PM, Philip Levis wrote: >=20 >> Simulations of wireless networks using unit disc, time invariant models h= ave zero relevance to reality. Any results from such simulations MUST NOT be= used as evidence of the performance of protocols. :) >>=20 >> Phil >>=20 >> On Oct 31, 2012, at 3:26 PM, Axel Colin de Verdi=C3=A8re wrote: >>=20 >>> Hi JP, >>>=20 >>> As usual, there isn't just one situation, be it in MANETs in general or i= n LLNs in particular. The simulations shown did make some assumptions on the= traffic, and some other assumptions might show different results, but that'= s true of any protocol. Which is why I would also be interested in your resu= lts concerning LOADng in LLNs. >>>=20 >>> Best, >>>=20 >>> Axel >>>=20 >>> Le 31 oct. 2012 =C3=A0 15:12, JP Vasseur (jvasseur) = a =C3=A9crit : >>>=20 >>>> Hi Bo, >>>>=20 >>>> We need to be very careful there =E2=80=A6 these documents provide resu= lts that CANNOT be generalized to say the least. >>>> Hypothesis made on traffic flows are such that you get the results that= you would like to see =E2=80=A6 >>>>=20 >>>> Thanks >>>>=20 >>>> JP. >>>>=20 >>>> On Oct 31, 2012, at 7:29 PM, Bo Berry wrote: >>>>=20 >>>>>=20 >>>>> For background and perspective, ran across these two docs on the origi= n=20 >>>>> and performance of Loadng. The WG may find helpful. >>>>>=20 >>>>> -Bo >>>>>=20 >>>>>=20 >>>>> The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Gener= ation (LOADng) =20 >>>>> By T. Clausen. A. Colin de Verdiere.=20 >>>>> Published in INRIA Research Report 7692 on 2011-07-25. >>>>> http://hipercom.thomasclausen.net/resteam/data/publications/414efa79c4= c772e5af46f426e77ca581.pdf >>>>>=20 >>>>>=20 >>>>> A Comparative Performance Study of the Routing Protocols LOAD and RPL w= ith Bi-Directional Traffic in Low-power and Lossy Networks (LLN) =20 >>>>> By T. Clausen, U. Herberg.=20 >>>>> Published in INRIA Research Report 7637 on 2011-06-01. >>>>> http://hipercom.thomasclausen.net/resteam/data/publications/49eaae3228= cf686a462108aef8332ceb.pdf >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Oct 31, 2012, at 1:48 PM, Jon Black wrote: >>>>>=20 >>>>>> Certainly smart meters are one of the types of networks that are MANE= Ts. Just because houses do not move it does not mean that the connectivity b= etween those meters isn't changing. A smart meter network is most certainly= a MANET. [One could argue that it is not an LLN since at least from the el= ectrical power there is no lack of power.] >>>>>>=20 >>>>>> Totally agree that one size does not fit all. >>>>>>=20 >>>>>> Jon >>>>>>=20 >>>>>> On October 31, 2012 John.Dowdell wrote: >>>>>>=20 >>>>>> While I am very pleased for you and your co-authors that the LOADng w= ork has been so fruitful, I am not really sure that smart meters are really t= he kind of MANET devices that the working group was intended to address. I h= ave been party to the conversations for only a year or two, so I am very hap= py to be corrected by those with longer histories, but MANET to me means dyn= amically moving nodes, with links being established and broken often and wit= hout prior warning. Examples may be communications networks built out of nod= es contained in cars, trucks and aircraft of all sizes. I appreciate a comme= nt on the list a while back that the RF environment for smart metering is ac= tually more difficult than one would think, but I would suggest to the chair= s that unless LOADng has applications in this dynamically mobile environment= (and I have to admit I have not read the spec in enough detail to determine= if this is the case), then we come to the conclusion that the DYMO/AODVv2 p= ath sh >>>>> ould be followed unless we collectively feel that such a direction is n= ot worth pursuing (and note I am definitely not proposing that view). >>>>>>=20 >>>>>> In the two years or so that I have been working with MANETs, the only= conclusion I have come to is that very many use cases exist, and that one s= ize does not fit all. >>>>>>=20 >>>>>> Regards >>>>>>=20 >>>>>> John >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From prvs=2657c9fb8d=david.ward@ll.mit.edu Mon Nov 5 19:19:28 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FAD21F85AE for ; Mon, 5 Nov 2012 19:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1B7LUV6r0Ml for ; Mon, 5 Nov 2012 19:19:28 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4741321F85AC for ; Mon, 5 Nov 2012 19:19:28 -0800 (PST) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id qA63JQ2B021010; Mon, 5 Nov 2012 22:19:27 -0500 From: "Ward, David - 0663 - MITLL" To: "Ivancic, William D. (GRC-RHN0)" Date: Mon, 5 Nov 2012 22:19:23 -0500 Thread-Topic: New Version Notification for draft-ivancic-manet-modemlpa-00.txt Thread-Index: Ac27zYYXDmsiH5f+Q1yHpHDwdb1eSg== Message-ID: <509881BB.6030001@ll.mit.edu> References: <20121105212854.4905.95804.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-11-05_06:2012-11-05, 2012-11-05, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1211050357 Cc: "manet@ietf.org" Subject: Re: [manet] New Version Notification for draft-ivancic-manet-modemlpa-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 03:19:29 -0000 On 11/05/2012 04:31 PM, Ivancic, William D. (GRC-RHN0) wrote: > > > I uploaded the modemlpa draft. Unfortunately, I cannot be at the > meeting this week. > > - Will > Hi Will, I'm not sure that I agree with extending layer 2 information beyond the=20 radio-to-router interface. Looking at figure 4, how will the=20 host/application know which way the router is going to forward packets,=20 in order to control its output data rate? I think the mechanism to=20 control the rate of your application traffic should be separate from the=20 radio-to-router interface. David From charliep@computer.org Mon Nov 5 22:03:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDD321F865E for ; Mon, 5 Nov 2012 22:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqwXadiGCSTd for ; Mon, 5 Nov 2012 22:03:23 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id EB88F21F84DD for ; Mon, 5 Nov 2012 22:03:22 -0800 (PST) Received: from [130.129.66.42] by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TVcFt-0000ac-PT for manet@ietf.org; Tue, 06 Nov 2012 01:03:21 -0500 Message-ID: <5098A826.4000208@computer.org> Date: Mon, 05 Nov 2012 22:03:18 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8653b43a84829baaef0940ad5081d80532350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.66.42 Subject: [manet] New AODVv2 revision still needing a few hours of proofreading X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 06:03:24 -0000 Hello folks, Below, is a link to what I have done so far. It's mostly there, but I am sure there are some lingering mistakes. Before I submit as the next revision, I will fix all of those plus add some missing things to IANA considerations, check for all the manifest constants, make the abbreviations consistent, etc. Aiming to get that all done before the social tomorrow.... http://www.psg.com/~charliep/txt/ietf85/draft-ietf-manet-dymo-24c.txt -- Regards, Charlie P. From abdussalambaryun@gmail.com Tue Nov 6 03:25:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F73821F85E8 for ; Tue, 6 Nov 2012 03:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYlfdGnD967I for ; Tue, 6 Nov 2012 03:25:48 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 88D2B21F85E2 for ; Tue, 6 Nov 2012 03:25:48 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so327806vbb.31 for ; Tue, 06 Nov 2012 03:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9/Q9amGd1W0x7HYfGxOfqT73dTibTEE2axjTLIn4zNw=; b=OQr/FAfrV2SmWL3E6FmRS8tvXbOU9ZXbescLmC+lO0jHoSO/vLLox9ptlZm1RAXfNs 8Bd2JqoLonMCjO5FPqtG8mW8ZSic6XcgNFQXiwyxrsY+5KV9PHT1MAOMT+IQPbgc5Vim Po+e7KFDMUw1kzpA304DmkUqhnqmqGOdtfjopAqDfZRz4g5um16zn600ej/rsHRiY/sr PrTXH5Mn51YH8bVD+FMIQrZGAinLBc9r4k2k/L6I0FeHbG0odtwTjjpe/L/jagdBdKMw E29Dbf7pzHJ/JRSzSQhQRM+gVkUrqgQjLLxfmvCkz+qywwFs1Wnt2DHX6ghVN/5X3yIj Xw5w== MIME-Version: 1.0 Received: by 10.220.16.12 with SMTP id m12mr559974vca.14.1352201146478; Tue, 06 Nov 2012 03:25:46 -0800 (PST) Received: by 10.220.204.9 with HTTP; Tue, 6 Nov 2012 03:25:45 -0800 (PST) In-Reply-To: <92086B00-D5AA-4141-8AB1-2B1A912E5F9A@cs.stanford.edu> References: <03B78081B371D44390ED6E7BADBB4A7722052EFE@xmb-rcd-x02.cisco.com> <92086B00-D5AA-4141-8AB1-2B1A912E5F9A@cs.stanford.edu> Date: Tue, 6 Nov 2012 12:25:45 +0100 Message-ID: From: Abdussalam Baryun To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org List" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 11:25:49 -0000 +1 and thanks for supporting your argument with valuable references. AB On 11/5/12, Philip Levis wrote: > On Nov 4, 2012, at 11:21 PM, Henning Rogge wrote: > >> On Mon, Nov 5, 2012 at 2:38 AM, JP Vasseur (jvasseur) >> wrote: >>> JP> We all agree, with a a non subtle nuance. I never said that reactive >>> routing was a bad idea. These protocol are very useful. >>> They are just ill-suited to LLNs. >> >> At least that is your personal opinion. We got this, no need to repeat it >> again. >> >> Henning Rogge > > Henning, > > At this point, I'm unsure what the difference between "proactive" and > "reactive" is. I'm going to interpret "reactive" as "uses scoped floods to > discover routes." That is, route request, route reply, etc. If I'm mistaken, > then my comment below might be off the mark. > > There's a lot of experimental evidence supporting the claim that using > floods or scoped floods to discover routes is ill-suited to low-power and > lossy networks (LLNs). This is due to the low-power requirement. In > low-power wireless networks, broadcast packets usually cost much more to > transmit than unicast ones. This is one of the reasons why RPL uses a > Trickle timer to regulate its beaconing interval, so that if the current > routes are operating well the broadcast rate approaches zero. Requiring a > scoped flood every time a route breaks or is needed can be very costly. > > If you want, I can walk you through the issues and a bibliography of > low-power link layer and protocol designs. There's about a decade of work. > If I were to recommend 3 papers to explain the issues and tradeoffs low > power wireless introduces, then I'd suggest B-MAC (Polastre, SenSys 2004), > X-MAC (Buettner, SenSys 2006) and A-MAC (Dutta, SenSys 2010). For protocol > design, 3 papers I'd suggest Dozer (Burri, IPSN 2007), CTP (Gnawali, 2009), > and a complete low power IP layer that greatly informed RPL's design (Hui, > SenSys 2008). > > I realize there are a lot of opinions on these topics. But there's > thankfully also a lot of science and engineering. Let's not let the former > get in the way of the latter. > > Phil > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Tue Nov 6 03:35:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE6721F843C for ; Tue, 6 Nov 2012 03:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcQJtee8xVAB for ; Tue, 6 Nov 2012 03:35:37 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6FC21F843E for ; Tue, 6 Nov 2012 03:35:36 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so483668iec.31 for ; Tue, 06 Nov 2012 03:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UjkqYudQBqJuf56O6Wb7u80rANlKO4MZMBJ3BPu3rdg=; b=MTblWYeMeC9HPRE3dPudEVnXqgOb8SmYBP5mBYuQ4HXbuTQGHKGDUG9A603bfkPT1o YY0hEmiJaTfEqxCVlchmjKkUCY1K4+Ak/jfwr21cVkhVD6+ybH/IHXPzgDp1d+djJdpt AogSjNg29Ny9+l1tp1fbzX3eWCLvkUkScCb0aUvOAjpPqAiDKIy4rngDT4anFNNu3mn+ Lmdn3ZRReGt0kFdlKtcc+GfcgbsHRn54Ciws0o7enNtEUfobAj+7VWh3Aa5Cc50+3PNu SuSLWw0cnIZWBHnoYm4F82PgiHuiN5+GCcruwEQI0EugTsrjAjzxwktRcmfzEfAb6NGR p1Tg== MIME-Version: 1.0 Received: by 10.50.0.171 with SMTP id 11mr651230igf.14.1352201736521; Tue, 06 Nov 2012 03:35:36 -0800 (PST) Received: by 10.64.25.46 with HTTP; Tue, 6 Nov 2012 03:35:36 -0800 (PST) In-Reply-To: <061.f6d9e0fa28b46c77085c2605af4906fb@trac.tools.ietf.org> References: <061.f6d9e0fa28b46c77085c2605af4906fb@trac.tools.ietf.org> Date: Tue, 6 Nov 2012 12:35:36 +0100 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] #7: Top level document organization X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 11:35:41 -0000 Thanks, I agree with the proposal, AB On 11/5/12, manet issue tracker wrote: > #7: Top level document organization > > Previous revisions have collected together various sections describing > base protocol features into a top-level section entitled "Detailed > Operation for the Base Protocol". However, this does not seem to provid= e > very much guidance for finding appropriate sections of the document, and > some of the subsections seem better suited to be described in their own > high-level sections. There is another section devoted to Optional > Features, and it seems that already provides a pretty good way to separa= te > Base features from Optional features. It is proposed to eliminate the > abovementioned top-level section and promote its subsections to be top- > level sections. > > Here is a snapshot of the Table of Contents, still subject to minor > changes: > > {{{ > Table of Contents > > 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 > 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 8 > 4.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 8 > 4.2. AODVv2 Message Structure and Information Elements . . . . 10 > 4.3. RteMsg-specific Protocol Elements . . . . . . . . . . . . 13 > 4.4. Route Error (RERR)-specific Protocol Elements . . . . . . 14 > 5. AODVv2 Sequence Numbers . . . . . . . . . . . . . . . . . . . 14 > 6. AODVv2 Operations on Route Table Entries . . . . . . . . . . . 15 > 6.1. Evaluating Incoming Routing Information . . . . . . . . . 15 > 6.2. Creating or Updating Route Table Entries . . . . . . . . . 17 > 6.3. Route Table Entry Timeouts . . . . . . . . . . . . . . . . 17 > 7. Routing Messages . . . . . . . . . . . . . . . . . . . . . . . 18 > 7.1. RREQ Creation . . . . . . . . . . . . . . . . . . . . . . 18 > 7.2. RREP Creation . . . . . . . . . . . . . . . . . . . . . . 19 > 7.3. Handling a Received RteMsg . . . . . . . . . . . . . . . . 19 > 8. Route Discovery, Retries, and Buffering . . . . . . . . . . . 21 > 9. Route Maintenance . . . . . . . . . . . . . . . . . . . . . . 22 > 9.1. Active Next-hop Router Adjacency Monitoring . . . . . . . 22 > 9.2. Handling Route Lifetimes During Packet Forwarding . . . . 23 > 9.3. RERR Generation . . . . . . . . . . . . . . . . . . . . . 23 > 9.4. Receiving and Handling RERR Messages . . . . . . . . . . . 24 > 10. Unknown Message and TLV Types . . . . . . . . . . . . . . . . 25 > 11. Advertising Network Addresses . . . . . . . . . . . . . . . . 25 > 12. Simple Internet Attachment . . . . . . . . . . . . . . . . . . 25 > 13. Multiple Interfaces . . . . . . . . . . . . . . . . . . . . . 27 > 14. AODVv2 Control Packet/Message Generation Limits . . . . . . . 27 > 15. Optional Features . . . . . . . . . . . . . . . . . . . . . . 27 > 15.1. Expanding Rings Multicast . . . . . . . . . . . . . . . . 28 > 15.2. Intermediate RREP . . . . . . . . . . . . . . . . . . . . 28 > 15.3. Precursor Notification . . . . . . . . . . . . . . . . . . 28 > 15.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 28 > 15.3.2. Precursor Notification . . . . . . . . . . . . . . . 28 > 15.4. Reporting Multiple Unreachable Nodes . . . . . . . . . . . 30 > 15.5. Message Aggregation . . . . . . . . . . . . . . . . . . . 30 > 15.6. Adding Additional Routing Information to a RteMsg . . . . 30 > 16. Administratively Configured Parameters and Timer Values . . . 32 > 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 > 17.1. AODVv2 Message Types Specification . . . . . . . . . . . . 35 > 17.2. Message and Address Block TLV Type Specification . . . . . 35 > 17.3. Address Block TLV Specification . . . . . . . . . . . . . 36 > 18. Security Considerations . . . . . . . . . . . . . . . . . . . 36 > 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 > 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 > 20.1. Normative References . . . . . . . . . . . . . . . . . . . 38 > 20.2. Informative References . . . . . . . . . . . . . . . . . . 39 > Appendix A. Changes since the Previous Version . . . . . . . . . 40 > Appendix B. Shifting Network Prefix Advertisement Between > AODVv2 Routers . . . . . . . . . . . . . . . . . . . 41 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 > }}} > > -- > --------------------------------+----------------------------- > Reporter: charliep@=85 | Owner: Charlie Perkins > Type: enhancement | Status: new > Priority: minor | Milestone: > Component: dymo | Version: > Severity: Active WG Document | Keywords: > --------------------------------+----------------------------- > > Ticket URL: > manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Tue Nov 6 03:43:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D3D21F884D for ; Tue, 6 Nov 2012 03:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-cunwQBPNol for ; Tue, 6 Nov 2012 03:43:58 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE5821F884C for ; Tue, 6 Nov 2012 03:43:58 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so494816iec.31 for ; Tue, 06 Nov 2012 03:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LRgvLb+xC61KVOXLMAYHXAgmHUbmPfqg87haBhkATkQ=; b=EPjL13AcQtERV0jm6JwD+V18/Z1vAn0XuUMpUxQbZAOvUdbs49RkHcS+QyxjXHn68U VYOO1NopODTj+rbYao8Z5kI8b5SivRLTUxAM6NjSZ24SidirL0y5s9m8HPt1Hnxc3qr8 9T92OMyeVUzQwsxj931IHsMpk5FqvP7mOpZnnrNEeCFJ3ptITmI+4W+t9YiWReoBI/UB 1iZ3K1m72jdK8ZXMfxJPTm7v2/82/MX4iPjVTeMVcBVPttOcfzldboP3Fa3s/gfYTxhq UwJwbT+ylLlW/P+A43Ax2ykhqqTnS36x+irbSQbsp6CdxoqfjRgAA09ApdaI37w877Qa vZjg== MIME-Version: 1.0 Received: by 10.50.190.161 with SMTP id gr1mr12666214igc.14.1352202237686; Tue, 06 Nov 2012 03:43:57 -0800 (PST) Received: by 10.64.25.46 with HTTP; Tue, 6 Nov 2012 03:43:57 -0800 (PST) In-Reply-To: <5098A826.4000208@computer.org> References: <5098A826.4000208@computer.org> Date: Tue, 6 Nov 2012 12:43:57 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" , "ian.chakeres" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] New AODVv2 revision still needing a few hours of proofreading X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 11:43:59 -0000 Dear Charlie and Ian, I read the draft and have no further modify comments, I suggest to propose the WG draft to WGLC, Regards AB On 11/6/12, Charles E. Perkins wrote: > > Hello folks, > > Below, is a link to what I have done so far. It's mostly there, but I > am sure there > are some lingering mistakes. Before I submit as the next revision, I > will fix all > of those plus add some missing things to IANA considerations, check for all > the manifest constants, make the abbreviations consistent, etc. > > Aiming to get that all done before the social tomorrow.... > > http://www.psg.com/~charliep/txt/ietf85/draft-ietf-manet-dymo-24c.txt > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Tue Nov 6 03:46:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924A421F8976 for ; Tue, 6 Nov 2012 03:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.122 X-Spam-Level: X-Spam-Status: No, score=-3.122 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLeDv-ql7g9F for ; Tue, 6 Nov 2012 03:46:40 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6E4921F88C7 for ; Tue, 6 Nov 2012 03:46:39 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so498405iec.31 for ; Tue, 06 Nov 2012 03:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+IFRSMLQeZyZOoPEi10r2K8T7U/T5G6zCt0RKMG/bzg=; b=DDIUpisxY3QWdIu2Ym2K0FlIYFl8H+VRRmwgt9mKoR+XPH1jKG42ub7dPY7EwxadB4 PtpPSuRfn2rUDCGXzfiLZHShONdE5vLXGFu7lgfj4RfhVH419ap4b+UoEEcOYYRxLnib 16SKtkwICyAEjoagwcWli/zhKYOQOosjmY8vC4ecpuLrYPzUAQ/96vdCds6ReX+8nKtE X0RhJ6pd0i18kFTz213C3RyM+/jB89v4x2KrMeoIZc+8ZN1ynGRKGWmS31HIP4mqk3sc EfRrCmmQOYTSQMS3lWBkwEZCu3nMhlCOTOSSlLOAqKu/z5V2cgs9P1eB+D7XCKClPccY 0imQ== MIME-Version: 1.0 Received: by 10.50.190.161 with SMTP id gr1mr12672842igc.14.1352202397899; Tue, 06 Nov 2012 03:46:37 -0800 (PST) Received: by 10.64.25.46 with HTTP; Tue, 6 Nov 2012 03:46:37 -0800 (PST) In-Reply-To: <509881BB.6030001@ll.mit.edu> References: <20121105212854.4905.95804.idtracker@ietfa.amsl.com> <509881BB.6030001@ll.mit.edu> Date: Tue, 6 Nov 2012 12:46:37 +0100 Message-ID: From: Abdussalam Baryun To: "Ward, David - 0663 - MITLL" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] New Version Notification for draft-ivancic-manet-modemlpa-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 11:46:40 -0000 +1 AB On 11/6/12, Ward, David - 0663 - MITLL wrote: > On 11/05/2012 04:31 PM, Ivancic, William D. (GRC-RHN0) wrote: >> >> >> I uploaded the modemlpa draft. Unfortunately, I cannot be at the >> meeting this week. >> >> - Will >> > > Hi Will, > > I'm not sure that I agree with extending layer 2 information beyond the > radio-to-router interface. Looking at figure 4, how will the > host/application know which way the router is going to forward packets, > in order to control its output data rate? I think the mechanism to > control the rate of your application traffic should be separate from the > radio-to-router interface. > > David > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From ulrich@herberg.name Tue Nov 6 10:22:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0BB21F8A81 for ; Tue, 6 Nov 2012 10:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoJMT9CIo8gZ for ; Tue, 6 Nov 2012 10:22:05 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA5421F8A6F for ; Tue, 6 Nov 2012 10:22:05 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so748614vcb.31 for ; Tue, 06 Nov 2012 10:22:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BLt9Jh9HRvgS9gDUQKvGKSL+glf8A3K5nJ9aQtrZAGU=; b=vQg2v2ZRyzG17voJ1Sd+YqFoWaUCoCe17xm+1/jY4vAgvY/whM+LwwT4BcXu5bxjYE WZzCgHGkiu/fBSShUoZT+NhyhOe3EUlPgGkzO1nXBci/VOnPsACv1DSBmvnW6zLMOYh3 cG7satFd5mc0ehcWo7w/9YtSgecP7fxJQTvgo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=BLt9Jh9HRvgS9gDUQKvGKSL+glf8A3K5nJ9aQtrZAGU=; b=dtoOoOaOuPAzsZXkkP7xnStX2w02lXx7ousmo+5TwpDT8OAaEhI7ZupN2OwdqmQcdP K0xM1y++eTu5cwX75Pm+OfAwFu0wvWJFMAyyj8sTse++UnAQt/Cxs2bz2zbOJOwW8kb/ 0zmSsl+KsZzjyXt7yEIrSBu+eZY+y1saB0YatDYhPgJWoewioXyLeAECgvu6mTu3pbh7 6lX2fV35eoW+RAiPdB+7/s5b2cRk9+h3MXvx5wyGFWJrXor06NmSUc7QIhSv37CRJSg0 Wyz4Nm4tuBejhHLCQA0UNHNLLdYlUN2Dp9S2bvCJ5frYgGhCMizV7re9dAWYCDAIbfDi pang== MIME-Version: 1.0 Received: by 10.220.150.82 with SMTP id x18mr1693658vcv.73.1352226124939; Tue, 06 Nov 2012 10:22:04 -0800 (PST) Received: by 10.58.94.103 with HTTP; Tue, 6 Nov 2012 10:22:04 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Nov 2012 13:22:04 -0500 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=f46d043c7c1ed542c504cdd7ad88 X-Gm-Message-State: ALoCoQnwE5KR8kd3GBLdcM/s8OaEVDsd8H2tXHYu52AVjb5VNrUaXbUs5EKJmoTYxp/+hrhEfOEJ Subject: Re: [manet] Slides please X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 18:22:06 -0000 --f46d043c7c1ed542c504cdd7ad88 Content-Type: text/plain; charset=ISO-8859-1 Hello, a friendly reminder to send me the slides as soon as possible. Thanks Ulrich On Wed, Oct 31, 2012 at 7:00 PM, Ulrich Herberg wrote: > Hello, > > for those who present at the MANET meeting: please send your slides (in > ppt or pdf) to the chairs and me. Please send them by this weekend, so that > I can upload the slides on Sunday. > > Thank you > Ulrich > --f46d043c7c1ed542c504cdd7ad88 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

a friendly reminder to send me the slides as soon= as possible.

Thanks
Ulrich

On Wed, Oct 31, 2012 at 7:00 PM, Ulrich Herberg <u= lrich@herberg.name> wrote:
Hello,

for those who pres= ent at the MANET meeting: please send your slides (in ppt or pdf) to the ch= airs and me. Please send them by this weekend, so that I can upload the sli= des on Sunday.

Thank you
Ulrich

--f46d043c7c1ed542c504cdd7ad88-- From jvasseur@cisco.com Tue Nov 6 11:01:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9721021F8AFD for ; Tue, 6 Nov 2012 11:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.447 X-Spam-Level: X-Spam-Status: No, score=-10.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVX+S2-hiYkk for ; Tue, 6 Nov 2012 11:01:40 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9952721F8ACA for ; Tue, 6 Nov 2012 11:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3339; q=dns/txt; s=iport; t=1352228500; x=1353438100; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zPf1VsyqHq1fL2rqI4498z9D0S5ku1b+JfzqPSSlPDM=; b=iHbT366eOkajhTXIg5AfmN/LxiCXmFjTVbFAKWf7w+NUmaURCVCjZSvu B0RiWYQuXnCSv2apIsv6Mx045ymtIeV6jIxqlSb6YIvVAvphiUciFYZtg FXbtY0xvAnahOyDQuUFfG6lE56h/FqynWfgDmOz7jYY2Wu6T8j9kAUs/T s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABZemVCtJV2d/2dsb2JhbABEwzGBCIIeAQEBAwEBAQEPASc0CxACAQgYChQQJwslAgQOBQgah2IGC5wUj2KQPwSMAyeFTWEDpFSBa4JvgV0HFx4 X-IronPort-AV: E=Sophos;i="4.80,722,1344211200"; d="scan'208";a="139418984" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 06 Nov 2012 19:01:39 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA6J1dAv032115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 19:01:39 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 13:01:39 -0600 From: "JP Vasseur (jvasseur)" To: "Charles E. Perkins" Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuRrYLPVi/cSo/ES1hdb7zda62w== Date: Tue, 6 Nov 2012 19:01:38 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772205B854@xmb-rcd-x02.cisco.com> References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C638@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204C877@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204CB91@xmb-rcd-x02.cisco.com> <1351891740.83248.YahooMailNeo@web160605.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204D717@xmb-rcd-x02.cisco.com> <50972F44.5040901@saloits.com> <5097550A.9010300@computer.org> In-Reply-To: <5097550A.9010300@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.120.65] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002 x-tm-as-result: No--44.761000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <13E607FD4B21FD41810CF33C9D1A890E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Timothy J. Salo" , "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 19:01:41 -0000 Looks very promising Charlie, thanks for the update, looking forward to the= next revision. On Nov 5, 2012, at 12:56 AM, Charles E. Perkins wrote: >=20 > Hello folks, >=20 > I'm working away on a new revision. The terminology has been significant= ly > improved. I need to respond to many email messages, but there are so man= y! > The feature descriptions in the previous specifications has become much > more clear. I've got RFC 5444 packet formats to add to the spec, probabl= y > will finish this tomorrow. The text for the reorganized route timeouts i= s > much more compact and understandable than the previous revisions. There > is a small reduction in flexibility compared to previous versions, but it= takes > a very close reading (which I have done) to figure out where. I'm pretty= sure > the extra bits of flexibility regarding route timeouts will never be miss= ed. >=20 > This email caught my attention: >=20 > On 11/4/2012 7:15 PM, Timothy J. Salo wrote: >>=20 >> Of course, the approach of base and extensions documents does >> pose some risks. First, we might not agree on what the base protocol >> is, and whether the LOADng document accurately reflects that group >> consensus on what ought be be in the base protocol. Second, the >> base protocol might not accurately reflect the experience of the >> available modeling and field deployment experience. This might >> give rise to some risk that the working group might select the >> wrong functionality for inclusion in a base protocol specification. >>=20 >> My concerns would be somewhat alleviated if there are good prospect >> that two interoperable implementations of the DYMO-based >> (base+extensions) approach exist and that their developers are >> committed to upgrading them to whatever protocol (including >> options/extensions) the working group finally agrees upon. >=20 > I remain ever more confident that this can (and *should*) be done. > Certain features (intermediate RREP as just one example) need to be > considered so that they have a natural fit with the "base protocol". >=20 >>=20 >> I think that it would be useful to have more information about the >> state of DYMO and LOADng implementations, including the prospects >> that these implementations will conform to the eventual working >> group consensus. In my view, the working group really ought to >> have detailed information about the current and prospective >> implementations before deciding on an approach -- I would be >> surprised if this information could be pulled together in sufficient >> detail by the Atlanta meetings. >=20 > I will try to make as much information available as possible, and in > particular to make available a next revision that does not have so > many hasty inconsistencies as the last two (after ...-21.txt). And > the ...-21.txt revision had its various inconsistencies that I have been > repairing . Please keep in mind that the revision process since > I resumed editorial duties has been "alloted" less than a month of > my time, and I am sure you will notice rapid progress since then. >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From charliep@computer.org Tue Nov 6 22:51:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C2F21F888C for ; Tue, 6 Nov 2012 22:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5VIFJ9gcq+N for ; Tue, 6 Nov 2012 22:51:08 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9F821F8879 for ; Tue, 6 Nov 2012 22:51:08 -0800 (PST) Received: from [130.129.66.42] by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TVzTf-00010B-Eu for manet@ietf.org; Wed, 07 Nov 2012 01:51:07 -0500 Message-ID: <509A04D7.3090605@computer.org> Date: Tue, 06 Nov 2012 22:51:03 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad867d60716368f0c7b7e8d436a251e24b58350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.66.42 Subject: [manet] draft-ietf-manet-dymo-24d.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 06:51:09 -0000 Hello folks, I still didn't finish proofreading the next AODVv2 revision document, due to normal IETF reasons like meetings and so on. However, numerous improvements and logical inconsistencies from ...-24c have been fixed. I'd like the next revision to finally be something I can be proud of, in contrast to the last two drastically rushed revisions. I think at least that the RFC 5444 compliance is pretty close now. Some of the optional features still need work. Here is the next intermediate revision: http://www.psg.com/~charliep/txt/ietf85/draft-ietf-manet-dymo-24d.txt There is a good chance I can finish the proofreading tomorrow. Thanks for your understanding. -- Regards, Charlie P. From yi.jiazi@gmail.com Wed Nov 7 07:37:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CE321F8C01 for ; Wed, 7 Nov 2012 07:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21BG9tVn2+nT for ; Wed, 7 Nov 2012 07:37:36 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 455C421F8B67 for ; Wed, 7 Nov 2012 07:37:36 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so1348762pbb.31 for ; Wed, 07 Nov 2012 07:37:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:subject:message-id:date:to:mime-version :x-mailer; bh=1IA8k/wcfvwP019BcFQSE17hoTyVhIHpWo6W6Fyi9is=; b=Y9VirNjG5Xxq9JQFfcJJ/EyQnDmnO1IUGpMkGOWrd049pYLjArQtktiOJx5ub5Kjjm a9mRPWTYR1fb5yRMRYl5fe55yTpJIVzfkeWnoamNYduW5sZ4xCNq8W/yJv18pCvGB5CC Sjt5BPMPBpjzlIFUDm9fFCw9zveb20+aJ7vEF23shOwBr7qTMSe0TTccspU3mq7d97Ig VvG49QsU52fjW7RWJNkSscx3Wr1w08TuZVusTdoAG9uhNUmjoXz68kcdT4FnZLNQmews GcKxWsqq0y6i+oSAWbnoJD8ssqhVLdltjd5PvuOUeCfuw0fDQJ+5RsBk2HfXWC2CTaPO 7PxQ== Received: by 10.66.85.233 with SMTP id k9mr7262119paz.73.1352302650220; Wed, 07 Nov 2012 07:37:30 -0800 (PST) Received: from dhcp-41ca.meeting.ietf.org (dhcp-41ca.meeting.ietf.org. [130.129.65.202]) by mx.google.com with ESMTPS id oi2sm14286783pbb.62.2012.11.07.07.37.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 07:37:29 -0800 (PST) Sender: Jiazi YI From: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_981A154D-0B15-4FFC-9F58-2968EBBEC481" Message-Id: Date: Wed, 7 Nov 2012 10:37:26 -0500 To: "manet@ietf.org List" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [manet] Some general comments for dymo-23/24 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:37:37 -0000 --Apple-Mail=_981A154D-0B15-4FFC-9F58-2968EBBEC481 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi,=20 I had a detailed review of dymo-23 draft. Because the editor is still = working on dymo-24, and there are many changes on the text between those = two revisions, I'm just putting some general comments.=20 Those comments are mainly based on observations of dymo-23, but I think = they still hold after a quick reading through of dymo-24 = http://www.psg.com/~charliep/txt/ietf85/draft-ietf-manet-dymo-24d.txt 1. It's not clear how metric are used and calculated, and how different = metrics can be supported (according to the specification, only hop-count = metric can be used).=20 2. Don't know how uni-directional links should be handled. There is some = text mentioning blacklist, etc, but no specification on the details.=20 3. No full RFC5444 compliance. Especially there are violations between = the IP layer and RFC 5444 message layer. In the meantime, the use of = TLVs is unclear, and I don't know how to map some of the fields to = RFC5444 TLVs.=20 4. How to use jitter is not specified.=20 5. Although there is a short section 5.9 declaring DYMO can be used with = multiple interfaces, the specification is in lack of text & information = bases to support it.=20 6. The protocol says that it maybe operate at different layers, but the = whole specification is bind to IP.=20 7 . Too much SHOULD in the text, without further explanation why not = MUST. =20 8. The whole specification is full of different optional features = (intermediate RREP, blacklist, message aggregation, etc...), without = further information when to use them, and how to do with them.=20 best Jiazi= --Apple-Mail=_981A154D-0B15-4FFC-9F58-2968EBBEC481 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I had a = detailed review of dymo-23 draft. Because the editor is still working on = dymo-24, and there are many changes on the text between those two = revisions, I'm just putting some general = comments. 
Those = comments are mainly based on observations of dymo-23, but I think they = still hold after a quick reading through of dymo-24 http://www.psg.com/~charliep/txt/ietf85/draft-ietf-manet-dymo-24d.txt=

1. It's not clear how metric are used and calculated, and how = different metrics can be supported (according to the specification, only = hop-count metric can be used). 

2. Don't = know how uni-directional links should be handled. There is some text = mentioning blacklist, etc, but no specification on the = details. 

3. No full RFC5444 compliance. = Especially there are violations between the IP layer and RFC 5444 = message layer. In the meantime, the use of TLVs is unclear, and I don't = know how to map some of the fields to RFC5444 = TLVs. 

4. How to use jitter is not = specified. 

5. Although there is a short = section 5.9 declaring DYMO can be used with multiple interfaces, the = specification is in lack of text & information bases to support = it. 

6. The protocol says that it maybe = operate at different layers, but the whole specification is bind to = IP. 

7 . Too much SHOULD in the text, = without further explanation why not MUST. =  

8. The whole specification is full of = different optional features (intermediate RREP, blacklist, message = aggregation, etc...), without further information when to use them, and = how to do with = them. 

best

Jiazi= --Apple-Mail=_981A154D-0B15-4FFC-9F58-2968EBBEC481-- From charliep@computer.org Wed Nov 7 07:53:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76DA21F8B8E for ; Wed, 7 Nov 2012 07:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAOL56d8gUmp for ; Wed, 7 Nov 2012 07:53:00 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id EC44B21F8C31 for ; Wed, 7 Nov 2012 07:52:59 -0800 (PST) Received: from [130.129.66.42] by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TW7w3-0003W5-Cq for manet@ietf.org; Wed, 07 Nov 2012 10:52:59 -0500 Message-ID: <509A83D5.1020600@computer.org> Date: Wed, 07 Nov 2012 07:52:53 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "manet@ietf.org List" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad866d7b2714cf1e04636f2f0ab0145c8ba2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.66.42 Subject: [manet] Stability and optional features in AODVv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:53:01 -0000 Hello folks, The AODVv2 specification has certain optional features; each one is in the current specification for pretty good reasons. I believe that once these optional features are completed, and modified according to WG consensus, it is likely that no other optional features will be included. If there is WG consensus for removing some of the optional features, that is also fine of course; as yet another alternative, a feature could be moved to another document. The exception would be to allow for alternate metrics. I have a proposal for that, which I will propose to the list shortly by way of raising an issue on the issue tracker. Regards, Charlie P. From jvasseur@cisco.com Wed Nov 7 08:05:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242A421F88EE for ; Wed, 7 Nov 2012 08:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.451 X-Spam-Level: X-Spam-Status: No, score=-10.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uafJOFrB2-KX for ; Wed, 7 Nov 2012 08:05:13 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A454921F8BCE for ; Wed, 7 Nov 2012 08:05:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8353; q=dns/txt; s=iport; t=1352304301; x=1353513901; h=from:to:subject:date:message-id:references:mime-version; bh=COWV3XuOFyp/Vk5to3mOIbmm+TA6M/36rAckR57CopQ=; b=cObIebkk4o0NAYXFYsh9Qw+7b9EaU5nND3IwnmnHW+4RRU1BXKlYtzg7 GUMzW1rKjF6tj+mo4hKXC9uiMwxvKYZQEKkHTwwvBfTfU2HnWaJT1XMUo UfS8RhIsWm4UsKKqxiBCObLZGw4shDU5mhA3x/YqHvF4gZnY/YuL8P/vI g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIGGmlCtJXG//2dsb2JhbABEw2CBCIIaBAEBAQQBAQEPAVsbAgEZAwECCx0HJwsUBwIIAgQTCAELDoUnB4IeHAucMaAljA2FZmEDlxeKGoMjgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,730,1344211200"; d="scan'208,217";a="139778368" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 07 Nov 2012 16:04:48 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA7G4mMI017706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 7 Nov 2012 16:04:48 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 10:04:47 -0600 From: "JP Vasseur (jvasseur)" To: "manet@ietf.org List" Thread-Topic: I-D Action: draft-herberg-lln-loadng-mib-01.txt Thread-Index: AQHNvQGcakeklW33hUCFwBgPpdiMBg== Date: Wed, 7 Nov 2012 16:04:47 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722060637@xmb-rcd-x02.cisco.com> References: <20121107142822.12100.51447.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.113.170] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--43.033600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722060637xmbrcdx02ciscoc_" MIME-Version: 1.0 Subject: [manet] Fwd: I-D Action: draft-herberg-lln-loadng-mib-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:05:14 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7722060637xmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, Are you expecting to use SNMPv2 is constrained networks ? As you know, the = IETF came up with different ways of managing networks that are indeed constrained (CoRE). Thanks. JP. Begin forwarded message: From: > Subject: I-D Action: draft-herberg-lln-loadng-mib-01.txt Date: November 7, 2012 9:28:22 AM EST To: > Reply-To: > A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Definition of Managed Objects for the Lightweight On-dema= nd Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) Author(s) : Ulrich Herberg Robert G. Cole Thomas Heide Clausen Filename : draft-herberg-lln-loadng-mib-01.txt Pages : 43 Date : 2012-11-07 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) process on a router. The MIB module defined in this memo, denoted LOADng-MIB, also reports state. While LOADng is layer agnostic and can be run with different address families (e.g., on L2 using MAC addreses, or on L3 using IP addresss), this MIB module assumes that LOADng is used on L3, and uses only IPv4/IPv6 addresses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-herberg-lln-loadng-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-herberg-lln-loadng-mib-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-herberg-lln-loadng-mib-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_000_03B78081B371D44390ED6E7BADBB4A7722060637xmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Dear Authors,

Are you expecting to use SNMPv2 is constrained networks ? As you know,= the IETF came up with different ways of managing 
networks that are indeed constrained (CoRE).

Thanks.

JP.

Begin forwarded message:

From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Subject: I-= D Action: draft-herberg-lln-loadng-mib-01.txt
Date: Novem= ber 7, 2012 9:28:22 AM EST
To: <<= a href=3D"mailto:i-d-announce@ietf.org">i-d-announce@ietf.org>
Reply-To: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


Title  = ;         : Definition of Mana= ged Objects for the Lightweight On-demand Ad hoc Distance-vector Routing Pr= otocol - Next Generation (LOADng)
Author(s) &= nbsp;     : Ulrich Herberg
            &nb= sp;            = Robert G. Cole
            &nb= sp;            = Thomas Heide Clausen
Filename &n= bsp;      : draft-herberg-lln-loadng-mib-01.t= xt
Pages  = ;         : 43
Date  =           : 2012-11-07
Abstract:
  This memo defines a portion of the Management Information Base = (MIB)
  for use with network management protocols in the Internet commu= nity.
  In particular, it describes objects for configuring parameters = of the
  Lightweight On-demand Ad hoc Distance-vector Routing Protocol -= Next
  Generation (LOADng) process on a router.  The MIB module d= efined in
  this memo, denoted LOADng-MIB, also reports state.  While = LOADng is
  layer agnostic and can be run with different address families (= e.g.,
  on L2 using MAC addreses, or on L3 using IP addresss), this MIB=
  module assumes that LOADng is used on L3, and uses only IPv4/IP= v6
  addresses.


The IETF datatracker status page for this draft is:
h= ttps://datatracker.ietf.org/doc/draft-herberg-lln-loadng-mib

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-herberg-lln-loadng-mib-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-herberg-lln-loadng-mib-01


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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--_000_03B78081B371D44390ED6E7BADBB4A7722060637xmbrcdx02ciscoc_-- From charliep@computer.org Wed Nov 7 08:06:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CC821F8C31 for ; Wed, 7 Nov 2012 08:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mLE6+JUO8V4 for ; Wed, 7 Nov 2012 08:06:36 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id F09BC21F8C0A for ; Wed, 7 Nov 2012 08:06:27 -0800 (PST) Received: from [130.129.66.42] by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TW890-0003xA-UK; Wed, 07 Nov 2012 11:06:22 -0500 Message-ID: <509A86F9.70202@computer.org> Date: Wed, 07 Nov 2012 08:06:17 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Jiazi YI References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8674a3c3a4c2b4970038e1820e0cb6cfb6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.66.42 Cc: "manet@ietf.org List" Subject: Re: [manet] Some general comments for dymo-23/24 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:06:37 -0000 Hello Jiazi, Congratulations on your field goal last night :-) Thanks for your general comments. I'll just make some general follow-up. I am continuing to work on bringing consistency and clarity to the document, and your comments are helpful. On 11/7/2012 7:37 AM, Jiazi YI wrote: > > 1. It's not clear how metric are used and calculated, and how > different metrics can be supported (according to the specification, > only hop-count metric can be used). My proposal is to replace all existing metric calculation and description in the document to be specifically about HopCount, and to make the appropriate changes to terminology (so, for instance, replace Route.Dist by Route.HopCount). > > 2. Don't know how uni-directional links should be handled. There is > some text mentioning blacklist, etc, but no specification on the details. There is some specification now about blacklist. More about this below. While more could be added to the specification, it is more of a layer-2 feature and any layer-3 support should be considered optional. > > 3. No full RFC5444 compliance. Especially there are violations between > the IP layer and RFC 5444 message layer. In the meantime, the use of > TLVs is unclear, and I don't know how to map some of the fields to > RFC5444 TLVs. I think that one could probably "guess right" given the current information in the specification, but I agree this is an urgent area for improvement. My intention to make this crystal clear, hopefully today. > > 4. How to use jitter is not specified. I'm open to suggestion on this. Should I take a look at LOADng and follow the example from that document? Previous versions of AODV have not been very precise on this point. > > 5. Although there is a short section 5.9 declaring DYMO can be used > with multiple interfaces, the specification is in lack of text & > information bases to support it. Actually, I don't see what else needs to be done. I believe that with proper IP address management, there is little else that is required. But I know that OLSR has in the past paid a lot of attention to this, and I am open to suggestion. > > 6. The protocol says that it maybe operate at different layers, but > the whole specification is bind to IP. It has been suggested that I simply remove that text. It's not really normative, and only meant to inspire people who might wish to make the appropriate modifications for their layer. For instance, I think you could do the same protocol with some modifications for overlay routing :-) > > 7 . Too much SHOULD in the text, without further explanation why not > MUST. I agree. Once the specification is stable, I will attend each one of these details. > > 8. The whole specification is full of different optional features > (intermediate RREP, blacklist, message aggregation, etc...), without > further information when to use them, and how to do with them. Point noted... For each optional feature, I will include more description about when it might be useful. Thanks for your additional motivation to get this done. In particular, blacklisting should be optional because in many situations AODVv2 can rely on layer-2 information describing whether or not the link is bidirectional. -- Regards, Charlie P. From jvasseur@cisco.com Wed Nov 7 08:07:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0262221F8C12 for ; Wed, 7 Nov 2012 08:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.457 X-Spam-Level: X-Spam-Status: No, score=-10.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orOD0So0o8Rz for ; Wed, 7 Nov 2012 08:07:36 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 06C7F21F8C74 for ; Wed, 7 Nov 2012 08:07:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1268; q=dns/txt; s=iport; t=1352304455; x=1353514055; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=J7FA5gr8SZ1buZeAHekXgCkPiIJIG1NK9oDr/+8k8NE=; b=WzY/O+2PgRH6T5PnSAE8HkBrko9o8m+YXhIu3dMBSuUgw5z/Mvsbd3Au 0CMCNuc8oBkMXJJqdXWlQkTiDhV7tRH89KAWwJ6UuHEtmPySs8v+ld5X+ ZVo5K/SH+kcaz2Lt9rZJmtfWuUHuIQ5M4gmlE9UeoTnrNzMaAbDigFO0E 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMCGmlCtJXG+/2dsb2JhbABEw2CBCIIeAQEBAwEBAQEPASc0CxACAQgiFBAnCyUCBA4FCBqHYgYLnDKgIQSMDYVmYQOkVIFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,730,1344211200"; d="scan'208";a="139814983" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 07 Nov 2012 16:07:34 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA7G7YeW032614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 16:07:34 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 10:07:34 -0600 From: "JP Vasseur (jvasseur)" To: "Charles E. Perkins" Thread-Topic: [manet] Stability and optional features in AODVv2 Thread-Index: AQHNvQH/WUlxqiiJhkCOhUxOXCsn7A== Date: Wed, 7 Nov 2012 16:07:33 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77220606AE@xmb-rcd-x02.cisco.com> References: <509A83D5.1020600@computer.org> In-Reply-To: <509A83D5.1020600@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.113.170] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--33.655100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <8F0BBAC2CDC17B4ABF5CA2EB4AC4BDF5@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: Re: [manet] Stability and optional features in AODVv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:07:37 -0000 Hi Charlie, I carefully looked at these options and I do think that we should be carefu= l not adding any more indeed, although I could not find options that we should a priori remove. B= ut may be should we=20 do the exercise of the looking at them one by one and discuss on whether to= keep them or not ? Thanks. JP. On Nov 7, 2012, at 10:52 AM, Charles E. Perkins wrote: >=20 > Hello folks, >=20 > The AODVv2 specification has certain optional features; each > one is in the current specification for pretty good reasons. > I believe that once these optional features are completed, > and modified according to WG consensus, it is likely that no > other optional features will be included. If there is WG consensus > for removing some of the optional features, that is also fine > of course; as yet another alternative, a feature could be moved > to another document. >=20 > The exception would be to allow for alternate metrics. > I have a proposal for that, which I will propose to the list > shortly by way of raising an issue on the issue tracker. >=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Wed Nov 7 08:53:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D45A21F88EE for ; Wed, 7 Nov 2012 08:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.665 X-Spam-Level: X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TQF7L8P1YUh for ; Wed, 7 Nov 2012 08:53:13 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA0521F8C85 for ; Wed, 7 Nov 2012 08:53:13 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so1971736vbb.31 for ; Wed, 07 Nov 2012 08:53:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1t+UmTs+7mNcHn5NTEfjVKPF8p2san+ZLjjtGAZVnAA=; b=uoLpxnuxW9vtQ3vNLsil2ILPpFM8H1ak1PpSdsrxY4/RbnUbMJ7XEaNdmXicz7QCqB 7BlPWdN3cSs6NH2wMFRcRzOmsybKj5Ek3A+vakssJGPZuiy7PvXNZyumcbGobAWzPJEY 2/djOQG3055D1a2j14+6PQCXVCLmquxoVWs+g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=1t+UmTs+7mNcHn5NTEfjVKPF8p2san+ZLjjtGAZVnAA=; b=pghsgLBVgxs2bvbXCUPs2E9t2OpOMyEJ1kj5yUR2m8jXdzcKt0O8uDvwOFQGzaUGi0 OkA/ufXSyOggXgiRIa0PNoDR3VNOE4PgbBiaDp3FfQHp/KGNM+Jkw5Dts8g0oBOFQMOJ Rggr3+R1YLKthjCO7aLxybQnOWNHHA+DyoNbp4qHIBkaZ6DZ21p2pyniU/pnvLjF7YCU 6u6S4Be9mETfqVqSYv5tBGJBQI6bRZsklisP41okR+U8xZqxL0F9ZrwoObmFBhblZKsy gdKFwzoKm6zBcN55sXCwWl0jXg5hjT0Yecw4X74fot3siH2+Q42A5zpVmMo4HspYEjKy KERg== MIME-Version: 1.0 Received: by 10.52.66.10 with SMTP id b10mr4054056vdt.71.1352307186926; Wed, 07 Nov 2012 08:53:06 -0800 (PST) Received: by 10.58.94.103 with HTTP; Wed, 7 Nov 2012 08:53:06 -0800 (PST) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722060637@xmb-rcd-x02.cisco.com> References: <20121107142822.12100.51447.idtracker@ietfa.amsl.com> <03B78081B371D44390ED6E7BADBB4A7722060637@xmb-rcd-x02.cisco.com> Date: Wed, 7 Nov 2012 11:53:06 -0500 Message-ID: From: Ulrich Herberg To: "JP Vasseur (jvasseur)" Content-Type: multipart/alternative; boundary=20cf3071cf1e8104a404cdea8dea X-Gm-Message-State: ALoCoQmZ2TOCii7on0iZefCelHj79AaePbCqLmmRbKi03K+wb4eFNonjOuTZcO9ySnI/oWBJQFpz Cc: "manet@ietf.org List" Subject: Re: [manet] Fwd: I-D Action: draft-herberg-lln-loadng-mib-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:53:16 -0000 --20cf3071cf1e8104a404cdea8dea Content-Type: text/plain; charset=ISO-8859-1 Hi JP, The answer is: it depends. Some MANET deployments may use SNMP, other, more constrained MANETs don't. For these more constrained networks, other protocols may be more suitable (or management may not be possible). Regard Ulrich On Wed, Nov 7, 2012 at 11:04 AM, JP Vasseur (jvasseur) wrote: > Dear Authors, > > Are you expecting to use SNMPv2 is constrained networks ? As you know, > the IETF came up with different ways of managing > networks that are indeed constrained (CoRE). > > Thanks. > > JP. > > Begin forwarded message: > > *From: * > *Subject: **I-D Action: draft-herberg-lln-loadng-mib-01.txt* > *Date: *November 7, 2012 9:28:22 AM EST > *To: * > *Reply-To: * > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Definition of Managed Objects for the Lightweight > On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) > Author(s) : Ulrich Herberg > Robert G. Cole > Thomas Heide Clausen > Filename : draft-herberg-lln-loadng-mib-01.txt > Pages : 43 > Date : 2012-11-07 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes objects for configuring parameters of the > Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next > Generation (LOADng) process on a router. The MIB module defined in > this memo, denoted LOADng-MIB, also reports state. While LOADng is > layer agnostic and can be run with different address families (e.g., > on L2 using MAC addreses, or on L3 using IP addresss), this MIB > module assumes that LOADng is used on L3, and uses only IPv4/IPv6 > addresses. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-herberg-lln-loadng-mib > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-herberg-lln-loadng-mib-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-herberg-lln-loadng-mib-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --20cf3071cf1e8104a404cdea8dea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi JP,

The answer is: it depends. Some MANET deployments= may use SNMP, other, more constrained MANETs don't. For these more con= strained networks, other protocols may be more suitable (or management may = not be possible).

Regard
Ulrich

On Wed, Nov 7, 2012 at 11:04 AM, JP Vasseur (jvasseur) <jvasseur@cisco= .com> wrote:
Dear Authors,

Are you expecting to use SNMPv2 is constrained networks ? As you know,= the IETF came up with different ways of managing=A0
networks that are indeed constrained (CoRE).

Thanks.

JP.

Begin forwarded message:

Subject: I-D Action: draft-herberg-lln-loadng-mib-01.txt
Date: November 7, 2012 9:28:22 AM EST


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


Title =A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0: Definition of Managed Objects for the Lightweight On-demand Ad hoc = Distance-vector Routing Protocol - Next Generation (LOADng)
Author(s) =A0=A0=A0=A0=A0=A0: U= lrich Herberg
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Robert G. Cole
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Thomas Heide Clausen
Filename =A0=A0=A0=A0=A0=A0=A0:= draft-herberg-lln-loadng-mib-01.txt
Pages =A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0: 43
Date =A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0: 2012-11-07

Abstract:
=A0=A0This memo defines a portion of the Management Information Base (MIB)<= br> =A0=A0for use with network management protocols in the Internet community.<= br> =A0=A0In particular, it describes objects for configuring parameters of the=
=A0=A0Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next<= br> =A0=A0Generation (LOADng) process on a router. =A0The MIB module defined in=
=A0=A0this memo, denoted LOADng-MIB, also reports state. =A0While LOADng is=
=A0=A0layer agnostic and can be run with different address families (e.g.,<= br> =A0=A0on L2 using MAC addreses, or on L3 using IP addresss), this MIB
=A0=A0module assumes that LOADng is used on L3, and uses only IPv4/IPv6
=A0=A0addresses.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-herberg-lln-loadng-= mib

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-herberg-lln-loadng-mib-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-herberg-lln-= loadng-mib-01


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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--20cf3071cf1e8104a404cdea8dea-- From trac+manet@trac.tools.ietf.org Wed Nov 7 08:57:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0830021F8C77 for ; Wed, 7 Nov 2012 08:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgwoDXXKUZwb for ; Wed, 7 Nov 2012 08:57:05 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 116D121F8C2A for ; Wed, 7 Nov 2012 08:57:05 -0800 (PST) Received: from localhost ([127.0.0.1]:53192 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TW8vn-0005qE-3P; Wed, 07 Nov 2012 17:57:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "manet issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 07 Nov 2012 16:56:47 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/8 Message-ID: <061.01e84a8c55d727234bea54462c8094cf@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: [manet] #8: HopCount and alternate metrics in AODVv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:57:06 -0000 #8: HopCount and alternate metrics in AODVv2 Most of the language in the current specification for route metrics is actually specific to !HopCount. It is proposed to rename existing metric fields to actually *be* !HopCount, to improve clarity. Following common practice up until now, the default route metric for AODVv2 is !HopCount. Nevertheless, the document should allow for alternate metrics to be used. To be compatible with RFC 5444 and the current reactive features, the following design guidelines are suggested. * a new AddTLV of type "metric" should be supported. The metric AddTLV would supply metric values for each of the addresses in the !AddBlk * a metric 'type' should be supplied in a msg-TLV Whether or not the metric belongs in AODVv2 this year is a matter for discussion. The design can be quite straightforward, requiring only an IANA registry for "metric type". Given the flexibiity of RFC 5444 msg- header format, very general metrics could be supported. Metric type '0' would be reserved for HopCount. -- --------------------------------+------------------------------------- Reporter: charliep@… | Owner: Charlie Perkins Type: enhancement | Status: new Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Keywords: route metric, hop count --------------------------------+------------------------------------- Ticket URL: manet From jvasseur@cisco.com Wed Nov 7 11:05:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71BA621F8C4F for ; Wed, 7 Nov 2012 11:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.46 X-Spam-Level: X-Spam-Status: No, score=-10.46 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTaXWgyJLW6a for ; Wed, 7 Nov 2012 11:05:30 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A9E2D21F8B8E for ; Wed, 7 Nov 2012 11:05:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2416; q=dns/txt; s=iport; t=1352315129; x=1353524729; h=from:to:cc:subject:date:message-id:mime-version; bh=2l4Gl8VDDKJXT87Def32VV/LsRvI25g+60jAHoa5dVk=; b=jnWz1c3BNErrtSkzYy9gd2qhbKk7Yeba4ICG2uUTQ54QoHbx2yqCJxxj Y7a/EOVV/aEgdZ9Xss6g0B1zYodHK7uxkbWRYOPbOR7xuYp3DIxeg6vqf 1NHe5LbyNG6vWmzTC6nKFHutRhIMjoLPJGJ6dNqxPJuZ3benJDOEp8AnF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAK2wmlCtJV2a/2dsb2JhbABEgknBH4EIgiABBBIBZhIBDAEdVicEDg0ah2icNqA4kXNhA6RUgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,731,1344211200"; d="scan'208,217";a="139851724" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 07 Nov 2012 19:05:29 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA7J5QiD030209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 19:05:26 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 13:05:26 -0600 From: "JP Vasseur (jvasseur)" To: Thomas Heide Clausen Thread-Topic: As pointed out during the WG meeting ... Thread-Index: AQHNvRrYNZvy8gQOe0utSe7gjdGJfg== Date: Wed, 7 Nov 2012 19:05:25 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77220614D0@xmb-rcd-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.112.172] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--20.624000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77220614D0xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: [manet] As pointed out during the WG meeting ... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 19:05:32 -0000 --_000_03B78081B371D44390ED6E7BADBB4A77220614D0xmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since you mentioned that the assumption was not there, please refer to A LOADng Router does not maintain a precursor list, thus when forwarding of a data packet to the recorded next hop on the route to the destination fails, an RERR is sent only to the originator of that data packet. The rationale for this simplification is an assumption that few overlapping routes are in use concurrently in a given network. This is why I was proposing to clearly spell out the assumption on traffic = profiles. --_000_03B78081B371D44390ED6E7BADBB4A77220614D0xmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Since you mentioned that the assumption was not there, please refer to 

A LOADng Router does not maintain a precu=
rsor list, thus when
      forwarding of a data packet to the recorded next hop on the route
      to the destination fails, an RERR is sent only to the originator
      of that data packet.  The rationale for this simplification is an
      assumption that few overlapping routes are in use concurrently in
      a given network.

This is why I was proposing to clearly spell out the assumption on tra= ffic profiles.
--_000_03B78081B371D44390ED6E7BADBB4A77220614D0xmbrcdx02ciscoc_-- From alexandru.petrescu@gmail.com Wed Nov 7 11:38:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20DA21F8B75 for ; Wed, 7 Nov 2012 11:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.209 X-Spam-Level: X-Spam-Status: No, score=-10.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+As4ywTHUHo for ; Wed, 7 Nov 2012 11:38:48 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 230B321F8B74 for ; Wed, 7 Nov 2012 11:38:47 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA7Jckaw010785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Nov 2012 20:38:46 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA7JckVX024075; Wed, 7 Nov 2012 20:38:46 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-49.intra.cea.fr [132.166.201.49]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA7JcVxY023372; Wed, 7 Nov 2012 20:38:45 +0100 Message-ID: <509AB8B7.3080203@gmail.com> Date: Wed, 07 Nov 2012 20:38:31 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Anupam Jamatia References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: manet@ietf.org Subject: Re: [manet] VANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 19:38:49 -0000 Dear Anupam, I understand an Road Side Unit (RSU) would send data to On-Board Units (OBUs) which would then relay from vehicle to vehicle, and back to source. I suppose a packet would hold a field (maybe the Hop Limit field) that gets decremented or incremented as packets go. And finally the src would examine this packet to find the count. Another means, which 'traceroute' uses, is for the src to send packets in sequence: one to the first hop, another to the second hop, and so on, until reaching the destination. For each of these packets it expects a reply. There are as many vehicles as there are replies. It is very easy to set up a testbed and try some of these techniques. Suffices it of a few laptops, wireless interfaces and a unix software distribution like linux, bsd or android. But what is very difficult is to set up an IP addressing architecture plan and implement it in these laptops, albeit manually first. And also see how the IP subnets are formed between each of these laptops. Hope this helps, Alex Le 05/11/2012 17:47, Anupam Jamatia a écrit : > | Henning asked about context of your question - please provide more. > | Something like - is this simulation with ns or protocol > implementation? | Is it for a deployment of WAVE? What is WAVE in > your perspective? Is | there a list of primitive WAVE operations > that you wonder how to combine? \-- > > Hi , Actually I am trying to figure out the possible ways to count > vehicles or to know the actual position when the vehicles are in > stopping position in VANET using WAVE technologies. One possible > ways is from RSU to OBU a PDU can be sent and then OBU to OBU until > the last vehicle . Every vehicle periodically advertises this > information to its neighbor vehicles and a vehicle is thus informed > about all other vehicles located within its direct communication > range. If a vehicle intends to send data to a known target > geographic location, it chooses another vehicle as a message relay, > which is located in the direction towards the target position. The > same procedure is executed by every vehicle on the multihop path > until the destination is reached and then again from Destination to > source.This can be require to implement in parking booking. ANY OTHER > WAY TO COUNT ? Next generation vehicles are expected to exchange > information not only beyond their immediate surroundings and > line-of-sight with other vehicles, but also with the road > infrastructure and Internet databases. Not yet decided the simulation > with ns or other tools like NCTUns. I am very novice in this field. > > Regards -- AJ From charliep@computer.org Wed Nov 7 12:13:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73E821F8904 for ; Wed, 7 Nov 2012 12:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh-J5jNoolIF for ; Wed, 7 Nov 2012 12:13:47 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9A221F8A13 for ; Wed, 7 Nov 2012 12:13:47 -0800 (PST) Received: from [130.129.66.42] by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TWC0Q-00044b-7H; Wed, 07 Nov 2012 15:13:46 -0500 Message-ID: <509AC0F4.5020209@computer.org> Date: Wed, 07 Nov 2012 12:13:40 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "JP Vasseur (jvasseur)" References: <03B78081B371D44390ED6E7BADBB4A77220614D0@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77220614D0@xmb-rcd-x02.cisco.com> Content-Type: multipart/alternative; boundary="------------080500070901000005090101" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad861355c5fd47e79d952934c6e6904af19c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.66.42 Cc: "manet@ietf.org List" Subject: Re: [manet] As pointed out during the WG meeting ... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 20:13:47 -0000 This is a multi-part message in MIME format. --------------080500070901000005090101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello folks, Regarding precursors, I'd also like to point out that AODVv2 specifies that RERR be sent for *active routes*. And, moreover, if a RERR is sent out for a idle route, there is no reason that an inactive node would generate a RREQ because there would be no traffic to trigger that action. Regards, Charlie P. On 11/7/2012 11:05 AM, JP Vasseur (jvasseur) wrote: > Since you mentioned that the assumption was not there, please refer to > > A LOADng Router does not maintain a precursor list, thus when > forwarding of a data packet to the recorded next hop on the route > to the destination fails, an RERR is sent only to the originator > of that data packet.*The rationale for this simplification is an > assumption that few overlapping routes are in use concurrently in > a given network. > * > > This is why I was proposing to clearly spell out the assumption on > traffic profiles. > -- Regards, Charlie P. --------------080500070901000005090101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello folks,

Regarding precursors, I'd also like to point out that AODVv2 specifies
that RERR be sent for *active routes*.  And, moreover, if a RERR is
sent out for a idle route, there is no reason that an inactive node
would generate a RREQ because there would be no traffic to trigger
that action.

Regards,
Charlie P.


On 11/7/2012 11:05 AM, JP Vasseur (jvasseur) wrote:
Since you mentioned that the assumption was not there, please refer to 

A LOADng Router does not maintain a precursor list, thus when
      forwarding of a data packet to the recorded next hop on the route
      to the destination fails, an RERR is sent only to the originator
      of that data packet.  The rationale for this simplification is an
      assumption that few overlapping routes are in use concurrently in
      a given network.

This is why I was proposing to clearly spell out the assumption on traffic profiles.



-- 
Regards,
Charlie P.
--------------080500070901000005090101-- From jvasseur@cisco.com Wed Nov 7 13:24:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02A621F8B02 for ; Wed, 7 Nov 2012 13:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.481 X-Spam-Level: X-Spam-Status: No, score=-10.481 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFfxtbGiEy5S for ; Wed, 7 Nov 2012 13:24:21 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1D321F8AF0 for ; Wed, 7 Nov 2012 13:24:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4445; q=dns/txt; s=iport; t=1352323461; x=1353533061; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/roWnfhSbtVbnOh60zaXTnERgslJ/fM8BhniJcHGFws=; b=K5A6hL8HwzbQrprQFw/oz/uqFyWy5jp783S8deBhYcbXf0NcIDAeYiWx Rea/w5tY17YGX1o8HN20vxg1Xt5GRrUclQhokNafRNMAjDtELbhXK/PwQ V4lgadKVaCK6KV6IfS8Bf0tBxggMiMEJq9Nf2I7hRaYfrIa861GOX8Q2z s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGrQmlCtJXG9/2dsb2JhbABEgkm9YYNAgQiCHwEBBBIBZhACAQgEHiQyJQIEDg0ah2icUaAvjA2FZmEDiCWcL4Frgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,732,1344211200"; d="scan'208,217";a="136894322" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 07 Nov 2012 21:24:15 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA7LOFTc032181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 21:24:15 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 15:24:14 -0600 From: "JP Vasseur (jvasseur)" To: "Charles E. Perkins" Thread-Topic: [manet] As pointed out during the WG meeting ... Thread-Index: AQHNvRrYNZvy8gQOe0utSe7gjdGJfg== Date: Wed, 7 Nov 2012 21:24:13 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722061A84@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A77220614D0@xmb-rcd-x02.cisco.com> <509AC0F4.5020209@computer.org> In-Reply-To: <509AC0F4.5020209@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.90.153] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--29.342700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722061A84xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: Re: [manet] As pointed out during the WG meeting ... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 21:24:22 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7722061A84xmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Right and as routes start to overlap, which is the case in many of these ne= tworks (observing traffic patterns) the lack of a precursor lists get problematic IMO, leading to many stales routes on = a potentially large number of routers (some of these network may have up to 20 hops). On Nov 7, 2012, at 3:13 PM, Charles E. Perkins wrote: Hello folks, Regarding precursors, I'd also like to point out that AODVv2 specifies that RERR be sent for *active routes*. And, moreover, if a RERR is sent out for a idle route, there is no reason that an inactive node would generate a RREQ because there would be no traffic to trigger that action. Regards, Charlie P. On 11/7/2012 11:05 AM, JP Vasseur (jvasseur) wrote: Since you mentioned that the assumption was not there, please refer to A LOADng Router does not maintain a precursor list, thus when forwarding of a data packet to the recorded next hop on the route to the destination fails, an RERR is sent only to the originator of that data packet. The rationale for this simplification is an assumption that few overlapping routes are in use concurrently in a given network. This is why I was proposing to clearly spell out the assumption on traffic = profiles. -- Regards, Charlie P. --_000_03B78081B371D44390ED6E7BADBB4A7722061A84xmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <65DE9FCA99563E4998343FA1B8D3E819@cisco.com> Content-Transfer-Encoding: quoted-printable Right and as routes start to overlap, which is the case in many of these ne= tworks (observing traffic patterns) the lack 
of a precursor lists get problematic IMO, leading to many stales route= s on a potentially large number of routers (some
of these network may have up to 20 hops).

On Nov 7, 2012, at 3:13 PM, Charles E. Perkins wrote:


Hello folks,

Regarding precursors, I'd also like to point out that AODVv2 specifies
that RERR be sent for *active routes*.  And, moreover, if a RERR is sent out for a idle route, there is no reason that an inactive node
would generate a RREQ because there would be no traffic to trigger
that action.

Regards,
Charlie P.


On 11/7/2012 11:05 AM, JP Vasseur (jvasseur) wrote:
Since you mentioned that the assumption was not there, please refer to 

A LOADng Router does not maintain a precursor list, thus when
      forwarding of a data packet to the recorded next hop on the route
      to the destination fails, an RERR is sent only to the originator
      of that data packet.  The rationale for this simplification is an
      assumption that few overlapping routes are in use concurrently in
      a given network.

This is why I was proposing to clearly spell out the assumption on tra= ffic profiles.



--=20
Regards,
Charlie P.

--_000_03B78081B371D44390ED6E7BADBB4A7722061A84xmbrcdx02ciscoc_-- From jvasseur@cisco.com Wed Nov 7 13:29:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A053C21F8B35 for ; Wed, 7 Nov 2012 13:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.484 X-Spam-Level: X-Spam-Status: No, score=-10.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5nF1XuKkwoC for ; Wed, 7 Nov 2012 13:29:51 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D9A2721F8B22 for ; Wed, 7 Nov 2012 13:29:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2365; q=dns/txt; s=iport; t=1352323791; x=1353533391; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=p5ifTy6lR48dExb6vdajTYz3l3gjSBUCCrVrxYer5YA=; b=BBpb4eBf2dEwDqYsfIeOC9bWkyEfI3+trf1bYZoVaaCX4q1A5j0HUoJu 0RktAhcxg9QS7QLyuKGwLjxSC3sLoqZL3d3JnWQb12ybHQSQmpvgZenbo cmdPApdjvjOZp9ZK/A/Pf8XgezTJ7pyx7LyZl2dQB3c6ONDh/7kNLdmUP 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAHSmlCtJXG+/2dsb2JhbABEw2qBCIIfAQEEAQEBDwFbGwIBCCIkJwslAgQBEggah2gLnEagL4wNJIVCYQOXF4oagyOBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,732,1344211200"; d="scan'208";a="139681461" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 07 Nov 2012 21:29:49 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA7LTnil017146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 21:29:49 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 15:29:49 -0600 From: "JP Vasseur (jvasseur)" To: "Charles E. Perkins" , "manet@ietf.org List" Thread-Topic: [manet] #8: HopCount and alternate metrics in AODVv2 Thread-Index: AQHNvS8DiwQSYcouoEO+h4Idk5lwTQ== Date: Wed, 7 Nov 2012 21:29:48 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722061AF6@xmb-rcd-x02.cisco.com> References: <061.01e84a8c55d727234bea54462c8094cf@trac.tools.ietf.org> In-Reply-To: <061.01e84a8c55d727234bea54462c8094cf@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.90.153] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--43.693200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] #8: HopCount and alternate metrics in AODVv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 21:29:51 -0000 Hi Charlie, On Nov 7, 2012, at 11:56 AM, manet issue tracker wrote: > #8: HopCount and alternate metrics in AODVv2 >=20 > Most of the language in the current specification for route metrics is > actually specific to !HopCount. It is proposed to rename existing metric > fields to actually *be* !HopCount, to improve clarity. >=20 > Following common practice up until now, the default route metric for > AODVv2 is !HopCount. Nevertheless, the document should allow for > alternate metrics to be used. To be compatible with RFC 5444 and the > current reactive features, the following design guidelines are suggested. > * a new AddTLV of type "metric" should be supported. The metric AddTLV > would supply metric values for each of the addresses in the !AddBlk > * a metric 'type' should be supplied in a msg-TLV >=20 > Whether or not the metric belongs in AODVv2 this year is a matter for > discussion. The design can be quite straightforward, requiring only an > IANA registry for "metric type". Given the flexibiity of RFC 5444 msg- > header format, very general metrics could be supported. Metric type '0' > would be reserved for HopCount. Completely agreeing. Although I love simplicity with only hop counts, it tu= rns out not=20 to always be the most relevant metric in MANET. It is not so rare to see sh= orter delays on longer paths in terms of hop counts. Same comment for Packet Delivery Ra= tio (some link may have really high ETX!). Not suggesting to adopt a similar model as in RFC6551, but adding a bit of = flexibility will help in the future, even if we start with something very simple. >=20 > --=20 > --------------------------------+------------------------------------- > Reporter: charliep@=85 | Owner: Charlie Perkins > Type: enhancement | Status: new > Priority: major | Milestone: > Component: dymo | Version: > Severity: Active WG Document | Keywords: route metric, hop count > --------------------------------+------------------------------------- >=20 > Ticket URL: > manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Wed Nov 7 13:39:24 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9793C21F8AD3 for ; Wed, 7 Nov 2012 13:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4C4DbAJyE6z7 for ; Wed, 7 Nov 2012 13:39:23 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id A23F321F8C42 for ; Wed, 7 Nov 2012 13:39:23 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so907334dan.31 for ; Wed, 07 Nov 2012 13:39:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dxTgSjpXatMNV+pIu6khgtfxNpv5T9kP4Sp62ywLoCs=; b=GlMMLIfeD1w70WFKzqwrRu0kyJiLchMavUAiM8fjh+uW8yiX++E+WoMLZXG5tM82eK jIrEaUy2iiHMP+vgW4TKtF1+/7N9bEsPyCR7PMfr30MBr2e8u6dP7xvFt0Cve0INC0O0 OLN0vbQODOVxa8Jl5rlCMLXzHT7Pd7MgAcjG9F5f1jZNSbNCyH47O+dfPzDsgLJw2+MK TtOSBgdBUGLTul9mwJdwhmWsXbWjY5qwfMHTIYm2rbBM/m/9rl14POHI6odtDzrH7dJB PQxIEqS5//kCvefz6gaIi9oIu2x0wbGJyYuWGyQ21YcwojApcGtAdRCxYIqefZL1H1Ga K6Rg== Received: by 10.68.233.196 with SMTP id ty4mr17781780pbc.23.1352324363472; Wed, 07 Nov 2012 13:39:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Wed, 7 Nov 2012 13:39:03 -0800 (PST) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722061AF6@xmb-rcd-x02.cisco.com> References: <061.01e84a8c55d727234bea54462c8094cf@trac.tools.ietf.org> <03B78081B371D44390ED6E7BADBB4A7722061AF6@xmb-rcd-x02.cisco.com> From: Henning Rogge Date: Wed, 7 Nov 2012 22:39:03 +0100 Message-ID: To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org List" Subject: Re: [manet] #8: HopCount and alternate metrics in AODVv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 21:39:24 -0000 On Wed, Nov 7, 2012 at 10:29 PM, JP Vasseur (jvasseur) wrote: > Hi Charlie, > > On Nov 7, 2012, at 11:56 AM, manet issue tracker wrote: > >> #8: HopCount and alternate metrics in AODVv2 >> >> Most of the language in the current specification for route metrics is >> actually specific to !HopCount. It is proposed to rename existing metric >> fields to actually *be* !HopCount, to improve clarity. >> >> Following common practice up until now, the default route metric for >> AODVv2 is !HopCount. Nevertheless, the document should allow for >> alternate metrics to be used. To be compatible with RFC 5444 and the >> current reactive features, the following design guidelines are suggested. >> * a new AddTLV of type "metric" should be supported. The metric AddTLV >> would supply metric values for each of the addresses in the !AddBlk >> * a metric 'type' should be supplied in a msg-TLV >> >> Whether or not the metric belongs in AODVv2 this year is a matter for >> discussion. The design can be quite straightforward, requiring only an >> IANA registry for "metric type". Given the flexibiity of RFC 5444 msg- >> header format, very general metrics could be supported. Metric type '0' >> would be reserved for HopCount. > > Completely agreeing. Although I love simplicity with only hop counts, it turns out not > to always be the most relevant metric in MANET. In my experience Hopcount metrics don't work well in wireless networks unless you have very specific links. Using hopcount as a metric means you optimize for LONG links, which are often the ones that do not work reasonable well. Without a well thought hysteresis your network might just dissolve into a huge mess, especially for multirate networks like IEEE802.11. Saying "hopcount is the most relevant metric in MANET" is at best shady... and at worst just wrong. > It is not so rare to see shorter delays > on longer paths in terms of hop counts. Same comment for Packet Delivery Ratio (some > link may have really high ETX!). > Not suggesting to adopt a similar model as in RFC6551, but adding a bit of flexibility will > help in the future, even if we start with something very simple. I agree that not specifying the metric is a good idea (similar to the way it has been done in OLSRv2), but hopcount only is a poor choice for a metric. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From jvasseur@cisco.com Wed Nov 7 13:40:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B07C21F8C3E for ; Wed, 7 Nov 2012 13:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.465 X-Spam-Level: X-Spam-Status: No, score=-10.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huDBUHPhj13W for ; Wed, 7 Nov 2012 13:40:10 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACBB21F8AD3 for ; Wed, 7 Nov 2012 13:40:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11055; q=dns/txt; s=iport; t=1352324410; x=1353534010; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fFINXyNfs5WhokA9bFNtIaR0IgHwNtRG8btUTeSY99E=; b=arM/85/Q7MhsWc42BH64/5UeMqDzqREItp6wxQPKimPxkCTxIKEDXNwd pSg/P8Lvq1GEhIGSDWc8PAdNLMbzeQVBYmC2ICR1WOKf4vxtIT0PHLG0C FgNhj/f/8+xkdeHqn7syyqcuvWyHyQRAoJBpZcxMo3euWHSDbAcjwcHAZ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAO3TmlCtJXHB/2dsb2JhbABEun+Ia4EIghoEAQEBBAEBAQ8BWwsQAgEIEQMBAgsdBycLFAkIAgQOBQgBCw6FJweCHhwLnESgL4wNhWZhA4gljnKKGoMjgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,732,1344211200"; d="scan'208,217";a="136899012" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 07 Nov 2012 21:40:10 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA7Le9pT008487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 21:40:09 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 15:40:09 -0600 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] I-D Action: draft-herberg-lln-loadng-mib-01.txt Thread-Index: AQHNvQGcakeklW33hUCFwBgPpdiMBg== Date: Wed, 7 Nov 2012 21:40:09 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722061BAC@xmb-rcd-x02.cisco.com> References: <20121107142822.12100.51447.idtracker@ietfa.amsl.com> <03B78081B371D44390ED6E7BADBB4A7722060637@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.90.153] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--47.546900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722061BACxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: Re: [manet] I-D Action: draft-herberg-lln-loadng-mib-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 21:40:12 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7722061BACxmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ulrich, On Nov 7, 2012, at 11:53 AM, Ulrich Herberg wrote: Hi JP, The answer is: it depends. Some MANET deployments may use SNMP, other, more= constrained MANETs don't. JP> Absolutely. For these more constrained networks, other protocols may be more suitable (= or management may not be possible). JP> It might be worth spelling it out clearly - happy to help. Thanks. JP. Regard Ulrich On Wed, Nov 7, 2012 at 11:04 AM, JP Vasseur (jvasseur) > wrote: Dear Authors, Are you expecting to use SNMPv2 is constrained networks ? As you know, the = IETF came up with different ways of managing networks that are indeed constrained (CoRE). Thanks. JP. Begin forwarded message: From: > Subject: I-D Action: draft-herberg-lln-loadng-mib-01.txt Date: November 7, 2012 9:28:22 AM EST To: > Reply-To: > A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Definition of Managed Objects for the Lightweight On-dema= nd Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) Author(s) : Ulrich Herberg Robert G. Cole Thomas Heide Clausen Filename : draft-herberg-lln-loadng-mib-01.txt Pages : 43 Date : 2012-11-07 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) process on a router. The MIB module defined in this memo, denoted LOADng-MIB, also reports state. While LOADng is layer agnostic and can be run with different address families (e.g., on L2 using MAC addreses, or on L3 using IP addresss), this MIB module assumes that LOADng is used on L3, and uses only IPv4/IPv6 addresses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-herberg-lln-loadng-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-herberg-lln-loadng-mib-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-herberg-lln-loadng-mib-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A7722061BACxmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Ulrich,

On Nov 7, 2012, at 11:53 AM, Ulrich Herberg wrote:

Hi JP,

The answer is: it depends. Some MANET deployments may use SNMP, other,= more constrained MANETs don't.

JP> Absolutely.

For these more constrained networks, other protocols may be more suita= ble (or management may not be possible).


JP> It might be worth spelling it out clearly - happy to help.

Thanks.

JP.

Regard
Ulrich

On Wed, Nov 7, 2012 at 11:04 AM, JP Vasseur (jva= sseur) <jvasseur@cisco.= com> wrote:
Dear Authors,

Are you expecting to use SNMPv2 is constrained networks ? As you know,= the IETF came up with different ways of managing 
networks that are indeed constrained (CoRE).

Thanks.

JP.

Begin forwarded message:

Subject: I-D = Action: draft-herberg-lln-loadng-mib-01.txt
Date: Novembe= r 7, 2012 9:28:22 AM EST


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


Title     &= nbsp;     : Definition of Managed Objects for the = Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Genera= tion (LOADng)
Author(s)    &nb= sp;  : Ulrich Herberg
            &nb= sp;            = Robert G. Cole
            &nb= sp;            = Thomas Heide Clausen
Filename    &nbs= p;   : draft-herberg-lln-loadng-mib-01.txt
Pages     &= nbsp;     : 43
Date     &n= bsp;      : 2012-11-07

Abstract:
  This memo defines a portion of the Management Information Base = (MIB)
  for use with network management protocols in the Internet commu= nity.
  In particular, it describes objects for configuring parameters = of the
  Lightweight On-demand Ad hoc Distance-vector Routing Protocol -= Next
  Generation (LOADng) process on a router.  The MIB module d= efined in
  this memo, denoted LOADng-MIB, also reports state.  While = LOADng is
  layer agnostic and can be run with different address families (= e.g.,
  on L2 using MAC addreses, or on L3 using IP addresss), this MIB=
  module assumes that LOADng is used on L3, and uses only IPv4/IP= v6
  addresses.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-herberg-lln-loadng-= mib

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-herberg-lln-loadng-mib-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-herberg-lln-= loadng-mib-01


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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet



--_000_03B78081B371D44390ED6E7BADBB4A7722061BACxmbrcdx02ciscoc_-- From hrogge@googlemail.com Wed Nov 7 13:43:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A99521F8C36 for ; Wed, 7 Nov 2012 13:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjmKUeQmB7cS for ; Wed, 7 Nov 2012 13:43:52 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3211321F8AF0 for ; Wed, 7 Nov 2012 13:43:34 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so908708dan.31 for ; Wed, 07 Nov 2012 13:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sQQOe8kvPIHmWqXWJhVSP+HVeXVf/Jh+zpfRUEgiVF8=; b=wX8sGbjkT9At60X3jg2sTQ7mhuUJTlE6RyR4c6M4DDTSDs6TL5DHyiszx4RQin2VyK PQvzNUKt6J1ixTp7C+Y+jv0AoMP4ATh+7fwbRIYSphwdYy3x+Pkt4IgPGeI2p0BvHHW7 oToPBbmZviHz1FsAjNQivb1XoMaTSQWI1wcAnh2hjqxercIckh0CE4xZqje4oTf/aKyj vfadc5etgjG5RMlVUsOOKqdyh89a24xxcxaOvo71sqA76C4wkeIA0Nmg9OmH4aCm1Zmn hPfL5rHUT/HLeYKFvsdgPMxW1vi4BGzwwNiNMOYrdhjjscgQRKt6nkDOH9iKVFP/Brzu M+1g== Received: by 10.68.219.163 with SMTP id pp3mr17460276pbc.13.1352324614039; Wed, 07 Nov 2012 13:43:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Wed, 7 Nov 2012 13:43:13 -0800 (PST) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722061BAC@xmb-rcd-x02.cisco.com> References: <20121107142822.12100.51447.idtracker@ietfa.amsl.com> <03B78081B371D44390ED6E7BADBB4A7722060637@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7722061BAC@xmb-rcd-x02.cisco.com> From: Henning Rogge Date: Wed, 7 Nov 2012 22:43:13 +0100 Message-ID: To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org List" Subject: Re: [manet] I-D Action: draft-herberg-lln-loadng-mib-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 21:43:53 -0000 On Wed, Nov 7, 2012 at 10:40 PM, JP Vasseur (jvasseur) wrote: > Hi Ulrich, > > On Nov 7, 2012, at 11:53 AM, Ulrich Herberg wrote: > > Hi JP, > > The answer is: it depends. Some MANET deployments may use SNMP, other, more > constrained MANETs don't. > > JP> Absolutely. > > For these more constrained networks, other protocols may be more suitable > (or management may not be possible). > > JP> It might be worth spelling it out clearly - happy to help. It doesn't help that NetSNMP (which seems to be the default OpenSource SNMP implementation) is a messy and bloated thing either. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ulrich@herberg.name Wed Nov 7 14:27:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B8B21F8419 for ; Wed, 7 Nov 2012 14:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmRBSnHFx47k for ; Wed, 7 Nov 2012 14:27:15 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0D821F8422 for ; Wed, 7 Nov 2012 13:59:32 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so2242446vcb.31 for ; Wed, 07 Nov 2012 13:59:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=903NXkaM0fP2+D0VjYjld7ViD40iS2uoS/oDAloWaV8=; b=cL5nRI+jGItAKm0Z+db4HLNko5Pp8xbR6/y0vyMGnCv9NSZvmlJNdUG6JGmtYE08JM Kil4pWORvsRCntbspgvrqFLXm09LkwuCWRgJ2gFzGETussjit4/EySnfOXCGCEOgJWQ9 xpsRUWHiRwXeIsb57OepshDVuERoF2aV44cvI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=903NXkaM0fP2+D0VjYjld7ViD40iS2uoS/oDAloWaV8=; b=ObZGqI95HCH/xp4xAW8JY+1Ry3Et+hJlIDJYWAZtleLtbrGP9LZBKe/v1xgR4bzyCa Z8xTJnljOmVzpGRhMH9oQk9nOsmyOtAActgG1vv121VIEcLaRHv/LKqcuI7w352k49pw PPgFjHaQDmTRyKNG98ATYjrwM09XmTK5uerbP4spbYQUnGrZxZQR3Orx80S1Q3+QaWef BGNsyb04VoHosFoyDttGkHkvQeVWWdgh1Da9TQ46iLjBt4ff4R8Dju+A4qIz1B3Ffqce /RURBWYOqBt23w/O8UgFjgSOSNY36WM25DJ0staIB9vcOrcsY1exbIa9kNTD8NAuI56o obhg== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr4852482vdv.20.1352325571502; Wed, 07 Nov 2012 13:59:31 -0800 (PST) Received: by 10.58.94.103 with HTTP; Wed, 7 Nov 2012 13:59:31 -0800 (PST) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722061BAC@xmb-rcd-x02.cisco.com> References: <20121107142822.12100.51447.idtracker@ietfa.amsl.com> <03B78081B371D44390ED6E7BADBB4A7722060637@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7722061BAC@xmb-rcd-x02.cisco.com> Date: Wed, 7 Nov 2012 16:59:31 -0500 Message-ID: From: Ulrich Herberg To: "JP Vasseur (jvasseur)" Content-Type: multipart/alternative; boundary=bcaec50162bd4f635604cdeed5d1 X-Gm-Message-State: ALoCoQm5wBLtyDLjoJbSB9A8anWB38YdKtdGZFI7gbrGHBM/e9N1gBHpW7qGPOR6j3JWTvpZyYuf Cc: "manet@ietf.org List" Subject: Re: [manet] I-D Action: draft-herberg-lln-loadng-mib-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 22:27:16 -0000 --bcaec50162bd4f635604cdeed5d1 Content-Type: text/plain; charset=ISO-8859-1 Hi JP, similar to the other MIB documents, there will be a brief applicability statement section. Note that the MIB module itself represents an API, not a protocol. Most importantly, we need the MANET use case draft for having a detailed discussion on applicability/use cases etc. of management of MANETs. Best regards Ulrich On Wed, Nov 7, 2012 at 4:40 PM, JP Vasseur (jvasseur) wrote: > Hi Ulrich, > > On Nov 7, 2012, at 11:53 AM, Ulrich Herberg wrote: > > Hi JP, > > The answer is: it depends. Some MANET deployments may use SNMP, other, > more constrained MANETs don't. > > > JP> Absolutely. > > For these more constrained networks, other protocols may be more > suitable (or management may not be possible). > > > JP> It might be worth spelling it out clearly - happy to help. > > Thanks. > > JP. > > Regard > Ulrich > > On Wed, Nov 7, 2012 at 11:04 AM, JP Vasseur (jvasseur) > wrote: > >> Dear Authors, >> >> Are you expecting to use SNMPv2 is constrained networks ? As you know, >> the IETF came up with different ways of managing >> networks that are indeed constrained (CoRE). >> >> Thanks. >> >> JP. >> >> Begin forwarded message: >> >> *From: * >> *Subject: **I-D Action: draft-herberg-lln-loadng-mib-01.txt* >> *Date: *November 7, 2012 9:28:22 AM EST >> *To: * >> *Reply-To: * >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Definition of Managed Objects for the Lightweight >> On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) >> Author(s) : Ulrich Herberg >> Robert G. Cole >> Thomas Heide Clausen >> Filename : draft-herberg-lln-loadng-mib-01.txt >> Pages : 43 >> Date : 2012-11-07 >> >> Abstract: >> This memo defines a portion of the Management Information Base (MIB) >> for use with network management protocols in the Internet community. >> In particular, it describes objects for configuring parameters of the >> Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next >> Generation (LOADng) process on a router. The MIB module defined in >> this memo, denoted LOADng-MIB, also reports state. While LOADng is >> layer agnostic and can be run with different address families (e.g., >> on L2 using MAC addreses, or on L3 using IP addresss), this MIB >> module assumes that LOADng is used on L3, and uses only IPv4/IPv6 >> addresses. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-herberg-lln-loadng-mib >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-herberg-lln-loadng-mib-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-herberg-lln-loadng-mib-01 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > > --bcaec50162bd4f635604cdeed5d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi JP,

similar to the other MIB documents, there will be= a brief applicability statement section. Note that the MIB module itself r= epresents an API, not a protocol.
Most importantly, we need the M= ANET use case draft for having a detailed discussion on applicability/use c= ases etc. of management of MANETs.

Best regards
Ulrich

On Wed, Nov 7, 2012 at 4:40 PM, JP Vasseur (jvasseur) <jvasseur@= cisco.com> wrote:
Hi Ulrich,

On Nov 7, 2012, at 11:53 AM, Ulrich Herberg wrote:

Hi JP,

The answer is: it depends. Some MANET deployments may use SNMP, other,= more constrained MANETs don't.

JP> Absolutely.

For these more constrained networks, other protocols may be more suita= ble (or management may not be possible).


JP> It might be worth spelling it out clearly - happy to help= .

Thanks.

JP.

Regard
Ulrich

On Wed, Nov 7, 2012 at 11:04 AM, JP Vasseur (jva= sseur) <jvasseur@cisco.= com> wrote:
Dear Authors,

Are you expecting to use SNMPv2 is constrained networks ? As you know,= the IETF came up with different ways of managing=A0
networks that are indeed constrained (CoRE).

Thanks.

JP.

Begin forwarded message:

Subject: I-D Action: draft-herberg-lln-loadng-mib-01.txt
Date: November 7, 2012 9:28:22 AM EST


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


Title =A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0: Definition of Managed Objects for the Lightweight On-demand Ad hoc = Distance-vector Routing Protocol - Next Generation (LOADng)
Author(s) =A0=A0=A0=A0=A0=A0: U= lrich Herberg
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Robert G. Cole
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Thomas Heide Clausen
Filename =A0=A0=A0=A0=A0=A0=A0:= draft-herberg-lln-loadng-mib-01.txt
Pages =A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0: 43
Date =A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0: 2012-11-07

Abstract:
=A0=A0This memo defines a portion of the Management Information Base (MIB)<= br> =A0=A0for use with network management protocols in the Internet community.<= br> =A0=A0In particular, it describes objects for configuring parameters of the=
=A0=A0Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next<= br> =A0=A0Generation (LOADng) process on a router. =A0The MIB module defined in=
=A0=A0this memo, denoted LOADng-MIB, also reports state. =A0While LOADng is=
=A0=A0layer agnostic and can be run with different address families (e.g.,<= br> =A0=A0on L2 using MAC addreses, or on L3 using IP addresss), this MIB
=A0=A0module assumes that LOADng is used on L3, and uses only IPv4/IPv6
=A0=A0addresses.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-herberg-lln-loadng-= mib

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-herberg-lln-loadng-mib-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-herberg-lln-= loadng-mib-01


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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet




--bcaec50162bd4f635604cdeed5d1-- From john.dowdell@cassidian.com Wed Nov 7 14:29:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1954221F8461 for ; Wed, 7 Nov 2012 14:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpoDwXwbXTqB for ; Wed, 7 Nov 2012 14:29:42 -0800 (PST) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 10A1D21F8477 for ; Wed, 7 Nov 2012 14:08:39 -0800 (PST) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 07 Nov 2012 23:08:35 +0100 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 7 Nov 2012 23:08:39 +0100 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Nov 2012 23:08:35 +0100 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Nov 2012 23:08:35 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDBD34.5E2D07F5" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 7 Nov 2012 22:08:32 -0000 Message-ID: <1B40484159234F4FB6FE11D4C2F408DE01FFCD0B@SUKNPT8108.cogent-dsn.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DLEP Lite? Thread-Index: Ac29NGzv94qiDydZR2mE2my3zmAILQ== From: "Dowdell, John" To: X-OriginalArrivalTime: 07 Nov 2012 22:08:35.0411 (UTC) FILETIME=[6E8A2A30:01CDBD34] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19348.002 X-TM-AS-Result: No--7.347700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: [manet] DLEP Lite? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 22:29:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDBD34.5E2D07F5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable @Stan and Will =20 Can you explain exactly what you mean by DLEP Lite, as mentioned in the dying moments of the WG meeting? Lite in what respect? I would not consider DLEP to be particularly overweight, so understanding exactly what you would intend to remove would be useful. =20 Also, IMHO it is enough work simply to define one DLEP, so having another one to choose from is not likely to help the radio manufacturers along the road to implementation. Having a mandatory core of DLEP, with optional extras, I can support. Having a further cut down edition means you then either have to know beforehand whether the radio supports full or Lite DLEP, or you have to be able to automatically query the radio to find out (which is a feature I suggested long, long ago, you may recall ....). =20 Regards =20 John =20 ------_=_NextPart_001_01CDBD34.5E2D07F5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

@Stan and Will

 

Can you explain exactly what you mean by DLEP Lite, = as mentioned in the dying moments of the WG meeting? Lite in what respect? = I would not consider DLEP to be particularly overweight, so understanding = exactly what you would intend to remove would be useful.

 

Also, IMHO it is enough work simply to define one = DLEP, so having another one to choose from is not likely to help the radio = manufacturers along the road to implementation. Having a mandatory core of DLEP, with optional extras, I can support. Having a further cut down edition means = you then either have to know beforehand whether the radio supports full or = Lite DLEP, or you have to be able to automatically query the radio to find = out (which is a feature I suggested long, long ago, you may recall = ….).

 

Regards

 

John

 

------_=_NextPart_001_01CDBD34.5E2D07F5-- From jvasseur@cisco.com Thu Nov 8 09:31:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21D021F84C4 for ; Thu, 8 Nov 2012 09:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.469 X-Spam-Level: X-Spam-Status: No, score=-10.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acJ-FXYjsM+z for ; Thu, 8 Nov 2012 09:31:31 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9F45921F84BF for ; Thu, 8 Nov 2012 09:31:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13185; q=dns/txt; s=iport; t=1352395891; x=1353605491; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=R4Xv0Sp091jjkWiNAuTXcIGymSJEhsZlcYeqsWDuMEM=; b=WSfU57A86FgP10Q+Y4g9WKNuLcGLPsxB+L91VABNGS9mA+s+cxKoDFqK Vf3ctyS1PXbDGytmuGUwk9PI/ave+b4VXM5Y5ro6TD3ef329YujLfyUnG UcMg03bS4A0Ok9SqGgzVX9UKQb3Ci1Cez7vGTchVihW5KkXgYQbPybRw0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAJbrm1CtJXG//2dsb2JhbABEumsBiGuBCIIaBAEBAQQBAQEPAVsLEAIBCBEDAQILHQcnCxQJCAIEDgUIAQsOhScHgh4cC5t1oDKMEoVmYQOXF4oZgyOBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,739,1344211200"; d="scan'208,217";a="137225838" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 08 Nov 2012 17:31:31 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA8HVVoY032208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Nov 2012 17:31:31 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 11:31:30 -0600 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] I-D Action: draft-herberg-lln-loadng-mib-01.txt Thread-Index: AQHNvQGcakeklW33hUCFwBgPpdiMBg== Date: Thu, 8 Nov 2012 17:31:30 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772206383F@xmb-rcd-x02.cisco.com> References: <20121107142822.12100.51447.idtracker@ietfa.amsl.com> <03B78081B371D44390ED6E7BADBB4A7722060637@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7722061BAC@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19348.005 x-tm-as-result: No--49.429600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772206383Fxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: Re: [manet] I-D Action: draft-herberg-lln-loadng-mib-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 17:31:33 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772206383Fxmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, On Nov 7, 2012, at 10:59 PM, Ulrich Herberg wrote: Hi JP, similar to the other MIB documents, there will be a brief applicability sta= tement section. Note that the MIB module itself represents an API, not a pr= otocol. Most importantly, we need the MANET use case draft for having a detailed di= scussion on applicability/use cases etc. of management of MANETs. In total agreement ! This was my last comment at the mic today =85 very acc= urate applicability statement is a MUST for both. Thanks. JP. Best regards Ulrich On Wed, Nov 7, 2012 at 4:40 PM, JP Vasseur (jvasseur) > wrote: Hi Ulrich, On Nov 7, 2012, at 11:53 AM, Ulrich Herberg wrote: Hi JP, The answer is: it depends. Some MANET deployments may use SNMP, other, more= constrained MANETs don't. JP> Absolutely. For these more constrained networks, other protocols may be more suitable (= or management may not be possible). JP> It might be worth spelling it out clearly - happy to help. Thanks. JP. Regard Ulrich On Wed, Nov 7, 2012 at 11:04 AM, JP Vasseur (jvasseur) > wrote: Dear Authors, Are you expecting to use SNMPv2 is constrained networks ? As you know, the = IETF came up with different ways of managing networks that are indeed constrained (CoRE). Thanks. JP. Begin forwarded message: From: > Subject: I-D Action: draft-herberg-lln-loadng-mib-01.txt Date: November 7, 2012 9:28:22 AM EST To: > Reply-To: > A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Definition of Managed Objects for the Lightweight On-dema= nd Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) Author(s) : Ulrich Herberg Robert G. Cole Thomas Heide Clausen Filename : draft-herberg-lln-loadng-mib-01.txt Pages : 43 Date : 2012-11-07 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) process on a router. The MIB module defined in this memo, denoted LOADng-MIB, also reports state. While LOADng is layer agnostic and can be run with different address families (e.g., on L2 using MAC addreses, or on L3 using IP addresss), this MIB module assumes that LOADng is used on L3, and uses only IPv4/IPv6 addresses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-herberg-lln-loadng-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-herberg-lln-loadng-mib-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-herberg-lln-loadng-mib-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A772206383Fxmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi,

On Nov 7, 2012, at 10:59 PM, Ulrich Herberg wrote:

Hi JP,

similar to the other MIB documents, there will be a brief applicabilit= y statement section. Note that the MIB module itself represents an API, not= a protocol.
Most importantly, we need the MANET use case draft for having a detail= ed discussion on applicability/use cases etc. of management of MANETs.


In total agreement ! This was my last comment at the mic today =85 ver= y accurate applicability statement is a MUST for both.

Thanks.

JP.

Best regards
Ulrich

On Wed, Nov 7, 2012 at 4:40 PM, JP Vasseur (jvas= seur) <jvasseur@cisco.= com> wrote:
Hi Ulrich,

On Nov 7, 2012, at 11:53 AM, Ulrich Herberg wrote:

Hi JP,

The answer is: it depends. Some MANET deployments may use SNMP, other,= more constrained MANETs don't.

JP> Absolutely.

For these more constrained networks, other protocols may be more suita= ble (or management may not be possible).


JP> It might be worth spelling it out clearly - happy to help.

Thanks.

JP.

Regard
Ulrich

On Wed, Nov 7, 2012 at 11:04 AM, JP Vasseur (jva= sseur) <jvasseur@cisco.= com> wrote:
Dear Authors,

Are you expecting to use SNMPv2 is constrained networks ? As you know,= the IETF came up with different ways of managing 
networks that are indeed constrained (CoRE).

Thanks.

JP.

Begin forwarded message:

Subject: I-D = Action: draft-herberg-lln-loadng-mib-01.txt
Date: Novembe= r 7, 2012 9:28:22 AM EST


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


Title     &= nbsp;     : Definition of Managed Objects for the = Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Genera= tion (LOADng)
Author(s)    &nb= sp;  : Ulrich Herberg
            &nb= sp;            = Robert G. Cole
            &nb= sp;            = Thomas Heide Clausen
Filename    &nbs= p;   : draft-herberg-lln-loadng-mib-01.txt
Pages     &= nbsp;     : 43
Date     &n= bsp;      : 2012-11-07

Abstract:
  This memo defines a portion of the Management Information Base = (MIB)
  for use with network management protocols in the Internet commu= nity.
  In particular, it describes objects for configuring parameters = of the
  Lightweight On-demand Ad hoc Distance-vector Routing Protocol -= Next
  Generation (LOADng) process on a router.  The MIB module d= efined in
  this memo, denoted LOADng-MIB, also reports state.  While = LOADng is
  layer agnostic and can be run with different address families (= e.g.,
  on L2 using MAC addreses, or on L3 using IP addresss), this MIB=
  module assumes that LOADng is used on L3, and uses only IPv4/IP= v6
  addresses.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-herberg-lln-loadng-= mib

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-herberg-lln-loadng-mib-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-herberg-lln-= loadng-mib-01


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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet





--_000_03B78081B371D44390ED6E7BADBB4A772206383Fxmbrcdx02ciscoc_-- From jvasseur@cisco.com Thu Nov 8 09:31:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25B721F84D3 for ; Thu, 8 Nov 2012 09:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.487 X-Spam-Level: X-Spam-Status: No, score=-10.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27B4aJc+qC+R for ; Thu, 8 Nov 2012 09:31:54 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 96EDF21F84D2 for ; Thu, 8 Nov 2012 09:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9365; q=dns/txt; s=iport; t=1352395910; x=1353605510; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nYd/UOJab1BlvnKDCViYX4e3npG1Djfe2uqsr8mQEy0=; b=cjfBs2fz/gwkIfmsnDWb9sASGhL3A2O9NwSqBXxiiS3qzfdqJchlQR0j 53/sUEGA+gUfKZcIXFl6ZR8VtRrQO6uZSfXhWzKJejHsUIi7MUevJpa3l nVDItuVn5IfESn0pxTZChKv4VfqUd/1TZhFSq/W7yeExM/RW3oCXXhi6H s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEPsm1CtJV2b/2dsb2JhbABEw1iBCIIfAQEEEgFmEAIBCA4UHQcyFBECBA4FCBqHaJt/oDKMEoVmYQOkU4Frgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,739,1344211200"; d="scan'208,217";a="140224898" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 08 Nov 2012 17:31:43 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA8HVhaq002720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Nov 2012 17:31:43 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 11:31:42 -0600 From: "JP Vasseur (jvasseur)" To: Henning Rogge Thread-Topic: [manet] #8: HopCount and alternate metrics in AODVv2 Thread-Index: AQHNvdbqgRYnb8NeCEiZjV2P2XI/aA== Date: Thu, 8 Nov 2012 17:31:42 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7722063860@xmb-rcd-x02.cisco.com> References: <061.01e84a8c55d727234bea54462c8094cf@trac.tools.ietf.org> <03B78081B371D44390ED6E7BADBB4A7722061AF6@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19348.005 x-tm-as-result: No--39.073900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722063860xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: Re: [manet] #8: HopCount and alternate metrics in AODVv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 17:31:55 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7722063860xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Nov 7, 2012, at 10:39 PM, Henning Rogge wrote: On Wed, Nov 7, 2012 at 10:29 PM, JP Vasseur (jvasseur) > wrote: Hi Charlie, On Nov 7, 2012, at 11:56 AM, manet issue tracker wrote: #8: HopCount and alternate metrics in AODVv2 Most of the language in the current specification for route metrics is actually specific to !HopCount. It is proposed to rename existing metric fields to actually *be* !HopCount, to improve clarity. Following common practice up until now, the default route metric for AODVv2 is !HopCount. Nevertheless, the document should allow for alternate metrics to be used. To be compatible with RFC 5444 and the current reactive features, the following design guidelines are suggested. * a new AddTLV of type "metric" should be supported. The metric AddTLV would supply metric values for each of the addresses in the !AddBlk * a metric 'type' should be supplied in a msg-TLV Whether or not the metric belongs in AODVv2 this year is a matter for discussion. The design can be quite straightforward, requiring only an IANA registry for "metric type". Given the flexibiity of RFC 5444 msg- header format, very general metrics could be supported. Metric type '0' would be reserved for HopCount. Completely agreeing. Although I love simplicity with only hop counts, it tu= rns out not to always be the most relevant metric in MANET. In my experience Hopcount metrics don't work well in wireless networks unless you have very specific links. Using hopcount as a metric means you optimize for LONG links, which are often the ones that do not work reasonable well. Without a well thought hysteresis your network might just dissolve into a huge mess, especially for multirate networks like IEEE802.11. Saying "hopcount is the most relevant metric in MANET" is at best shady... and at worst just wrong. we agree this is what I wrote ;-) =85 "Although I love simplicity with only= hop counts, it turns out not to always be the most relevant metric in MANET It is not so rare to see shorter delays on longer paths in terms of hop counts. Same comment for Packet Delivery Ra= tio (some link may have really high ETX!). Not suggesting to adopt a similar model as in RFC6551, but adding a bit of = flexibility will help in the future, even if we start with something very simple. I agree that not specifying the metric is a good idea (similar to the way it has been done in OLSRv2), but hopcount only is a poor choice for a metric. indeed, this is why I was referring to the RFC6551 (being the editor of the= document) although we may not need all of these metrics. JP. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." --_000_03B78081B371D44390ED6E7BADBB4A7722063860xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1246FD0FA9DB434395682E22761395D3@cisco.com> Content-Transfer-Encoding: quoted-printable
On Nov 7, 2012, at 10:39 PM, Henning Rogge wrote:

On Wed, Nov 7, 2012 at 10:29 PM, JP Vasseur (jvasseur)
<jvasseur@cisco.com> wrote:=
Hi Charlie,

On Nov 7, 2012, at 11:56 AM, manet issue tracker = wrote:

#8: HopCount and alternate metrics in AODVv2

Most of the language in the current specification= for route metrics is
actually specific to !HopCount.  It is propo= sed to rename existing metric
fields to actually *be* !HopCount, to improve cla= rity.

Following common practice up until now, the defau= lt route metric for
AODVv2 is !HopCount.  Nevertheless, the docu= ment should allow for
alternate metrics to be used.  To be compati= ble with RFC 5444 and the
current reactive features, the following design g= uidelines are suggested.
* a new AddTLV of type "metric" should = be supported.  The metric AddTLV
  would supply metric values for each o= f the addresses in the !AddBlk
* a metric 'type' should be supplied in a msg-TLV=

Whether or not the metric belongs in AODVv2 this = year is a matter for
discussion.  The design can be quite straigh= tforward, requiring only an
IANA registry for "metric type".  = Given the flexibiity of RFC 5444 msg-
header format, very general metrics could be supp= orted.  Metric type '0'
would be reserved for HopCount.

Completely agreeing. Although I love simplicity w= ith only hop counts, it turns out not
to always be the most relevant metric in MANET.

In my experience Hopcount metrics don't work well in wireless networks
unless you have very specific links. Using hopcount as a metric means
you optimize for LONG links, which are often the ones that do not work
reasonable well. Without a well thought hysteresis your network might
just dissolve into a huge mess, especially for multirate networks like
IEEE802.11.

Saying "hopcount is the most relevant metric in MANET" is at best=
shady... and at worst just wrong.

we agree this is what I wrote ;-) =85 "Although I love sim= plicity with only hop counts, it turns out not
to always be the most relevant metric in MANET


It is not so rare to see shorter delays
on longer paths in terms of hop counts. Same comm= ent for Packet Delivery Ratio (some
link may have really high ETX!).
Not suggesting to adopt a similar model as in RFC= 6551, but adding a bit of flexibility will
help in the future, even if we start with somethi= ng very simple.

I agree that not specifying the metric is a good idea (similar to the
way it has been done in OLSRv2), but hopcount only is a poor choice
for a metric.


indeed, this is why I was referring to the RFC6551 (being the editor o= f the document) although we may
not need all of these metrics.

JP.

Henning Rogge

--
Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that
was before the present government."

--_000_03B78081B371D44390ED6E7BADBB4A7722063860xmbrcdx02ciscoc_-- From william.d.ivancic@nasa.gov Thu Nov 8 11:00:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9F721F867C for ; Thu, 8 Nov 2012 11:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2d6gccD9xw1 for ; Thu, 8 Nov 2012 11:00:57 -0800 (PST) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE1E21F85C5 for ; Thu, 8 Nov 2012 11:00:57 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 1178B2D829B; Thu, 8 Nov 2012 13:00:57 -0600 (CST) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt04.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id qA8J0uqw016994; Thu, 8 Nov 2012 13:00:56 -0600 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Thu, 8 Nov 2012 13:00:56 -0600 From: "Ivancic, William D. (GRC-RHN0)" To: "Dowdell, John" Date: Thu, 8 Nov 2012 13:00:55 -0600 Thread-Topic: [manet] DLEP Lite? Thread-Index: Ac2942HRUkM4BR0cTiGrPhezEeSLcw== Message-ID: References: <1B40484159234F4FB6FE11D4C2F408DE01FFCD0B@SUKNPT8108.cogent-dsn.local> In-Reply-To: <1B40484159234F4FB6FE11D4C2F408DE01FFCD0B@SUKNPT8108.cogent-dsn.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C4223B4918594ADEAC6831F68F0B40D6nasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-08_04:2012-11-08, 2012-11-08, 1970-01-01 signatures=0 Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Lite? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:00:59 -0000 --_000_C4223B4918594ADEAC6831F68F0B40D6nasagov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable DLEP, at least the last time I read it, which was a month or two ago, is cl= ient/server based with sessions setup between radio and router. ModemLPA s= imply has the radio (or crypto device or whatever) sending out status packe= ts either periodically or when something changes. ModemLPA could send eith= er to all routers address, a unicast address, or perhaps a organizationally= scoped multicast address. "It should be possible to use the DLEP message formats without all the sign= aling required for the DLEP client/server session to perform the functions = addressed in this draft. The modem would simply provide link states out vi= a multicast or unicast UDP datagrams (DLEP-Lite)." DLEP is designed to operate only over the local-link and does not accommoda= te systems that are multiple hops away from the modem. Upstream notificatio= n would be a simple modification to DLEP (I think). "To handle advertisements beyond the local interface, Internet Protocol version 4 (IPv4) organizational-scoped multicast and Internet Protocol version 6 (IPv6) site-local multicast MAY be used with no explicit configuration in the modem. Use of IPv4 administratively-scoped multicast and IPv6 site-local multicast could handle both devices that are directly connected to the modem as well as hosts and applications that are multiple hops away [RFC2365] [RFC2373]." On Nov 7, 2012, at 5:08 PM, Dowdell, John wrote: @Stan and Will Can you explain exactly what you mean by DLEP Lite, as mentioned in the dyi= ng moments of the WG meeting? Lite in what respect? I would not consider DL= EP to be particularly overweight, so understanding exactly what you would i= ntend to remove would be useful. Also, IMHO it is enough work simply to define one DLEP, so having another o= ne to choose from is not likely to help the radio manufacturers along the r= oad to implementation. Having a mandatory core of DLEP, with optional extra= s, I can support. Having a further cut down edition means you then either h= ave to know beforehand whether the radio supports full or Lite DLEP, or you= have to be able to automatically query the radio to find out (which is a f= eature I suggested long, long ago, you may recall =85.). Regards John _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_C4223B4918594ADEAC6831F68F0B40D6nasagov_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

DLEP is designed to operate only over the local-l= ink and does not accommodate systems that are multiple hops away from = the modem. Upstream notification would be a simple modification to DLEP (I = think).

  "To handle advertisement= s beyond the local interface, Internet
   Protocol vers= ion 4 (IPv4) organizational-scoped multicast and
   Int= ernet Protocol version 6 (IPv6) site-local multicast MAY be used
=    with no explicit configuration in the modem.  Use of IPv4=
   administratively-scoped multicast and IPv6 site-loc= al multicast could
   handle both devices that are dire= ctly connected to the modem as well
   as hosts and app= lications that are multiple hops away [RFC2365]
   [RFC= 2373]."




On Nov 7, 2012, at 5:08 PM, Dowdell, John wrote:

= @Stan and Will
 
Can you explain exactly what you mean by DLEP L= ite, as mentioned in the dying moments of the WG meeting? Lite in what resp= ect? I would not consider DLEP to be particularly overweight, so understand= ing exactly what you would intend to remove would be useful.
 
Also, IMHO= it is enough work simply to define one DLEP, so having another one to choo= se from is not likely to help the radio manufacturers along the road to imp= lementation. Having a mandatory core of DLEP, with optional extras, I can s= upport. Having a further cut down edition means you then either have to kno= w beforehand whether the radio supports full or Lite DLEP, or you have to b= e able to automatically query the radio to find out (which is a feature I s= uggested long, long ago, you may recall =85.).
 
Regards<= /font>
 
John
 
__________________= _____________________________
manet mailing list
manet@iet= f.org
https://www.ietf.org/mailman= /listinfo/manet

= --_000_C4223B4918594ADEAC6831F68F0B40D6nasagov_-- From prvs=265978d650=david.ward@ll.mit.edu Thu Nov 8 11:43:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C91221F8522 for ; Thu, 8 Nov 2012 11:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYU3SZaoWB3V for ; Thu, 8 Nov 2012 11:43:58 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD0D21F8889 for ; Thu, 8 Nov 2012 11:43:58 -0800 (PST) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id qA8JhVZx006424; Thu, 8 Nov 2012 14:43:56 -0500 From: "Ward, David - 0663 - MITLL" To: "Ivancic, William D. (GRC-RHN0)" Date: Thu, 8 Nov 2012 14:43:51 -0500 Thread-Topic: DLEP Lite? Thread-Index: Ac296WGco3GxT3nSQhKyLyaRX1dzMg== Message-ID: <509C0B77.2000406@ll.mit.edu> References: <1B40484159234F4FB6FE11D4C2F408DE01FFCD0B@SUKNPT8108.cogent-dsn.local> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070700090107000509000801" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-08_04:2012-11-08, 2012-11-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1211080189 Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Lite? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:43:59 -0000 --------------ms070700090107000509000801 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Will, On 11/08/2012 02:00 PM, Ivancic, William D. (GRC-RHN0) wrote: > DLEP, at least the last time I read it, which was a month or two ago, i= s > client/server based with sessions setup between radio and router. > ModemLPA simply has the radio (or crypto device or whatever) sending > out status packets either periodically or when something changes. > ModemLPA could send either to all routers address, a unicast address,= > or perhaps a organizationally scoped multicast address. > > "It should be possible to use the DLEP message formats without all > the signaling required for the DLEP client/server session to perform > the functions addressed in this draft. The modem would simply > provide link states out via multicast or unicast UDP datagrams (DLEP-Li= te)." > > DLEP is designed to operate only over the local-link and does > not accommodate systems that are multiple hops away from the modem. > Upstream notification would be a simple modification to DLEP (I think).= > > "To handle advertisements beyond the local interface, Internet > Protocol version 4 (IPv4) organizational-scoped multicast and > Internet Protocol version 6 (IPv6) site-local multicast MAY be used= > with no explicit configuration in the modem. Use of IPv4 > administratively-scoped multicast and IPv6 site-local multicast cou= ld > handle both devices that are directly connected to the modem as wel= l > as hosts and applications that are multiple hops away [RFC2365] > [RFC2373]." > Please see my earlier message. I don't think DLEP, or any radio=20 interface, is the right place for that. Perhaps RSVP/NSIS is a better=20 starting point for controlling your application traffic, although I=20 realize it might not do exactly what you are looking for as-is. David > > > > On Nov 7, 2012, at 5:08 PM, Dowdell, John wrote: > >> @Stan and Will >> Can you explain exactly what you mean by DLEP Lite, as mentioned in >> the dying moments of the WG meeting? Lite in what respect? I would not= >> consider DLEP to be particularly overweight, so understanding exactly >> what you would intend to remove would be useful. >> Also, IMHO it is enough work simply to define one DLEP, so having >> another one to choose from is not likely to help the radio >> manufacturers along the road to implementation. Having a mandatory >> core of DLEP, with optional extras, I can support. Having a further >> cut down edition means you then either have to know beforehand whether= >> the radio supports full or Lite DLEP, or you have to be able to >> automatically query the radio to find out (which is a feature I >> suggested long, long ago, you may recall =85.). >> Regards >> John >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --=20 David Ward, Associate Staff Wideband Tactical Networking Group MIT Lincoln Laboratory Office: 781-981-4266 Mobile: 781-999-1925 Fax: 781-981-4583 --------------ms070700090107000509000801 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOZjCC BLcwggOfoAMCAQICARQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoT Fk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwg Um9vdCBDQTAeFw0wOTEyMTQxMjAwMDBaFw0xNTEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnBMsjYUiH 7DegMwcFYWZM6OknYzRgEO5gNgPE9JJnQgfDB+o1o1VTMBWcJYPXII4CyhLhDvSjfCvTPI4H mRDKIp5UX5N2BCzwu7BJJMwUJHFaS4RMAC7nvYh6MIEixpl2aWCpkYX74b2CeDDQriGlqXCv xmg2QhPlNmk4ONpL/80Kx9wKKhV/NThe54sFzZ2pz9YUEX5DE0a52hFvA19EzGhv7fUcucUj Ky0zXPQ70LYwOWXLlpxAolKcgwRVsS6/cse8YH9fy8IAsXKAXikgQaFs5EJigLIDKPTKtRaf 55yKsORSpoDrO1cvuntA5PnIH/qAFfACvGRTEK1RNLh9AgMBAAGjggGVMIIBkTASBgNVHRMB Af8ECDAGAQH/AgEAMB0GA1UdDgQWBBSOSn2JoWMXHIGINFc3JkVeGYp+JDAfBgNVHSMEGDAW gBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwYQYIKwYBBQUHAQEEVTBT MC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0EwIgYIKwYB BQUHMAGGFmh0dHA6Ly9vY3NwLmxsLm1pdC5lZHUwMwYDVR0fBCwwKjAooCagJIYiaHR0cDov L2NybC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIB AwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqG SIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEP MA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBCwUAA4IBAQCIdwah0P1x/Augwi/nhBq6Ds8Q XAqkzSLZrL+DADWjk6HYFNo64x3Bo15c6oaW/GcTpZACt3StPa3OvsgAnKCtk81bQ0WV2MaL /0qmUYyN3bn1NiWrQD8aLAssv9aLY5dUylGOO1r37d9b3X+YtFytg0FRCfl5arYAYhU1SDCH wScD2o67Is/qYBRGMIYcCcb7PH5UotBSwhO+1WCxIqD+YcRusyD3kEcc4dW6IG36YVhx7aIk w5AUmeFH7xl0E1X+0I4Q+cmMNdMiArYx5rYG34AZB+f770fdjWPUUpTT82aphiiImutWyQpm oEWBsnsX3nVTRdHCVi+Cf3Cx4YDWMIIE0DCCA7igAwIBAgIKFDTzfQAAAABQQzANBgkqhkiG 9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEyMDkwNDEzMjA1NFoX DTEzMDkwNDEzMjA1NFowXzELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEeMBwGA1UEAxMVV2FyZC5EYXZpZC5QLjUwMDEx NDU5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlQpeGVnnD5Qk9yst3Dc4hHB7 ffqz1+uzSq+vbdj8SsPimBI1/ptJDv047zbGKH+8GR6JF9ykClRkyse5QtC5oxn2gvMDDxI1 dI5t4itSWE1zi4+5Sc7c/+kiDaZxWfjhSgYlSY160VbzudjaAY7uRZtVLVGqsfYV631GBCH/ zPnklpmx79kZO3s2dHh1J/xvUiGY3VrqCi1mdigP4Sys0kzzrH0bRzkKYWYjQQKgbFgQE17l cVflo22XZ82rM7boe+u5zMeo2UYcuKV9sh2wttVijbJpIgV0PQJIxTAtcUjzEkZXBCR3vMvS RtQB9k+i6+L4qLJagSSmK0LPL5GT4QIDAQABo4IBmjCCAZYwHQYDVR0OBBYEFJDeo9mVRpLI h5SCQITbLFzbqIaQMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBSOSn2JoWMXHIGINFc3 JkVeGYp+JDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3Js L0xMQ0EyMGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQu ZWR1L2dldHRvL0xMQ0EyMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAM BgNVHRMBAf8EAjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq 8EWFtqEfHYXL3jKH/4pzAgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3 CgMMMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwIAYDVR0RBBkwF4EVZGF2aWQud2FyZEBs bC5taXQuZWR1MA0GCSqGSIb3DQEBCwUAA4IBAQA+4Y9Phse3fgha9SCOdzKDbrFdD6GrFHf2 G6qwyWKn02TE+HnEqu8bArS9HTruLHJSZd6Sk0fJ0kjsV93XuivqiagSiwTE5Z3LbVmEZmVz /J1wNwbt4Wh6Fia+HzGwpxJUVMaiCNW/KZ6QG89c9fUeXz20QLcwaXFbFDxFowYOJ18z6znq muerd0Vgadj+tUNLkaFKExfSHz4S6vGHruKzlp8pN5pShkL2WvcrLfex6DFK3vYhrYTdkaB+ mKAy/dokW1x6qygDW+WW2ykQ5gwIdldidpCtWf77ifYrJ3PqPrI1koY8I2zmc6F96eIXXmSI dCcKkrv/7zbuwtuNQUElMIIE0zCCA7ugAwIBAgIKFDWLlwAAAABQRDANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEyMDkwNDEzMjEzM1oXDTEzMDkw NDEzMjEzM1owXzELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEeMBwGA1UEAxMVV2FyZC5EYXZpZC5QLjUwMDExNDU5MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3CB/DldDL6g8NAY4KpWAgCgXj1s+C8bG z3dPr47Iuc/4hfvPVx6uEnQH7nG1L3QvV5AAISN6kILSRUkJCluU6c3XyjgIl5wP4jrviMEI HV8YLGyihZwAXaakGT3zWopv5J/LzJSk5z2AJf7zmX6PbD2yoCicUqWTwtBIZtSOeBT2b/yf a/BzrTivc8QvB69BBu72VcaKe6F6yqnNU1FH/CKkxcDva+YC1MzFZrfEof2MMmc8gJrdEzsJ mwPYV6EZO4P8T09cMUiqyfgUX4Qvy2Poe7wlRDnFDZxFQTGnsq/HSjBMnwr2LmwNUef4qJEH cnOcaMFPFZM8lbFtr69x0wIDAQABo4IBnTCCAZkwHQYDVR0OBBYEFFGXCofTuCBcetmoX4/Z Q7y0QXlGMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAWgBSOSn2JoWMXHIGINFc3JkVeGYp+ JDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xMQ0Ey MGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0EyMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMB Af8EAjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEf HYXr0HCD6+0gAgFkAgEEMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgME MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwIAYDVR0RBBkwF4EVZGF2aWQud2FyZEBsbC5t aXQuZWR1MA0GCSqGSIb3DQEBCwUAA4IBAQAhEOVwxw+GDmh/7XAXTFab//YvOnc25VZ72/IW IW07g6YuDsiFHNXQ67GcXySUpjgKsxeorrGxfnDZ03Qp67s+xHvtVqqgkclOa+CAmFm18yG8 sBpY0G2C+HJuFwWKBHmnt5/npvZLIqwbFLm548QYRuS5u073HRW4QH2MPrrexZBL50e8fjnI NoyK8JcXwzXNWeo1yRCl+REKUIqqtjS2AM9+4H0M3HONctclRU4sryPVpddxGi8T0Hv798IA uBF8vkBfCwGVrB3mi9PQXBWdBBV9++shL3Vj0TT+Ec/sc1ftXt+CvoF9ggppVVRJwBfA6ZJ4 /yiLxDsY+K5I9gvRMYIDNzCCAzMCAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y AgoUNPN9AAAAAFBDMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEyMTEwODE5NDM1MVowIwYJKoZIhvcNAQkEMRYEFPvmoqk4KiSr dEiAj9lJE8E63auyMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0yAgoUNYuXAAAAAFBEMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEf MB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQD EwpNSVRMTCBDQS0yAgoUNYuXAAAAAFBEMA0GCSqGSIb3DQEBAQUABIIBAH74xDUviozUzii1 2WG7z0OoQddHi2LDAIF8v7i1eSLjU/1fdKhoDJHvM7txSlvSrczKb8S1tubYYtfYVLJZcpu3 6YCQ77SZK9YxVx9mrC0bJwqp307bGHxt2+zGwyktBCQ6rJ3mZ2dblR+ebzUj/5KGRbYLjvf0 /fg06xZ5MR2d57Y1kzBD69uU1vjObjJLr8kZHDY8W/VLwpKDKCf5JHyi8UUxU2aKlkaKUAmL jQAJtVcIKy0eoB4pKwXE8zjZs4WIE5Gyhgy+dj/v4HHDsYz5s1Ruo+dYYOqSda2lkCqlsQTG WLCqY5ozFyVfpl1EjrXS8CTRRjyHgAIWwS5O8eoAAAAAAAA= --------------ms070700090107000509000801-- From teco@inf-net.nl Fri Nov 9 05:54:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EA221F866C for ; Fri, 9 Nov 2012 05:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FBXCOjqJu5j for ; Fri, 9 Nov 2012 05:54:50 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E97621F847B for ; Fri, 9 Nov 2012 05:54:49 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so3049397pbb.31 for ; Fri, 09 Nov 2012 05:54:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=iHb4rnNZqoHJ96f+hINKuKUDvYdATJ0hQfB83eCRVwU=; b=h3K5mMO8kukT+uTgcHk+OLeoDzjuQJGY16TuJ3Bha70JIcBuOtURCMoO9eamf+qaJ8 CzqL84GRG0Woxm3xMzX69eDROG3dCHSNOe4L6uOZm/BIJUAfjwX/7xcfypD489cv89rN vxhAXmhLBbTkwgN23GMA1GBPdDcXYEFPlbcCr4xj5zSdKtv8+w7mJYSozpcWKO2Tsoo/ W6mWwWFPekpTPKFZeD3qmBxGBHat7UYBfxkRYAu0xzq8XKiXGDD63QQIQezmm+DTib1k +GTAZ8ryNGFGHhweCKWBXhDexHVJe6qoYZ2ZQpF01oXw6L7K1cNTFiOm1LvctVMH6UWk WfUg== Received: by 10.66.85.66 with SMTP id f2mr31877120paz.56.1352469279995; Fri, 09 Nov 2012 05:54:39 -0800 (PST) Received: from dhcp-1616.meeting.ietf.org (dhcp-1616.meeting.ietf.org. [130.129.22.22]) by mx.google.com with ESMTPS id a4sm17997147pax.12.2012.11.09.05.54.37 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 05:54:39 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_E196D18C-CE88-4289-8880-2C5DF0F06AB8" From: Teco Boot In-Reply-To: Date: Fri, 9 Nov 2012 13:59:39 +0100 Message-Id: <55238ACB-F5B2-40EB-A906-96E0F4387928@inf-net.nl> References: <1B40484159234F4FB6FE11D4C2F408DE01FFCD0B@SUKNPT8108.cogent-dsn.local> To: "Ivancic, William D. (GRC-RHN0)" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkRhPFrA7EVFq1FiSawYlW2t0Z5aouVZJw2oQnpvMgBMYg94kJG2wx19WDupfhfRZTNktXH Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Lite? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 13:54:51 -0000 --Apple-Mail=_E196D18C-CE88-4289-8880-2C5DF0F06AB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The reason why I need a one way protocol is that I have to deal with = some security mandates. All outgoing traffic from the router port has to = be crypted packets, or related to the crypto engine. This piece of code = for crypto and firewall needs to be reviewed and certified. Import of = data is less a problem. During WGLC review, I'll start reading security considerations. When it = describes something like "this protocol does not introduce a covert = channel", I'll get more interested. As I see it right now, there is a = need to split the DLEP protocol draft. The basic mode would be = DLEP-Lite, and provide transport from radio to router only. Maybe = DLEP-heavy is a better name for it, it could need more lines of code. = And more bits on the wire. Teco Op 8 nov. 2012, om 20:00 heeft Ivancic, William D. (GRC-RHN0) het = volgende geschreven: > DLEP, at least the last time I read it, which was a month or two ago, = is client/server based with sessions setup between radio and router. = ModemLPA simply has the radio (or crypto device or whatever) sending out = status packets either periodically or when something changes. ModemLPA = could send either to all routers address, a unicast address, or perhaps = a organizationally scoped multicast address. =20 >=20 > "It should be possible to use the DLEP message formats without all the = signaling required for the DLEP client/server session to perform the = functions addressed in this draft. The modem would simply provide link = states out via multicast or unicast UDP datagrams (DLEP-Lite)." >=20 > DLEP is designed to operate only over the local-link and does not = accommodate systems that are multiple hops away from the modem. Upstream = notification would be a simple modification to DLEP (I think). >=20 > "To handle advertisements beyond the local interface, Internet > Protocol version 4 (IPv4) organizational-scoped multicast and > Internet Protocol version 6 (IPv6) site-local multicast MAY be used > with no explicit configuration in the modem. Use of IPv4 > administratively-scoped multicast and IPv6 site-local multicast = could > handle both devices that are directly connected to the modem as = well > as hosts and applications that are multiple hops away [RFC2365] > [RFC2373]." >=20 >=20 >=20 >=20 > On Nov 7, 2012, at 5:08 PM, Dowdell, John wrote: >=20 >> @Stan and Will >> =20 >> Can you explain exactly what you mean by DLEP Lite, as mentioned in = the dying moments of the WG meeting? Lite in what respect? I would not = consider DLEP to be particularly overweight, so understanding exactly = what you would intend to remove would be useful. >> =20 >> Also, IMHO it is enough work simply to define one DLEP, so having = another one to choose from is not likely to help the radio manufacturers = along the road to implementation. Having a mandatory core of DLEP, with = optional extras, I can support. Having a further cut down edition means = you then either have to know beforehand whether the radio supports full = or Lite DLEP, or you have to be able to automatically query the radio to = find out (which is a feature I suggested long, long ago, you may recall = =85.). >> =20 >> Regards >> =20 >> John >> =20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_E196D18C-CE88-4289-8880-2C5DF0F06AB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The = reason why I need a one way protocol is that I have to deal with some = security mandates. All outgoing traffic from the router port has to be = crypted packets, or related to the crypto engine. This piece of code for = crypto  and firewall needs to be reviewed and certified. = Import of data is less a problem.

During WGLC review, = I'll start reading security considerations. When it describes something = like "this protocol does not introduce a covert channel", I'll get more = interested. As I see it right now, there is a need to split the DLEP = protocol draft. The basic mode would be DLEP-Lite, and provide transport = from radio to router only. Maybe DLEP-heavy is a better name for it, it = could need more lines of code. And more bits on the = wire.

Teco

Op 8 nov. = 2012, om 20:00 heeft Ivancic, William D. (GRC-RHN0) het volgende = geschreven:

DLEP, at least the last time I read it, which was a = month or two ago, is client/server based with sessions setup between = radio and router.  ModemLPA simply has the radio (or crypto device = or whatever) sending out status packets either periodically or when = something changes.  ModemLPA could send either to all routers = address, a unicast address, or perhaps a organizationally scoped = multicast address.  

"It should be possible to = use the DLEP message formats without all the signaling required for = the DLEP client/server session to perform the functions addressed = in this draft.  The modem would simply provide link states out = via multicast or unicast UDP datagrams = (DLEP-Lite)."

DLEP is designed = to operate only over the local-link and does not accommodate = systems that are multiple hops away from the modem. Upstream = notification would be a simple modification to DLEP (I = think).

  "To handle = advertisements beyond the local interface, Internet
  =  Protocol version 4 (IPv4) organizational-scoped multicast = and
   Internet Protocol version 6 (IPv6) site-local = multicast MAY be used
   with no explicit = configuration in the modem.  Use of IPv4
  =  administratively-scoped multicast and IPv6 site-local multicast = could
   handle both devices that are directly = connected to the modem as well
   as hosts and = applications that are multiple hops away [RFC2365]
  =  [RFC2373]."



=

On Nov 7, 2012, at 5:08 PM, Dowdell, John = wrote:

Can = you explain exactly what you mean by DLEP Lite, as mentioned in the = dying moments of the WG meeting? Lite in what respect? I would not = consider DLEP to be particularly overweight, so understanding exactly = what you would intend to remove would be = useful.
manet@ietf.org
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= = --Apple-Mail=_E196D18C-CE88-4289-8880-2C5DF0F06AB8-- From william.d.ivancic@nasa.gov Fri Nov 9 06:16:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB60821F8594 for ; Fri, 9 Nov 2012 06:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8B1nqslWhwHR for ; Fri, 9 Nov 2012 06:16:38 -0800 (PST) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by ietfa.amsl.com (Postfix) with ESMTP id 34B3021F8588 for ; Fri, 9 Nov 2012 06:16:38 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 52EBA2D8485; Fri, 9 Nov 2012 08:16:37 -0600 (CST) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt04.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id qA9EGaDA010597; Fri, 9 Nov 2012 08:16:36 -0600 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Fri, 9 Nov 2012 08:16:36 -0600 From: "Ivancic, William D. (GRC-RHN0)" To: "Ward, David - 0663 - MITLL" Date: Fri, 9 Nov 2012 08:16:36 -0600 Thread-Topic: New Version Notification for draft-ivancic-manet-modemlpa-00.txt Thread-Index: Ac2+hNQWnDT4mPgGSQ+wrFy+q019iw== Message-ID: <766AB770-5E6B-4D41-BD22-6B199C6B95AE@nasa.gov> References: <20121105212854.4905.95804.idtracker@ietfa.amsl.com> <509881BB.6030001@ll.mit.edu> In-Reply-To: <509881BB.6030001@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-09_03:2012-11-08, 2012-11-09, 1970-01-01 signatures=0 Cc: "manet@ietf.org" Subject: Re: [manet] New Version Notification for draft-ivancic-manet-modemlpa-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 14:16:39 -0000 David, Often for end-systems such as those found in many manets, there is only one= WAN with a router attached that is either routing traffic off the system o= r between local nodes. Conversely, there may not even be a router attached= , just a host system attached to a radio. ModemLPA offers a very simple wa= y to communicate layer 2 information to systems and applications upstream = from the radio. Sometimes rate is important. Other times link up/down is = useful. Certainly for something like store/carry/forward distributed appli= cations know that the link is down is useful. - Will >=20 > Hi Will, >=20 > I'm not sure that I agree with extending layer 2 information beyond the=20 > radio-to-router interface. Looking at figure 4, how will the=20 > host/application know which way the router is going to forward packets,=20 > in order to control its output data rate? I think the mechanism to=20 > control the rate of your application traffic should be separate from the= =20 > radio-to-router interface. >=20 > David From abdussalambaryun@gmail.com Fri Nov 9 06:41:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA2A21F8594 for ; Fri, 9 Nov 2012 06:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kumhkk4wbAip for ; Fri, 9 Nov 2012 06:41:46 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DDAB521F858B for ; Fri, 9 Nov 2012 06:41:45 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so4358036vbb.31 for ; Fri, 09 Nov 2012 06:41:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IRnQNnxtlxTQoaeVxbBMym3q8ee8BlhFscBJnOs//kY=; b=dacaQ+8Stv1aNuZH7EyodA+jEyuXIGJkNbBsQLfTV8gMZHSHNqXaG1QYsQx7V9d8Wm jN+xT5pfmzzUlvZgbhq+cFiLI9IXemJTWIPv0GgCqiE9wXsPEEzUKLwKtMDDMXouh7Us Y+FovJwUAohnZd6nV7n5V95Io5IA7BaobOB0QGsdymhVot02T/Jds9CFle9jEPv3Vyzx jBMgsOEbcB0LnC+bLMJk9FrYEWo0fVaoKPNvV6f96Kff7Q6vaHsNxV+4lYBsYn0fdPk2 mciZn8VfKKVpy5SRQboiiKjaXOsWnd5jNV1jgCWycfUrnoVdryk5AE2oPCME3P6zGCXn nhIQ== MIME-Version: 1.0 Received: by 10.220.154.68 with SMTP id n4mr10470465vcw.22.1352472105370; Fri, 09 Nov 2012 06:41:45 -0800 (PST) Received: by 10.220.204.9 with HTTP; Fri, 9 Nov 2012 06:41:45 -0800 (PST) In-Reply-To: <55238ACB-F5B2-40EB-A906-96E0F4387928@inf-net.nl> References: <1B40484159234F4FB6FE11D4C2F408DE01FFCD0B@SUKNPT8108.cogent-dsn.local> <55238ACB-F5B2-40EB-A906-96E0F4387928@inf-net.nl> Date: Fri, 9 Nov 2012 15:41:45 +0100 Message-ID: From: Abdussalam Baryun To: "manet@ietf.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] DLEP Lite? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 14:41:46 -0000 Initially as this draft is an experimental draft (not standard track) I don't mind we have both DLEP and DLEP-lite as long within document, the requirement difference can be identified. AB > > Op 8 nov. 2012, om 20:00 heeft Ivancic, William D. (GRC-RHN0) het volgend= e > geschreven: > >> DLEP, at least the last time I read it, which was a month or two ago, is >> client/server based with sessions setup between radio and router. >> ModemLPA simply has the radio (or crypto device or whatever) sending out >> status packets either periodically or when something changes. ModemLPA >> could send either to all routers address, a unicast address, or perhaps = a >> organizationally scoped multicast address. >> >> "It should be possible to use the DLEP message formats without all the >> signaling required for the DLEP client/server session to perform the >> functions addressed in this draft. The modem would simply provide link >> states out via multicast or unicast UDP datagrams (DLEP-Lite)." >> >> DLEP is designed to operate only over the local-link and does not >> accommodate systems that are multiple hops away from the modem. Upstream >> notification would be a simple modification to DLEP (I think). >> >> "To handle advertisements beyond the local interface, Internet >> Protocol version 4 (IPv4) organizational-scoped multicast and >> Internet Protocol version 6 (IPv6) site-local multicast MAY be used >> with no explicit configuration in the modem. Use of IPv4 >> administratively-scoped multicast and IPv6 site-local multicast could >> handle both devices that are directly connected to the modem as well >> as hosts and applications that are multiple hops away [RFC2365] >> [RFC2373]." >> >> >> >> >> On Nov 7, 2012, at 5:08 PM, Dowdell, John wrote: >> >>> @Stan and Will >>> >>> Can you explain exactly what you mean by DLEP Lite, as mentioned in the >>> dying moments of the WG meeting? Lite in what respect? I would not >>> consider DLEP to be particularly overweight, so understanding exactly >>> what you would intend to remove would be useful. >>> >>> Also, IMHO it is enough work simply to define one DLEP, so having anoth= er >>> one to choose from is not likely to help the radio manufacturers along >>> the road to implementation. Having a mandatory core of DLEP, with >>> optional extras, I can support. Having a further cut down edition means >>> you then either have to know beforehand whether the radio supports full >>> or Lite DLEP, or you have to be able to automatically query the radio t= o >>> find out (which is a feature I suggested long, long ago, you may recall >>> =85.). >>> >>> Regards >>> >>> John >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From prvs=2660864c8b=david.ward@ll.mit.edu Fri Nov 9 07:16:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3267A21F8640 for ; Fri, 9 Nov 2012 07:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J66pv1zMnI-m for ; Fri, 9 Nov 2012 07:16:50 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4540C21F84C6 for ; Fri, 9 Nov 2012 07:16:50 -0800 (PST) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id qA9FGnoP020347; Fri, 9 Nov 2012 10:16:49 -0500 From: "Ward, David - 0663 - MITLL" To: "Ivancic, William D. (GRC-RHN0)" Date: Fri, 9 Nov 2012 10:16:47 -0500 Thread-Topic: New Version Notification for draft-ivancic-manet-modemlpa-00.txt Thread-Index: Ac2+jTztwDh6KQ+JSy68Y2SKVmUmBw== Message-ID: <509D1E5F.8080703@ll.mit.edu> References: <20121105212854.4905.95804.idtracker@ietfa.amsl.com> <509881BB.6030001@ll.mit.edu> <766AB770-5E6B-4D41-BD22-6B199C6B95AE@nasa.gov> In-Reply-To: <766AB770-5E6B-4D41-BD22-6B199C6B95AE@nasa.gov> Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060504020009080809060305" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-09_03:2012-11-08, 2012-11-09, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1211090120 Cc: "manet@ietf.org" Subject: Re: [manet] New Version Notification for draft-ivancic-manet-modemlpa-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:16:51 -0000 X-List-Received-Date: Fri, 09 Nov 2012 15:16:51 -0000 --------------ms060504020009080809060305 Content-Type: multipart/alternative; boundary="------------070009020204080201080004" This is a multi-part message in MIME format. --------------070009020204080201080004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Will, So then, how does the application know whether it is serving up traffic=20 to another attached LAN (where it does not need to constrain its output=20 to the radio's rate limit) or the radio WAN (where it does)? There are plenty of MANETs where you assumption does not hold (like ones = I deal with), and I'm afraid that standardizing an approach where you=20 make that kind of assumption could cause major headaches elsewhere when=20 that gets implemented. I know the intent is to optimize the application = for the network, but this seems like a pretty gross violation of layer=20 separation principles. How about we take the time to come up with an approach that will solve=20 the general case of rate-limiting application traffic using feedback=20 from the routing layer (where only the router will be getting the radio=20 metrics and using them appropriately)? This problem isn't necessarily=20 specific to MANETs or even wireless links. David On 11/09/2012 09:16 AM, Ivancic, William D. (GRC-RHN0) wrote: > Re: New Version Notification for draft-ivancic-manet-modemlpa-00.txt > > David, > > Often for end-systems such as those found in many manets, there is=20 > only one WAN with a router attached that is either routing traffic off = > the system or between local nodes. Conversely, there may not even be a = > router attached, just a host system attached to a radio. ModemLPA=20 > offers a very simple way to communicate layer 2 information to=20 > systems and applications upstream from the radio. Sometimes rate is=20 > important. Other times link up/down is useful. Certainly for=20 > something like store/carry/forward distributed applications know that=20 > the link is down is useful. > > - Will > > > > > Hi Will, > > > > I'm not sure that I agree with extending layer 2 information beyond t= he > > radio-to-router interface. Looking at figure 4, how will the > > host/application know which way the router is going to forward packet= s, > > in order to control its output data rate? I think the mechanism to > > control the rate of your application traffic should be separate from = the > > radio-to-router interface. > > > > David > --=20 David Ward, Associate Staff Wideband Tactical Networking Group MIT Lincoln Laboratory Office: 781-981-4266 Mobile: 781-999-1925 Fax: 781-981-4583 --------------070009020204080201080004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Will,

So then, how does the application know whether it is serving up traffic to another attached LAN (where it does not need to constrain its output to the radio's rate limit) or the radio WAN (where it does)?

There are plenty of MANETs where you assumption does not hold (like ones I deal with), and I'm afraid that standardizing an approach where you make that kind of assumption could cause major headaches elsewhere when that gets implemented.  I know the in= tent is to optimize the application for the network, but this seems like a pretty gross violation of layer separation principles.

How about we take the time to come up with an approach that will solve the general case of rate-limiting application traffic using feedback from the routing layer (where only the router will be getting the radio metrics and using them appropriately)?  This= problem isn't necessarily specific to MANETs or even wireless links.

David


On 11/09/2012 09:16 AM, Ivancic, William D. (GRC-RHN0) wrote:
Re: New Version Notification for draft-ivancic-manet-modemlpa-00.txt

David,

Often for end-systems such as those found in many manets, there is only one WAN with a router attached that is either routing traffic off the system or between local nodes.  Conversely, there may not even be a router attached, just a host system attached to a radio.  ModemLPA offers a very simple way to communicate layer 2 information to systems  = and applications upstream from the radio.  Sometimes rate is important.  Other times link up/down is useful.  Cert= ainly for something like store/carry/forward distributed applications know that the link is down is useful.

- Will

>
> Hi Will,
>
> I'm not sure that I agree with extending layer 2 information beyond the
> radio-to-router interface.  Looking at figure 4, how = will the
> host/application know which way the router is going to forward packets,
> in order to control its output data rate?  I think th= e mechanism to
> control the rate of your application traffic should be separate from the
> radio-to-router interface.
>
> David

 



--=20
David Ward, Associate Staff
Wideband Tactical Networking Group
MIT Lincoln Laboratory
Office: 781-981-4266
Mobile: 781-999-1925
Fax: 781-981-4583
--------------070009020204080201080004-- --------------ms060504020009080809060305 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOZjCC BLcwggOfoAMCAQICARQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoT Fk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwg Um9vdCBDQTAeFw0wOTEyMTQxMjAwMDBaFw0xNTEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnBMsjYUiH 7DegMwcFYWZM6OknYzRgEO5gNgPE9JJnQgfDB+o1o1VTMBWcJYPXII4CyhLhDvSjfCvTPI4H mRDKIp5UX5N2BCzwu7BJJMwUJHFaS4RMAC7nvYh6MIEixpl2aWCpkYX74b2CeDDQriGlqXCv xmg2QhPlNmk4ONpL/80Kx9wKKhV/NThe54sFzZ2pz9YUEX5DE0a52hFvA19EzGhv7fUcucUj Ky0zXPQ70LYwOWXLlpxAolKcgwRVsS6/cse8YH9fy8IAsXKAXikgQaFs5EJigLIDKPTKtRaf 55yKsORSpoDrO1cvuntA5PnIH/qAFfACvGRTEK1RNLh9AgMBAAGjggGVMIIBkTASBgNVHRMB Af8ECDAGAQH/AgEAMB0GA1UdDgQWBBSOSn2JoWMXHIGINFc3JkVeGYp+JDAfBgNVHSMEGDAW gBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwYQYIKwYBBQUHAQEEVTBT MC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0EwIgYIKwYB BQUHMAGGFmh0dHA6Ly9vY3NwLmxsLm1pdC5lZHUwMwYDVR0fBCwwKjAooCagJIYiaHR0cDov L2NybC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIB AwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqG SIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEP MA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBCwUAA4IBAQCIdwah0P1x/Augwi/nhBq6Ds8Q XAqkzSLZrL+DADWjk6HYFNo64x3Bo15c6oaW/GcTpZACt3StPa3OvsgAnKCtk81bQ0WV2MaL /0qmUYyN3bn1NiWrQD8aLAssv9aLY5dUylGOO1r37d9b3X+YtFytg0FRCfl5arYAYhU1SDCH wScD2o67Is/qYBRGMIYcCcb7PH5UotBSwhO+1WCxIqD+YcRusyD3kEcc4dW6IG36YVhx7aIk w5AUmeFH7xl0E1X+0I4Q+cmMNdMiArYx5rYG34AZB+f770fdjWPUUpTT82aphiiImutWyQpm oEWBsnsX3nVTRdHCVi+Cf3Cx4YDWMIIE0DCCA7igAwIBAgIKFDTzfQAAAABQQzANBgkqhkiG 9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEyMDkwNDEzMjA1NFoX DTEzMDkwNDEzMjA1NFowXzELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEeMBwGA1UEAxMVV2FyZC5EYXZpZC5QLjUwMDEx NDU5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlQpeGVnnD5Qk9yst3Dc4hHB7 ffqz1+uzSq+vbdj8SsPimBI1/ptJDv047zbGKH+8GR6JF9ykClRkyse5QtC5oxn2gvMDDxI1 dI5t4itSWE1zi4+5Sc7c/+kiDaZxWfjhSgYlSY160VbzudjaAY7uRZtVLVGqsfYV631GBCH/ zPnklpmx79kZO3s2dHh1J/xvUiGY3VrqCi1mdigP4Sys0kzzrH0bRzkKYWYjQQKgbFgQE17l cVflo22XZ82rM7boe+u5zMeo2UYcuKV9sh2wttVijbJpIgV0PQJIxTAtcUjzEkZXBCR3vMvS RtQB9k+i6+L4qLJagSSmK0LPL5GT4QIDAQABo4IBmjCCAZYwHQYDVR0OBBYEFJDeo9mVRpLI h5SCQITbLFzbqIaQMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBSOSn2JoWMXHIGINFc3 JkVeGYp+JDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3Js L0xMQ0EyMGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQu ZWR1L2dldHRvL0xMQ0EyMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAM BgNVHRMBAf8EAjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq 8EWFtqEfHYXL3jKH/4pzAgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3 CgMMMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwIAYDVR0RBBkwF4EVZGF2aWQud2FyZEBs bC5taXQuZWR1MA0GCSqGSIb3DQEBCwUAA4IBAQA+4Y9Phse3fgha9SCOdzKDbrFdD6GrFHf2 G6qwyWKn02TE+HnEqu8bArS9HTruLHJSZd6Sk0fJ0kjsV93XuivqiagSiwTE5Z3LbVmEZmVz /J1wNwbt4Wh6Fia+HzGwpxJUVMaiCNW/KZ6QG89c9fUeXz20QLcwaXFbFDxFowYOJ18z6znq muerd0Vgadj+tUNLkaFKExfSHz4S6vGHruKzlp8pN5pShkL2WvcrLfex6DFK3vYhrYTdkaB+ mKAy/dokW1x6qygDW+WW2ykQ5gwIdldidpCtWf77ifYrJ3PqPrI1koY8I2zmc6F96eIXXmSI dCcKkrv/7zbuwtuNQUElMIIE0zCCA7ugAwIBAgIKFDWLlwAAAABQRDANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEyMDkwNDEzMjEzM1oXDTEzMDkw NDEzMjEzM1owXzELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEeMBwGA1UEAxMVV2FyZC5EYXZpZC5QLjUwMDExNDU5MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3CB/DldDL6g8NAY4KpWAgCgXj1s+C8bG z3dPr47Iuc/4hfvPVx6uEnQH7nG1L3QvV5AAISN6kILSRUkJCluU6c3XyjgIl5wP4jrviMEI HV8YLGyihZwAXaakGT3zWopv5J/LzJSk5z2AJf7zmX6PbD2yoCicUqWTwtBIZtSOeBT2b/yf a/BzrTivc8QvB69BBu72VcaKe6F6yqnNU1FH/CKkxcDva+YC1MzFZrfEof2MMmc8gJrdEzsJ mwPYV6EZO4P8T09cMUiqyfgUX4Qvy2Poe7wlRDnFDZxFQTGnsq/HSjBMnwr2LmwNUef4qJEH cnOcaMFPFZM8lbFtr69x0wIDAQABo4IBnTCCAZkwHQYDVR0OBBYEFFGXCofTuCBcetmoX4/Z Q7y0QXlGMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAWgBSOSn2JoWMXHIGINFc3JkVeGYp+ JDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xMQ0Ey MGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0EyMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMB Af8EAjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEf HYXr0HCD6+0gAgFkAgEEMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgME MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwIAYDVR0RBBkwF4EVZGF2aWQud2FyZEBsbC5t aXQuZWR1MA0GCSqGSIb3DQEBCwUAA4IBAQAhEOVwxw+GDmh/7XAXTFab//YvOnc25VZ72/IW IW07g6YuDsiFHNXQ67GcXySUpjgKsxeorrGxfnDZ03Qp67s+xHvtVqqgkclOa+CAmFm18yG8 sBpY0G2C+HJuFwWKBHmnt5/npvZLIqwbFLm548QYRuS5u073HRW4QH2MPrrexZBL50e8fjnI NoyK8JcXwzXNWeo1yRCl+REKUIqqtjS2AM9+4H0M3HONctclRU4sryPVpddxGi8T0Hv798IA uBF8vkBfCwGVrB3mi9PQXBWdBBV9++shL3Vj0TT+Ec/sc1ftXt+CvoF9ggppVVRJwBfA6ZJ4 /yiLxDsY+K5I9gvRMYIDNzCCAzMCAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y AgoUNPN9AAAAAFBDMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEyMTEwOTE1MTY0N1owIwYJKoZIhvcNAQkEMRYEFMPQl5ZDE5VV dz82tFUqtCJfGp/rMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0yAgoUNYuXAAAAAFBEMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEf MB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQD EwpNSVRMTCBDQS0yAgoUNYuXAAAAAFBEMA0GCSqGSIb3DQEBAQUABIIBADdQYEZLxvYZ54T4 8L52rXdXRrWjv7U8wnhtRO1nn4Zj7yoqBpCKmsA4F5litczenIHXStBTH87GWJYu4cdUhJ8m GOQwLi4MGRkfSxtPSO6ae0O1CxylDcH/cWbHkG1Bu89BkR5p0uQY8dI0QXxSf6Np5Y0XxPUX Q0hSeO522KsRlHFqCqtLMfBKT3vFCbVXOyZ8CyzyRz5kcvKcPrDetA0ow8GClEoNqaTVo+w7 CrbVaVeQ+BMAWXA4ujn+CDxzJHrW13FS4VIDDwznenbEz5o9S3BJY9YJAN1b8B2hwZwEY7Kn jgoHBg8sRZRmwfnaH70xlzNOXXRgVWylZBPdVJQAAAAAAAA= --------------ms060504020009080809060305-- From Neil.Viberg@gdcanada.com Fri Nov 9 10:08:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF76121F8771 for ; Fri, 9 Nov 2012 10:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVdaolehkvPX for ; Fri, 9 Nov 2012 10:08:12 -0800 (PST) Received: from gdcanada.com (smtp.gdcanada.com [209.29.4.39]) by ietfa.amsl.com (Postfix) with ESMTP id DA5E721F8758 for ; Fri, 9 Nov 2012 10:08:11 -0800 (PST) Received: from ottsvw100.gdcan.com ([172.16.7.212]) by gdcanada.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Nov 2012 13:08:20 -0500 Received: from CGYSVW100.gdcan.com ([172.31.27.211]) by ottsvw100.gdcan.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Nov 2012 13:08:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain;charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Nov 2012 11:08:05 -0700 Message-ID: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DLEP Lite? (Teco Boot) Thread-Index: Ac2+jVdl8St7CxHOQImNx8g7RjcZBAADdN/w References: From: "Viberg, Neil" To: X-OriginalArrivalTime: 09 Nov 2012 18:08:06.0546 (UTC) FILETIME=[2B179720:01CDBEA5] Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 18:08:12 -0000 Folks, I hadn't heard the security argument for DLEP Lite before but, having some limited exposure to red-black boundaries, I can understand the desire/need for a one-way protocol. I have colleagues who would like a DLEP Lite for a different reason. They see it as a way to reduce development cost along with cpu and communication load on the modem side of the information flow. Another situation where DLEP Lite would be sufficient is with a modem that isn't sophisticated enough to determine its neighbors but could give basic information about its transmission state. DLEP Lite would offer an extremely lightweight and standardized way to learn about the modem and its basic capabilities. A few things to consider: 1. having a DLEP Lite does not lessen the work the router has to do. Whether the modem thinks it has a session or not, the router will need to treat the flow of data from the modem as a session except without any well known points at which failure can be detected. I think that the router's response to failed modems will be slower, in general, with a DLEP Lite. 2. users of DLEP Lite would need to carefully balance the modem savings with the system cost. With DLEP Lite the amount of messaging towards the router will need to have a rate that is a function of the number of modem neighbors, rate of significant change of link parameters *and* the probability that a specific DLEP message can be lost. DLEP Lite moves the information model to a pure soft state approach while the original DLEP model is much closer to a hard state model. This implies that the consistency of router state depends on the flow of information from the modem to overcome the packet loss rate *but* there is no communication from the router back to the modem so it is very difficult for the modem to estimate packet loss rate. If one has a strong desire for consistent state in the router and the modem has a large number of neighbors and/or volatile links then the messaging rate may be considerably higher than the ACKed exchange of a straight DLEP implementation. 3. DLEP Lite would need to be a required part of the router and the modem would be able to implement either the full DLEP or DLEP Lite. Cheers, Neil Viberg Network Architect C3ISS Business Unit General Dynamics Canada P.S. I personally tend to use the generic term bearer rather than modem because the modem is just one of many components in every device I've worked with. -----Excerpt from manet Digest Vol 102 Issue 117----- ---------------------------------------------------------------------- Message: 1 Date: Fri, 9 Nov 2012 13:59:39 +0100 From: Teco Boot To: "Ivancic, William D. (GRC-RHN0)" Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Lite? Message-ID: <55238ACB-F5B2-40EB-A906-96E0F4387928@inf-net.nl> Content-Type: text/plain; charset=3D"windows-1252" The reason why I need a one way protocol is that I have to deal with some security mandates. All outgoing traffic from the router port has to be crypted packets, or related to the crypto engine. This piece of code for crypto and firewall needs to be reviewed and certified. Import of data is less a problem. During WGLC review, I'll start reading security considerations. When it describes something like "this protocol does not introduce a covert channel", I'll get more interested. As I see it right now, there is a need to split the DLEP protocol draft. The basic mode would be DLEP-Lite, and provide transport from radio to router only. Maybe DLEP-heavy is a better name for it, it could need more lines of code. And more bits on the wire. Teco Op 8 nov. 2012, om 20:00 heeft Ivancic, William D. (GRC-RHN0) het volgende geschreven: > DLEP, at least the last time I read it, which was a month or two ago, is client/server based with sessions setup between radio and router. ModemLPA simply has the radio (or crypto device or whatever) sending out status packets either periodically or when something changes. ModemLPA could send either to all routers address, a unicast address, or perhaps a organizationally scoped multicast address. > > "It should be possible to use the DLEP message formats without all the signaling required for the DLEP client/server session to perform the functions addressed in this draft. The modem would simply provide link states out via multicast or unicast UDP datagrams (DLEP-Lite)." > > DLEP is designed to operate only over the local-link and does not accommodate systems that are multiple hops away from the modem. Upstream notification would be a simple modification to DLEP (I think). > > "To handle advertisements beyond the local interface, Internet > Protocol version 4 (IPv4) organizational-scoped multicast and > Internet Protocol version 6 (IPv6) site-local multicast MAY be used > with no explicit configuration in the modem. Use of IPv4 > administratively-scoped multicast and IPv6 site-local multicast could > handle both devices that are directly connected to the modem as well > as hosts and applications that are multiple hops away [RFC2365] > [RFC2373]." > > > > > On Nov 7, 2012, at 5:08 PM, Dowdell, John wrote: > >> @Stan and Will >> >> Can you explain exactly what you mean by DLEP Lite, as mentioned in the dying moments of the WG meeting? Lite in what respect? I would not consider DLEP to be particularly overweight, so understanding exactly what you would intend to remove would be useful. >> >> Also, IMHO it is enough work simply to define one DLEP, so having another one to choose from is not likely to help the radio manufacturers along the road to implementation. Having a mandatory core of DLEP, with optional extras, I can support. Having a further cut down edition means you then either have to know beforehand whether the radio supports full or Lite DLEP, or you have to be able to automatically query the radio to find out (which is a feature I suggested long, long ago, you may recall ?.). >> >> Regards >> >> John >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet The information contained in this e-mail message is PRIVATE. It may contain = confidential information and may be legally privileged. It is intended for t= he exclusive use of the addressee(s). If you are not the intended recipient,= you are hereby notified that any dissemination, distribution or reproductio= n of this communication is strictly prohibited. If the intended recipient(s)= cannot be reached or if a transmission problem has occurred, please notify = the sender immediately by return e-mail and destroy all copies of this messa= ge. Thank you. From sratliff@cisco.com Fri Nov 9 11:29:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B73921F84E1 for ; Fri, 9 Nov 2012 11:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsMwqI7XJrBN for ; Fri, 9 Nov 2012 11:29:31 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4F95921F84B0 for ; Fri, 9 Nov 2012 11:29:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8125; q=dns/txt; s=iport; t=1352489371; x=1353698971; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=A+L68E730CkuOzVi5nmDqgZWrJz0ilAdu1kGaMU7Zbg=; b=acZSEwnBNCLOmbUKH9vlkh2RSVtoABX/OIeB0B5VZi/vx8kQfNnJmZ5x KWIBxTs8gL013iX2NuPuTbswQq8L41u51SP7yV/AN3iS4RIl+9dGPoP6F eMHPelR9xPqvFPYqozBF7jH6Rn45E1frxxkgC9AHvsa+bZOpNssFh2Jxw c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAENYnVCtJXHA/2dsb2JhbABEw0OBCIIeAQEBAwEBAQELBAFSAQgLBQsCAQgRAwECAQokJwsdCAEBBA4FCBqHYgYLnXOgEgSMFBQGhU9hA6RTgWuCb4FbCRce X-IronPort-AV: E=McAfee;i="5400,1158,6891"; a="140655608" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 09 Nov 2012 19:29:30 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA9JTUoC006466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Nov 2012 19:29:30 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Fri, 9 Nov 2012 13:29:30 -0600 From: "Stan Ratliff (sratliff)" To: "Viberg, Neil" Thread-Topic: [manet] DLEP Lite? (Teco Boot) Thread-Index: Ac2+jVdl8St7CxHOQImNx8g7RjcZBAADdN/wABHqP4A= Date: Fri, 9 Nov 2012 19:29:29 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> In-Reply-To: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.211] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19350.005 x-tm-as-result: No--36.736900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <5A6C303098A02D40B54054F7ED042EB0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 19:29:34 -0000 One (of many) things that confuses me about DLEP-Lite is the notion that th= e modem (or radio, or bearer) would "strobe" packets to "some address" (let= 's say some sort of site-local scoped multicast address) and not know (or c= are) about responses. What if, in that case, I put multiple routers "behind= " the modem that can hear the strobes? Pretty easy to get the link overload= ed, just as before=85 so, I'm not seeing any general benefit, unless some a= ssumptions are made as to the overall structure of the network. Regards, Stan On Nov 9, 2012, at 1:08 PM, Viberg, Neil wrote: > Folks, >=20 > I hadn't heard the security argument for DLEP Lite before but, having > some limited exposure to red-black boundaries, I can understand the > desire/need for a one-way protocol. >=20 > I have colleagues who would like a DLEP Lite for a different reason. > They see it as a way to reduce development cost along with cpu and > communication load on the modem side of the information flow. >=20 > Another situation where DLEP Lite would be sufficient is with a modem > that isn't sophisticated enough to determine its neighbors but could > give basic information about its transmission state. DLEP Lite would > offer an extremely lightweight and standardized way to learn about the > modem and its basic capabilities. >=20 > A few things to consider: >=20 > 1. having a DLEP Lite does not lessen the work the router has to do. > Whether the modem thinks it has a session or not, the router will need > to treat the flow of data from the modem as a session except without any > well known points at which failure can be detected. I think that the > router's response to failed modems will be slower, in general, with a > DLEP Lite. >=20 > 2. users of DLEP Lite would need to carefully balance the modem savings > with the system cost. With DLEP Lite the amount of messaging towards the > router will need to have a rate that is a function of the number of > modem neighbors, rate of significant change of link parameters *and* the > probability that a specific DLEP message can be lost. DLEP Lite moves > the information model to a pure soft state approach while the original > DLEP model is much closer to a hard state model. This implies that the > consistency of router state depends on the flow of information from the > modem to overcome the packet loss rate *but* there is no communication > from the router back to the modem so it is very difficult for the modem > to estimate packet loss rate. If one has a strong desire for consistent > state in the router and the modem has a large number of neighbors and/or > volatile links then the messaging rate may be considerably higher than > the ACKed exchange of a straight DLEP implementation. >=20 > 3. DLEP Lite would need to be a required part of the router and the > modem would be able to implement either the full DLEP or DLEP Lite. >=20 >=20 > Cheers, > Neil Viberg > Network Architect > C3ISS Business Unit > General Dynamics Canada >=20 > P.S. I personally tend to use the generic term bearer rather than modem > because the modem is just one of many components in every device I've > worked with.=20 >=20 >=20 > -----Excerpt from manet Digest Vol 102 Issue 117----- >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Fri, 9 Nov 2012 13:59:39 +0100 > From: Teco Boot > To: "Ivancic, William D. (GRC-RHN0)" > Cc: "manet@ietf.org" > Subject: Re: [manet] DLEP Lite? > Message-ID: <55238ACB-F5B2-40EB-A906-96E0F4387928@inf-net.nl> > Content-Type: text/plain; charset=3D"windows-1252" >=20 > The reason why I need a one way protocol is that I have to deal with > some security mandates. All outgoing traffic from the router port has to > be crypted packets, or related to the crypto engine. This piece of code > for crypto and firewall needs to be reviewed and certified. Import of > data is less a problem. >=20 > During WGLC review, I'll start reading security considerations. When it > describes something like "this protocol does not introduce a covert > channel", I'll get more interested. As I see it right now, there is a > need to split the DLEP protocol draft. The basic mode would be > DLEP-Lite, and provide transport from radio to router only. Maybe > DLEP-heavy is a better name for it, it could need more lines of code. > And more bits on the wire. >=20 > Teco >=20 > Op 8 nov. 2012, om 20:00 heeft Ivancic, William D. (GRC-RHN0) het > volgende geschreven: >=20 >> DLEP, at least the last time I read it, which was a month or two ago, > is client/server based with sessions setup between radio and router. > ModemLPA simply has the radio (or crypto device or whatever) sending out > status packets either periodically or when something changes. ModemLPA > could send either to all routers address, a unicast address, or perhaps > a organizationally scoped multicast address. =20 >>=20 >> "It should be possible to use the DLEP message formats without all the > signaling required for the DLEP client/server session to perform the > functions addressed in this draft. The modem would simply provide link > states out via multicast or unicast UDP datagrams (DLEP-Lite)." >>=20 >> DLEP is designed to operate only over the local-link and does not > accommodate systems that are multiple hops away from the modem. Upstream > notification would be a simple modification to DLEP (I think). >>=20 >> "To handle advertisements beyond the local interface, Internet >> Protocol version 4 (IPv4) organizational-scoped multicast and >> Internet Protocol version 6 (IPv6) site-local multicast MAY be used >> with no explicit configuration in the modem. Use of IPv4 >> administratively-scoped multicast and IPv6 site-local multicast > could >> handle both devices that are directly connected to the modem as > well >> as hosts and applications that are multiple hops away [RFC2365] >> [RFC2373]." >>=20 >>=20 >>=20 >>=20 >> On Nov 7, 2012, at 5:08 PM, Dowdell, John wrote: >>=20 >>> @Stan and Will >>>=20 >>> Can you explain exactly what you mean by DLEP Lite, as mentioned in > the dying moments of the WG meeting? Lite in what respect? I would not > consider DLEP to be particularly overweight, so understanding exactly > what you would intend to remove would be useful. >>>=20 >>> Also, IMHO it is enough work simply to define one DLEP, so having > another one to choose from is not likely to help the radio manufacturers > along the road to implementation. Having a mandatory core of DLEP, with > optional extras, I can support. Having a further cut down edition means > you then either have to know beforehand whether the radio supports full > or Lite DLEP, or you have to be able to automatically query the radio to > find out (which is a feature I suggested long, long ago, you may recall > ?.). >>>=20 >>> Regards >>>=20 >>> John >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > The information contained in this e-mail message is PRIVATE. It may conta= in confidential information and may be legally privileged. It is intended f= or the exclusive use of the addressee(s). If you are not the intended recip= ient, you are hereby notified that any dissemination, distribution or repro= duction of this communication is strictly prohibited. If the intended recip= ient(s) cannot be reached or if a transmission problem has occurred, please= notify the sender immediately by return e-mail and destroy all copies of t= his message.=20 > Thank you.=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Fri Nov 9 11:42:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E4E21F8540 for ; Fri, 9 Nov 2012 11:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vmok1We-Ub6 for ; Fri, 9 Nov 2012 11:42:53 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 99F3B21F853E for ; Fri, 9 Nov 2012 11:42:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2484; q=dns/txt; s=iport; t=1352490173; x=1353699773; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=657c5i36SE3yR6Far8PnEF8P43Ycf0J8UfzcWFNYqm0=; b=Q8fW+kU1MM7KjTV9lz70ehqEc9vBJpJaVnd9aKwhClY8WhonewKpLLxL KE1fQLnmS09QQe873RgbMVH40Hkg911LEoN7h2ZDZsjoc90Y0AAyqpsQA gDCdvEwqfb7hFifPvCbmqjYetqzx2gpNWSTrtP6pqiQ05LE/RSpx/pUib k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMpbnVCtJXG9/2dsb2JhbABEw0OBCIIeAQEBAwESAWQCEAIBCCIdBzIUEQIEAQ0FCAEZh2IGC51zoBWMFIVpYQOIJY5yjTyBa4Jvghk X-IronPort-AV: E=McAfee;i="5400,1158,6891"; a="140683386" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 09 Nov 2012 19:42:53 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA9Jgqi0007129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Nov 2012 19:42:52 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Fri, 9 Nov 2012 13:42:52 -0600 From: "Stan Ratliff (sratliff)" To: Mohamad Sbeiti , " List" Thread-Topic: New Version Notification for draft-sbeiti-karp-paser-00.txt Thread-Index: AQJzQGZmRWtrYF9C59srSVhtmVKh2JaWLDxQgAEZeoA= Date: Fri, 9 Nov 2012 19:42:51 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B085@xmb-aln-x03.cisco.com> References: <20121109075706.22359.16028.idtracker@ietfa.amsl.com> <04e701cdbe56$f192d850$d4b888f0$@tu-dortmund.de> In-Reply-To: <04e701cdbe56$f192d850$d4b888f0$@tu-dortmund.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.211] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19350.005 x-tm-as-result: No--33.259300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Christian Wietfeld Subject: Re: [manet] New Version Notification for draft-sbeiti-karp-paser-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 19:42:54 -0000 MANET WG -=20 FYI. Regards, Stan On Nov 9, 2012, at 3:48 AM, Mohamad Sbeiti wrote: >=20 > Find below the corresponding links to the PASER draft. >=20 > Thank you and best regards, > Mohamad >=20 > -- > Dipl.-Ing. Mohamad Sbeiti > Communication Networks Institute (CNI) > Technische Universit=E4t Dortmund > Otto-Hahn-Strasse 6 > D-44227 Dortmund, Germany >=20 > Fon: +49(0)2 31/755-6128 > Fax: +49(0)2 31/755-6136 > Room: C1-04-103 > http://www.kn.e-technik.tu-dortmund.de/ >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Gesendet: Freitag, 9. November 2012 08:57 > An: mohamad.sbeiti@tu-dortmund.de > Cc: christian.wietfeld@tu-dortmund.de > Betreff: New Version Notification for draft-sbeiti-karp-paser-00.txt >=20 >=20 > A new version of I-D, draft-sbeiti-karp-paser-00.txt has been successfull= y submitted by Mohamad Sbeiti and posted to the IETF repository. >=20 > Filename: draft-sbeiti-karp-paser > Revision: 00 > Title: PASER: Position Aware Secure and Efficient Mesh Routing Protocol > Creation date: 2012-11-08 > WG ID: Individual Submission > Number of pages: 37 > URL: http://www.ietf.org/internet-drafts/draft-sbeiti-karp-pa= ser-00.txt > Status: http://datatracker.ietf.org/doc/draft-sbeiti-karp-paser > Htmlized: http://tools.ietf.org/html/draft-sbeiti-karp-paser-00 >=20 >=20 > Abstract: > The Position Aware Secure and Efficient Mesh Routing Protocol > (PASER) aims to efficiently establish accurate routes in terms of > metric and legitimated mesh nodes in wireless mesh networks in > presence of external attackers. For this end, it achieves the > following goals: Node authentication, message freshness and > integrity, and neighbor transmissions authentication. The novelty of > PASER lies essentially in combining asymmetric cryptography with > Merkle tree (a lightweight cryptographic primitive) and a keyed-hash > function to secure the routing messages. Another key feature of > PASER is integrating (virtual) geographical positions of nodes in > its hierarchical reactive routing process to enable an advanced > network management while mitigating the wormhole attack. Apart from > that, to address the problem of node compromise, PASER endorses a > key revocation scheme to efficiently exclude those nodes. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 From teco@inf-net.nl Fri Nov 9 11:45:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581AB21F8503 for ; Fri, 9 Nov 2012 11:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lmc910YZNY3V for ; Fri, 9 Nov 2012 11:45:44 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5963521F84FF for ; Fri, 9 Nov 2012 11:45:43 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so3242657pbb.31 for ; Fri, 09 Nov 2012 11:45:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=mVfuZN1xcptCCFyWWPnO/F81w8bVL03H+rYQPmbM7cE=; b=GfnP1Vezk8tNkp74ckunb2qHh1IYv+eu2lkOZpXk+o3lGwUFnD5eVUsx13FiyKQ/ep PX0UHO9z8wjdWwOHrLhrbdlk751PVJ0YLRxdVrQ0qjyWJvlovxiedR136tYkxxVcGsx2 8paoI6s9738TiRC21Bjyd5cfpkTSosCZPxs+30/T0+hSQa/nNtx8iaZfoEMFtSXl4o9M ZOmDrbWqh2O/XBa1jnWRDe+vh30ZRSAZOb4t5WfHOzbfWhYn6I6hCWwSPDb9oIM95uFY 0c3Dp66cpqscy1wib+7VTvNJuElW9lOhS/UXK+aPBBK6kbWYAV6usiqKKJM4JjWRJCgt zSzA== Received: by 10.68.197.101 with SMTP id it5mr36997301pbc.91.1352490343361; Fri, 09 Nov 2012 11:45:43 -0800 (PST) Received: from dhcp-1616.meeting.ietf.org (dhcp-1616.meeting.ietf.org. [130.129.22.22]) by mx.google.com with ESMTPS id pu4sm11081261pbb.72.2012.11.09.11.45.41 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 11:45:42 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> Date: Fri, 9 Nov 2012 20:45:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkiHpl6TmzopNhezxeLBsVVRHXCfrEjob0LGTM3nrCBVEbF3tgshcqz+SlesfJyhN7tRZQD Cc: "" , "Viberg, Neil" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 19:45:45 -0000 Which link gets overloaded? I cannot see why there would be any = difference. Routers are passive, radio just send its info for other = peers. But, on other side of RF link, there is info for each router on this = side. Info is per MAC address. In fact, MAC addresses could be for a = router or a host. If you had flow control in mind, that is another story. This doesn't = meet my requirements, as stated before a couple of times. Should I open a ticket for this? Teco Op 9 nov. 2012, om 20:29 heeft Stan Ratliff (sratliff) het volgende = geschreven: > One (of many) things that confuses me about DLEP-Lite is the notion = that the modem (or radio, or bearer) would "strobe" packets to "some = address" (let's say some sort of site-local scoped multicast address) = and not know (or care) about responses. What if, in that case, I put = multiple routers "behind" the modem that can hear the strobes? Pretty = easy to get the link overloaded, just as before=85 so, I'm not seeing = any general benefit, unless some assumptions are made as to the overall = structure of the network. >=20 > Regards, > Stan >=20 > On Nov 9, 2012, at 1:08 PM, Viberg, Neil wrote: >=20 >> Folks, >>=20 >> I hadn't heard the security argument for DLEP Lite before but, having >> some limited exposure to red-black boundaries, I can understand the >> desire/need for a one-way protocol. >>=20 >> I have colleagues who would like a DLEP Lite for a different reason. >> They see it as a way to reduce development cost along with cpu and >> communication load on the modem side of the information flow. >>=20 >> Another situation where DLEP Lite would be sufficient is with a modem >> that isn't sophisticated enough to determine its neighbors but could >> give basic information about its transmission state. DLEP Lite would >> offer an extremely lightweight and standardized way to learn about = the >> modem and its basic capabilities. >>=20 >> A few things to consider: >>=20 >> 1. having a DLEP Lite does not lessen the work the router has to do. >> Whether the modem thinks it has a session or not, the router will = need >> to treat the flow of data from the modem as a session except without = any >> well known points at which failure can be detected. I think that the >> router's response to failed modems will be slower, in general, with a >> DLEP Lite. >>=20 >> 2. users of DLEP Lite would need to carefully balance the modem = savings >> with the system cost. With DLEP Lite the amount of messaging towards = the >> router will need to have a rate that is a function of the number of >> modem neighbors, rate of significant change of link parameters *and* = the >> probability that a specific DLEP message can be lost. DLEP Lite moves >> the information model to a pure soft state approach while the = original >> DLEP model is much closer to a hard state model. This implies that = the >> consistency of router state depends on the flow of information from = the >> modem to overcome the packet loss rate *but* there is no = communication >> from the router back to the modem so it is very difficult for the = modem >> to estimate packet loss rate. If one has a strong desire for = consistent >> state in the router and the modem has a large number of neighbors = and/or >> volatile links then the messaging rate may be considerably higher = than >> the ACKed exchange of a straight DLEP implementation. >>=20 >> 3. DLEP Lite would need to be a required part of the router and the >> modem would be able to implement either the full DLEP or DLEP Lite. >>=20 >>=20 >> Cheers, >> Neil Viberg >> Network Architect >> C3ISS Business Unit >> General Dynamics Canada >>=20 >> P.S. I personally tend to use the generic term bearer rather than = modem >> because the modem is just one of many components in every device I've >> worked with.=20 >>=20 >>=20 >> -----Excerpt from manet Digest Vol 102 Issue 117----- >>=20 >> = ---------------------------------------------------------------------- >>=20 >> Message: 1 >> Date: Fri, 9 Nov 2012 13:59:39 +0100 >> From: Teco Boot >> To: "Ivancic, William D. (GRC-RHN0)" >> Cc: "manet@ietf.org" >> Subject: Re: [manet] DLEP Lite? >> Message-ID: <55238ACB-F5B2-40EB-A906-96E0F4387928@inf-net.nl> >> Content-Type: text/plain; charset=3D"windows-1252" >>=20 >> The reason why I need a one way protocol is that I have to deal with >> some security mandates. All outgoing traffic from the router port has = to >> be crypted packets, or related to the crypto engine. This piece of = code >> for crypto and firewall needs to be reviewed and certified. Import = of >> data is less a problem. >>=20 >> During WGLC review, I'll start reading security considerations. When = it >> describes something like "this protocol does not introduce a covert >> channel", I'll get more interested. As I see it right now, there is a >> need to split the DLEP protocol draft. The basic mode would be >> DLEP-Lite, and provide transport from radio to router only. Maybe >> DLEP-heavy is a better name for it, it could need more lines of code. >> And more bits on the wire. >>=20 >> Teco >>=20 >> Op 8 nov. 2012, om 20:00 heeft Ivancic, William D. (GRC-RHN0) het >> volgende geschreven: >>=20 >>> DLEP, at least the last time I read it, which was a month or two = ago, >> is client/server based with sessions setup between radio and router. >> ModemLPA simply has the radio (or crypto device or whatever) sending = out >> status packets either periodically or when something changes. = ModemLPA >> could send either to all routers address, a unicast address, or = perhaps >> a organizationally scoped multicast address. =20 >>>=20 >>> "It should be possible to use the DLEP message formats without all = the >> signaling required for the DLEP client/server session to perform the >> functions addressed in this draft. The modem would simply provide = link >> states out via multicast or unicast UDP datagrams (DLEP-Lite)." >>>=20 >>> DLEP is designed to operate only over the local-link and does not >> accommodate systems that are multiple hops away from the modem. = Upstream >> notification would be a simple modification to DLEP (I think). >>>=20 >>> "To handle advertisements beyond the local interface, Internet >>> Protocol version 4 (IPv4) organizational-scoped multicast and >>> Internet Protocol version 6 (IPv6) site-local multicast MAY be used >>> with no explicit configuration in the modem. Use of IPv4 >>> administratively-scoped multicast and IPv6 site-local multicast >> could >>> handle both devices that are directly connected to the modem as >> well >>> as hosts and applications that are multiple hops away [RFC2365] >>> [RFC2373]." >>>=20 >>>=20 >>>=20 >>>=20 >>> On Nov 7, 2012, at 5:08 PM, Dowdell, John wrote: >>>=20 >>>> @Stan and Will >>>>=20 >>>> Can you explain exactly what you mean by DLEP Lite, as mentioned in >> the dying moments of the WG meeting? Lite in what respect? I would = not >> consider DLEP to be particularly overweight, so understanding exactly >> what you would intend to remove would be useful. >>>>=20 >>>> Also, IMHO it is enough work simply to define one DLEP, so having >> another one to choose from is not likely to help the radio = manufacturers >> along the road to implementation. Having a mandatory core of DLEP, = with >> optional extras, I can support. Having a further cut down edition = means >> you then either have to know beforehand whether the radio supports = full >> or Lite DLEP, or you have to be able to automatically query the radio = to >> find out (which is a feature I suggested long, long ago, you may = recall >> ?.). >>>>=20 >>>> Regards >>>>=20 >>>> John >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> The information contained in this e-mail message is PRIVATE. It may = contain confidential information and may be legally privileged. It is = intended for the exclusive use of the addressee(s). If you are not the = intended recipient, you are hereby notified that any dissemination, = distribution or reproduction of this communication is strictly = prohibited. If the intended recipient(s) cannot be reached or if a = transmission problem has occurred, please notify the sender immediately = by return e-mail and destroy all copies of this message.=20 >> Thank you.=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Fri Nov 9 11:51:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A9021F860C for ; Fri, 9 Nov 2012 11:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99U6vDgOxkvJ for ; Fri, 9 Nov 2012 11:51:54 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 40B6C21F85F0 for ; Fri, 9 Nov 2012 11:51:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9646; q=dns/txt; s=iport; t=1352490712; x=1353700312; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+kQjnJG8GyveIXKBVMOOu6tcCmemWCBaVWc/uXm96+k=; b=PtK989yj3bl/sB0cyvHD9rpZguCsTG+hKgi4SZ75scxLTrXvwZnYo6EF 6Bea5fOawrUo7niCVY+Zfcmqbs1KIZIJahHTmuWH3/gl+Be8VHKe0GJdr 9xE31nhhgC9zJDypd7vi4+mKXzuKkGjsS2TSgCljSxdLYsSNMAARzo2fl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAB5enVCtJV2Z/2dsb2JhbABEw0KBCIIeAQEBAwEBAQELBAFSAQgLBQsCAQgRAwECAQokJwsdCAEBBA4FCBqHYgYLnXWgDwSMFBQGCoVFYQOkU4Frgm+BWwkXHg X-IronPort-AV: E=McAfee;i="5400,1158,6891"; a="140685972" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 09 Nov 2012 19:51:51 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA9Jppvs031033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Nov 2012 19:51:51 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Fri, 9 Nov 2012 13:51:50 -0600 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] DLEP Lite? (Teco Boot) Thread-Index: Ac2+jVdl8St7CxHOQImNx8g7RjcZBAADdN/wABHqP4AAAJBkAAAANyIA Date: Fri, 9 Nov 2012 19:51:50 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.211] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19350.005 x-tm-as-result: No--36.753400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <7644A18CCF9BC343B34C466745561668@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Viberg, Neil" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 19:51:56 -0000 On Nov 9, 2012, at 2:45 PM, Teco Boot wrote: > Which link gets overloaded? I cannot see why there would be any differenc= e. Routers are passive, radio just send its info for other peers. >=20 > But, on other side of RF link, there is info for each router on this side= . Info is per MAC address. In fact, MAC addresses could be for a router or = a host. How? How did the far-end radio get the MAC information on its routers? Beca= use I assume that it, too, is in "send only" mode, therefore, it knows *not= hing* about the router or routers on its end (just as the "local radio" kno= ws nothing about local devices)=85. that's part of the whole point on DLEP. And no, no ticket required. Stan >=20 > If you had flow control in mind, that is another story. This doesn't meet= my requirements, as stated before a couple of times. >=20 > Should I open a ticket for this? >=20 > Teco >=20 > Op 9 nov. 2012, om 20:29 heeft Stan Ratliff (sratliff) het volgende gesch= reven: >=20 >> One (of many) things that confuses me about DLEP-Lite is the notion that= the modem (or radio, or bearer) would "strobe" packets to "some address" (= let's say some sort of site-local scoped multicast address) and not know (o= r care) about responses. What if, in that case, I put multiple routers "beh= ind" the modem that can hear the strobes? Pretty easy to get the link overl= oaded, just as before=85 so, I'm not seeing any general benefit, unless som= e assumptions are made as to the overall structure of the network. >>=20 >> Regards, >> Stan >>=20 >> On Nov 9, 2012, at 1:08 PM, Viberg, Neil wrote: >>=20 >>> Folks, >>>=20 >>> I hadn't heard the security argument for DLEP Lite before but, having >>> some limited exposure to red-black boundaries, I can understand the >>> desire/need for a one-way protocol. >>>=20 >>> I have colleagues who would like a DLEP Lite for a different reason. >>> They see it as a way to reduce development cost along with cpu and >>> communication load on the modem side of the information flow. >>>=20 >>> Another situation where DLEP Lite would be sufficient is with a modem >>> that isn't sophisticated enough to determine its neighbors but could >>> give basic information about its transmission state. DLEP Lite would >>> offer an extremely lightweight and standardized way to learn about the >>> modem and its basic capabilities. >>>=20 >>> A few things to consider: >>>=20 >>> 1. having a DLEP Lite does not lessen the work the router has to do. >>> Whether the modem thinks it has a session or not, the router will need >>> to treat the flow of data from the modem as a session except without an= y >>> well known points at which failure can be detected. I think that the >>> router's response to failed modems will be slower, in general, with a >>> DLEP Lite. >>>=20 >>> 2. users of DLEP Lite would need to carefully balance the modem savings >>> with the system cost. With DLEP Lite the amount of messaging towards th= e >>> router will need to have a rate that is a function of the number of >>> modem neighbors, rate of significant change of link parameters *and* th= e >>> probability that a specific DLEP message can be lost. DLEP Lite moves >>> the information model to a pure soft state approach while the original >>> DLEP model is much closer to a hard state model. This implies that the >>> consistency of router state depends on the flow of information from the >>> modem to overcome the packet loss rate *but* there is no communication >>> from the router back to the modem so it is very difficult for the modem >>> to estimate packet loss rate. If one has a strong desire for consistent >>> state in the router and the modem has a large number of neighbors and/o= r >>> volatile links then the messaging rate may be considerably higher than >>> the ACKed exchange of a straight DLEP implementation. >>>=20 >>> 3. DLEP Lite would need to be a required part of the router and the >>> modem would be able to implement either the full DLEP or DLEP Lite. >>>=20 >>>=20 >>> Cheers, >>> Neil Viberg >>> Network Architect >>> C3ISS Business Unit >>> General Dynamics Canada >>>=20 >>> P.S. I personally tend to use the generic term bearer rather than modem >>> because the modem is just one of many components in every device I've >>> worked with.=20 >>>=20 >>>=20 >>> -----Excerpt from manet Digest Vol 102 Issue 117----- >>>=20 >>> ---------------------------------------------------------------------- >>>=20 >>> Message: 1 >>> Date: Fri, 9 Nov 2012 13:59:39 +0100 >>> From: Teco Boot >>> To: "Ivancic, William D. (GRC-RHN0)" >>> Cc: "manet@ietf.org" >>> Subject: Re: [manet] DLEP Lite? >>> Message-ID: <55238ACB-F5B2-40EB-A906-96E0F4387928@inf-net.nl> >>> Content-Type: text/plain; charset=3D"windows-1252" >>>=20 >>> The reason why I need a one way protocol is that I have to deal with >>> some security mandates. All outgoing traffic from the router port has t= o >>> be crypted packets, or related to the crypto engine. This piece of code >>> for crypto and firewall needs to be reviewed and certified. Import of >>> data is less a problem. >>>=20 >>> During WGLC review, I'll start reading security considerations. When it >>> describes something like "this protocol does not introduce a covert >>> channel", I'll get more interested. As I see it right now, there is a >>> need to split the DLEP protocol draft. The basic mode would be >>> DLEP-Lite, and provide transport from radio to router only. Maybe >>> DLEP-heavy is a better name for it, it could need more lines of code. >>> And more bits on the wire. >>>=20 >>> Teco >>>=20 >>> Op 8 nov. 2012, om 20:00 heeft Ivancic, William D. (GRC-RHN0) het >>> volgende geschreven: >>>=20 >>>> DLEP, at least the last time I read it, which was a month or two ago, >>> is client/server based with sessions setup between radio and router. >>> ModemLPA simply has the radio (or crypto device or whatever) sending ou= t >>> status packets either periodically or when something changes. ModemLPA >>> could send either to all routers address, a unicast address, or perhaps >>> a organizationally scoped multicast address. =20 >>>>=20 >>>> "It should be possible to use the DLEP message formats without all the >>> signaling required for the DLEP client/server session to perform the >>> functions addressed in this draft. The modem would simply provide link >>> states out via multicast or unicast UDP datagrams (DLEP-Lite)." >>>>=20 >>>> DLEP is designed to operate only over the local-link and does not >>> accommodate systems that are multiple hops away from the modem. Upstrea= m >>> notification would be a simple modification to DLEP (I think). >>>>=20 >>>> "To handle advertisements beyond the local interface, Internet >>>> Protocol version 4 (IPv4) organizational-scoped multicast and >>>> Internet Protocol version 6 (IPv6) site-local multicast MAY be used >>>> with no explicit configuration in the modem. Use of IPv4 >>>> administratively-scoped multicast and IPv6 site-local multicast >>> could >>>> handle both devices that are directly connected to the modem as >>> well >>>> as hosts and applications that are multiple hops away [RFC2365] >>>> [RFC2373]." >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Nov 7, 2012, at 5:08 PM, Dowdell, John wrote: >>>>=20 >>>>> @Stan and Will >>>>>=20 >>>>> Can you explain exactly what you mean by DLEP Lite, as mentioned in >>> the dying moments of the WG meeting? Lite in what respect? I would not >>> consider DLEP to be particularly overweight, so understanding exactly >>> what you would intend to remove would be useful. >>>>>=20 >>>>> Also, IMHO it is enough work simply to define one DLEP, so having >>> another one to choose from is not likely to help the radio manufacturer= s >>> along the road to implementation. Having a mandatory core of DLEP, with >>> optional extras, I can support. Having a further cut down edition means >>> you then either have to know beforehand whether the radio supports full >>> or Lite DLEP, or you have to be able to automatically query the radio t= o >>> find out (which is a feature I suggested long, long ago, you may recall >>> ?.). >>>>>=20 >>>>> Regards >>>>>=20 >>>>> John >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>> The information contained in this e-mail message is PRIVATE. It may con= tain confidential information and may be legally privileged. It is intended= for the exclusive use of the addressee(s). If you are not the intended rec= ipient, you are hereby notified that any dissemination, distribution or rep= roduction of this communication is strictly prohibited. If the intended rec= ipient(s) cannot be reached or if a transmission problem has occurred, plea= se notify the sender immediately by return e-mail and destroy all copies of= this message.=20 >>> Thank you.=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From Neil.Viberg@gdcanada.com Fri Nov 9 12:39:28 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7EF21F86D2 for ; Fri, 9 Nov 2012 12:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W1DplGYKJ+a for ; Fri, 9 Nov 2012 12:39:27 -0800 (PST) Received: from gdcanada.com (smtp.gdcanada.com [209.29.4.39]) by ietfa.amsl.com (Postfix) with ESMTP id 9516721F868E for ; Fri, 9 Nov 2012 12:39:22 -0800 (PST) Received: from ottsvw100.gdcan.com ([172.16.7.212]) by gdcanada.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Nov 2012 15:39:33 -0500 Received: from CGYSVW100.gdcan.com ([172.31.27.211]) by ottsvw100.gdcan.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Nov 2012 15:39:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain;charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Nov 2012 13:39:18 -0700 Message-ID: <2142BCFA1F7F0D468F8EE6C8DE719E6805B70903@CGYSVW100.gdcan.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP Lite? (Teco Boot) Thread-Index: Ac2+jVdl8St7CxHOQImNx8g7RjcZBAADdN/wABHqP4AACm0wUA== References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> From: "Viberg, Neil" To: "Stan Ratliff (sratliff)" X-OriginalArrivalTime: 09 Nov 2012 20:39:19.0638 (UTC) FILETIME=[4B138F60:01CDBEBA] Cc: manet@ietf.org Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 20:39:28 -0000 Stan, Good point. I personally would find it a bit odd to just add a bearer into a situation where multiple routers could each view it as "their" link and I haven't encountered that situation but others might. Neil -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] Sent: Friday, November 09, 2012 12:29 PM To: Viberg, Neil Cc: Subject: Re: [manet] DLEP Lite? (Teco Boot) One (of many) things that confuses me about DLEP-Lite is the notion that the modem (or radio, or bearer) would "strobe" packets to "some address" (let's say some sort of site-local scoped multicast address) and not know (or care) about responses. What if, in that case, I put multiple routers "behind" the modem that can hear the strobes? Pretty easy to get the link overloaded, just as before... so, I'm not seeing any general benefit, unless some assumptions are made as to the overall structure of the network. Regards, Stan On Nov 9, 2012, at 1:08 PM, Viberg, Neil wrote: > Folks, > > I hadn't heard the security argument for DLEP Lite before but, having > some limited exposure to red-black boundaries, I can understand the > desire/need for a one-way protocol. > > I have colleagues who would like a DLEP Lite for a different reason. > They see it as a way to reduce development cost along with cpu and > communication load on the modem side of the information flow. > > Another situation where DLEP Lite would be sufficient is with a modem > that isn't sophisticated enough to determine its neighbors but could > give basic information about its transmission state. DLEP Lite would > offer an extremely lightweight and standardized way to learn about the > modem and its basic capabilities. > > A few things to consider: > > 1. having a DLEP Lite does not lessen the work the router has to do. > Whether the modem thinks it has a session or not, the router will need > to treat the flow of data from the modem as a session except without > any well known points at which failure can be detected. I think that > the router's response to failed modems will be slower, in general, > with a DLEP Lite. > > 2. users of DLEP Lite would need to carefully balance the modem > savings with the system cost. With DLEP Lite the amount of messaging > towards the router will need to have a rate that is a function of the > number of modem neighbors, rate of significant change of link > parameters *and* the probability that a specific DLEP message can be > lost. DLEP Lite moves the information model to a pure soft state > approach while the original DLEP model is much closer to a hard state > model. This implies that the consistency of router state depends on > the flow of information from the modem to overcome the packet loss > rate *but* there is no communication from the router back to the modem > so it is very difficult for the modem to estimate packet loss rate. If > one has a strong desire for consistent state in the router and the > modem has a large number of neighbors and/or volatile links then the > messaging rate may be considerably higher than the ACKed exchange of a straight DLEP implementation. > > 3. DLEP Lite would need to be a required part of the router and the > modem would be able to implement either the full DLEP or DLEP Lite. > > > Cheers, > Neil Viberg > Network Architect > C3ISS Business Unit > General Dynamics Canada > > P.S. I personally tend to use the generic term bearer rather than > modem because the modem is just one of many components in every device > I've worked with. > > > -----Excerpt from manet Digest Vol 102 Issue 117----- > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 9 Nov 2012 13:59:39 +0100 > From: Teco Boot > To: "Ivancic, William D. (GRC-RHN0)" > Cc: "manet@ietf.org" > Subject: Re: [manet] DLEP Lite? > Message-ID: <55238ACB-F5B2-40EB-A906-96E0F4387928@inf-net.nl> > Content-Type: text/plain; charset=3D"windows-1252" > > The reason why I need a one way protocol is that I have to deal with > some security mandates. All outgoing traffic from the router port has > to be crypted packets, or related to the crypto engine. This piece of > code for crypto and firewall needs to be reviewed and certified. > Import of data is less a problem. > > During WGLC review, I'll start reading security considerations. When > it describes something like "this protocol does not introduce a covert > channel", I'll get more interested. As I see it right now, there is a > need to split the DLEP protocol draft. The basic mode would be > DLEP-Lite, and provide transport from radio to router only. Maybe > DLEP-heavy is a better name for it, it could need more lines of code. > And more bits on the wire. > > Teco > > Op 8 nov. 2012, om 20:00 heeft Ivancic, William D. (GRC-RHN0) het > volgende geschreven: > >> DLEP, at least the last time I read it, which was a month or two ago, > is client/server based with sessions setup between radio and router. > ModemLPA simply has the radio (or crypto device or whatever) sending > out status packets either periodically or when something changes. > ModemLPA could send either to all routers address, a unicast address, > or perhaps a organizationally scoped multicast address. >> >> "It should be possible to use the DLEP message formats without all >> the > signaling required for the DLEP client/server session to perform the > functions addressed in this draft. The modem would simply provide > link states out via multicast or unicast UDP datagrams (DLEP-Lite)." >> >> DLEP is designed to operate only over the local-link and does not > accommodate systems that are multiple hops away from the modem. > Upstream notification would be a simple modification to DLEP (I think). >> >> "To handle advertisements beyond the local interface, Internet >> Protocol version 4 (IPv4) organizational-scoped multicast and >> Internet Protocol version 6 (IPv6) site-local multicast MAY be used >> with no explicit configuration in the modem. Use of IPv4 >> administratively-scoped multicast and IPv6 site-local multicast > could >> handle both devices that are directly connected to the modem as > well >> as hosts and applications that are multiple hops away [RFC2365] >> [RFC2373]." >> >> >> >> >> On Nov 7, 2012, at 5:08 PM, Dowdell, John wrote: >> >>> @Stan and Will >>> >>> Can you explain exactly what you mean by DLEP Lite, as mentioned in > the dying moments of the WG meeting? Lite in what respect? I would not > consider DLEP to be particularly overweight, so understanding exactly > what you would intend to remove would be useful. >>> >>> Also, IMHO it is enough work simply to define one DLEP, so having > another one to choose from is not likely to help the radio > manufacturers along the road to implementation. Having a mandatory > core of DLEP, with optional extras, I can support. Having a further > cut down edition means you then either have to know beforehand whether > the radio supports full or Lite DLEP, or you have to be able to > automatically query the radio to find out (which is a feature I > suggested long, long ago, you may recall ?.). >>> >>> Regards >>> >>> John >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > > The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. > Thank you. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Fri Nov 9 14:49:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5880721F86D4 for ; Fri, 9 Nov 2012 14:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWhJg0r573RI for ; Fri, 9 Nov 2012 14:49:49 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 12DFA21F860C for ; Fri, 9 Nov 2012 14:49:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9635; q=dns/txt; s=iport; t=1352501389; x=1353710989; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VME2xM9eWRJ0nK4CvZEGVtyBX9lBHC0qlZLkhqh8cjM=; b=Wx0RRezlkpp4YT12PHFlE89SzJQZIbb0pKv4BjE2xn1Jucquhn6dJvyl m00spGseshIb2G95pq/5RSRrSfXGhmY/0M4gGAo0pSyCPxXI8Xfv9urAU VUpEZPLCILBS7eUWa1ktvopwpx64n6yKhAFxk9BnvITka24ulTcCupC+4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAASHnVCtJXG+/2dsb2JhbABEw0GBCIIeAQEBAwEBAQELBAFSAQgLBQcEAgEIEQMBAQEBCh0HJwsUCQgBAQQOBQgah2IGC51/oAsEjBQUBoVPYQOkU4Frgm+BWwkXHg X-IronPort-AV: E=McAfee;i="5400,1158,6891"; a="140518212" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 09 Nov 2012 22:49:48 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA9MnlUq022579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Nov 2012 22:49:47 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Fri, 9 Nov 2012 16:49:47 -0600 From: "Stan Ratliff (sratliff)" To: "Viberg, Neil" Thread-Topic: [manet] DLEP Lite? (Teco Boot) Thread-Index: Ac2+jVdl8St7CxHOQImNx8g7RjcZBAADdN/wABHqP4AACm0wUP//5IqA Date: Fri, 9 Nov 2012 22:49:46 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B83A@xmb-aln-x03.cisco.com> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2142BCFA1F7F0D468F8EE6C8DE719E6805B70903@CGYSVW100.gdcan.com> In-Reply-To: <2142BCFA1F7F0D468F8EE6C8DE719E6805B70903@CGYSVW100.gdcan.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.211] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19350.005 x-tm-as-result: No--50.276800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <5344F815187BE64FAC32ABFA04732A47@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 22:49:50 -0000 Neil,=20 Thanks. While it's on my mind, and just to keep the conversation going, I t= hink there's another assumption with ModemLPA that's confusing me - having = this radio link potentially multiple hops away. The assumption there is tha= t the RF link, by definition, is the bandwidth bottleneck. There's no slowe= r link between the router and the modem. Hence, traffic gated at the speed = of the modem is the right thing to do. But, I don't think that assumption w= ould hold in all cases=85 To the DLEP-interested parties in general - is there something I'm missing = here? Regards, Stan On Nov 9, 2012, at 3:39 PM, Viberg, Neil wrote: > Stan, >=20 > Good point. I personally would find it a bit odd to just add a bearer > into a situation where multiple routers could each view it as "their" > link and I haven't encountered that situation but others might. >=20 > Neil >=20 > -----Original Message----- > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 > Sent: Friday, November 09, 2012 12:29 PM > To: Viberg, Neil > Cc: > Subject: Re: [manet] DLEP Lite? (Teco Boot) >=20 > One (of many) things that confuses me about DLEP-Lite is the notion that > the modem (or radio, or bearer) would "strobe" packets to "some address" > (let's say some sort of site-local scoped multicast address) and not > know (or care) about responses. What if, in that case, I put multiple > routers "behind" the modem that can hear the strobes? Pretty easy to get > the link overloaded, just as before... so, I'm not seeing any general > benefit, unless some assumptions are made as to the overall structure of > the network. >=20 > Regards, > Stan >=20 > On Nov 9, 2012, at 1:08 PM, Viberg, Neil wrote: >=20 >> Folks, >>=20 >> I hadn't heard the security argument for DLEP Lite before but, having=20 >> some limited exposure to red-black boundaries, I can understand the=20 >> desire/need for a one-way protocol. >>=20 >> I have colleagues who would like a DLEP Lite for a different reason. >> They see it as a way to reduce development cost along with cpu and=20 >> communication load on the modem side of the information flow. >>=20 >> Another situation where DLEP Lite would be sufficient is with a modem=20 >> that isn't sophisticated enough to determine its neighbors but could=20 >> give basic information about its transmission state. DLEP Lite would=20 >> offer an extremely lightweight and standardized way to learn about the >=20 >> modem and its basic capabilities. >>=20 >> A few things to consider: >>=20 >> 1. having a DLEP Lite does not lessen the work the router has to do. >> Whether the modem thinks it has a session or not, the router will need >=20 >> to treat the flow of data from the modem as a session except without=20 >> any well known points at which failure can be detected. I think that=20 >> the router's response to failed modems will be slower, in general,=20 >> with a DLEP Lite. >>=20 >> 2. users of DLEP Lite would need to carefully balance the modem=20 >> savings with the system cost. With DLEP Lite the amount of messaging=20 >> towards the router will need to have a rate that is a function of the=20 >> number of modem neighbors, rate of significant change of link=20 >> parameters *and* the probability that a specific DLEP message can be=20 >> lost. DLEP Lite moves the information model to a pure soft state=20 >> approach while the original DLEP model is much closer to a hard state=20 >> model. This implies that the consistency of router state depends on=20 >> the flow of information from the modem to overcome the packet loss=20 >> rate *but* there is no communication from the router back to the modem >=20 >> so it is very difficult for the modem to estimate packet loss rate. If >=20 >> one has a strong desire for consistent state in the router and the=20 >> modem has a large number of neighbors and/or volatile links then the=20 >> messaging rate may be considerably higher than the ACKed exchange of a > straight DLEP implementation. >>=20 >> 3. DLEP Lite would need to be a required part of the router and the=20 >> modem would be able to implement either the full DLEP or DLEP Lite. >>=20 >>=20 >> Cheers, >> Neil Viberg >> Network Architect >> C3ISS Business Unit >> General Dynamics Canada >>=20 >> P.S. I personally tend to use the generic term bearer rather than=20 >> modem because the modem is just one of many components in every device >=20 >> I've worked with. >>=20 >>=20 >> -----Excerpt from manet Digest Vol 102 Issue 117----- >>=20 >> ---------------------------------------------------------------------- >>=20 >> Message: 1 >> Date: Fri, 9 Nov 2012 13:59:39 +0100 >> From: Teco Boot >> To: "Ivancic, William D. (GRC-RHN0)" >> Cc: "manet@ietf.org" >> Subject: Re: [manet] DLEP Lite? >> Message-ID: <55238ACB-F5B2-40EB-A906-96E0F4387928@inf-net.nl> >> Content-Type: text/plain; charset=3D"windows-1252" >>=20 >> The reason why I need a one way protocol is that I have to deal with=20 >> some security mandates. All outgoing traffic from the router port has=20 >> to be crypted packets, or related to the crypto engine. This piece of=20 >> code for crypto and firewall needs to be reviewed and certified.=20 >> Import of data is less a problem. >>=20 >> During WGLC review, I'll start reading security considerations. When=20 >> it describes something like "this protocol does not introduce a covert >=20 >> channel", I'll get more interested. As I see it right now, there is a=20 >> need to split the DLEP protocol draft. The basic mode would be=20 >> DLEP-Lite, and provide transport from radio to router only. Maybe=20 >> DLEP-heavy is a better name for it, it could need more lines of code. >> And more bits on the wire. >>=20 >> Teco >>=20 >> Op 8 nov. 2012, om 20:00 heeft Ivancic, William D. (GRC-RHN0) het=20 >> volgende geschreven: >>=20 >>> DLEP, at least the last time I read it, which was a month or two ago, >> is client/server based with sessions setup between radio and router. >> ModemLPA simply has the radio (or crypto device or whatever) sending=20 >> out status packets either periodically or when something changes. =20 >> ModemLPA could send either to all routers address, a unicast address,=20 >> or perhaps a organizationally scoped multicast address. >>>=20 >>> "It should be possible to use the DLEP message formats without all=20 >>> the >> signaling required for the DLEP client/server session to perform the=20 >> functions addressed in this draft. The modem would simply provide=20 >> link states out via multicast or unicast UDP datagrams (DLEP-Lite)." >>>=20 >>> DLEP is designed to operate only over the local-link and does not >> accommodate systems that are multiple hops away from the modem.=20 >> Upstream notification would be a simple modification to DLEP (I > think). >>>=20 >>> "To handle advertisements beyond the local interface, Internet >>> Protocol version 4 (IPv4) organizational-scoped multicast and >>> Internet Protocol version 6 (IPv6) site-local multicast MAY be used >>> with no explicit configuration in the modem. Use of IPv4 >>> administratively-scoped multicast and IPv6 site-local multicast >> could >>> handle both devices that are directly connected to the modem as >> well >>> as hosts and applications that are multiple hops away [RFC2365] >>> [RFC2373]." >>>=20 >>>=20 >>>=20 >>>=20 >>> On Nov 7, 2012, at 5:08 PM, Dowdell, John wrote: >>>=20 >>>> @Stan and Will >>>>=20 >>>> Can you explain exactly what you mean by DLEP Lite, as mentioned in >> the dying moments of the WG meeting? Lite in what respect? I would not >=20 >> consider DLEP to be particularly overweight, so understanding exactly=20 >> what you would intend to remove would be useful. >>>>=20 >>>> Also, IMHO it is enough work simply to define one DLEP, so having >> another one to choose from is not likely to help the radio=20 >> manufacturers along the road to implementation. Having a mandatory=20 >> core of DLEP, with optional extras, I can support. Having a further=20 >> cut down edition means you then either have to know beforehand whether >=20 >> the radio supports full or Lite DLEP, or you have to be able to=20 >> automatically query the radio to find out (which is a feature I=20 >> suggested long, long ago, you may recall ?.). >>>>=20 >>>> Regards >>>>=20 >>>> John >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> The information contained in this e-mail message is PRIVATE. It may > contain confidential information and may be legally privileged. It is > intended for the exclusive use of the addressee(s). If you are not the > intended recipient, you are hereby notified that any dissemination, > distribution or reproduction of this communication is strictly > prohibited. If the intended recipient(s) cannot be reached or if a > transmission problem has occurred, please notify the sender immediately > by return e-mail and destroy all copies of this message.=20 >> Thank you.=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From Neil.Viberg@gdcanada.com Fri Nov 9 15:44:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F1E21F8604 for ; Fri, 9 Nov 2012 15:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jboHxV9eBXfW for ; Fri, 9 Nov 2012 15:44:53 -0800 (PST) Received: from gdcanada.com (smtp.gdcanada.com [209.29.4.39]) by ietfa.amsl.com (Postfix) with ESMTP id 235A721F85E3 for ; Fri, 9 Nov 2012 15:44:44 -0800 (PST) Received: from ottsvw100.gdcan.com ([172.16.7.212]) by gdcanada.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Nov 2012 18:44:56 -0500 Received: from CGYSVW100.gdcan.com ([172.31.27.211]) by ottsvw100.gdcan.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Nov 2012 18:44:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain;charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Nov 2012 16:44:41 -0700 Message-ID: <2142BCFA1F7F0D468F8EE6C8DE719E6805B70906@CGYSVW100.gdcan.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B83A@xmb-aln-x03.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP Lite? (Teco Boot) Thread-Index: Ac2+jVdl8St7CxHOQImNx8g7RjcZBAADdN/wABHqP4AACm0wUP//5IqAgABg/bA= References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2142BCFA1F7F0D468F8EE6C8DE719E6805B70903@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B83A@xmb-aln-x03.cisco.com> From: "Viberg, Neil" To: "Stan Ratliff (sratliff)" X-OriginalArrivalTime: 09 Nov 2012 23:44:42.0589 (UTC) FILETIME=[30DF30D0:01CDBED4] Cc: manet@ietf.org Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 23:44:54 -0000 Stan, I had a similar reaction to the ModemLPA assumption of the radio link multiple hops away from the router but I remember toying with the idea in a system design a few years ago. The problem was the radio link wasn't "good" enough to be hooked into the general network but it was sometimes "needed" (a system requirement) for specific data transfers. The design would have worked whether the data link was the bottleneck or not. One would hope that the route metric would reflect the cost of getting to the data link. Regards, Neil -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] Sent: Friday, November 09, 2012 3:50 PM To: Viberg, Neil Cc: Subject: Re: [manet] DLEP Lite? (Teco Boot) Neil, Thanks. While it's on my mind, and just to keep the conversation going, I think there's another assumption with ModemLPA that's confusing me - having this radio link potentially multiple hops away. The assumption there is that the RF link, by definition, is the bandwidth bottleneck. There's no slower link between the router and the modem. Hence, traffic gated at the speed of the modem is the right thing to do. But, I don't think that assumption would hold in all cases... To the DLEP-interested parties in general - is there something I'm missing here? Regards, Stan On Nov 9, 2012, at 3:39 PM, Viberg, Neil wrote: > Stan, > > Good point. I personally would find it a bit odd to just add a bearer > into a situation where multiple routers could each view it as "their" > link and I haven't encountered that situation but others might. > > Neil > > -----Original Message----- > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] > Sent: Friday, November 09, 2012 12:29 PM > To: Viberg, Neil > Cc: > Subject: Re: [manet] DLEP Lite? (Teco Boot) > > One (of many) things that confuses me about DLEP-Lite is the notion > that the modem (or radio, or bearer) would "strobe" packets to "some address" > (let's say some sort of site-local scoped multicast address) and not > know (or care) about responses. What if, in that case, I put multiple > routers "behind" the modem that can hear the strobes? Pretty easy to > get the link overloaded, just as before... so, I'm not seeing any > general benefit, unless some assumptions are made as to the overall > structure of the network. > > Regards, > Stan > > On Nov 9, 2012, at 1:08 PM, Viberg, Neil wrote: > >> Folks, >> >> I hadn't heard the security argument for DLEP Lite before but, having >> some limited exposure to red-black boundaries, I can understand the >> desire/need for a one-way protocol. >> >> I have colleagues who would like a DLEP Lite for a different reason. >> They see it as a way to reduce development cost along with cpu and >> communication load on the modem side of the information flow. >> >> Another situation where DLEP Lite would be sufficient is with a modem >> that isn't sophisticated enough to determine its neighbors but could >> give basic information about its transmission state. DLEP Lite would >> offer an extremely lightweight and standardized way to learn about >> the > >> modem and its basic capabilities. >> >> A few things to consider: >> >> 1. having a DLEP Lite does not lessen the work the router has to do. >> Whether the modem thinks it has a session or not, the router will >> need > >> to treat the flow of data from the modem as a session except without >> any well known points at which failure can be detected. I think that >> the router's response to failed modems will be slower, in general, >> with a DLEP Lite. >> >> 2. users of DLEP Lite would need to carefully balance the modem >> savings with the system cost. With DLEP Lite the amount of messaging >> towards the router will need to have a rate that is a function of the >> number of modem neighbors, rate of significant change of link >> parameters *and* the probability that a specific DLEP message can be >> lost. DLEP Lite moves the information model to a pure soft state >> approach while the original DLEP model is much closer to a hard state >> model. This implies that the consistency of router state depends on >> the flow of information from the modem to overcome the packet loss >> rate *but* there is no communication from the router back to the >> modem > >> so it is very difficult for the modem to estimate packet loss rate. >> If > >> one has a strong desire for consistent state in the router and the >> modem has a large number of neighbors and/or volatile links then the >> messaging rate may be considerably higher than the ACKed exchange of >> a > straight DLEP implementation. >> >> 3. DLEP Lite would need to be a required part of the router and the >> modem would be able to implement either the full DLEP or DLEP Lite. >> >> >> Cheers, >> Neil Viberg >> Network Architect >> C3ISS Business Unit >> General Dynamics Canada >> >> P.S. I personally tend to use the generic term bearer rather than >> modem because the modem is just one of many components in every >> device > >> I've worked with. >> >> >> -----Excerpt from manet Digest Vol 102 Issue 117----- >> >> --------------------------------------------------------------------- >> - >> >> Message: 1 >> Date: Fri, 9 Nov 2012 13:59:39 +0100 >> From: Teco Boot >> To: "Ivancic, William D. (GRC-RHN0)" >> Cc: "manet@ietf.org" >> Subject: Re: [manet] DLEP Lite? >> Message-ID: <55238ACB-F5B2-40EB-A906-96E0F4387928@inf-net.nl> >> Content-Type: text/plain; charset=3D"windows-1252" >> >> The reason why I need a one way protocol is that I have to deal with >> some security mandates. All outgoing traffic from the router port has >> to be crypted packets, or related to the crypto engine. This piece of >> code for crypto and firewall needs to be reviewed and certified. >> Import of data is less a problem. >> >> During WGLC review, I'll start reading security considerations. When >> it describes something like "this protocol does not introduce a >> covert > >> channel", I'll get more interested. As I see it right now, there is a >> need to split the DLEP protocol draft. The basic mode would be >> DLEP-Lite, and provide transport from radio to router only. Maybe >> DLEP-heavy is a better name for it, it could need more lines of code. >> And more bits on the wire. >> >> Teco >> >> Op 8 nov. 2012, om 20:00 heeft Ivancic, William D. (GRC-RHN0) het >> volgende geschreven: >> >>> DLEP, at least the last time I read it, which was a month or two >>> ago, >> is client/server based with sessions setup between radio and router. >> ModemLPA simply has the radio (or crypto device or whatever) sending >> out status packets either periodically or when something changes. >> ModemLPA could send either to all routers address, a unicast address, >> or perhaps a organizationally scoped multicast address. >>> >>> "It should be possible to use the DLEP message formats without all >>> the >> signaling required for the DLEP client/server session to perform the >> functions addressed in this draft. The modem would simply provide >> link states out via multicast or unicast UDP datagrams (DLEP-Lite)." >>> >>> DLEP is designed to operate only over the local-link and does not >> accommodate systems that are multiple hops away from the modem. >> Upstream notification would be a simple modification to DLEP (I > think). >>> >>> "To handle advertisements beyond the local interface, Internet >>> Protocol version 4 (IPv4) organizational-scoped multicast and >>> Internet Protocol version 6 (IPv6) site-local multicast MAY be used >>> with no explicit configuration in the modem. Use of IPv4 >>> administratively-scoped multicast and IPv6 site-local multicast >> could >>> handle both devices that are directly connected to the modem as >> well >>> as hosts and applications that are multiple hops away [RFC2365] >>> [RFC2373]." >>> >>> >>> >>> >>> On Nov 7, 2012, at 5:08 PM, Dowdell, John wrote: >>> >>>> @Stan and Will >>>> >>>> Can you explain exactly what you mean by DLEP Lite, as mentioned in >> the dying moments of the WG meeting? Lite in what respect? I would >> not > >> consider DLEP to be particularly overweight, so understanding exactly >> what you would intend to remove would be useful. >>>> >>>> Also, IMHO it is enough work simply to define one DLEP, so having >> another one to choose from is not likely to help the radio >> manufacturers along the road to implementation. Having a mandatory >> core of DLEP, with optional extras, I can support. Having a further >> cut down edition means you then either have to know beforehand >> whether > >> the radio supports full or Lite DLEP, or you have to be able to >> automatically query the radio to find out (which is a feature I >> suggested long, long ago, you may recall ?.). >>>> >>>> Regards >>>> >>>> John >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> >> The information contained in this e-mail message is PRIVATE. It may > contain confidential information and may be legally privileged. It is > intended for the exclusive use of the addressee(s). If you are not the > intended recipient, you are hereby notified that any dissemination, > distribution or reproduction of this communication is strictly > prohibited. If the intended recipient(s) cannot be reached or if a > transmission problem has occurred, please notify the sender > immediately by return e-mail and destroy all copies of this message. >> Thank you. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > From teco@inf-net.nl Sat Nov 10 07:12:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E13C21F8522 for ; Sat, 10 Nov 2012 07:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJYd6KZJIIBe for ; Sat, 10 Nov 2012 07:12:10 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7A77921F851F for ; Sat, 10 Nov 2012 07:12:08 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id jg9so496165bkc.31 for ; Sat, 10 Nov 2012 07:12:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=tzq414zwiHbj//uceGbt6sj5JuHM1saEJKN/m+kobp4=; b=KxyzO+PEt0gwzoBuVTM0+I9XJ6YACVsaOKKfHw/iFRqxvNw15FuhBV6cIu87fVl+to MqGsVbzodceY+5gknTE1i6vVWHxk+K4FjAWws7t0+yHY11Iirgomx4Y0dzdlufuVG/uH iHbz8uYS6ahldH0dRGHyUcSMNUTx+TpJsIhHNiRykz9ZPYioL5G7Z8pDv41bOneXqlqe IYFZNKsxuvpV8uwkFjBDnaElFrDOOySqlo3DGos5qIYrNcUTeZ4Gq8gVAo2McdrZGfc2 ctKxHnHsB6jc6TJfeSZEKubddb3W57+08vK1sje/EP+g+NyV3wdGQzDF2IhwekwoHGRe daNQ== Received: by 10.204.9.138 with SMTP id l10mr4910769bkl.80.1352560327425; Sat, 10 Nov 2012 07:12:07 -0800 (PST) Received: from [10.87.147.120] ([80.187.201.44]) by mx.google.com with ESMTPS id ia2sm583162bkc.11.2012.11.10.07.12.02 (version=SSLv3 cipher=OTHER); Sat, 10 Nov 2012 07:12:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> Date: Sat, 10 Nov 2012 16:12:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnnG6DDoGg1sSsm+e3Uy3q+eq/4kePHGB60TJ/qGnUrrZtgtZ8+hdq0Wqz/OlmBf/9a0wj3 Cc: "" , "Viberg, Neil" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 15:12:11 -0000 Op 9 nov. 2012, om 20:51 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Nov 9, 2012, at 2:45 PM, Teco Boot wrote: >=20 >> Which link gets overloaded? I cannot see why there would be any = difference. Routers are passive, radio just send its info for other = peers. >>=20 >> But, on other side of RF link, there is info for each router on this = side. Info is per MAC address. In fact, MAC addresses could be for a = router or a host. >=20 > How? How did the far-end radio get the MAC information on its routers? This is data plane. What about a hello packet? > Because I assume that it, too, is in "send only" mode, therefore, it = knows *nothing* about the router or routers on its end (just as the = "local radio" knows nothing about local devices)=85. that's part of the = whole point on DLEP. If router is not powered, you are correct. Teco >=20 > And no, no ticket required. >=20 > Stan >=20 >>=20 >> If you had flow control in mind, that is another story. This doesn't = meet my requirements, as stated before a couple of times. >>=20 >> Should I open a ticket for this? >>=20 >> Teco >>=20 >> Op 9 nov. 2012, om 20:29 heeft Stan Ratliff (sratliff) het volgende = geschreven: >>=20 >>> One (of many) things that confuses me about DLEP-Lite is the notion = that the modem (or radio, or bearer) would "strobe" packets to "some = address" (let's say some sort of site-local scoped multicast address) = and not know (or care) about responses. What if, in that case, I put = multiple routers "behind" the modem that can hear the strobes? Pretty = easy to get the link overloaded, just as before=85 so, I'm not seeing = any general benefit, unless some assumptions are made as to the overall = structure of the network. >>>=20 >>> Regards, >>> Stan >>>=20 >>> On Nov 9, 2012, at 1:08 PM, Viberg, Neil wrote: >>>=20 >>>> Folks, >>>>=20 >>>> I hadn't heard the security argument for DLEP Lite before but, = having >>>> some limited exposure to red-black boundaries, I can understand the >>>> desire/need for a one-way protocol. >>>>=20 >>>> I have colleagues who would like a DLEP Lite for a different = reason. >>>> They see it as a way to reduce development cost along with cpu and >>>> communication load on the modem side of the information flow. >>>>=20 >>>> Another situation where DLEP Lite would be sufficient is with a = modem >>>> that isn't sophisticated enough to determine its neighbors but = could >>>> give basic information about its transmission state. DLEP Lite = would >>>> offer an extremely lightweight and standardized way to learn about = the >>>> modem and its basic capabilities. >>>>=20 >>>> A few things to consider: >>>>=20 >>>> 1. having a DLEP Lite does not lessen the work the router has to = do. >>>> Whether the modem thinks it has a session or not, the router will = need >>>> to treat the flow of data from the modem as a session except = without any >>>> well known points at which failure can be detected. I think that = the >>>> router's response to failed modems will be slower, in general, with = a >>>> DLEP Lite. >>>>=20 >>>> 2. users of DLEP Lite would need to carefully balance the modem = savings >>>> with the system cost. With DLEP Lite the amount of messaging = towards the >>>> router will need to have a rate that is a function of the number of >>>> modem neighbors, rate of significant change of link parameters = *and* the >>>> probability that a specific DLEP message can be lost. DLEP Lite = moves >>>> the information model to a pure soft state approach while the = original >>>> DLEP model is much closer to a hard state model. This implies that = the >>>> consistency of router state depends on the flow of information from = the >>>> modem to overcome the packet loss rate *but* there is no = communication >>>> from the router back to the modem so it is very difficult for the = modem >>>> to estimate packet loss rate. If one has a strong desire for = consistent >>>> state in the router and the modem has a large number of neighbors = and/or >>>> volatile links then the messaging rate may be considerably higher = than >>>> the ACKed exchange of a straight DLEP implementation. >>>>=20 >>>> 3. DLEP Lite would need to be a required part of the router and the >>>> modem would be able to implement either the full DLEP or DLEP Lite. >>>>=20 >>>>=20 >>>> Cheers, >>>> Neil Viberg >>>> Network Architect >>>> C3ISS Business Unit >>>> General Dynamics Canada >>>>=20 >>>> P.S. I personally tend to use the generic term bearer rather than = modem >>>> because the modem is just one of many components in every device = I've >>>> worked with.=20 >>>>=20 >>>>=20 >>>> -----Excerpt from manet Digest Vol 102 Issue 117----- >>>>=20 >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> Message: 1 >>>> Date: Fri, 9 Nov 2012 13:59:39 +0100 >>>> From: Teco Boot >>>> To: "Ivancic, William D. (GRC-RHN0)" >>>> Cc: "manet@ietf.org" >>>> Subject: Re: [manet] DLEP Lite? >>>> Message-ID: <55238ACB-F5B2-40EB-A906-96E0F4387928@inf-net.nl> >>>> Content-Type: text/plain; charset=3D"windows-1252" >>>>=20 >>>> The reason why I need a one way protocol is that I have to deal = with >>>> some security mandates. All outgoing traffic from the router port = has to >>>> be crypted packets, or related to the crypto engine. This piece of = code >>>> for crypto and firewall needs to be reviewed and certified. Import = of >>>> data is less a problem. >>>>=20 >>>> During WGLC review, I'll start reading security considerations. = When it >>>> describes something like "this protocol does not introduce a covert >>>> channel", I'll get more interested. As I see it right now, there is = a >>>> need to split the DLEP protocol draft. The basic mode would be >>>> DLEP-Lite, and provide transport from radio to router only. Maybe >>>> DLEP-heavy is a better name for it, it could need more lines of = code. >>>> And more bits on the wire. >>>>=20 >>>> Teco >>>>=20 >>>> Op 8 nov. 2012, om 20:00 heeft Ivancic, William D. (GRC-RHN0) het >>>> volgende geschreven: >>>>=20 >>>>> DLEP, at least the last time I read it, which was a month or two = ago, >>>> is client/server based with sessions setup between radio and = router. >>>> ModemLPA simply has the radio (or crypto device or whatever) = sending out >>>> status packets either periodically or when something changes. = ModemLPA >>>> could send either to all routers address, a unicast address, or = perhaps >>>> a organizationally scoped multicast address. =20 >>>>>=20 >>>>> "It should be possible to use the DLEP message formats without all = the >>>> signaling required for the DLEP client/server session to perform = the >>>> functions addressed in this draft. The modem would simply provide = link >>>> states out via multicast or unicast UDP datagrams (DLEP-Lite)." >>>>>=20 >>>>> DLEP is designed to operate only over the local-link and does not >>>> accommodate systems that are multiple hops away from the modem. = Upstream >>>> notification would be a simple modification to DLEP (I think). >>>>>=20 >>>>> "To handle advertisements beyond the local interface, Internet >>>>> Protocol version 4 (IPv4) organizational-scoped multicast and >>>>> Internet Protocol version 6 (IPv6) site-local multicast MAY be = used >>>>> with no explicit configuration in the modem. Use of IPv4 >>>>> administratively-scoped multicast and IPv6 site-local multicast >>>> could >>>>> handle both devices that are directly connected to the modem as >>>> well >>>>> as hosts and applications that are multiple hops away [RFC2365] >>>>> [RFC2373]." >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Nov 7, 2012, at 5:08 PM, Dowdell, John wrote: >>>>>=20 >>>>>> @Stan and Will >>>>>>=20 >>>>>> Can you explain exactly what you mean by DLEP Lite, as mentioned = in >>>> the dying moments of the WG meeting? Lite in what respect? I would = not >>>> consider DLEP to be particularly overweight, so understanding = exactly >>>> what you would intend to remove would be useful. >>>>>>=20 >>>>>> Also, IMHO it is enough work simply to define one DLEP, so having >>>> another one to choose from is not likely to help the radio = manufacturers >>>> along the road to implementation. Having a mandatory core of DLEP, = with >>>> optional extras, I can support. Having a further cut down edition = means >>>> you then either have to know beforehand whether the radio supports = full >>>> or Lite DLEP, or you have to be able to automatically query the = radio to >>>> find out (which is a feature I suggested long, long ago, you may = recall >>>> ?.). >>>>>>=20 >>>>>> Regards >>>>>>=20 >>>>>> John >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>> The information contained in this e-mail message is PRIVATE. It may = contain confidential information and may be legally privileged. It is = intended for the exclusive use of the addressee(s). If you are not the = intended recipient, you are hereby notified that any dissemination, = distribution or reproduction of this communication is strictly = prohibited. If the intended recipient(s) cannot be reached or if a = transmission problem has occurred, please notify the sender immediately = by return e-mail and destroy all copies of this message.=20 >>>> Thank you.=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 From sratliff@cisco.com Sat Nov 10 10:35:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE2321F84B2 for ; Sat, 10 Nov 2012 10:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzEZY7LkV13C for ; Sat, 10 Nov 2012 10:35:57 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6174721F84A4 for ; Sat, 10 Nov 2012 10:35:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10587; q=dns/txt; s=iport; t=1352572557; x=1353782157; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fDXBpVln2kuD2Q/M0yZlA+PuNFCSEVwYvSIPh+1CWpY=; b=IdbyfPZZkHvFKfJ/Uob/U4NrvuvuZ9nWqVODEQjFMQIV/+NemT95AxBL GqZrmHR4hY1mrke/VS7hheWcaKsKMYDktaEGHe8QI8MZ0B171HTXBCpdU 98R6s8W5jAkZWPGuDp9onnuTfhlwuAEO4fAbpyrfhqXr/NSlN43TDd/bT 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALGdnlCtJV2Y/2dsb2JhbABEw1aBCIIeAQEBAwEBAQELBAFSAQgLEAIBCBEDAQIBCiQnCx0IAgQOBQgah2IGC5xdn0QEjBUUBgqFRWEDpFOBa4JvgVsJFx4 X-IronPort-AV: E=McAfee;i="5400,1158,6892"; a="140907655" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 10 Nov 2012 18:35:56 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAAIZuOT009091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 10 Nov 2012 18:35:56 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Sat, 10 Nov 2012 12:35:56 -0600 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] DLEP Lite? (Teco Boot) Thread-Index: Ac2+jVdl8St7CxHOQImNx8g7RjcZBAADdN/wABHqP4AAAJBkAAAANyIAACiFJoAABx7cAA== Date: Sat, 10 Nov 2012 18:35:55 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> In-Reply-To: <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.211] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19352.005 x-tm-as-result: No--36.731200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <8B5C34FD0983F54A805969F25A5BE5BC@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Viberg, Neil" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 18:35:58 -0000 On Nov 10, 2012, at 10:12 AM, Teco Boot wrote: >=20 > Op 9 nov. 2012, om 20:51 heeft Stan Ratliff (sratliff) het volgende gesch= reven: >=20 >>=20 >> On Nov 9, 2012, at 2:45 PM, Teco Boot wrote: >>=20 >>> Which link gets overloaded? I cannot see why there would be any differe= nce. Routers are passive, radio just send its info for other peers. >>>=20 >>> But, on other side of RF link, there is info for each router on this si= de. Info is per MAC address. In fact, MAC addresses could be for a router o= r a host. >>=20 >> How? How did the far-end radio get the MAC information on its routers? > This is data plane. What about a hello packet? And if you're going to rely on HELLO packets, and ARP, and IPv6 ND, then yo= u aren't using (and don't need) DLEP. >=20 >> Because I assume that it, too, is in "send only" mode, therefore, it kno= ws *nothing* about the router or routers on its end (just as the "local rad= io" knows nothing about local devices)=85. that's part of the whole point o= n DLEP. > If router is not powered, you are correct. I don't understand that response.=20 Stan >=20 > Teco >=20 >>=20 >> And no, no ticket required. >>=20 >> Stan >>=20 >>>=20 >>> If you had flow control in mind, that is another story. This doesn't me= et my requirements, as stated before a couple of times. >>>=20 >>> Should I open a ticket for this? >>>=20 >>> Teco >>>=20 >>> Op 9 nov. 2012, om 20:29 heeft Stan Ratliff (sratliff) het volgende ges= chreven: >>>=20 >>>> One (of many) things that confuses me about DLEP-Lite is the notion th= at the modem (or radio, or bearer) would "strobe" packets to "some address"= (let's say some sort of site-local scoped multicast address) and not know = (or care) about responses. What if, in that case, I put multiple routers "b= ehind" the modem that can hear the strobes? Pretty easy to get the link ove= rloaded, just as before=85 so, I'm not seeing any general benefit, unless s= ome assumptions are made as to the overall structure of the network. >>>>=20 >>>> Regards, >>>> Stan >>>>=20 >>>> On Nov 9, 2012, at 1:08 PM, Viberg, Neil wrote: >>>>=20 >>>>> Folks, >>>>>=20 >>>>> I hadn't heard the security argument for DLEP Lite before but, having >>>>> some limited exposure to red-black boundaries, I can understand the >>>>> desire/need for a one-way protocol. >>>>>=20 >>>>> I have colleagues who would like a DLEP Lite for a different reason. >>>>> They see it as a way to reduce development cost along with cpu and >>>>> communication load on the modem side of the information flow. >>>>>=20 >>>>> Another situation where DLEP Lite would be sufficient is with a modem >>>>> that isn't sophisticated enough to determine its neighbors but could >>>>> give basic information about its transmission state. DLEP Lite would >>>>> offer an extremely lightweight and standardized way to learn about th= e >>>>> modem and its basic capabilities. >>>>>=20 >>>>> A few things to consider: >>>>>=20 >>>>> 1. having a DLEP Lite does not lessen the work the router has to do. >>>>> Whether the modem thinks it has a session or not, the router will nee= d >>>>> to treat the flow of data from the modem as a session except without = any >>>>> well known points at which failure can be detected. I think that the >>>>> router's response to failed modems will be slower, in general, with a >>>>> DLEP Lite. >>>>>=20 >>>>> 2. users of DLEP Lite would need to carefully balance the modem savin= gs >>>>> with the system cost. With DLEP Lite the amount of messaging towards = the >>>>> router will need to have a rate that is a function of the number of >>>>> modem neighbors, rate of significant change of link parameters *and* = the >>>>> probability that a specific DLEP message can be lost. DLEP Lite moves >>>>> the information model to a pure soft state approach while the origina= l >>>>> DLEP model is much closer to a hard state model. This implies that th= e >>>>> consistency of router state depends on the flow of information from t= he >>>>> modem to overcome the packet loss rate *but* there is no communicatio= n >>>>> from the router back to the modem so it is very difficult for the mod= em >>>>> to estimate packet loss rate. If one has a strong desire for consiste= nt >>>>> state in the router and the modem has a large number of neighbors and= /or >>>>> volatile links then the messaging rate may be considerably higher tha= n >>>>> the ACKed exchange of a straight DLEP implementation. >>>>>=20 >>>>> 3. DLEP Lite would need to be a required part of the router and the >>>>> modem would be able to implement either the full DLEP or DLEP Lite. >>>>>=20 >>>>>=20 >>>>> Cheers, >>>>> Neil Viberg >>>>> Network Architect >>>>> C3ISS Business Unit >>>>> General Dynamics Canada >>>>>=20 >>>>> P.S. I personally tend to use the generic term bearer rather than mod= em >>>>> because the modem is just one of many components in every device I've >>>>> worked with.=20 >>>>>=20 >>>>>=20 >>>>> -----Excerpt from manet Digest Vol 102 Issue 117----- >>>>>=20 >>>>> ---------------------------------------------------------------------= - >>>>>=20 >>>>> Message: 1 >>>>> Date: Fri, 9 Nov 2012 13:59:39 +0100 >>>>> From: Teco Boot >>>>> To: "Ivancic, William D. (GRC-RHN0)" >>>>> Cc: "manet@ietf.org" >>>>> Subject: Re: [manet] DLEP Lite? >>>>> Message-ID: <55238ACB-F5B2-40EB-A906-96E0F4387928@inf-net.nl> >>>>> Content-Type: text/plain; charset=3D"windows-1252" >>>>>=20 >>>>> The reason why I need a one way protocol is that I have to deal with >>>>> some security mandates. All outgoing traffic from the router port has= to >>>>> be crypted packets, or related to the crypto engine. This piece of co= de >>>>> for crypto and firewall needs to be reviewed and certified. Import o= f >>>>> data is less a problem. >>>>>=20 >>>>> During WGLC review, I'll start reading security considerations. When = it >>>>> describes something like "this protocol does not introduce a covert >>>>> channel", I'll get more interested. As I see it right now, there is a >>>>> need to split the DLEP protocol draft. The basic mode would be >>>>> DLEP-Lite, and provide transport from radio to router only. Maybe >>>>> DLEP-heavy is a better name for it, it could need more lines of code. >>>>> And more bits on the wire. >>>>>=20 >>>>> Teco >>>>>=20 >>>>> Op 8 nov. 2012, om 20:00 heeft Ivancic, William D. (GRC-RHN0) het >>>>> volgende geschreven: >>>>>=20 >>>>>> DLEP, at least the last time I read it, which was a month or two ago= , >>>>> is client/server based with sessions setup between radio and router. >>>>> ModemLPA simply has the radio (or crypto device or whatever) sending = out >>>>> status packets either periodically or when something changes. ModemL= PA >>>>> could send either to all routers address, a unicast address, or perha= ps >>>>> a organizationally scoped multicast address. =20 >>>>>>=20 >>>>>> "It should be possible to use the DLEP message formats without all t= he >>>>> signaling required for the DLEP client/server session to perform the >>>>> functions addressed in this draft. The modem would simply provide li= nk >>>>> states out via multicast or unicast UDP datagrams (DLEP-Lite)." >>>>>>=20 >>>>>> DLEP is designed to operate only over the local-link and does not >>>>> accommodate systems that are multiple hops away from the modem. Upstr= eam >>>>> notification would be a simple modification to DLEP (I think). >>>>>>=20 >>>>>> "To handle advertisements beyond the local interface, Internet >>>>>> Protocol version 4 (IPv4) organizational-scoped multicast and >>>>>> Internet Protocol version 6 (IPv6) site-local multicast MAY be used >>>>>> with no explicit configuration in the modem. Use of IPv4 >>>>>> administratively-scoped multicast and IPv6 site-local multicast >>>>> could >>>>>> handle both devices that are directly connected to the modem as >>>>> well >>>>>> as hosts and applications that are multiple hops away [RFC2365] >>>>>> [RFC2373]." >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Nov 7, 2012, at 5:08 PM, Dowdell, John wrote: >>>>>>=20 >>>>>>> @Stan and Will >>>>>>>=20 >>>>>>> Can you explain exactly what you mean by DLEP Lite, as mentioned in >>>>> the dying moments of the WG meeting? Lite in what respect? I would no= t >>>>> consider DLEP to be particularly overweight, so understanding exactly >>>>> what you would intend to remove would be useful. >>>>>>>=20 >>>>>>> Also, IMHO it is enough work simply to define one DLEP, so having >>>>> another one to choose from is not likely to help the radio manufactur= ers >>>>> along the road to implementation. Having a mandatory core of DLEP, wi= th >>>>> optional extras, I can support. Having a further cut down edition mea= ns >>>>> you then either have to know beforehand whether the radio supports fu= ll >>>>> or Lite DLEP, or you have to be able to automatically query the radio= to >>>>> find out (which is a feature I suggested long, long ago, you may reca= ll >>>>> ?.). >>>>>>>=20 >>>>>>> Regards >>>>>>>=20 >>>>>>> John >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>>=20 >>>>> The information contained in this e-mail message is PRIVATE. It may c= ontain confidential information and may be legally privileged. It is intend= ed for the exclusive use of the addressee(s). If you are not the intended r= ecipient, you are hereby notified that any dissemination, distribution or r= eproduction of this communication is strictly prohibited. If the intended r= ecipient(s) cannot be reached or if a transmission problem has occurred, pl= ease notify the sender immediately by return e-mail and destroy all copies = of this message.=20 >>>>> Thank you.=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >=20 From hrogge@googlemail.com Sat Nov 10 10:53:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E420821F8498 for ; Sat, 10 Nov 2012 10:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+x00NLVWscp for ; Sat, 10 Nov 2012 10:53:42 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 728A221F8496 for ; Sat, 10 Nov 2012 10:53:42 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so2244396dan.31 for ; Sat, 10 Nov 2012 10:53:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YZukn7NJ7uOm/kqscCW3vZpGG6XRRTP4oJblKIIbVJU=; b=BbeRkoBBZFnPvOQvAXcLPqMSNdjidkIdAwTx3Lb9YA5nJtbVWHca2xJ0Box/RhsiZo TVuIRdoFoK/JELS51+KSaCgVf2t5s840mwCqvaYsCW89wPDdfCCJmCFOyBVw4ze7rGjc MrHBY+c0Im2EgsqiUSVtM6zzL1vJk9nJwyPB1EugDXrQ3ZPEkCqkAF/hho6ib61ZY/y+ O4LtaYlx7sumo1tqMd8Pykjlj9W5qVHL9+x+EtF1ifbQOGGqR8IXoC9vz7uL/ZjryB3i 4k0cU+aYUJ374qeKMgqIGG6jntoC2uUiipmEXI9QTDPL9nZj14FazDgfILg8Pn7jjIq8 OweA== Received: by 10.68.233.196 with SMTP id ty4mr44979554pbc.23.1352573622189; Sat, 10 Nov 2012 10:53:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Sat, 10 Nov 2012 10:53:21 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Sat, 10 Nov 2012 19:53:21 +0100 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Viberg, Neil" , "" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 18:53:43 -0000 On Sat, Nov 10, 2012 at 7:35 PM, Stan Ratliff (sratliff) wrote: >>> How? How did the far-end radio get the MAC information on its routers? >> This is data plane. What about a hello packet? > > And if you're going to rely on HELLO packets, and ARP, and IPv6 ND, then you aren't using (and don't need) DLEP. Even with Hello-Packets on layer-3, ARPs (maybe with a transparent cache on the radio) and IPv6 ND you would still need DLEP to get access to the layer-2 data of the radio. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From sratliff@cisco.com Sat Nov 10 15:13:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B03C21F85EA for ; Sat, 10 Nov 2012 15:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixH2nTAiE1EU for ; Sat, 10 Nov 2012 15:13:57 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 67A9C21F86D0 for ; Sat, 10 Nov 2012 15:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2519; q=dns/txt; s=iport; t=1352589237; x=1353798837; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=e716Z/nYwVMIk28t4luVaXPozlwxSQykcXpv8MxfH24=; b=i1plxqNkwIfl0X1TiHm0AYOq+sN9QJdCgXmzplOT6skJxoDrzWY+uwXF 8/uhjQqMD1+QwdhcySfD7/aXHH1g8EzbvDQnNhczlDo4gTHINbk2gHZRC OuatWnemKCn5WndQ63TRB5AZQMUszZ0lEYNBn8dchU64xYLms8H99XGIs Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJ3enlCtJV2a/2dsb2JhbABDw1aBCIIeAQEBAwESAV4IBQsCAQgOCgokMiUCBA4FCBqFboF0Bpxunx6MFYVpYQOkVIFrgm+BZBce X-IronPort-AV: E=McAfee;i="5400,1158,6892"; a="137934019" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 10 Nov 2012 23:13:57 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAANDuJp016837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 10 Nov 2012 23:13:56 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Sat, 10 Nov 2012 17:13:56 -0600 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] DLEP Lite? (Teco Boot) Thread-Index: Ac2+jVdl8St7CxHOQImNx8g7RjcZBAADdN/wABHqP4AAAJBkAAAANyIAACiFJoAABx7cAAAAnAOAAAkZpoA= Date: Sat, 10 Nov 2012 23:13:56 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.211] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19352.005 x-tm-as-result: No--33.894400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <54173312BF9B4A47A3CB55E589F828DB@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Viberg, Neil" , "" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 23:13:58 -0000 On Nov 10, 2012, at 1:53 PM, Henning Rogge wrote: > On Sat, Nov 10, 2012 at 7:35 PM, Stan Ratliff (sratliff) > wrote: >>>> How? How did the far-end radio get the MAC information on its routers? >>> This is data plane. What about a hello packet? >>=20 >> And if you're going to rely on HELLO packets, and ARP, and IPv6 ND, then= you aren't using (and don't need) DLEP. >=20 > Even with Hello-Packets on layer-3, ARPs (maybe with a transparent > cache on the radio) and IPv6 ND you would still need DLEP to get > access to the layer-2 data of the radio. My point is that any layer 2 information you get is useless, because you ca= n't correlate the two with this "one way, no responses" mode of operation. = Assume there are 3 router/modem setups - A, B, and C. Router/modem A can s= ee both B and C. The RF path between A and B is at 40Mbps; the path between= A and C is only 6Mbps=85. All three modems are "strobing" in this one-way = communications mode back to their respective routers. So all that router A = knows is that there are a couple of potential partners "out there" - and wi= th HELLO packets, and IPv6 ND/ARP, router A can actually find them. But how= does A know that the path to B os 40Mbps while the path to C is only 6? Th= ere's no correlation - since the modems are operating in bridge mode, there= 's no indication whatsoever as to which router (B or C) is on which radio. = Because there was no "radio-to-MAC" correlation, because the radios don't w= ant to hear anything from the routers. Unless, of course, the radios are su= rreptitiously snooping the traffic coming in off of their wired connections= , looking for things like this. But that seems a lot more complex to me.=20 This mode of operation *only* works if you make assumptions about the struc= ture of the network. Assumptions I don't believe we should be making. Like,= there's *only* 1 router behind each radio. And that the RF link is the sma= llest in terms of bandwidth (or latency, or whatever metric you wish to key= on). And in the case I describe above, the assumption is that the bandwidt= h to *all* stations across the RF is the same - which isn't true, and if it= is, why do we need dynamic metrics in the first place? Stan >=20 > Henning Rogge >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From teco@inf-net.nl Sun Nov 11 21:51:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BF321F84C9 for ; Sun, 11 Nov 2012 21:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmcsU73KkDuS for ; Sun, 11 Nov 2012 21:51:56 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBA221F849A for ; Sun, 11 Nov 2012 21:51:54 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so2529500eaa.31 for ; Sun, 11 Nov 2012 21:51:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=31R65WRQhk/CnC/aESrsn14yBshrJxiQ9hOCV9pFbnM=; b=imk4QvH8puNDvKTEMB3MWmWEk8LmxJUicgMudh9AF3v6U1mViIhfYwXJaBZ4Ki64gc HycUk1xlmiMIRiBnsCO0iQy8cqDWExH9dk5SSPFXYkN4b7IDwdwl3YrmGMK9qBeJYI/S 6EGJIZXN8Sy4e1G7BHgw4pFVDZk496znaod8+ZGjPozA1pvqLw6t7VkFx44thmZDf7CV qwYLSGURsaDbTKnsv++hkSLEBgZdyIgH6mApTMq46cJE8vUUw3dQ/jYc9VNBy/sWMmrU L9aAPxFuoVyBZCh03NCnSkaOwXHPnhicn45Oc0Z6OV9S/0EcNNjdQqX1BO8nGii9aF4v uV9A== Received: by 10.14.172.195 with SMTP id t43mr60019537eel.17.1352699513663; Sun, 11 Nov 2012 21:51:53 -0800 (PST) Received: from [10.87.158.21] ([80.187.201.44]) by mx.google.com with ESMTPS id 2sm1649771eef.17.2012.11.11.21.51.50 (version=SSLv3 cipher=OTHER); Sun, 11 Nov 2012 21:51:52 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> Date: Mon, 12 Nov 2012 06:51:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQl/lsJi/8Gcd4ia50VjOhunCBlKj/sZ620sGqTGHpRATYgcplqRAoM1FjAjnFWfhv4FVS1A Cc: "" , "Viberg, Neil" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 05:51:57 -0000 Op 10 nov. 2012, om 19:35 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Nov 10, 2012, at 10:12 AM, Teco Boot wrote: >=20 >>=20 >> Op 9 nov. 2012, om 20:51 heeft Stan Ratliff (sratliff) het volgende = geschreven: >>=20 >>>=20 >>> On Nov 9, 2012, at 2:45 PM, Teco Boot wrote: >>>=20 >>>> Which link gets overloaded? I cannot see why there would be any = difference. Routers are passive, radio just send its info for other = peers. >>>>=20 >>>> But, on other side of RF link, there is info for each router on = this side. Info is per MAC address. In fact, MAC addresses could be for = a router or a host. >>>=20 >>> How? How did the far-end radio get the MAC information on its = routers? >> This is data plane. What about a hello packet? >=20 > And if you're going to rely on HELLO packets, and ARP, and IPv6 ND, = then you aren't using (and don't need) DLEP. Please explain. I never heard of one of the mentioned protocols can = provide link metrics. There is code out there that provides the link metrics *in addition* to = routing protocols and ARP/ND. It is needed. I use it. =20 >=20 >>=20 >>> Because I assume that it, too, is in "send only" mode, therefore, it = knows *nothing* about the router or routers on its end (just as the = "local radio" knows nothing about local devices)=85. that's part of the = whole point on DLEP. >> If router is not powered, you are correct. >=20 > I don't understand that response.=20 If router does not send packets, bridges do not learn routes for MAC = forwarding, nor do radios learn link metrics for it. Teco >=20 > Stan >=20 >>=20 >> Teco >>=20 >>>=20 >>> And no, no ticket required. >>>=20 >>> Stan >>>=20 >>>>=20 >>>> If you had flow control in mind, that is another story. This = doesn't meet my requirements, as stated before a couple of times. >>>>=20 >>>> Should I open a ticket for this? >>>>=20 >>>> Teco >>>>=20 >>>> Op 9 nov. 2012, om 20:29 heeft Stan Ratliff (sratliff) het volgende = geschreven: >>>>=20 >>>>> One (of many) things that confuses me about DLEP-Lite is the = notion that the modem (or radio, or bearer) would "strobe" packets to = "some address" (let's say some sort of site-local scoped multicast = address) and not know (or care) about responses. What if, in that case, = I put multiple routers "behind" the modem that can hear the strobes? = Pretty easy to get the link overloaded, just as before=85 so, I'm not = seeing any general benefit, unless some assumptions are made as to the = overall structure of the network. >>>>>=20 >>>>> Regards, >>>>> Stan >>>>>=20 >>>>> On Nov 9, 2012, at 1:08 PM, Viberg, Neil wrote: >>>>>=20 >>>>>> Folks, >>>>>>=20 >>>>>> I hadn't heard the security argument for DLEP Lite before but, = having >>>>>> some limited exposure to red-black boundaries, I can understand = the >>>>>> desire/need for a one-way protocol. >>>>>>=20 >>>>>> I have colleagues who would like a DLEP Lite for a different = reason. >>>>>> They see it as a way to reduce development cost along with cpu = and >>>>>> communication load on the modem side of the information flow. >>>>>>=20 >>>>>> Another situation where DLEP Lite would be sufficient is with a = modem >>>>>> that isn't sophisticated enough to determine its neighbors but = could >>>>>> give basic information about its transmission state. DLEP Lite = would >>>>>> offer an extremely lightweight and standardized way to learn = about the >>>>>> modem and its basic capabilities. >>>>>>=20 >>>>>> A few things to consider: >>>>>>=20 >>>>>> 1. having a DLEP Lite does not lessen the work the router has to = do. >>>>>> Whether the modem thinks it has a session or not, the router will = need >>>>>> to treat the flow of data from the modem as a session except = without any >>>>>> well known points at which failure can be detected. I think that = the >>>>>> router's response to failed modems will be slower, in general, = with a >>>>>> DLEP Lite. >>>>>>=20 >>>>>> 2. users of DLEP Lite would need to carefully balance the modem = savings >>>>>> with the system cost. With DLEP Lite the amount of messaging = towards the >>>>>> router will need to have a rate that is a function of the number = of >>>>>> modem neighbors, rate of significant change of link parameters = *and* the >>>>>> probability that a specific DLEP message can be lost. DLEP Lite = moves >>>>>> the information model to a pure soft state approach while the = original >>>>>> DLEP model is much closer to a hard state model. This implies = that the >>>>>> consistency of router state depends on the flow of information = from the >>>>>> modem to overcome the packet loss rate *but* there is no = communication >>>>>> from the router back to the modem so it is very difficult for the = modem >>>>>> to estimate packet loss rate. If one has a strong desire for = consistent >>>>>> state in the router and the modem has a large number of neighbors = and/or >>>>>> volatile links then the messaging rate may be considerably higher = than >>>>>> the ACKed exchange of a straight DLEP implementation. >>>>>>=20 >>>>>> 3. DLEP Lite would need to be a required part of the router and = the >>>>>> modem would be able to implement either the full DLEP or DLEP = Lite. >>>>>>=20 >>>>>>=20 >>>>>> Cheers, >>>>>> Neil Viberg >>>>>> Network Architect >>>>>> C3ISS Business Unit >>>>>> General Dynamics Canada >>>>>>=20 >>>>>> P.S. I personally tend to use the generic term bearer rather than = modem >>>>>> because the modem is just one of many components in every device = I've >>>>>> worked with.=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Excerpt from manet Digest Vol 102 Issue 117----- >>>>>>=20 >>>>>> = ---------------------------------------------------------------------- >>>>>>=20 >>>>>> Message: 1 >>>>>> Date: Fri, 9 Nov 2012 13:59:39 +0100 >>>>>> From: Teco Boot >>>>>> To: "Ivancic, William D. (GRC-RHN0)" >>>>>> Cc: "manet@ietf.org" >>>>>> Subject: Re: [manet] DLEP Lite? >>>>>> Message-ID: <55238ACB-F5B2-40EB-A906-96E0F4387928@inf-net.nl> >>>>>> Content-Type: text/plain; charset=3D"windows-1252" >>>>>>=20 >>>>>> The reason why I need a one way protocol is that I have to deal = with >>>>>> some security mandates. All outgoing traffic from the router port = has to >>>>>> be crypted packets, or related to the crypto engine. This piece = of code >>>>>> for crypto and firewall needs to be reviewed and certified. = Import of >>>>>> data is less a problem. >>>>>>=20 >>>>>> During WGLC review, I'll start reading security considerations. = When it >>>>>> describes something like "this protocol does not introduce a = covert >>>>>> channel", I'll get more interested. As I see it right now, there = is a >>>>>> need to split the DLEP protocol draft. The basic mode would be >>>>>> DLEP-Lite, and provide transport from radio to router only. Maybe >>>>>> DLEP-heavy is a better name for it, it could need more lines of = code. >>>>>> And more bits on the wire. >>>>>>=20 >>>>>> Teco >>>>>>=20 >>>>>> Op 8 nov. 2012, om 20:00 heeft Ivancic, William D. (GRC-RHN0) het >>>>>> volgende geschreven: >>>>>>=20 >>>>>>> DLEP, at least the last time I read it, which was a month or two = ago, >>>>>> is client/server based with sessions setup between radio and = router. >>>>>> ModemLPA simply has the radio (or crypto device or whatever) = sending out >>>>>> status packets either periodically or when something changes. = ModemLPA >>>>>> could send either to all routers address, a unicast address, or = perhaps >>>>>> a organizationally scoped multicast address. =20 >>>>>>>=20 >>>>>>> "It should be possible to use the DLEP message formats without = all the >>>>>> signaling required for the DLEP client/server session to perform = the >>>>>> functions addressed in this draft. The modem would simply = provide link >>>>>> states out via multicast or unicast UDP datagrams (DLEP-Lite)." >>>>>>>=20 >>>>>>> DLEP is designed to operate only over the local-link and does = not >>>>>> accommodate systems that are multiple hops away from the modem. = Upstream >>>>>> notification would be a simple modification to DLEP (I think). >>>>>>>=20 >>>>>>> "To handle advertisements beyond the local interface, Internet >>>>>>> Protocol version 4 (IPv4) organizational-scoped multicast and >>>>>>> Internet Protocol version 6 (IPv6) site-local multicast MAY be = used >>>>>>> with no explicit configuration in the modem. Use of IPv4 >>>>>>> administratively-scoped multicast and IPv6 site-local multicast >>>>>> could >>>>>>> handle both devices that are directly connected to the modem as >>>>>> well >>>>>>> as hosts and applications that are multiple hops away [RFC2365] >>>>>>> [RFC2373]." >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Nov 7, 2012, at 5:08 PM, Dowdell, John wrote: >>>>>>>=20 >>>>>>>> @Stan and Will >>>>>>>>=20 >>>>>>>> Can you explain exactly what you mean by DLEP Lite, as = mentioned in >>>>>> the dying moments of the WG meeting? Lite in what respect? I = would not >>>>>> consider DLEP to be particularly overweight, so understanding = exactly >>>>>> what you would intend to remove would be useful. >>>>>>>>=20 >>>>>>>> Also, IMHO it is enough work simply to define one DLEP, so = having >>>>>> another one to choose from is not likely to help the radio = manufacturers >>>>>> along the road to implementation. Having a mandatory core of = DLEP, with >>>>>> optional extras, I can support. Having a further cut down edition = means >>>>>> you then either have to know beforehand whether the radio = supports full >>>>>> or Lite DLEP, or you have to be able to automatically query the = radio to >>>>>> find out (which is a feature I suggested long, long ago, you may = recall >>>>>> ?.). >>>>>>>>=20 >>>>>>>> Regards >>>>>>>>=20 >>>>>>>> John >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> manet mailing list >>>>>>>> manet@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>>=20 >>>>>> The information contained in this e-mail message is PRIVATE. It = may contain confidential information and may be legally privileged. It = is intended for the exclusive use of the addressee(s). If you are not = the intended recipient, you are hereby notified that any dissemination, = distribution or reproduction of this communication is strictly = prohibited. If the intended recipient(s) cannot be reached or if a = transmission problem has occurred, please notify the sender immediately = by return e-mail and destroy all copies of this message.=20 >>>>>> Thank you.=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>=20 >>=20 >=20 From teco@inf-net.nl Sun Nov 11 22:00:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC44221F851B for ; Sun, 11 Nov 2012 22:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yS821+uDfFy for ; Sun, 11 Nov 2012 22:00:34 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 156D821F8512 for ; Sun, 11 Nov 2012 22:00:33 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so2531680eaa.31 for ; Sun, 11 Nov 2012 22:00:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=qQjpX8N3VKX0cpl+ItdMkx/bzmlRdmdc6z9XZaNusbc=; b=Taz/KGWH2Ebnt9v6Ag/S4C//Dsb58+wNZOfjDdZRmvDrLi+lL3ANMRqrj3j3M84eHt tMJ58OTUg+tTLNWEyZ9WlcGqf+W1OS6Fnz1yiuDlcDIGewYJ5L5g5d6yqmBd0MLSismM dNgwryECsdZ5xtw4/LmXAc7dvQLf8b4dbytC3bCY7Z9VUCvePfXBEm2pswwJPdBp8/tA qX9v2/hYkFbT2BsHD4so40yd5Wstpio2j/7GYPaTlX0BU59IQkePpaDJ+rezbj33qh7y QQ/uuB5FwWlsxPMHlAWN26u0akwHNDs8BZ4POg5f9olAtv6DjYjErNdKgCCJ3p7KxhPT /IoQ== Received: by 10.14.193.134 with SMTP id k6mr18670600een.15.1352700033038; Sun, 11 Nov 2012 22:00:33 -0800 (PST) Received: from [10.87.158.21] ([80.187.201.44]) by mx.google.com with ESMTPS id 42sm14110296eee.0.2012.11.11.22.00.30 (version=SSLv3 cipher=OTHER); Sun, 11 Nov 2012 22:00:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> Date: Mon, 12 Nov 2012 07:00:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQn+UeA5MC2GmzwjFB0RJNqNGI0iINZhVa8pu4wY9LFkfmXj4JDDehMeNCiMm/Qn3/bdXkPe Cc: "Viberg, Neil" , "" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 06:00:35 -0000 Op 11 nov. 2012, om 00:13 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Nov 10, 2012, at 1:53 PM, Henning Rogge wrote: >=20 >> On Sat, Nov 10, 2012 at 7:35 PM, Stan Ratliff (sratliff) >> wrote: >>>>> How? How did the far-end radio get the MAC information on its = routers? >>>> This is data plane. What about a hello packet? >>>=20 >>> And if you're going to rely on HELLO packets, and ARP, and IPv6 ND, = then you aren't using (and don't need) DLEP. >>=20 >> Even with Hello-Packets on layer-3, ARPs (maybe with a transparent >> cache on the radio) and IPv6 ND you would still need DLEP to get >> access to the layer-2 data of the radio. >=20 > My point is that any layer 2 information you get is useless, because = you can't correlate the two with this "one way, no responses" mode of = operation. Assume there are 3 router/modem setups - A, B, and C. = Router/modem A can see both B and C. The RF path between A and B is at = 40Mbps; the path between A and C is only 6Mbps=85. All three modems are = "strobing" in this one-way communications mode back to their respective = routers. So all that router A knows is that there are a couple of = potential partners "out there" - and with HELLO packets, and IPv6 = ND/ARP, router A can actually find them. But how does A know that the = path to B os 40Mbps while the path to C is only 6? With DLEP :-) > There's no correlation - since the modems are operating in bridge = mode, there's no indication whatsoever as to which router (B or C) is on = which radio. Router A only has to know the cost of the link to B and to C. Or the = cost from B and from C.=20 This *to* / *from* is another quite important open issue. Open ticket = for it? > Because there was no "radio-to-MAC" correlation, ?? > because the radios don't want to hear anything from the routers. ?????? > Unless, of course, the radios are surreptitiously snooping the traffic = coming in off of their wired connections, looking for things like this. = But that seems a lot more complex to me.=20 Each 802.1D bridge *has* to do this. I don't get your point. >=20 > This mode of operation *only* works if you make assumptions about the = structure of the network. No. > Assumptions I don't believe we should be making. Agreed :-) > Like, there's *only* 1 router behind each radio. ??? > And that the RF link is the smallest in terms of bandwidth (or = latency, or whatever metric you wish to key on). And in the case I = describe above, the assumption is that the bandwidth to *all* stations = across the RF is the same - which isn't true, and if it is, why do we = need dynamic metrics in the first place? I am completely lost in your response. Can we assume 802.1D bridging? Teco >=20 > Stan >=20 >=20 >>=20 >> Henning Rogge >>=20 >> --=20 >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >=20 From abdussalambaryun@gmail.com Tue Nov 13 11:27:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEA721F8679 for ; Tue, 13 Nov 2012 11:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgwoQmfTkwai for ; Tue, 13 Nov 2012 11:27:14 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 568CD21F865C for ; Tue, 13 Nov 2012 11:27:13 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so8666116vbb.31 for ; Tue, 13 Nov 2012 11:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=xYUFR1DlxQKC73mbkS+GaqC3YVlKgZw580A84cqlSYU=; b=Z98Jof0pfIy70q4JJZ+8pknYVCqb2KC3QV5EWSNjE1b//RetQjUGRH4YNKPg/RG/dR G+sAIFH4Y60y1KMZZhug7f16iQg2yEY1VK0xxb2+2yMh75uEI43udGqMWrByZ8+23u77 t+XT43b+nfI1FIPuet8OzqiEEf5fleB8HWCdLdCAxHmvvaQBe2xmvKseh8MtsF82zGIt 16fEqAR7qugMZQKLZyxCw8YPDnYVPVp2q3biwgQ2fAxHiyj/ctoZDGLpBcIo6EZV3L0k ZL+85+emUl/j+SdxjD14GSFz4Xhz+i07snW74uYql9PiBPt+LGCGg9rIniM1/mnVJHNZ 6efA== MIME-Version: 1.0 Received: by 10.52.66.234 with SMTP id i10mr4394054vdt.55.1352834832687; Tue, 13 Nov 2012 11:27:12 -0800 (PST) Received: by 10.220.204.9 with HTTP; Tue, 13 Nov 2012 11:27:12 -0800 (PST) In-Reply-To: <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> Date: Tue, 13 Nov 2012 19:27:12 +0000 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=20cf307d0602a461c604ce656779 Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 19:27:17 -0000 --20cf307d0602a461c604ce656779 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >Because there was no "radio-to-MAC" correlation, IMO, correlation concept not understood, but understand that we don't need bridge mode. However, still waiting for the respond to Teco question, AB On Mon, Nov 12, 2012 at 6:00 AM, Teco Boot wrote: > > Op 11 nov. 2012, om 00:13 heeft Stan Ratliff (sratliff) het volgende > geschreven: > > > > > On Nov 10, 2012, at 1:53 PM, Henning Rogge wrote: > > > >> On Sat, Nov 10, 2012 at 7:35 PM, Stan Ratliff (sratliff) > >> wrote: > >>>>> How? How did the far-end radio get the MAC information on its > routers? > >>>> This is data plane. What about a hello packet? > >>> > >>> And if you're going to rely on HELLO packets, and ARP, and IPv6 ND, > then you aren't using (and don't need) DLEP. > >> > >> Even with Hello-Packets on layer-3, ARPs (maybe with a transparent > >> cache on the radio) and IPv6 ND you would still need DLEP to get > >> access to the layer-2 data of the radio. > > > > My point is that any layer 2 information you get is useless, because yo= u > can't correlate the two with this "one way, no responses" mode of > operation. Assume there are 3 router/modem setups - A, B, and C. > Router/modem A can see both B and C. The RF path between A and B is at > 40Mbps; the path between A and C is only 6Mbps=85. All three modems are > "strobing" in this one-way communications mode back to their respective > routers. So all that router A knows is that there are a couple of potenti= al > partners "out there" - and with HELLO packets, and IPv6 ND/ARP, router A > can actually find them. But how does A know that the path to B os 40Mbps > while the path to C is only 6? > With DLEP :-) > > > There's no correlation - since the modems are operating in bridge mode, > there's no indication whatsoever as to which router (B or C) is on which > radio. > Router A only has to know the cost of the link to B and to C. Or the cost > from B and from C. > This *to* / *from* is another quite important open issue. Open ticket for > it? > > > Because there was no "radio-to-MAC" correlation, > ?? > > > because the radios don't want to hear anything from the routers. > ?????? > > > Unless, of course, the radios are surreptitiously snooping the traffic > coming in off of their wired connections, looking for things like this. B= ut > that seems a lot more complex to me. > Each 802.1D bridge *has* to do this. I don't get your point. > > > > > This mode of operation *only* works if you make assumptions about the > structure of the network. > No. > > > Assumptions I don't believe we should be making. > Agreed :-) > > > Like, there's *only* 1 router behind each radio. > ??? > > > And that the RF link is the smallest in terms of bandwidth (or latency, > or whatever metric you wish to key on). And in the case I describe above, > the assumption is that the bandwidth to *all* stations across the RF is t= he > same - which isn't true, and if it is, why do we need dynamic metrics in > the first place? > > I am completely lost in your response. Can we assume 802.1D bridging? > > Teco > > --20cf307d0602a461c604ce656779 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
>Because there was no "radio-to-MAC" correlation,

= IMO, correlation concept=A0not understood, but understand that we don't= need bridge mode. However, still waiting for the=A0respond to Teco questio= n,
=A0
AB
On Mon, Nov 12, 2= 012 at 6:00 AM, Teco Boot <teco@inf-net.nl> wrote:

Op 11 nov. 2012, om 00:13 heeft Stan Ratliff (sratliff) het volgende geschr= even:

>
> On Nov 10, 2012, at 1:53 PM, Henning Rogge wrote:
>
>> On Sat, Nov 10, 2012 at 7:35 PM, Stan Ratliff (sratliff)
>> <sratliff@cisco.com&g= t; wrote:
>>>>> How? How did the far-end radio get the MAC information= on its routers?
>>>> This is data plane. What about a hello packet?
>>>
>>> And if you're going to rely on HELLO packets, and ARP, and= IPv6 ND, then you aren't using (and don't need) DLEP.
>>
>> Even with Hello-Packets on layer-3, ARPs (maybe with a transparent=
>> cache on the radio) and IPv6 ND you would still need DLEP to get >> access to the layer-2 data of the radio.
>
> My point is that any layer 2 information you get is useless, because y= ou can't correlate the two with this "one way, no responses" = mode of operation. Assume there are 3 router/modem setups - =A0A, B, and C.= Router/modem A can see both B and C. The RF path between A and B is at 40M= bps; the path between A and C is only 6Mbps=85. All three modems are "= strobing" in this one-way communications mode back to their respective= routers. So all that router A knows is that there are a couple of potentia= l partners "out there" - and with HELLO packets, and IPv6 ND/ARP,= router A can actually find them. But how does A know that the path to B os= 40Mbps while the path to C is only 6?
With DLEP :-)

> There's no correlation - since the modems are operating in bridge = mode, there's no indication whatsoever as to which router (B or C) is o= n which radio.
Router A only has to know the cost of the link to B and to C. Or the = cost from B and from C.
This *to* / *from* is another quite important open issue. Open ticket for i= t?

> Because there was no "radio-to-MAC" correlation,
??

> because the radios don't want to hear anything from the routers.
??????

> Unless, of course, the radios are surreptitiously snooping the traffic= coming in off of their wired connections, looking for things like this. Bu= t that seems a lot more complex to me.
Each 802.1D bridge *has* to do this. I don't get your point.

>
> This mode of operation *only* works if you make assumptions about the = structure of the network.
No.

> Assumptions I don't believe we should be making.
Agreed :-)

> Like, there's *only* 1 router behind each radio.
???

> And that the RF link is the smallest in terms of bandwidth (or latency= , or whatever metric you wish to key on). And in the case I describe above,= the assumption is that the bandwidth to *all* stations across the RF is th= e same - which isn't true, and if it is, why do we need dynamic metrics= in the first place?

I am completely lost in your response. Can we assume 802.1D bridging?=

Teco
=A0
--20cf307d0602a461c604ce656779-- From hrogge@googlemail.com Tue Nov 13 11:31:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0580421F8630 for ; Tue, 13 Nov 2012 11:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xkVhXqa0Y8u for ; Tue, 13 Nov 2012 11:31:31 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8999221F8628 for ; Tue, 13 Nov 2012 11:31:31 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so3429808dan.31 for ; Tue, 13 Nov 2012 11:31:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XcrC2dbzD8lSQT2DVrQRHlpBLCwFn3CqHt96PPb+Tis=; b=BjT+fKEVnexlohyvF11nbpm1Li5Eor++oMnDX4uAYBv/ZPmLc5zGJYMy2iUCp1B6UD 3tmOKM/8qPUKrt8bFcWa2EMLUggGObxrRuK2s0fidCA7z4qMUg+P5EW7sNEIl7VaaGYV RJchjqkifFI6I4hB+jPTk4GXPEiDhRq5ibUfKRcpn9pnt9v/tu421W5ISnsLg5q/hLi3 R02XxOsLUX0ZTBP9dlajsgZo51i51hL6+sVaQzC+2dp2D7EZPg1U4Gywsr2RxTwpvYFX oYDOUOfwuxkpYGCm7wSH1Z2jPLuoMFGBlBnIT5jr65vFsA6vBffkkT4kbp1FECS85q90 Y2gQ== Received: by 10.66.84.131 with SMTP id z3mr107661pay.34.1352835091347; Tue, 13 Nov 2012 11:31:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Tue, 13 Nov 2012 11:31:11 -0800 (PST) In-Reply-To: References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> From: Henning Rogge Date: Tue, 13 Nov 2012 20:31:11 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 19:31:32 -0000 On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun wrote: >>Because there was no "radio-to-MAC" correlation, > > IMO, correlation concept not understood, but understand that we don't need > bridge mode. However, still waiting for the respond to Teco question, What do you mean with "we don't need bridge mode" ? Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Tue Nov 13 12:38:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EB521F86EE for ; Tue, 13 Nov 2012 12:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3gW1wT3uBLk for ; Tue, 13 Nov 2012 12:38:21 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6783C21F86E9 for ; Tue, 13 Nov 2012 12:38:21 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so1686511iaf.31 for ; Tue, 13 Nov 2012 12:38:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OKJ/zOcl8BiDD5EzD6MSIRCM2Zf6vJAt+jQrS5ISqQE=; b=pLBh9d3i7KJmfnMCCndEUicGVV++UI3dJB9JApm6lCv5Qw16F1/nltlgsp7J527abZ fdt5odVwoB2LL1g7He5Bjmym+Mj/WpADb71SZj7FQYBWXIa+9MD2bX079XHQReCLPg4m 7ZMhJckMv2AjZC21TaT/M03WMCJxyx0hUGXL69P5lfMOu9S6jkQEL8R2T6uy4sDyRggI OHmmtGLUJF1Xq8HXJ05WQ5mfxZbVyT+uD6vvgVWHCoCQhjNfy1s4zEaxoSViXTynPf+7 ZdbZ0CLqZ6L//I3j7VsR9njtcG1xq+kaghdCTWt7jcwN3GeD/+dfeye9myxQOao0pdYN HH9g== MIME-Version: 1.0 Received: by 10.50.7.232 with SMTP id m8mr2048732iga.48.1352839100863; Tue, 13 Nov 2012 12:38:20 -0800 (PST) Received: by 10.64.25.46 with HTTP; Tue, 13 Nov 2012 12:38:20 -0800 (PST) In-Reply-To: References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> Date: Tue, 13 Nov 2012 20:38:20 +0000 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=f46d04462dd20b96a204ce6666ba Cc: manet Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 20:38:22 -0000 --f46d04462dd20b96a204ce6666ba Content-Type: text/plain; charset=ISO-8859-1 I mean I understand from discussions that Stan's reply to Teco that he does not beleive to use bridge mode, AB On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge wrote: > On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun > wrote: > >>Because there was no "radio-to-MAC" correlation, > > > > IMO, correlation concept not understood, but understand that we don't > need > > bridge mode. However, still waiting for the respond to Teco question, > > What do you mean with "we don't need bridge mode" ? > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > --f46d04462dd20b96a204ce6666ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I mean I understand from discussions that Stan's reply to Teco tha= t he does not beleive to=A0use bridge mode,
=A0
AB
<= br>
On Tue, Nov 13, 2012 at 7:31 PM, Hennin= g Rogge <hrogge@googlemail.com> wrote:
On Tue, Nov 13, 2012 at 8:27 PM, Abdussa= lam Baryun
<abdussalambaryun@gmail.co= m> wrote:
>>Because there was no "radio-to-MAC" correlation,
>
> IMO, correlation concept not understood, but understand that we don= 9;t need
> bridge mode. However, still waiting for the respond to Teco question,<= br>
What do you mean with "we don't need bridge mode" ?

Henning Rogge
--
Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that
was before the present government."

--f46d04462dd20b96a204ce6666ba-- From teco@inf-net.nl Wed Nov 14 04:15:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1B521F84E1 for ; Wed, 14 Nov 2012 04:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zolVMNq1z2zV for ; Wed, 14 Nov 2012 04:15:07 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A44F21F84E0 for ; Wed, 14 Nov 2012 04:15:07 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so242778eek.31 for ; Wed, 14 Nov 2012 04:15:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=dMfBWsSKtm1A8GaBMYLJdDQGGtD6t7IUbHNp/09AEgg=; b=aihP3xFCkJFHT0lukp/KCcsRIvbOB25EpCYXJp5h3W97GESRjrdmD13Nu/eR2LYeY9 MdSWVcT0tpa4YLjnMD7EHF/o8+1psj/qRsuRkzt3lcbQvu9pSdy1xKk/8V3/RBN4KHU2 VmxXa7C2TbyD+qiik6KqiEpFO8lXFL7saTzbC6PU0hwpbPV7rzrocmx/jrPycpkjwcOy MiHlL1tie2qSA9PoEzmtLPrCDExRjNrtlaTW+KbnURtcbDfRkFyBdX91OHIJX7rcPOXE MuZJEsqfXki0RwN3IBjckp1Ebnf6GM+oSCXS9suKO9K0k17xmFKRF+WTpy888qvix2mf 2Grw== Received: by 10.14.1.69 with SMTP id 45mr86635271eec.23.1352895306297; Wed, 14 Nov 2012 04:15:06 -0800 (PST) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id g5sm29257711eem.4.2012.11.14.04.15.04 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Nov 2012 04:15:04 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Wed, 14 Nov 2012 13:15:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmIwb5GqTJWRPkZdBLfqLmxPV9qKiQCOyv9mobyoe0vkGIr6yeauTkEMQSB3nHy6nykaVq2 Cc: manet Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 12:15:08 -0000 Attempt to make thinks clear. Radio is L2 device, could be 802.1D bridge or repeater. Device is=20 self learning. It has MAC addresses and probably an IP address.=20 Routers are connected to radio with ethernet or equivalent. Routers have a sub-IP connection with each other via the ethernet - RF - ethernet sub-IP link. Connection is based on 802.1 MAC addresses. Radio has the task to deliver router originated frames to destination, based on destination MAC address. Could be L2 multicast or broadcast. With DLEP, radios have the task to keep track of link properties between each connected device. Could be *any* connected ethernet NIC, as long as=20= it has an 802.1 address and it sends a packet every now and then. All=20 radios in the sub-IP network automatically learn the existence of each=20= connected sending node, as required by 802.1D. DLEP shall be 100%=20 compatible with this widely deployed mechanism. It shall provide link metrics for far end connected MAC addresses to locally connected nodes. It shall work this way for single- and multi-hop sub-IP networks. Teco Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het volgende = geschreven: > I mean I understand from discussions that Stan's reply to Teco that he = does not beleive to use bridge mode, > =20 > AB >=20 > On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge = wrote: > On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun > wrote: > >>Because there was no "radio-to-MAC" correlation, > > > > IMO, correlation concept not understood, but understand that we = don't need > > bridge mode. However, still waiting for the respond to Teco = question, >=20 > What do you mean with "we don't need bridge mode" ? >=20 > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Wed Nov 14 07:34:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F88721F85FF for ; Wed, 14 Nov 2012 07:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG0touGR4qZB for ; Wed, 14 Nov 2012 07:34:14 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8827C21F85FE for ; Wed, 14 Nov 2012 07:34:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3038; q=dns/txt; s=iport; t=1352907254; x=1354116854; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=D44suceuOCCjWrxhI9yahNgJZHOlGl64i/Sgj81mL14=; b=Fa7RkgdTWSwRftIr1Rk/GnYkPoFHhyhUo7gADPMo00jZyFGFRBPjxDlq mdWLzHyaQKz3uTV5QPp60F/H2zUkVA17/7TMPXfrgkbITmTe+NmCGvLA9 lfhvnVu8N1DriJQyiBGDIVt7wnS2vi+BWCr5mp/XRaJZhdgWsrZMPOnwX g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADa5o1CtJXG9/2dsb2JhbABEwz2BCIIeAQEBAwEBAQEPASczAQsFCwIBCBgKFBAhBgslAgQOBQgah1YDCQYLmxaWOQ2JUASLRGmFS2EDlCeNB4MmgWuCb4IZ X-IronPort-AV: E=McAfee;i="5400,1158,6895"; a="142325128" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 14 Nov 2012 15:34:14 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAEFYDJD017638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Nov 2012 15:34:13 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 09:34:13 -0600 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] DLEP Lite? (Teco Boot) Thread-Index: Ac2+jVdl8St7CxHOQImNx8g7RjcZBAADdN/wABHqP4AAAJBkAAAANyIAACiFJoAABx7cAAAAnAOAAAkZpoAAQH5XAABOdncAAAAjnYAAAlheAAAgtueAAAb0igA= Date: Wed, 14 Nov 2012 15:34:12 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> <8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl> In-Reply-To: <8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.100] Content-Type: text/plain; charset="us-ascii" Content-ID: <67411F9590679648BE2AB1A06497B436@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 15:34:15 -0000 On Nov 14, 2012, at 7:15 AM, Teco Boot wrote: > Attempt to make thinks clear. >=20 > Radio is L2 device, could be 802.1D bridge or repeater. Device is=20 > self learning. It has MAC addresses and probably an IP address.=20 > Routers are connected to radio with ethernet or equivalent. > Routers have a sub-IP connection with each other via the ethernet - RF > - ethernet sub-IP link. Connection is based on 802.1 MAC addresses. > Radio has the task to deliver router originated frames to destination, > based on destination MAC address. Could be L2 multicast or broadcast. > With DLEP, radios have the task to keep track of link properties between > each connected device. Could be *any* connected ethernet NIC, as long as= =20 > it has an 802.1 address and it sends a packet every now and then. All=20 > radios in the sub-IP network automatically learn the existence of each=20 > connected sending node, as required by 802.1D. DLEP shall be 100%=20 > compatible with this widely deployed mechanism. It shall provide link > metrics for far end connected MAC addresses to locally connected nodes. > It shall work this way for single- and multi-hop sub-IP networks. I think we're talking past each other. DLEP has not assumed 802.1D support = in the radios, so all of your "shall" verbiage doesn't make sense. The only= assumption DLEP makes (at least as of now) is that the radios operate in t= ransparent bridge mode - that the destination MAC is that of the far-end ro= uter, not any of the intervening devices. And without some flows from route= r *to* radio, your "one-way only" communication mode doesn't work, because = you can't correlate a router to it's attached RF device. And I'm not OK wit= h *requiring* that level of functionality in the radio.=20 Stan =20 >=20 > Teco >=20 >=20 > Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het volgende geschreven= : >=20 >> I mean I understand from discussions that Stan's reply to Teco that he d= oes not beleive to use bridge mode, >>=20 >> AB >>=20 >> On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge w= rote: >> On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun >> wrote: >>>> Because there was no "radio-to-MAC" correlation, >>>=20 >>> IMO, correlation concept not understood, but understand that we don't n= eed >>> bridge mode. However, still waiting for the respond to Teco question, >>=20 >> What do you mean with "we don't need bridge mode" ? >>=20 >> Henning Rogge >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Wed Nov 14 07:55:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AC021F85FF for ; Wed, 14 Nov 2012 07:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fq9qzR4ij1-O for ; Wed, 14 Nov 2012 07:55:41 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A430D21F84A1 for ; Wed, 14 Nov 2012 07:55:40 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so299176eaa.31 for ; Wed, 14 Nov 2012 07:55:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=d1x5i/BrpJSm8OWVa0JXp/0nVGQgfy3f1GLcffkzCk0=; b=NhgCx/CnARYwiTgJ2AueT0c83SQtRFbWRsRrHadwdY4a7LlyNNh3Ugu8YLs5lC28bc vJRkSlf4y5mFuY7+fVg+qyHvM0laBrFRUqRabX1nLPV5lbyO8/85WEasAtu2G3E+9mqX oIZ5ROE+X8zUPJVi26mJbWHTYSkL5Vf3EHJ2AovkLaj8EjKjg4rXsAJ8XLJPjvTILewI ziruLqALmJ6Cg/yc0LT7twBIqfklsMn6NR876qMESbS21ose4fCygeDeJJBnzK40IxqH QX8Hk130472qYIER9gwKFScc5DfjDlUpAXE2RsfJtgXWi1Byxsl3CT5Www0owH+rKu8A ZWYQ== Received: by 10.14.203.132 with SMTP id f4mr88623874eeo.11.1352908539604; Wed, 14 Nov 2012 07:55:39 -0800 (PST) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id k2sm30269934eep.15.2012.11.14.07.55.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Nov 2012 07:55:38 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com> Date: Wed, 14 Nov 2012 16:55:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> <8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlGyuSieZRPXL1dkWeXI0qYWLutr1FZFkQk0qMmjFuXg6qngoNt4IMZZkv5l7IAsADLGmMX Cc: manet Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 15:55:41 -0000 Op 14 nov. 2012, om 16:34 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Nov 14, 2012, at 7:15 AM, Teco Boot wrote: >=20 >> Attempt to make thinks clear. >>=20 >> Radio is L2 device, could be 802.1D bridge or repeater. Device is=20 >> self learning. It has MAC addresses and probably an IP address.=20 >> Routers are connected to radio with ethernet or equivalent. >> Routers have a sub-IP connection with each other via the ethernet - = RF >> - ethernet sub-IP link. Connection is based on 802.1 MAC addresses. >> Radio has the task to deliver router originated frames to = destination, >> based on destination MAC address. Could be L2 multicast or broadcast. >> With DLEP, radios have the task to keep track of link properties = between >> each connected device. Could be *any* connected ethernet NIC, as long = as=20 >> it has an 802.1 address and it sends a packet every now and then. All=20= >> radios in the sub-IP network automatically learn the existence of = each=20 >> connected sending node, as required by 802.1D. DLEP shall be 100%=20 >> compatible with this widely deployed mechanism. It shall provide link >> metrics for far end connected MAC addresses to locally connected = nodes. >> It shall work this way for single- and multi-hop sub-IP networks. >=20 > I think we're talking past each other. DLEP has not assumed 802.1D = support in the radios, so all of your "shall" verbiage doesn't make = sense. The only assumption DLEP makes (at least as of now) is that the = radios operate in transparent bridge mode - that the destination MAC is = that of the far-end router, not any of the intervening devices. As is in 802.1D. > And without some flows from router *to* radio, your "one-way only" = communication mode doesn't work, because you can't correlate a router to = it's attached RF device. It is the RF device that is locally connected. Not the far end RF = device. Cannot be mistaken, can it? > And I'm not OK with *requiring* that level of functionality in the = radio. I didn't read anything here that didn't match 802.1D. Teco >=20 > Stan >=20 >=20 >>=20 >> Teco >>=20 >>=20 >> Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het volgende = geschreven: >>=20 >>> I mean I understand from discussions that Stan's reply to Teco that = he does not beleive to use bridge mode, >>>=20 >>> AB >>>=20 >>> On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge = wrote: >>> On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun >>> wrote: >>>>> Because there was no "radio-to-MAC" correlation, >>>>=20 >>>> IMO, correlation concept not understood, but understand that we = don't need >>>> bridge mode. However, still waiting for the respond to Teco = question, >>>=20 >>> What do you mean with "we don't need bridge mode" ? >>>=20 >>> Henning Rogge >>> -- >>> Steven Hawkings about cosmic inflation: "An increase of billions of >>> billions of percent in a tiny fraction of a second. Of course, that >>> was before the present government." >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From sratliff@cisco.com Wed Nov 14 10:31:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43DA21F8803 for ; Wed, 14 Nov 2012 10:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74qXztHPgVDH for ; Wed, 14 Nov 2012 10:31:43 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B03F021F8516 for ; Wed, 14 Nov 2012 10:31:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3690; q=dns/txt; s=iport; t=1352917903; x=1354127503; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=a9HhfjlnS09xvDJPp8DT1KYpY59KnE1nRQGR5hNiVTw=; b=C5P8eBnidYraH4HQ374B77XwiVlg5OEw4q0MifDoJKe23MqgLXPczpsu KgaX6MtxHkrbH/U7Y+1MCQErBSWZ89HA6abBp/HjtW9TeB2Tsz2XZXoEC M7VnzIOshVsl441hYfLiPZsK6cNjr+jtdBlmmU3ay7VMstCrXU2UZ4ssY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALjio1CtJV2d/2dsb2JhbABEwziBCIIeAQEBAwEBAQEPASczAQsQAgEIGAoUECEGCyUCBA4FCBqHVgMJBgubJpY1DYlQBItEaYVLYQOUJ40HgyaBa4Jvghk X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142394951" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 14 Nov 2012 18:31:43 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAEIVhVt008653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Nov 2012 18:31:43 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 12:31:42 -0600 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] DLEP Lite? (Teco Boot) Thread-Index: Ac2+jVdl8St7CxHOQImNx8g7RjcZBAADdN/wABHqP4AAAJBkAAAANyIAACiFJoAABx7cAAAAnAOAAAkZpoAAQH5XAABOdncAAAAjnYAAAlheAAAgtueAAAb0igAAAL9VAAAFc36A Date: Wed, 14 Nov 2012 18:31:41 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42FFE2@xmb-aln-x03.cisco.com> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> <8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.34.217] Content-Type: text/plain; charset="us-ascii" Content-ID: <35C5C266BF765A48BEE7443051FDC122@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 18:31:44 -0000 On Nov 14, 2012, at 10:55 AM, Teco Boot wrote: >=20 > Op 14 nov. 2012, om 16:34 heeft Stan Ratliff (sratliff) het volgende gesc= hreven: >=20 >>=20 >> On Nov 14, 2012, at 7:15 AM, Teco Boot wrote: >>=20 >>> Attempt to make thinks clear. >>>=20 >>> Radio is L2 device, could be 802.1D bridge or repeater. Device is=20 >>> self learning. It has MAC addresses and probably an IP address.=20 >>> Routers are connected to radio with ethernet or equivalent. >>> Routers have a sub-IP connection with each other via the ethernet - RF >>> - ethernet sub-IP link. Connection is based on 802.1 MAC addresses. >>> Radio has the task to deliver router originated frames to destination, >>> based on destination MAC address. Could be L2 multicast or broadcast. >>> With DLEP, radios have the task to keep track of link properties betwee= n >>> each connected device. Could be *any* connected ethernet NIC, as long a= s=20 >>> it has an 802.1 address and it sends a packet every now and then. All=20 >>> radios in the sub-IP network automatically learn the existence of each= =20 >>> connected sending node, as required by 802.1D. DLEP shall be 100%=20 >>> compatible with this widely deployed mechanism. It shall provide link >>> metrics for far end connected MAC addresses to locally connected nodes. >>> It shall work this way for single- and multi-hop sub-IP networks. >>=20 >> I think we're talking past each other. DLEP has not assumed 802.1D suppo= rt in the radios, so all of your "shall" verbiage doesn't make sense. The o= nly assumption DLEP makes (at least as of now) is that the radios operate i= n transparent bridge mode - that the destination MAC is that of the far-end= router, not any of the intervening devices. > As is in 802.1D. >=20 >> And without some flows from router *to* radio, your "one-way only" commu= nication mode doesn't work, because you can't correlate a router to it's at= tached RF device. > It is the RF device that is locally connected. Not the far end RF device.= Cannot be mistaken, can it? Yes, it can. Given 3 radio/router pairs, each in the "one-way" mode, what M= AC address is in the Neighbor Up?=20 >=20 >> And I'm not OK with *requiring* that level of functionality in the radio= . > I didn't read anything here that didn't match 802.1D. >=20 > Teco >=20 >=20 >>=20 >> Stan >>=20 >>=20 >>>=20 >>> Teco >>>=20 >>>=20 >>> Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het volgende geschrev= en: >>>=20 >>>> I mean I understand from discussions that Stan's reply to Teco that he= does not beleive to use bridge mode, >>>>=20 >>>> AB >>>>=20 >>>> On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge = wrote: >>>> On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun >>>> wrote: >>>>>> Because there was no "radio-to-MAC" correlation, >>>>>=20 >>>>> IMO, correlation concept not understood, but understand that we don't= need >>>>> bridge mode. However, still waiting for the respond to Teco question, >>>>=20 >>>> What do you mean with "we don't need bridge mode" ? >>>>=20 >>>> Henning Rogge >>>> -- >>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>> billions of percent in a tiny fraction of a second. Of course, that >>>> was before the present government." >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 From teco@inf-net.nl Wed Nov 14 11:03:24 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AA421F856E for ; Wed, 14 Nov 2012 11:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5+yToDteBVm for ; Wed, 14 Nov 2012 11:03:23 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 476FA21F85FD for ; Wed, 14 Nov 2012 11:03:23 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so554492eek.31 for ; Wed, 14 Nov 2012 11:03:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=MtGEJlzii/EdbrOZf/PBodxWY2+nSFybpjyUOiONTDE=; b=gIrEUWSxqYGji0Oqz4j/c+jhO+8kUl0yteFDyaLXxlf2fRllMyJmN7k/jTUFgAVZ+x xO8BxKmGNBJf4dlu6quUd70wEz1xuUxhoHukMlbf1IHRlmQXuQbjzAj6mIdZ9vmtuW9I yAX6Za8qAFJvw3Pg2eZS1VITom2zb7/PvrCrdgsGwpyIIM3HDnNjgFo6N89bnOUyjEOi AcH4zEr83YN+kIPz97yAlBarl2YCicCKN8t+dixZzpFPHOkNODQ0v/KX0Q25w8aw4KFo f2OZRLL4cmHGfYlB9OBHmzc0Ut4As6G0+Zr/Q3TUf2X2yl6+eBb5WF6jyfq1ezD9Jau1 E6vQ== Received: by 10.14.214.133 with SMTP id c5mr89596453eep.8.1352919802292; Wed, 14 Nov 2012 11:03:22 -0800 (PST) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id o49sm31223597eep.5.2012.11.14.11.03.20 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Nov 2012 11:03:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42FFE2@xmb-aln-x03.cisco.com> Date: Wed, 14 Nov 2012 20:03:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> <8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459 FDB4EAC9EAD090C0F42FFE2@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlpOR0QiZgu/SGQtRR7mQ/rRRZNgjGWfAbtedLzdatEuQik9hOVyXoYolGi8WT7yH4OWuDe Cc: manet Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 19:03:24 -0000 Op 14 nov. 2012, om 19:31 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Nov 14, 2012, at 10:55 AM, Teco Boot wrote: >=20 >>=20 >> Op 14 nov. 2012, om 16:34 heeft Stan Ratliff (sratliff) het volgende = geschreven: >>=20 >>>=20 >>> On Nov 14, 2012, at 7:15 AM, Teco Boot wrote: >>>=20 >>>> Attempt to make thinks clear. >>>>=20 >>>> Radio is L2 device, could be 802.1D bridge or repeater. Device is=20= >>>> self learning. It has MAC addresses and probably an IP address.=20 >>>> Routers are connected to radio with ethernet or equivalent. >>>> Routers have a sub-IP connection with each other via the ethernet - = RF >>>> - ethernet sub-IP link. Connection is based on 802.1 MAC addresses. >>>> Radio has the task to deliver router originated frames to = destination, >>>> based on destination MAC address. Could be L2 multicast or = broadcast. >>>> With DLEP, radios have the task to keep track of link properties = between >>>> each connected device. Could be *any* connected ethernet NIC, as = long as=20 >>>> it has an 802.1 address and it sends a packet every now and then. = All=20 >>>> radios in the sub-IP network automatically learn the existence of = each=20 >>>> connected sending node, as required by 802.1D. DLEP shall be 100%=20= >>>> compatible with this widely deployed mechanism. It shall provide = link >>>> metrics for far end connected MAC addresses to locally connected = nodes. >>>> It shall work this way for single- and multi-hop sub-IP networks. >>>=20 >>> I think we're talking past each other. DLEP has not assumed 802.1D = support in the radios, so all of your "shall" verbiage doesn't make = sense. The only assumption DLEP makes (at least as of now) is that the = radios operate in transparent bridge mode - that the destination MAC is = that of the far-end router, not any of the intervening devices. >> As is in 802.1D. >>=20 >>> And without some flows from router *to* radio, your "one-way only" = communication mode doesn't work, because you can't correlate a router to = it's attached RF device. >> It is the RF device that is locally connected. Not the far end RF = device. Cannot be mistaken, can it? >=20 > Yes, it can. Given 3 radio/router pairs, each in the "one-way" mode, = what MAC address is in the Neighbor Up? The far end router. It doesn't need to be DLEP enabled. Could be a host = also, like a laptop for testing. BTW, I would just send the metric costs. Neighbor up is implicit. Due to = RF, signals fade away, Neighbor down is artificial (or result of a = disconnect).=20 Teco >=20 >=20 >>=20 >>> And I'm not OK with *requiring* that level of functionality in the = radio. >> I didn't read anything here that didn't match 802.1D. >>=20 >> Teco >>=20 >>=20 >>>=20 >>> Stan >>>=20 >>>=20 >>>>=20 >>>> Teco >>>>=20 >>>>=20 >>>> Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het volgende = geschreven: >>>>=20 >>>>> I mean I understand from discussions that Stan's reply to Teco = that he does not beleive to use bridge mode, >>>>>=20 >>>>> AB >>>>>=20 >>>>> On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge = wrote: >>>>> On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun >>>>> wrote: >>>>>>> Because there was no "radio-to-MAC" correlation, >>>>>>=20 >>>>>> IMO, correlation concept not understood, but understand that we = don't need >>>>>> bridge mode. However, still waiting for the respond to Teco = question, >>>>>=20 >>>>> What do you mean with "we don't need bridge mode" ? >>>>>=20 >>>>> Henning Rogge >>>>> -- >>>>> Steven Hawkings about cosmic inflation: "An increase of billions = of >>>>> billions of percent in a tiny fraction of a second. Of course, = that >>>>> was before the present government." >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >=20 From william.d.ivancic@nasa.gov Wed Nov 14 11:19:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C9A21F8819 for ; Wed, 14 Nov 2012 11:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpH5Rj-+3uaA for ; Wed, 14 Nov 2012 11:19:56 -0800 (PST) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by ietfa.amsl.com (Postfix) with ESMTP id 5160621F872D for ; Wed, 14 Nov 2012 11:19:56 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 57880D00BE; Wed, 14 Nov 2012 13:19:55 -0600 (CST) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt05.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id qAEJJtCf009764; Wed, 14 Nov 2012 13:19:55 -0600 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Wed, 14 Nov 2012 13:19:54 -0600 From: "Ivancic, William D. (GRC-RHN0)" To: "Stan Ratliff (sratliff)" Date: Wed, 14 Nov 2012 13:19:53 -0600 Thread-Topic: [manet] DLEP Lite? (Teco Boot) Thread-Index: Ac3CnQbHFUMmIirHSz+Qf3lmPZ+xUg== Message-ID: <255DB026-120C-40EF-924F-1B260E1386DA@nasa.gov> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2142BCFA1F7F0D468F8EE6C8DE719E6805B70903@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B83A@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B83A@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-14_06:2012-11-14, 2012-11-14, 1970-01-01 signatures=0 Cc: "" , "Viberg, Neil" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 19:19:57 -0000 On Nov 9, 2012, at 5:49 PM, Stan Ratliff (sratliff) wrote: > Neil, >=20 > Thanks. While it's on my mind, and just to keep the conversation going, I= think there's another assumption with ModemLPA that's confusing me - havin= g this radio link potentially multiple hops away. The assumption there is t= hat the RF link, by definition, is the bandwidth bottleneck. There's no slo= wer link between the router and the modem. Hence, traffic gated at the spee= d of the modem is the right thing to do. But, I don't think that assumption= would hold in all cases=85 Correct, the assumption would not hold in all cases. It is deployment speci= fic. - Will ps. I had to fix my email box and had not read manet for a few days, so so= rry if you were waiting for a response from me. From sratliff@cisco.com Wed Nov 14 11:26:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E3621F848B for ; Wed, 14 Nov 2012 11:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8U7LuX5C5i3v for ; Wed, 14 Nov 2012 11:26:24 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 172E621F8487 for ; Wed, 14 Nov 2012 11:26:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4432; q=dns/txt; s=iport; t=1352921184; x=1354130784; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yXDKKDWCeodwn/G2T/5OTjMPT7Gi+tqGFfYr1+4jxVk=; b=R9KlvorqhZVuoOY9gupIaAdf4UmgpCwloqSwkfHZj+Qdq2b85u3DCh4C bmISonI9ILDlJaZt4snRE49DAyesY+X9yfsAXHNUB8HCdNl9eIEsNJqY5 FxO2zYUKGdy+y9gKj0UNzpRnknrB77/7VJvmyeoIBZR2MKeZBkk1xAVaR o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAHvo1CtJXG+/2dsb2JhbABEwzuBCIIeAQEBAwEBAQEPASczAQsQAgEIGAoUECEGCyUCBA4FCBqHVgMJBgubHpYzDYlQBItEaYVLYQOUJ40HgyaBa4Jvghk X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142449394" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 14 Nov 2012 19:26:23 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAEJQNQh008658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Nov 2012 19:26:23 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 13:26:23 -0600 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] DLEP Lite? (Teco Boot) Thread-Index: Ac2+jVdl8St7CxHOQImNx8g7RjcZBAADdN/wABHqP4AAAJBkAAAANyIAACiFJoAABx7cAAAAnAOAAAkZpoAAQH5XAABOdncAAAAjnYAAAlheAAAgtueAAAb0igAAAL9VAAAFc36AAAEa+QAAAM3JgA== Date: Wed, 14 Nov 2012 19:26:22 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430211@xmb-aln-x03.cisco.com> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> <8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42FFE2@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.34.217] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19364.000 x-tm-as-result: No--39.335300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 19:26:25 -0000 On Nov 14, 2012, at 2:03 PM, Teco Boot wrote: >=20 > Op 14 nov. 2012, om 19:31 heeft Stan Ratliff (sratliff) het volgende gesc= hreven: >=20 >>=20 >> On Nov 14, 2012, at 10:55 AM, Teco Boot wrote: >>=20 >>>=20 >>> Op 14 nov. 2012, om 16:34 heeft Stan Ratliff (sratliff) het volgende ge= schreven: >>>=20 >>>>=20 >>>> On Nov 14, 2012, at 7:15 AM, Teco Boot wrote: >>>>=20 >>>>> Attempt to make thinks clear. >>>>>=20 >>>>> Radio is L2 device, could be 802.1D bridge or repeater. Device is=20 >>>>> self learning. It has MAC addresses and probably an IP address.=20 >>>>> Routers are connected to radio with ethernet or equivalent. >>>>> Routers have a sub-IP connection with each other via the ethernet - R= F >>>>> - ethernet sub-IP link. Connection is based on 802.1 MAC addresses. >>>>> Radio has the task to deliver router originated frames to destination= , >>>>> based on destination MAC address. Could be L2 multicast or broadcast. >>>>> With DLEP, radios have the task to keep track of link properties betw= een >>>>> each connected device. Could be *any* connected ethernet NIC, as long= as=20 >>>>> it has an 802.1 address and it sends a packet every now and then. All= =20 >>>>> radios in the sub-IP network automatically learn the existence of eac= h=20 >>>>> connected sending node, as required by 802.1D. DLEP shall be 100%=20 >>>>> compatible with this widely deployed mechanism. It shall provide link >>>>> metrics for far end connected MAC addresses to locally connected node= s. >>>>> It shall work this way for single- and multi-hop sub-IP networks. >>>>=20 >>>> I think we're talking past each other. DLEP has not assumed 802.1D sup= port in the radios, so all of your "shall" verbiage doesn't make sense. The= only assumption DLEP makes (at least as of now) is that the radios operate= in transparent bridge mode - that the destination MAC is that of the far-e= nd router, not any of the intervening devices. >>> As is in 802.1D. >>>=20 >>>> And without some flows from router *to* radio, your "one-way only" com= munication mode doesn't work, because you can't correlate a router to it's = attached RF device. >>> It is the RF device that is locally connected. Not the far end RF devic= e. Cannot be mistaken, can it? >>=20 >> Yes, it can. Given 3 radio/router pairs, each in the "one-way" mode, wha= t MAC address is in the Neighbor Up? >=20 > The far end router. It doesn't need to be DLEP enabled. Could be a host a= lso, like a laptop for testing. And how does the radio (far-end radio) learn of the MAC address? >=20 > BTW, I would just send the metric costs. Neighbor up is implicit. Due to = RF, signals fade away, Neighbor down is artificial (or result of a disconne= ct).=20 >=20 > Teco >=20 >>=20 >>=20 >>>=20 >>>> And I'm not OK with *requiring* that level of functionality in the rad= io. >>> I didn't read anything here that didn't match 802.1D. >>>=20 >>> Teco >>>=20 >>>=20 >>>>=20 >>>> Stan >>>>=20 >>>>=20 >>>>>=20 >>>>> Teco >>>>>=20 >>>>>=20 >>>>> Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het volgende geschr= even: >>>>>=20 >>>>>> I mean I understand from discussions that Stan's reply to Teco that = he does not beleive to use bridge mode, >>>>>>=20 >>>>>> AB >>>>>>=20 >>>>>> On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge wrote: >>>>>> On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun >>>>>> wrote: >>>>>>>> Because there was no "radio-to-MAC" correlation, >>>>>>>=20 >>>>>>> IMO, correlation concept not understood, but understand that we don= 't need >>>>>>> bridge mode. However, still waiting for the respond to Teco questio= n, >>>>>>=20 >>>>>> What do you mean with "we don't need bridge mode" ? >>>>>>=20 >>>>>> Henning Rogge >>>>>> -- >>>>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>>>> billions of percent in a tiny fraction of a second. Of course, that >>>>>> was before the present government." >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>=20 >>=20 >=20 From boberry@cisco.com Wed Nov 14 11:42:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D85321F8799 for ; Wed, 14 Nov 2012 11:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bl050Ss8JlYC for ; Wed, 14 Nov 2012 11:42:41 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5D32121F8798 for ; Wed, 14 Nov 2012 11:42:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5599; q=dns/txt; s=iport; t=1352922161; x=1354131761; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=yeItDola/zjoTfGOKWbvxGWnwFKlr+KczwC92QH8RZ4=; b=bqsKtEWWtgrce5C49bbeOZiSqu6SlG4emAJCO4SFfFVqnP3KDmVxosjn EH5J7DdI0786z5dxQET90Oj03FUrl9V+gvpGZUEjG38E0a2hBQMRycIFb Gw9MnewHQ6QV1yjTsBRPZRUOrM8Jhk8ILuYy8tCHEfSF4J/o/Dp6+Qa2J A=; X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142420373" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 14 Nov 2012 19:42:41 +0000 Received: from dhcp-64-102-54-132.cisco.com (dhcp-64-102-54-132.cisco.com [64.102.54.132]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAEJgeTk028017; Wed, 14 Nov 2012 19:42:40 GMT Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430211@xmb-aln-x03.cisco.com> Date: Wed, 14 Nov 2012 14:43:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <50FBC4FB-6677-440A-B50A-685DFDD96A46@cisco.com> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> <8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459 FDB4EAC9EAD090C0F42FFE2@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430211@xmb-aln-x03.cisco.com> To: "Stan Ratliff (sratliff)" X-Mailer: Apple Mail (2.1085) Cc: manet Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 19:43:49 -0000 On Nov 14, 2012, at 2:26 PM, Stan Ratliff (sratliff) wrote: >=20 > On Nov 14, 2012, at 2:03 PM, Teco Boot wrote: >=20 >>=20 >> Op 14 nov. 2012, om 19:31 heeft Stan Ratliff (sratliff) het volgende = geschreven: >>=20 >>>=20 >>> On Nov 14, 2012, at 10:55 AM, Teco Boot wrote: >>>=20 >>>>=20 >>>> Op 14 nov. 2012, om 16:34 heeft Stan Ratliff (sratliff) het = volgende geschreven: >>>>=20 >>>>>=20 >>>>> On Nov 14, 2012, at 7:15 AM, Teco Boot wrote: >>>>>=20 >>>>>> Attempt to make thinks clear. >>>>>>=20 >>>>>> Radio is L2 device, could be 802.1D bridge or repeater. Device is=20= >>>>>> self learning. It has MAC addresses and probably an IP address.=20= >>>>>> Routers are connected to radio with ethernet or equivalent. >>>>>> Routers have a sub-IP connection with each other via the ethernet = - RF >>>>>> - ethernet sub-IP link. Connection is based on 802.1 MAC = addresses. >>>>>> Radio has the task to deliver router originated frames to = destination, >>>>>> based on destination MAC address. Could be L2 multicast or = broadcast. >>>>>> With DLEP, radios have the task to keep track of link properties = between >>>>>> each connected device. Could be *any* connected ethernet NIC, as = long as=20 >>>>>> it has an 802.1 address and it sends a packet every now and then. = All=20 >>>>>> radios in the sub-IP network automatically learn the existence of = each=20 >>>>>> connected sending node, as required by 802.1D. DLEP shall be 100%=20= >>>>>> compatible with this widely deployed mechanism. It shall provide = link >>>>>> metrics for far end connected MAC addresses to locally connected = nodes. >>>>>> It shall work this way for single- and multi-hop sub-IP networks. >>>>>=20 >>>>> I think we're talking past each other. DLEP has not assumed 802.1D = support in the radios, so all of your "shall" verbiage doesn't make = sense. The only assumption DLEP makes (at least as of now) is that the = radios operate in transparent bridge mode - that the destination MAC is = that of the far-end router, not any of the intervening devices. >>>> As is in 802.1D. >>>>=20 >>>>> And without some flows from router *to* radio, your "one-way only" = communication mode doesn't work, because you can't correlate a router to = it's attached RF device. >>>> It is the RF device that is locally connected. Not the far end RF = device. Cannot be mistaken, can it? >>>=20 >>> Yes, it can. Given 3 radio/router pairs, each in the "one-way" mode, = what MAC address is in the Neighbor Up? >>=20 >> The far end router. It doesn't need to be DLEP enabled. Could be a = host also, like a laptop for testing. >=20 > And how does the radio (far-end radio) learn of the MAC address? A picture my help (me for atleast as I try to follow). Two different = networks below. A) [ DLEP Enabled] [ DLEP Enabled] [ radio~router]~~~~~~~[ radio|router]=20 B) [ DLEP Enabled] [ integrated] [ radio~router]~~~~~~~[ radio|host] The [integrated radio|host] shares MAC/IP address information via a = driver, not DLEP. In configuration (B) the DLEP Enabled radio must = obtain the host MAC address to drive DLEP. How the DLEP Enabled radio = obtains the host MAC is really a function of the DLEP Enabled radio. = Once obtained, the DLEP Enabled radio generates a Neighbor Up and can = report metrics associated with the host MAC. The DLEP Enabled router = uses the host MAC in the DLEP messages to adjust/influence routing.=20 >=20 >=20 >>=20 >> BTW, I would just send the metric costs. Neighbor up is implicit. Due = to RF, signals fade away, Neighbor down is artificial (or result of a = disconnect).=20 >>=20 >> Teco >>=20 >>>=20 >>>=20 >>>>=20 >>>>> And I'm not OK with *requiring* that level of functionality in the = radio. >>>> I didn't read anything here that didn't match 802.1D. >>>>=20 >>>> Teco >>>>=20 >>>>=20 >>>>>=20 >>>>> Stan >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Teco >>>>>>=20 >>>>>>=20 >>>>>> Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het volgende = geschreven: >>>>>>=20 >>>>>>> I mean I understand from discussions that Stan's reply to Teco = that he does not beleive to use bridge mode, >>>>>>>=20 >>>>>>> AB >>>>>>>=20 >>>>>>> On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge = wrote: >>>>>>> On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun >>>>>>> wrote: >>>>>>>>> Because there was no "radio-to-MAC" correlation, >>>>>>>>=20 >>>>>>>> IMO, correlation concept not understood, but understand that we = don't need >>>>>>>> bridge mode. However, still waiting for the respond to Teco = question, >>>>>>>=20 >>>>>>> What do you mean with "we don't need bridge mode" ? >>>>>>>=20 >>>>>>> Henning Rogge >>>>>>> -- >>>>>>> Steven Hawkings about cosmic inflation: "An increase of billions = of >>>>>>> billions of percent in a tiny fraction of a second. Of course, = that >>>>>>> was before the present government." >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Wed Nov 14 22:29:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E125F21F87A0 for ; Wed, 14 Nov 2012 22:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njaUalhzpRa0 for ; Wed, 14 Nov 2012 22:29:57 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6E621F8793 for ; Wed, 14 Nov 2012 22:29:55 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so559368bku.31 for ; Wed, 14 Nov 2012 22:29:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Mmh4eh+NoPtfQBY9kSS1ufAOnyAbf+FvNheMLzuAr5Q=; b=DNSaFPECgNMlj1XwKAjwJEAfdUFouQJLr+xyk/FN7hP0E+6WR9sGYO3CVf5C9JC+JW RPjw04cFe0BsqUSgdrAS5que2w6oguUwDngXl8RwFCQpmynmLUhu9E+S+kdrZUKHUIoH kKuFIEANJO2sKGtF14YRggZglL9Q8CbM1z49pOnCcJ+4ex0nosqKqJlDCJDljt2AbOtT AJNFWsdDckAzcYJI0FIn10KAq4dokQ2eFZDqgyo+nXqQa+dHAjdrYwrEs3kDR2eFC6CQ 9678a/mJk/0SGZUFP5lZsqOEaXQNUWbvo13+a5DYaT2FHZf8GagT//LCA8KFu4zHEqpF 9Tow== Received: by 10.204.7.136 with SMTP id d8mr24779bkd.85.1352960994611; Wed, 14 Nov 2012 22:29:54 -0800 (PST) Received: from [10.87.17.167] ([80.187.201.33]) by mx.google.com with ESMTPS id n27sm9251592bkw.0.2012.11.14.22.29.49 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 22:29:53 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <50FBC4FB-6677-440A-B50A-685DFDD96A46@cisco.com> Date: Thu, 15 Nov 2012 07:29:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> <8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459 FDB4EAC9EAD090C0F42FFE2@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430211@xmb-aln-x03.cisco.com> <50FBC4FB-6677-440A-B50A-685DFDD96A46@cisco.com> To: Bo Berry X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQna1PpesiUgMV92CuI4erktghC9QUA6iar/cn5tKa5ocrg3mGl/C/cYUb0TmnlcjfOegWmI Cc: manet , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 06:29:58 -0000 Op 14 nov. 2012, om 20:43 heeft Bo Berry het volgende geschreven: >=20 > On Nov 14, 2012, at 2:26 PM, Stan Ratliff (sratliff) wrote: >=20 >>=20 >> On Nov 14, 2012, at 2:03 PM, Teco Boot wrote: >>=20 >>>=20 >>> Op 14 nov. 2012, om 19:31 heeft Stan Ratliff (sratliff) het volgende = geschreven: >>>=20 >>>>=20 >>>> On Nov 14, 2012, at 10:55 AM, Teco Boot wrote: >>>>=20 >>>>>=20 >>>>> Op 14 nov. 2012, om 16:34 heeft Stan Ratliff (sratliff) het = volgende geschreven: >>>>>=20 >>>>>>=20 >>>>>> On Nov 14, 2012, at 7:15 AM, Teco Boot wrote: >>>>>>=20 >>>>>>> Attempt to make thinks clear. >>>>>>>=20 >>>>>>> Radio is L2 device, could be 802.1D bridge or repeater. Device = is=20 >>>>>>> self learning. It has MAC addresses and probably an IP address.=20= >>>>>>> Routers are connected to radio with ethernet or equivalent. >>>>>>> Routers have a sub-IP connection with each other via the = ethernet - RF >>>>>>> - ethernet sub-IP link. Connection is based on 802.1 MAC = addresses. >>>>>>> Radio has the task to deliver router originated frames to = destination, >>>>>>> based on destination MAC address. Could be L2 multicast or = broadcast. >>>>>>> With DLEP, radios have the task to keep track of link properties = between >>>>>>> each connected device. Could be *any* connected ethernet NIC, as = long as=20 >>>>>>> it has an 802.1 address and it sends a packet every now and = then. All=20 >>>>>>> radios in the sub-IP network automatically learn the existence = of each=20 >>>>>>> connected sending node, as required by 802.1D. DLEP shall be = 100%=20 >>>>>>> compatible with this widely deployed mechanism. It shall provide = link >>>>>>> metrics for far end connected MAC addresses to locally connected = nodes. >>>>>>> It shall work this way for single- and multi-hop sub-IP = networks. >>>>>>=20 >>>>>> I think we're talking past each other. DLEP has not assumed = 802.1D support in the radios, so all of your "shall" verbiage doesn't = make sense. The only assumption DLEP makes (at least as of now) is that = the radios operate in transparent bridge mode - that the destination MAC = is that of the far-end router, not any of the intervening devices. >>>>> As is in 802.1D. >>>>>=20 >>>>>> And without some flows from router *to* radio, your "one-way = only" communication mode doesn't work, because you can't correlate a = router to it's attached RF device. >>>>> It is the RF device that is locally connected. Not the far end RF = device. Cannot be mistaken, can it? >>>>=20 >>>> Yes, it can. Given 3 radio/router pairs, each in the "one-way" = mode, what MAC address is in the Neighbor Up? >>>=20 >>> The far end router. It doesn't need to be DLEP enabled. Could be a = host also, like a laptop for testing. >>=20 >> And how does the radio (far-end radio) learn of the MAC address? @Stan: Assume frames have 4 MAC addresses: SA, DA, TA and RA. SA: Source Address, sending router DA: Destination Address, receiving router (far end radio sends frame to = locally attached router) TA: Transmitter Address, radio ID of RF link, sending radio RA: Receiver Address, radio ID on RF link, receiving radio I am aware of radio's that reuse the SA/DA for TA/RA, so they do not = need the 4-address mode. This has some limitations, in that radio = supports only one node (although there could be a work-around). The more = enhanced radios use the 4 address mode. Now your question: radio inspects the frame header, to find out what to = do with it. Highly simplified: Is RA its own address? No, then discard. = It could update link metrics for TA and all SA behind TA, no reason to = ignore available info. For frames for that radio, it refresh forwarding = tables: SA is behind TA, this info is required for return frames. Frame = is converted or decapsulated and forwarded to DA, could be flooding if = unknown outgoing port was unknown. Side node: when RA !=3D own address, radio could update bridge = forwarding table, and relate SA and TA. >=20 >=20 > A picture my help (me for atleast as I try to follow). Two different = networks below. >=20 > A) > [ DLEP Enabled] [ DLEP Enabled] > [ radio~router]~~~~~~~[ radio|router]=20 >=20 > B) > [ DLEP Enabled] [ integrated] > [ radio~router]~~~~~~~[ radio|host] There are more scenario's: C) [ DLEP Enabled] [ DLEP Disabled] [ radio~router]~~~~~~~[ radio|router ]=20 D) [ DLEP Enabled] [ DLEP Enabled] [ integrated] [ radio~router]~~~~~~~[ radio|host] All should work. >=20 > The [integrated radio|host] shares MAC/IP address information via a = driver, not DLEP. What is "shares MAC/IP address"? With 4 address mode, SA and TA would be same MAC address. > In configuration (B) the DLEP Enabled radio must obtain the host MAC = address to drive DLEP. How the DLEP Enabled radio obtains the host MAC = is really a function of the DLEP Enabled radio. Once obtained, the DLEP = Enabled radio generates a Neighbor Up and can report metrics associated = with the host MAC. The DLEP Enabled router uses the host MAC in the = DLEP messages to adjust/influence routing.=20 Agreed in that the DLEP specification shall not assume both sides of = link have DLEP enabled, such as with (B) and (C)?=20 Teco >=20 >=20 >=20 >>=20 >>=20 >>>=20 >>> BTW, I would just send the metric costs. Neighbor up is implicit. = Due to RF, signals fade away, Neighbor down is artificial (or result of = a disconnect).=20 >>>=20 >>> Teco >>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>>> And I'm not OK with *requiring* that level of functionality in = the radio. >>>>> I didn't read anything here that didn't match 802.1D. >>>>>=20 >>>>> Teco >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Stan >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Teco >>>>>>>=20 >>>>>>>=20 >>>>>>> Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het volgende = geschreven: >>>>>>>=20 >>>>>>>> I mean I understand from discussions that Stan's reply to Teco = that he does not beleive to use bridge mode, >>>>>>>>=20 >>>>>>>> AB >>>>>>>>=20 >>>>>>>> On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge = wrote: >>>>>>>> On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun >>>>>>>> wrote: >>>>>>>>>> Because there was no "radio-to-MAC" correlation, >>>>>>>>>=20 >>>>>>>>> IMO, correlation concept not understood, but understand that = we don't need >>>>>>>>> bridge mode. However, still waiting for the respond to Teco = question, >>>>>>>>=20 >>>>>>>> What do you mean with "we don't need bridge mode" ? >>>>>>>>=20 >>>>>>>> Henning Rogge >>>>>>>> -- >>>>>>>> Steven Hawkings about cosmic inflation: "An increase of = billions of >>>>>>>> billions of percent in a tiny fraction of a second. Of course, = that >>>>>>>> was before the present government." >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> manet mailing list >>>>>>>> manet@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From abdussalambaryun@gmail.com Thu Nov 15 04:56:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F5B21F88D1 for ; Thu, 15 Nov 2012 04:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.48 X-Spam-Level: X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh0Advh3C26Q for ; Thu, 15 Nov 2012 04:56:20 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F3E3B21F88CB for ; Thu, 15 Nov 2012 04:56:19 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so1771701vcb.31 for ; Thu, 15 Nov 2012 04:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7Z3gb5c3xcgaucdjXC6U2QqA3ZOxprhuPJ1ZDixrFCM=; b=Ji/Mm3g82KGctD2k/OxP7LH+VKe52BOfQV4vz3HK4OhYuLx9lus92C8YIEoxHb5FB3 h3TQHoPRltcwZQbEEvpjgeA84rATrUJTIdXvsrEJiBmhlTOFlCdcF3HYvaRUJePQIcBd wP2Q6O04rVpzmaTi6l4vK43i03X/BaQRj0vjO0tXSZ+01x0jRptvLYymKWWaoNs9YPKg V5n44JW/NsR+Riq99Eza8KChFGApYUHNlkVPzOkaRnS45k1b21X0AtTXJSQDloubBnKo CHzm0qip41qrlBNBjfoTGx/D0gpfvV877DSusud78QE5y/FlbGW3kcXkssy5oaZjaAqQ K6Iw== MIME-Version: 1.0 Received: by 10.52.35.82 with SMTP id f18mr986587vdj.99.1352984179395; Thu, 15 Nov 2012 04:56:19 -0800 (PST) Received: by 10.220.204.9 with HTTP; Thu, 15 Nov 2012 04:56:19 -0800 (PST) In-Reply-To: <50FBC4FB-6677-440A-B50A-685DFDD96A46@cisco.com> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> <8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430211@xmb-aln-x03.cisco.com> <50FBC4FB-6677-440A-B50A-685DFDD96A46@cisco.com> Date: Thu, 15 Nov 2012 13:56:19 +0100 Message-ID: From: Abdussalam Baryun To: Bo Berry Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 12:56:20 -0000 On 11/14/12, Bo Berry wrote: > > A picture my help (me for atleast as I try to follow). Two different > networks below. > > A) > [ DLEP Enabled] [ DLEP Enabled] > [ radio~router]~~~~~~~[ radio|router] > > B) > [ DLEP Enabled] [ integrated] > [ radio~router]~~~~~~~[ radio|host] > What kind of host reporting? I thought we in DLEP are focused to reporting about routers' links, but now undertanding that some are interested in reporting about hosts' links also. > The [integrated radio|host] shares MAC/IP address information via a driver, > not DLEP. In configuration (B) the DLEP Enabled radio must obtain the host > MAC address to drive DLEP. How the DLEP Enabled radio obtains the host MAC > is really a function of the DLEP Enabled radio. Once obtained, the DLEP > Enabled radio generates a Neighbor Up and can report metrics associated with > the host MAC. The DLEP Enabled router uses the host MAC in the DLEP > messages to adjust/influence routing. > IMO, the host MAC and/or router MAC should be specified only for *enabled DLEP*, if we considering non-enabled DLEP devices, the DLEP exchange function may become complicated. AB From abdussalambaryun@gmail.com Thu Nov 15 05:03:28 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D3A21F88D4 for ; Thu, 15 Nov 2012 05:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.183 X-Spam-Level: X-Spam-Status: No, score=-3.183 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jmfy2mPZpIbm for ; Thu, 15 Nov 2012 05:03:27 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 62FAC21F88E1 for ; Thu, 15 Nov 2012 05:03:27 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so1759087vbb.31 for ; Thu, 15 Nov 2012 05:03:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sy5eHTN0qIU40ofGbLLw+IsEK17I98ZlDzgu9JAa1yg=; b=y2MIvgfTWy8DMbVwEmlodwFWPzUBBX+hlMe9PvpaSdbuk+XsJHcu96F0fDdfsP2LDA SZBizSfOuqtpcEVENcS7qgD93sOVWzocen3mINoyiAS89ZaDNkH7BQnhCqNqu44B50vh vNjncVDyvmG/wb4stfNg//YZ1wsfMem+i/c2glgTD9KXecBDTs5ZNykwQtsnTPp3uLd4 iJfLZrRIFzStKB8WBpfoWLfa32naxwvVXAx476Nh7qrmG19d4+x88w7K/z7BZU1L/il+ sLV3VVUtz9XNSQjejNCGvBRJCiGsUwfxk7G6FU7BTVRA2u6QtsR5bLm09uFGS6QcQBHl LSlA== MIME-Version: 1.0 Received: by 10.220.16.12 with SMTP id m12mr1238642vca.14.1352984606079; Thu, 15 Nov 2012 05:03:26 -0800 (PST) Received: by 10.220.204.9 with HTTP; Thu, 15 Nov 2012 05:03:25 -0800 (PST) In-Reply-To: References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> <8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430211@xmb-aln-x03.cisco.com> <50FBC4FB-6677-440A-B50A-685DFDD96A46@cisco.com> Date: Thu, 15 Nov 2012 14:03:25 +0100 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , Bo Berry , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 13:03:28 -0000 > @Stan: > Assume frames have 4 MAC addresses: SA, DA, TA and RA. > SA: Source Address, sending router > DA: Destination Address, receiving router (far end radio sends frame to > locally attached router) > TA: Transmitter Address, radio ID of RF link, sending radio > RA: Receiver Address, radio ID on RF link, receiving radio ok, so the MAC address of sources and destinations are ROUTERs not HOSTs, I agree to fix the DLEP exchange function with reporting to/about routers. > There are more scenario's: > > C) > [ DLEP Enabled] [ DLEP Disabled] > [ radio~router]~~~~~~~[ radio|router ] > > D) > [ DLEP Enabled] > [ DLEP Enabled] [ integrated] > [ radio~router]~~~~~~~[ radio|host] > > All should work. Do you mean should work within DLEP, so you mean that DLEP should consider devices that don't enable its functions? Why you think the C and D scenarios are within DLEP scope? AB From teco@inf-net.nl Thu Nov 15 05:28:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B10C21F88C9 for ; Thu, 15 Nov 2012 05:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfnLNCTIjwbJ for ; Thu, 15 Nov 2012 05:28:12 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 61ABC21F88D4 for ; Thu, 15 Nov 2012 05:28:12 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so774273bku.31 for ; Thu, 15 Nov 2012 05:28:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=pMv5Tyn3Ymmm+nKQNUfTL+etHKKrAkCgVZuH3ccRdQs=; b=UfHg6MSKBU227n+a2knq+g78nfnKzRKfhdWOF3LhpxkJjdxNzBny7UD465xGxdJHmv +6YK7I0bYgzs5uSs1hEYtNG1JDeaC/5PXpr4NBSiyRCVAzXB+RdIhe4G8RD7IUBpLbdW Xs4akDkr3VkmmhJmeFSdZLyDIxHR+HchS4S0a1S0Ex4XLf5KIoVnlfspWNXcgFHQymVo Xh2Gvipb5daJ5Nmiz2aD6PioSzZlVRnLv9V08mS/NWQkE4oZ6HdVp68vOeCtqK3TG5ZK 3RpiofkZyU9EoZwlyCwH0AUI9FP5Ju2F7avDdNYRy5iW6SKq+1qpBBluqDxypPmr6JHQ 9yLg== Received: by 10.204.9.139 with SMTP id l11mr378198bkl.133.1352986091342; Thu, 15 Nov 2012 05:28:11 -0800 (PST) Received: from [172.16.4.186] ([188.205.88.52]) by mx.google.com with ESMTPS id n27sm10229040bkw.0.2012.11.15.05.28.09 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 05:28:10 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Thu, 15 Nov 2012 14:28:08 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> <8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430211@xmb-aln-x03.cisco.com> <50FBC4FB-6677-440A-B50A-685DFDD96A46@cisco.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnzTPKZVw/taRkHKXkHA+Ar2pIJNJrHohebbHPdUSyVCUcYJ6ZzNXE4uMHYDnRKCa3pAAsU Cc: manet , Bo Berry , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 13:28:13 -0000 Op 15 nov. 2012, om 14:03 heeft Abdussalam Baryun het volgende geschreven: >> @Stan: >> Assume frames have 4 MAC addresses: SA, DA, TA and RA. >> SA: Source Address, sending router >> DA: Destination Address, receiving router (far end radio sends frame to >> locally attached router) >> TA: Transmitter Address, radio ID of RF link, sending radio >> RA: Receiver Address, radio ID on RF link, receiving radio > > ok, so the MAC address of sources and destinations are ROUTERs not > HOSTs, I agree to fix the DLEP exchange function with reporting > to/about routers. I don't see a reason why the radio connected devices MUST be routers. They typically are. Can be hosts also. > >> There are more scenario's: >> >> C) >> [ DLEP Enabled] [ DLEP Disabled] >> [ radio~router]~~~~~~~[ radio|router ] >> >> D) >> [ DLEP Enabled] >> [ DLEP Enabled] [ integrated] >> [ radio~router]~~~~~~~[ radio|host] >> >> All should work. > > Do you mean should work within DLEP, so you mean that DLEP should > consider devices that don't enable its functions? With C (probably B), DLEP functions could be limited, as there would be no exchange of link metrics between radio's. DLEP doesn't specify how radios interact, that is why it is a should, not a must. > Why you think the C > and D scenarios are within DLEP scope? Sure. Teco > > AB From sratliff@cisco.com Thu Nov 15 06:55:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D337921F893B for ; Thu, 15 Nov 2012 06:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCHtFngGGZnq for ; Thu, 15 Nov 2012 06:55:08 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB6D21F84C4 for ; Thu, 15 Nov 2012 06:55:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7966; q=dns/txt; s=iport; t=1352991308; x=1354200908; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cDvdCDx7oPWGIQnKrDdspdjw+06wVKTOtGoc5K+qE2k=; b=dEOTYU0Ex/m7Bqk6Xi/oeDNCb2W0gKsn0pSB1cgjmMFLihP3u3hZZjmn iHyM/QmWRIyao0fu3rh6YP5bboRcbT+ECj7e7lRgZeAZZOUtIbirRXEw8 KEe7jR4bh/9jVeV93UGTLzXuLv1zEtArhwngbrbDIoR3m1yJRl/uQqegc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAE4BpVCtJV2b/2dsb2JhbABEw0mBCIIeAQEBAwEBAQEPASczAQsQAgEIGAoUECEGCyUCBA4FCBqHVwMJBgucVpYlDYlQBItIaYVLYQOUJ40HgyaBa4Jvghk X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142757208" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 15 Nov 2012 14:55:07 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAFEt7NF026647 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Nov 2012 14:55:07 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 08:55:07 -0600 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] DLEP Lite? (Teco Boot) Thread-Index: Ac2+jVdl8St7CxHOQImNx8g7RjcZBAADdN/wABHqP4AAAJBkAAAANyIAACiFJoAABx7cAAAAnAOAAAkZpoAAQH5XAABOdncAAAAjnYAAAlheAAAgtueAAAb0igAAAL9VAAAFc36AAAEa+QAAAM3JgAAAl7KAABaSq4AAEaeGgA== Date: Thu, 15 Nov 2012 14:55:06 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430886@xmb-aln-x03.cisco.com> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> <8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42FFE2@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430211@xmb-aln-x03.cisco.com> <50FBC4FB-6677-440A-B50A-685DFDD96A46@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.100] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19368.001 x-tm-as-result: No--45.384400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <9EA3F6DB64C7A94C86C9AEAF46250EE6@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , "Bo Berry \(boberry\)" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 14:55:10 -0000 On Nov 15, 2012, at 1:29 AM, Teco Boot wrote: >=20 > Op 14 nov. 2012, om 20:43 heeft Bo Berry het volgende geschreven: >=20 >>=20 >> On Nov 14, 2012, at 2:26 PM, Stan Ratliff (sratliff) wrote: >>=20 >>>=20 >>> On Nov 14, 2012, at 2:03 PM, Teco Boot wrote: >>>=20 >>>>=20 >>>> Op 14 nov. 2012, om 19:31 heeft Stan Ratliff (sratliff) het volgende g= eschreven: >>>>=20 >>>>>=20 >>>>> On Nov 14, 2012, at 10:55 AM, Teco Boot wrote: >>>>>=20 >>>>>>=20 >>>>>> Op 14 nov. 2012, om 16:34 heeft Stan Ratliff (sratliff) het volgende= geschreven: >>>>>>=20 >>>>>>>=20 >>>>>>> On Nov 14, 2012, at 7:15 AM, Teco Boot wrote: >>>>>>>=20 >>>>>>>> Attempt to make thinks clear. >>>>>>>>=20 >>>>>>>> Radio is L2 device, could be 802.1D bridge or repeater. Device is= =20 >>>>>>>> self learning. It has MAC addresses and probably an IP address.=20 >>>>>>>> Routers are connected to radio with ethernet or equivalent. >>>>>>>> Routers have a sub-IP connection with each other via the ethernet = - RF >>>>>>>> - ethernet sub-IP link. Connection is based on 802.1 MAC addresses= . >>>>>>>> Radio has the task to deliver router originated frames to destinat= ion, >>>>>>>> based on destination MAC address. Could be L2 multicast or broadca= st. >>>>>>>> With DLEP, radios have the task to keep track of link properties b= etween >>>>>>>> each connected device. Could be *any* connected ethernet NIC, as l= ong as=20 >>>>>>>> it has an 802.1 address and it sends a packet every now and then. = All=20 >>>>>>>> radios in the sub-IP network automatically learn the existence of = each=20 >>>>>>>> connected sending node, as required by 802.1D. DLEP shall be 100%= =20 >>>>>>>> compatible with this widely deployed mechanism. It shall provide l= ink >>>>>>>> metrics for far end connected MAC addresses to locally connected n= odes. >>>>>>>> It shall work this way for single- and multi-hop sub-IP networks. >>>>>>>=20 >>>>>>> I think we're talking past each other. DLEP has not assumed 802.1D = support in the radios, so all of your "shall" verbiage doesn't make sense. = The only assumption DLEP makes (at least as of now) is that the radios oper= ate in transparent bridge mode - that the destination MAC is that of the fa= r-end router, not any of the intervening devices. >>>>>> As is in 802.1D. >>>>>>=20 >>>>>>> And without some flows from router *to* radio, your "one-way only" = communication mode doesn't work, because you can't correlate a router to it= 's attached RF device. >>>>>> It is the RF device that is locally connected. Not the far end RF de= vice. Cannot be mistaken, can it? >>>>>=20 >>>>> Yes, it can. Given 3 radio/router pairs, each in the "one-way" mode, = what MAC address is in the Neighbor Up? >>>>=20 >>>> The far end router. It doesn't need to be DLEP enabled. Could be a hos= t also, like a laptop for testing. >>>=20 >>> And how does the radio (far-end radio) learn of the MAC address? >=20 > @Stan: > Assume frames have 4 MAC addresses: SA, DA, TA and RA. > SA: Source Address, sending router > DA: Destination Address, receiving router (far end radio sends frame to l= ocally attached router) > TA: Transmitter Address, radio ID of RF link, sending radio > RA: Receiver Address, radio ID on RF link, receiving radio >=20 > I am aware of radio's that reuse the SA/DA for TA/RA, so they do not need= the 4-address mode. This has some limitations, in that radio supports only= one node (although there could be a work-around). The more enhanced radios= use the 4 address mode. >=20 > Now your question: radio inspects the frame header, to find out what to d= o with it. Highly simplified: Is RA its own address? No, then discard. It c= ould update link metrics for TA and all SA behind TA, no reason to ignore a= vailable info. For frames for that radio, it refresh forwarding tables: SA = is behind TA, this info is required for return frames. Frame is converted o= r decapsulated and forwarded to DA, could be flooding if unknown outgoing p= ort was unknown. >=20 > Side node: when RA !=3D own address, radio could update bridge forwarding= table, and relate SA and TA. And if the router, for whatever reason or reasons might be appropriate, sim= ply hasn't emitted any frames toward the radio? >=20 >>=20 >>=20 >> A picture my help (me for atleast as I try to follow). Two different ne= tworks below. >>=20 >> A) >> [ DLEP Enabled] [ DLEP Enabled] >> [ radio~router]~~~~~~~[ radio|router]=20 >>=20 >> B) >> [ DLEP Enabled] [ integrated] >> [ radio~router]~~~~~~~[ radio|host] >=20 > There are more scenario's: >=20 > C) > [ DLEP Enabled] [ DLEP Disabled] > [ radio~router]~~~~~~~[ radio|router ]=20 >=20 > D) > [ DLEP Enabled] > [ DLEP Enabled] [ integrated] > [ radio~router]~~~~~~~[ radio|host] >=20 > All should work. >=20 >>=20 >> The [integrated radio|host] shares MAC/IP address information via a driv= er, not DLEP. > What is "shares MAC/IP address"? > With 4 address mode, SA and TA would be same MAC address. >=20 >> In configuration (B) the DLEP Enabled radio must obtain the host MAC add= ress to drive DLEP. How the DLEP Enabled radio obtains the host MAC is rea= lly a function of the DLEP Enabled radio. Once obtained, the DLEP Enabled = radio generates a Neighbor Up and can report metrics associated with the ho= st MAC. The DLEP Enabled router uses the host MAC in the DLEP messages to = adjust/influence routing.=20 >=20 > Agreed in that the DLEP specification shall not assume both sides of link= have DLEP enabled, such as with (B) and (C)?=20 >=20 > Teco >=20 >>=20 >>=20 >>=20 >>>=20 >>>=20 >>>>=20 >>>> BTW, I would just send the metric costs. Neighbor up is implicit. Due = to RF, signals fade away, Neighbor down is artificial (or result of a disco= nnect).=20 >>>>=20 >>>> Teco >>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>>> And I'm not OK with *requiring* that level of functionality in the = radio. >>>>>> I didn't read anything here that didn't match 802.1D. >>>>>>=20 >>>>>> Teco >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Stan >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Teco >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het volgende ges= chreven: >>>>>>>>=20 >>>>>>>>> I mean I understand from discussions that Stan's reply to Teco th= at he does not beleive to use bridge mode, >>>>>>>>>=20 >>>>>>>>> AB >>>>>>>>>=20 >>>>>>>>> On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge wrote: >>>>>>>>> On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun >>>>>>>>> wrote: >>>>>>>>>>> Because there was no "radio-to-MAC" correlation, >>>>>>>>>>=20 >>>>>>>>>> IMO, correlation concept not understood, but understand that we = don't need >>>>>>>>>> bridge mode. However, still waiting for the respond to Teco ques= tion, >>>>>>>>>=20 >>>>>>>>> What do you mean with "we don't need bridge mode" ? >>>>>>>>>=20 >>>>>>>>> Henning Rogge >>>>>>>>> -- >>>>>>>>> Steven Hawkings about cosmic inflation: "An increase of billions = of >>>>>>>>> billions of percent in a tiny fraction of a second. Of course, th= at >>>>>>>>> was before the present government." >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> manet mailing list >>>>>>>>> manet@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> manet mailing list >>>>>>>> manet@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 From teco@inf-net.nl Thu Nov 15 08:02:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5380B21F88EA for ; Thu, 15 Nov 2012 08:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4XOHZ6zmeAd for ; Thu, 15 Nov 2012 08:02:51 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC00621F844E for ; Thu, 15 Nov 2012 08:02:50 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so868796bku.31 for ; Thu, 15 Nov 2012 08:02:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=uqA7hd29swB5GrN5SpvyrLMs5ra+Y3+efz9q4SCQ3/Q=; b=bOpAGIE823YxT3XFR45q/nxN2nIUcx484ovsKkREnOovsLnm7sLOaDi+XyJnYEXjXl 8j1GAYtAwsFKO96HAdmXLq99Dx6xhiZ990O3dlyUZGo84JNpgTUEF3+1PBxs/puJNGlw 2ro2AKJp9FfitpKMuz/xOOjJf14A0D8slMFIw9vJRFwxsH2hIVAOqGIFCynBvfkuFEHj 0fnWE7J1y7fZ5ErCq6GQbAqo4vw7PAFpO2hmxO2/WnXLOrVGhfenNNcNgdHcj17dG8ol dy8d69QngpQXarpxrZ58k8d2ZKtroKn1HGjDfgx5C60yuuPBuCk4/JPWE8RPQv+FTz7e epvA== Received: by 10.204.13.28 with SMTP id z28mr602925bkz.113.1352995369558; Thu, 15 Nov 2012 08:02:49 -0800 (PST) Received: from [172.20.10.3] ([84.241.201.240]) by mx.google.com with ESMTPS id u3sm4230571bkw.9.2012.11.15.08.02.32 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 08:02:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430886@xmb-aln-x03.cisco.com> Date: Thu, 15 Nov 2012 16:42:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> <8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459 FDB4EAC9EAD090C0F42FFE2@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430211@xmb-aln-x03.cisco.com> <50FBC4FB-6677-440A-B50A-685DFDD96A46@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430886@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkvJHufWe9Ih1KhuHitJ6S6pU9gajUMl2PdBLoak2U4hCTWwbbk+aJIkzSg9LhyTbMtBNVY Cc: manet , "Bo Berry \(boberry\)" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 16:02:52 -0000 Op 15 nov. 2012, om 15:55 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Nov 15, 2012, at 1:29 AM, Teco Boot wrote: >=20 >>=20 >> Op 14 nov. 2012, om 20:43 heeft Bo Berry het volgende geschreven: >>=20 >>>=20 >>> On Nov 14, 2012, at 2:26 PM, Stan Ratliff (sratliff) wrote: >>>=20 >>>>=20 >>>> On Nov 14, 2012, at 2:03 PM, Teco Boot wrote: >>>>=20 >>>>>=20 >>>>> Op 14 nov. 2012, om 19:31 heeft Stan Ratliff (sratliff) het = volgende geschreven: >>>>>=20 >>>>>>=20 >>>>>> On Nov 14, 2012, at 10:55 AM, Teco Boot wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> Op 14 nov. 2012, om 16:34 heeft Stan Ratliff (sratliff) het = volgende geschreven: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Nov 14, 2012, at 7:15 AM, Teco Boot wrote: >>>>>>>>=20 >>>>>>>>> Attempt to make thinks clear. >>>>>>>>>=20 >>>>>>>>> Radio is L2 device, could be 802.1D bridge or repeater. Device = is=20 >>>>>>>>> self learning. It has MAC addresses and probably an IP = address.=20 >>>>>>>>> Routers are connected to radio with ethernet or equivalent. >>>>>>>>> Routers have a sub-IP connection with each other via the = ethernet - RF >>>>>>>>> - ethernet sub-IP link. Connection is based on 802.1 MAC = addresses. >>>>>>>>> Radio has the task to deliver router originated frames to = destination, >>>>>>>>> based on destination MAC address. Could be L2 multicast or = broadcast. >>>>>>>>> With DLEP, radios have the task to keep track of link = properties between >>>>>>>>> each connected device. Could be *any* connected ethernet NIC, = as long as=20 >>>>>>>>> it has an 802.1 address and it sends a packet every now and = then. All=20 >>>>>>>>> radios in the sub-IP network automatically learn the existence = of each=20 >>>>>>>>> connected sending node, as required by 802.1D. DLEP shall be = 100%=20 >>>>>>>>> compatible with this widely deployed mechanism. It shall = provide link >>>>>>>>> metrics for far end connected MAC addresses to locally = connected nodes. >>>>>>>>> It shall work this way for single- and multi-hop sub-IP = networks. >>>>>>>>=20 >>>>>>>> I think we're talking past each other. DLEP has not assumed = 802.1D support in the radios, so all of your "shall" verbiage doesn't = make sense. The only assumption DLEP makes (at least as of now) is that = the radios operate in transparent bridge mode - that the destination MAC = is that of the far-end router, not any of the intervening devices. >>>>>>> As is in 802.1D. >>>>>>>=20 >>>>>>>> And without some flows from router *to* radio, your "one-way = only" communication mode doesn't work, because you can't correlate a = router to it's attached RF device. >>>>>>> It is the RF device that is locally connected. Not the far end = RF device. Cannot be mistaken, can it? >>>>>>=20 >>>>>> Yes, it can. Given 3 radio/router pairs, each in the "one-way" = mode, what MAC address is in the Neighbor Up? >>>>>=20 >>>>> The far end router. It doesn't need to be DLEP enabled. Could be a = host also, like a laptop for testing. >>>>=20 >>>> And how does the radio (far-end radio) learn of the MAC address? >>=20 >> @Stan: >> Assume frames have 4 MAC addresses: SA, DA, TA and RA. >> SA: Source Address, sending router >> DA: Destination Address, receiving router (far end radio sends frame = to locally attached router) >> TA: Transmitter Address, radio ID of RF link, sending radio >> RA: Receiver Address, radio ID on RF link, receiving radio >>=20 >> I am aware of radio's that reuse the SA/DA for TA/RA, so they do not = need the 4-address mode. This has some limitations, in that radio = supports only one node (although there could be a work-around). The more = enhanced radios use the 4 address mode. >>=20 >> Now your question: radio inspects the frame header, to find out what = to do with it. Highly simplified: Is RA its own address? No, then = discard. It could update link metrics for TA and all SA behind TA, no = reason to ignore available info. For frames for that radio, it refresh = forwarding tables: SA is behind TA, this info is required for return = frames. Frame is converted or decapsulated and forwarded to DA, could be = flooding if unknown outgoing port was unknown. >>=20 >> Side node: when RA !=3D own address, radio could update bridge = forwarding table, and relate SA and TA. >=20 > And if the router, for whatever reason or reasons might be = appropriate, simply hasn't emitted any frames toward the radio? Then far-end nodes are not aware the router exists. In my environment, = radio silence is a normal mode of operation. Teco >=20 >=20 >>=20 >>>=20 >>>=20 >>> A picture my help (me for atleast as I try to follow). Two = different networks below. >>>=20 >>> A) >>> [ DLEP Enabled] [ DLEP Enabled] >>> [ radio~router]~~~~~~~[ radio|router]=20 >>>=20 >>> B) >>> [ DLEP Enabled] [ integrated] >>> [ radio~router]~~~~~~~[ radio|host] >>=20 >> There are more scenario's: >>=20 >> C) >> [ DLEP Enabled] [ DLEP Disabled] >> [ radio~router]~~~~~~~[ radio|router ]=20 >>=20 >> D) >> [ DLEP Enabled] >> [ DLEP Enabled] [ integrated] >> [ radio~router]~~~~~~~[ radio|host] >>=20 >> All should work. >>=20 >>>=20 >>> The [integrated radio|host] shares MAC/IP address information via a = driver, not DLEP. >> What is "shares MAC/IP address"? >> With 4 address mode, SA and TA would be same MAC address. >>=20 >>> In configuration (B) the DLEP Enabled radio must obtain the host MAC = address to drive DLEP. How the DLEP Enabled radio obtains the host MAC = is really a function of the DLEP Enabled radio. Once obtained, the DLEP = Enabled radio generates a Neighbor Up and can report metrics associated = with the host MAC. The DLEP Enabled router uses the host MAC in the = DLEP messages to adjust/influence routing.=20 >>=20 >> Agreed in that the DLEP specification shall not assume both sides of = link have DLEP enabled, such as with (B) and (C)?=20 >>=20 >> Teco >>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> BTW, I would just send the metric costs. Neighbor up is implicit. = Due to RF, signals fade away, Neighbor down is artificial (or result of = a disconnect).=20 >>>>>=20 >>>>> Teco >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>> And I'm not OK with *requiring* that level of functionality in = the radio. >>>>>>> I didn't read anything here that didn't match 802.1D. >>>>>>>=20 >>>>>>> Teco >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Stan >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Teco >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het volgende = geschreven: >>>>>>>>>=20 >>>>>>>>>> I mean I understand from discussions that Stan's reply to = Teco that he does not beleive to use bridge mode, >>>>>>>>>>=20 >>>>>>>>>> AB >>>>>>>>>>=20 >>>>>>>>>> On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge = wrote: >>>>>>>>>> On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun >>>>>>>>>> wrote: >>>>>>>>>>>> Because there was no "radio-to-MAC" correlation, >>>>>>>>>>>=20 >>>>>>>>>>> IMO, correlation concept not understood, but understand that = we don't need >>>>>>>>>>> bridge mode. However, still waiting for the respond to Teco = question, >>>>>>>>>>=20 >>>>>>>>>> What do you mean with "we don't need bridge mode" ? >>>>>>>>>>=20 >>>>>>>>>> Henning Rogge >>>>>>>>>> -- >>>>>>>>>> Steven Hawkings about cosmic inflation: "An increase of = billions of >>>>>>>>>> billions of percent in a tiny fraction of a second. Of = course, that >>>>>>>>>> was before the present government." >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> manet mailing list >>>>>>>>>> manet@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> manet mailing list >>>>>>>>> manet@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >=20 From teco@inf-net.nl Thu Nov 15 08:03:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170C821F8917 for ; Thu, 15 Nov 2012 08:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJlQegMQOWj6 for ; Thu, 15 Nov 2012 08:03:37 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D98DE21F8514 for ; Thu, 15 Nov 2012 08:03:36 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so868796bku.31 for ; Thu, 15 Nov 2012 08:03:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=uqA7hd29swB5GrN5SpvyrLMs5ra+Y3+efz9q4SCQ3/Q=; b=BgVb9Jfx0F7ttuP+ACyOjrkR+tgg8ukAngHJC/Tp7Wh9OyJcZU4usY07wWT/5DWbYE MWfwKrQfIGkFY+k0c7jkJ9nHNTdL4eX69YTuTyXtnPs12ShVWguFgQ7mkXkAx/RsMKes r7yrcCAR/7AswjfwLuq+ZNxtiv6WLY4rnZJNcD5vyNZ5FLujRSMVYY9WLy83AwnbpHZ7 pDQWj2IlewrIM+NHslvbvhm+ZmyOVwM6518ybOfUdcutqgUIEkul4Oh67iAdMJwmFRzt 5PqxB6PobcN7hNSt9PUoLKC6TbV+HJ/T78YzmUyfkm5lJtxVe3NN2Qc8TVGcuIBLwuqe 08qw== Received: by 10.204.8.136 with SMTP id h8mr596822bkh.62.1352995416342; Thu, 15 Nov 2012 08:03:36 -0800 (PST) Received: from [172.20.10.3] ([84.241.201.240]) by mx.google.com with ESMTPS id u3sm4230571bkw.9.2012.11.15.08.03.20 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 08:03:35 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430886@xmb-aln-x03.cisco.com> Date: Thu, 15 Nov 2012 17:02:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> <8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459 FDB4EAC9EAD090C0F42FFE2@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430211@xmb-aln-x03.cisco.com> <50FBC4FB-6677-440A-B50A-685DFDD96A46@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430886@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnbwTNVa9zU3WoP6weBFUsVLRdb0x9G3DUGesg+NlCD8TsZXQ0exPojgeiVQ4RvGLp6RI9o Cc: manet , "Bo Berry \(boberry\)" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 16:03:38 -0000 Op 15 nov. 2012, om 15:55 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Nov 15, 2012, at 1:29 AM, Teco Boot wrote: >=20 >>=20 >> Op 14 nov. 2012, om 20:43 heeft Bo Berry het volgende geschreven: >>=20 >>>=20 >>> On Nov 14, 2012, at 2:26 PM, Stan Ratliff (sratliff) wrote: >>>=20 >>>>=20 >>>> On Nov 14, 2012, at 2:03 PM, Teco Boot wrote: >>>>=20 >>>>>=20 >>>>> Op 14 nov. 2012, om 19:31 heeft Stan Ratliff (sratliff) het = volgende geschreven: >>>>>=20 >>>>>>=20 >>>>>> On Nov 14, 2012, at 10:55 AM, Teco Boot wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> Op 14 nov. 2012, om 16:34 heeft Stan Ratliff (sratliff) het = volgende geschreven: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Nov 14, 2012, at 7:15 AM, Teco Boot wrote: >>>>>>>>=20 >>>>>>>>> Attempt to make thinks clear. >>>>>>>>>=20 >>>>>>>>> Radio is L2 device, could be 802.1D bridge or repeater. Device = is=20 >>>>>>>>> self learning. It has MAC addresses and probably an IP = address.=20 >>>>>>>>> Routers are connected to radio with ethernet or equivalent. >>>>>>>>> Routers have a sub-IP connection with each other via the = ethernet - RF >>>>>>>>> - ethernet sub-IP link. Connection is based on 802.1 MAC = addresses. >>>>>>>>> Radio has the task to deliver router originated frames to = destination, >>>>>>>>> based on destination MAC address. Could be L2 multicast or = broadcast. >>>>>>>>> With DLEP, radios have the task to keep track of link = properties between >>>>>>>>> each connected device. Could be *any* connected ethernet NIC, = as long as=20 >>>>>>>>> it has an 802.1 address and it sends a packet every now and = then. All=20 >>>>>>>>> radios in the sub-IP network automatically learn the existence = of each=20 >>>>>>>>> connected sending node, as required by 802.1D. DLEP shall be = 100%=20 >>>>>>>>> compatible with this widely deployed mechanism. It shall = provide link >>>>>>>>> metrics for far end connected MAC addresses to locally = connected nodes. >>>>>>>>> It shall work this way for single- and multi-hop sub-IP = networks. >>>>>>>>=20 >>>>>>>> I think we're talking past each other. DLEP has not assumed = 802.1D support in the radios, so all of your "shall" verbiage doesn't = make sense. The only assumption DLEP makes (at least as of now) is that = the radios operate in transparent bridge mode - that the destination MAC = is that of the far-end router, not any of the intervening devices. >>>>>>> As is in 802.1D. >>>>>>>=20 >>>>>>>> And without some flows from router *to* radio, your "one-way = only" communication mode doesn't work, because you can't correlate a = router to it's attached RF device. >>>>>>> It is the RF device that is locally connected. Not the far end = RF device. Cannot be mistaken, can it? >>>>>>=20 >>>>>> Yes, it can. Given 3 radio/router pairs, each in the "one-way" = mode, what MAC address is in the Neighbor Up? >>>>>=20 >>>>> The far end router. It doesn't need to be DLEP enabled. Could be a = host also, like a laptop for testing. >>>>=20 >>>> And how does the radio (far-end radio) learn of the MAC address? >>=20 >> @Stan: >> Assume frames have 4 MAC addresses: SA, DA, TA and RA. >> SA: Source Address, sending router >> DA: Destination Address, receiving router (far end radio sends frame = to locally attached router) >> TA: Transmitter Address, radio ID of RF link, sending radio >> RA: Receiver Address, radio ID on RF link, receiving radio >>=20 >> I am aware of radio's that reuse the SA/DA for TA/RA, so they do not = need the 4-address mode. This has some limitations, in that radio = supports only one node (although there could be a work-around). The more = enhanced radios use the 4 address mode. >>=20 >> Now your question: radio inspects the frame header, to find out what = to do with it. Highly simplified: Is RA its own address? No, then = discard. It could update link metrics for TA and all SA behind TA, no = reason to ignore available info. For frames for that radio, it refresh = forwarding tables: SA is behind TA, this info is required for return = frames. Frame is converted or decapsulated and forwarded to DA, could be = flooding if unknown outgoing port was unknown. >>=20 >> Side node: when RA !=3D own address, radio could update bridge = forwarding table, and relate SA and TA. >=20 > And if the router, for whatever reason or reasons might be = appropriate, simply hasn't emitted any frames toward the radio? Then far-end nodes are not aware the router exists. In my environment, = radio silence is a normal mode of operation. Teco >=20 >=20 >>=20 >>>=20 >>>=20 >>> A picture my help (me for atleast as I try to follow). Two = different networks below. >>>=20 >>> A) >>> [ DLEP Enabled] [ DLEP Enabled] >>> [ radio~router]~~~~~~~[ radio|router]=20 >>>=20 >>> B) >>> [ DLEP Enabled] [ integrated] >>> [ radio~router]~~~~~~~[ radio|host] >>=20 >> There are more scenario's: >>=20 >> C) >> [ DLEP Enabled] [ DLEP Disabled] >> [ radio~router]~~~~~~~[ radio|router ]=20 >>=20 >> D) >> [ DLEP Enabled] >> [ DLEP Enabled] [ integrated] >> [ radio~router]~~~~~~~[ radio|host] >>=20 >> All should work. >>=20 >>>=20 >>> The [integrated radio|host] shares MAC/IP address information via a = driver, not DLEP. >> What is "shares MAC/IP address"? >> With 4 address mode, SA and TA would be same MAC address. >>=20 >>> In configuration (B) the DLEP Enabled radio must obtain the host MAC = address to drive DLEP. How the DLEP Enabled radio obtains the host MAC = is really a function of the DLEP Enabled radio. Once obtained, the DLEP = Enabled radio generates a Neighbor Up and can report metrics associated = with the host MAC. The DLEP Enabled router uses the host MAC in the = DLEP messages to adjust/influence routing.=20 >>=20 >> Agreed in that the DLEP specification shall not assume both sides of = link have DLEP enabled, such as with (B) and (C)?=20 >>=20 >> Teco >>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> BTW, I would just send the metric costs. Neighbor up is implicit. = Due to RF, signals fade away, Neighbor down is artificial (or result of = a disconnect).=20 >>>>>=20 >>>>> Teco >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>> And I'm not OK with *requiring* that level of functionality in = the radio. >>>>>>> I didn't read anything here that didn't match 802.1D. >>>>>>>=20 >>>>>>> Teco >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Stan >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Teco >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het volgende = geschreven: >>>>>>>>>=20 >>>>>>>>>> I mean I understand from discussions that Stan's reply to = Teco that he does not beleive to use bridge mode, >>>>>>>>>>=20 >>>>>>>>>> AB >>>>>>>>>>=20 >>>>>>>>>> On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge = wrote: >>>>>>>>>> On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun >>>>>>>>>> wrote: >>>>>>>>>>>> Because there was no "radio-to-MAC" correlation, >>>>>>>>>>>=20 >>>>>>>>>>> IMO, correlation concept not understood, but understand that = we don't need >>>>>>>>>>> bridge mode. However, still waiting for the respond to Teco = question, >>>>>>>>>>=20 >>>>>>>>>> What do you mean with "we don't need bridge mode" ? >>>>>>>>>>=20 >>>>>>>>>> Henning Rogge >>>>>>>>>> -- >>>>>>>>>> Steven Hawkings about cosmic inflation: "An increase of = billions of >>>>>>>>>> billions of percent in a tiny fraction of a second. Of = course, that >>>>>>>>>> was before the present government." >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> manet mailing list >>>>>>>>>> manet@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> manet mailing list >>>>>>>>> manet@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >=20 From sratliff@cisco.com Thu Nov 15 08:26:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0C321F888C for ; Thu, 15 Nov 2012 08:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tZZ++2ZevjI for ; Thu, 15 Nov 2012 08:26:02 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0882C21F87AD for ; Thu, 15 Nov 2012 08:26:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9199; q=dns/txt; s=iport; t=1352996762; x=1354206362; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CtlBQ+1lNl/gaTIGiA4LiruPNIMSbyuzuxpg+g2S8MA=; b=gHOv6WYUTlXCbzFXyvvybHMoJhwIIU9CUVnce86kQJjBX5573w6PUxHO WrQbgkloGlR0Bt7M6qtTMXGxp+4aODh3qxnK/5dgdKTJY74pDN3k/JDh0 p/1RgRfp2Q+BSbw2e0gct0HAUH/HsrCWKmTDkFMIIm7cSSm1asPo6cbCo E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPsWpVCtJXHA/2dsb2JhbABEwkKBCIIeAQEBAwEBAQEPASczAQsFCwIBCBgKFBAhBgslAgQOBQgah1kDCQYLnGmWLA2JUASLSGmFS2EDlCeNB4MmgWuCb4IZ X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142817306" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 15 Nov 2012 16:26:01 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qAFGQ1Cu006563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Nov 2012 16:26:01 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 10:26:00 -0600 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] DLEP Lite? (Teco Boot) Thread-Index: Ac2+jVdl8St7CxHOQImNx8g7RjcZBAADdN/wABHqP4AAAJBkAAAANyIAACiFJoAABx7cAAAAnAOAAAkZpoAAQH5XAABOdncAAAAjnYAAAlheAAAgtueAAAb0igAAAL9VAAAFc36AAAEa+QAAAM3JgAAAl7KAABaSq4AAEaeGgAACWPcAAADTJoA= Date: Thu, 15 Nov 2012 16:26:00 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430A1A@xmb-aln-x03.cisco.com> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> <8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459 FDB4EAC9EAD090C0F42FFE2@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430211@xmb-aln-x03.cisco.com> <50FBC4FB-6677-440A-B50A-685DFDD96A46@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430886@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.100] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19368.001 x-tm-as-result: No--45.473300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , "Bo Berry \(boberry\)" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 16:26:03 -0000 On Nov 15, 2012, at 11:02 AM, Teco Boot wrote: >=20 > Op 15 nov. 2012, om 15:55 heeft Stan Ratliff (sratliff) het volgende gesc= hreven: >=20 >>=20 >> On Nov 15, 2012, at 1:29 AM, Teco Boot wrote: >>=20 >>>=20 >>> Op 14 nov. 2012, om 20:43 heeft Bo Berry het volgende geschreven: >>>=20 >>>>=20 >>>> On Nov 14, 2012, at 2:26 PM, Stan Ratliff (sratliff) wrote: >>>>=20 >>>>>=20 >>>>> On Nov 14, 2012, at 2:03 PM, Teco Boot wrote: >>>>>=20 >>>>>>=20 >>>>>> Op 14 nov. 2012, om 19:31 heeft Stan Ratliff (sratliff) het volgende= geschreven: >>>>>>=20 >>>>>>>=20 >>>>>>> On Nov 14, 2012, at 10:55 AM, Teco Boot wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Op 14 nov. 2012, om 16:34 heeft Stan Ratliff (sratliff) het volgen= de geschreven: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Nov 14, 2012, at 7:15 AM, Teco Boot wrote: >>>>>>>>>=20 >>>>>>>>>> Attempt to make thinks clear. >>>>>>>>>>=20 >>>>>>>>>> Radio is L2 device, could be 802.1D bridge or repeater. Device i= s=20 >>>>>>>>>> self learning. It has MAC addresses and probably an IP address.= =20 >>>>>>>>>> Routers are connected to radio with ethernet or equivalent. >>>>>>>>>> Routers have a sub-IP connection with each other via the etherne= t - RF >>>>>>>>>> - ethernet sub-IP link. Connection is based on 802.1 MAC address= es. >>>>>>>>>> Radio has the task to deliver router originated frames to destin= ation, >>>>>>>>>> based on destination MAC address. Could be L2 multicast or broad= cast. >>>>>>>>>> With DLEP, radios have the task to keep track of link properties= between >>>>>>>>>> each connected device. Could be *any* connected ethernet NIC, as= long as=20 >>>>>>>>>> it has an 802.1 address and it sends a packet every now and then= . All=20 >>>>>>>>>> radios in the sub-IP network automatically learn the existence o= f each=20 >>>>>>>>>> connected sending node, as required by 802.1D. DLEP shall be 100= %=20 >>>>>>>>>> compatible with this widely deployed mechanism. It shall provide= link >>>>>>>>>> metrics for far end connected MAC addresses to locally connected= nodes. >>>>>>>>>> It shall work this way for single- and multi-hop sub-IP networks= . >>>>>>>>>=20 >>>>>>>>> I think we're talking past each other. DLEP has not assumed 802.1= D support in the radios, so all of your "shall" verbiage doesn't make sense= . The only assumption DLEP makes (at least as of now) is that the radios op= erate in transparent bridge mode - that the destination MAC is that of the = far-end router, not any of the intervening devices. >>>>>>>> As is in 802.1D. >>>>>>>>=20 >>>>>>>>> And without some flows from router *to* radio, your "one-way only= " communication mode doesn't work, because you can't correlate a router to = it's attached RF device. >>>>>>>> It is the RF device that is locally connected. Not the far end RF = device. Cannot be mistaken, can it? >>>>>>>=20 >>>>>>> Yes, it can. Given 3 radio/router pairs, each in the "one-way" mode= , what MAC address is in the Neighbor Up? >>>>>>=20 >>>>>> The far end router. It doesn't need to be DLEP enabled. Could be a h= ost also, like a laptop for testing. >>>>>=20 >>>>> And how does the radio (far-end radio) learn of the MAC address? >>>=20 >>> @Stan: >>> Assume frames have 4 MAC addresses: SA, DA, TA and RA. >>> SA: Source Address, sending router >>> DA: Destination Address, receiving router (far end radio sends frame to= locally attached router) >>> TA: Transmitter Address, radio ID of RF link, sending radio >>> RA: Receiver Address, radio ID on RF link, receiving radio >>>=20 >>> I am aware of radio's that reuse the SA/DA for TA/RA, so they do not ne= ed the 4-address mode. This has some limitations, in that radio supports on= ly one node (although there could be a work-around). The more enhanced radi= os use the 4 address mode. >>>=20 >>> Now your question: radio inspects the frame header, to find out what to= do with it. Highly simplified: Is RA its own address? No, then discard. It= could update link metrics for TA and all SA behind TA, no reason to ignore= available info. For frames for that radio, it refresh forwarding tables: S= A is behind TA, this info is required for return frames. Frame is converted= or decapsulated and forwarded to DA, could be flooding if unknown outgoing= port was unknown. >>>=20 >>> Side node: when RA !=3D own address, radio could update bridge forwardi= ng table, and relate SA and TA. >>=20 >> And if the router, for whatever reason or reasons might be appropriate, = simply hasn't emitted any frames toward the radio? >=20 > Then far-end nodes are not aware the router exists. In my environment, ra= dio silence is a normal mode of operation. >=20 I'm not talking about radio silence. Just a router that hasn't emitted any = frames. So back to my original comment - this suggestion is making assumpti= ons. It assumes that the radio is snooping/cacheing MAC addresses, and it a= ssumes that the router is forwarding frames to the radio prior to any "Neig= hbor Up" event. I do not believe that DLEP should be making such assumption= s.=20 Stan > Teco >=20 >>=20 >>=20 >>>=20 >>>>=20 >>>>=20 >>>> A picture my help (me for atleast as I try to follow). Two different = networks below. >>>>=20 >>>> A) >>>> [ DLEP Enabled] [ DLEP Enabled] >>>> [ radio~router]~~~~~~~[ radio|router]=20 >>>>=20 >>>> B) >>>> [ DLEP Enabled] [ integrated] >>>> [ radio~router]~~~~~~~[ radio|host] >>>=20 >>> There are more scenario's: >>>=20 >>> C) >>> [ DLEP Enabled] [ DLEP Disabled] >>> [ radio~router]~~~~~~~[ radio|router ]=20 >>>=20 >>> D) >>> [ DLEP Enabled] >>> [ DLEP Enabled] [ integrated] >>> [ radio~router]~~~~~~~[ radio|host] >>>=20 >>> All should work. >>>=20 >>>>=20 >>>> The [integrated radio|host] shares MAC/IP address information via a dr= iver, not DLEP. >>> What is "shares MAC/IP address"? >>> With 4 address mode, SA and TA would be same MAC address. >>>=20 >>>> In configuration (B) the DLEP Enabled radio must obtain the host MAC a= ddress to drive DLEP. How the DLEP Enabled radio obtains the host MAC is r= eally a function of the DLEP Enabled radio. Once obtained, the DLEP Enable= d radio generates a Neighbor Up and can report metrics associated with the = host MAC. The DLEP Enabled router uses the host MAC in the DLEP messages t= o adjust/influence routing.=20 >>>=20 >>> Agreed in that the DLEP specification shall not assume both sides of li= nk have DLEP enabled, such as with (B) and (C)?=20 >>>=20 >>> Teco >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> BTW, I would just send the metric costs. Neighbor up is implicit. Du= e to RF, signals fade away, Neighbor down is artificial (or result of a dis= connect).=20 >>>>>>=20 >>>>>> Teco >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>>> And I'm not OK with *requiring* that level of functionality in th= e radio. >>>>>>>> I didn't read anything here that didn't match 802.1D. >>>>>>>>=20 >>>>>>>> Teco >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Stan >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Teco >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het volgende g= eschreven: >>>>>>>>>>=20 >>>>>>>>>>> I mean I understand from discussions that Stan's reply to Teco = that he does not beleive to use bridge mode, >>>>>>>>>>>=20 >>>>>>>>>>> AB >>>>>>>>>>>=20 >>>>>>>>>>> On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge wrote: >>>>>>>>>>> On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun >>>>>>>>>>> wrote: >>>>>>>>>>>>> Because there was no "radio-to-MAC" correlation, >>>>>>>>>>>>=20 >>>>>>>>>>>> IMO, correlation concept not understood, but understand that w= e don't need >>>>>>>>>>>> bridge mode. However, still waiting for the respond to Teco qu= estion, >>>>>>>>>>>=20 >>>>>>>>>>> What do you mean with "we don't need bridge mode" ? >>>>>>>>>>>=20 >>>>>>>>>>> Henning Rogge >>>>>>>>>>> -- >>>>>>>>>>> Steven Hawkings about cosmic inflation: "An increase of billion= s of >>>>>>>>>>> billions of percent in a tiny fraction of a second. Of course, = that >>>>>>>>>>> was before the present government." >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> manet mailing list >>>>>>>>>>> manet@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> manet mailing list >>>>>>>>>> manet@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Thu Nov 15 10:56:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F8921F84D8 for ; Thu, 15 Nov 2012 10:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E67Z1QWeRn99 for ; Thu, 15 Nov 2012 10:56:22 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8BD21F84DF for ; Thu, 15 Nov 2012 10:56:20 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so876441eaa.31 for ; Thu, 15 Nov 2012 10:56:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=bJSmmQfjwWDo5fTuSfLAChE1ikJPHCyuBzaPTEbvF20=; b=eNJjdZsEALRDNGjewAmqizrJ+XE1CSSdlj8hZSCsV7rtTQVxPvP22tehEiqTHLj+B+ t0AnD7lZa/GxzBrWZdu0UmdgcmbQP2LY8Z/7ocV2Vg6SDYEgB4MQyiKDUVWfPkhabpWV jnRXcxrH2tE4OZv9cy0e5jb/179Jt89/UOSWnRKes1yqeO3DIX9dAYc5VoxCpD4LZVMI qmNfAfidHNy8PY1IBw9B45MPYF9v5d8sCWE2+aVCxmbVSswObISe2FiB0HfzqHscQWt9 7rZUquSF+WTUN3KPs5S8CbgZ66zeubGJ/jW6HAbSuC09Q/kP/wQXV43r5QPm5OPu7Tnj iCdw== Received: by 10.14.194.136 with SMTP id m8mr6587829een.10.1353005779846; Thu, 15 Nov 2012 10:56:19 -0800 (PST) Received: from [10.175.173.26] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id f2sm37778998eep.2.2012.11.15.10.56.17 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 10:56:18 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430A1A@xmb-aln-x03.cisco.com> Date: Thu, 15 Nov 2012 19:56:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <96CB7ACD-3B90-4111-957A-8D96D77C90E4@inf-net.nl> References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com> <5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com> <56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl> <8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459 FDB4EAC9EAD090C0F42FFE2@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430211@xmb-aln-x03.cisco.com> <50FBC4FB-6677-440A-B50A-685DFDD96A46@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430886@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F430A1A@xmb-aln-x03.cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlFAecdkvJhPTH+VJDuGBubp1ibKED/0oQtPspvAQJyTuKJ+4iy2RbJiTdEL+VMrUuxV8Dk Cc: manet , "Bo Berry \(boberry\)" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:56:22 -0000 Op 15 nov. 2012, om 17:26 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Nov 15, 2012, at 11:02 AM, Teco Boot wrote: >=20 >>=20 >> Op 15 nov. 2012, om 15:55 heeft Stan Ratliff (sratliff) het volgende = geschreven: >>=20 >>>=20 >>> On Nov 15, 2012, at 1:29 AM, Teco Boot wrote: >>>=20 >>>>=20 >>>> Op 14 nov. 2012, om 20:43 heeft Bo Berry het volgende geschreven: >>>>=20 >>>>>=20 >>>>> On Nov 14, 2012, at 2:26 PM, Stan Ratliff (sratliff) wrote: >>>>>=20 >>>>>>=20 >>>>>> On Nov 14, 2012, at 2:03 PM, Teco Boot wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> Op 14 nov. 2012, om 19:31 heeft Stan Ratliff (sratliff) het = volgende geschreven: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Nov 14, 2012, at 10:55 AM, Teco Boot wrote: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Op 14 nov. 2012, om 16:34 heeft Stan Ratliff (sratliff) het = volgende geschreven: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Nov 14, 2012, at 7:15 AM, Teco Boot wrote: >>>>>>>>>>=20 >>>>>>>>>>> Attempt to make thinks clear. >>>>>>>>>>>=20 >>>>>>>>>>> Radio is L2 device, could be 802.1D bridge or repeater. = Device is=20 >>>>>>>>>>> self learning. It has MAC addresses and probably an IP = address.=20 >>>>>>>>>>> Routers are connected to radio with ethernet or equivalent. >>>>>>>>>>> Routers have a sub-IP connection with each other via the = ethernet - RF >>>>>>>>>>> - ethernet sub-IP link. Connection is based on 802.1 MAC = addresses. >>>>>>>>>>> Radio has the task to deliver router originated frames to = destination, >>>>>>>>>>> based on destination MAC address. Could be L2 multicast or = broadcast. >>>>>>>>>>> With DLEP, radios have the task to keep track of link = properties between >>>>>>>>>>> each connected device. Could be *any* connected ethernet = NIC, as long as=20 >>>>>>>>>>> it has an 802.1 address and it sends a packet every now and = then. All=20 >>>>>>>>>>> radios in the sub-IP network automatically learn the = existence of each=20 >>>>>>>>>>> connected sending node, as required by 802.1D. DLEP shall be = 100%=20 >>>>>>>>>>> compatible with this widely deployed mechanism. It shall = provide link >>>>>>>>>>> metrics for far end connected MAC addresses to locally = connected nodes. >>>>>>>>>>> It shall work this way for single- and multi-hop sub-IP = networks. >>>>>>>>>>=20 >>>>>>>>>> I think we're talking past each other. DLEP has not assumed = 802.1D support in the radios, so all of your "shall" verbiage doesn't = make sense. The only assumption DLEP makes (at least as of now) is that = the radios operate in transparent bridge mode - that the destination MAC = is that of the far-end router, not any of the intervening devices. >>>>>>>>> As is in 802.1D. >>>>>>>>>=20 >>>>>>>>>> And without some flows from router *to* radio, your "one-way = only" communication mode doesn't work, because you can't correlate a = router to it's attached RF device. >>>>>>>>> It is the RF device that is locally connected. Not the far end = RF device. Cannot be mistaken, can it? >>>>>>>>=20 >>>>>>>> Yes, it can. Given 3 radio/router pairs, each in the "one-way" = mode, what MAC address is in the Neighbor Up? >>>>>>>=20 >>>>>>> The far end router. It doesn't need to be DLEP enabled. Could be = a host also, like a laptop for testing. >>>>>>=20 >>>>>> And how does the radio (far-end radio) learn of the MAC address? >>>>=20 >>>> @Stan: >>>> Assume frames have 4 MAC addresses: SA, DA, TA and RA. >>>> SA: Source Address, sending router >>>> DA: Destination Address, receiving router (far end radio sends = frame to locally attached router) >>>> TA: Transmitter Address, radio ID of RF link, sending radio >>>> RA: Receiver Address, radio ID on RF link, receiving radio >>>>=20 >>>> I am aware of radio's that reuse the SA/DA for TA/RA, so they do = not need the 4-address mode. This has some limitations, in that radio = supports only one node (although there could be a work-around). The more = enhanced radios use the 4 address mode. >>>>=20 >>>> Now your question: radio inspects the frame header, to find out = what to do with it. Highly simplified: Is RA its own address? No, then = discard. It could update link metrics for TA and all SA behind TA, no = reason to ignore available info. For frames for that radio, it refresh = forwarding tables: SA is behind TA, this info is required for return = frames. Frame is converted or decapsulated and forwarded to DA, could be = flooding if unknown outgoing port was unknown. >>>>=20 >>>> Side node: when RA !=3D own address, radio could update bridge = forwarding table, and relate SA and TA. >>>=20 >>> And if the router, for whatever reason or reasons might be = appropriate, simply hasn't emitted any frames toward the radio? >>=20 >> Then far-end nodes are not aware the router exists. In my = environment, radio silence is a normal mode of operation. >>=20 >=20 > I'm not talking about radio silence. Just a router that hasn't emitted = any frames. OK, I just mentioned I have to deal with silent radios. I guess I am not = the only one here. > So back to my original comment - this suggestion is making = assumptions. Yes, in that standard protocols are being used. Not a bad assumption, I = think. If your DLEP proposal is not built on standards, I prefer staying far = away from it.=20 > It assumes that the radio is snooping/cacheing MAC addresses, Yes. It is specified in dlep-03, page 8: DLEP assumes that participating modems, and their physical links, act as a transparent bridge. I am not aware of transparent bridges that do not act the way I = describe. > and it assumes that the router is forwarding frames to the radio prior = to any "Neighbor Up" event. I do not believe that DLEP should be making = such assumptions.=20 Are you kidding in that a router does not send packets on an interface, = where the routing protocol is enabled? (leaving PPPoE / VMI out of scope here) Teco >=20 > Stan >=20 >=20 >> Teco >>=20 >>>=20 >>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>> A picture my help (me for atleast as I try to follow). Two = different networks below. >>>>>=20 >>>>> A) >>>>> [ DLEP Enabled] [ DLEP Enabled] >>>>> [ radio~router]~~~~~~~[ radio|router]=20 >>>>>=20 >>>>> B) >>>>> [ DLEP Enabled] [ integrated] >>>>> [ radio~router]~~~~~~~[ radio|host] >>>>=20 >>>> There are more scenario's: >>>>=20 >>>> C) >>>> [ DLEP Enabled] [ DLEP Disabled] >>>> [ radio~router]~~~~~~~[ radio|router ]=20 >>>>=20 >>>> D) >>>> [ DLEP Enabled] >>>> [ DLEP Enabled] [ integrated] >>>> [ radio~router]~~~~~~~[ radio|host] >>>>=20 >>>> All should work. >>>>=20 >>>>>=20 >>>>> The [integrated radio|host] shares MAC/IP address information via = a driver, not DLEP. >>>> What is "shares MAC/IP address"? >>>> With 4 address mode, SA and TA would be same MAC address. >>>>=20 >>>>> In configuration (B) the DLEP Enabled radio must obtain the host = MAC address to drive DLEP. How the DLEP Enabled radio obtains the host = MAC is really a function of the DLEP Enabled radio. Once obtained, the = DLEP Enabled radio generates a Neighbor Up and can report metrics = associated with the host MAC. The DLEP Enabled router uses the host MAC = in the DLEP messages to adjust/influence routing.=20 >>>>=20 >>>> Agreed in that the DLEP specification shall not assume both sides = of link have DLEP enabled, such as with (B) and (C)?=20 >>>>=20 >>>> Teco >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> BTW, I would just send the metric costs. Neighbor up is = implicit. Due to RF, signals fade away, Neighbor down is artificial (or = result of a disconnect).=20 >>>>>>>=20 >>>>>>> Teco >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> And I'm not OK with *requiring* that level of functionality = in the radio. >>>>>>>>> I didn't read anything here that didn't match 802.1D. >>>>>>>>>=20 >>>>>>>>> Teco >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Stan >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Teco >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het = volgende geschreven: >>>>>>>>>>>=20 >>>>>>>>>>>> I mean I understand from discussions that Stan's reply to = Teco that he does not beleive to use bridge mode, >>>>>>>>>>>>=20 >>>>>>>>>>>> AB >>>>>>>>>>>>=20 >>>>>>>>>>>> On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge = wrote: >>>>>>>>>>>> On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun >>>>>>>>>>>> wrote: >>>>>>>>>>>>>> Because there was no "radio-to-MAC" correlation, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> IMO, correlation concept not understood, but understand = that we don't need >>>>>>>>>>>>> bridge mode. However, still waiting for the respond to = Teco question, >>>>>>>>>>>>=20 >>>>>>>>>>>> What do you mean with "we don't need bridge mode" ? >>>>>>>>>>>>=20 >>>>>>>>>>>> Henning Rogge >>>>>>>>>>>> -- >>>>>>>>>>>> Steven Hawkings about cosmic inflation: "An increase of = billions of >>>>>>>>>>>> billions of percent in a tiny fraction of a second. Of = course, that >>>>>>>>>>>> was before the present government." >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> manet mailing list >>>>>>>>>>>> manet@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> manet mailing list >>>>>>>>>>> manet@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From nathan@nathansamson.be Mon Nov 19 04:07:04 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5D721F85D3 for ; Mon, 19 Nov 2012 04:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.224 X-Spam-Level: X-Spam-Status: No, score=0.224 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWlDruVcqzSi for ; Mon, 19 Nov 2012 04:07:02 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8154521F85D2 for ; Mon, 19 Nov 2012 04:07:01 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so3372932qca.31 for ; Mon, 19 Nov 2012 04:07:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nathansamson.be; s=google; h=mime-version:sender:x-originating-ip:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=2NNJzvLxCxeds0rG+Jb1mIHM5zGqK2rWYlAIIe3Si+A=; b=iTi0y7xkKLfUybqwaN/lOdpFggELqC34IcvBhaKeQrBrn5hiuRIcZ57JLrODGdHfYk NXhZfsYgpT59omasIgiAMaJ17cVORFedAyzeioaPvgcq9oX5hYCMCRPd/ckQAvhxlkhI YYxRXxJvh64HBE4XWCDSaQ/BAEFq4V65WvQP0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:from:date:x-google-sender-auth :message-id:subject:to:content-type:x-gm-message-state; bh=2NNJzvLxCxeds0rG+Jb1mIHM5zGqK2rWYlAIIe3Si+A=; b=iGkR32ie/LhVuYrciBbM9RcQv14+uR9TJ2747ekLmMUVJzF5oNoaXiUWFLnY81aQiF TbNaztmA/gV9chG4mURbTumzqtIRn7H1j6q+swRa2v2PToq1K1nxhAmMP1aVDAOa+gZu xs5YSVWzsetuEuTpd/mOUBn2W+iKq2XIXGfgoh4zwUhI5hr/g/Uu9urKjcLHrLn0hmC9 NgiU4D2ST+YPAzVgZ4TZySzzY0UooAPg+72hQWiLvck2nLGQdTiYykd3xFCM4UAmHf7s 5Kt9+bGFjDUZURc9JP8iF0+qJgnbeIH8SAy89bYORFPetvuDXIo7OB58MPzYzSYkWhi1 QINQ== Received: by 10.49.52.33 with SMTP id q1mr13123992qeo.3.1353326820712; Mon, 19 Nov 2012 04:07:00 -0800 (PST) MIME-Version: 1.0 Sender: nathan@nathansamson.be Received: by 10.49.82.194 with HTTP; Mon, 19 Nov 2012 04:06:40 -0800 (PST) X-Originating-IP: [143.169.200.199] From: Nathan Samson Date: Mon, 19 Nov 2012 13:06:40 +0100 X-Google-Sender-Auth: DuSa1e2OASWDzFDg6dbGryFcQ6Y Message-ID: To: manet@ietf.org Content-Type: multipart/alternative; boundary=047d7bea3bc669e21004ced7f438 X-Gm-Message-State: ALoCoQkJxe2XrVaq0KlxbGtsJTN6FrbDlCkVQGhAZMrmFI9dT8SOgOKn7VX5rByR5BwaY/6Z7nMJ Subject: [manet] questions & comments about manet-dlep-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 12:08:16 -0000 --047d7bea3bc669e21004ced7f438 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi All, I have just read the dlep V03 draft and I have some comments and small questions. First I have some general questions. 1) Transport =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft V3 Specifies that this protocol is transport independent. Although new consensus (as far as I can see from recent messages on the mailing list) is that UDP would be the standard transport protocol. Some also have suggested to use TCP, which also removes the need for many of the different ACK messages we currently have. Using UDP(or TCP) would also allow for the removal of the Identification TLV (which seems to be already planned). Why is the TCP idea not applied? Some discussion on the list seems that using TCP (and removing the ACKs) would make it more difficult to move to another protocol, which also means that UDP/TCP would not be the only transport protocol? 2) Sequence Numbers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I didn't see any sequence numbers in the messages, which makes it hard to correlate any ACK with the corresponding message. Can someone confirm that indeed will appear in V4 (as I saw somewhere on the list). Note that I have seen a reference to the sequence numbers in the assumption= s Sequence Numbers for DLEP messages start at 0 and are incremented by > one for each original and retransmitted message. The unsigned 16-bit > Sequence Number rolls over at 65535 to 0. Sequence Numbers are unique > within the context of a DLEP session. Sequence numbers are used in > DLEP to correlate a response to a request. > To fix the rollover problem a better mechanism could be introduced like in RFC 3220 (Mobile IP) [1]. With that scheme you can easily detect if a rollover happened or the other participant was reset. Another inconsistency can happen with the current scheme: Modem Router -------------------------> #1 (Modem sends router message with sequence number 1) <------------------------ ACK #1 Now the sequence counter is at 1 on each side. Both the modem and router wants to send something at exactly the same moment to each other. Both will be using sequence number 2 which might pose a problem in some implementations. I propose to solve this issue by rewriting it as Numbers are unique within the context of a DLEP session *per participant*. *Each > participant keeps track of its own current sequence number, and the > sequence number of the other party. *Sequence numbers are used in DLEP to > correlate a response to a request. This means that every packet will be correlated by the implicit sequence number #PARTICIPANTID-SEQUENCE_NUMBER. ACKing a message will only include the Sequence number since the participant ID (the receiver of the ACK or the sender of the original message) is implicit. 3) Many items are specified as out of scope. I am a little bit worried that implementations can exist without being able to be inter-operable. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A) > The modem, once it is aware of the existence of this > logical neighbor, reports link characteristics just as it would for > any other destination in the network. The specific algorithms a modem > would use to report metrics on multicast (or logical) destinations is > outside the scope of this specification, and is left to specific > implementations to decide. > Is there any reason why this is not specified? Or might it not be a good idea to specify at least an example algorithm as indication? B) > Either entity (the router or the modem) can initiate the discovery > process. > What if both are configured to wait for the other? Isn't it better that at least one (eg. the modem?) should be obliged to broadcast its existence? C) > In cases where both entities initiate discovery, a race condition can > occur. > When this race condition occurs, the router MUST cease its active > discovery, and respond to the modem=92s request. > What is meant by "the router MUST cease its active discovery"? I understand this that the router must stop sending any Peer discovery message. What in the (not so uncommon) case one router has several modems attached (from different vendors and/or with different configurations) where one modem is not configured to send Peer discovery messages. In these circumstances both would not be able to find each other (see also B). D) This document details the mechanism whereby the data is > transmitted, however, the specific algorithms (precedence, etc) for > utilizing the dual-context metrics is out of scope and not addressed > by this document. > Same remark as A) E) 9.11 Resources The message has no method to be able to tell what resource usage is described. >From a consumer of this information this doesn't make sense, since having a 50% memory usage might be quite different from having only 50% battery left= . What should the sender do in case he has many types of resources (very common since any type of modem/router working on battery will have some sort of memory)? Should he take some sort of average. How to weigh 50% battery usage vs 75% memory usage? I think a less general, more specific approach should be used. Where one could specify the type of resource left in a field (Battery, memory, disk usage, ...) and the absolute value in another field. This other field might be different of type and length depending on the type of resource. The DLEP protocol could describe the most common types and their corresponding types eg. Memory (type =3D 0x01), value is unsigned 64 bit in bytes of memory left Disk (type =3D 0x02), value is unsigned 64 bit in bytes of memory left Battery Life Time (type =3D 0x03), value is unsigned 16 bit in minutes left (at current usage rate) of battery life time. Batter usage (type =3D 0x04), value is unsigned 8 bit in percent (0-100) of battery left. A method has to be invented to let implementers add their own (experimental) types. F) 9.13 Status > Non Zero =3D Failure. Specific values of ... > Isn't it better to at least specify basic error case numbers? Also an optional human readable error could be added so logs might clear up why something happened. G) 9.17 Credit grant request > with the correct Status TLV. > What is the correct Status TLV (non zero?) Probably same issue as F) H) 14. Peer Update Message > Concerning Layer 3 addresses, if the modem is capable of > understanding and forwarding this information (via proprietary > mechanisms), the address update would prompt any remote DLEP modems > (DLEP-enabled modems in a remote node) to issue a "Neighbor Update" > message to their local routers with the new (or deleted) addresses. > Modems that do not track Layer 3 addresses SHOULD silently parse and > ignore the Peer Update Message. Modems that track Layer 3 addresses > MUST acknowledge the Peer Update with a Peer Update ACK message. > Routers receiving a Peer Update with metric changes MUST apply the > new metric to all neighbors (remote nodes) accessible via the modem. > Supporting implementations are free to employ heuristics to > retransmit Peer Update messages. The sending of Peer Update Messages > for Layer 3 address changes SHOULD cease when a either participant > (router or modem) determines that the other implementation does NOT > support Layer 3 address tracking. > This is rather a vague paragraph with many unspecified items. Why is it important to detect remote DLEP modems? If a valid use case is gven, might it not be a better idea to define a mechanism in DLEP instead of specifying that a (proprietary) mechanism might be used. The heuristics for resending peer updates are not defined. Why not define a sensible set of heuristics in this document? How can implementations detect that the other party doesn't support tracking L3 changes? 4) Some items are optional. For most of those, I don't see a sensible reasoning. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A) Timers are an optional feature, although they seem to me that they are very useful. Is there any specific reason why are those optional? B) DLEP Version TLV. Why is this one optional? If one of the participants decides (because it does not implement it), not to send the version TLV it might leave the other side undecided if they can safely talk to each other. Also no Version handshake scheme is described so that implementations can choose to send only messages that are version compatible by the other side. 5) Various Comments =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A) 9.3 Peer Type Message * Length: 80 Octets maximum. Why is a maximum string length given? * The type is defined as a string, but no encoding (ASCII, UTF-8) is given. If allowing UTF-8 (as I think in the modern world we should do) the 80 octets might be quite low since might only allow for 40 visible characters in Chinese for example (if I am not mistaken) B) 9.5 IPv4 Address * Add/Drop > Value indicating whether this is a new or existing IPv4 address > Part of the sentence seems to be removed, since the description of this field is correct for the IPv6 message. * Really nitpick: > A subnet mask (0-32) to be applied to the IPv4 address. > (similar for IPv6) It is not defined what the data type of this field is. Obviously a 8 bit integer value, but signed vs unsigned is not defined. Obviously an unsigned value does not make sense in this case (and is even impossible in the IPv6 case where 127 would be the maximum). C) 9.8 Current Data Rate * Contains a TLV Flags =3D 0X10 which is not defined, and is not used anywhere else. I suspect this is a leftover of a previous version. D) 9.11 Resources & 9.12 Relative link quality If the values are not supported or can not be calculated their value is set to 100, which makes it difficult (if not impossible) to differentiate between the perfect case and the unknown case. Since the used range is only 0-100 and we have 8 bits available we can also use 255 as a unknown case. E) 9.14 Heartbeat interval > . If an activity timeout is supported, implementations > MAY choose to implement heuristics such that signals sent/received > reset the timer window. > What if the sender resets its windows, but the receiver does not imply such heuristics? Then the receiver might time-out and send a peer terminate request. I think these heuristics must be required and clearly specified (since they make sense to reduce the load on the network). F) 9.18 Credit Request Length =3D 0. Problem is that the length of the package is 1, with a reserv= ed field that must be set to 0. I think this reserved field has to be removed (leftover of a previous version?) G) 22. Neighbour Update Message The Neighbour Update doesn't have to seem an ACK message. Is this intentional? H) 25. Link Characteristics Request ACK Message. > The Link Characteristics ACK message SHOULD contain a complete set > of metric data item TLVs. It MUST contain the same TLV types as the > request. > This seems to be a contradiction. Or it should contain a complete set, or it should contain the same as the request. Since the request may not contain any metrics (as to request the current values) it does make sense to specify only the first part. Cheers, Nathan [1] http://www.ietf.org/rfc/rfc3220.txt --047d7bea3bc669e21004ced7f438 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi All,


I have just read the dlep V03 draft and I have some comm= ents and small questions.

First I have some general questions.
1) Transport
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
Draft V3 Specifies that this protocol is transport independent. Although new=20 consensus (as far as I can see from recent messages on the mailing list) is that UDP would be the standard transport protocol.
Some also have suggested to use TCP, which also removes the need for many o= f the different ACK messages we currently have.
Using UDP(or TCP) would = also allow for the removal of the Identification TLV (which seems to be alr= eady planned).

Why is the TCP idea not applied?=A0 Some discussion on the list seems= =20 that using TCP (and removing the ACKs) would make it more difficult to=20 move to another protocol, which also means that UDP/TCP would not be the only transport protocol?


2) Sequence Numbers
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I didn't see any sequence numbers in the messages, which makes it hard to correlate=20 any ACK with the corresponding message. Can someone confirm that indeed=20 will appear in V4 (as I saw somewhere on the list).
Note that I have seen a reference to the sequence numbers in the assumption= s

Sequence Numbers= for DLEP messages start at 0 and are incremented by
one for each original and retransmitted message. The unsigned 16-bit
Seq= uence Number rolls over at 65535 to 0. Sequence Numbers are unique
withi= n the context of a DLEP session. Sequence numbers are used in
DLEP to co= rrelate a response to a request.

To fix the rollover problem a better mechanism could = be introduced like in RFC 3220 (Mobile IP) [1]. With that scheme you can ea= sily detect if a rollover happened or the other participant was reset.

Another inconsistency can happen with the current scheme:

Modem=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 Router
=A0=A0=A0=A0 ------------------------->=A0 #1 (Modem= sends router message with sequence number 1)
=A0=A0=A0 <------------------------=A0=A0=A0 ACK #1
Now the sequence= counter is at 1 on each side.
Both the modem and router wants to send something at exactly the same moment to each other. Both will be using sequence number 2 which might pose a=20 problem in some implementations.

I propose to solve this issue by rewriting it as

Numbers are unique withi= n the context of a DLEP session per participant. Each participant= =A0 keeps track of its own current sequence number, and the sequence number= of the other party. Sequence numbers are used in DLEP to correlate a r= esponse to a request.

This means that every packet will be correlated by the implicit se= quence number #PARTICIPANTID-SEQUENCE_NUMBER. ACKing a message will only in= clude the Sequence number since the participant ID (the receiver of the ACK= or the sender of the original message) is implicit.

3) Many items are specified as out of scope. I am a little bit wo= rried that implementations can exist without being able to be inter-operabl= e.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
=A0A)
The modem, once it is aware of the existence of this
logical neighbor, r= eports link characteristics just as it would for
any other destination i= n the network. The specific algorithms a modem
would use to report metri= cs on multicast (or logical) destinations is
outside the scope of this specification, and is left to specific
impleme= ntations to decide.
Is there=A0 any reason why this is= not specified? Or might it not be a good=20 idea to specify at least an example algorithm as indication?
B)
=A0Either entity (= the router or the modem) can initiate the discovery process.
What if both are configured to wait for the other? Isn't it better= =20 that at least one (eg. the modem?) should be obliged to broadcast its=20 existence?

C)
In cases where both entities initiate discovery, a race condition can occur= .
When this race condition occurs, the router MUST cease its active
d= iscovery, and respond to the modem=92s request.

What is meant by "the router MUST cease its active discovery"?I understand this that the router must stop sending any Peer discovery mes= sage.
What in the (not so uncommon) case one router has several modems attached=20 (from different vendors and/or with different configurations) where one=20 modem is not configured to send Peer discovery messages.
In these circumstances both would not be able to find each other (see also = B).
D)

This do= cument details the mechanism whereby the data is
transmitted, however, the specific algorithms (precedence, etc) for
util= izing the dual-context metrics is out of scope and not addressed
by this= document.
Same remark as A)

E) 9.11 Resources
The message has no method to be able to tell what resource usage is describ= ed.
>From a consumer of this information this doesn't make sense, since=20 having a 50% memory usage might be quite different from having only 50%=20 battery left.

What should the sender do in case he has many types of resources (very common since any type of modem/router working on=20 battery will have some sort of memory)? Should he take some sort of=20 average. How to weigh 50% battery usage vs 75% memory usage?
I think a less general, more specific approach should be used.
Where=20 one could specify the type of resource left in a field (Battery, memory, disk usage, ...) and the absolute value in another field.
This other fi= eld might be different of type and length depending on the type of resource= .
The DLEP protocol could describe the most common types and their correspond= ing types eg.

Memory (type =3D 0x01), value is unsigned 64 bit in by= tes of memory left
Disk (type =3D 0x02), value is unsigned 64 bit in byt= es of memory left
Battery Life Time (type =3D 0x03), value is unsigned 16 bit in minutes left= (at current usage rate) of battery life time.
Batter usage (type =3D 0x= 04), value is unsigned 8 bit in percent (0-100) of battery left.

A m= ethod has to be invented to let implementers add their own (experimental) t= ypes.

F) 9.13 Status
Non= Zero =3D Failure. Specific values of ...
Isn't it better to at least specify basic error case numbers? Also an=20 optional human readable error could be added so logs might clear up why=20 something happened.

G) 9.17 Credit grant request
with the correct Status TLV.
What is the co= rrect Status TLV (non zero?) Probably same issue as F)


H) 14. Peer Update Message
Concerning Layer 3 addresses, if the modem is capable of=
understanding and forwarding this information (via proprietary
mechanism= s), the address update would prompt any remote DLEP modems
(DLEP-enabled= modems in a remote node) to issue a "Neighbor Update"
message= to their local routers with the new (or deleted) addresses.
Modems that do not track Layer 3 addresses SHOULD silently parse and
ign= ore the Peer Update Message. Modems that track Layer 3 addresses
MUST ac= knowledge the Peer Update with a Peer Update ACK message.
Routers receiv= ing a Peer Update with metric changes MUST apply the
new metric to all neighbors (remote nodes) accessible via the modem.
Sup= porting implementations are free to employ heuristics to
retransmit Peer= Update messages. The sending of Peer Update Messages
for Layer 3 addres= s changes SHOULD cease when a either participant
(router or modem) determines that the other implementation does NOT
supp= ort Layer 3 address tracking.
This is rather a vague p= aragraph with many unspecified items.

Why is it important to detect remote DLEP modems? If a valid u= se case is gven, might it not be a better idea to define a mechanism in DLE= P instead of specifying that a (proprietary) mechanism might be used.
The heuristics for resending peer updates are not defined. Why not define a= sensible set of heuristics in this document?
How can implementations de= tect that the other party doesn't support tracking L3 changes?


4) Some items are optional. For mos= t of those, I don't see a sensible reasoning.
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
A) Timers are an optional feature, = although they seem to me that they are very useful.
Is there any specific reason why are those optional?

B) DLEP Version TLV.
Why is this one optional? If one of the=20 participants decides (because it does not implement it), not to send the version TLV it might leave the other side undecided if they can safely=20 talk to each other.
Also no Version handshake scheme is described so that implementations=20 can choose to send only messages that are version compatible by the=20 other side.

5) Various Comments
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
A) 9.3 Peer Type Message
=A0* Length: 80 Octets maximum. Why is a maximum string length given?
* = The type is defined as a string, but no encoding (ASCII, UTF-8) is given.If allowing UTF-8 (as I think in the modern world we should do) the 80=20 octets might be quite low since might only allow for 40 visible characters= =A0 in Chinese for example (if I am not mistaken)

B) 9.5 IPv4 Address
* Add/Drop
Value indicating whether this is a new or existing IPv4 ad= dress
Part of the sentence seems to be removed, since the descriptio= n of this field is correct for the IPv6 message.
* Really nitpick:
A subnet mask (0-32) to be applied to the IPv4 address.
=A0= (similar for IPv6)
It is not defined what the data type of this field is. Obviously a 8 bit=20 integer value, but signed vs unsigned is not defined. Obviously an=20 unsigned value does not make sense in this case (and is even impossible=20 in the IPv6 case where 127 would be the maximum).

C) 9.8 Current Data Rate
* Contains a TLV Flags =3D 0X10 which is=20 not defined, and is not used anywhere else. I suspect this is a leftover of a previous version.

D) 9.11 Resources & 9.12 Relative link q= uality

If the values are not supported or can not be calculated their value is set to 100, which makes it difficult (if not impossible) to=20 differentiate between the perfect case and the unknown case.

Since t= he used range is only 0-100 and we have 8 bits available we can also use 25= 5 as a unknown case.

E) 9.14 Heartbeat interval
. If an activity timeout is supported, implementations
MAY choo= se to implement heuristics such that signals sent/received
reset the timer window.

What if the sender=20 resets its windows, but the receiver does not imply such heuristics?=20 Then the receiver might time-out and send a peer terminate request.

= I think these heuristics must be required and clearly specified (since they= make sense to reduce the load on the network).

F) 9.18 Credit Request
Length =3D 0. Problem is that the length of t= he package is 1, with a reserved field that must be set to 0.
I think th= is reserved field has to be removed (leftover of a previous version?)

G) 22. Neighbour Update Message
The Neighbour Update doesn't hav= e to seem an ACK message. Is this intentional?

H) 25. Link Character= istics Request ACK Message.
The Link Characteristics ACK message SHOULD contain a complete set
of me= tric data item TLVs. It MUST contain the same TLV types as the
request.<= br>
This seems to be a contradiction. Or it should contain a co= mplete set, or it should contain the same as the request.
Since the request may not contain any metrics=A0 (as to request the current= values) it does make sense to specify
only the first part.

Cheer= s,
Nathan


[1] http://www.ietf.org/rfc/rfc3220.txt
--047d7bea3bc669e21004ced7f438-- From henning.rogge@fkie.fraunhofer.de Tue Nov 20 01:32:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BCD21F845B for ; Tue, 20 Nov 2012 01:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxftyMhkHkZn for ; Tue, 20 Nov 2012 01:32:39 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id AA0F021F883A for ; Tue, 20 Nov 2012 01:32:38 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TakC5-0005r0-HO for manet@ietf.org; Tue, 20 Nov 2012 10:32:37 +0100 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TakC5-0002N4-Ek for manet@ietf.org; Tue, 20 Nov 2012 10:32:37 +0100 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Nov 2012 10:32:37 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 20 Nov 2012 10:32:36 +0100 Message-ID: <50AB4E2D.8080500@fkie.fraunhofer.de> Date: Tue, 20 Nov 2012 10:32:29 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: "manet@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010900020002060101050304" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 20 Nov 2012 09:32:37.0283 (UTC) FILETIME=[FA5BD730:01CDC701] X-Virus-Scanned: yes (ClamAV 0.97.6/15603/Tue Nov 20 03:30:55 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 1e5ed3ddb0980af3ef4e782a5de29073 Subject: [manet] Metric TLVs for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 09:32:39 -0000 --------------ms010900020002060101050304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, as discussed during the IETF, here a few thoughts about additional=20 metric TLVs. I think that including a larger set of metric TLVs (like Relative Link=20 Quality, Current/Maximum Datarate, ...) is a good thing, because it=20 allows radio/router implementors to choose from a larger set of=20 standardized TLVs, which increase the chance of interoperability between = the products. There are two kinds of metric TLVs, one of them contain information=20 about the network the radio is attached to and one of them contain=20 information about the link of the radio to a target. Network specific metric TLVs ---------------------------- * network-id A binary identifier of the network the radio is attached to (1-16 octets = binary) * network-description A text identifier of the network the radio is attached to (1-80 octects=20 ascii) * supported-rates An array of datarates supported by the radio on the current network=20 (array of 8 octet values in bit/s) * last-active Time since the last data was sent or received over the radio (4 octet=20 value in milliseconds) * frequency Mid-Frequency of the current radio channel (8 octet value in Hz) * bandwidth Amount of spectrum a radio channel uses (8 octet value in Hz) Neighbor specific metric TLVs ----------------------------- * maximum-datarate This one already exists in DLEP, but doesn't report both incoming and=20 outgoing maximum link speed, which could be different. * current-datarate Same as maximum datarate, incoming and outgoing speed can be different. * traffic Amount of bytes sent and received with the neighbor (8+8 octet value) * packets Amount of IP packet sent and received with the neighbor (8+8 octet value)= * frames Amount of layer-2 frames sent and received with the neighbor (8+8 octet=20 value) * tx-retries Number of linklayer retransmissions for IP packets (8 octet value) * tx-fails Number of failed linklayer transmissions * last-active Time since the last data was sent or received with this neighbor (4=20 octet value in milliseconds) ---------------------- The traffic and packet TLVs become important when you have multiple=20 routers of hosts attached to a DLEP capable radio, because they cannot=20 track the traffic on their local interface anymore. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms010900020002060101050304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjExMjAwOTMyMzRaMCMGCSqGSIb3DQEJBDEWBBTIjwZCILGAtMlu0HIMx6XuawMYWjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAlDMjgXajQhAeLtaG/PvTvVblPqT4bmCWeJNpa4Wr6T2I c4bf+3JyIXeAbU0ne3jRtKYl3QMQa/ujKz2J6+j8sO0sDaqIhRY3LhY2KQCLbGhQrpYxClCT 0Q4wwwwmcn6LC3IaQcNYW5tI5ju3l7ceqPIh+qKyYHf/Dq/czDyi5zDueUecfLzhCo6GbPlF ykQWibMFUJ3uoQ2+0jBzGSgyfubbCv5VTddo59padj2F1eperdBKGmYQLkqmRBCZAKJeN5ZR JmgX0+LtbH5r0IaQgHkI18zJFLzMVh3EW1sChzrgaIjQszdfABXdNVIqS+Z6ECec4yy5iH0g KGx1iv6zywAAAAAAAA== --------------ms010900020002060101050304-- From henning.rogge@fkie.fraunhofer.de Tue Nov 20 01:51:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F4A21F86F7 for ; Tue, 20 Nov 2012 01:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClY9Zc-g07TT for ; Tue, 20 Nov 2012 01:51:46 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF8221F85A1 for ; Tue, 20 Nov 2012 01:51:46 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TakUb-0004AG-Oc for manet@ietf.org; Tue, 20 Nov 2012 10:51:45 +0100 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TakUb-0002yc-M0 for manet@ietf.org; Tue, 20 Nov 2012 10:51:45 +0100 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Nov 2012 10:51:45 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 20 Nov 2012 10:51:45 +0100 Message-ID: <50AB52AC.2040509@fkie.fraunhofer.de> Date: Tue, 20 Nov 2012 10:51:40 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: References: <50AB4E2D.8080500@fkie.fraunhofer.de> In-Reply-To: <50AB4E2D.8080500@fkie.fraunhofer.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050105010503060900030600" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 20 Nov 2012 09:51:45.0478 (UTC) FILETIME=[A6BC7E60:01CDC704] X-Virus-Scanned: yes (ClamAV 0.97.6/15603/Tue Nov 20 03:30:55 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 0a24b81f0d4341276157346bda7ba1ce Subject: Re: [manet] Metric TLVs for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 09:51:48 -0000 --------------ms050105010503060900030600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 11/20/2012 10:32 AM, Henning Rogge wrote: > Hi, > > as discussed during the IETF, here a few thoughts about additional > metric TLVs. > > I think that including a larger set of metric TLVs (like Relative Link > Quality, Current/Maximum Datarate, ...) is a good thing, because it > allows radio/router implementors to choose from a larger set of > standardized TLVs, which increase the chance of interoperability betwee= n > the products. > > There are two kinds of metric TLVs, one of them contain information > about the network the radio is attached to and one of them contain > information about the link of the radio to a target. > > Network specific metric TLVs > ---------------------------- > > * network-id > > A binary identifier of the network the radio is attached to (1-16 octet= s > binary) > > * network-description > > A text identifier of the network the radio is attached to (1-80 octects= > ascii) > > * supported-rates > > An array of datarates supported by the radio on the current network > (array of 8 octet values in bit/s) > > * last-active > > Time since the last data was sent or received over the radio (4 octet > value in milliseconds) > > * frequency > > Mid-Frequency of the current radio channel (8 octet value in Hz) > > * bandwidth > > Amount of spectrum a radio channel uses (8 octet value in Hz) > > > Neighbor specific metric TLVs > ----------------------------- > > * maximum-datarate > > This one already exists in DLEP, but doesn't report both incoming and > outgoing maximum link speed, which could be different. > > * current-datarate > > Same as maximum datarate, incoming and outgoing speed can be different.= > > * traffic > > Amount of bytes sent and received with the neighbor (8+8 octet value) > > * packets > > Amount of IP packet sent and received with the neighbor (8+8 octet valu= e) > > * frames > > Amount of layer-2 frames sent and received with the neighbor (8+8 octet= > value) > > * tx-retries > > Number of linklayer retransmissions for IP packets (8 octet value) > > * tx-fails > > Number of failed linklayer transmissions > > * last-active > > Time since the last data was sent or received with this neighbor (4 > octet value in milliseconds) I forgot the signal strength for neighbors: * signal-strength Incoming power of the last frame from this neighbor (2 octet value in=20 1/100 dBm) Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms050105010503060900030600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjExMjAwOTUxNDNaMCMGCSqGSIb3DQEJBDEWBBRBPBmF5SKhGwZ2nfd9zDMc/ZvvBTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEADcAyxEiBGIG8MrjVOuS43fAy3/bhXQc7NEnl/ZrKx5Jq U8mWUqXBW/BBK47uFiCqOFMdkGnkqAhALafmwMDo9E9flF6zgG/H65sTz1WRc0Ud0IZq4fI1 TvDdzykW7ZgSGwasp58TuxcRuJhGoUCfBJ0qlt71t/OcPo+GEPjdiFdPEfceNaAs06vUbKc7 3h0WK75cGIeafN+Bj4E2IlhUgra6OmyKYGQVGUdcZCFHiQQoXl01VEVgNgvuHdPvWh2YA+cB zTIvb4bYBiTL8YmfTLrEaIM+c1aeDfeIF/Lgwkqdny+iRWGO7wlXOEFkgzPdYLlkkAn/hZR/ 4qLk9WGlMAAAAAAAAA== --------------ms050105010503060900030600-- From abdussalambaryun@gmail.com Tue Nov 20 06:18:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2271021F84C8 for ; Tue, 20 Nov 2012 06:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaEPr5cegHDr for ; Tue, 20 Nov 2012 06:18:47 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 060EA21F84BB for ; Tue, 20 Nov 2012 06:18:46 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so6922511vbb.31 for ; Tue, 20 Nov 2012 06:18:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TaMKXE787MD4xH1aLlT+2KG0Zsyl2sax782VBsjMbWo=; b=pxgNBTJh9lxYujGiavxBjeEFhVxBxaYEfWhQDLxlEVTgw7W49xz+vNmc7nPH9Vrkf7 kIz/+aprhmKzgwYhzYBxxzLhtwQ6ZiCSG8GKbNz/+FXXUKQBIXD4XzKHp47c0VmeHLWl XcQvhuIVUkla6uut4r4tdV8hBqIqK9v3Re5/txMIxSBlIzPlTTcTiWgzN2dOpueCJF1p CYi2sazmTGZfNfv6z05lNB7Nk3fe/um+dk+CSe6P5j4OWdinbQb83f8xkhPwnILGZSCQ B2KsOCQpBN3hEGPYX77IwiM3nmpONgNrXGbzOxfJDu/7bAOqTIoppIqtjoqaIKVJRuB4 Bqpw== MIME-Version: 1.0 Received: by 10.52.35.82 with SMTP id f18mr18622741vdj.99.1353421126385; Tue, 20 Nov 2012 06:18:46 -0800 (PST) Received: by 10.220.204.9 with HTTP; Tue, 20 Nov 2012 06:18:45 -0800 (PST) In-Reply-To: <50AB4E2D.8080500@fkie.fraunhofer.de> References: <50AB4E2D.8080500@fkie.fraunhofer.de> Date: Tue, 20 Nov 2012 14:18:45 +0000 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=20cf307c9fbe7840ea04ceede972 Cc: "manet@ietf.org" Subject: Re: [manet] Metric TLVs for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 14:18:48 -0000 --20cf307c9fbe7840ea04ceede972 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Henning, I understand the advantages of your proposal. Regarding Mid-frequency and BW, is it better to let it to be defined or not specified in value? I think if we make it fixed to values in Hz we should not ignore the radio links and interface limitations, AB On Tue, Nov 20, 2012 at 9:32 AM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > Hi, > > as discussed during the IETF, here a few thoughts about additional metric > TLVs. > > I think that including a larger set of metric TLVs (like Relative Link > Quality, Current/Maximum Datarate, ...) is a good thing, because it allow= s > radio/router implementors to choose from a larger set of standardized TLV= s, > which increase the chance of interoperability between the products. > > There are two kinds of metric TLVs, one of them contain information about > the network the radio is attached to and one of them contain information > about the link of the radio to a target. > > Network specific metric TLVs > ---------------------------- > > * network-id > > A binary identifier of the network the radio is attached to (1-16 octets > binary) > > * network-description > > A text identifier of the network the radio is attached to (1-80 octects > ascii) > > * supported-rates > > An array of datarates supported by the radio on the current network (arra= y > of 8 octet values in bit/s) > > * last-active > > Time since the last data was sent or received over the radio (4 octet > value in milliseconds) > > * frequency > > Mid-Frequency of the current radio channel (8 octet value in Hz) > > * bandwidth > > Amount of spectrum a radio channel uses (8 octet value in Hz) > > > Neighbor specific metric TLVs > ----------------------------- > > * maximum-datarate > > This one already exists in DLEP, but doesn't report both incoming and > outgoing maximum link speed, which could be different. > > * current-datarate > > Same as maximum datarate, incoming and outgoing speed can be different. > > * traffic > > Amount of bytes sent and received with the neighbor (8+8 octet value) > > * packets > > Amount of IP packet sent and received with the neighbor (8+8 octet value) > > * frames > > Amount of layer-2 frames sent and received with the neighbor (8+8 octet > value) > > * tx-retries > > Number of linklayer retransmissions for IP packets (8 octet value) > > * tx-fails > > Number of failed linklayer transmissions > > * last-active > > Time since the last data was sent or received with this neighbor (4 octet > value in milliseconds) > > ---------------------- > > The traffic and packet TLVs become important when you have multiple > routers of hosts attached to a DLEP capable radio, because they cannot > track the traffic on their local interface anymore. > > > Henning Rogge > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.**fraunhofer.de > http://www.fkie.fraunhofer.de > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --20cf307c9fbe7840ea04ceede972 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Henning,
=A0
I understand=A0the advantages of y= our proposal. Regarding Mid-frequency and BW, is it better to let it to be = defined or=A0not specified in value? I think if we make it fixed to values = in Hz we should not ignore the radio=A0links and interface limitations,
AB
On Tue, Nov 20, 2012 at 9= :32 AM, Henning Rogge <henning.rogge@fkie.fraunhofer.de= > wrote:
Hi,

as discussed during the IETF, here a few thoughts about additional metric T= LVs.

I think that including a larger set of metric TLVs (like Relative Link Qual= ity, Current/Maximum Datarate, ...) is a good thing, because it allows radi= o/router implementors to choose from a larger set of standardized TLVs, whi= ch increase the chance of interoperability between the products.

There are two kinds of metric TLVs, one of them contain information about t= he network the radio is attached to and one of them contain information abo= ut the link of the radio to a target.

Network specific metric TLVs
----------------------------

* network-id

A binary identifier of the network the radio is attached to (1-16 octets bi= nary)

* network-description

A text identifier of the network the radio is attached to (1-80 octects asc= ii)

* supported-rates

An array of datarates supported by the radio on the current network (array = of 8 octet values in bit/s)

* last-active

Time since the last data was sent or received over the radio (4 octet value= in milliseconds)

* frequency

Mid-Frequency of the current radio channel (8 octet value in Hz)

* bandwidth

Amount of spectrum a radio channel uses (8 octet value in Hz)


Neighbor specific metric TLVs
-----------------------------

* maximum-datarate

This one already exists in DLEP, but doesn't report both incoming and o= utgoing maximum link speed, which could be different.

* current-datarate

Same as maximum datarate, incoming and outgoing speed can be different.

* traffic

Amount of bytes sent and received with the neighbor (8+8 octet value)

* packets

Amount of IP packet sent and received with the neighbor (8+8 octet value)
* frames

Amount of layer-2 frames sent and received with the neighbor (8+8 octet val= ue)

* tx-retries

Number of linklayer retransmissions for IP packets (8 octet value)

* tx-fails

Number of failed linklayer transmissions

* last-active

Time since the last data was sent or received with this neighbor (4 octet v= alue in milliseconds)

----------------------

The traffic and packet TLVs become important when you have multiple routers= of hosts attached to a DLEP capable radio, because they cannot track the t= raffic on their local interface anymore.


Henning Rogge
--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--20cf307c9fbe7840ea04ceede972-- From henning.rogge@fkie.fraunhofer.de Tue Nov 20 06:24:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2C821F86CC for ; Tue, 20 Nov 2012 06:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ioqzyqnl4k16 for ; Tue, 20 Nov 2012 06:23:55 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id E1F8521F86E5 for ; Tue, 20 Nov 2012 06:23:42 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Taojl-0002MH-JE; Tue, 20 Nov 2012 15:23:41 +0100 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1Taojl-0003lA-Ga; Tue, 20 Nov 2012 15:23:41 +0100 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Nov 2012 15:23:41 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 20 Nov 2012 15:23:40 +0100 Message-ID: <50AB926B.1030903@fkie.fraunhofer.de> Date: Tue, 20 Nov 2012 15:23:39 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Abdussalam Baryun References: <50AB4E2D.8080500@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080303020800010503020900" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 20 Nov 2012 14:23:41.0382 (UTC) FILETIME=[A3C5DE60:01CDC72A] X-Virus-Scanned: yes (ClamAV 0.97.6/15603/Tue Nov 20 03:30:55 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 324d8966091bca9045707e25a905f109 Cc: "manet@ietf.org" Subject: Re: [manet] Metric TLVs for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 14:24:07 -0000 --------------ms080303020800010503020900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Am 20.11.2012 15:18, schrieb Abdussalam Baryun: > Hi Henning, > > I understand the advantages of your proposal. Regarding Mid-frequency a= nd > BW, is it better to let it to be defined or not specified in value? I t= hink > if we make it fixed to values in Hz we should not ignore the radio link= s > and interface limitations, I am not sure what you want to say about Mid-frequency and bandwidth.=20 Both are values that are measured in Hz, so if the radio want/can supply = these values, what else should it use? Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms080303020800010503020900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Kryptografische Unterschrift MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjExMjAxNDIzMzlaMCMGCSqGSIb3DQEJBDEWBBRx2snW2P9YTTgidklU1gDNK9YN7zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAqRqLocVRtrqNMy55T1t0MolzimEcqlpfN/MLuQvOio8L 7H9KhahXgsQFzuZGdIsfQJmUvY8jpNlc5hSi9t5DeNH1LrgestOq+uCFsxn4nSZCiejwN5Na loZvihjelbsqKnmevgQo3HmFyk5crz8n2K9nk3aMAXV+MmzLBN7UQgy7VmksqsDyEPrF6VOf ToB8F5LoSn+2RfhwmHZlwok1ggJqjlyFOkU0HCTtZ8RNyQh1sWfi+LEDQi1FTrQe1IyZCLPh qtg/Tihj5g+PemwuJ9Es35utWYXtWgsNz+WE9e9DoN4C4L1fHeBFx0EUr16VSfLDXO/+jX56 fEiB9hRdfwAAAAAAAA== --------------ms080303020800010503020900-- From abdussalambaryun@gmail.com Tue Nov 20 07:21:27 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B42821F8770 for ; Tue, 20 Nov 2012 07:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zaeLCNllF2y for ; Tue, 20 Nov 2012 07:21:26 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4DE21F874B for ; Tue, 20 Nov 2012 07:21:26 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id m14so707366yen.31 for ; Tue, 20 Nov 2012 07:21:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dyqqzWLre/iAXozrQcLR82Y/4qJO5zWey2HrqYdrf+c=; b=InnShG9JbPVUjwnaDjFwws9/lmYZkyhufr0mppwQrrm48su4Ql0mgGhHc3Ijfa5BHA KjMmfjdDuI+xaXNgpTCKuPerID3AVI9hbqzMKrY9y5n68AWXKKGLo0QFqhhQoJ+Y5aJA +j/Ntg9i6IbzCvKGmkf8BNKkVQT/P22PVbR70d2XATBkWvq2KBzXG5304mVMg/QHKDER DnJvvGFEbK+FmurC9lJx0YE9+AeKG4cCKtm0gWO/ZWNuUiCsrlG3nBp1WbBjtDydxoAq zQJA5an54L1Ci5FWc7P4YVz32LR+1Latygpy1R7esUSARxk3Dt90OKbAn8KVw1/tW3EN zu/A== MIME-Version: 1.0 Received: by 10.58.243.166 with SMTP id wz6mr22561383vec.28.1353424885724; Tue, 20 Nov 2012 07:21:25 -0800 (PST) Received: by 10.220.204.9 with HTTP; Tue, 20 Nov 2012 07:21:25 -0800 (PST) In-Reply-To: <50AB926B.1030903@fkie.fraunhofer.de> References: <50AB4E2D.8080500@fkie.fraunhofer.de> <50AB926B.1030903@fkie.fraunhofer.de> Date: Tue, 20 Nov 2012 15:21:25 +0000 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7b86f4b28b368704ceeec9dd Cc: "manet@ietf.org" Subject: Re: [manet] Metric TLVs for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 15:21:27 -0000 --047d7b86f4b28b368704ceeec9dd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 20, 2012 at 2:23 PM, Henning Rogge > > > I am not sure what you want to say about Mid-frequency and bandwidth. Bot= h > are values that are measured in Hz, so if the radio want/can supply these > values, what else should it use? > > Yes frequencies are in Hz, but I ment the TLV does not have to specify th= e Hz value it can be defined related to modem used with its limited dynamic link frequencies, AB > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.**fraunhofer.de > http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > --047d7b86f4b28b368704ceeec9dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Nov 20, 2012 at 2:23 PM, Henning= Rogge

I am not sure what you want to say about Mid-frequency and bandwidth. Both = are values that are measured in Hz, so if the radio want/can supply these v= alues, what else should it use?

Yes frequencies are in Hz, but I ment the TLV does not have to specify= the Hz value it can be defined=A0related to modem used=A0with its limited= =A0dynamic link frequencies,
=A0
AB
=A0
=
=A0

Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0


--047d7b86f4b28b368704ceeec9dd-- From hrogge@googlemail.com Tue Nov 20 07:36:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EC921F8692 for ; Tue, 20 Nov 2012 07:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwMdYqEqfnbf for ; Tue, 20 Nov 2012 07:36:30 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E168221F8691 for ; Tue, 20 Nov 2012 07:36:30 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so4336685pbc.31 for ; Tue, 20 Nov 2012 07:36:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DQnN42VRGAU0MgpUBCrsY8L9vU5pedyemPB+ebHTvcs=; b=CZWdexpJgAs/IIBW7vOoaJX7IOrSd1bKt9xS66M4ikruy1ahMn3wpNGim1Q7DzQ+rB DWhwEOJHxeTIb+slnN+K142jwyCmYIfp/u6QIfTDN34KB9lvttqsnV1Nqk8+kzafYS5+ L7cHdzVvCQ1hhigTIdjcD+8bPA1qD76b57eDWDhCiSoEzPc2r1KdWY8My9FELlFyh4tP VnlzbjJJHgjuudof/Y1ZIlRpAA3pZnCXNjRQ4+/NM1blI0ZSijf93PG9iGns7SVG/c1K YD+dhyteeFPJEBYc7o9pUmMVXDosHl85TZbh35JQBDpgdpzQqo/Ps9CMTSUvV8MvHBzh O3bQ== Received: by 10.68.138.198 with SMTP id qs6mr50104604pbb.151.1353425790627; Tue, 20 Nov 2012 07:36:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Tue, 20 Nov 2012 07:36:10 -0800 (PST) In-Reply-To: References: <50AB4E2D.8080500@fkie.fraunhofer.de> <50AB926B.1030903@fkie.fraunhofer.de> From: Henning Rogge Date: Tue, 20 Nov 2012 16:36:10 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Metric TLVs for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 15:36:31 -0000 On Tue, Nov 20, 2012 at 4:21 PM, Abdussalam Baryun wrote: > Yes frequencies are in Hz, but I ment the TLV does not have to specify the > Hz value it can be defined related to modem used with its limited dynamic > link frequencies, " (8 octet value in Hz)" okay, maybe the word "integer" is missing. "8 octet long integer, containing a value measured in Hz" sounds like a good specification. Henning -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Tue Nov 20 10:42:35 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B68E21F877B for ; Tue, 20 Nov 2012 10:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuggNDUsqybw for ; Tue, 20 Nov 2012 10:42:34 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8B821F86D1 for ; Tue, 20 Nov 2012 10:42:34 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so1754689ieb.31 for ; Tue, 20 Nov 2012 10:42:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sXq5NbV5TaHh1LiiYSKXgijeQ3Noqn3icYHZbaoH2W4=; b=fiRhsPh81Eg9mjS1YuF0+vWTeISPB/AemwedSDmgNqtgMNTDCyvvLUkR5g2S9/1O8e o4Sm/XB0TFXny/2JS26qW/fjbTNRUfJuj0F2qpfnIya63GeHhuGNRBypjjs5E7XnS5k8 UqvwEJEjp6FvzK2XwHtr882VScEExWxX35pnm3+F4P0OiAN4FndJ7wznZwRgxecBD/cN Lzedc6Lz/l/lPWEmPqp9mNqz7Px+XvL5XWmbdYvpwIFYgrQ4HYlV3Wvn72Ct4sEFkqPJ K93t1WEOKXYfzdBAYLO5hRAomwU2A8oRO1ngnO9hmJkfesu6W8cjW2Cfo05ZTfHIP6Ya reJA== MIME-Version: 1.0 Received: by 10.42.72.130 with SMTP id o2mr15060060icj.7.1353436953739; Tue, 20 Nov 2012 10:42:33 -0800 (PST) Received: by 10.64.25.46 with HTTP; Tue, 20 Nov 2012 10:42:33 -0800 (PST) In-Reply-To: <50AB4E2D.8080500@fkie.fraunhofer.de> References: <50AB4E2D.8080500@fkie.fraunhofer.de> Date: Tue, 20 Nov 2012 18:42:33 +0000 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=90e6ba6e84f6da80be04cef198ef Cc: "manet@ietf.org" Subject: Re: [manet] Metric TLVs for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 18:42:35 -0000 --90e6ba6e84f6da80be04cef198ef Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Henning, Do you think your proposal can be for the Metric as extension as suggested in the section 5 (that extensions specified in another draft)? AB On Tue, Nov 20, 2012 at 9:32 AM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > Hi, > > as discussed during the IETF, here a few thoughts about additional metric > TLVs. > > I think that including a larger set of metric TLVs (like Relative Link > Quality, Current/Maximum Datarate, ...) is a good thing, because it allow= s > radio/router implementors to choose from a larger set of standardized TLV= s, > which increase the chance of interoperability between the products. > > There are two kinds of metric TLVs, one of them contain information about > the network the radio is attached to and one of them contain information > about the link of the radio to a target. > > Network specific metric TLVs > ---------------------------- > > * network-id > > A binary identifier of the network the radio is attached to (1-16 octets > binary) > > * network-description > > A text identifier of the network the radio is attached to (1-80 octects > ascii) > > * supported-rates > > An array of datarates supported by the radio on the current network (arra= y > of 8 octet values in bit/s) > > * last-active > > Time since the last data was sent or received over the radio (4 octet > value in milliseconds) > > * frequency > > Mid-Frequency of the current radio channel (8 octet value in Hz) > > * bandwidth > > Amount of spectrum a radio channel uses (8 octet value in Hz) > > > Neighbor specific metric TLVs > ----------------------------- > > * maximum-datarate > > This one already exists in DLEP, but doesn't report both incoming and > outgoing maximum link speed, which could be different. > > * current-datarate > > Same as maximum datarate, incoming and outgoing speed can be different. > > * traffic > > Amount of bytes sent and received with the neighbor (8+8 octet value) > > * packets > > Amount of IP packet sent and received with the neighbor (8+8 octet value) > > * frames > > Amount of layer-2 frames sent and received with the neighbor (8+8 octet > value) > > * tx-retries > > Number of linklayer retransmissions for IP packets (8 octet value) > > * tx-fails > > Number of failed linklayer transmissions > > * last-active > > Time since the last data was sent or received with this neighbor (4 octet > value in milliseconds) > > ---------------------- > > The traffic and packet TLVs become important when you have multiple > routers of hosts attached to a DLEP capable radio, because they cannot > track the traffic on their local interface anymore. > > > Henning Rogge > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.**fraunhofer.de > http://www.fkie.fraunhofer.de > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --90e6ba6e84f6da80be04cef198ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Henning,
=A0
Do you think your proposal can be = for the Metric as extension as suggested in the section 5 (that=A0extension= s specified=A0in another draft)?
AB
On Tue, Nov 20, 2012 at 9:32 AM, Henning Rogge <henning.rog= ge@fkie.fraunhofer.de> wrote:
Hi,

as discussed during the IETF, here a few thoughts about additional metric T= LVs.

I think that including a larger set of metric TLVs (like Relative Link Qual= ity, Current/Maximum Datarate, ...) is a good thing, because it allows radi= o/router implementors to choose from a larger set of standardized TLVs, whi= ch increase the chance of interoperability between the products.

There are two kinds of metric TLVs, one of them contain information about t= he network the radio is attached to and one of them contain information abo= ut the link of the radio to a target.

Network specific metric TLVs
----------------------------

* network-id

A binary identifier of the network the radio is attached to (1-16 octets bi= nary)

* network-description

A text identifier of the network the radio is attached to (1-80 octects asc= ii)

* supported-rates

An array of datarates supported by the radio on the current network (array = of 8 octet values in bit/s)

* last-active

Time since the last data was sent or received over the radio (4 octet value= in milliseconds)

* frequency

Mid-Frequency of the current radio channel (8 octet value in Hz)

* bandwidth

Amount of spectrum a radio channel uses (8 octet value in Hz)


Neighbor specific metric TLVs
-----------------------------

* maximum-datarate

This one already exists in DLEP, but doesn't report both incoming and o= utgoing maximum link speed, which could be different.

* current-datarate

Same as maximum datarate, incoming and outgoing speed can be different.

* traffic

Amount of bytes sent and received with the neighbor (8+8 octet value)

* packets

Amount of IP packet sent and received with the neighbor (8+8 octet value)
* frames

Amount of layer-2 frames sent and received with the neighbor (8+8 octet val= ue)

* tx-retries

Number of linklayer retransmissions for IP packets (8 octet value)

* tx-fails

Number of failed linklayer transmissions

* last-active

Time since the last data was sent or received with this neighbor (4 octet v= alue in milliseconds)

----------------------

The traffic and packet TLVs become important when you have multiple routers= of hosts attached to a DLEP capable radio, because they cannot track the t= raffic on their local interface anymore.


Henning Rogge
--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--90e6ba6e84f6da80be04cef198ef-- From rick.taylor@cassidian.com Wed Nov 21 02:39:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D1821F8604 for ; Wed, 21 Nov 2012 02:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KRZ+LEYEhXY for ; Wed, 21 Nov 2012 02:39:58 -0800 (PST) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id D4B5321F85FC for ; Wed, 21 Nov 2012 02:39:56 -0800 (PST) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 21 Nov 2012 11:39:54 +0100 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 21 Nov 2012 11:39:20 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Nov 2012 11:39:14 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Nov 2012 11:39:13 +0100 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Wed, 21 Nov 2012 10:39:14 +0000 From: "Taylor, Rick" To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] Metric TLVs for DLEP Thread-Index: AQHNxwMg4XcZ9XmMtUWIHKviQ59M1pf0GGAg Date: Wed, 21 Nov 2012 10:39:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.114] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Nov 2012 10:39:13.0828 (UTC) FILETIME=[72E5F640:01CDC7D4] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19382.005 X-TM-AS-Result: No--21.365500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] Metric TLVs for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 10:39:59 -0000 Henning, I agree with your separation of 'attached radio' metrics from 'neighbour li= nk' metrics, but I don't see the reason for reporting RF-style metrics, suc= h as channel mid-point. From my understanding DLEP is about reporting link= /modem metrics *of use to a router*. When defining a mandatory set of metrics for DLEP, I would consider it most= appropriate to concentrate on metrics such as Current Data Rate and Latenc= y, leaving RF metrics such as channel midpoint frequency as vendor specific= extensions. >From my experience with radios and DLEP: Most software defined radios suppl= y a debug interface where such RF information can be retrieved, and some ra= dios do not even have a concept of a channel midpoint. Network identifier metrics: I like the idea, but I am not sure what use suc= h metrics provide to an attached router. In conclusion: Separation of Radio/Modem metrics and Link metrics: +1 'RF' metrics, e.g. channel frequency, bandwidth: -1 : Keep the core metrics= to router-relevant metrics. Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Henning Rogge > Sent: 20 November 2012 09:32 > To: manet@ietf.org > Subject: [manet] Metric TLVs for DLEP > > Hi, > > as discussed during the IETF, here a few thoughts about additional > metric TLVs. > > I think that including a larger set of metric TLVs (like Relative Link > Quality, Current/Maximum Datarate, ...) is a good thing, because it > allows radio/router implementors to choose from a larger set of > standardized TLVs, which increase the chance of interoperability between > the products. > > There are two kinds of metric TLVs, one of them contain information > about the network the radio is attached to and one of them contain > information about the link of the radio to a target. > > Network specific metric TLVs > ---------------------------- > > * network-id > > A binary identifier of the network the radio is attached to (1-16 octets > binary) > > * network-description > > A text identifier of the network the radio is attached to (1-80 octects > ascii) > > * supported-rates > > An array of datarates supported by the radio on the current network > (array of 8 octet values in bit/s) > > * last-active > > Time since the last data was sent or received over the radio (4 octet > value in milliseconds) > > * frequency > > Mid-Frequency of the current radio channel (8 octet value in Hz) > > * bandwidth > > Amount of spectrum a radio channel uses (8 octet value in Hz) > > > Neighbor specific metric TLVs > ----------------------------- > > * maximum-datarate > > This one already exists in DLEP, but doesn't report both incoming and > outgoing maximum link speed, which could be different. > > * current-datarate > > Same as maximum datarate, incoming and outgoing speed can be different. > > * traffic > > Amount of bytes sent and received with the neighbor (8+8 octet value) > > * packets > > Amount of IP packet sent and received with the neighbor (8+8 octet value) > > * frames > > Amount of layer-2 frames sent and received with the neighbor (8+8 octet > value) > > * tx-retries > > Number of linklayer retransmissions for IP packets (8 octet value) > > * tx-fails > > Number of failed linklayer transmissions > > * last-active > > Time since the last data was sent or received with this neighbor (4 > octet value in milliseconds) > > ---------------------- > > The traffic and packet TLVs become important when you have multiple > routers of hosts attached to a DLEP capable radio, because they cannot > track the traffic on their local interface anymore. > > > Henning Rogge > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From rick.taylor@cassidian.com Wed Nov 21 02:48:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D63E21F855F for ; Wed, 21 Nov 2012 02:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQuIL+qKJOjF for ; Wed, 21 Nov 2012 02:48:08 -0800 (PST) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7815B21F8611 for ; Wed, 21 Nov 2012 02:48:07 -0800 (PST) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 21 Nov 2012 11:48:06 +0100 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 21 Nov 2012 11:48:12 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Nov 2012 11:48:05 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Nov 2012 11:48:05 +0100 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Wed, 21 Nov 2012 10:48:05 +0000 From: "Taylor, Rick" To: Teco Boot , "Stan Ratliff (sratliff)" Thread-Topic: [manet] DLEP Lite? (Teco Boot) Thread-Index: AQHNw2Lk8St7CxHOQImNx8g7RjcZBJf0IjWw Date: Wed, 21 Nov 2012 10:48:04 +0000 Message-ID: References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com><5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com><56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl><8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459 FDB4EAC9EAD090C0F42FFE2@xmb-aln-x03 .cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F430211@xmb-aln-x03.cisco.com><50FBC4FB-6677-440A-B50A-685DFDD96A46@cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F430886@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F430A1A@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Nov 2012 10:48:05.0040 (UTC) FILETIME=[AF867B00:01CDC7D5] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19382.005 X-TM-AS-Result: No--25.726000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet , "Bo Berry \(boberry\)" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 10:48:09 -0000 Teco, I am just trying to understand your difficulty with 'full-fat' DLEP. Is it= : A) You require unidirectional traffic through your crypto from modem to rad= io. Or, B) You require your radio to sometimes operate in an Rx-only mode. Or is it both? >From my perspective: A) can be solved by placing a device between the crypt= o and the modem that acts as a proxy, rather than a new DLEP-lite protocol. B) Has been covered by Stan I believe: DLEP (as it currently stands) does n= ot define the communication between radios, only between router and radio. = The methods used by radios to forward packets at Layers < 3 is the manufac= turers business, not DLEP's. The only requirement is that two neighbouring= routers shall be able to address packets to each other using the DLEP supp= lied MAC addresses. But I might have missed the thrust of your argument. Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Teco Boot > Sent: 15 November 2012 18:56 > To: Stan Ratliff (sratliff) > Cc: manet; Bo Berry (boberry) > Subject: Re: [manet] DLEP Lite? (Teco Boot) > > > > Op 15 nov. 2012, om 17:26 heeft Stan Ratliff (sratliff) het volgende > geschreven: > > > > > On Nov 15, 2012, at 11:02 AM, Teco Boot wrote: > > > >> > >> Op 15 nov. 2012, om 15:55 heeft Stan Ratliff (sratliff) het volgende > geschreven: > >> > >>> > >>> On Nov 15, 2012, at 1:29 AM, Teco Boot wrote: > >>> > >>>> > >>>> Op 14 nov. 2012, om 20:43 heeft Bo Berry het volgende geschreven: > >>>> > >>>>> > >>>>> On Nov 14, 2012, at 2:26 PM, Stan Ratliff (sratliff) wrote: > >>>>> > >>>>>> > >>>>>> On Nov 14, 2012, at 2:03 PM, Teco Boot wrote: > >>>>>> > >>>>>>> > >>>>>>> Op 14 nov. 2012, om 19:31 heeft Stan Ratliff (sratliff) het > volgende geschreven: > >>>>>>> > >>>>>>>> > >>>>>>>> On Nov 14, 2012, at 10:55 AM, Teco Boot wrote: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Op 14 nov. 2012, om 16:34 heeft Stan Ratliff (sratliff) het > volgende geschreven: > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Nov 14, 2012, at 7:15 AM, Teco Boot wrote: > >>>>>>>>>> > >>>>>>>>>>> Attempt to make thinks clear. > >>>>>>>>>>> > >>>>>>>>>>> Radio is L2 device, could be 802.1D bridge or repeater. Devic= e > is > >>>>>>>>>>> self learning. It has MAC addresses and probably an IP > address. > >>>>>>>>>>> Routers are connected to radio with ethernet or equivalent. > >>>>>>>>>>> Routers have a sub-IP connection with each other via the > ethernet - RF > >>>>>>>>>>> - ethernet sub-IP link. Connection is based on 802.1 MAC > addresses. > >>>>>>>>>>> Radio has the task to deliver router originated frames to > destination, > >>>>>>>>>>> based on destination MAC address. Could be L2 multicast or > broadcast. > >>>>>>>>>>> With DLEP, radios have the task to keep track of link > properties between > >>>>>>>>>>> each connected device. Could be *any* connected ethernet NIC, > as long as > >>>>>>>>>>> it has an 802.1 address and it sends a packet every now and > then. All > >>>>>>>>>>> radios in the sub-IP network automatically learn the existenc= e > of each > >>>>>>>>>>> connected sending node, as required by 802.1D. DLEP shall be > 100% > >>>>>>>>>>> compatible with this widely deployed mechanism. It shall > provide link > >>>>>>>>>>> metrics for far end connected MAC addresses to locally > connected nodes. > >>>>>>>>>>> It shall work this way for single- and multi-hop sub-IP > networks. > >>>>>>>>>> > >>>>>>>>>> I think we're talking past each other. DLEP has not assumed > 802.1D support in the radios, so all of your "shall" verbiage doesn't mak= e > sense. The only assumption DLEP makes (at least as of now) is that the > radios operate in transparent bridge mode - that the destination MAC is > that of the far-end router, not any of the intervening devices. > >>>>>>>>> As is in 802.1D. > >>>>>>>>> > >>>>>>>>>> And without some flows from router *to* radio, your "one-way > only" communication mode doesn't work, because you can't correlate a > router to it's attached RF device. > >>>>>>>>> It is the RF device that is locally connected. Not the far end > RF device. Cannot be mistaken, can it? > >>>>>>>> > >>>>>>>> Yes, it can. Given 3 radio/router pairs, each in the "one-way" > mode, what MAC address is in the Neighbor Up? > >>>>>>> > >>>>>>> The far end router. It doesn't need to be DLEP enabled. Could be = a > host also, like a laptop for testing. > >>>>>> > >>>>>> And how does the radio (far-end radio) learn of the MAC address? > >>>> > >>>> @Stan: > >>>> Assume frames have 4 MAC addresses: SA, DA, TA and RA. > >>>> SA: Source Address, sending router > >>>> DA: Destination Address, receiving router (far end radio sends frame > to locally attached router) > >>>> TA: Transmitter Address, radio ID of RF link, sending radio > >>>> RA: Receiver Address, radio ID on RF link, receiving radio > >>>> > >>>> I am aware of radio's that reuse the SA/DA for TA/RA, so they do not > need the 4-address mode. This has some limitations, in that radio support= s > only one node (although there could be a work-around). The more enhanced > radios use the 4 address mode. > >>>> > >>>> Now your question: radio inspects the frame header, to find out what > to do with it. Highly simplified: Is RA its own address? No, then discard= . > It could update link metrics for TA and all SA behind TA, no reason to > ignore available info. For frames for that radio, it refresh forwarding > tables: SA is behind TA, this info is required for return frames. Frame i= s > converted or decapsulated and forwarded to DA, could be flooding if > unknown outgoing port was unknown. > >>>> > >>>> Side node: when RA !=3D own address, radio could update bridge > forwarding table, and relate SA and TA. > >>> > >>> And if the router, for whatever reason or reasons might be > appropriate, simply hasn't emitted any frames toward the radio? > >> > >> Then far-end nodes are not aware the router exists. In my environment, > radio silence is a normal mode of operation. > >> > > > > I'm not talking about radio silence. Just a router that hasn't emitted > any frames. > > OK, I just mentioned I have to deal with silent radios. I guess I am not > the only one here. > > > So back to my original comment - this suggestion is making assumptions. > > Yes, in that standard protocols are being used. Not a bad assumption, I > think. > If your DLEP proposal is not built on standards, I prefer staying far awa= y > from it. > > > It assumes that the radio is snooping/cacheing MAC addresses, > > Yes. It is specified in dlep-03, page 8: > DLEP assumes that participating modems, and their physical links, act > as a transparent bridge. > I am not aware of transparent bridges that do not act the way I describe. > > > and it assumes that the router is forwarding frames to the radio prior > to any "Neighbor Up" event. I do not believe that DLEP should be making > such assumptions. > > Are you kidding in that a router does not send packets on an interface, > where the routing protocol is enabled? > (leaving PPPoE / VMI out of scope here) > > Teco > > > > > > Stan > > > > > >> Teco > >> > >>> > >>> > >>>> > >>>>> > >>>>> > >>>>> A picture my help (me for atleast as I try to follow). Two > different networks below. > >>>>> > >>>>> A) > >>>>> [ DLEP Enabled] [ DLEP Enabled] > >>>>> [ radio~router]~~~~~~~[ radio|router] > >>>>> > >>>>> B) > >>>>> [ DLEP Enabled] [ integrated] > >>>>> [ radio~router]~~~~~~~[ radio|host] > >>>> > >>>> There are more scenario's: > >>>> > >>>> C) > >>>> [ DLEP Enabled] [ DLEP Disabled] > >>>> [ radio~router]~~~~~~~[ radio|router ] > >>>> > >>>> D) > >>>> [ DLEP Enabled] > >>>> [ DLEP Enabled] [ integrated] > >>>> [ radio~router]~~~~~~~[ radio|host] > >>>> > >>>> All should work. > >>>> > >>>>> > >>>>> The [integrated radio|host] shares MAC/IP address information via a > driver, not DLEP. > >>>> What is "shares MAC/IP address"? > >>>> With 4 address mode, SA and TA would be same MAC address. > >>>> > >>>>> In configuration (B) the DLEP Enabled radio must obtain the host MA= C > address to drive DLEP. How the DLEP Enabled radio obtains the host MAC i= s > really a function of the DLEP Enabled radio. Once obtained, the DLEP > Enabled radio generates a Neighbor Up and can report metrics associated > with the host MAC. The DLEP Enabled router uses the host MAC in the DLEP > messages to adjust/influence routing. > >>>> > >>>> Agreed in that the DLEP specification shall not assume both sides of > link have DLEP enabled, such as with (B) and (C)? > >>>> > >>>> Teco > >>>> > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> BTW, I would just send the metric costs. Neighbor up is implicit. > Due to RF, signals fade away, Neighbor down is artificial (or result of a > disconnect). > >>>>>>> > >>>>>>> Teco > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> And I'm not OK with *requiring* that level of functionality in > the radio. > >>>>>>>>> I didn't read anything here that didn't match 802.1D. > >>>>>>>>> > >>>>>>>>> Teco > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Stan > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Teco > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het volgend= e > geschreven: > >>>>>>>>>>> > >>>>>>>>>>>> I mean I understand from discussions that Stan's reply to > Teco that he does not beleive to use bridge mode, > >>>>>>>>>>>> > >>>>>>>>>>>> AB > >>>>>>>>>>>> > >>>>>>>>>>>> On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge > wrote: > >>>>>>>>>>>> On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> Because there was no "radio-to-MAC" correlation, > >>>>>>>>>>>>> > >>>>>>>>>>>>> IMO, correlation concept not understood, but understand tha= t > we don't need > >>>>>>>>>>>>> bridge mode. However, still waiting for the respond to Teco > question, > >>>>>>>>>>>> > >>>>>>>>>>>> What do you mean with "we don't need bridge mode" ? > >>>>>>>>>>>> > >>>>>>>>>>>> Henning Rogge > >>>>>>>>>>>> -- > >>>>>>>>>>>> Steven Hawkings about cosmic inflation: "An increase of > billions of > >>>>>>>>>>>> billions of percent in a tiny fraction of a second. Of > course, that > >>>>>>>>>>>> was before the present government." > >>>>>>>>>>>> > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> manet mailing list > >>>>>>>>>>>> manet@ietf.org > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> manet mailing list > >>>>>>>>>>> manet@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> manet mailing list > >>>>>> manet@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/manet > >>>>> > >>>> > >>> > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From rick.taylor@cassidian.com Wed Nov 21 03:04:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE8021F8586 for ; Wed, 21 Nov 2012 03:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08A7E3LkMJxa for ; Wed, 21 Nov 2012 03:04:32 -0800 (PST) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id A0D0A21F8576 for ; Wed, 21 Nov 2012 03:04:30 -0800 (PST) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 21 Nov 2012 12:04:29 +0100 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 21 Nov 2012 12:04:35 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Nov 2012 12:04:28 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Nov 2012 12:04:28 +0100 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Wed, 21 Nov 2012 11:04:28 +0000 From: "Taylor, Rick" To: "manet@ietf.org" Thread-Topic: [manet] DLEP Hop-count metrics TLV Thread-Index: AQHNx9f5oloGbHqdMU+KjNI+KSJM7A== Date: Wed, 21 Nov 2012 11:04:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Nov 2012 11:04:28.0153 (UTC) FILETIME=[F9819E90:01CDC7D7] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19382.006 X-TM-AS-Result: No--6.167700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] DLEP Hop-count metrics TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 11:04:33 -0000 I have raised this before, but failed to explain it clearly, so I'll try ag= ain: With meshed radio networks, such as 802.11s, the definition of a DLEP neigh= bour is not clear in relation to the current draft. Does a 'Neighbour' refer to: A) a radio attached to the network that direct= ly receives packets from the sending radio, or is it B) any radio that can = receive packets *even if they are passed via other radios within the mesh*? If the answer is A) then the draft needs to be updated to reflect this, and= I imagine many people will object to this definition as being too strict. If the answer is B) then there must be some way for the radio to report how= many lower-layer hops are involved between the sender and the neighbour. = My proposal would be to add a hop-count metric TLV to the link metric set. = This will allow the mesh to alter its topology and inform connected router= s via a Neighbour_Update. There might be an argument, if the definition is B), to add a 'Path' or 'Vi= a' metric that describes the (Layer < 3) path between source and neighbour,= but it is currently unclear to me how this might be encoded within a TLV o= f reasonable length for a big mesh. Please do not confuse my proposal with any particular routing protocol hop-= count, it is unrelated. Rick Taylor The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From Chris.Dearlove@baesystems.com Wed Nov 21 03:55:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6081021F8610 for ; Wed, 21 Nov 2012 03:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.261 X-Spam-Level: X-Spam-Status: No, score=-10.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C40ig4aqxvrp for ; Wed, 21 Nov 2012 03:55:55 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 99B5D21F84CA for ; Wed, 21 Nov 2012 03:55:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,293,1352073600"; d="scan'208";a="244419235" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 21 Nov 2012 11:55:40 +0000 Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qALBtdGi016018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Nov 2012 11:55:39 GMT Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Wed, 21 Nov 2012 11:55:38 +0000 From: "Dearlove, Christopher (UK)" To: "Taylor, Rick" , Teco Boot , "Stan Ratliff (sratliff)" Thread-Topic: [manet] DLEP Lite? (Teco Boot) Thread-Index: AQHNw2Lk8St7CxHOQImNx8g7RjcZBJf0IjWwgAAT7MA= Date: Wed, 21 Nov 2012 11:55:38 +0000 Message-ID: References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com><5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com><56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl><8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459 FDB4EAC9EAD090C0F42FFE2@xmb-aln-x03 .cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F430211@xmb-aln-x03.cisco.com><50FBC4FB-6677-440A-B50A-685DFDD96A46@cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F430886@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F430A1A@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , "Bo Berry \(boberry\)" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 11:55:57 -0000 Do you mean through your crypto from modem to radio? I thought we were disc= ussing a crypto between radio/modem and router? --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of T= aylor, Rick Sent: 21 November 2012 10:48 To: Teco Boot; Stan Ratliff (sratliff) Cc: manet; Bo Berry (boberry) Subject: Re: [manet] DLEP Lite? (Teco Boot) ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Teco, I am just trying to understand your difficulty with 'full-fat' DLEP. Is it= : A) You require unidirectional traffic through your crypto from modem to rad= io. Or, B) You require your radio to sometimes operate in an Rx-only mode. Or is it both? >From my perspective: A) can be solved by placing a device between the crypt= o and the modem that acts as a proxy, rather than a new DLEP-lite protocol. B) Has been covered by Stan I believe: DLEP (as it currently stands) does n= ot define the communication between radios, only between router and radio. = The methods used by radios to forward packets at Layers < 3 is the manufac= turers business, not DLEP's. The only requirement is that two neighbouring= routers shall be able to address packets to each other using the DLEP supp= lied MAC addresses. But I might have missed the thrust of your argument. Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Teco Boot > Sent: 15 November 2012 18:56 > To: Stan Ratliff (sratliff) > Cc: manet; Bo Berry (boberry) > Subject: Re: [manet] DLEP Lite? (Teco Boot) > > > > Op 15 nov. 2012, om 17:26 heeft Stan Ratliff (sratliff) het volgende > geschreven: > > > > > On Nov 15, 2012, at 11:02 AM, Teco Boot wrote: > > > >> > >> Op 15 nov. 2012, om 15:55 heeft Stan Ratliff (sratliff) het volgende > geschreven: > >> > >>> > >>> On Nov 15, 2012, at 1:29 AM, Teco Boot wrote: > >>> > >>>> > >>>> Op 14 nov. 2012, om 20:43 heeft Bo Berry het volgende geschreven: > >>>> > >>>>> > >>>>> On Nov 14, 2012, at 2:26 PM, Stan Ratliff (sratliff) wrote: > >>>>> > >>>>>> > >>>>>> On Nov 14, 2012, at 2:03 PM, Teco Boot wrote: > >>>>>> > >>>>>>> > >>>>>>> Op 14 nov. 2012, om 19:31 heeft Stan Ratliff (sratliff) het > volgende geschreven: > >>>>>>> > >>>>>>>> > >>>>>>>> On Nov 14, 2012, at 10:55 AM, Teco Boot wrote: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Op 14 nov. 2012, om 16:34 heeft Stan Ratliff (sratliff) het > volgende geschreven: > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Nov 14, 2012, at 7:15 AM, Teco Boot wrote: > >>>>>>>>>> > >>>>>>>>>>> Attempt to make thinks clear. > >>>>>>>>>>> > >>>>>>>>>>> Radio is L2 device, could be 802.1D bridge or repeater. Devic= e > is > >>>>>>>>>>> self learning. It has MAC addresses and probably an IP > address. > >>>>>>>>>>> Routers are connected to radio with ethernet or equivalent. > >>>>>>>>>>> Routers have a sub-IP connection with each other via the > ethernet - RF > >>>>>>>>>>> - ethernet sub-IP link. Connection is based on 802.1 MAC > addresses. > >>>>>>>>>>> Radio has the task to deliver router originated frames to > destination, > >>>>>>>>>>> based on destination MAC address. Could be L2 multicast or > broadcast. > >>>>>>>>>>> With DLEP, radios have the task to keep track of link > properties between > >>>>>>>>>>> each connected device. Could be *any* connected ethernet NIC, > as long as > >>>>>>>>>>> it has an 802.1 address and it sends a packet every now and > then. All > >>>>>>>>>>> radios in the sub-IP network automatically learn the existenc= e > of each > >>>>>>>>>>> connected sending node, as required by 802.1D. DLEP shall be > 100% > >>>>>>>>>>> compatible with this widely deployed mechanism. It shall > provide link > >>>>>>>>>>> metrics for far end connected MAC addresses to locally > connected nodes. > >>>>>>>>>>> It shall work this way for single- and multi-hop sub-IP > networks. > >>>>>>>>>> > >>>>>>>>>> I think we're talking past each other. DLEP has not assumed > 802.1D support in the radios, so all of your "shall" verbiage doesn't mak= e > sense. The only assumption DLEP makes (at least as of now) is that the > radios operate in transparent bridge mode - that the destination MAC is > that of the far-end router, not any of the intervening devices. > >>>>>>>>> As is in 802.1D. > >>>>>>>>> > >>>>>>>>>> And without some flows from router *to* radio, your "one-way > only" communication mode doesn't work, because you can't correlate a > router to it's attached RF device. > >>>>>>>>> It is the RF device that is locally connected. Not the far end > RF device. Cannot be mistaken, can it? > >>>>>>>> > >>>>>>>> Yes, it can. Given 3 radio/router pairs, each in the "one-way" > mode, what MAC address is in the Neighbor Up? > >>>>>>> > >>>>>>> The far end router. It doesn't need to be DLEP enabled. Could be = a > host also, like a laptop for testing. > >>>>>> > >>>>>> And how does the radio (far-end radio) learn of the MAC address? > >>>> > >>>> @Stan: > >>>> Assume frames have 4 MAC addresses: SA, DA, TA and RA. > >>>> SA: Source Address, sending router > >>>> DA: Destination Address, receiving router (far end radio sends frame > to locally attached router) > >>>> TA: Transmitter Address, radio ID of RF link, sending radio > >>>> RA: Receiver Address, radio ID on RF link, receiving radio > >>>> > >>>> I am aware of radio's that reuse the SA/DA for TA/RA, so they do not > need the 4-address mode. This has some limitations, in that radio support= s > only one node (although there could be a work-around). The more enhanced > radios use the 4 address mode. > >>>> > >>>> Now your question: radio inspects the frame header, to find out what > to do with it. Highly simplified: Is RA its own address? No, then discard= . > It could update link metrics for TA and all SA behind TA, no reason to > ignore available info. For frames for that radio, it refresh forwarding > tables: SA is behind TA, this info is required for return frames. Frame i= s > converted or decapsulated and forwarded to DA, could be flooding if > unknown outgoing port was unknown. > >>>> > >>>> Side node: when RA !=3D own address, radio could update bridge > forwarding table, and relate SA and TA. > >>> > >>> And if the router, for whatever reason or reasons might be > appropriate, simply hasn't emitted any frames toward the radio? > >> > >> Then far-end nodes are not aware the router exists. In my environment, > radio silence is a normal mode of operation. > >> > > > > I'm not talking about radio silence. Just a router that hasn't emitted > any frames. > > OK, I just mentioned I have to deal with silent radios. I guess I am not > the only one here. > > > So back to my original comment - this suggestion is making assumptions. > > Yes, in that standard protocols are being used. Not a bad assumption, I > think. > If your DLEP proposal is not built on standards, I prefer staying far awa= y > from it. > > > It assumes that the radio is snooping/cacheing MAC addresses, > > Yes. It is specified in dlep-03, page 8: > DLEP assumes that participating modems, and their physical links, act > as a transparent bridge. > I am not aware of transparent bridges that do not act the way I describe. > > > and it assumes that the router is forwarding frames to the radio prior > to any "Neighbor Up" event. I do not believe that DLEP should be making > such assumptions. > > Are you kidding in that a router does not send packets on an interface, > where the routing protocol is enabled? > (leaving PPPoE / VMI out of scope here) > > Teco > > > > > > Stan > > > > > >> Teco > >> > >>> > >>> > >>>> > >>>>> > >>>>> > >>>>> A picture my help (me for atleast as I try to follow). Two > different networks below. > >>>>> > >>>>> A) > >>>>> [ DLEP Enabled] [ DLEP Enabled] > >>>>> [ radio~router]~~~~~~~[ radio|router] > >>>>> > >>>>> B) > >>>>> [ DLEP Enabled] [ integrated] > >>>>> [ radio~router]~~~~~~~[ radio|host] > >>>> > >>>> There are more scenario's: > >>>> > >>>> C) > >>>> [ DLEP Enabled] [ DLEP Disabled] > >>>> [ radio~router]~~~~~~~[ radio|router ] > >>>> > >>>> D) > >>>> [ DLEP Enabled] > >>>> [ DLEP Enabled] [ integrated] > >>>> [ radio~router]~~~~~~~[ radio|host] > >>>> > >>>> All should work. > >>>> > >>>>> > >>>>> The [integrated radio|host] shares MAC/IP address information via a > driver, not DLEP. > >>>> What is "shares MAC/IP address"? > >>>> With 4 address mode, SA and TA would be same MAC address. > >>>> > >>>>> In configuration (B) the DLEP Enabled radio must obtain the host MA= C > address to drive DLEP. How the DLEP Enabled radio obtains the host MAC i= s > really a function of the DLEP Enabled radio. Once obtained, the DLEP > Enabled radio generates a Neighbor Up and can report metrics associated > with the host MAC. The DLEP Enabled router uses the host MAC in the DLEP > messages to adjust/influence routing. > >>>> > >>>> Agreed in that the DLEP specification shall not assume both sides of > link have DLEP enabled, such as with (B) and (C)? > >>>> > >>>> Teco > >>>> > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> BTW, I would just send the metric costs. Neighbor up is implicit. > Due to RF, signals fade away, Neighbor down is artificial (or result of a > disconnect). > >>>>>>> > >>>>>>> Teco > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> And I'm not OK with *requiring* that level of functionality in > the radio. > >>>>>>>>> I didn't read anything here that didn't match 802.1D. > >>>>>>>>> > >>>>>>>>> Teco > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Stan > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Teco > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het volgend= e > geschreven: > >>>>>>>>>>> > >>>>>>>>>>>> I mean I understand from discussions that Stan's reply to > Teco that he does not beleive to use bridge mode, > >>>>>>>>>>>> > >>>>>>>>>>>> AB > >>>>>>>>>>>> > >>>>>>>>>>>> On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge > wrote: > >>>>>>>>>>>> On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> Because there was no "radio-to-MAC" correlation, > >>>>>>>>>>>>> > >>>>>>>>>>>>> IMO, correlation concept not understood, but understand tha= t > we don't need > >>>>>>>>>>>>> bridge mode. However, still waiting for the respond to Teco > question, > >>>>>>>>>>>> > >>>>>>>>>>>> What do you mean with "we don't need bridge mode" ? > >>>>>>>>>>>> > >>>>>>>>>>>> Henning Rogge > >>>>>>>>>>>> -- > >>>>>>>>>>>> Steven Hawkings about cosmic inflation: "An increase of > billions of > >>>>>>>>>>>> billions of percent in a tiny fraction of a second. Of > course, that > >>>>>>>>>>>> was before the present government." > >>>>>>>>>>>> > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> manet mailing list > >>>>>>>>>>>> manet@ietf.org > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> manet mailing list > >>>>>>>>>>> manet@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> manet mailing list > >>>>>> manet@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/manet > >>>>> > >>>> > >>> > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com _______________________________________________ manet mailing list manet@ietf.org 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@fkie.fraunhofer.de Wed Nov 21 04:08:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7C621F84DC for ; Wed, 21 Nov 2012 04:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pv35AkcH2pWd for ; Wed, 21 Nov 2012 04:08:17 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 6320821F84DD for ; Wed, 21 Nov 2012 04:08:16 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tb969-0001wI-KC; Wed, 21 Nov 2012 13:08:09 +0100 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1Tb969-0006VL-HY; Wed, 21 Nov 2012 13:08:09 +0100 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Nov 2012 13:08:09 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 21 Nov 2012 13:08:09 +0100 Message-ID: <50ACC423.4000305@fkie.fraunhofer.de> Date: Wed, 21 Nov 2012 13:08:03 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Taylor, Rick" References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080005090204060305020602" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 21 Nov 2012 12:08:09.0370 (UTC) FILETIME=[DF210FA0:01CDC7E0] X-Virus-Scanned: yes (ClamAV 0.97.6/15608/Wed Nov 21 04:53:48 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: ab3a174db55cc7687c315337a34e1612 Cc: "manet@ietf.org" Subject: Re: [manet] Metric TLVs for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 12:08:23 -0000 --------------ms080005090204060305020602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Am 21.11.2012 11:39, schrieb Taylor, Rick: > Henning, > > I agree with your separation of 'attached radio' metrics from > 'neighbour link' metrics, but I don't see the reason for reporting > RF-style metrics, such as channel mid-point. From my understanding > DLEP is about reporting link/modem metrics *of use to a router*. > > When defining a mandatory set of metrics for DLEP, I would consider > it most appropriate to concentrate on metrics such as Current Data > Rate and Latency, leaving RF metrics such as channel midpoint > frequency as vendor specific extensions. > > From my experience with radios and DLEP: Most software defined radios > supply a debug interface where such RF information can be retrieved, > and some radios do not even have a concept of a channel midpoint. Debug interfaces are not really useful, because they are device (and=20 sometimes even firmware-release) specific. The channel midpoint might not make sense for radios in frequency=20 hopping mode. The bandwidth of a channel tells the router something about the=20 'spectral effiency'. If you have two radio channels, both without packet loss and both with a = link-speed of 10 MBit/s, both seem to be similar to the router. But if you know that one of them is 10 MHz wide and one of them 40 MHz=20 wide, its might be better to take the 10 MHz wide one. > Network identifier metrics: I like the idea, but I am not sure what > use such metrics provide to an attached router. Its more a help to the autodiscovery part of DLEP, because it allows the = Router to present the user with a short information what the new radio=20 is attached to. > In conclusion: > > Separation of Radio/Modem metrics and Link metrics: +1 > > 'RF' metrics, e.g. channel frequency, bandwidth: -1 : Keep the core > metrics to router-relevant metrics. MIC-metric is one example of a "collision domain aware" metric for MANET = that use the frequency of a link to decide if it will interfere with=20 other links or not. Parameters like frequency and bandwith are relevant for MANET routing=20 metrics. If the radio knows them, we should provide ways to deliver them = to the router. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms080005090204060305020602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Kryptografische Unterschrift MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjExMjExMjA4MDdaMCMGCSqGSIb3DQEJBDEWBBTN2VEVJkNYDxw8rcXMA/VODsEMxjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAin2CUkPUTj6Vw+fnWLFUQePuFj6Zaz0Urr749RdCPD9+ OoLcaNXMMJSu9VLlQLxi1Cfg5Jsu3M2+lbLUquCoQ4z1Xf4OQwBEye8/Ppnt+F5MbClk1IL2 5mcKGDvfV0qw+uCfJSAamLSnmP1sMIcqaLGtS1LVlBFdOjk8zSQVwglP8uIJ612Stux1g9Cm aB1cTuEXwjOQXDhtIChIdUhN4EexdQo0GCqoTajxUnqvSuKYdh9fCUpN7QQr9JJtUpHEj0mn piqqTPgecjS12TCmh5/wy8vS6d9KfI6MNwJRJLZ9GFs/tjIWGhDF+4obM10toKlbPwkOTsDT 9KbEPCvb8QAAAAAAAA== --------------ms080005090204060305020602-- From teco@inf-net.nl Wed Nov 21 04:25:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB2821F855B for ; Wed, 21 Nov 2012 04:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEiMDw9yP4t6 for ; Wed, 21 Nov 2012 04:25:35 -0800 (PST) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7C121F8557 for ; Wed, 21 Nov 2012 04:25:34 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq7so3040810wib.1 for ; Wed, 21 Nov 2012 04:25:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=9/RMdV7/dcLTOU7aCI9RTud2eqArdEDjp+t3D0Wkv8U=; b=UR3h4k76RaEesUublO1XSEfZkJht9oHwFUkKldp0bGI2i+9C5pcVbK7i8O6uvK4clH wNCezyPiTZedVgqGQdb89q26OiaaXmLLItm3QTvZz73pD2wMcprwlU8QAYMJUDKKKJFN mjFeQGEd/0N6qWrgwVEfIc4hFqY0ZmBlOWuDAp4VR505SJr4C0Kdy57zbKfIa6F4YrwP AygJfbegYmMZQ8PSrJn0D8m4tRVWEJGo8xOR/uZbeGLyuoOHm8nrBj/Y4rAJda/0Ljpn tAHWlwO7kmDr6keNTXFmB72/XXWPJXoS6gEydwmQgf/ZjzPDIE8L/FbuqrOVFvElrsv8 hZbQ== Received: by 10.180.7.197 with SMTP id l5mr19486560wia.13.1353500733875; Wed, 21 Nov 2012 04:25:33 -0800 (PST) Received: from [172.16.4.198] ([188.205.88.52]) by mx.google.com with ESMTPS id y3sm20875469wix.6.2012.11.21.04.25.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Nov 2012 04:25:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Wed, 21 Nov 2012 13:25:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com><5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com><56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl><8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459 FDB4EAC9EAD090C 0F42FFE2@xmb-aln-x03 .cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F430211@xmb-aln-x03.cisco.com><50FBC4FB-6677-440A-B50A-685DFDD96A46@cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F430886@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F430A1A@xmb-aln-x03.cisco.com> To: "Taylor, Rick" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQltivz0WqEDt47GwgwAuQSi1AxUWjxW/9OVsAuVYC0elnSa1bKVz+GMrRDmwyEFEwGfSpLM Cc: manet , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 12:25:37 -0000 Op 21 nov. 2012, om 11:48 heeft Taylor, Rick het volgende geschreven: > Teco, >=20 > I am just trying to understand your difficulty with 'full-fat' DLEP. = Is it: >=20 > A) You require unidirectional traffic through your crypto from modem = to radio. >=20 > Or, >=20 > B) You require your radio to sometimes operate in an Rx-only mode. >=20 > Or is it both? I have to deal with A. Not all my radio's have crypto on board, the = devices are "black". I use "grey" routers. These are part of my = protected network. I use firewall rules, that blocks *all* non-crypted = outgoing packets on router interfaces (OK, I permit ARP/ND and required = ICMP stuff). I can connect whatever radio on my router port, and use it = with VPN tunnels. I have also crypto between grey and red. With a data = diode.=20 I could use red routers, and connect radio's on black interface of my = crypto. This is not what I use today. I have to deal with B also. This is slightly related to DLEP. Not = important here. >=20 > =46rom my perspective: A) can be solved by placing a device between = the crypto and the modem that acts as a proxy, rather than a new = DLEP-lite protocol. I have some SWaP requirements. I cannot add devices. >=20 > B) Has been covered by Stan I believe: DLEP (as it currently stands) = does not define the communication between radios, only between router = and radio. The methods used by radios to forward packets at Layers < 3 = is the manufacturers business, not DLEP's. =20 Yes. Although I like standards here.=20 > The only requirement is that two neighbouring routers shall be able to = address packets to each other using the DLEP supplied MAC addresses. Strongly disagreed. Current DLEP-03 assumes transparent bridging. Me = too. >=20 > But I might have missed the thrust of your argument. My main point: if the routers are simply cross-connected, shall it work? = It has to be. DLEP shall optimize routing and shall not introduce = dependencies. Teco >=20 > Rick Taylor >=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of >> Teco Boot >> Sent: 15 November 2012 18:56 >> To: Stan Ratliff (sratliff) >> Cc: manet; Bo Berry (boberry) >> Subject: Re: [manet] DLEP Lite? (Teco Boot) >>=20 >>=20 >>=20 >> Op 15 nov. 2012, om 17:26 heeft Stan Ratliff (sratliff) het volgende >> geschreven: >>=20 >>>=20 >>> On Nov 15, 2012, at 11:02 AM, Teco Boot wrote: >>>=20 >>>>=20 >>>> Op 15 nov. 2012, om 15:55 heeft Stan Ratliff (sratliff) het = volgende >> geschreven: >>>>=20 >>>>>=20 >>>>> On Nov 15, 2012, at 1:29 AM, Teco Boot wrote: >>>>>=20 >>>>>>=20 >>>>>> Op 14 nov. 2012, om 20:43 heeft Bo Berry het volgende geschreven: >>>>>>=20 >>>>>>>=20 >>>>>>> On Nov 14, 2012, at 2:26 PM, Stan Ratliff (sratliff) wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Nov 14, 2012, at 2:03 PM, Teco Boot wrote: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Op 14 nov. 2012, om 19:31 heeft Stan Ratliff (sratliff) het >> volgende geschreven: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Nov 14, 2012, at 10:55 AM, Teco Boot wrote: >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Op 14 nov. 2012, om 16:34 heeft Stan Ratliff (sratliff) het >> volgende geschreven: >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On Nov 14, 2012, at 7:15 AM, Teco Boot wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Attempt to make thinks clear. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Radio is L2 device, could be 802.1D bridge or repeater. = Device >> is >>>>>>>>>>>>> self learning. It has MAC addresses and probably an IP >> address. >>>>>>>>>>>>> Routers are connected to radio with ethernet or = equivalent. >>>>>>>>>>>>> Routers have a sub-IP connection with each other via the >> ethernet - RF >>>>>>>>>>>>> - ethernet sub-IP link. Connection is based on 802.1 MAC >> addresses. >>>>>>>>>>>>> Radio has the task to deliver router originated frames to >> destination, >>>>>>>>>>>>> based on destination MAC address. Could be L2 multicast or >> broadcast. >>>>>>>>>>>>> With DLEP, radios have the task to keep track of link >> properties between >>>>>>>>>>>>> each connected device. Could be *any* connected ethernet = NIC, >> as long as >>>>>>>>>>>>> it has an 802.1 address and it sends a packet every now = and >> then. All >>>>>>>>>>>>> radios in the sub-IP network automatically learn the = existence >> of each >>>>>>>>>>>>> connected sending node, as required by 802.1D. DLEP shall = be >> 100% >>>>>>>>>>>>> compatible with this widely deployed mechanism. It shall >> provide link >>>>>>>>>>>>> metrics for far end connected MAC addresses to locally >> connected nodes. >>>>>>>>>>>>> It shall work this way for single- and multi-hop sub-IP >> networks. >>>>>>>>>>>>=20 >>>>>>>>>>>> I think we're talking past each other. DLEP has not assumed >> 802.1D support in the radios, so all of your "shall" verbiage doesn't = make >> sense. The only assumption DLEP makes (at least as of now) is that = the >> radios operate in transparent bridge mode - that the destination MAC = is >> that of the far-end router, not any of the intervening devices. >>>>>>>>>>> As is in 802.1D. >>>>>>>>>>>=20 >>>>>>>>>>>> And without some flows from router *to* radio, your = "one-way >> only" communication mode doesn't work, because you can't correlate a >> router to it's attached RF device. >>>>>>>>>>> It is the RF device that is locally connected. Not the far = end >> RF device. Cannot be mistaken, can it? >>>>>>>>>>=20 >>>>>>>>>> Yes, it can. Given 3 radio/router pairs, each in the = "one-way" >> mode, what MAC address is in the Neighbor Up? >>>>>>>>>=20 >>>>>>>>> The far end router. It doesn't need to be DLEP enabled. Could = be a >> host also, like a laptop for testing. >>>>>>>>=20 >>>>>>>> And how does the radio (far-end radio) learn of the MAC = address? >>>>>>=20 >>>>>> @Stan: >>>>>> Assume frames have 4 MAC addresses: SA, DA, TA and RA. >>>>>> SA: Source Address, sending router >>>>>> DA: Destination Address, receiving router (far end radio sends = frame >> to locally attached router) >>>>>> TA: Transmitter Address, radio ID of RF link, sending radio >>>>>> RA: Receiver Address, radio ID on RF link, receiving radio >>>>>>=20 >>>>>> I am aware of radio's that reuse the SA/DA for TA/RA, so they do = not >> need the 4-address mode. This has some limitations, in that radio = supports >> only one node (although there could be a work-around). The more = enhanced >> radios use the 4 address mode. >>>>>>=20 >>>>>> Now your question: radio inspects the frame header, to find out = what >> to do with it. Highly simplified: Is RA its own address? No, then = discard. >> It could update link metrics for TA and all SA behind TA, no reason = to >> ignore available info. For frames for that radio, it refresh = forwarding >> tables: SA is behind TA, this info is required for return frames. = Frame is >> converted or decapsulated and forwarded to DA, could be flooding if >> unknown outgoing port was unknown. >>>>>>=20 >>>>>> Side node: when RA !=3D own address, radio could update bridge >> forwarding table, and relate SA and TA. >>>>>=20 >>>>> And if the router, for whatever reason or reasons might be >> appropriate, simply hasn't emitted any frames toward the radio? >>>>=20 >>>> Then far-end nodes are not aware the router exists. In my = environment, >> radio silence is a normal mode of operation. >>>>=20 >>>=20 >>> I'm not talking about radio silence. Just a router that hasn't = emitted >> any frames. >>=20 >> OK, I just mentioned I have to deal with silent radios. I guess I am = not >> the only one here. >>=20 >>> So back to my original comment - this suggestion is making = assumptions. >>=20 >> Yes, in that standard protocols are being used. Not a bad assumption, = I >> think. >> If your DLEP proposal is not built on standards, I prefer staying far = away >> from it. >>=20 >>> It assumes that the radio is snooping/cacheing MAC addresses, >>=20 >> Yes. It is specified in dlep-03, page 8: >> DLEP assumes that participating modems, and their physical links, = act >> as a transparent bridge. >> I am not aware of transparent bridges that do not act the way I = describe. >>=20 >>> and it assumes that the router is forwarding frames to the radio = prior >> to any "Neighbor Up" event. I do not believe that DLEP should be = making >> such assumptions. >>=20 >> Are you kidding in that a router does not send packets on an = interface, >> where the routing protocol is enabled? >> (leaving PPPoE / VMI out of scope here) >>=20 >> Teco >>=20 >>=20 >>>=20 >>> Stan >>>=20 >>>=20 >>>> Teco >>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> A picture my help (me for atleast as I try to follow). Two >> different networks below. >>>>>>>=20 >>>>>>> A) >>>>>>> [ DLEP Enabled] [ DLEP Enabled] >>>>>>> [ radio~router]~~~~~~~[ radio|router] >>>>>>>=20 >>>>>>> B) >>>>>>> [ DLEP Enabled] [ integrated] >>>>>>> [ radio~router]~~~~~~~[ radio|host] >>>>>>=20 >>>>>> There are more scenario's: >>>>>>=20 >>>>>> C) >>>>>> [ DLEP Enabled] [ DLEP Disabled] >>>>>> [ radio~router]~~~~~~~[ radio|router ] >>>>>>=20 >>>>>> D) >>>>>> [ DLEP Enabled] >>>>>> [ DLEP Enabled] [ integrated] >>>>>> [ radio~router]~~~~~~~[ radio|host] >>>>>>=20 >>>>>> All should work. >>>>>>=20 >>>>>>>=20 >>>>>>> The [integrated radio|host] shares MAC/IP address information = via a >> driver, not DLEP. >>>>>> What is "shares MAC/IP address"? >>>>>> With 4 address mode, SA and TA would be same MAC address. >>>>>>=20 >>>>>>> In configuration (B) the DLEP Enabled radio must obtain the host = MAC >> address to drive DLEP. How the DLEP Enabled radio obtains the host = MAC is >> really a function of the DLEP Enabled radio. Once obtained, the DLEP >> Enabled radio generates a Neighbor Up and can report metrics = associated >> with the host MAC. The DLEP Enabled router uses the host MAC in the = DLEP >> messages to adjust/influence routing. >>>>>>=20 >>>>>> Agreed in that the DLEP specification shall not assume both sides = of >> link have DLEP enabled, such as with (B) and (C)? >>>>>>=20 >>>>>> Teco >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> BTW, I would just send the metric costs. Neighbor up is = implicit. >> Due to RF, signals fade away, Neighbor down is artificial (or result = of a >> disconnect). >>>>>>>>>=20 >>>>>>>>> Teco >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> And I'm not OK with *requiring* that level of functionality = in >> the radio. >>>>>>>>>>> I didn't read anything here that didn't match 802.1D. >>>>>>>>>>>=20 >>>>>>>>>>> Teco >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Stan >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Teco >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het = volgende >> geschreven: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I mean I understand from discussions that Stan's reply to >> Teco that he does not beleive to use bridge mode, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> AB >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge >> wrote: >>>>>>>>>>>>>> On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> Because there was no "radio-to-MAC" correlation, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> IMO, correlation concept not understood, but understand = that >> we don't need >>>>>>>>>>>>>>> bridge mode. However, still waiting for the respond to = Teco >> question, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> What do you mean with "we don't need bridge mode" ? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Henning Rogge >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Steven Hawkings about cosmic inflation: "An increase of >> billions of >>>>>>>>>>>>>> billions of percent in a tiny fraction of a second. Of >> course, that >>>>>>>>>>>>>> was before the present government." >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> manet mailing list >>>>>>>>>>>>>> manet@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> manet mailing list >>>>>>>>>>>>> manet@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> manet mailing list >>>>>>>> manet@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > The information contained within this e-mail and any files attached to = this e-mail is private and in addition may include commercially = sensitive information. The contents of this e-mail are for the intended = recipient only and therefore if you wish to disclose the information = contained within this e-mail or attached files, please contact the = sender prior to any such disclosure. If you are not the intended = recipient, any disclosure, copying or distribution is prohibited. Please = also contact the sender and inform them of the error and delete the = e-mail, including any attached files from your system. Cassidian = Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, = Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From teco@inf-net.nl Wed Nov 21 04:32:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0460321F855F for ; Wed, 21 Nov 2012 04:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgkMtoXALchW for ; Wed, 21 Nov 2012 04:32:35 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F07921F85C9 for ; Wed, 21 Nov 2012 04:32:34 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1016812wey.31 for ; Wed, 21 Nov 2012 04:32:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=qvXLy/+22FWqe7xQ29DLlLrTgCc01j1X4cMim8Or8zs=; b=LZmeBjMvDvAH5OMG+4btngUG342oIG/LtPXBuc3ro72PLo6l37pr6RzMNuQjClU3EN knu1H7M6P+ATjMedYCly+CE+7xhOnzcXqlsz3ASPAU2aXxq+xktiNXkAP3wUdymtfNa2 oNTm4FOlpJD/yvFbrN8MgHhlDhHfND6ayZNbqm94WHtPx2ABcO4iilponIhm77tV8tP9 5ojbwbsxphQy0vqLxQc77GGfXxkl3rbE8SOBPo/zenpE/d2NQ4HI3KZqRzZydNcqUIJq xmlXrdJ0uZqdPzUpjsNG+9Xjr6LOB9RwIT6L5ApDcv9EEz3/HuuaSIV2guAAE2Y5ayMY lERg== Received: by 10.181.11.233 with SMTP id el9mr2599398wid.3.1353501154150; Wed, 21 Nov 2012 04:32:34 -0800 (PST) Received: from [172.16.4.198] ([188.205.88.52]) by mx.google.com with ESMTPS id n11sm4993750wiw.6.2012.11.21.04.32.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Nov 2012 04:32:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Wed, 21 Nov 2012 13:32:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com><5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com><56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl><8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459 FDB4EAC9EAD090C 0F42FFE2@xmb-aln-x03 .cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F430211@xmb-aln-x03.cisco.com><50FBC4FB-6677-440A-B50A-685DFDD96A46@cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F430886@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F430A1A@xmb-aln-x03.cisco.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQk5sqwj4bkyHhzbYpkXY+3V+pDSFonpSexfBeB/JM33l9exedlKIbPI3KDi67vKia6vdTHG Cc: manet , "Stan Ratliff \(sratliff\)" , "Bo Berry \(boberry\)" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 12:32:37 -0000 Op 21 nov. 2012, om 12:55 heeft Dearlove, Christopher (UK) het volgende = geschreven: > Do you mean through your crypto from modem to radio? I thought we were = discussing a crypto between radio/modem and router? There could be a need to use many of it. a) VPN: router to router tunnel (or payload encryption, or whatever) b) Firewall on router interface to radio. With policies that permits = what is allowed and let drop everything else (think of a diode) c) Some security mechanism between radio and router I have (a) and (b). (c) is not that important, boxes are physically = connected and crypto can be avoid.=20 Teco >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Taylor, Rick > Sent: 21 November 2012 10:48 > To: Teco Boot; Stan Ratliff (sratliff) > Cc: manet; Bo Berry (boberry) > Subject: Re: [manet] DLEP Lite? (Teco Boot) >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Teco, >=20 > I am just trying to understand your difficulty with 'full-fat' DLEP. = Is it: >=20 > A) You require unidirectional traffic through your crypto from modem = to radio. >=20 > Or, >=20 > B) You require your radio to sometimes operate in an Rx-only mode. >=20 > Or is it both? >=20 > =46rom my perspective: A) can be solved by placing a device between = the crypto and the modem that acts as a proxy, rather than a new = DLEP-lite protocol. >=20 > B) Has been covered by Stan I believe: DLEP (as it currently stands) = does not define the communication between radios, only between router = and radio. The methods used by radios to forward packets at Layers < 3 = is the manufacturers business, not DLEP's. The only requirement is that = two neighbouring routers shall be able to address packets to each other = using the DLEP supplied MAC addresses. >=20 > But I might have missed the thrust of your argument. >=20 > Rick Taylor >=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of >> Teco Boot >> Sent: 15 November 2012 18:56 >> To: Stan Ratliff (sratliff) >> Cc: manet; Bo Berry (boberry) >> Subject: Re: [manet] DLEP Lite? (Teco Boot) >>=20 >>=20 >>=20 >> Op 15 nov. 2012, om 17:26 heeft Stan Ratliff (sratliff) het volgende >> geschreven: >>=20 >>>=20 >>> On Nov 15, 2012, at 11:02 AM, Teco Boot wrote: >>>=20 >>>>=20 >>>> Op 15 nov. 2012, om 15:55 heeft Stan Ratliff (sratliff) het = volgende >> geschreven: >>>>=20 >>>>>=20 >>>>> On Nov 15, 2012, at 1:29 AM, Teco Boot wrote: >>>>>=20 >>>>>>=20 >>>>>> Op 14 nov. 2012, om 20:43 heeft Bo Berry het volgende geschreven: >>>>>>=20 >>>>>>>=20 >>>>>>> On Nov 14, 2012, at 2:26 PM, Stan Ratliff (sratliff) wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Nov 14, 2012, at 2:03 PM, Teco Boot wrote: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Op 14 nov. 2012, om 19:31 heeft Stan Ratliff (sratliff) het >> volgende geschreven: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Nov 14, 2012, at 10:55 AM, Teco Boot wrote: >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Op 14 nov. 2012, om 16:34 heeft Stan Ratliff (sratliff) het >> volgende geschreven: >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On Nov 14, 2012, at 7:15 AM, Teco Boot wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Attempt to make thinks clear. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Radio is L2 device, could be 802.1D bridge or repeater. = Device >> is >>>>>>>>>>>>> self learning. It has MAC addresses and probably an IP >> address. >>>>>>>>>>>>> Routers are connected to radio with ethernet or = equivalent. >>>>>>>>>>>>> Routers have a sub-IP connection with each other via the >> ethernet - RF >>>>>>>>>>>>> - ethernet sub-IP link. Connection is based on 802.1 MAC >> addresses. >>>>>>>>>>>>> Radio has the task to deliver router originated frames to >> destination, >>>>>>>>>>>>> based on destination MAC address. Could be L2 multicast or >> broadcast. >>>>>>>>>>>>> With DLEP, radios have the task to keep track of link >> properties between >>>>>>>>>>>>> each connected device. Could be *any* connected ethernet = NIC, >> as long as >>>>>>>>>>>>> it has an 802.1 address and it sends a packet every now = and >> then. All >>>>>>>>>>>>> radios in the sub-IP network automatically learn the = existence >> of each >>>>>>>>>>>>> connected sending node, as required by 802.1D. DLEP shall = be >> 100% >>>>>>>>>>>>> compatible with this widely deployed mechanism. It shall >> provide link >>>>>>>>>>>>> metrics for far end connected MAC addresses to locally >> connected nodes. >>>>>>>>>>>>> It shall work this way for single- and multi-hop sub-IP >> networks. >>>>>>>>>>>>=20 >>>>>>>>>>>> I think we're talking past each other. DLEP has not assumed >> 802.1D support in the radios, so all of your "shall" verbiage doesn't = make >> sense. The only assumption DLEP makes (at least as of now) is that = the >> radios operate in transparent bridge mode - that the destination MAC = is >> that of the far-end router, not any of the intervening devices. >>>>>>>>>>> As is in 802.1D. >>>>>>>>>>>=20 >>>>>>>>>>>> And without some flows from router *to* radio, your = "one-way >> only" communication mode doesn't work, because you can't correlate a >> router to it's attached RF device. >>>>>>>>>>> It is the RF device that is locally connected. Not the far = end >> RF device. Cannot be mistaken, can it? >>>>>>>>>>=20 >>>>>>>>>> Yes, it can. Given 3 radio/router pairs, each in the = "one-way" >> mode, what MAC address is in the Neighbor Up? >>>>>>>>>=20 >>>>>>>>> The far end router. It doesn't need to be DLEP enabled. Could = be a >> host also, like a laptop for testing. >>>>>>>>=20 >>>>>>>> And how does the radio (far-end radio) learn of the MAC = address? >>>>>>=20 >>>>>> @Stan: >>>>>> Assume frames have 4 MAC addresses: SA, DA, TA and RA. >>>>>> SA: Source Address, sending router >>>>>> DA: Destination Address, receiving router (far end radio sends = frame >> to locally attached router) >>>>>> TA: Transmitter Address, radio ID of RF link, sending radio >>>>>> RA: Receiver Address, radio ID on RF link, receiving radio >>>>>>=20 >>>>>> I am aware of radio's that reuse the SA/DA for TA/RA, so they do = not >> need the 4-address mode. This has some limitations, in that radio = supports >> only one node (although there could be a work-around). The more = enhanced >> radios use the 4 address mode. >>>>>>=20 >>>>>> Now your question: radio inspects the frame header, to find out = what >> to do with it. Highly simplified: Is RA its own address? No, then = discard. >> It could update link metrics for TA and all SA behind TA, no reason = to >> ignore available info. For frames for that radio, it refresh = forwarding >> tables: SA is behind TA, this info is required for return frames. = Frame is >> converted or decapsulated and forwarded to DA, could be flooding if >> unknown outgoing port was unknown. >>>>>>=20 >>>>>> Side node: when RA !=3D own address, radio could update bridge >> forwarding table, and relate SA and TA. >>>>>=20 >>>>> And if the router, for whatever reason or reasons might be >> appropriate, simply hasn't emitted any frames toward the radio? >>>>=20 >>>> Then far-end nodes are not aware the router exists. In my = environment, >> radio silence is a normal mode of operation. >>>>=20 >>>=20 >>> I'm not talking about radio silence. Just a router that hasn't = emitted >> any frames. >>=20 >> OK, I just mentioned I have to deal with silent radios. I guess I am = not >> the only one here. >>=20 >>> So back to my original comment - this suggestion is making = assumptions. >>=20 >> Yes, in that standard protocols are being used. Not a bad assumption, = I >> think. >> If your DLEP proposal is not built on standards, I prefer staying far = away >> from it. >>=20 >>> It assumes that the radio is snooping/cacheing MAC addresses, >>=20 >> Yes. It is specified in dlep-03, page 8: >> DLEP assumes that participating modems, and their physical links, = act >> as a transparent bridge. >> I am not aware of transparent bridges that do not act the way I = describe. >>=20 >>> and it assumes that the router is forwarding frames to the radio = prior >> to any "Neighbor Up" event. I do not believe that DLEP should be = making >> such assumptions. >>=20 >> Are you kidding in that a router does not send packets on an = interface, >> where the routing protocol is enabled? >> (leaving PPPoE / VMI out of scope here) >>=20 >> Teco >>=20 >>=20 >>>=20 >>> Stan >>>=20 >>>=20 >>>> Teco >>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> A picture my help (me for atleast as I try to follow). Two >> different networks below. >>>>>>>=20 >>>>>>> A) >>>>>>> [ DLEP Enabled] [ DLEP Enabled] >>>>>>> [ radio~router]~~~~~~~[ radio|router] >>>>>>>=20 >>>>>>> B) >>>>>>> [ DLEP Enabled] [ integrated] >>>>>>> [ radio~router]~~~~~~~[ radio|host] >>>>>>=20 >>>>>> There are more scenario's: >>>>>>=20 >>>>>> C) >>>>>> [ DLEP Enabled] [ DLEP Disabled] >>>>>> [ radio~router]~~~~~~~[ radio|router ] >>>>>>=20 >>>>>> D) >>>>>> [ DLEP Enabled] >>>>>> [ DLEP Enabled] [ integrated] >>>>>> [ radio~router]~~~~~~~[ radio|host] >>>>>>=20 >>>>>> All should work. >>>>>>=20 >>>>>>>=20 >>>>>>> The [integrated radio|host] shares MAC/IP address information = via a >> driver, not DLEP. >>>>>> What is "shares MAC/IP address"? >>>>>> With 4 address mode, SA and TA would be same MAC address. >>>>>>=20 >>>>>>> In configuration (B) the DLEP Enabled radio must obtain the host = MAC >> address to drive DLEP. How the DLEP Enabled radio obtains the host = MAC is >> really a function of the DLEP Enabled radio. Once obtained, the DLEP >> Enabled radio generates a Neighbor Up and can report metrics = associated >> with the host MAC. The DLEP Enabled router uses the host MAC in the = DLEP >> messages to adjust/influence routing. >>>>>>=20 >>>>>> Agreed in that the DLEP specification shall not assume both sides = of >> link have DLEP enabled, such as with (B) and (C)? >>>>>>=20 >>>>>> Teco >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> BTW, I would just send the metric costs. Neighbor up is = implicit. >> Due to RF, signals fade away, Neighbor down is artificial (or result = of a >> disconnect). >>>>>>>>>=20 >>>>>>>>> Teco >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> And I'm not OK with *requiring* that level of functionality = in >> the radio. >>>>>>>>>>> I didn't read anything here that didn't match 802.1D. >>>>>>>>>>>=20 >>>>>>>>>>> Teco >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Stan >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Teco >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het = volgende >> geschreven: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I mean I understand from discussions that Stan's reply to >> Teco that he does not beleive to use bridge mode, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> AB >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge >> wrote: >>>>>>>>>>>>>> On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> Because there was no "radio-to-MAC" correlation, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> IMO, correlation concept not understood, but understand = that >> we don't need >>>>>>>>>>>>>>> bridge mode. However, still waiting for the respond to = Teco >> question, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> What do you mean with "we don't need bridge mode" ? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Henning Rogge >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Steven Hawkings about cosmic inflation: "An increase of >> billions of >>>>>>>>>>>>>> billions of percent in a tiny fraction of a second. Of >> course, that >>>>>>>>>>>>>> was before the present government." >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> manet mailing list >>>>>>>>>>>>>> manet@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> manet mailing list >>>>>>>>>>>>> manet@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> manet mailing list >>>>>>>> manet@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > The information contained within this e-mail and any files attached to = this e-mail is private and in addition may include commercially = sensitive information. The contents of this e-mail are for the intended = recipient only and therefore if you wish to disclose the information = contained within this e-mail or attached files, please contact the = sender prior to any such disclosure. If you are not the intended = recipient, any disclosure, copying or distribution is prohibited. Please = also contact the sender and inform them of the error and delete the = e-mail, including any attached files from your system. Cassidian = Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, = Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > 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. > ******************************************************************** >=20 From rick.taylor@cassidian.com Wed Nov 21 05:41:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492B521F873E for ; Wed, 21 Nov 2012 05:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znKotxIJyTX3 for ; Wed, 21 Nov 2012 05:41:03 -0800 (PST) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id DD10B21F853C for ; Wed, 21 Nov 2012 05:40:58 -0800 (PST) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 21 Nov 2012 14:40:52 +0100 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 21 Nov 2012 14:40:58 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Nov 2012 14:40:51 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Nov 2012 14:40:51 +0100 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Wed, 21 Nov 2012 13:40:51 +0000 From: "Taylor, Rick" To: "Dearlove, Christopher (UK)" , Teco Boot , "Stan Ratliff (sratliff)" Thread-Topic: [manet] DLEP Lite? (Teco Boot) Thread-Index: AQHNw2Lk8St7CxHOQImNx8g7RjcZBJf0VLZg Date: Wed, 21 Nov 2012 13:40:50 +0000 Message-ID: References: <2142BCFA1F7F0D468F8EE6C8DE719E6805B708FF@CGYSVW100.gdcan.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B026@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42B14D@xmb-aln-x03.cisco.com><5CF4E9FA-1BA2-4CAF-A9AC-9848D69F0400@inf-net.nl><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42C56E@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42CF54@xmb-aln-x03.cisco.com><56E8EC2A-B630-4A1E-A133-B180547599F3@inf-net.nl><8C5D6971-05E8-49C4-A77F-29BDC320762D@inf-net.nl><2ED1D3801ACAAB459FDB4EAC9EAD090C0F42F76E@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459 FDB4EAC9EAD090! C0F42FFE2 @xmb-aln-x03 .cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F430211@xmb-aln-x03.cisco.com><50FBC4FB-6677-440A-B50A-685DFDD96A46@cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F430886@xmb-aln-x03.cisco.com><2ED1D3801ACAAB459FDB4EAC9EAD090C0F430A1A@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.114] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Nov 2012 13:40:51.0830 (UTC) FILETIME=[D29D1960:01CDC7ED] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19382.007 X-TM-AS-Result: No--41.492900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet , "Bo Berry \(boberry\)" Subject: Re: [manet] DLEP Lite? (Teco Boot) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 13:41:05 -0000 Ooops, Thanks Christopher, I meant crypto between router and modem! Rick Taylor > -----Original Message----- > From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] > Sent: 21 November 2012 11:56 > To: Taylor, Rick; Teco Boot; Stan Ratliff (sratliff) > Cc: manet; Bo Berry (boberry) > Subject: RE: [manet] DLEP Lite? (Teco Boot) > > Do you mean through your crypto from modem to radio? I thought we were > discussing a crypto between radio/modem and router? > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Taylor, Rick > Sent: 21 November 2012 10:48 > To: Teco Boot; Stan Ratliff (sratliff) > Cc: manet; Bo Berry (boberry) > Subject: Re: [manet] DLEP Lite? (Teco Boot) > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Teco, > > I am just trying to understand your difficulty with 'full-fat' DLEP. Is > it: > > A) You require unidirectional traffic through your crypto from modem to > radio. > > Or, > > B) You require your radio to sometimes operate in an Rx-only mode. > > Or is it both? > > From my perspective: A) can be solved by placing a device between the > crypto and the modem that acts as a proxy, rather than a new DLEP-lite > protocol. > > B) Has been covered by Stan I believe: DLEP (as it currently stands) does > not define the communication between radios, only between router and > radio. The methods used by radios to forward packets at Layers < 3 is th= e > manufacturers business, not DLEP's. The only requirement is that two > neighbouring routers shall be able to address packets to each other using > the DLEP supplied MAC addresses. > > But I might have missed the thrust of your argument. > > Rick Taylor > > > -----Original Message----- > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of > > Teco Boot > > Sent: 15 November 2012 18:56 > > To: Stan Ratliff (sratliff) > > Cc: manet; Bo Berry (boberry) > > Subject: Re: [manet] DLEP Lite? (Teco Boot) > > > > > > > > Op 15 nov. 2012, om 17:26 heeft Stan Ratliff (sratliff) het volgende > > geschreven: > > > > > > > > On Nov 15, 2012, at 11:02 AM, Teco Boot wrote: > > > > > >> > > >> Op 15 nov. 2012, om 15:55 heeft Stan Ratliff (sratliff) het volgende > > geschreven: > > >> > > >>> > > >>> On Nov 15, 2012, at 1:29 AM, Teco Boot wrote: > > >>> > > >>>> > > >>>> Op 14 nov. 2012, om 20:43 heeft Bo Berry het volgende geschreven: > > >>>> > > >>>>> > > >>>>> On Nov 14, 2012, at 2:26 PM, Stan Ratliff (sratliff) wrote: > > >>>>> > > >>>>>> > > >>>>>> On Nov 14, 2012, at 2:03 PM, Teco Boot wrote: > > >>>>>> > > >>>>>>> > > >>>>>>> Op 14 nov. 2012, om 19:31 heeft Stan Ratliff (sratliff) het > > volgende geschreven: > > >>>>>>> > > >>>>>>>> > > >>>>>>>> On Nov 14, 2012, at 10:55 AM, Teco Boot wrote: > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Op 14 nov. 2012, om 16:34 heeft Stan Ratliff (sratliff) het > > volgende geschreven: > > >>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> On Nov 14, 2012, at 7:15 AM, Teco Boot wrote: > > >>>>>>>>>> > > >>>>>>>>>>> Attempt to make thinks clear. > > >>>>>>>>>>> > > >>>>>>>>>>> Radio is L2 device, could be 802.1D bridge or repeater. > Device > > is > > >>>>>>>>>>> self learning. It has MAC addresses and probably an IP > > address. > > >>>>>>>>>>> Routers are connected to radio with ethernet or equivalent. > > >>>>>>>>>>> Routers have a sub-IP connection with each other via the > > ethernet - RF > > >>>>>>>>>>> - ethernet sub-IP link. Connection is based on 802.1 MAC > > addresses. > > >>>>>>>>>>> Radio has the task to deliver router originated frames to > > destination, > > >>>>>>>>>>> based on destination MAC address. Could be L2 multicast or > > broadcast. > > >>>>>>>>>>> With DLEP, radios have the task to keep track of link > > properties between > > >>>>>>>>>>> each connected device. Could be *any* connected ethernet > NIC, > > as long as > > >>>>>>>>>>> it has an 802.1 address and it sends a packet every now and > > then. All > > >>>>>>>>>>> radios in the sub-IP network automatically learn the > existence > > of each > > >>>>>>>>>>> connected sending node, as required by 802.1D. DLEP shall b= e > > 100% > > >>>>>>>>>>> compatible with this widely deployed mechanism. It shall > > provide link > > >>>>>>>>>>> metrics for far end connected MAC addresses to locally > > connected nodes. > > >>>>>>>>>>> It shall work this way for single- and multi-hop sub-IP > > networks. > > >>>>>>>>>> > > >>>>>>>>>> I think we're talking past each other. DLEP has not assumed > > 802.1D support in the radios, so all of your "shall" verbiage doesn't > make > > sense. The only assumption DLEP makes (at least as of now) is that the > > radios operate in transparent bridge mode - that the destination MAC is > > that of the far-end router, not any of the intervening devices. > > >>>>>>>>> As is in 802.1D. > > >>>>>>>>> > > >>>>>>>>>> And without some flows from router *to* radio, your "one-way > > only" communication mode doesn't work, because you can't correlate a > > router to it's attached RF device. > > >>>>>>>>> It is the RF device that is locally connected. Not the far en= d > > RF device. Cannot be mistaken, can it? > > >>>>>>>> > > >>>>>>>> Yes, it can. Given 3 radio/router pairs, each in the "one-way" > > mode, what MAC address is in the Neighbor Up? > > >>>>>>> > > >>>>>>> The far end router. It doesn't need to be DLEP enabled. Could b= e > a > > host also, like a laptop for testing. > > >>>>>> > > >>>>>> And how does the radio (far-end radio) learn of the MAC address? > > >>>> > > >>>> @Stan: > > >>>> Assume frames have 4 MAC addresses: SA, DA, TA and RA. > > >>>> SA: Source Address, sending router > > >>>> DA: Destination Address, receiving router (far end radio sends > frame > > to locally attached router) > > >>>> TA: Transmitter Address, radio ID of RF link, sending radio > > >>>> RA: Receiver Address, radio ID on RF link, receiving radio > > >>>> > > >>>> I am aware of radio's that reuse the SA/DA for TA/RA, so they do > not > > need the 4-address mode. This has some limitations, in that radio > supports > > only one node (although there could be a work-around). The more enhance= d > > radios use the 4 address mode. > > >>>> > > >>>> Now your question: radio inspects the frame header, to find out > what > > to do with it. Highly simplified: Is RA its own address? No, then > discard. > > It could update link metrics for TA and all SA behind TA, no reason to > > ignore available info. For frames for that radio, it refresh forwarding > > tables: SA is behind TA, this info is required for return frames. Frame > is > > converted or decapsulated and forwarded to DA, could be flooding if > > unknown outgoing port was unknown. > > >>>> > > >>>> Side node: when RA !=3D own address, radio could update bridge > > forwarding table, and relate SA and TA. > > >>> > > >>> And if the router, for whatever reason or reasons might be > > appropriate, simply hasn't emitted any frames toward the radio? > > >> > > >> Then far-end nodes are not aware the router exists. In my > environment, > > radio silence is a normal mode of operation. > > >> > > > > > > I'm not talking about radio silence. Just a router that hasn't emitte= d > > any frames. > > > > OK, I just mentioned I have to deal with silent radios. I guess I am no= t > > the only one here. > > > > > So back to my original comment - this suggestion is making > assumptions. > > > > Yes, in that standard protocols are being used. Not a bad assumption, I > > think. > > If your DLEP proposal is not built on standards, I prefer staying far > away > > from it. > > > > > It assumes that the radio is snooping/cacheing MAC addresses, > > > > Yes. It is specified in dlep-03, page 8: > > DLEP assumes that participating modems, and their physical links, ac= t > > as a transparent bridge. > > I am not aware of transparent bridges that do not act the way I > describe. > > > > > and it assumes that the router is forwarding frames to the radio prio= r > > to any "Neighbor Up" event. I do not believe that DLEP should be making > > such assumptions. > > > > Are you kidding in that a router does not send packets on an interface, > > where the routing protocol is enabled? > > (leaving PPPoE / VMI out of scope here) > > > > Teco > > > > > > > > > > Stan > > > > > > > > >> Teco > > >> > > >>> > > >>> > > >>>> > > >>>>> > > >>>>> > > >>>>> A picture my help (me for atleast as I try to follow). Two > > different networks below. > > >>>>> > > >>>>> A) > > >>>>> [ DLEP Enabled] [ DLEP Enabled] > > >>>>> [ radio~router]~~~~~~~[ radio|router] > > >>>>> > > >>>>> B) > > >>>>> [ DLEP Enabled] [ integrated] > > >>>>> [ radio~router]~~~~~~~[ radio|host] > > >>>> > > >>>> There are more scenario's: > > >>>> > > >>>> C) > > >>>> [ DLEP Enabled] [ DLEP Disabled] > > >>>> [ radio~router]~~~~~~~[ radio|router ] > > >>>> > > >>>> D) > > >>>> [ DLEP Enabled] > > >>>> [ DLEP Enabled] [ integrated] > > >>>> [ radio~router]~~~~~~~[ radio|host] > > >>>> > > >>>> All should work. > > >>>> > > >>>>> > > >>>>> The [integrated radio|host] shares MAC/IP address information via > a > > driver, not DLEP. > > >>>> What is "shares MAC/IP address"? > > >>>> With 4 address mode, SA and TA would be same MAC address. > > >>>> > > >>>>> In configuration (B) the DLEP Enabled radio must obtain the host > MAC > > address to drive DLEP. How the DLEP Enabled radio obtains the host MAC > is > > really a function of the DLEP Enabled radio. Once obtained, the DLEP > > Enabled radio generates a Neighbor Up and can report metrics associated > > with the host MAC. The DLEP Enabled router uses the host MAC in the > DLEP > > messages to adjust/influence routing. > > >>>> > > >>>> Agreed in that the DLEP specification shall not assume both sides > of > > link have DLEP enabled, such as with (B) and (C)? > > >>>> > > >>>> Teco > > >>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>> > > >>>>>> > > >>>>>>> > > >>>>>>> BTW, I would just send the metric costs. Neighbor up is > implicit. > > Due to RF, signals fade away, Neighbor down is artificial (or result of > a > > disconnect). > > >>>>>>> > > >>>>>>> Teco > > >>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>>> And I'm not OK with *requiring* that level of functionality > in > > the radio. > > >>>>>>>>> I didn't read anything here that didn't match 802.1D. > > >>>>>>>>> > > >>>>>>>>> Teco > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> Stan > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> Teco > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het > volgende > > geschreven: > > >>>>>>>>>>> > > >>>>>>>>>>>> I mean I understand from discussions that Stan's reply to > > Teco that he does not beleive to use bridge mode, > > >>>>>>>>>>>> > > >>>>>>>>>>>> AB > > >>>>>>>>>>>> > > >>>>>>>>>>>> On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge > > wrote: > > >>>>>>>>>>>> On Tue, Nov 13, 2012 at 8:27 PM, Abdussalam Baryun > > >>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>> Because there was no "radio-to-MAC" correlation, > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> IMO, correlation concept not understood, but understand > that > > we don't need > > >>>>>>>>>>>>> bridge mode. However, still waiting for the respond to > Teco > > question, > > >>>>>>>>>>>> > > >>>>>>>>>>>> What do you mean with "we don't need bridge mode" ? > > >>>>>>>>>>>> > > >>>>>>>>>>>> Henning Rogge > > >>>>>>>>>>>> -- > > >>>>>>>>>>>> Steven Hawkings about cosmic inflation: "An increase of > > billions of > > >>>>>>>>>>>> billions of percent in a tiny fraction of a second. Of > > course, that > > >>>>>>>>>>>> was before the present government." > > >>>>>>>>>>>> > > >>>>>>>>>>>> _______________________________________________ > > >>>>>>>>>>>> manet mailing list > > >>>>>>>>>>>> manet@ietf.org > > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet > > >>>>>>>>>>> > > >>>>>>>>>>> _______________________________________________ > > >>>>>>>>>>> manet mailing list > > >>>>>>>>>>> manet@ietf.org > > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> manet mailing list > > >>>>>> manet@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/manet > > >>>>> > > >>>> > > >>> > > >> > > >> _______________________________________________ > > >> manet mailing list > > >> manet@ietf.org > > >> https://www.ietf.org/mailman/listinfo/manet > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > The information contained within this e-mail and any files attached to > this e-mail is private and in addition may include commercially sensitive > information. The contents of this e-mail are for the intended recipient > only and therefore if you wish to disclose the information contained > within this e-mail or attached files, please contact the sender prior to > any such disclosure. If you are not the intended recipient, any > disclosure, copying or distribution is prohibited. Please also contact th= e > sender and inform them of the error and delete the e-mail, including any > attached files from your system. Cassidian Limited, Registered Office : > Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: > 04191036 http://www.cassidian.com > _______________________________________________ > manet mailing list > manet@ietf.org > 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. > ******************************************************************** The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From budden@nps.edu Wed Nov 21 09:22:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6856921F864D for ; Wed, 21 Nov 2012 09:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXiX5cD7eGwx for ; Wed, 21 Nov 2012 09:22:50 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 406DC21F862C for ; Wed, 21 Nov 2012 09:22:50 -0800 (PST) X-ASG-Debug-ID: 1353518569-036c92203d130e40001-Rp4q3q Received: from gulfstream.ern.nps.edu (gulfstream.ern.nps.edu [172.20.24.113]) by mule.nps.edu with ESMTP id t3l0Fa6Orw2DwJbt for ; Wed, 21 Nov 2012 09:22:49 -0800 (PST) X-Barracuda-Envelope-From: budden@nps.edu Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.113) with Microsoft SMTP Server (TLS) id 14.1.421.2; Wed, 21 Nov 2012 09:22:49 -0800 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [manet] Metric TLVs for DLEP To: In-Reply-To: <50AB4E2D.8080500@fkie.fraunhofer.de> References: <50AB4E2D.8080500@fkie.fraunhofer.de> Content-Type: text/plain; charset="UTF-8" Date: Wed, 21 Nov 2012 09:21:46 -0800 Message-ID: <1353518506.2201.110.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-Barracuda-Connect: gulfstream.ern.nps.edu[172.20.24.113] X-Barracuda-Start-Time: 1353518569 X-Barracuda-URL: http://205.155.65.106:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.114860 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Subject: Re: [manet] Metric TLVs for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 17:22:51 -0000 ... hints on where to look. IEEE 802.16 and TIA LTE (the two standards are very much alike, no accident) have a set of about four dozen MAC messages that are exchanged between BS and SS (and do not pass above layer 2, except indirectly as MIB values). Included in this set of MAC messages are ranging messages that appear to be very similar to what you're describing below. Mining that set might save you some reinvention. On Tue, 2012-11-20 at 10:32 +0100, Henning Rogge wrote: > Hi, > > as discussed during the IETF, here a few thoughts about additional > metric TLVs. > > I think that including a larger set of metric TLVs (like Relative Link > Quality, Current/Maximum Datarate, ...) is a good thing, because it > allows radio/router implementors to choose from a larger set of > standardized TLVs, which increase the chance of interoperability between > the products. > > There are two kinds of metric TLVs, one of them contain information > about the network the radio is attached to and one of them contain > information about the link of the radio to a target. > > Network specific metric TLVs > ---------------------------- > > * network-id > > A binary identifier of the network the radio is attached to (1-16 octets > binary) > > * network-description > > A text identifier of the network the radio is attached to (1-80 octects > ascii) > > * supported-rates > > An array of datarates supported by the radio on the current network > (array of 8 octet values in bit/s) > > * last-active > > Time since the last data was sent or received over the radio (4 octet > value in milliseconds) > > * frequency > > Mid-Frequency of the current radio channel (8 octet value in Hz) > > * bandwidth > > Amount of spectrum a radio channel uses (8 octet value in Hz) > > > Neighbor specific metric TLVs > ----------------------------- > > * maximum-datarate > > This one already exists in DLEP, but doesn't report both incoming and > outgoing maximum link speed, which could be different. > > * current-datarate > > Same as maximum datarate, incoming and outgoing speed can be different. > > * traffic > > Amount of bytes sent and received with the neighbor (8+8 octet value) > > * packets > > Amount of IP packet sent and received with the neighbor (8+8 octet value) > > * frames > > Amount of layer-2 frames sent and received with the neighbor (8+8 octet > value) > > * tx-retries > > Number of linklayer retransmissions for IP packets (8 octet value) > > * tx-fails > > Number of failed linklayer transmissions > > * last-active > > Time since the last data was sent or received with this neighbor (4 > octet value in milliseconds) > > ---------------------- > > The traffic and packet TLVs become important when you have multiple > routers of hosts attached to a DLEP capable radio, because they cannot > track the traffic on their local interface anymore. > > > Henning Rogge > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From charliep@computer.org Thu Nov 29 18:03:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE1521F865D for ; Thu, 29 Nov 2012 18:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 037-4UT0lAFo for ; Thu, 29 Nov 2012 18:03:12 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id D735421F8623 for ; Thu, 29 Nov 2012 18:03:12 -0800 (PST) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TeFwd-0004L3-QG for manet@ietf.org; Thu, 29 Nov 2012 21:03:11 -0500 Message-ID: <50B813D8.1070705@computer.org> Date: Thu, 29 Nov 2012 18:03:04 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86b048a942ef6ed90784bca2e7acb8c514350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Subject: [manet] draft-ietf-manet-dymo-24x.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 02:03:13 -0000 Hello folks, I have completed the first really coherent revision of AODVv2 since I took the editorial pen last year. I want to read through it just a bit more, and I expect to submit it to the Internet Draft directories tomorrow. In the meantime, here is the current version: http://www.psg.com/~charliep/txt/ietf85/draft-ietf-manet-dymo-24x.txt I have made a big effort to improve the readability and organization of the text; other than that, there have been very few technical changes. The section on precursors (optional feature) has been mostly rewritten, and most other sections have had very heavy editing to reflect the terminology revision. Some things clarified or changed or made more definite: - When a node generates a RteMsg (RREQ or RREP), it always increments its sequence number - RFC 5444 compliance (many changes for this) - New MsgTLV for RERR, to enable unicast route error to PktSource - New MsgTLV for RREQ, to enable destination-only RREP - SeqNum field required for all "Added Node" AddrBlk (optional feature) Making RREP and RREQ always to increment sequence number some beneficial simplifications in route table update description. I think the only thing unfinished right now is to enable alternate metrics. Some of the mechanism is specified (and was before in DYMO) but it needs a few more paragraphs. If I can do that for tomorrow, I will do so. Comments on the prerelease are, as always, welcome. I will also post some relevant issues to the Issue Tracker soon. -- Regards, Charlie P. From charliep@computer.org Thu Nov 29 18:04:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DA921F8660 for ; Thu, 29 Nov 2012 18:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7Dok5flMY4F for ; Thu, 29 Nov 2012 18:04:59 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 08E1E21F865D for ; Thu, 29 Nov 2012 18:04:59 -0800 (PST) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TeFyM-0000Vo-9M for manet@ietf.org; Thu, 29 Nov 2012 21:04:58 -0500 Message-ID: <50B81443.7030800@computer.org> Date: Thu, 29 Nov 2012 18:04:51 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: manet References: <50B813D8.1070705@computer.org> In-Reply-To: <50B813D8.1070705@computer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8667c32b199c4e1a48b28f3136efa9152b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Subject: Re: [manet] draft-ietf-manet-dymo-24x.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 02:04:59 -0000 Hello again folks, I forgot to mention that I have already submitted the Intermediate Route Reply document to the Internet Draft directories: http://www.ietf.org/internet-drafts/draft-perkins-irrep-02.txt It is compatible with the base draft, and uses the same approach to terminology. Regards, Charlie P. On 11/29/2012 6:03 PM, Charles E. Perkins wrote: > > Hello folks, > > I have completed the first really coherent revision of AODVv2 since I > took the editorial pen last year. I want to read through it just a > bit more, > and I expect to submit it to the Internet Draft directories tomorrow. > In the meantime, here is the current version: > http://www.psg.com/~charliep/txt/ietf85/draft-ietf-manet-dymo-24x.txt > > I have made a big effort to improve the readability and organization > of the text; other than that, there have been very few technical changes. > The section on precursors (optional feature) has been mostly rewritten, > and most other sections have had very heavy editing to reflect the > terminology revision. > > Some things clarified or changed or made more definite: > - When a node generates a RteMsg (RREQ or RREP), it always > increments its sequence number > - RFC 5444 compliance (many changes for this) > - New MsgTLV for RERR, to enable unicast route error to PktSource > - New MsgTLV for RREQ, to enable destination-only RREP > - SeqNum field required for all "Added Node" AddrBlk (optional > feature) > Making RREP and RREQ always to increment sequence number > some beneficial simplifications in route table update description. > > I think the only thing unfinished right now is to enable alternate > metrics. Some of the mechanism is specified (and was before in > DYMO) but it needs a few more paragraphs. If I can do that for > tomorrow, I will do so. > > Comments on the prerelease are, as always, welcome. > > I will also post some relevant issues to the Issue Tracker soon. > -- Regards, Charlie P. From sratliff@cisco.com Fri Nov 30 07:18:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844BF21F854D for ; Fri, 30 Nov 2012 07:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiK8NgOwYvWx for ; Fri, 30 Nov 2012 07:18:14 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2541B21F8543 for ; Fri, 30 Nov 2012 07:18:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2727; q=dns/txt; s=iport; t=1354288694; x=1355498294; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wID/ApBjx6v3uN7ItGEY3WCnkXC9JfrA3iROUzf/ZrM=; b=JJ0G8aZ8/iI6O4EmHqWOvRZ1znVn9MKm2VreY+BdIRcdKQIQ8eKSAx28 5wVCFOFibg84WXUjhQcOgxcJIDPrh9wvGNL+B46quVsg+g5CCnkoS4NRw P7MPAvm+td6Xk65uUAqoIXujhYbPIIBMTZg3lLjVcRDNKuoVuSqOYhpuE 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAP7NuFCtJV2Y/2dsb2JhbABEFr93FnOCHgEBAQMBAQEBNzQLEAIBCBgKFBAnCyUCBA4FCAGIAQYMv3aMQINgYQOSTpN2gnKCIQ X-IronPort-AV: E=McAfee;i="5400,1158,6911"; a="148003420" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 30 Nov 2012 15:17:55 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAUFHttP012326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Nov 2012 15:17:55 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.161]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Fri, 30 Nov 2012 09:17:55 -0600 From: "Stan Ratliff (sratliff)" To: "Charles E. Perkins" Thread-Topic: [manet] draft-ietf-manet-dymo-24x.txt Thread-Index: AQHNzp7dFgVNeQFDAk6UkwFVggW235gCBYGAgADdkoA= Date: Fri, 30 Nov 2012 15:17:54 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF00525@xmb-aln-x03.cisco.com> References: <50B813D8.1070705@computer.org> <50B81443.7030800@computer.org> In-Reply-To: <50B81443.7030800@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.115] Content-Type: text/plain; charset="us-ascii" Content-ID: <043EAC589DBDAD45B489FD22C1614536@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet Subject: Re: [manet] draft-ietf-manet-dymo-24x.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 15:18:16 -0000 Charlie,=20 Speaking as a WG participant, I'd rather see you submit the draft via the n= ormal process in order to get the WG's review.=20 Speaking as a WG co-chair, I'd *really* rather see you submit the draft bef= ore the WG invests the cycles in a review. How does inviting WG review of a= "prerelease" version of an accepted document improve the process? Regards, Stan On Nov 29, 2012, at 9:04 PM, Charles E. Perkins wrote: >=20 > Hello again folks, >=20 > I forgot to mention that I have already submitted the Intermediate > Route Reply document to the Internet Draft directories: > http://www.ietf.org/internet-drafts/draft-perkins-irrep-02.txt >=20 > It is compatible with the base draft, and uses the same > approach to terminology. >=20 > Regards, > Charlie P. >=20 >=20 > On 11/29/2012 6:03 PM, Charles E. Perkins wrote: >>=20 >> Hello folks, >>=20 >> I have completed the first really coherent revision of AODVv2 since I >> took the editorial pen last year. I want to read through it just a bit = more, >> and I expect to submit it to the Internet Draft directories tomorrow. >> In the meantime, here is the current version: >> http://www.psg.com/~charliep/txt/ietf85/draft-ietf-manet-dymo-24x.txt >>=20 >> I have made a big effort to improve the readability and organization >> of the text; other than that, there have been very few technical changes= . >> The section on precursors (optional feature) has been mostly rewritten, >> and most other sections have had very heavy editing to reflect the >> terminology revision. >>=20 >> Some things clarified or changed or made more definite: >> - When a node generates a RteMsg (RREQ or RREP), it always >> increments its sequence number >> - RFC 5444 compliance (many changes for this) >> - New MsgTLV for RERR, to enable unicast route error to PktSource >> - New MsgTLV for RREQ, to enable destination-only RREP >> - SeqNum field required for all "Added Node" AddrBlk (optional >> feature) >> Making RREP and RREQ always to increment sequence number >> some beneficial simplifications in route table update description. >>=20 >> I think the only thing unfinished right now is to enable alternate >> metrics. Some of the mechanism is specified (and was before in >> DYMO) but it needs a few more paragraphs. If I can do that for >> tomorrow, I will do so. >>=20 >> Comments on the prerelease are, as always, welcome. >>=20 >> I will also post some relevant issues to the Issue Tracker soon. >>=20 >=20 >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From charliep@computer.org Fri Nov 30 08:14:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDE421F8B4C for ; Fri, 30 Nov 2012 08:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0s-+k1Cl9KP9 for ; Fri, 30 Nov 2012 08:14:44 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC0521F8B13 for ; Fri, 30 Nov 2012 08:14:44 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TeTEh-0003bB-Dv; Fri, 30 Nov 2012 11:14:43 -0500 Message-ID: <50B8DB6C.4060904@computer.org> Date: Fri, 30 Nov 2012 08:14:36 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <50B813D8.1070705@computer.org> <50B81443.7030800@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF00525@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF00525@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad860a86ce358e64095bb9de54b9df6265b8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: manet Subject: Re: [manet] draft-ietf-manet-dymo-24x.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 16:14:45 -0000 Hello Stan, O.K. I was planning to submit it today anyway. It has been several weeks since the last MANET meeting, and I was happy to have beaten it into shape especially compared to the last two releases. You are right that people will spend their time more efficiently by waiting for the release to the Internet Drafts directories. Regards, Charlie P. On 11/30/2012 7:17 AM, Stan Ratliff (sratliff) wrote: > Charlie, > > Speaking as a WG participant, I'd rather see you submit the draft via the normal process in order to get the WG's review. > > Speaking as a WG co-chair, I'd *really* rather see you submit the draft before the WG invests the cycles in a review. How does inviting WG review of a "prerelease" version of an accepted document improve the process? > > Regards, > Stan > > On Nov 29, 2012, at 9:04 PM, Charles E. Perkins wrote: > >> Hello again folks, >> >> I forgot to mention that I have already submitted the Intermediate >> Route Reply document to the Internet Draft directories: >> http://www.ietf.org/internet-drafts/draft-perkins-irrep-02.txt >> >> It is compatible with the base draft, and uses the same >> approach to terminology. >> >> Regards, >> Charlie P. >> >> >> On 11/29/2012 6:03 PM, Charles E. Perkins wrote: >>> Hello folks, >>> >>> I have completed the first really coherent revision of AODVv2 since I >>> took the editorial pen last year. I want to read through it just a bit more, >>> and I expect to submit it to the Internet Draft directories tomorrow. >>> In the meantime, here is the current version: >>> http://www.psg.com/~charliep/txt/ietf85/draft-ietf-manet-dymo-24x.txt >>> >>> I have made a big effort to improve the readability and organization >>> of the text; other than that, there have been very few technical changes. >>> The section on precursors (optional feature) has been mostly rewritten, >>> and most other sections have had very heavy editing to reflect the >>> terminology revision. >>> >>> Some things clarified or changed or made more definite: >>> - When a node generates a RteMsg (RREQ or RREP), it always >>> increments its sequence number >>> - RFC 5444 compliance (many changes for this) >>> - New MsgTLV for RERR, to enable unicast route error to PktSource >>> - New MsgTLV for RREQ, to enable destination-only RREP >>> - SeqNum field required for all "Added Node" AddrBlk (optional >>> feature) >>> Making RREP and RREQ always to increment sequence number >>> some beneficial simplifications in route table update description. >>> >>> I think the only thing unfinished right now is to enable alternate >>> metrics. Some of the mechanism is specified (and was before in >>> DYMO) but it needs a few more paragraphs. If I can do that for >>> tomorrow, I will do so. >>> >>> Comments on the prerelease are, as always, welcome. >>> >>> I will also post some relevant issues to the Issue Tracker soon. >>> >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. From charliep@computer.org Fri Nov 30 11:58:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E508421F8A29 for ; Fri, 30 Nov 2012 11:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjLumKFv1w+0 for ; Fri, 30 Nov 2012 11:58:16 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC9B21F85C2 for ; Fri, 30 Nov 2012 11:58:16 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.253.71]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TeWj1-0005Q7-Hk for manet@ietf.org; Fri, 30 Nov 2012 14:58:15 -0500 Message-ID: <50B90FD1.6070909@computer.org> Date: Fri, 30 Nov 2012 11:58:09 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad867039cf33a740a4ee0c1a0bdd2c68cde2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Subject: [manet] Enabling alternate metrics X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 19:58:17 -0000 Hello folks, As mentioned in previous email, enabling alternate metrics has been a topic often discussed in the MANET working group. There seems to be wide recognition of the insufficiency of using HopCount. However, the selection of "best" route can be tricky, because that depends on the application. Also, some considerations from "draft-ietf-manet-olsrv2-metrics-rationale-01.txt" apply. If it is agreed that AODVv2 needs to enable specification for the use of alternate routing metrics, there is a relatively straightforward way to do it, as long as the purpose of doing so is also agreed as above. In the AODVv2 document, the main changes required are: - include the following new section - change discussion about HopCount to instead refer to "Cost()" - refer to a table of Metric Types (e.g., as in RFC 6551) - use abstract functions "Cost()" and "LoopFree()" - allow for storage of multiple routes to the same destination but which allow the metric type to identify different next hops. ======================================================================= 5.6. Enabling Alternate Metrics Route selection in AODVv2 MANETs depends upon associating metric information with each route table entry. When presented with candidate route update information, deciding whether to use the update involves evaluating the metric. Some applications may require the consideration of metric information other than Hop Count, which has traditionally been the default metric associated with routes in MANET. In fact, it is well known that reliance on Hop Count can cause selection of the worst possible route in many situations. It is beyond the scope of this document to describe how applications specify route selection at the time they launch processing. One possibility would be to provide a route metric preference as part of the library routines for opening sockets. In view of the above considerations, it is important to enable route selection based on metric information other than Hop Count -- in other words, based on "alternate metrics". Each such alternate metric identifies a "cost" of using the associated route, and there are many different kinds of cost (latency, delay, financial, energy, etc.). The most significant change when enabling use of alternate metrics is to require the possibility of multiple routes to the same destination, where the "cost" of each of the multiple routes is measured by a different alternate metric. The other change relevant to AODVv2 is that the method by which route updates are tested for usefulness has to be slightly generalized to depend upon a more abstract method of evaluation which, in this document, is named "Cost(R)", where 'R' is the route information to be evaluated. From the above, the route table information for 'R' must always include the type of metric by which Cost(R) is evaluated, so the metric type does not have to be shown as a distinct parameter for Cost(R). Since determining loop freedom is known to depend on comparing the Cost(R) of route update information to the Cost(R) of an existing stored route using the same metric, AODVv2 must also be able to invoke an abstract routine which in this document is called "LoopFree(R1, R2)". LoopFree(R1, R2) returns TRUE when, given that R2 is loop-free and Cost(R2) is the cost of route R2, Cost(R1) is known to guarantee loop freedom of the route R1. In this document, LoopFree(R1,R2) will only be invoked for routes R1 and R2 which use the same metric. Generally, HopCount may still be considered the default metric for use in MANETs, notwithstanding the above objections. Each metric has to have a Metric Type, and the Metric Type is allocated by IANA as specified in [RFC6551]. Each Route has to include the Metric Type as part of the route table entry for that route. Hop Count has Metric Type assignment 3. The Cost of a route using Metric Type 3 is naturally the Hop Count between the router and the destination. For routes R1 and R2 using Metric Type 3, LoopFree (R1, R2) is TRUE when Cost(R2) <= (Cost(R1) + 1). The specification of Cost(R) and LoopFree(R1,R2) for metric types other than 3 is beyond the scope of this document. ======================================================================= By the way, Ian always hated HopCount as a metric, and so there was always an attempt to specify DYMO to enable alternate metrics. To my understanding, however, that effort was incomplete. -- Regards, Charlie P. From abdussalambaryun@gmail.com Fri Nov 30 17:27:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7D421F89A5 for ; Fri, 30 Nov 2012 17:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lk95clWLRjFY for ; Fri, 30 Nov 2012 17:27:00 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E1E8821F89A4 for ; Fri, 30 Nov 2012 17:26:59 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so72419vbb.31 for ; Fri, 30 Nov 2012 17:26:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VJtLmcA8fF7wiCCIUEz0wEWZIr0HO6Njv9t0UFubgF8=; b=oI8bJR4p31exb5nfFdh4ZMIIAMWijgS22vy9OS6eY2kxA1nj0NxvTUabt1+isvPtkW JOv5PzXDwB4QJCX2EEIi6s0A+N91NrDvtSWBCf3KyUMD9ZEidZrtsQ5LNNEO20Mw1V5F 3Ph/tUoY+YOCiXcu46shPzAgTr8qW86rsn5HmHKcH5f9ZSh3pZqsg+O0XYPYZoOAXNvY 1yhL4gX8/bxa2846YjvT3NyHXi9yti5YwTKEiKjDLkaMftCjxmzq/1hYnCziG47sUNJw Y/biZScwfu0/pIAzxSYqshfnTR2TiVSj3XLLdPk9VvCNkFrMY9vM93qijWzo05E7DdAs JAfQ== MIME-Version: 1.0 Received: by 10.52.99.131 with SMTP id eq3mr2358098vdb.55.1354325219369; Fri, 30 Nov 2012 17:26:59 -0800 (PST) Received: by 10.220.145.5 with HTTP; Fri, 30 Nov 2012 17:26:59 -0800 (PST) In-Reply-To: <50B8DB6C.4060904@computer.org> References: <50B813D8.1070705@computer.org> <50B81443.7030800@computer.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FF00525@xmb-aln-x03.cisco.com> <50B8DB6C.4060904@computer.org> Date: Sat, 1 Dec 2012 02:26:59 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Cc: "Stan Ratliff \(sratliff\)" Subject: Re: [manet] draft-ietf-manet-dymo-24x.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 01:27:00 -0000 I don't mind either way processing it, as long our WG documents go forward, AB On 11/30/12, Charles E. Perkins wrote: > > Hello Stan, > > O.K. I was planning to submit it today anyway. It has been several > weeks since the last MANET meeting, and I was happy to have > beaten it into shape especially compared to the last two releases. > > You are right that people will spend their time more efficiently > by waiting for the release to the Internet Drafts directories. > > Regards, > Charlie P. > > > On 11/30/2012 7:17 AM, Stan Ratliff (sratliff) wrote: >> Charlie, >> >> Speaking as a WG participant, I'd rather see you submit the draft via the >> normal process in order to get the WG's review. >> >> Speaking as a WG co-chair, I'd *really* rather see you submit the draft >> before the WG invests the cycles in a review. How does inviting WG review >> of a "prerelease" version of an accepted document improve the process? >> >> Regards, >> Stan >> >> On Nov 29, 2012, at 9:04 PM, Charles E. Perkins wrote: >> >>> Hello again folks, >>> >>> I forgot to mention that I have already submitted the Intermediate >>> Route Reply document to the Internet Draft directories: >>> http://www.ietf.org/internet-drafts/draft-perkins-irrep-02.txt >>> >>> It is compatible with the base draft, and uses the same >>> approach to terminology. >>> >>> Regards, >>> Charlie P. >>> >>> >>> On 11/29/2012 6:03 PM, Charles E. Perkins wrote: >>>> Hello folks, >>>> >>>> I have completed the first really coherent revision of AODVv2 since I >>>> took the editorial pen last year. I want to read through it just a bit >>>> more, >>>> and I expect to submit it to the Internet Draft directories tomorrow. >>>> In the meantime, here is the current version: >>>> http://www.psg.com/~charliep/txt/ietf85/draft-ietf-manet-dymo-24x.txt >>>> >>>> I have made a big effort to improve the readability and organization >>>> of the text; other than that, there have been very few technical >>>> changes. >>>> The section on precursors (optional feature) has been mostly rewritten, >>>> and most other sections have had very heavy editing to reflect the >>>> terminology revision. >>>> >>>> Some things clarified or changed or made more definite: >>>> - When a node generates a RteMsg (RREQ or RREP), it always >>>> increments its sequence number >>>> - RFC 5444 compliance (many changes for this) >>>> - New MsgTLV for RERR, to enable unicast route error to PktSource >>>> - New MsgTLV for RREQ, to enable destination-only RREP >>>> - SeqNum field required for all "Added Node" AddrBlk (optional >>>> feature) >>>> Making RREP and RREQ always to increment sequence number >>>> some beneficial simplifications in route table update description. >>>> >>>> I think the only thing unfinished right now is to enable alternate >>>> metrics. Some of the mechanism is specified (and was before in >>>> DYMO) but it needs a few more paragraphs. If I can do that for >>>> tomorrow, I will do so. >>>> >>>> Comments on the prerelease are, as always, welcome. >>>> >>>> I will also post some relevant issues to the Issue Tracker soon. >>>> >>> >>> -- >>> Regards, >>> Charlie P. >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> > > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Fri Nov 30 18:21:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C4521F8699 for ; Fri, 30 Nov 2012 18:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUTzeARSEMRY for ; Fri, 30 Nov 2012 18:21:21 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EDA7F21F841E for ; Fri, 30 Nov 2012 18:21:20 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so98764vbb.31 for ; Fri, 30 Nov 2012 18:21:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iCCbOmbCaU1UGjayR3ksU1keVZFWbWZwk8LPBQTn0n8=; b=vZxz7tJw+LLxAPDowvpxngw0d1TA77/OxF0yJiVzkMZr9gP/KpTx8kVMq22iUzfwhT gqYSY/ykaur3A9MibXtW0q+nkZFBjpWVIX4Lu9EM3xSIj5AL85bN43OkuVL4nCRLDNj4 pHlQnmKhtDXX/ND5uWyYJwiW8uuaSBGEEn163XcC7Gum2YjutnjUew/m6o+Fnp4HFA1p sTgwnRX4VGio6HRLiRFFWFtrGc5/un+atn25+qIvbqEt4r0ouBNzFO3pjaYQogH1Czq1 +p3JjLzrJgaNI6/nY+VZal72gkH5mxUqGND/MF26E8NxqJNIzBVQY6v3PPqbA1/T8mgb Ulsw== MIME-Version: 1.0 Received: by 10.220.8.195 with SMTP id i3mr2693209vci.44.1354328480405; Fri, 30 Nov 2012 18:21:20 -0800 (PST) Received: by 10.220.145.5 with HTTP; Fri, 30 Nov 2012 18:21:20 -0800 (PST) In-Reply-To: <50B90FD1.6070909@computer.org> References: <50B90FD1.6070909@computer.org> Date: Sat, 1 Dec 2012 03:21:20 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Enabling alternate metrics X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 02:21:21 -0000 Hi Charlie, Regarding the suggested main changes required, as one was for possible of having multi-next-hop per dest, I am thinking to add another requirement; - All intermediate routers in the path to destination should have same metric type while forwarding packets to their nexthop, otherwise an error reported. AB On 11/30/12, Charles E. Perkins wrote: > Hello folks, > > As mentioned in previous email, enabling alternate metrics has been > a topic often discussed in the MANET working group. There seems to > be wide recognition of the insufficiency of using HopCount. However, > the selection of "best" route can be tricky, because that depends > on the application. Also, some considerations from > "draft-ietf-manet-olsrv2-metrics-rationale-01.txt" apply. > > If it is agreed that AODVv2 needs to enable specification for the > use of alternate routing metrics, there is a relatively straightforward > way to do it, as long as the purpose of doing so is also agreed as > above. > In the AODVv2 document, the main changes required are: > - include the following new section > - change discussion about HopCount to instead refer to "Cost()" > - refer to a table of Metric Types (e.g., as in RFC 6551) > - use abstract functions "Cost()" and "LoopFree()" > - allow for storage of multiple routes to the same destination > but which allow the metric type to identify different next hops. > > > ======================================================================= > > 5.6. Enabling Alternate Metrics > > Route selection in AODVv2 MANETs depends upon associating metric > information with each route table entry. When presented with > candidate route update information, deciding whether to use the > update involves evaluating the metric. Some applications may require > the consideration of metric information other than Hop Count, which > has traditionally been the default metric associated with routes in > MANET. In fact, it is well known that reliance on Hop Count can > cause selection of the worst possible route in many situations. > > It is beyond the scope of this document to describe how applications > specify route selection at the time they launch processing. One > possibility would be to provide a route metric preference as part of > the library routines for opening sockets. In view of the above > considerations, it is important to enable route selection based on > metric information other than Hop Count -- in other words, based on > "alternate metrics". Each such alternate metric identifies a "cost" > of using the associated route, and there are many different kinds of > cost (latency, delay, financial, energy, etc.). > > The most significant change when enabling use of alternate metrics is > to require the possibility of multiple routes to the same > destination, where the "cost" of each of the multiple routes is > measured by a different alternate metric. The other change relevant > to AODVv2 is that the method by which route updates are tested for > usefulness has to be slightly generalized to depend upon a more > abstract method of evaluation which, in this document, is named > "Cost(R)", where 'R' is the route information to be evaluated. From > the above, the route table information for 'R' must always include > the type of metric by which Cost(R) is evaluated, so the metric type > does not have to be shown as a distinct parameter for Cost(R). Since > determining loop freedom is known to depend on comparing the Cost(R) > of route update information to the Cost(R) of an existing stored > route using the same metric, AODVv2 must also be able to invoke an > abstract routine which in this document is called "LoopFree(R1, R2)". > LoopFree(R1, R2) returns TRUE when, given that R2 is loop-free and > Cost(R2) is the cost of route R2, Cost(R1) is known to guarantee loop > freedom of the route R1. In this document, LoopFree(R1,R2) will only > be invoked for routes R1 and R2 which use the same metric. > > Generally, HopCount may still be considered the default metric for > use in MANETs, notwithstanding the above objections. Each metric has > to have a Metric Type, and the Metric Type is allocated by IANA as > specified in [RFC6551]. Each Route has to include the Metric Type as > part of the route table entry for that route. Hop Count has Metric > Type assignment 3. The Cost of a route using Metric Type 3 is > naturally the Hop Count between the router and the destination. For > routes R1 and R2 using Metric Type 3, LoopFree (R1, R2) is TRUE when > Cost(R2) <= (Cost(R1) + 1). The specification of Cost(R) and > LoopFree(R1,R2) for metric types other than 3 is beyond the scope of > this document. > > ======================================================================= > > By the way, Ian always hated HopCount as a metric, and so there was > always an attempt to specify DYMO to enable alternate metrics. > To my understanding, however, that effort was incomplete. > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From internet-drafts@ietf.org Fri Nov 30 19:27:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6FE21F8502; Fri, 30 Nov 2012 19:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jsyc8W6H23st; Fri, 30 Nov 2012 19:27:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6C221F8554; Fri, 30 Nov 2012 19:27:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121201032732.9644.12784.idtracker@ietfa.amsl.com> Date: Fri, 30 Nov 2012 19:27:32 -0800 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 03:27:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Dynamic MANET On-demand (AODVv2) Routing Author(s) : Charles E. Perkins Ian D Chakeres Filename : draft-ietf-manet-dymo-24.txt Pages : 53 Date : 2012-11-30 Abstract: The Dynamic MANET On-demand (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering on-demand convergence in dynamic topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dymo There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-dymo-24 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-24 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From charliep@computer.org Fri Nov 30 19:36:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B8A21F8ACB for ; Fri, 30 Nov 2012 19:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swcseXws4CDk for ; Fri, 30 Nov 2012 19:36:53 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC4621F8AB3 for ; Fri, 30 Nov 2012 19:36:53 -0800 (PST) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Tedsq-0007uS-KB for manet@ietf.org; Fri, 30 Nov 2012 22:36:52 -0500 Message-ID: <50B97B4D.60209@computer.org> Date: Fri, 30 Nov 2012 19:36:45 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: manet References: <20121201032732.9644.98468.idtracker@ietfa.amsl.com> In-Reply-To: <20121201032732.9644.98468.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121201032732.9644.98468.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------060609080506050501060302" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86d84f993a5aa07e201355f500ddbd0f4f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Subject: [manet] Fwd: New Version Notification for draft-ietf-manet-dymo-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 03:36:54 -0000 This is a multi-part message in MIME format. --------------060609080506050501060302 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello folks, The new AODVv2 draft has been posted. I put in the necessary specification to enable alternate metrics; more discussion is needed for this point. I noticed at the last minute that there were some mistakes in the example message formats in the Appendices. I think that I fixed most or all of them, but today I have run out of time. Nevertheless, instead of waiting until next week to post the draft, I have submitted it today in case anyone would like to have it available during the week. Somehow I don't think it will be the last version anyway. Another thing I did not do is to re-verify that it is compatible with the latest version of LOADng. If there are incompatibilities, I expect them to be minor, but as always everything is open for discussion. If there is a desire to specify Cost() functions for other alternate metrics, that will require more discussion. I know this has been discussed before, and in other working groups as well. Whether the discussion would result in further changes to the AODVv2 document, I don't know. In the meantime, we can just have HopCount to be the only fully specified metric for AODVv2. There are some issues that may need to be posted to the Issue Tracker, possibly including: - whether SeqNum == 0 should be a reserved value - whether a packet with alternate metric is recoverable when a handling node does not understand the metric. - whether msg-hop-count can be relied on to count hops of a RteMsg - whether msg-orig-addr can be relied on to indicate the IP address of the originator of a message - whether msg-hop-count *really* has to be initialized to zero. Have a great weekend! Regards, Charlie P. PS. The draft for Intermediate RREP needs to be updated to account for minor differences introduced by enabling alternate metrics. -------- Original Message -------- Subject: New Version Notification for draft-ietf-manet-dymo-24.txt Date: Fri, 30 Nov 2012 19:27:32 -0800 From: internet-drafts@ietf.org To: charliep@computer.org CC: ian.chakeres@gmail.com A new version of I-D, draft-ietf-manet-dymo-24.txt has been successfully submitted by Charles E. Perkins and posted to the IETF repository. Filename: draft-ietf-manet-dymo Revision: 24 Title: Dynamic MANET On-demand (AODVv2) Routing Creation date: 2012-12-01 WG ID: manet Number of pages: 53 URL: http://www.ietf.org/internet-drafts/draft-ietf-manet-dymo-24.txt Status: http://datatracker.ietf.org/doc/draft-ietf-manet-dymo Htmlized: http://tools.ietf.org/html/draft-ietf-manet-dymo-24 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dymo-24 Abstract: The Dynamic MANET On-demand (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering on-demand convergence in dynamic topologies. The IETF Secretariat --------------060609080506050501060302 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hello folks,

The new AODVv2 draft has been posted.  I put in the necessary specification
to enable alternate metrics; more discussion is needed for this point.

I noticed at the last minute that there were some mistakes in the example
message formats in the Appendices.  I think that I fixed most or all of them,
but today I have run out of time.  Nevertheless, instead of waiting until
next week to post the draft, I have submitted it today in case anyone
would like to have it available during the week.  Somehow I don't think
it will be the last version anyway.

Another thing I did not do is to re-verify that it is compatible with the
latest version of LOADng.  If there are incompatibilities, I expect them to
be minor, but as always everything is open for discussion.

If there is a desire to specify Cost() functions for other alternate metrics,
that will require more discussion.  I know this has been discussed before,
and in other working groups as well.  Whether the discussion would result
in further changes to the AODVv2 document, I don't know.  In the meantime,
we can just have HopCount to be the only fully specified metric for AODVv2.

There are some issues that may need to be posted to the Issue Tracker,
possibly including:
- whether SeqNum == 0 should be a reserved value
- whether a packet with alternate metric is recoverable when
   a handling node does not understand the metric.
- whether msg-hop-count can be relied on to count hops of
   a RteMsg
- whether msg-orig-addr can be relied on to indicate the IP address
   of the originator of a message
- whether msg-hop-count *really* has to be initialized to zero.

Have a great weekend!

Regards,
Charlie P.

PS. The draft for Intermediate RREP needs to be updated to
       account for minor differences introduced by enabling
       alternate metrics.


-------- Original Message --------
Subject: New Version Notification for draft-ietf-manet-dymo-24.txt
Date: Fri, 30 Nov 2012 19:27:32 -0800
From: internet-drafts@ietf.org
To: charliep@computer.org
CC: ian.chakeres@gmail.com 


A new version of I-D, draft-ietf-manet-dymo-24.txt
has been successfully submitted by Charles E. Perkins and posted to the
IETF repository.

Filename:	 draft-ietf-manet-dymo
Revision:	 24
Title:		 Dynamic MANET On-demand (AODVv2) Routing
Creation date:	 2012-12-01
WG ID:		 manet
Number of pages: 53
URL:             http://www.ietf.org/internet-drafts/draft-ietf-manet-dymo-24.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-manet-dymo
Htmlized:        http://tools.ietf.org/html/draft-ietf-manet-dymo-24
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dymo-24

Abstract:
   The Dynamic MANET On-demand (AODVv2) routing protocol is intended for
   use by mobile routers in wireless, multihop networks.  AODVv2
   determines unicast routes among AODVv2 routers within the network in
   an on-demand fashion, offering on-demand convergence in dynamic
   topologies.

                                                                                  


The IETF Secretariat


--------------060609080506050501060302--
On Nov 2, 2012, at 11:22 AM, "Dearlove, Christopher (UK)" = <There is, = superficially at least, an apparent contradiction between your = points:

- DYMO cannot be end-to-end secured. Messages are changed = in transit
(and not just hop-limit or the metric), but rather = addresses can be
removed from RERRs and RREQs.

which = implicitly suggests LOADng does not do this

and 

- LOADng uses a = Metric message TLV, and it is clearly defined how to
update the = metric under way.

Could you expand on this please?

-- 
Christopher = Dearlove
Senior Principal Engineer, Communications = Group
Communications, Networks and Image Analysis Capability
BAE = Systems Advanced Technology Centre
West Hanningfield Road, Great = Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 | =  Fax: +44 1245 242124
 |  
Sent: 01 November 2012 = 22:02
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; = Thomas Heide Clausen (thomas@thomasclausen.org)
Subject: Re: [manet] = Reactive routing protocols, what are the = differences?

----------------------! WARNING ! = ----------------------
This message originates from outside our = organisation,
either from an external partner or from the = internet.
Keep this in mind if you answer this message.
Follow the = 'Report Suspicious Emails' link on IT matters
for instructions on = reporting suspicious email = messages.
--------------------------------------------------------
<= br>Hi Chris,

you have seen my review on DYMO. I will try to = answer to your
question, and focus on the technical differences, not = presentation.


On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, = Christopher (UK)
<Chris.Dearlove@baesystems.com> = wrote:


The obviously best = people to answer this should be document authors, but anyone else may = have useful additions and comments. Ideally the different document = authors could agree a list. (If they differ in that one has X and the = other doesn't, but one wants to say "we plan to add/remove X" then X = should be listed as a difference with that caveat, in at least my ideal = world.)

If we set aside, for the moment (though these things = matter):
- The presentational quality of the documents,
- Any = issues of 5444 compliance and other formatting issues,
- Issues of = internal data organisation,
- Minor details such as possible = different timeout parameters etc.
then what are the technical (and I = stress that word) differences between DYMO and LOADng? (I'm withholding = the term AODVv2 for reasons I may come back = to.)


First, let's = see what is common. Both are reactive protocols, using
RREQ, RREP and = RERR. So if someone claims that DYMO performs great and
LOADng badly = in the same scenario, I cannot understand that. MANET has
understood = the scenarios where reactive protocols are useful and = where
not.

Now, to the differences:

- DYMO cannot be = end-to-end secured. Messages are changed in transit
(and not just = hop-limit or the metric), but rather addresses can be
removed from = RERRs and RREQs. There is also no provision to allow
external = mechanisms to add additional reasons to reject messages = as
invalid.
- DYMO uses the originator address in an address = block, LOADng in the
message header. The sequence number is a TLV = value in DYMO, and LOADng
uses the message sequence number. DYMO = requires the originator address
to be the first one in the address = block, the destination must be the
second one. LOADng uses a TLV to = determine the target address.
- DYMO can advertise multiple addresses = in an RERR; they can be
removed in transit of the message.
- DYMO = allows intermediate routers to reply (as an option). That = makes
end-to-end security difficult. In the core DYMO, there is = a
destination sequence number that may be contained in RREQs in = DYMO.
- DYMO allows for unicast RREQ, but does not specify in detail = how to use that.
- There are four timers for each route entry in = DYMO, only one in LOADng.
- LOADng can be used on other layers; DYMO = is tied to IP.
- LOADng provides a bidirectionality verification = using RREP_ACK, a
time-out of these, a blacklisted set and a Pending = Acknowledgment Set
to verify bidirectional links. DYMO says that = other mechanisms can be
used, but does not specify these.
- DYMO = has several options for expanding ring RREQ, precursor list,
adding = route information in transit, message aggregation in RFC5444
packets = and reporting multiple unreachable addresses in a RERR. LOADng
takes = the approach to have a slim core of a basic mechanism that = is
applicable in all MANET use cases, and companion documents = with
extensions. In DYMO, it is not clearly specified what happens if = some
routers support an option, and others don't.
- LOADng uses a = Metric message TLV, and it is clearly defined how to
update the = metric under way. If a router in transit does not recognize
a route = metric type, it is reset to a "hop count" tlv extension type
of the = Metric TLV and the value set to 0xFFFFF... (for the full TLV
length). = It is specified that security mechanism must ignore the
content of = the metric TLV value and that the length cannot be changed
under way, = so that end-to-end security is possible. DYMO uses an
optional = "distance" field for the metric, which is not clearly
specified how = it is updated. Also, since this is optional, it is
unclear if routers = receiving a message and forwarding it, update the
distance field or = not.
- LOADng allows for (optionally) waiting to reply with a RREP, = in case
a "better" RREQ comes a little later. In DYMO, a RREP is = always sent
immediately.

There are probably more differences, = but I let other chime in.

Best = regards
Ulrich




Note that it's a lot more useful to have direct differences = than differences of each from AODV (especially when both have the same = difference). And it would be useful to have the objective differences = separated from the "and now why this is better" discussion - though that = would be a next step.

I'm not saying I don't see any of the = differences. But I certainly haven't worked out the complete list. In = trying to form my view of how things should go forward (a view that is = coming together, and when it does, I'll argue for it) and I hope for = other people as well, it would be good to know what the differences are. = Regardless of views for or against each, we should be able to = objectively list the significant differences - if we can't then = something is wrong.

--
Christopher Dearlove
Senior = Principal Engineer, Communications Group
Communications, Networks and = Image Analysis Capability
BAE Systems Advanced Technology = Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, = UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
 | 
_______________________________________________
manet = mailing list
 List" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 13:02:19 -0000 --bcaec54a37fabe1d3b04cd82be7f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Teco, The chair's 3 options suggested were confusing because the 3rd was not wanted, I hope we get cooperative options and directions that we can agree on, as you mentioned Teco I noticed that all want a reactive protocol as standard, so lets start to delet option 3 and all object to that, and focus to base our efforts on MANET charter and participants interests AB On Fri, Nov 2, 2012 at 12:18 PM, Teco Boot wrote: > @Stan, > > I think you and Joe should do whatever you can, as chairs, to get our wor= k > done. I have seen confusion on what chairs had in mind with this polling. > Can you guide the discussion? > > Thanks, Teco > > Op 1 nov. 2012, om 21:11 heeft Stan Ratliff het volgende geschreven: > > JP, > > Speaking for myself (not necessarily for Joe, as I haven't discussed with > him a couple of days), my intent with the email was to bring the situatio= n > vis-a-vis reactive protocols to the WG's attention, and to see if the gro= up > coalesces around any of the three options. > > To be frank, based on the last 3 months of discussion, and the current > email storm (including references to the "toxic environment"), I believe > that the situation has passed to point of no return. I do not think the > respective authors, or the WG as a whole, will ever (or at least for the > foreseeable future) be able to reach consensus on a reactive protocol. > Therefore, my preference is to remove the work item from the charter. > > Let's see how the discussion progresses. > > Regards, > Stan > > On Thu, Nov 1, 2012 at 3:36 PM, JP Vasseur (jvasseur) wrote: > >> Agree with you Don. >> >> Since discussions are going in many directions =85 would the chairs help= us >> organize these discussions ? >> >> Are you indeed asking us to express our preference for one of these >> options, pick one and start from there ? >> >> On Nov 1, 2012, at 7:40 PM, Don Sturek wrote: >> >> Hi Charlie, >> >> Apologies if I misrepresented the facts on DYMO/AODVv2=85=85 >> >> I do think the facts as exist right now are: >> 1) We have a LOADng draft that claims support to address the MANET >> reactive protocol requirements >> 2) Work has restarted (by yourself) on DYMO/AODVv2 >> 3) There are two different views on the ability to merge LOADng with >> DYMO/AODVv2. One view is the merge can happen and another (unfortunately= by >> some authors of LOADng) that such a merge is impractical. >> >> So, irrespective of how we got to where we are, the point is it is a goo= d >> time to draw a conclusion on which of the 3 options above MANET should t= ake >> to meet its requirement for a reactive routing protocol. >> >> Don >> >> >> From: "Charles E. Perkins" >> Organization: Saratoga Blue Skies >> Date: Thursday, November 1, 2012 11:32 AM >> To: Don Sturek >> Cc: "manet@ietf.org" >> >> Subject: Re: [manet] Reactive Protocol Situation >> >> >> Hello Don, >> >> Your claim has been made several times, and I think it is highly >> misleading. >> >> The bottom line is that the editorship of the WG document is now in good >> hands, and given the time available in the past, good progress has been >> made. Also given my renewed emphasis, support from my job, and clear >> understanding of goals, I can confidently state that I can do the work, >> and >> can manage the editorship process to follow working group discussion to >> completion. Here is (some of) what happened. I hope you will read it. >> >> I was asked last fall to resume editorship of the DYMO document, and >> agreed to do so. >> >> Almost at the same time, I was invited to work with the LOADng authors >> to produce a merged document that incorporated the best features from >> DYMO and from LOADng. At that time, the general agreement was that >> the merged document would be renamed AODVv2. >> >> Because of various personal difficulties unfamiliar in my experience, I >> was >> surprised to find very late in the winter that the merge was not >> happening. >> In order to carry out my responsibility, which was clearly to submit a >> revised document for IETF 83 in Paris, I took the resource available to = me >> and within less than a week I submitted the revised DYMO draft renamed >> to be AODVv2. >> >> People attending the meeting will remember what happened. I was quite >> unjustly attacked and called names for doing: >> a) what I said I would do >> b) what I was supposed to do, and >> c) changing the document to become more compatible with LOADng, as >> requested by those authors and according to my best understanding. >> >> After that, I still hoped that we could do the merge, but nothing happen= ed >> until in Vancouver when the WG chairs gave us an ultimatum to make >> something happen by November. >> >> We went around and around, but I eventually determined that there >> was almost no chance that the LOADng authors would willingly help to >> produce the desired merge. So I did what the LOADng authors had asked >> me not to do: namely submit a revised document for consideration. >> This revised document was an attempt to respond to valid comments >> made during 2010 about problems with the document while it was >> under Ian's editorial responsibility. It needs further revision -- in >> fact >> I will submit a much more polished document on my website this >> week. >> >> The important point is that for the last year the document languished >> for all but a few weeks *at the request of the LOADng authors* -- >> in fact, I would even say at their *DEMAND*, and all the while they >> refused to help make the merge that (a) they had originally suggested >> and (b) I was supposed to do. >> >> This note is already too long. I have much, much more to say. >> But I will say one more thing: I have the ability and now the time to >> do an excellent job on this, and I am here on the job only for the >> benefit of the working group. Now that I can focus on it, and now >> that I do not feel constrained to abide by the demands for delay >> that were imposed by the LOADng author team, I can do it pretty >> expediently. Of course I will welcome their input as well, and to >> further reiterate it will be my intention to make the WG document >> compatible with the needs of LOADng. >> >> Oh -- and one more thing... Regardless of the poisoned atmosphere >> surrounding this debate, I have nothing but high regard for the work >> done by the LOADng team. I don't think their methods are right for >> this working group, and any statements to the effect that the DYMO >> editorial process has been deficient during the last year or more >> should be understood in light of the above narrative. >> >> Regards, >> Charlie P. >> >> PS. Oh, and one more thing... I am a peaceful man, and if I don't >> respond to all the invective and intransigence so clearly >> in evidence lately, you'll just have to excuse me for trying >> to remain so. >> >> >> On 11/1/2012 9:40 AM, Don Sturek wrote: >> >> Hi Adbussalam, >> >> It is hard to consider a draft stalled 2+ years as the only way forward >> in MANET as a reactive protocol. >> >> Don >> >> >> >> From: Abdussalam Baryun >> Date: Thursday, November 1, 2012 8:53 AM >> To: Jon Black >> Cc: "manet@ietf.org" , Stan Ratliff >> >> Subject: Re: [manet] Reactive Protocol Situation >> >> Yes LOADng is a reactive protocols, but not the MANET WG reactive >> protocol (DYMO is already authorised). The WG is the only authorised to >> make such decisions for its WG drafts, if WG decides to add any LOADng >> ideas it can, or to accept such merge it can as well, >> AB >> On Thu, Nov 1, 2012 at 3:37 PM, Jon Black wrote: >> >>> Why would you think that LOADng is not reactive? If it is not a >>> reactive protocol, then what is it? >>> >>> As to merging the documents, this is what WGs do. If you have multiple >>> "competing" ideas you ask the authors to see if they can merge their >>> concepts and ideas. If they cannot or will not then the WG must decide >>> based on facts and not conjecture which is the most prudent path to tak= e. >>> >>> Jon >>> >>> >>> ------------------------------ >>> *From:* Abdussalam Baryun >>> *To:* Joseph Macker >>> *Cc:* manet@ietf.org; Stan Ratliff >>> *Sent:* Thursday, November 1, 2012 8:22 AM >>> >>> *Subject:* Re: [manet] Reactive Protocol Situation >>> >>> Dear Joseph Macker and Stan, >>> MANET WG Chairs >>> >>> I disagree that the WG arranged/guided to merge the documents, I never >>> heard that there was a consensus on such activity. DYMO is a reactive W= G >>> draft, but LOADng is not. Why did you guide to merge documents, I recom= mend >>> that you ment to merge the team drafts co-authors to one WG draft (whic= h is >>> only DYMO so far). The authority is for the WG to decide to merge >>> individual drafts to its WG draft. >>> >>> Therefore, my vote is for option 1 only. Thanking you for updating us >>> with the status. >>> >>> Regards >>> AB >>> >>> On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker wr= ote: >>> >>> Hello MANET working group (form Stan and Joe), >>> >>> As you are all probably aware, there has been WG activity lately on >>> competing drafts for a MANET reactive protocol - DYMO (reviving the cur= rent >>> working group document that was parked due to inactivity), and LOADng. = Many >>> months ago there was a somewhat authorship led movement towards a commo= n >>> document effort and given positive feedback at the time we the chairs >>> thought this was the best approach given the authors potential to come >>> together and gain the best of both efforts. Since that period, there h= as >>> been some fairly strident and rancorous "at times" debate between the >>> authors of the two documents. >>> >>> During IETF 84 in Vancouver, the co-chairs held a discussion with some >>> of the co-authors of the two documents. Our guidance to the co-authors = was >>> to find a way to merge the two documents into one, as it was perceived = that >>> are not technically far apart and they both derive roughly from AODV >>> concepts and LOADng had fairly active authorship and implementation >>> efforts. We provided a co-editing proposal to the authors and gave them= the >>> timeframe of the Atlanta to come up with an answer back to us regarding >>> this. As of this writing, those discussions of a potential commonn >>> document and authorship merger have failed. >>> >>> Therefore, we find ourselves at a crossroads. The authors of the two >>> documents are divided, and it is unlikely that progress on a merged >>> document can be reached based upon recent author feedback. I have also >>> polled the earlier WG editor of DYMO, Ian Chakeres, and he is somewhat >>> disengaged on the issue at the present time. We see only 3 possible pa= ths >>> forward: >>> >>> 1. Continue the work on the DYMO document, starting with whether there >>> is consensus on its continued approach and also the desire to rename it= to >>> AODVv2. >>> 2. Replace the existing DYMO document effort with the LOADng related >>> document effort, defusing ealier references to LLNs as recommended in t= he >>> last meeting minutes, and to focus more motivationally on general MANET >>> problem spaces (the authors seem to have agreed to this issue if its a = WG >>> document). >>> 3. Remove the working group charter for a reactive protocol, effectivel= y >>> killing both documents, at least from a working group (WG) standpoint. = This >>> would not be a reflection on the technology in either case, just an >>> admission that we are not working together and reaching consensus. >>> >>> The co-chairs request and need your opinions on the options. We have >>> been some silent collecting initial feedback and waiting for author >>> feedback at this point. Stan and I are both on travel prior to Atlanta= so >>> our responses may be sparse and we will also likely be in a "receive mo= de" >>> for a few days. So send your opinions. >>> >>> -Joe >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> >> _______________________________________________ manet mailing list >> manet@ietf.org https://www.ietf.org/mailman/listinfo/manet >> >> >> _______________________________________________ >> manet mailing listmanet@ietf.orghttps://www.ietf.org/mailman/listinfo/ma= net >> >> >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > > > -- > Regards, > Stan > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --bcaec54a37fabe1d3b04cd82be7f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Teco,
=A0
The chair's 3 options suggested were confusing because the 3rd was= not=A0wanted, I hope we get cooperative options and directions that we can= agree on, as you mentioned Teco I noticed that all want a reactive protoco= l as standard, so lets start to delet option 3 and all object to that, and = focus to base our efforts on MANET charter and participants interests
=A0
AB

On Fri, Nov 2, 2012 at 12:18 PM, Teco Boot <teco@= inf-net.nl> wrote:
@Stan,=20

I think you and Joe should do whatever you can, as chairs, to get our = work done.=A0I have seen confusion on what chairs had in mind with this pol= ling. Can you guide the discussion?

Thanks, Teco

Op 1 nov. 2012, om 21:11 heeft Stan Ratliff het volgende geschreven:
JP,

Speaking for myself (not necessarily = for Joe, as I haven't discussed with him a couple of days), my intent w= ith the email was to bring the situation vis-a-vis reactive protocols to th= e WG's attention, and to see if the group coalesces around any of the t= hree options.

To be frank, based on the last 3 months of discussion, and the current = email storm (including references to the "toxic environment"), I = believe that the situation has passed to point of no return. I do not think= the respective authors, or the WG as a whole, will ever (or at least for t= he foreseeable future) be able to reach consensus on a reactive protocol. T= herefore, my preference is to remove the work item from the charter.

Let's see how the discussion progresses.

Regards,
Stan
On Thu, Nov 1, 2012 at 3:36 PM, JP Vasseur (jvas= seur) <jvasseur@cisco.com> wrote:
Agree with you Don.=20

Since discussions are going in many directions =85 would the chairs he= lp us organize these discussions ?

Are you indeed asking us to express our preference for one of these op= tions, pick one and start from there ?

On Nov 1, 2012, at 7:40 PM, Don Sturek wrote:

Hi Charlie,

Apologies if I misrepresented the facts on DYMO/AODVv2=85=85

I do think the facts as exist right now are:
1) =A0We have a LOADng draft that claims support to address the MANET = reactive protocol requirements
2) =A0Work has restarted (by yourself) on DYMO/AODVv2
3) =A0There are two different views on the ability to merge LOADng wit= h DYMO/AODVv2. One view is the merge can happen and another (unfortunately = by some authors of LOADng) that such a merge is impractical.

So, irrespective of how we got to where we are, the point is it is a g= ood time to draw a conclusion on which of the 3 options above MANET should = take to meet its requirement for a reactive routing protocol.

Don


From: "Charles E. Perkins"= ; <charliep@c= omputer.org>
Organization: Saratoga Blue Skies
Date: Thursday, November 1, 2012 11= :32 AM
To: Don Sturek <d.sturek@att.net>Cc: "manet@ietf.org" <manet@ietf.org>=20

Subject: Re: = [manet] Reactive Protocol Situation


Hello Don,

Your claim has been made several times, and I th= ink it is highly misleading.

The bottom line is that the editorship = of the WG document is now in good
hands, and given the time available in= the past, good progress has been
made.=A0 Also given my renewed emphasis, support from my job, and clear
= understanding of goals, I can confidently state that I can do the work, and=
can manage the editorship process to follow working group discussion to=
completion.=A0 Here is (some of) what happened.=A0 I hope you will read it.=

I was asked last fall to resume editorship of the DYMO document, an= d
agreed to do so.

Almost at the same time, I was invited to work= with the LOADng authors
to produce a merged document that incorporated the best features from
DY= MO and from LOADng.=A0 At that time, the general agreement was that
the = merged document would be renamed AODVv2.

Because of various personal= difficulties unfamiliar in my experience, I was
surprised to find very late in the winter that the merge was not happening.=
In order to carry out my responsibility, which was clearly to submit a<= br>revised document for IETF 83 in Paris, I took the resource available to = me
and within less than a week I submitted the revised DYMO draft renamed
t= o be AODVv2.

People attending the meeting will remember what happene= d.=A0 I was quite
unjustly attacked and called names for doing:
a) wh= at I said I would do
b) what I was supposed to do, and
c) changing the document to become mor= e compatible with LOADng, as
=A0=A0=A0 requested by those authors and ac= cording to my best understanding.

After that, I still hoped that we = could do the merge, but nothing happened
until in Vancouver when the WG chairs gave us an ultimatum to make
somet= hing happen by November.

We went around and around, but I eventually= determined that there
was almost no chance that the LOADng authors woul= d willingly help to
produce the desired merge.=A0 So I did what the LOADng authors had askedme not to do: namely submit a revised document for consideration.
This = revised document was an attempt to respond to valid comments
made during= 2010 about problems with the document while it was
under Ian's editorial responsibility.=A0 It needs further revision -- i= n fact
I will submit a much more polished document on my website thisweek.

The important point is that for the last year the document la= nguished
for all but a few weeks *at the request of the LOADng authors* --
in fac= t, I would even say at their *DEMAND*, and all the while they
refused to= help make the merge that (a) they had originally suggested
and (b) I wa= s supposed to do.

This note is already too long.=A0 I have much, much more to say.
Bu= t I will say one more thing: I have the ability and now the time to
do a= n excellent job on this, and I am here on the job only for the
benefit o= f the working group.=A0 Now that I can focus on it, and now
that I do not feel constrained to abide by the demands for delay
that we= re imposed by the LOADng author team, I can do it pretty
expediently.=A0= Of course I will welcome their input as well, and to
further reiterate = it will be my intention to make the WG document
compatible with the needs of LOADng.

Oh -- and one more thing...=A0 = Regardless of the poisoned atmosphere
surrounding this debate, I have no= thing but high regard for the work
done by the LOADng team.=A0 I don'= ;t think their methods are right for
this working group, and any statements to the effect that the DYMO
edito= rial process has been deficient during the last year or more
should be u= nderstood in light of the above narrative.

Regards,
Charlie P.
PS. Oh, and one more thing...=A0 I am a peaceful man, and if I don'= t
=A0=A0=A0=A0=A0=A0=A0 respond to all the invective and intransigence s= o clearly
=A0=A0=A0=A0=A0=A0=A0 in evidence lately, you'll just have= to excuse me for trying
=A0=A0=A0=A0=A0=A0=A0 to remain so.


On 11/1/2012 9:40 AM, Don St= urek wrote:
Hi Adbussalam,

It is hard to consider a draft stalled 2+ years as the only way forwar= d in MANET as a reactive protocol.

Don



From: Abdussalam Baryun <abdussalambaryun@g= mail.com>
Date: Thursday,= November 1, 2012 8:53 AM
To: Jon Black <jblack.ietf@yahoo.com>
= Cc: "manet@ietf.org" <manet@ietf.org>, Stan Ratliff <<= a href=3D"mailto:sratliff@cisco.com" target=3D"_blank">sratliff@cisco.com>=20

Subject: Re: = [manet] Reactive Protocol Situation

Yes LOADng is a reactive protocols, but not the MANET=A0WG reactive pr= otocol (DYMO is already authorised). The WG is the only authorised to make = such decisions for its WG drafts, if WG decides to add any LOADng ideas it = can, or to accept such merge it can as well,
AB
On Thu, Nov 1, 2012 at 3:37 PM, Jon Black <= jblack.ietf@yahoo.com> wrote:
Why would you think that LOADng is not reactive?=A0 If it is not a reac= tive protocol, then what is it?

As to merging the documents, this is= what WGs do.=A0 If you have multiple "competing" ideas you ask t= he authors to see if they can merge their concepts and ideas.=A0 If they ca= nnot or will not then the WG must decide based on facts and not conjecture = which is the most prudent path to take.

Jon


From: Abdussalam Baryun <= abdussalamb= aryun@gmail.com>
To: Joseph Macker <jpmacker@gmail.com>
Cc: manet@ietf.org; Stan Ratliff <sratliff@cisco.com> Sent: Thursday, November 1= , 2012 8:22 AM=20

Subject: Re: [manet= ] Reactive Protocol Situation

Dear Joseph Macker and Stan,
MANET WG Chairs
=A0
I disagree that the=A0WG=A0arranged/guided to merge the documents, I n= ever heard that there was a consensus on such activity. DYMO is a reactive = WG draft, but LOADng is not. Why did you guide to merge documents, I recomm= end that you ment to merge the team drafts co-authors to one=A0WG draft (wh= ich is only DYMO so far). The authority is for the WG to decide to merge in= dividual drafts to its WG draft.
=A0
Therefore, my vote is for option 1 only. Thanking you for updating us = with the status.
=A0
Regards
AB

On Tue, Oct 30, 2012 at 11:13 PM, Joseph Macker <= jp= macker@gmail.com> wrote:
Hello MANET working group (form S= tan and Joe),

As you are all probably aware, there has been WG activ= ity lately on competing drafts for a MANET reactive protocol - DYMO (revivi= ng the current working group document that was parked due to inactivity), a= nd LOADng. Many months ago there was a somewhat authorship led movement tow= ards a common document effort and given positive feedback at the time we th= e chairs thought this was the best approach given the authors potential to = come together and gain the best of both efforts.=A0 Since that period, ther= e has been some fairly strident and rancorous "at times" debate b= etween the authors of the two documents.

During IETF 84 in Vancouver, the co-chairs held a discussion with some = of the co-authors of the two documents. Our guidance to the co-authors was = to find a way to merge the two documents into one, as it was perceived that= are not technically far apart and they both derive roughly from AODV conce= pts and LOADng had fairly active authorship and implementation efforts. We = provided a co-editing proposal to the authors and gave them the timeframe o= f the Atlanta to come up with an answer back to us regarding this.=A0 As of= this writing, those discussions of a potential commonn document and author= ship merger have failed.

Therefore, we find ourselves at a crossroads. The authors of the two do= cuments are divided, and it is unlikely that progress on a merged document = can be reached based upon recent author feedback. I have also polled the ea= rlier WG editor of DYMO, Ian Chakeres, and he is somewhat disengaged on the= issue at the present time.=A0 We see only 3 possible paths forward:

1. Continue the work on the DYMO document, starting with whether there = is consensus on its continued approach and also the desire to rename it to = AODVv2.
2. Replace the existing DYMO document effort with the LOADng rel= ated document effort, defusing ealier references to LLNs as recommended in = the last meeting minutes, and to focus more motivationally on general MANET= problem spaces (the authors seem to have agreed to this issue if its a WG = document).
3. Remove the working group charter for a reactive protocol, effectively ki= lling both documents, at least from a working group (WG) standpoint. This w= ould not be a reflection on the technology in either case, just an admissio= n that we are not working together and reaching consensus.

The co-chairs request and need your opinions on the options.=A0 We have= been some silent collecting initial feedback and waiting for author feedba= ck at this point.=A0 Stan and I are both on travel prior to Atlanta so our = responses may be sparse and we will also likely be in a "receive mode&= quot; for a few days.=A0 So send your opinions.

-Joe

_______________________________________________
manet ma= iling list
manet@ietf.org
https://www.ietf.org/mailman/= listinfo/manet



_______________________________________________
manet = mailing list
manet@i= etf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________ manet= mailing list manet@iet= f.org https://www.ietf.org/mailman/listinfo/manet 


____________________________________________=
___
manet mailing list
manet@ietf.orghttps:=
//www.ietf.org/mailman/listinfo/manet


--=20
Regards,
Charlie P.
___________________________= ____________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/li= stinfo/manet


_______________________________________________
ma= net mailing list
man= et@ietf.org
https://www.ietf.org/mailman/listinfo/manet



<= font color=3D"#888888">
--
Regards,
Stan=20


_______________________________________________manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


______________________________= _________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--bcaec54a37fabe1d3b04cd82be7f-- From Martin.Heusse@imag.fr Fri Nov 2 07:00:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A173121F8A40 for ; Fri, 2 Nov 2012 07:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiBeFbUuY7ha for ; Fri, 2 Nov 2012 07:00:55 -0700 (PDT) Received: from rominette.imag.fr (mx2.imag.fr [IPv6:2001:660:5301:59::17]) by ietfa.amsl.com (Postfix) with ESMTP id E7E2221F8A2B for ; Fri, 2 Nov 2012 07:00:54 -0700 (PDT) Received: from globule.imag.fr (globule.imag.fr [129.88.34.238]) by rominette.imag.fr (8.13.8/8.13.8) with ESMTP id qA2Dqk77023778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Nov 2012 14:52:46 +0100 Received: from scilly.imag.fr (scilly.imag.fr [129.88.48.164]) (authenticated bits=0) by globule.imag.fr (8.13.8/8.13.8) with ESMTP id qA2E0kHU024703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Nov 2012 15:00:46 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Martin Heusse In-Reply-To: Date: Fri, 2 Nov 2012 15:01:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> References: To: manet@ietf.org X-Mailer: Apple Mail (2.1283) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (rominette.imag.fr [129.88.30.17]); Fri, 02 Nov 2012 14:52:46 +0100 (CET) X-IMAG-MailScanner-Information: Please contact MI2S MIM for more information X-MailScanner-ID: qA2Dqk77023778 X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-SpamCheck: X-IMAG-MailScanner-From: martin.heusse@imag.fr MailScanner-NULL-Check: 1352469170.61622@Hli8NNPqdrmmC/pKajhQZQ Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 14:00:55 -0000 I'm standing for option 2 (LOADng). I think it's better to agree first on a simple basic (versatile?) = protocol before proposing extensions to it; instead of starting from a = collection of ideas that can be used or not (and we know today what are = the options, thank to the huge amount of work done on reactive routing = during the past years). Conversely, it would be certainly easier to = reach a consensus on a set of variants but we need a good reference = point, first.=20 Moreover, reactive routing is most probably the approach that one would = pick for a simple case. So it should be simple...=20 Martin Le 2 nov. 2012 =E0 01:58, Joydeep Tripathi a =E9crit : > I can understand that for an LLN it may be beneficial for not = maintaining a precursor list or having only the destination reply t o a = RREQ, there can be (and are) other instances of MANETs where having the = option of precursor list will come handy. This can save on control = overhead, using some storage space in the node. LOAD-ng, in most cases = does not provide this flexibility to the developer to chose between = options for specific deployment. Some MANET deployment may be less harsh = than others in nature. Hence, AODVv2 having more open options than = LOAD-ng, in most cases, seem beneficial to me.=20 From Chris.Dearlove@baesystems.com Fri Nov 2 07:01:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BE421F8AA3 for ; Fri, 2 Nov 2012 07:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.54 X-Spam-Level: X-Spam-Status: No, score=-10.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-Yw+xCwNYEv for ; Fri, 2 Nov 2012 07:01:51 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 17BCC21F8A9F for ; Fri, 2 Nov 2012 07:01:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,699,1344207600"; d="scan'208,217";a="283222764" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 02 Nov 2012 14:01:47 +0000 Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id qA2E1kvZ020974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 14:01:47 GMT Received: from GLKXM0002V.GREENLNK.net ([169.254.2.7]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Fri, 2 Nov 2012 14:01:46 +0000 From: "Dearlove, Christopher (UK)" To: Teco Boot Thread-Topic: [manet] Reactive routing protocols, what are the differences? Thread-Index: Ac24S9gO52XASJQwQb67c7wvLBVIbQAMK9OAABnHRpAAASp5gAABOJ7QAAGNRoAAADmmIAABbuMAAAFgAqA= Date: Fri, 2 Nov 2012 14:01:46 +0000 Message-ID: References: <12708D7E-C548-4858-8144-6F04D2750E02@jiaziyi.com> <4F9C6208-78B8-41B1-81D2-C7DAAE9D780D@jiaziyi.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6C4BGLKXM0002VGREEN_" MIME-Version: 1.0 Cc: "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 14:01:54 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6C4BGLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, of course there can be malicious routers with link state protocols. I'= ve even helped implement one. But everything used is a link, and all links = are carried in messages/packets, and if all messages/packets are authentica= ted, then all links are authenticated, and hence no malicious routers are i= ncluded. But the RREQ/RREP process (at its simplest) uses information that is not in= cluded in any message. Going back to OLSRv2, yes, all routers will have to agree on a process. But= that's another discussion that I won't get into right now. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Teco Boot [mailto:teco@inf-net.nl] Sent: 02 November 2012 13:00 To: Dearlove, Christopher (UK) Cc: Jiazi YI; manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.or= g) Subject: Re: [manet] Reactive routing protocols, what are the differences? *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Op 2 nov. 2012, om 13:32 heeft Dearlove, Christopher (UK) het volgende gesc= hreven: I understand the basics. And I agree I can't see (except my bracketed aside= ) how to do it without a mutable field. But having that mutable field reduc= es the value of the argument against DYMO from "DYMO is mutable, LOADng is = not" to "DYMO is (uncontrolled?) mutable, LOADng is managed mutable". I'm n= ot convinced by the argument about having to mutate metric type. If you can= 't rely on it being available to your network layer protocol consistently i= n the one MANET, heterogeneous though it may be, I'm not sure you have a we= ll-put-together network. You could always make the metrioc increment when u= nknown the maximum such value. But there is, as another post raised, the larger question of what end to en= d message authentication buys you. If in a route A-B-X-C-D, where X is a ba= d guy, if X relays all RREQs and RREPs flawlessly, but throws all data pack= ets on the floor, X has done his job, and without needing to forge anything= . You also need B and/or C to authenticate X. Lower layer? (in which case w= hy can't that do the whole job?). There could be 2nd order nodes: hosts. Or the routing protocol security mec= hanism is implemented in the routing deamon, which is very similar to the f= irst. RREP-ACK? Accumulating signature? Something else? (Note that a link state protocol gets the B-X and X-C done. Those are, afte= r all, links.) There can be malicious routers with link state protocols too. Also, there is a requirement that all routers share the same policy on what= to do with failed authentication, and result of checking must be the same = on all nodes. Not easy to deploy. And missing in olsrv2 core protocol. Teco -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI Sent: 02 November 2012 12:13 To: Dearlove, Christopher (UK) Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Cla= usen (thomas@thomasclausen.org) Subject: Re: [manet] Reactive routing protocols, what are the differences? *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Hi, The reason that LOADng needs those fields mutable is to support different m= etrics other than hop-count, even routers using different metrics in the sa= me routing domain can at least find a path. To support different metric types, a metric-type tlv and a route-metric tlv= are needed. The route-metric tlv has to be mutable because it needs to be = updated at each hop. Having metric-type tlv mutable can make supporting different metrics in the= same network possible. It's common that in a heterogenous network, there are various transmission = medias (802.11, 802.15.4, cable, PLC...), therefore possible different metr= ics. In LOADng, if a router A (with metric-A) gets an RREQ message that it doesn= 't understand (say, metric-B), router A will change the metric-type to HOP_= COUNT, and forward the message (the hop-count field is always used). For th= e destination of RREQ, it will first consider the metrics that it understan= ds, and then HOP_COUNT. Of course, this will result in "degrading" to HOP_C= OUNT for certain routes, but at least we can get a usable route. I'm just introducing the design of LOADng, and would appreciate any good id= ea on this issue. best Jiazi On Nov 2, 2012, at 12:42 PM, "Dearlove, Christopher (UK)" > wrote: Having anything other than hop limit and hop count mutable is not the secur= ity mechanism suggested in 6622/5444. I'm of the view that the current approach of securing NHDP, securing OLSRv2= etc. is not where things should ideally be, that the ideal place is at the= 5444 multiplexer wherever possible. If doing hop by hop security, then tha= t is the place, as it's where packets live. But if we could do it once for = all message types, then that's a major gain. Now as soon as LOADng has anything else mutable, that doesn't help that. OK= , it's better than nothing, but those fields are buried in TLVs (using 5444= ) and messy. I'm at a disadvantage, I haven't studied why LOADng needs those fields (oth= er than hop count) mutable - or if it really does. But it reduces "here's a= clear advantage over DYMO" to "here's a more partial advantage over DYMO".= And I think Ulrich's summary could be edited to better present this. So if we adopted my separate proposal, this would be on the menu: why are t= hose fields mutable? Do they have to be? Can we find an alternative? (Unfor= tunately, I can see why probably not. But it's still a question.) [Actually I can see an alternative, which is a much more limited metric, wh= ich takes small integer values, and we increase hop count not by one but by= this metric, limiting paths to maximum 255 metric. We could still get hop = count from hop limit if we knew how it started - e.g. in a non-mutable TLV.= But I strongly doubt this is good enough.] -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of J= iazi YI Sent: 02 November 2012 10:54 To: Dearlove, Christopher (UK) Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Cla= usen (thomas@thomasclausen.org) Subject: Re: [manet] Reactive routing protocols, what are the differences? *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Hi Chris, I think Ulrich is in deep sleep at the moment, so please allow me to have s= ome words on this. For reactive protocols, updating the route information (hop-count, metric) = is inevitable. In the specification of DYMO, the messages can be changed re= latively arbitrarily, including removing addresses from the messages. The i= ntermediate RREP also makes end-to-end security impossible. LOADng clearly defines which fields in the routing messages can't be change= d, and which fields are mutable. For example, for RREQ: The following fields of an RREQ message are immutable, i.e., they MUST NOT = be changed during processing or forwarding of the message: RREQ.addr-length= , RREQ.seq-num, RREQ.originator, and RREQ.destination. The following fields of an RREQ message are mutable, i.e., they will be cha= nged by intermediate routers during processing or forwarding, as specified = in Section 12.2 and Section 12.3: RREQ.metric-type, RREQ.route-metric, and RREQ.hop-co= unt. Any additional field that is added to the message by an extension to this p= rotocol, e.g., by way of TLVs, MUST be considered immutable, unless the ext= ension specifically defines the field as mutable. This allows the protocol to secure the messages by zeroing the mutable fiel= ds. best Jiazi (sorry to Chris if you received multiple copy of this message. I fixed one = typo though :) My previous one was bounced by manet mailing list because of= not using the right sender address) On Nov 2, 2012, at 11:22 AM, "Dearlove, Christopher (UK)" > wrote: There is, superficially at least, an apparent contradiction between your po= ints: - DYMO cannot be end-to-end secured. Messages are changed in transit (and not just hop-limit or the metric), but rather addresses can be removed from RERRs and RREQs. which implicitly suggests LOADng does not do this and - LOADng uses a Metric message TLV, and it is clearly defined how to update the metric under way. Could you expand on this please? -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Ulrich Herberg [mailto:ulrich@herberg.name] Sent: 01 November 2012 22:02 To: Dearlove, Christopher (UK) Cc: manet@ietf.org; Thomas Heide Clausen (thomas@tho= masclausen.org) Subject: Re: [manet] Reactive routing protocols, what are the differences? ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi Chris, you have seen my review on DYMO. I will try to answer to your question, and focus on the technical differences, not presentation. On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK) > wrote= : The obviously best people to answer this should be document authors, but an= yone else may have useful additions and comments. Ideally the different doc= ument authors could agree a list. (If they differ in that one has X and the= other doesn't, but one wants to say "we plan to add/remove X" then X shoul= d be listed as a difference with that caveat, in at least my ideal world.) If we set aside, for the moment (though these things matter): - The presentational quality of the documents, - Any issues of 5444 compliance and other formatting issues, - Issues of internal data organisation, - Minor details such as possible different timeout parameters etc. then what are the technical (and I stress that word) differences between DY= MO and LOADng? (I'm withholding the term AODVv2 for reasons I may come back= to.) First, let's see what is common. Both are reactive protocols, using RREQ, RREP and RERR. So if someone claims that DYMO performs great and LOADng badly in the same scenario, I cannot understand that. MANET has understood the scenarios where reactive protocols are useful and where not. Now, to the differences: - DYMO cannot be end-to-end secured. Messages are changed in transit (and not just hop-limit or the metric), but rather addresses can be removed from RERRs and RREQs. There is also no provision to allow external mechanisms to add additional reasons to reject messages as invalid. - DYMO uses the originator address in an address block, LOADng in the message header. The sequence number is a TLV value in DYMO, and LOADng uses the message sequence number. DYMO requires the originator address to be the first one in the address block, the destination must be the second one. LOADng uses a TLV to determine the target address. - DYMO can advertise multiple addresses in an RERR; they can be removed in transit of the message. - DYMO allows intermediate routers to reply (as an option). That makes end-to-end security difficult. In the core DYMO, there is a destination sequence number that may be contained in RREQs in DYMO. - DYMO allows for unicast RREQ, but does not specify in detail how to use t= hat. - There are four timers for each route entry in DYMO, only one in LOADng. - LOADng can be used on other layers; DYMO is tied to IP. - LOADng provides a bidirectionality verification using RREP_ACK, a time-out of these, a blacklisted set and a Pending Acknowledgment Set to verify bidirectional links. DYMO says that other mechanisms can be used, but does not specify these. - DYMO has several options for expanding ring RREQ, precursor list, adding route information in transit, message aggregation in RFC5444 packets and reporting multiple unreachable addresses in a RERR. LOADng takes the approach to have a slim core of a basic mechanism that is applicable in all MANET use cases, and companion documents with extensions. In DYMO, it is not clearly specified what happens if some routers support an option, and others don't. - LOADng uses a Metric message TLV, and it is clearly defined how to update the metric under way. If a router in transit does not recognize a route metric type, it is reset to a "hop count" tlv extension type of the Metric TLV and the value set to 0xFFFFF... (for the full TLV length). It is specified that security mechanism must ignore the content of the metric TLV value and that the length cannot be changed under way, so that end-to-end security is possible. DYMO uses an optional "distance" field for the metric, which is not clearly specified how it is updated. Also, since this is optional, it is unclear if routers receiving a message and forwarding it, update the distance field or not. - LOADng allows for (optionally) waiting to reply with a RREP, in case a "better" RREQ comes a little later. In DYMO, a RREP is always sent immediately. There are probably more differences, but I let other chime in. Best regards Ulrich Note that it's a lot more useful to have direct differences than difference= s of each from AODV (especially when both have the same difference). And it= would be useful to have the objective differences separated from the "and = now why this is better" discussion - though that would be a next step. I'm not saying I don't see any of the differences. But I certainly haven't = worked out the complete list. In trying to form my view of how things shoul= d go forward (a view that is coming together, and when it does, I'll argue = for it) and I hope for other people as well, it would be good to know what = the differences are. Regardless of views for or against each, we should be = able to objectively list the significant differences - if we can't then som= ething is wrong. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** 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. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6C4BGLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, of course there can = be malicious routers with link state protocols. I've even helped implement = one. But everything used is a link, and all links are carried in messages/packets, and if all messages/packets are authenticated, then a= ll links are authenticated, and hence no malicious routers are included.

 <= /p>

But the RREQ/RREP process= (at its simplest) uses information that is not included in any message.

 <= /p>

Going back to OLSRv2, yes= , all routers will have to agree on a process. But that's another discussio= n that I won't get into right now.

 <= /p>

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (O= perations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 <= /p>

From: Teco Boot [mailto:teco@inf-net.nl]
Sent: 02 November 2012 13:00
To: Dearlove, Christopher (UK)
Cc: Jiazi YI; manet@ietf.org; Thomas Heide Clausen (thomas@thomascla= usen.org)
Subject: Re: [manet] Reactive routing protocols, what are the differ= ences?

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

 

Op 2 nov. 2012, om 13:32 heeft Dearlove, Christopher= (UK) het volgende geschreven:



I understand the basics. = And I agree I can't see (except my bracketed aside) how to do it without a = mutable field. But having that mutable field reduces the value of the argument against DYMO from "DYMO is mutable, LOADng is n= ot" to "DYMO is (uncontrolled?) mutable, LOADng is managed mutabl= e". I'm not convinced by the argument about having to mutate metric ty= pe. If you can't rely on it being available to your network layer protocol consistently in the one MANET, heterogeneous though= it may be, I'm not sure you have a well-put-together network. You could al= ways make the metrioc increment when unknown the maximum such value.=

 <= /p>

But there is, as another = post raised, the larger question of what end to end message authentication = buys you. If in a route A-B-X-C-D, where X is a bad guy, if X relays all RREQs and RREPs flawlessly, but throws all data packets on= the floor, X has done his job, and without needing to forge anything. You = also need B and/or C to authenticate X. Lower layer? (in which case why can= 't that do the whole job?).

There could be 2nd order nodes: hosts. Or the routin= g protocol security mechanism is implemented in the routing deamon, which i= s very similar to the first.



RREP-ACK? Accumulating si= gnature? Something else?

 <= /p>

(Note that a link state p= rotocol gets the B-X and X-C done. Those are, after all, links.)

There can be malicious routers with link state proto= cols too. 

Also, there is a requirement that all routers share = the same policy on what to do with failed authentication, and result of che= cking must be the same on all nodes. Not easy to deploy. And missing in ols= rv2 core protocol.

 

Teco

 



 <= /p>

--

Christopher Dearlove

Senior Principal Engineer= , Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124<= /o:p>

= chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 <= /p>

From: Jiazi YI [mailto:yi.jiazi@gmail.com] = On Behalf Of Jiazi YI
Sent: 02 November = 2012 12:13
To: Dearlove, Chri= stopher (UK)
Cc: Ulrich Herberg= ; manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.org)
Subject: Re: [mane= t] Reactive routing protocols, what are the differences?<= /p>

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see = this process = on= how to deal with suspicious emails.

Hi,




The reason that LOADng needs those fields mutable is to support dif= ferent metrics other than hop-count, even routers using different metrics in the same routing domain can at least find a path. <= /span>




To support different metric types, a metric-type tlv and a route-me= tric tlv are needed. The route-metric tlv has to be mutable because it needs to be updated at each hop. =

Having metric-type tlv mutable can make supporting different metric= s in the same network possible. 




It's common that in a heterogenous network, there are various trans= mission medias (802.11, 802.15.4, cable, PLC...), therefore possible different metrics.

In LOADng, if a router A (with metric-A) gets an RREQ message that = it doesn't understand (say, metric-B), router A will change the metric-type to HOP_COUNT, and forward the message (the hop-count field= is always used). For the destination of RREQ, it will first consider the m= etrics that it understands, and then HOP_COUNT. Of course, this will result= in "degrading" to HOP_COUNT for certain routes, but at least we can get a usable route. 




I'm just introducing the design of LOADng, and would appreciate any= good idea on this issue. 




best




Jiazi

 

 

 

On Nov 2, 2012, at 12:42 PM, "Dearlove, Christo= pher (UK)" <Chris.= Dearlove@baesystems.com> wrote:




Having anything other tha= n hop limit and hop count mutable is not the security mechanism suggested i= n 6622/5444.

 <= /p>

I'm of the view that the = current approach of securing NHDP, securing OLSRv2 etc. is not where things= should ideally be, that the ideal place is at the 5444 multiplexer wherever possible. If doing hop by hop security, then that is = the place, as it's where packets live. But if we could do it once for all m= essage types, then that's a major gain.

 <= /p>

Now as soon as LOADng has= anything else mutable, that doesn't help that. OK, it's better than nothin= g, but those fields are buried in TLVs (using 5444) and messy.

 <= /p>

I'm at a disadvantage, I = haven't studied why LOADng needs those fields (other than hop count) mutabl= e - or if it really does. But it reduces "here's a clear advantage over DYMO" to "here's a more partial advantage over DY= MO". And I think Ulrich's summary could be edited to better present th= is.

 <= /p>

So if we adopted my separ= ate proposal, this would be on the menu: why are those fields mutable? Do t= hey have to be? Can we find an alternative? (Unfortunately, I can see why probably not. But it's still a question.)<= /p>

 <= /p>

[Actually I can see an al= ternative, which is a much more limited metric, which takes small integer v= alues, and we increase hop count not by one but by this metric, limiting paths to maximum 255 metric. We could still get hop count= from hop limit if we knew how it started - e.g. in a non-mutable TLV. But = I strongly doubt this is good enough.]

 <= /p>

--

Christopher Dearlove

Senior Principal Engineer= , Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124<= /o:p>

= chris.dearlove@baesystems.com | http://www.baes= ystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 <= /p>

From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiaz= i YI
Sent: 02 November = 2012 10:54
To: Dearlove, Chri= stopher (UK)
Cc: Ulrich Herberg= ; manet@ietf.org; Thomas H= eide Clausen (thomas@thomasclausen.org)
Subject: Re: [mane= t] Reactive routing protocols, what are the differences?<= /p>

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see = this process = on how to deal with suspicious emails.

Hi C= hris, 





I th= ink Ulrich is in deep sleep at the moment, so please allow me to have some = words on this. 





For = reactive protocols, updating the route information (hop-count, metric) is i= nevitable. In the specification of DYMO, the messages can be changed relatively arbitrarily, including removing addresses from the m= essages. The intermediate RREP also makes end-to-end security impossible.&n= bsp;





LOAD= ng clearly defines which fields in the routing messages can't be changed, a= nd which fields are mutable. For example, for RREQ:





The = following fields of an RREQ message are immutable, i.e., they MUST NOT be c= hanged during processing or forwarding of the message: RREQ.addr-length, RR= EQ.seq-num, RREQ.originator, and RREQ.destination.

The = following fields of an RREQ message are mutable, i.e., they will be changed= by intermediate routers during processing or forwarding, as specified in&n= bsp;Section 12.2 and Section 12.3: RREQ.metric-type, RREQ.route-metric, and RREQ.hop-count.=

Any = additional field that is added to the message by an extension to this proto= col, e.g., by way of TLVs, MUST be considered immutable, unless the extensi= on specifically defines the field as mutable.





This= allows the protocol to secure the messages by zeroing the mutable fields.&= nbsp;





best=





Jiaz= i 





(sor= ry to Chris if you received multiple copy of this message. I fixed one typo= though :) My previous one was bounced by manet mailing list because of not using the right sender address)

 

 

On Nov 2, 2012, at 11:22 AM, "Dearlove, Christo= pher (UK)" <Chris.Dearlove@baesystems.com> wrote:<= o:p>





There is, superficially at least, an apparent contra= diction between your points:

- DYMO cannot be end-to-end secured. Messages are changed in transit
(and not just hop-limit or the metric), but rather addresses can be
removed from RERRs and RREQs.

which implicitly suggests LOADng does not do this

and 

- LOADng uses a Metric message TLV, and it is clearly defined how to
update the metric under way.

Could you expand on this please?

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.b= aesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Ulrich Herberg [mailto:ulrich@herberg.name] 
Sent: 01 November 2012 22:02
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; Thomas= Heide Clausen (thomas@thomasclausen.org)
Subject: Re: [manet] Reactive routing protocols, what are the differences?<= br>
----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hi Chris,

you have seen my review on DYMO. I will try to answer to your
question, and focus on the technical differences, not presentation.


On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK)
<Chris.Dearlove@baesystems.com> wrote:



The obviously best people to answer this should be d= ocument authors, but anyone else may have useful additions and comments. Id= eally the different document authors could agree a list. (If they differ in= that one has X and the other doesn't, but one wants to say "we plan to add/remove X" then X should be = listed as a difference with that caveat, in at least my ideal world.)

If we set aside, for the moment (though these things matter):
- The presentational quality of the documents,
- Any issues of 5444 compliance and other formatting issues,
- Issues of internal data organisation,
- Minor details such as possible different timeout parameters etc.
then what are the technical (and I stress that word) differences between DY= MO and LOADng? (I'm withholding the term AODVv2 for reasons I may come back= to.)



First, let's see what is common. Both are reactive protocols, using
RREQ, RREP and RERR. So if someone claims that DYMO performs great and
LOADng badly in the same scenario, I cannot understand that. MANET has
understood the scenarios where reactive protocols are useful and where
not.

Now, to the differences:

- DYMO cannot be end-to-end secured. Messages are changed in transit
(and not just hop-limit or the metric), but rather addresses can be
removed from RERRs and RREQs. There is also no provision to allow
external mechanisms to add additional reasons to reject messages as
invalid.
- DYMO uses the originator address in an address block, LOADng in the
message header. The sequence number is a TLV value in DYMO, and LOADng
uses the message sequence number. DYMO requires the originator address
to be the first one in the address block, the destination must be the
second one. LOADng uses a TLV to determine the target address.
- DYMO can advertise multiple addresses in an RERR; they can be
removed in transit of the message.
- DYMO allows intermediate routers to reply (as an option). That makes
end-to-end security difficult. In the core DYMO, there is a
destination sequence number that may be contained in RREQs in DYMO.
- DYMO allows for unicast RREQ, but does not specify in detail how to use t= hat.
- There are four timers for each route entry in DYMO, only one in LOADng. - LOADng can be used on other layers; DYMO is tied to IP.
- LOADng provides a bidirectionality verification using RREP_ACK, a
time-out of these, a blacklisted set and a Pending Acknowledgment Set
to verify bidirectional links. DYMO says that other mechanisms can be
used, but does not specify these.
- DYMO has several options for expanding ring RREQ, precursor list,
adding route information in transit, message aggregation in RFC5444
packets and reporting multiple unreachable addresses in a RERR. LOADng
takes the approach to have a slim core of a basic mechanism that is
applicable in all MANET use cases, and companion documents with
extensions. In DYMO, it is not clearly specified what happens if some
routers support an option, and others don't.
- LOADng uses a Metric message TLV, and it is clearly defined how to
update the metric under way. If a router in transit does not recognize
a route metric type, it is reset to a "hop count" tlv extension t= ype
of the Metric TLV and the value set to 0xFFFFF... (for the full TLV
length). It is specified that security mechanism must ignore the
content of the metric TLV value and that the length cannot be changed
under way, so that end-to-end security is possible. DYMO uses an
optional "distance" field for the metric, which is not clearly specified how it is updated. Also, since this is optional, it is
unclear if routers receiving a message and forwarding it, update the
distance field or not.
- LOADng allows for (optionally) waiting to reply with a RREP, in case
a "better" RREQ comes a little later. In DYMO, a RREP is always s= ent
immediately.

There are probably more differences, but I let other chime in.

Best regards
Ulrich





Note that it's a lot more useful to have direct diff= erences than differences of each from AODV (especially when both have the s= ame difference). And it would be useful to have the objective differences s= eparated from the "and now why this is better" discussion - though that would be a next step.

I'm not saying I don't see any of the differences. But I certainly haven't = worked out the complete list. In trying to form my view of how things shoul= d go forward (a view that is coming together, and when it does, I'll argue = for it) and I hope for other people as well, it would be good to know what the differences are. Regardless of = views for or against each, we should be able to objectively list the signif= icant differences - if we can't then something is wrong.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.b= aesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687



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

_______________________________________________
manet mailing list
manet@ietf.o= rg
https://www.ietf.or= g/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.o= rg
https://www.ietf.or= g/mailman/listinfo/manet

 

_________________________________________= ______
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

 

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB6C4BGLKXM0002VGREEN_-- From ulrich@herberg.name Fri Nov 2 07:41:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D500D21F8ACE for ; Fri, 2 Nov 2012 07:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dxf-PEy2Add for ; Fri, 2 Nov 2012 07:41:52 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05C7521F8AC2 for ; Fri, 2 Nov 2012 07:41:51 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so2522245pad.31 for ; Fri, 02 Nov 2012 07:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=6VFS/lOVNTcUIZPVTQt9Emc3gKuP+LLboiQ/Az3FffE=; b=dvNBNMtkN0bao4tzXqbyi4Y0Krmr/iCj25nPpkmuf6OjfhkaxoI2zTliGbEpdWc5wq RRnlOWa+JTHIGEOaDf+JBxJdogs/kGHf9ZCwTIbszJR7watWlH6vu7cg1YeFDTmYs4qN 0nP61J4b++LSl6Rnelj/wUYFk9E570u6ZeorU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=6VFS/lOVNTcUIZPVTQt9Emc3gKuP+LLboiQ/Az3FffE=; b=JOhqfV+W2A27nFBTM6kLR2rblfbU1n2+HM7tLBfYaZJyISnAPujaUAm2VYIdNHiHR3 1yu+GkFmbRavUMrMNuHb+0x5SA65PG/T5s6rnPDqiVoc0nm68g99b+a+XTIlA90/Uf7U Jj765XL1064f7ikVAoMJ5d90Jp9JKh8o0VeFtRcAPxLQPtaJ/HQ0OmkfVOAJExnarz/1 l5nGEbvi/6qHPtQDuy4mHD6GvPTF0fbxTWAngj8jv8UDvYDr7ZTCyvGF4hNLsN5AbtGv zVWR+omE8/oVMXqX62YYZ472xscDJm6gQeXx4vyey6CSP5c4hxstJuWi+6SHvc0E+UHO gaSA== Received: by 10.68.245.169 with SMTP id xp9mr6718675pbc.142.1351867311733; Fri, 02 Nov 2012 07:41:51 -0700 (PDT) Received: from [10.0.1.5] (c-76-102-41-234.hsd1.ca.comcast.net. [76.102.41.234]) by mx.google.com with ESMTPS id v9sm5832383paz.6.2012.11.02.07.41.49 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 07:41:50 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> X-Mailer: iPad Mail (10A403) From: Ulrich Herberg Date: Fri, 2 Nov 2012 07:41:49 -0700 To: "Dearlove, Christopher (UK)" X-Gm-Message-State: ALoCoQmwkNVHsVAKkUZndLBUFs/0kun4vgcX8KTJCzoYBI7w8tQyfzLF6S8f5aophKl3D5MQvj1a Cc: "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 14:41:52 -0000 Dear Chris, personally, what you propose makes sense to me.=20 Regards Ulrich On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" wrote: > Before making a proposal, I'm going to introduce a distinction here betwee= n the DYMO and LOADng documents and protocols. >=20 > I'm of the opinion that the LOADng document is a greatly superior presenta= tion to the DYMO document. (I'm not really interested in why that has come a= bout.) >=20 > I think that regardless of whether one makes design decisions favouring DY= MO or LOADng where they differ - and let's not forget they overlap a lot - i= t would actually be easier to modify the LOADng document to specify DYMO tha= n it would be to modify the DYMO document to achieve that. And in practice I= think if making decisions it is unlikely that all would favour DYMO over LO= ADng. >=20 > So what I think would be best for the WG is not a simply "option 1" or eve= n (as it may appear I'm suggesting, but I'm not) "option 2" but rather to a= gree to take the LOADng document, and a list of where DYMO and LOADng differ= , and thrash out where they do, what the WG reactive protocol should do - ei= ther as a definite choice, or as an option (but not too many options please-= and some could be separate specifications). >=20 > This would not of course be LOADng, so we'd have to change the document na= me. And there I suggest we have a candidate name - AODVv2. (Which is why I h= ave recently taken to saying DYMO when referring to that document.) After al= l, the one thing we are agreed on is that the protocol being developed is de= rived from AODV. >=20 > The editors of this new document would have to agree that what goes in it i= s WG consensus (which should follow proper technical consideration of the is= sues). If they found it impossible to have other than their way to do things= , they'd have to move on. If that left no one editing it, obviously we don't= have a consensus of people prepared to do the work and option 3 would win. >=20 > So now I'm partly off the fence I've been sitting on. But only partly. I h= aven't yet formed a view on e.g. should this AODVv2 have IRREPs as standard,= IRREPs as an option in the main draft, IRREPs as a separate draft option, n= o IRREPs. I'd like to move on to those discussions. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 >=20 > ******************************************************************** > 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. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From yuichi.igarashi.hb@hitachi.com Fri Nov 2 07:54:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505B821F8AD5 for ; Fri, 2 Nov 2012 07:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTTIK44GYyBk for ; Fri, 2 Nov 2012 07:54:47 -0700 (PDT) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by ietfa.amsl.com (Postfix) with ESMTP id A54FD21F8AD1 for ; Fri, 2 Nov 2012 07:54:47 -0700 (PDT) Received: from mlsv4.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 85AC737AC3 for ; Fri, 2 Nov 2012 23:54:46 +0900 (JST) Received: from mfilter04.hitachi.co.jp by mlsv4.hitachi.co.jp (8.13.1/8.13.1) id qA2EskKN023018; Fri, 2 Nov 2012 23:54:46 +0900 Received: from vshuts01.hitachi.co.jp (vshuts01.hitachi.co.jp [10.201.6.83]) by mfilter04.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id qA2Esj7O031633 for ; Fri, 2 Nov 2012 23:54:46 +0900 Received: from vshuts2.hitachi.co.jp (unknown [10.201.6.71]) by vshuts01.hitachi.co.jp (Postfix) with ESMTP id 76FFB2F0050 for ; Fri, 2 Nov 2012 23:54:45 +0900 (JST) X-AuditID: b753bd60-963e4ba000004744-f0-5093deb564d6 Received: from hsdlmain.sdl.hitachi.co.jp (unknown [133.144.14.194]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id 452688B031B for ; Fri, 2 Nov 2012 23:54:45 +0900 (JST) Received: from hsdlvgate2.sdl.hitachi.co.jp by hsdlmain.sdl.hitachi.co.jp (8.13.8/3.7W11021512) id qA2EsjfA015228; Fri, 2 Nov 2012 23:54:45 +0900 X-AuditID: b753bd60-963e4ba000004744-f0-5093deb564d6 Received: from sdl99w.sdl.hitachi.co.jp (sdl99w.sdl.hitachi.co.jp [133.144.14.250]) by hsdlvgate2.sdl.hitachi.co.jp (Symantec Mail Security) with ESMTP id 0EA27236561; Fri, 2 Nov 2012 23:54:45 +0900 (JST) Received: from maila.sdl.hitachi.co.jp (sdl99a.sdl.hitachi.co.jp [133.144.14.196]) by sdl99w.sdl.hitachi.co.jp (Postfix) with ESMTP id 879BC53C158; Fri, 2 Nov 2012 23:54:47 +0900 (JST) Received: from [10.198.212.174] (unknown [10.198.212.174]) by maila.sdl.hitachi.co.jp (Postfix) with ESMTP id EE699495B88; Fri, 2 Nov 2012 23:54:44 +0900 (JST) Message-ID: <5093DEB4.7000907@hitachi.com> Date: Fri, 02 Nov 2012 23:54:44 +0900 From: Yuichi IGARASHI User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: manet@ietf.org References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> In-Reply-To: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 14:54:48 -0000 Hi, I agree with Martin and I would support option 2) at this stage. We LOADng co-authors made efforts to simplify core specification of the reactive protocol and to improve the readability of the draft. I think this approach is important not only for all implementor to shorten the development time, but also for business operators to make multi-vendor system easier to provide. Of course, I agree that, as several persons pointed out, "this draft" may limit use case. But we leave sufficient space for improving performance/adding functions by companion drafts. I am really concerned about complexity/difficulty of guaranteeing of interoperability. If the protocol becomes complicated, we need much time(many years?) for interoperability test. I think we should consider both time required for merging drafts and shape of document. Best regards, Yuichi (2012/11/02 23:01), Martin Heusse wrote: > > I'm standing for option 2 (LOADng). > > I think it's better to agree first on a simple basic (versatile?) protocol before proposing extensions to it; instead of starting from a collection of ideas that can be used or not (and we know today what are the options, thank to the huge amount of work done on reactive routing during the past years). Conversely, it would be certainly easier to reach a consensus on a set of variants but we need a good reference point, first. > > Moreover, reactive routing is most probably the approach that one would pick for a simple case. So it should be simple... > > Martin > > > Le 2 nov. 2012 à 01:58, Joydeep Tripathi a écrit : > >> I can understand that for an LLN it may be beneficial for not maintaining a precursor list or having only the destination reply t o a RREQ, there can be (and are) other instances of MANETs where having the option of precursor list will come handy. This can save on control overhead, using some storage space in the node. LOAD-ng, in most cases does not provide this flexibility to the developer to chose between options for specific deployment. Some MANET deployment may be less harsh than others in nature. Hence, AODVv2 having more open options than LOAD-ng, in most cases, seem beneficial to me. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Hitachi, Ltd., Yokohama Research Laboratory IGARASHI Yuichi Mail： yuichi.igarashi.hb@hitachi.com Tel ： +81-(0)45-860-3083 FAX ： +81-(0)45-860-1673 From ulrich@herberg.name Fri Nov 2 08:00:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BC821F8B44 for ; Fri, 2 Nov 2012 08:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcMbEneO9V9I for ; Fri, 2 Nov 2012 08:00:47 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E264B21F8AFC for ; Fri, 2 Nov 2012 08:00:46 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so2529474pbb.31 for ; Fri, 02 Nov 2012 08:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=pz3T4zss//IHeaSslLlvAha2OjMXzyfs8OKeMDP1XB8=; b=sEbdiIw1qSr7zCc0perg6Zh1lhXswHrsRX/rxUWzTIPPNzllkR2NzpqpnPIxpND0s/ j72AlV7eD6O0bM6dcwtrCdW3HsGRivCCSKKa+s3KO6IvRDQMrJpgObbZsvmBG1wW2BEp UedPd4IyRe7ha8g+sJzAMTCff9fFjxX3JndeU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=pz3T4zss//IHeaSslLlvAha2OjMXzyfs8OKeMDP1XB8=; b=SsKhTOX581IhhvrbNEZm6jN1VzcRQPdzRiUZ74FDokWTM62TzwOXoG24f/Mku09iiV A3mviQo1PPGvxqMksPGUacU5fmlVDaUrUKMJO9JiqPOZQ73Mu1u9Y+fGZJyfdE+7tpKF Yky5L+//rID+IZyPhtvlCJJ1fcbN+W8ftFZtFFix8i0vmysJMmMd7l7NyyWQ35T7xeeN zFmBr/o4745xBr0825WT8kq7IfssMrqKY0zlwOI8px8T5fxjYs4nzDKzwySJYqFFIoni J5YH3Ey/wELhrsN8P0EnTguCp2r/VDj1reJYtBkNf8QrI7eNFjOyU5255ZJ/7nLxZTT4 aQ2Q== Received: by 10.68.197.197 with SMTP id iw5mr7028977pbc.22.1351868446583; Fri, 02 Nov 2012 08:00:46 -0700 (PDT) Received: from [10.0.1.5] (c-76-102-41-234.hsd1.ca.comcast.net. [76.102.41.234]) by mx.google.com with ESMTPS id j4sm5844880pax.31.2012.11.02.08.00.44 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 08:00:45 -0700 (PDT) References: <12708D7E-C548-4858-8144-6F04D2750E02@jiaziyi.com> <4F9C6208-78B8-41B1-81D2-C7DAAE9D780D@jiaziyi.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-40316680-B4F8-49F3-A615-59CC11F9A60A Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10A403) From: Ulrich Herberg Date: Fri, 2 Nov 2012 08:00:44 -0700 To: "Dearlove, Christopher (UK)" X-Gm-Message-State: ALoCoQnGRnRbiIHN8S9jNT+fSDNu2gJDASgwX8aNbgPq/jzixNrsi6LXiyBsAD2lUyzNV6+YmG/N Cc: "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 15:00:49 -0000 --Apple-Mail-40316680-B4F8-49F3-A615-59CC11F9A60A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I am glad that we finally have some technical discussions... I agree that it is more difficult to provide end-to-end security in a reacti= ve protocol than in a proactive link-state. The idea in LOADng is that we kn= ow exactly the fields that are mutable, and we know that the length will not= change nor the position of any of the fields (but potentially the value of t= he metrics tlv). So it is relatively easy to just zero out the Metric TLV va= lue field. But I admit it's less straight forward than in OLSRv2. Ulrich On Nov 2, 2012, at 7:01, "Dearlove, Christopher (UK)" wrote: > Yes, of course there can be malicious routers with link state protocols. I= 've even helped implement one. But everything used is a link, and all links a= re carried in messages/packets, and if all messages/packets are authenticate= d, then all links are authenticated, and hence no malicious routers are incl= uded. > =20 > But the RREQ/RREP process (at its simplest) uses information that is not i= ncluded in any message. > =20 > Going back to OLSRv2, yes, all routers will have to agree on a process. Bu= t that's another discussion that I won't get into right now. > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: 02 November 2012 13:00 > To: Dearlove, Christopher (UK) > Cc: Jiazi YI; manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.o= rg) > Subject: Re: [manet] Reactive routing protocols, what are the differences?= > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an exte= rnal partner or the internet. > Keep this in mind if you answer this message. > Please see this process on how to deal with suspicious emails. >=20 > =20 > Op 2 nov. 2012, om 13:32 heeft Dearlove, Christopher (UK) het volgende ges= chreven: >=20 >=20 > I understand the basics. And I agree I can't see (except my bracketed asid= e) how to do it without a mutable field. But having that mutable field reduc= es the value of the argument against DYMO from "DYMO is mutable, LOADng is n= ot" to "DYMO is (uncontrolled?) mutable, LOADng is managed mutable". I'm not= convinced by the argument about having to mutate metric type. If you can't r= ely on it being available to your network layer protocol consistently in the= one MANET, heterogeneous though it may be, I'm not sure you have a well-put= -together network. You could always make the metrioc increment when unknown t= he maximum such value. > =20 > But there is, as another post raised, the larger question of what end to e= nd message authentication buys you. If in a route A-B-X-C-D, where X is a ba= d guy, if X relays all RREQs and RREPs flawlessly, but throws all data packe= ts on the floor, X has done his job, and without needing to forge anything. Y= ou also need B and/or C to authenticate X. Lower layer? (in which case why c= an't that do the whole job?). > There could be 2nd order nodes: hosts. Or the routing protocol security me= chanism is implemented in the routing deamon, which is very similar to the f= irst. >=20 >=20 > RREP-ACK? Accumulating signature? Something else? > =20 > (Note that a link state protocol gets the B-X and X-C done. Those are, aft= er all, links.) > There can be malicious routers with link state protocols too.=20 > Also, there is a requirement that all routers share the same policy on wha= t to do with failed authentication, and result of checking must be the same o= n all nodes. Not easy to deploy. And missing in olsrv2 core protocol. > =20 > Teco > =20 >=20 >=20 > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI > Sent: 02 November 2012 12:13 > To: Dearlove, Christopher (UK) > Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Clausen (thomas@thomascla= usen.org) > Subject: Re: [manet] Reactive routing protocols, what are the differences?= > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an exte= rnal partner or the internet. > Keep this in mind if you answer this message. > Please see this process on how to deal with suspicious emails. >=20 > Hi, >=20 >=20 >=20 > The reason that LOADng needs those fields mutable is to support different m= etrics other than hop-count, even routers using different metrics in the sam= e routing domain can at least find a path.=20 >=20 >=20 >=20 > To support different metric types, a metric-type tlv and a route-metric tl= v are needed. The route-metric tlv has to be mutable because it needs to be u= pdated at each hop.=20 > Having metric-type tlv mutable can make supporting different metrics in th= e same network possible.=20 >=20 >=20 >=20 > It's common that in a heterogenous network, there are various transmission= medias (802.11, 802.15.4, cable, PLC...), therefore possible different metr= ics. > In LOADng, if a router A (with metric-A) gets an RREQ message that it does= n't understand (say, metric-B), router A will change the metric-type to HOP_= COUNT, and forward the message (the hop-count field is always used). For the= destination of RREQ, it will first consider the metrics that it understands= , and then HOP_COUNT. Of course, this will result in "degrading" to HOP_COUN= T for certain routes, but at least we can get a usable route.=20 >=20 >=20 >=20 > I'm just introducing the design of LOADng, and would appreciate any good i= dea on this issue.=20 >=20 >=20 >=20 > best >=20 >=20 >=20 > Jiazi > =20 > =20 > =20 > On Nov 2, 2012, at 12:42 PM, "Dearlove, Christopher (UK)" wrote: >=20 >=20 >=20 > Having anything other than hop limit and hop count mutable is not the secu= rity mechanism suggested in 6622/5444. > =20 > I'm of the view that the current approach of securing NHDP, securing OLSRv= 2 etc. is not where things should ideally be, that the ideal place is at the= 5444 multiplexer wherever possible. If doing hop by hop security, then that= is the place, as it's where packets live. But if we could do it once for al= l message types, then that's a major gain. > =20 > Now as soon as LOADng has anything else mutable, that doesn't help that. O= K, it's better than nothing, but those fields are buried in TLVs (using 5444= ) and messy. > =20 > I'm at a disadvantage, I haven't studied why LOADng needs those fields (ot= her than hop count) mutable - or if it really does. But it reduces "here's a= clear advantage over DYMO" to "here's a more partial advantage over DYMO". A= nd I think Ulrich's summary could be edited to better present this. > =20 > So if we adopted my separate proposal, this would be on the menu: why are t= hose fields mutable? Do they have to be? Can we find an alternative? (Unfort= unately, I can see why probably not. But it's still a question.) > =20 > [Actually I can see an alternative, which is a much more limited metric, w= hich takes small integer values, and we increase hop count not by one but by= this metric, limiting paths to maximum 255 metric. We could still get hop c= ount from hop limit if we knew how it started - e.g. in a non-mutable TLV. B= ut I strongly doubt this is good enough.] > =20 > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI > Sent: 02 November 2012 10:54 > To: Dearlove, Christopher (UK) > Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Clausen (thomas@thomascla= usen.org) > Subject: Re: [manet] Reactive routing protocols, what are the differences?= > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an exte= rnal partner or the internet. > Keep this in mind if you answer this message. > Please see this process on how to deal with suspicious emails. >=20 > Hi Chris,=20 >=20 >=20 >=20 >=20 > I think Ulrich is in deep sleep at the moment, so please allow me to have s= ome words on this.=20 >=20 >=20 >=20 >=20 > For reactive protocols, updating the route information (hop-count, metric)= is inevitable. In the specification of DYMO, the messages can be changed re= latively arbitrarily, including removing addresses from the messages. The in= termediate RREP also makes end-to-end security impossible.=20 >=20 >=20 >=20 >=20 > LOADng clearly defines which fields in the routing messages can't be chang= ed, and which fields are mutable. For example, for RREQ: >=20 >=20 >=20 >=20 > The following fields of an RREQ message are immutable, i.e., they MUST NOT= be changed during processing or forwarding of the message: RREQ.addr-length= , RREQ.seq-num, RREQ.originator, and RREQ.destination. > The following fields of an RREQ message are mutable, i.e., they will be ch= anged by intermediate routers during processing or forwarding, as specified i= n Section 12.2 and Section 12.3: RREQ.metric-type, RREQ.route-metric, and RR= EQ.hop-count. > Any additional field that is added to the message by an extension to this p= rotocol, e.g., by way of TLVs, MUST be considered immutable, unless the exte= nsion specifically defines the field as mutable. >=20 >=20 >=20 >=20 > This allows the protocol to secure the messages by zeroing the mutable fie= lds.=20 >=20 >=20 >=20 >=20 > best >=20 >=20 >=20 >=20 > Jiazi=20 >=20 >=20 >=20 >=20 > (sorry to Chris if you received multiple copy of this message. I fixed one= typo though :) My previous one was bounced by manet mailing list because of= not using the right sender address) > =20 > =20 > On Nov 2, 2012, at 11:22 AM, "Dearlove, Christopher (UK)" wrote: >=20 >=20 >=20 >=20 > There is, superficially at least, an apparent contradiction between your p= oints: >=20 > - DYMO cannot be end-to-end secured. Messages are changed in transit > (and not just hop-limit or the metric), but rather addresses can be > removed from RERRs and RREQs. >=20 > which implicitly suggests LOADng does not do this >=20 > and=20 >=20 > - LOADng uses a Metric message TLV, and it is clearly defined how to > update the metric under way. >=20 > Could you expand on this please? >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Ulrich Herberg [mailto:ulrich@herberg.name]=20 > Sent: 01 November 2012 22:02 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.org) > Subject: Re: [manet] Reactive routing protocols, what are the differences?= >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Hi Chris, >=20 > you have seen my review on DYMO. I will try to answer to your > question, and focus on the technical differences, not presentation. >=20 >=20 > On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK) > wrote: >=20 >=20 >=20 > The obviously best people to answer this should be document authors, but a= nyone else may have useful additions and comments. Ideally the different doc= ument authors could agree a list. (If they differ in that one has X and the o= ther doesn't, but one wants to say "we plan to add/remove X" then X should b= e listed as a difference with that caveat, in at least my ideal world.) >=20 > If we set aside, for the moment (though these things matter): > - The presentational quality of the documents, > - Any issues of 5444 compliance and other formatting issues, > - Issues of internal data organisation, > - Minor details such as possible different timeout parameters etc. > then what are the technical (and I stress that word) differences between D= YMO and LOADng? (I'm withholding the term AODVv2 for reasons I may come back= to.) >=20 >=20 > First, let's see what is common. Both are reactive protocols, using > RREQ, RREP and RERR. So if someone claims that DYMO performs great and > LOADng badly in the same scenario, I cannot understand that. MANET has > understood the scenarios where reactive protocols are useful and where > not. >=20 > Now, to the differences: >=20 > - DYMO cannot be end-to-end secured. Messages are changed in transit > (and not just hop-limit or the metric), but rather addresses can be > removed from RERRs and RREQs. There is also no provision to allow > external mechanisms to add additional reasons to reject messages as > invalid. > - DYMO uses the originator address in an address block, LOADng in the > message header. The sequence number is a TLV value in DYMO, and LOADng > uses the message sequence number. DYMO requires the originator address > to be the first one in the address block, the destination must be the > second one. LOADng uses a TLV to determine the target address. > - DYMO can advertise multiple addresses in an RERR; they can be > removed in transit of the message. > - DYMO allows intermediate routers to reply (as an option). That makes > end-to-end security difficult. In the core DYMO, there is a > destination sequence number that may be contained in RREQs in DYMO. > - DYMO allows for unicast RREQ, but does not specify in detail how to use t= hat. > - There are four timers for each route entry in DYMO, only one in LOADng. > - LOADng can be used on other layers; DYMO is tied to IP. > - LOADng provides a bidirectionality verification using RREP_ACK, a > time-out of these, a blacklisted set and a Pending Acknowledgment Set > to verify bidirectional links. DYMO says that other mechanisms can be > used, but does not specify these. > - DYMO has several options for expanding ring RREQ, precursor list, > adding route information in transit, message aggregation in RFC5444 > packets and reporting multiple unreachable addresses in a RERR. LOADng > takes the approach to have a slim core of a basic mechanism that is > applicable in all MANET use cases, and companion documents with > extensions. In DYMO, it is not clearly specified what happens if some > routers support an option, and others don't. > - LOADng uses a Metric message TLV, and it is clearly defined how to > update the metric under way. If a router in transit does not recognize > a route metric type, it is reset to a "hop count" tlv extension type > of the Metric TLV and the value set to 0xFFFFF... (for the full TLV > length). It is specified that security mechanism must ignore the > content of the metric TLV value and that the length cannot be changed > under way, so that end-to-end security is possible. DYMO uses an > optional "distance" field for the metric, which is not clearly > specified how it is updated. Also, since this is optional, it is > unclear if routers receiving a message and forwarding it, update the > distance field or not. > - LOADng allows for (optionally) waiting to reply with a RREP, in case > a "better" RREQ comes a little later. In DYMO, a RREP is always sent > immediately. >=20 > There are probably more differences, but I let other chime in. >=20 > Best regards > Ulrich >=20 >=20 >=20 >=20 >=20 > Note that it's a lot more useful to have direct differences than differenc= es of each from AODV (especially when both have the same difference). And it= would be useful to have the objective differences separated from the "and n= ow why this is better" discussion - though that would be a next step. >=20 > I'm not saying I don't see any of the differences. But I certainly haven't= worked out the complete list. In trying to form my view of how things shoul= d go forward (a view that is coming together, and when it does, I'll argue f= or it) and I hope for other people as well, it would be good to know what th= e differences are. Regardless of views for or against each, we should be abl= e to objectively list the significant differences - if we can't then somethi= ng is wrong. >=20 > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 >=20 > ******************************************************************** > 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. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > =20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > =20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-40316680-B4F8-49F3-A615-59CC11F9A60A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I am glad that we finally have some technical discussions...

I agree that it is more difficult to provide end-to-end security in a reactive protocol than in a proactive link-state. The idea in LOADng is that we know exactly the fields that are mutable, and we know that the length will not change nor the position of any of the fields (but potentially the value of the metrics tlv). So it is relatively easy to just zero out the Metric TLV value field. But I admit it's less straight forward than in OLSRv2.

Ulrich

On Nov 2, 2012, at 7:01, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> wrote:

Yes, of course there can be malicious routers with link state protocols. I've even helped implement one. But everything used is a link, and all links are carried in messages/packets, and if all messages/packets are authenticated, then all links are authenticated, and hence no malicious routers are included.

 

But the RREQ/RREP process (at its simplest) uses information that is not included in any message.

 

Going back to OLSRv2, yes, all routers will have to agree on a process. But that's another discussion that I won't get into right now.

 

--

Christopher Dearlove

Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: Teco Boot [mailto:teco@inf-net.nl]
Sent: 02 November 2012 13:00
To: Dearlove, Christopher (UK)
Cc: Jiazi YI; manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.org)
Subject: Re: [manet] Reactive routing protocols, what are the differences?

 

 

*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

 

Op 2 nov. 2012, om 13:32 heeft Dearlove, Christopher (UK) het volgende geschreven:



I understand the basics. And I agree I can't see (except my bracketed aside) how to do it without a mutable field. But having that mutable field reduces the value of the argument against DYMO from "DYMO is mutable, LOADng is not" to "DYMO is (uncontrolled?) mutable, LOADng is managed mutable". I'm not convinced by the argument about having to mutate metric type. If you can't rely on it being available to your network layer protocol consistently in the one MANET, heterogeneous though it may be, I'm not sure you have a well-put-together network. You could always make the metrioc increment when unknown the maximum such value.

 

But there is, as another post raised, the larger question of what end to end message authentication buys you. If in a route A-B-X-C-D, where X is a bad guy, if X relays all RREQs and RREPs flawlessly, but throws all data packets on the floor, X has done his job, and without needing to forge anything. You also need B and/or C to authenticate X. Lower layer? (in which case why can't that do the whole job?).

There could be 2nd order nodes: hosts. Or the routing protocol security mechanism is implemented in the routing deamon, which is very similar to the first.



RREP-ACK? Accumulating signature? Something else?

 

(Note that a link state protocol gets the B-X and X-C done. Those are, after all, links.)

There can be malicious routers with link state protocols too. 

Also, there is a requirement that all routers share the same policy on what to do with failed authentication, and result of checking must be the same on all nodes. Not easy to deploy. And missing in olsrv2 core protocol.

 

Teco

 



 

--

Christopher Dearlove

Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI
Sent: 02 November 2012 12:13
To: Dearlove, Christopher (UK)
Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.org)
Subject: Re: [manet] Reactive routing protocols, what are the differences?

 

 

*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

Hi,




The reason that LOADng needs those fields mutable is to support different metrics other than hop-count, even routers using different metrics in the same routing domain can at least find a path. 




To support different metric types, a metric-type tlv and a route-metric tlv are needed. The route-metric tlv has to be mutable because it needs to be updated at each hop. 

Having metric-type tlv mutable can make supporting different metrics in the same network possible. 




It's common that in a heterogenous network, there are various transmission medias (802.11, 802.15.4, cable, PLC...), therefore possible different metrics.

In LOADng, if a router A (with metric-A) gets an RREQ message that it doesn't understand (say, metric-B), router A will change the metric-type to HOP_COUNT, and forward the message (the hop-count field is always used). For the destination of RREQ, it will first consider the metrics that it understands, and then HOP_COUNT. Of course, this will result in "degrading" to HOP_COUNT for certain routes, but at least we can get a usable route. 




I'm just introducing the design of LOADng, and would appreciate any good idea on this issue. 




best




Jiazi

 

 

 

On Nov 2, 2012, at 12:42 PM, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> wrote:




Having anything other than hop limit and hop count mutable is not the security mechanism suggested in 6622/5444.

 

I'm of the view that the current approach of securing NHDP, securing OLSRv2 etc. is not where things should ideally be, that the ideal place is at the 5444 multiplexer wherever possible. If doing hop by hop security, then that is the place, as it's where packets live. But if we could do it once for all message types, then that's a major gain.

 

Now as soon as LOADng has anything else mutable, that doesn't help that. OK, it's better than nothing, but those fields are buried in TLVs (using 5444) and messy.

 

I'm at a disadvantage, I haven't studied why LOADng needs those fields (other than hop count) mutable - or if it really does. But it reduces "here's a clear advantage over DYMO" to "here's a more partial advantage over DYMO". And I think Ulrich's summary could be edited to better present this.

 

So if we adopted my separate proposal, this would be on the menu: why are those fields mutable? Do they have to be? Can we find an alternative? (Unfortunately, I can see why probably not. But it's still a question.)

 

[Actually I can see an alternative, which is a much more limited metric, which takes small integer values, and we increase hop count not by one but by this metric, limiting paths to maximum 255 metric. We could still get hop count from hop limit if we knew how it started - e.g. in a non-mutable TLV. But I strongly doubt this is good enough.]

 

--

Christopher Dearlove

Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI
Sent: 02 November 2012 10:54
To: Dearlove, Christopher (UK)
Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.org)
Subject: Re: [manet] Reactive routing protocols, what are the differences?

 

 

*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

Hi Chris, 





I think Ulrich is in deep sleep at the moment, so please allow me to have some words on this. 





For reactive protocols, updating the route information (hop-count, metric) is inevitable. In the specification of DYMO, the messages can be changed relatively arbitrarily, including removing addresses from the messages. The intermediate RREP also makes end-to-end security impossible. 





LOADng clearly defines which fields in the routing messages can't be changed, and which fields are mutable. For example, for RREQ:





The following fields of an RREQ message are immutable, i.e., they MUST NOT be changed during processing or forwarding of the message: RREQ.addr-length, RREQ.seq-num, RREQ.originator, and RREQ.destination.

The following fields of an RREQ message are mutable, i.e., they will be changed by intermediate routers during processing or forwarding, as specified in Section 12.2 and Section 12.3: RREQ.metric-type, RREQ.route-metric, and RREQ.hop-count.

Any additional field that is added to the message by an extension to this protocol, e.g., by way of TLVs, MUST be considered immutable, unless the extension specifically defines the field as mutable.





This allows the protocol to secure the messages by zeroing the mutable fields. 





best





Jiazi 





(sorry to Chris if you received multiple copy of this message. I fixed one typo though :) My previous one was bounced by manet mailing list because of not using the right sender address)

 

 

On Nov 2, 2012, at 11:22 AM, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> wrote:





There is, superficially at least, an apparent contradiction between your points:

- DYMO cannot be end-to-end secured. Messages are changed in transit
(and not just hop-limit or the metric), but rather addresses can be
removed from RERRs and RREQs.

which implicitly suggests LOADng does not do this

and 

- LOADng uses a Metric message TLV, and it is clearly defined how to
update the metric under way.

Could you expand on this please?

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Ulrich Herberg [mailto:ulrich@herberg.name] 
Sent: 01 November 2012 22:02
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.org)
Subject: Re: [manet] Reactive routing protocols, what are the differences?

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hi Chris,

you have seen my review on DYMO. I will try to answer to your
question, and focus on the technical differences, not presentation.


On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK)
<Chris.Dearlove@baesystems.com> wrote:



The obviously best people to answer this should be document authors, but anyone else may have useful additions and comments. Ideally the different document authors could agree a list. (If they differ in that one has X and the other doesn't, but one wants to say "we plan to add/remove X" then X should be listed as a difference with that caveat, in at least my ideal world.)

If we set aside, for the moment (though these things matter):
- The presentational quality of the documents,
- Any issues of 5444 compliance and other formatting issues,
- Issues of internal data organisation,
- Minor details such as possible different timeout parameters etc.
then what are the technical (and I stress that word) differences between DYMO and LOADng? (I'm withholding the term AODVv2 for reasons I may come back to.)



First, let's see what is common. Both are reactive protocols, using
RREQ, RREP and RERR. So if someone claims that DYMO performs great and
LOADng badly in the same scenario, I cannot understand that. MANET has
understood the scenarios where reactive protocols are useful and where
not.

Now, to the differences:

- DYMO cannot be end-to-end secured. Messages are changed in transit
(and not just hop-limit or the metric), but rather addresses can be
removed from RERRs and RREQs. There is also no provision to allow
external mechanisms to add additional reasons to reject messages as
invalid.
- DYMO uses the originator address in an address block, LOADng in the
message header. The sequence number is a TLV value in DYMO, and LOADng
uses the message sequence number. DYMO requires the originator address
to be the first one in the address block, the destination must be the
second one. LOADng uses a TLV to determine the target address.
- DYMO can advertise multiple addresses in an RERR; they can be
removed in transit of the message.
- DYMO allows intermediate routers to reply (as an option). That makes
end-to-end security difficult. In the core DYMO, there is a
destination sequence number that may be contained in RREQs in DYMO.
- DYMO allows for unicast RREQ, but does not specify in detail how to use that.
- There are four timers for each route entry in DYMO, only one in LOADng.
- LOADng can be used on other layers; DYMO is tied to IP.
- LOADng provides a bidirectionality verification using RREP_ACK, a
time-out of these, a blacklisted set and a Pending Acknowledgment Set
to verify bidirectional links. DYMO says that other mechanisms can be
used, but does not specify these.
- DYMO has several options for expanding ring RREQ, precursor list,
adding route information in transit, message aggregation in RFC5444
packets and reporting multiple unreachable addresses in a RERR. LOADng
takes the approach to have a slim core of a basic mechanism that is
applicable in all MANET use cases, and companion documents with
extensions. In DYMO, it is not clearly specified what happens if some
routers support an option, and others don't.
- LOADng uses a Metric message TLV, and it is clearly defined how to
update the metric under way. If a router in transit does not recognize
a route metric type, it is reset to a "hop count" tlv extension type
of the Metric TLV and the value set to 0xFFFFF... (for the full TLV
length). It is specified that security mechanism must ignore the
content of the metric TLV value and that the length cannot be changed
under way, so that end-to-end security is possible. DYMO uses an
optional "distance" field for the metric, which is not clearly
specified how it is updated. Also, since this is optional, it is
unclear if routers receiving a message and forwarding it, update the
distance field or not.
- LOADng allows for (optionally) waiting to reply with a RREP, in case
a "better" RREQ comes a little later. In DYMO, a RREP is always sent
immediately.

There are probably more differences, but I let other chime in.

Best regards
Ulrich





Note that it's a lot more useful to have direct differences than differences of each from AODV (especially when both have the same difference). And it would be useful to have the objective differences separated from the "and now why this is better" discussion - though that would be a next step.

I'm not saying I don't see any of the differences. But I certainly haven't worked out the complete list. In trying to form my view of how things should go forward (a view that is coming together, and when it does, I'll argue for it) and I hope for other people as well, it would be good to know what the differences are. Regardless of views for or against each, we should be able to objectively list the significant differences - if we can't then something is wrong.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687



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

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

 

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

 

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--Apple-Mail-40316680-B4F8-49F3-A615-59CC11F9A60A-- From ulrich@herberg.name Fri Nov 2 08:08:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E808B21F857E for ; Fri, 2 Nov 2012 08:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+s0NrY2y7B2 for ; Fri, 2 Nov 2012 08:08:10 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB1821F8559 for ; Fri, 2 Nov 2012 08:08:10 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so2535808pad.31 for ; Fri, 02 Nov 2012 08:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=2EH4WN2U1P3u7ylV/OpBcrPeUqpuE0mW5I2sWmpTtKY=; b=h1oe/2rZgmeg6AxkzXpaxG54sh+ANs4LORYd91tYsjoeASl8+wbcpzeR301ek/aei6 oE1u8H2dhjMlC3NTGxGhBYV5C5ltA28E6VHpiCUS5/35xwGJuWM9OPc2nK3EDK5Mo/VE 83AgXrwsmD26NqiIUZLj4Mzw0/SQv+/X0on4s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=2EH4WN2U1P3u7ylV/OpBcrPeUqpuE0mW5I2sWmpTtKY=; b=Xy87Oy+C4QZHPeYxqqs1vuTWMSnHJIHPwcBgxScEqAqDyyRmnIEeYcII+gac+CqjYQ 1jCxHdm/H/HUIJLz9WAXfcQYGAbRK7gOeqD3JmVlSwANNmie2iXETYxHlRcZEpw23QdM xgsEJ8jk9Mx5kS4EXKof/WdflGI26lZjhyeZwtGwzf6+dJZXqNPsDM94rAJ2gNoG0/33 TcG7u1OqT4CMdcUmaSP9xw3Nvv0YqbOuJ94+515oM1hvuz24W+iPm65WFdL6Sq6o/HHd tFGZ3c+z8VpWp+RRT6G6xTcof1NMq3p0OJTqD6nYQWqFPLE6uXntlSlVFNaQDLPSHo30 Vcuw== Received: by 10.68.229.194 with SMTP id ss2mr7197856pbc.17.1351868890149; Fri, 02 Nov 2012 08:08:10 -0700 (PDT) Received: from [10.0.1.5] (c-76-102-41-234.hsd1.ca.comcast.net. [76.102.41.234]) by mx.google.com with ESMTPS id j9sm5866105paw.2.2012.11.02.08.08.08 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 08:08:09 -0700 (PDT) References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5093DEB4.7000907@hitachi.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> X-Mailer: iPad Mail (10A403) From: Ulrich Herberg Date: Fri, 2 Nov 2012 08:08:09 -0700 To: Yuichi IGARASHI X-Gm-Message-State: ALoCoQld22ynS4Fkec6baGTQID2Wah5sQJ9K5Zt7v6ALnpDu1z5qqTCBjakYVpUuMaG7Kn1UEF8V Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 15:08:11 -0000 I think one key point to stress is one that Chris mentioned: Both protocols are similar in their operation and performance. So anyone arg= uing against the performance of LOADng is automatically also not interested i= n DYMO.=20 However, LOADng is far closer to become an RFC in terms of the document qual= ity. If we start the new reactive protocol on the basis of the LOADng draft (= and I personally don't care what we name that protocol is), we can continue t= he work on the reactive protocol together and discuss the multiple options t= hat are currently in DYMO and see whether they should be discarded, put into= a companion document or in the core spec.=20 Best Ulrich On Nov 2, 2012, at 7:54, Yuichi IGARASHI wr= ote: > Hi, >=20 > I agree with Martin and I would support option 2) at this stage. >=20 > We LOADng co-authors made efforts to simplify core specification of the re= active protocol and to improve the readability of the draft. I think this ap= proach is important not only for all implementor to shorten the development t= ime, but also for business operators to make multi-vendor system easier to p= rovide. Of course, I agree that, as several persons pointed out, "this draft= " may limit use case. But we leave sufficient space for improving performanc= e/adding functions by companion drafts. >=20 > I am really concerned about complexity/difficulty of guaranteeing of inter= operability. If the protocol becomes complicated, we need much time(many yea= rs?) for interoperability test. I think we should consider both time require= d for merging drafts and shape of document. >=20 > Best regards, > Yuichi > (2012/11/02 23:01), Martin Heusse wrote: >>=20 >> I'm standing for option 2 (LOADng). >>=20 >> I think it's better to agree first on a simple basic (versatile?) protoco= l before proposing extensions to it; instead of starting from a collection o= f ideas that can be used or not (and we know today what are the options, tha= nk to the huge amount of work done on reactive routing during the past years= ). Conversely, it would be certainly easier to reach a consensus on a set of= variants but we need a good reference point, first. >>=20 >> Moreover, reactive routing is most probably the approach that one would p= ick for a simple case. So it should be simple... >>=20 >> Martin >>=20 >>=20 >> Le 2 nov. 2012 =C3=A0 01:58, Joydeep Tripathi a =C3=A9crit : >>=20 >>> I can understand that for an LLN it may be beneficial for not maintaini= ng a precursor list or having only the destination reply t o a RREQ, there c= an be (and are) other instances of MANETs where having the option of precurs= or list will come handy. This can save on control overhead, using some stora= ge space in the node. LOAD-ng, in most cases does not provide this flexibili= ty to the developer to chose between options for specific deployment. Some M= ANET deployment may be less harsh than others in nature. Hence, AODVv2 havin= g more open options than LOAD-ng, in most cases, seem beneficial to me. >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 > --=20 > Hitachi, Ltd., Yokohama Research Laboratory > IGARASHI Yuichi > Mail=EF=BC=9A yuichi.igarashi.hb@hitachi.com > Tel =EF=BC=9A +81-(0)45-860-3083 > FAX =EF=BC=9A +81-(0)45-860-1673 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From christopher.dearlove@googlemail.com Fri Nov 2 08:51:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1E91F0C59 for ; Fri, 2 Nov 2012 08:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.375 X-Spam-Level: X-Spam-Status: No, score=-1.375 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CNFoe8Xf4HB for ; Fri, 2 Nov 2012 08:51:30 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6301F0C42 for ; Fri, 2 Nov 2012 08:51:27 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1753766wgb.13 for ; Fri, 02 Nov 2012 08:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=K4aatdwcOj590o+YwnQ58CuMUmZFFPO3AbNW3RzDtAY=; b=iXdVZRHfbmnEL1GR04tZtSfXpiVdpycgjL+lgGFSQ9lTFWd2+p+shpi0c0Q8AJ82T8 6RbEywcw3R94vuIjplbeVd5xkdnl1gB+Z3x+jXPG672VfLto+G5pATN1ER2SPqnQ7heN 0Jn19HZxPxIsk9DgQyMp0aw8vZYF6NGb6NOEgtF7Jrnv5tu0wVb+79xQohYbHbMEurAm UlS4GGOirgummnej2lZWlKNtkJCmBLf7TA/qo9NBu9p5ydllDhaUVIbrY8C9zKEVwoMh KYWvsNh4gnGbNGXz+Q0r9s4SAaVmUl6CHjzjFxc5ey8TZdyPuPhfwyG8n9Yy7fRIo8QE 3VWQ== Received: by 10.181.13.239 with SMTP id fb15mr3183193wid.22.1351871486277; Fri, 02 Nov 2012 08:51:26 -0700 (PDT) Received: from [10.45.53.17] (dab-ell1-h-25-3.dab.02.net. [82.132.237.79]) by mx.google.com with ESMTPS id ea9sm3164007wib.11.2012.11.02.08.51.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 08:51:25 -0700 (PDT) References: <12708D7E-C548-4858-8144-6F04D2750E02@jiaziyi.com> <4F9C6208-78B8-41B1-81D2-C7DAAE9D780D@jiaziyi.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1--97870448 Message-Id: <4FC8B1E4-6747-4C36-A7A3-5991F326EF95@gmail.com> X-Mailer: iPhone Mail (8B117) From: Christopher Dearlove Date: Fri, 2 Nov 2012 15:51:13 +0000 To: Ulrich Herberg Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Thomas Heide Clausen\(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 15:51:34 -0000 --Apple-Mail-1--97870448 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii But that still leaves the problem that with just end to end security, the RR= EP path is not reported in any message and hence is not protected, and my A -= B - X - C - D example. --=20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) On 2 Nov 2012, at 15:00, Ulrich Herberg wrote: > I am glad that we finally have some technical discussions... >=20 > I agree that it is more difficult to provide end-to-end security in a reac= tive protocol than in a proactive link-state. The idea in LOADng is that we k= now exactly the fields that are mutable, and we know that the length will no= t change nor the position of any of the fields (but potentially the value of= the metrics tlv). So it is relatively easy to just zero out the Metric TLV v= alue field. But I admit it's less straight forward than in OLSRv2. >=20 > Ulrich >=20 > On Nov 2, 2012, at 7:01, "Dearlove, Christopher (UK)" wrote: >=20 >> Yes, of course there can be malicious routers with link state protocols. I= 've even helped implement one. But everything used is a link, and all links a= re carried in messages/packets, and if all messages/packets are authenticate= d, then all links are authenticated, and hence no malicious routers are incl= uded. >> =20 >> But the RREQ/RREP process (at its simplest) uses information that is not i= ncluded in any message. >> =20 >> Going back to OLSRv2, yes, all routers will have to agree on a process. B= ut that's another discussion that I won't get into right now. >> =20 >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> =20 >> From: Teco Boot [mailto:teco@inf-net.nl]=20 >> Sent: 02 November 2012 13:00 >> To: Dearlove, Christopher (UK) >> Cc: Jiazi YI; manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.= org) >> Subject: Re: [manet] Reactive routing protocols, what are the differences= ? >> =20 >> =20 >> *** WARNING *** >> This message originates from outside our organisation, either from an ext= ernal partner or the internet. >> Keep this in mind if you answer this message. >> Please see this process on how to deal with suspicious emails. >>=20 >> =20 >> Op 2 nov. 2012, om 13:32 heeft Dearlove, Christopher (UK) het volgende ge= schreven: >>=20 >>=20 >> I understand the basics. And I agree I can't see (except my bracketed asi= de) how to do it without a mutable field. But having that mutable field redu= ces the value of the argument against DYMO from "DYMO is mutable, LOADng is n= ot" to "DYMO is (uncontrolled?) mutable, LOADng is managed mutable". I'm not= convinced by the argument about having to mutate metric type. If you can't r= ely on it being available to your network layer protocol consistently in the= one MANET, heterogeneous though it may be, I'm not sure you have a well-put= -together network. You could always make the metrioc increment when unknown t= he maximum such value. >> =20 >> But there is, as another post raised, the larger question of what end to e= nd message authentication buys you. If in a route A-B-X-C-D, where X is a ba= d guy, if X relays all RREQs and RREPs flawlessly, but throws all data packe= ts on the floor, X has done his job, and without needing to forge anything. Y= ou also need B and/or C to authenticate X. Lower layer? (in which case why c= an't that do the whole job?). >> There could be 2nd order nodes: hosts. Or the routing protocol security m= echanism is implemented in the routing deamon, which is very similar to the f= irst. >>=20 >>=20 >> RREP-ACK? Accumulating signature? Something else? >> =20 >> (Note that a link state protocol gets the B-X and X-C done. Those are, af= ter all, links.) >> There can be malicious routers with link state protocols too.=20 >> Also, there is a requirement that all routers share the same policy on wh= at to do with failed authentication, and result of checking must be the same= on all nodes. Not easy to deploy. And missing in olsrv2 core protocol. >> =20 >> Teco >> =20 >>=20 >>=20 >> =20 >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> =20 >> From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI >> Sent: 02 November 2012 12:13 >> To: Dearlove, Christopher (UK) >> Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Clausen (thomas@thomascl= ausen.org) >> Subject: Re: [manet] Reactive routing protocols, what are the differences= ? >> =20 >> =20 >> *** WARNING *** >> This message originates from outside our organisation, either from an ext= ernal partner or the internet. >> Keep this in mind if you answer this message. >> Please see this process on how to deal with suspicious emails. >>=20 >> Hi, >>=20 >>=20 >>=20 >> The reason that LOADng needs those fields mutable is to support different= metrics other than hop-count, even routers using different metrics in the s= ame routing domain can at least find a path.=20 >>=20 >>=20 >>=20 >> To support different metric types, a metric-type tlv and a route-metric t= lv are needed. The route-metric tlv has to be mutable because it needs to be= updated at each hop.=20 >> Having metric-type tlv mutable can make supporting different metrics in t= he same network possible.=20 >>=20 >>=20 >>=20 >> It's common that in a heterogenous network, there are various transmissio= n medias (802.11, 802.15.4, cable, PLC...), therefore possible different met= rics. >> In LOADng, if a router A (with metric-A) gets an RREQ message that it doe= sn't understand (say, metric-B), router A will change the metric-type to HOP= _COUNT, and forward the message (the hop-count field is always used). For th= e destination of RREQ, it will first consider the metrics that it understand= s, and then HOP_COUNT. Of course, this will result in "degrading" to HOP_COU= NT for certain routes, but at least we can get a usable route.=20 >>=20 >>=20 >>=20 >> I'm just introducing the design of LOADng, and would appreciate any good i= dea on this issue.=20 >>=20 >>=20 >>=20 >> best >>=20 >>=20 >>=20 >> Jiazi >> =20 >> =20 >> =20 >> On Nov 2, 2012, at 12:42 PM, "Dearlove, Christopher (UK)" wrote: >>=20 >>=20 >>=20 >> Having anything other than hop limit and hop count mutable is not the sec= urity mechanism suggested in 6622/5444. >> =20 >> I'm of the view that the current approach of securing NHDP, securing OLSR= v2 etc. is not where things should ideally be, that the ideal place is at th= e 5444 multiplexer wherever possible. If doing hop by hop security, then tha= t is the place, as it's where packets live. But if we could do it once for a= ll message types, then that's a major gain. >> =20 >> Now as soon as LOADng has anything else mutable, that doesn't help that. O= K, it's better than nothing, but those fields are buried in TLVs (using 5444= ) and messy. >> =20 >> I'm at a disadvantage, I haven't studied why LOADng needs those fields (o= ther than hop count) mutable - or if it really does. But it reduces "here's a= clear advantage over DYMO" to "here's a more partial advantage over DYMO". A= nd I think Ulrich's summary could be edited to better present this. >> =20 >> So if we adopted my separate proposal, this would be on the menu: why are= those fields mutable? Do they have to be? Can we find an alternative? (Unfo= rtunately, I can see why probably not. But it's still a question.) >> =20 >> [Actually I can see an alternative, which is a much more limited metric, w= hich takes small integer values, and we increase hop count not by one but by= this metric, limiting paths to maximum 255 metric. We could still get hop c= ount from hop limit if we knew how it started - e.g. in a non-mutable TLV. B= ut I strongly doubt this is good enough.] >> =20 >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> =20 >> From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI >> Sent: 02 November 2012 10:54 >> To: Dearlove, Christopher (UK) >> Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Clausen (thomas@thomascl= ausen.org) >> Subject: Re: [manet] Reactive routing protocols, what are the differences= ? >> =20 >> =20 >> *** WARNING *** >> This message originates from outside our organisation, either from an ext= ernal partner or the internet. >> Keep this in mind if you answer this message. >> Please see this process on how to deal with suspicious emails. >>=20 >> Hi Chris,=20 >>=20 >>=20 >>=20 >>=20 >> I think Ulrich is in deep sleep at the moment, so please allow me to have= some words on this.=20 >>=20 >>=20 >>=20 >>=20 >> For reactive protocols, updating the route information (hop-count, metric= ) is inevitable. In the specification of DYMO, the messages can be changed r= elatively arbitrarily, including removing addresses from the messages. The i= ntermediate RREP also makes end-to-end security impossible.=20 >>=20 >>=20 >>=20 >>=20 >> LOADng clearly defines which fields in the routing messages can't be chan= ged, and which fields are mutable. For example, for RREQ: >>=20 >>=20 >>=20 >>=20 >> The following fields of an RREQ message are immutable, i.e., they MUST NO= T be changed during processing or forwarding of the message: RREQ.addr-lengt= h, RREQ.seq-num, RREQ.originator, and RREQ.destination. >> The following fields of an RREQ message are mutable, i.e., they will be c= hanged by intermediate routers during processing or forwarding, as specified= in Section 12.2 and Section 12.3: RREQ.metric-type, RREQ.route-metric, and R= REQ.hop-count. >> Any additional field that is added to the message by an extension to this= protocol, e.g., by way of TLVs, MUST be considered immutable, unless the ex= tension specifically defines the field as mutable. >>=20 >>=20 >>=20 >>=20 >> This allows the protocol to secure the messages by zeroing the mutable fi= elds.=20 >>=20 >>=20 >>=20 >>=20 >> best >>=20 >>=20 >>=20 >>=20 >> Jiazi=20 >>=20 >>=20 >>=20 >>=20 >> (sorry to Chris if you received multiple copy of this message. I fixed on= e typo though :) My previous one was bounced by manet mailing list because o= f not using the right sender address) >> =20 >> =20 >> On Nov 2, 2012, at 11:22 AM, "Dearlove, Christopher (UK)" wrote: >>=20 >>=20 >>=20 >>=20 >> There is, superficially at least, an apparent contradiction between your p= oints: >>=20 >> - DYMO cannot be end-to-end secured. Messages are changed in transit >> (and not just hop-limit or the metric), but rather addresses can be >> removed from RERRs and RREQs. >>=20 >> which implicitly suggests LOADng does not do this >>=20 >> and=20 >>=20 >> - LOADng uses a Metric message TLV, and it is clearly defined how to >> update the metric under way. >>=20 >> Could you expand on this please? >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: Ulrich Herberg [mailto:ulrich@herberg.name]=20 >> Sent: 01 November 2012 22:02 >> To: Dearlove, Christopher (UK) >> Cc: manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.org) >> Subject: Re: [manet] Reactive routing protocols, what are the differences= ? >>=20 >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> Hi Chris, >>=20 >> you have seen my review on DYMO. I will try to answer to your >> question, and focus on the technical differences, not presentation. >>=20 >>=20 >> On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK) >> wrote: >>=20 >>=20 >>=20 >> The obviously best people to answer this should be document authors, but a= nyone else may have useful additions and comments. Ideally the different doc= ument authors could agree a list. (If they differ in that one has X and the o= ther doesn't, but one wants to say "we plan to add/remove X" then X should b= e listed as a difference with that caveat, in at least my ideal world.) >>=20 >> If we set aside, for the moment (though these things matter): >> - The presentational quality of the documents, >> - Any issues of 5444 compliance and other formatting issues, >> - Issues of internal data organisation, >> - Minor details such as possible different timeout parameters etc. >> then what are the technical (and I stress that word) differences between D= YMO and LOADng? (I'm withholding the term AODVv2 for reasons I may come back= to.) >>=20 >>=20 >> First, let's see what is common. Both are reactive protocols, using >> RREQ, RREP and RERR. So if someone claims that DYMO performs great and >> LOADng badly in the same scenario, I cannot understand that. MANET has >> understood the scenarios where reactive protocols are useful and where >> not. >>=20 >> Now, to the differences: >>=20 >> - DYMO cannot be end-to-end secured. Messages are changed in transit >> (and not just hop-limit or the metric), but rather addresses can be >> removed from RERRs and RREQs. There is also no provision to allow >> external mechanisms to add additional reasons to reject messages as >> invalid. >> - DYMO uses the originator address in an address block, LOADng in the >> message header. The sequence number is a TLV value in DYMO, and LOADng >> uses the message sequence number. DYMO requires the originator address >> to be the first one in the address block, the destination must be the >> second one. LOADng uses a TLV to determine the target address. >> - DYMO can advertise multiple addresses in an RERR; they can be >> removed in transit of the message. >> - DYMO allows intermediate routers to reply (as an option). That makes >> end-to-end security difficult. In the core DYMO, there is a >> destination sequence number that may be contained in RREQs in DYMO. >> - DYMO allows for unicast RREQ, but does not specify in detail how to use= that. >> - There are four timers for each route entry in DYMO, only one in LOADng.= >> - LOADng can be used on other layers; DYMO is tied to IP. >> - LOADng provides a bidirectionality verification using RREP_ACK, a >> time-out of these, a blacklisted set and a Pending Acknowledgment Set >> to verify bidirectional links. DYMO says that other mechanisms can be >> used, but does not specify these. >> - DYMO has several options for expanding ring RREQ, precursor list, >> adding route information in transit, message aggregation in RFC5444 >> packets and reporting multiple unreachable addresses in a RERR. LOADng >> takes the approach to have a slim core of a basic mechanism that is >> applicable in all MANET use cases, and companion documents with >> extensions. In DYMO, it is not clearly specified what happens if some >> routers support an option, and others don't. >> - LOADng uses a Metric message TLV, and it is clearly defined how to >> update the metric under way. If a router in transit does not recognize >> a route metric type, it is reset to a "hop count" tlv extension type >> of the Metric TLV and the value set to 0xFFFFF... (for the full TLV >> length). It is specified that security mechanism must ignore the >> content of the metric TLV value and that the length cannot be changed >> under way, so that end-to-end security is possible. DYMO uses an >> optional "distance" field for the metric, which is not clearly >> specified how it is updated. Also, since this is optional, it is >> unclear if routers receiving a message and forwarding it, update the >> distance field or not. >> - LOADng allows for (optionally) waiting to reply with a RREP, in case >> a "better" RREQ comes a little later. In DYMO, a RREP is always sent >> immediately. >>=20 >> There are probably more differences, but I let other chime in. >>=20 >> Best regards >> Ulrich >>=20 >>=20 >>=20 >>=20 >>=20 >> Note that it's a lot more useful to have direct differences than differen= ces of each from AODV (especially when both have the same difference). And i= t would be useful to have the objective differences separated from the "and n= ow why this is better" discussion - though that would be a next step. >>=20 >> I'm not saying I don't see any of the differences. But I certainly haven'= t worked out the complete list. In trying to form my view of how things shou= ld go forward (a view that is coming together, and when it does, I'll argue f= or it) and I hope for other people as well, it would be good to know what th= e differences are. Regardless of views for or against each, we should be abl= e to objectively list the significant differences - if we can't then somethi= ng is wrong. >>=20 >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >>=20 >> ******************************************************************** >> 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. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> =20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> =20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-1--97870448 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
But that still leaves the problem that w= ith just end to end security, the RREP path is not reported in any message a= nd hence is not protected, and my A - B - X - C - D example.

-- =
Christopher Dearlove

On 2 Nov 2012, at 15:00, Ulrich Herberg <ulrich@herberg.name> wrote:

I am glad that we f= inally have some technical discussions...

I agree t= hat it is more difficult to provide end-to-end security in a reactive protoc= ol than in a proactive link-state. The idea in LOADng is that we know exactl= y the fields that are mutable, and we know that the length will not change n= or the position of any of the fields (but potentially the value of the metri= cs tlv). So it is relatively easy to just zero out the Metric TLV value fiel= d. But I admit it's less straight forward than in OLSRv2.

Ulrich

On Nov 2, 2012, at 7:01, "Dearlove, Christopher (UK)" &= lt;Chris.Dearlove@baesystems.com> wrote:

Yes, of course there can be= malicious routers with link state protocols. I've even helped implement one= . But everything used is a link, and all links are carried in messages/packets, and if all messages/packets are authenticated, then al= l links are authenticated, and hence no malicious routers are included.=

 

But the RREQ/RREP process (= at its simplest) uses information that is not included in any message.<= /o:p>

 

Going back to OLSRv2, yes, a= ll routers will have to agree on a process. But that's another discussion th= at I won't get into right now.

 

= --

= Christopher Dearlove

= Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

=

= chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Ope= rations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Fa= rnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: Teco Boot [mailto:teco@inf-net.nl]
Sent: 02 November 2012 13:00
To: Dearlove, Christopher (UK)
Cc: Jiazi YI; manet@ietf.org; Thomas Heide Clausen (thoma= s@thomasclausen.org)
Subject: Re: [manet] Reactive routing protocols, what are the differe= nces?

 

 

*** WARNING ***

This message originates from outside our organis= ation, either from an external partner or the internet.
Kee= p this in mind if you answer this message.
Ple= ase see this process on how to deal with suspicious emails.

 

Op 2 nov. 2012, om 13:32 heeft Dearlove, Christopher (= UK) het volgende geschreven:



I understand the basics. An= d I agree I can't see (except my bracketed aside) how to do it without a mut= able field. But having that mutable field reduces the value of the argument against DYMO from "DYMO is mutable, LOADng is not" to= "DYMO is (uncontrolled?) mutable, LOADng is managed mutable". I'm not convi= nced by the argument about having to mutate metric type. If you can't rely o= n it being available to your network layer protocol consistently in the one MANET, heterogeneous though i= t may be, I'm not sure you have a well-put-together network. You could alway= s make the metrioc increment when unknown the maximum such value.

 

But there is, as another po= st raised, the larger question of what end to end message authentication buy= s you. If in a route A-B-X-C-D, where X is a bad guy, if X relays all RREQs and RREPs flawlessly, but throws all data packets on t= he floor, X has done his job, and without needing to forge anything. You als= o need B and/or C to authenticate X. Lower layer? (in which case why can't t= hat do the whole job?).

There could be 2nd order nodes: hosts. Or the routing= protocol security mechanism is implemented in the routing deamon, which is v= ery similar to the first.



RREP-ACK? Accumulating sign= ature? Something else?

 

(Note that a link state pro= tocol gets the B-X and X-C done. Those are, after all, links.)

There can be malicious routers with link state protoc= ols too. 

Also, there is a requirement that all routers share t= he same policy on what to do with failed authentication, and result of check= ing must be the same on all nodes. Not easy to deploy. And missing in olsrv2= core protocol.

 

Teco

 



 

--

Christopher Dearlove=

Senior Principal Engineer, C= ommunications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

=

chr= is.dearlove@baesystems.com&= nbsp;| http://www.b= aesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Fa= rnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: = Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI
Sent: 02 November 2= 012 12:13
To: Dearlove, Chris= topher (UK)
Cc: Ulrich Herberg;=  manet@ietf.org; Thomas He= ide Clausen (thomas@thomasclausen.org)
Subject: Re: [manet= ] Reactive routing protocols, what are the differences?

 

 

*** WARNING ***

This message originates from outside our organis= ation, either from an external partner or the internet.
Kee= p this in mind if you answer this message.
Ple= ase see this process <= em>on h= ow to deal with suspicious emails.

Hi,




The reason that LOADng needs those fields mutable is to support differ= ent metrics other than hop-count, even routers using different metrics in the same routing domain can at least find a path. 




To support different metric types, a metric-type tlv and a route-metri= c tlv are needed. The route-metric tlv has to be mutable because it needs to be updated at each hop. <= /p>

Having metric-type tlv mutable can make supporting different metrics i= n the same network possible. 




It's common that in a heterogenous network, there are various transmis= sion medias (802.11, 802.15.4, cable, PLC...), therefore possible different metrics.

In LOADng, if a router A (with metric-A) gets an RREQ message that it d= oesn't understand (say, metric-B), router A will change the metric-type to HOP_COUNT, and forward the message (the hop-count field i= s always used). For the destination of RREQ, it will first consider the metr= ics that it understands, and then HOP_COUNT. Of course, this will result in "= degrading" to HOP_COUNT for certain routes, but at least we can get a usable route. =




I'm just introducing the design of LOADng, and would appreciate any go= od idea on this issue. 




best




Jiazi

 

 

 

On Nov 2, 2012, at 12:42 PM, "Dearlove, Christopher (= UK)" <Chris.Dearlove@baesystems.com> wro= te:




Having anything other than h= op limit and hop count mutable is not the security mechanism suggested in 66= 22/5444.

 

I'm of the view that the cu= rrent approach of securing NHDP, securing OLSRv2 etc. is not where things sh= ould ideally be, that the ideal place is at the 5444 multiplexer wherever possible. If doing hop by hop security, then that is t= he place, as it's where packets live. But if we could do it once for all mes= sage types, then that's a major gain.

 

Now as soon as LOADng has a= nything else mutable, that doesn't help that. OK, it's better than nothing, b= ut those fields are buried in TLVs (using 5444) and messy.

 

I'm at a disadvantage, I ha= ven't studied why LOADng needs those fields (other than hop count) mutable -= or if it really does. But it reduces "here's a clear advantage over DYMO" to "here's a more partial advantage over DYMO". And I t= hink Ulrich's summary could be edited to better present this.

 

So if we adopted my separat= e proposal, this would be on the menu: why are those fields mutable? Do they= have to be? Can we find an alternative? (Unfortunately, I can see why probably not. But it's still a question.)

 

[Actually I can see an alte= rnative, which is a much more limited metric, which takes small integer valu= es, and we increase hop count not by one but by this metric, limiting paths to maximum 255 metric. We could still get hop count f= rom hop limit if we knew how it started - e.g. in a non-mutable TLV. But I s= trongly doubt this is good enough.]

 

--

Christopher Dearlove=

Senior Principal Engineer, C= ommunications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

=

chr= is.dearlove@baesystems.com&= nbsp;| http://www.baesystems= .com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Fa= rnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: = Jiazi YI [mailto:yi.jiazi@gmail.com] <= b>On Behalf Of Jiazi Y= I
Sent: 02 November 2= 012 10:54
To: Dearlove, Chris= topher (UK)
Cc: Ulrich Herberg;=  manet@ietf.org; Thomas Heid= e Clausen (thomas@thomasclausen.org)
Subject: Re: [manet= ] Reactive routing protocols, what are the differences?

 

 

*** WARNING ***

This message originates from outside our organis= ation, either from an external partner or the internet.
Kee= p this in mind if you answer this message.
Ple= ase see this process <= /span>on how to deal with suspicious emails.<= /p>

Hi Chr= is, 





I thin= k Ulrich is in deep sleep at the moment, so please allow me to have some wor= ds on this. 





For re= active protocols, updating the route information (hop-count, metric) is inev= itable. In the specification of DYMO, the messages can be changed relatively arbitrarily, including removing addresses from the me= ssages. The intermediate RREP also makes end-to-end security impossible.&nbs= p;





LOADng= clearly defines which fields in the routing messages can't be changed, and w= hich fields are mutable. For example, for RREQ:

=





The f= ollowing fields of an RREQ message are immutable, i.e., they MUST NOT be cha= nged during processing or forwarding of the message: RREQ.addr-length, RREQ.= seq-num, RREQ.originator, and RREQ.destination.

The f= ollowing fields of an RREQ message are mutable, i.e., they will be changed b= y intermediate routers during processing or forwarding, as specified in = ;Section 12.2 and Section 12.3: RREQ.metric-type, RREQ.route-metric, and RREQ.hop-count.<= /p>

Any a= dditional field that is added to the message by an extension to this protoco= l, e.g., by way of TLVs, MUST be considered immutable, unless the extension s= pecifically defines the field as mutable.





This a= llows the protocol to secure the messages by zeroing the mutable fields.&nbs= p;





best





Jiazi&= nbsp;





(sorry= to Chris if you received multiple copy of this message. I fixed one typo th= ough :) My previous one was bounced by manet mailing list because of not using the right sender address)

=

 

 

On Nov 2, 2012, at 11:22 AM, "Dearlove, Christopher (= UK)" <Chris.Dearlove@baesystems.com> wrote:





There is, superficially at least, an apparent contrad= iction between your points:

- DYMO cannot be end-to-end secured. Messages are changed in transit
(and not just hop-limit or the metric), but rather addresses can be
removed from RERRs and RREQs.

which implicitly suggests LOADng does not do this

and 

- LOADng uses a Metric message TLV, and it is clearly defined how to
update the metric under way.

Could you expand on this please?

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesy= stems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Fa= rnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Ulrich Herberg [mailto:ulrich@herberg.name] 
Sent: 01 November 2012 22:02
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; Thomas H= eide Clausen (thomas@thomasclausen.org)
Subject: Re: [manet] Reactive routing protocols, what are the differences?
----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hi Chris,

you have seen my review on DYMO. I will try to answer to your
question, and focus on the technical differences, not presentation.


On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK)
<Chris.Dearlove@baesystems.com> wrote:



The obviously best people to answer this should be do= cument authors, but anyone else may have useful additions and comments. Idea= lly the different document authors could agree a list. (If they differ in th= at one has X and the other doesn't, but one wants to say "we plan to add/remove X" then X should be listed as a= difference with that caveat, in at least my ideal world.)

If we set aside, for the moment (though these things matter):
- The presentational quality of the documents,
- Any issues of 5444 compliance and other formatting issues,
- Issues of internal data organisation,
- Minor details such as possible different timeout parameters etc.
then what are the technical (and I stress that word) differences between DYM= O and LOADng? (I'm withholding the term AODVv2 for reasons I may come back t= o.)



First, let's see what is common. Both are reactive protocols, using
RREQ, RREP and RERR. So if someone claims that DYMO performs great and
LOADng badly in the same scenario, I cannot understand that. MANET has
understood the scenarios where reactive protocols are useful and where
not.

Now, to the differences:

- DYMO cannot be end-to-end secured. Messages are changed in transit
(and not just hop-limit or the metric), but rather addresses can be
removed from RERRs and RREQs. There is also no provision to allow
external mechanisms to add additional reasons to reject messages as
invalid.
- DYMO uses the originator address in an address block, LOADng in the
message header. The sequence number is a TLV value in DYMO, and LOADng
uses the message sequence number. DYMO requires the originator address
to be the first one in the address block, the destination must be the
second one. LOADng uses a TLV to determine the target address.
- DYMO can advertise multiple addresses in an RERR; they can be
removed in transit of the message.
- DYMO allows intermediate routers to reply (as an option). That makes
end-to-end security difficult. In the core DYMO, there is a
destination sequence number that may be contained in RREQs in DYMO.
- DYMO allows for unicast RREQ, but does not specify in detail how to use th= at.
- There are four timers for each route entry in DYMO, only one in LOADng. - LOADng can be used on other layers; DYMO is tied to IP.
- LOADng provides a bidirectionality verification using RREP_ACK, a
time-out of these, a blacklisted set and a Pending Acknowledgment Set
to verify bidirectional links. DYMO says that other mechanisms can be
used, but does not specify these.
- DYMO has several options for expanding ring RREQ, precursor list,
adding route information in transit, message aggregation in RFC5444
packets and reporting multiple unreachable addresses in a RERR. LOADng
takes the approach to have a slim core of a basic mechanism that is
applicable in all MANET use cases, and companion documents with
extensions. In DYMO, it is not clearly specified what happens if some
routers support an option, and others don't.
- LOADng uses a Metric message TLV, and it is clearly defined how to
update the metric under way. If a router in transit does not recognize
a route metric type, it is reset to a "hop count" tlv extension type
of the Metric TLV and the value set to 0xFFFFF... (for the full TLV
length). It is specified that security mechanism must ignore the
content of the metric TLV value and that the length cannot be changed
under way, so that end-to-end security is possible. DYMO uses an
optional "distance" field for the metric, which is not clearly
specified how it is updated. Also, since this is optional, it is
unclear if routers receiving a message and forwarding it, update the
distance field or not.
- LOADng allows for (optionally) waiting to reply with a RREP, in case
a "better" RREQ comes a little later. In DYMO, a RREP is always sent
immediately.

There are probably more differences, but I let other chime in.

Best regards
Ulrich





Note that it's a lot more useful to have direct diffe= rences than differences of each from AODV (especially when both have the sam= e difference). And it would be useful to have the objective differences sepa= rated from the "and now why this is better" discussion - though that would be a next step.

I'm not saying I don't see any of the differences. But I certainly haven't w= orked out the complete list. In trying to form my view of how things should g= o forward (a view that is coming together, and when it does, I'll argue for i= t) and I hope for other people as well, it would be good to know what the differences are. Regardless of v= iews for or against each, we should be able to objectively list the signific= ant differences - if we can't then something is wrong.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesy= stems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Fa= rnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687



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

_______________________________________________
manet mailing list
manet@ietf.or= g
https://www.ietf.org/mailman/listinfo/ma= net


_______________________________________________
manet mailing list
manet@ietf.or= g
https://www.ietf.org/mailman/listinfo/ma= net

 

___________________________________________= ____
manet mailing list
manet@ie= tf.org
https://www.ietf.org/mailman/listinfo/ma= net

 

____________________= ___________________________
manet mailing list
manet= @ietf.org
https:= //www.ietf.org/mailman/listinfo/manet
<= /div>
_______________________________________________
manet mailing list
man= et@ietf.org
https://www.ietf.org/mailman/listinfo/manet
=
= --Apple-Mail-1--97870448-- From salo@saloits.com Fri Nov 2 09:06:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FBC21F878B for ; Fri, 2 Nov 2012 09:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hf1QDJl7PVt for ; Fri, 2 Nov 2012 09:06:49 -0700 (PDT) Received: from server.saloits.com (saloits.com [208.42.140.127]) by ietfa.amsl.com (Postfix) with ESMTP id 09F5D21F8B38 for ; Fri, 2 Nov 2012 09:06:47 -0700 (PDT) Received: from [192.168.255.119] (thinkpad2.saloits.com [192.168.255.119]) by server.saloits.com (8.14.4/8.14.3) with ESMTP id qA2G6f3X031811; Fri, 2 Nov 2012 11:06:41 -0500 Message-ID: <5093EF93.70201@saloits.com> Date: Fri, 02 Nov 2012 11:06:43 -0500 From: "Timothy J. Salo" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 To: "JP Vasseur (jvasseur)" References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "manet@ietf.org" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 16:06:50 -0000 >>> JP> This is not just a question of "how large" it is … but also how >>> dynamic. I could show you few hundreds (if not less number of nodes) >>> not working if the traffic pattern is too dynamic. This is a >>> fundamental problem. No, it is a fundamental and well-known characteristic of reactive routing protocols. It is a problem only when this behavior doesn't match the characteristics of the network in which the reactive routing protocol is deployed. We've known for at least 15 years that reactive routing protocols are more appropriate for light traffic loads and that proactive routing protocols are more appropriate with heavier traffic loads. Dozens, probably hundreds of research papers have reiterated this result. I don't know of any that have contradicted this result, although some researchers have tried to develop hybrid routing protocols (which don't seem to have gained much traction, either in the IETF or elsewhere). Claiming that reactive routing protocols don't scale to heavier traffic loads is neither a new result nor particularly insightful -- this hasn't changed for at least 15 years. I haven't seen any evidence that _no_ LLN will experience the sort of light traffic load that matches the characteristics of a reactive routing protocol. To the contrary, the deployment experience with LOADng suggests that such do networks exist. At the risk of arguing by analogy, the argument that one can "prove" that reactive routing protocols don't work (in LLNs or elsewhere) seems to make about as much as sense as "proving" that OSPF doesn't work because it doesn't behave well in dynamic environments. The failure of OSPF in dynamic environments didn't cause us to abandon OSPF: there are many environments in which it works well. Rather, we concluded that we needed another routing protocol. In a similar manner, the MANET working group, and as far as I have seen pretty much all of the research community, concluded that there is a need for both a reactive routing protocol and a proactive routing protocol. Of course, the ROLL working group can decide not to standardize a reactive routing protocol. However, that doesn't prove that reactive routing protocols don't work (when they match the traffic characteristics of the network), that reactive routing protocols won't work better than proactive routing protocols in some LLNs (based on the characteristics of the traffic load), or that reactive routing protocols won't be successfully deployed in LLNs. If fact, the LOADng deployment experience strongly suggests that reactive routing protocols _will_ be deployed in some LLNs. And, they will be deployed regardless of the ROLL working group's decision to not standardize a reactive routing protocol. Claiming that reactive routing protocols don't work because they don't scale to higher traffic loads seems, at best, a poor characterization of well-known research results, and at worst a distraction from the question at hand: namely how to proceed towards an Internet-standard reactive routing protocol. -tjs From yi.jiazi@gmail.com Fri Nov 2 09:14:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36EC21F8875 for ; Fri, 2 Nov 2012 09:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unAWput5v2Z1 for ; Fri, 2 Nov 2012 09:14:36 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8399721F87F5 for ; Fri, 2 Nov 2012 09:14:35 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1764529wgb.13 for ; Fri, 02 Nov 2012 09:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=vq6tt4xdHBsVJjWoCdS6+LZpO9HVhWfFKGuyiLHYbXE=; b=NYkucf3j8akJt6rCDmX1m0++lm0WA0K+aiGS61UeGq35lxH9WNQcimjn5NlZIYEJfp PhySvH9o4GLVVLUg8bHeGLWSclFtj0G3Mjvi1oTCPy3whFh0VW2y/8eeKFyxG8aely6N +kCwG2Hy/oZxdXiuS++pwnulPx5HUq8+UR1t+3evInbwbhNllIMn94U8b2IfFLlGNacv nTwdAfxeerw4+5QZMLB+3b5HNMZmOLca77pnUg3114Y1ZCRopPKHYGwzGCYQtBV10R0i HLnOMRhS/oZDAUIYNPr+KnLqPEYLNujbc0QynS1t0NStOcEZoC8SYxtyrt6ZdLIwkOKJ BCrA== Received: by 10.216.213.152 with SMTP id a24mr847829wep.224.1351872874464; Fri, 02 Nov 2012 09:14:34 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id fg6sm2861988wib.3.2012.11.02.09.14.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 09:14:33 -0700 (PDT) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_FD5153FC-8473-4BF4-8744-850F8AA671F4" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi YI In-Reply-To: <4FC8B1E4-6747-4C36-A7A3-5991F326EF95@gmail.com> Date: Fri, 2 Nov 2012 17:14:29 +0100 Message-Id: <1C92F2E6-721C-4A9D-9BC7-E8A8529E67BE@jiaziyi.com> References: <12708D7E-C548-4858-8144-6F04D2750E02@jiaziyi.com> <4F9C6208-78B8-41B1-81D2-C7DAAE9D780D@jiaziyi.com> <4FC8B1E4-6747-4C36-A7A3-5991F326EF95@gmail.com> To: Christopher Dearlove X-Mailer: Apple Mail (2.1499) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Thomas Heide Clausen\(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 16:14:39 -0000 --Apple-Mail=_FD5153FC-8473-4BF4-8744-850F8AA671F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree that in your A-B-X-C-D example, end-to-end security is not = enough.=20 But it can protect the network from certain attacks. For example, it can = prevents X flooding numerous RREQs, or X spoofing the identify of D to = send a RREP.=20 And I think your comments on metric-type TLV make sense. I'll discuss = with other LOADng authors.=20 best Jiazi On Nov 2, 2012, at 4:51 PM, Christopher Dearlove = wrote: > But that still leaves the problem that with just end to end security, = the RREP path is not reported in any message and hence is not protected, = and my A - B - X - C - D example. >=20 > --=20 > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) >=20 > On 2 Nov 2012, at 15:00, Ulrich Herberg wrote: >=20 >> I am glad that we finally have some technical discussions... >>=20 >> I agree that it is more difficult to provide end-to-end security in a = reactive protocol than in a proactive link-state. The idea in LOADng is = that we know exactly the fields that are mutable, and we know that the = length will not change nor the position of any of the fields (but = potentially the value of the metrics tlv). So it is relatively easy to = just zero out the Metric TLV value field. But I admit it's less straight = forward than in OLSRv2. >>=20 >> Ulrich >>=20 >> On Nov 2, 2012, at 7:01, "Dearlove, Christopher (UK)" = wrote: >>=20 >>> Yes, of course there can be malicious routers with link state = protocols. I've even helped implement one. But everything used is a = link, and all links are carried in messages/packets, and if all = messages/packets are authenticated, then all links are authenticated, = and hence no malicious routers are included. >>> =20 >>> But the RREQ/RREP process (at its simplest) uses information that is = not included in any message. >>> =20 >>> Going back to OLSRv2, yes, all routers will have to agree on a = process. But that's another discussion that I won't get into right now. >>> =20 >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>> =20 >>> From: Teco Boot [mailto:teco@inf-net.nl]=20 >>> Sent: 02 November 2012 13:00 >>> To: Dearlove, Christopher (UK) >>> Cc: Jiazi YI; manet@ietf.org; Thomas Heide Clausen = (thomas@thomasclausen.org) >>> Subject: Re: [manet] Reactive routing protocols, what are the = differences? >>> =20 >>> =20 >>> *** WARNING *** >>> This message originates from outside our organisation, either from = an external partner or the internet. >>> Keep this in mind if you answer this message. >>> Please see this process on how to deal with suspicious emails. >>>=20 >>> =20 >>> Op 2 nov. 2012, om 13:32 heeft Dearlove, Christopher (UK) het = volgende geschreven: >>>=20 >>>=20 >>> I understand the basics. And I agree I can't see (except my = bracketed aside) how to do it without a mutable field. But having that = mutable field reduces the value of the argument against DYMO from "DYMO = is mutable, LOADng is not" to "DYMO is (uncontrolled?) mutable, LOADng = is managed mutable". I'm not convinced by the argument about having to = mutate metric type. If you can't rely on it being available to your = network layer protocol consistently in the one MANET, heterogeneous = though it may be, I'm not sure you have a well-put-together network. You = could always make the metrioc increment when unknown the maximum such = value. >>> =20 >>> But there is, as another post raised, the larger question of what = end to end message authentication buys you. If in a route A-B-X-C-D, = where X is a bad guy, if X relays all RREQs and RREPs flawlessly, but = throws all data packets on the floor, X has done his job, and without = needing to forge anything. You also need B and/or C to authenticate X. = Lower layer? (in which case why can't that do the whole job?). >>> There could be 2nd order nodes: hosts. Or the routing protocol = security mechanism is implemented in the routing deamon, which is very = similar to the first. >>>=20 >>>=20 >>> RREP-ACK? Accumulating signature? Something else? >>> =20 >>> (Note that a link state protocol gets the B-X and X-C done. Those = are, after all, links.) >>> There can be malicious routers with link state protocols too.=20 >>> Also, there is a requirement that all routers share the same policy = on what to do with failed authentication, and result of checking must be = the same on all nodes. Not easy to deploy. And missing in olsrv2 core = protocol. >>> =20 >>> Teco >>> =20 >>>=20 >>>=20 >>> =20 >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>> =20 >>> From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI >>> Sent: 02 November 2012 12:13 >>> To: Dearlove, Christopher (UK) >>> Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Clausen = (thomas@thomasclausen.org) >>> Subject: Re: [manet] Reactive routing protocols, what are the = differences? >>> =20 >>> =20 >>> *** WARNING *** >>> This message originates from outside our organisation, either from = an external partner or the internet. >>> Keep this in mind if you answer this message. >>> Please see this process on how to deal with suspicious emails. >>>=20 >>> Hi, >>>=20 >>>=20 >>>=20 >>> The reason that LOADng needs those fields mutable is to support = different metrics other than hop-count, even routers using different = metrics in the same routing domain can at least find a path.=20 >>>=20 >>>=20 >>>=20 >>> To support different metric types, a metric-type tlv and a = route-metric tlv are needed. The route-metric tlv has to be mutable = because it needs to be updated at each hop.=20 >>> Having metric-type tlv mutable can make supporting different metrics = in the same network possible.=20 >>>=20 >>>=20 >>>=20 >>> It's common that in a heterogenous network, there are various = transmission medias (802.11, 802.15.4, cable, PLC...), therefore = possible different metrics. >>> In LOADng, if a router A (with metric-A) gets an RREQ message that = it doesn't understand (say, metric-B), router A will change the = metric-type to HOP_COUNT, and forward the message (the hop-count field = is always used). For the destination of RREQ, it will first consider the = metrics that it understands, and then HOP_COUNT. Of course, this will = result in "degrading" to HOP_COUNT for certain routes, but at least we = can get a usable route.=20 >>>=20 >>>=20 >>>=20 >>> I'm just introducing the design of LOADng, and would appreciate any = good idea on this issue.=20 >>>=20 >>>=20 >>>=20 >>> best >>>=20 >>>=20 >>>=20 >>> Jiazi >>> =20 >>> =20 >>> =20 >>> On Nov 2, 2012, at 12:42 PM, "Dearlove, Christopher (UK)" = wrote: >>>=20 >>>=20 >>>=20 >>> Having anything other than hop limit and hop count mutable is not = the security mechanism suggested in 6622/5444. >>> =20 >>> I'm of the view that the current approach of securing NHDP, securing = OLSRv2 etc. is not where things should ideally be, that the ideal place = is at the 5444 multiplexer wherever possible. If doing hop by hop = security, then that is the place, as it's where packets live. But if we = could do it once for all message types, then that's a major gain. >>> =20 >>> Now as soon as LOADng has anything else mutable, that doesn't help = that. OK, it's better than nothing, but those fields are buried in TLVs = (using 5444) and messy. >>> =20 >>> I'm at a disadvantage, I haven't studied why LOADng needs those = fields (other than hop count) mutable - or if it really does. But it = reduces "here's a clear advantage over DYMO" to "here's a more partial = advantage over DYMO". And I think Ulrich's summary could be edited to = better present this. >>> =20 >>> So if we adopted my separate proposal, this would be on the menu: = why are those fields mutable? Do they have to be? Can we find an = alternative? (Unfortunately, I can see why probably not. But it's still = a question.) >>> =20 >>> [Actually I can see an alternative, which is a much more limited = metric, which takes small integer values, and we increase hop count not = by one but by this metric, limiting paths to maximum 255 metric. We = could still get hop count from hop limit if we knew how it started - = e.g. in a non-mutable TLV. But I strongly doubt this is good enough.] >>> =20 >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>> =20 >>> From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI >>> Sent: 02 November 2012 10:54 >>> To: Dearlove, Christopher (UK) >>> Cc: Ulrich Herberg; manet@ietf.org; Thomas Heide Clausen = (thomas@thomasclausen.org) >>> Subject: Re: [manet] Reactive routing protocols, what are the = differences? >>> =20 >>> =20 >>> *** WARNING *** >>> This message originates from outside our organisation, either from = an external partner or the internet. >>> Keep this in mind if you answer this message. >>> Please see this process on how to deal with suspicious emails. >>>=20 >>> Hi Chris,=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> I think Ulrich is in deep sleep at the moment, so please allow me to = have some words on this.=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> For reactive protocols, updating the route information (hop-count, = metric) is inevitable. In the specification of DYMO, the messages can be = changed relatively arbitrarily, including removing addresses from the = messages. The intermediate RREP also makes end-to-end security = impossible.=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> LOADng clearly defines which fields in the routing messages can't be = changed, and which fields are mutable. For example, for RREQ: >>>=20 >>>=20 >>>=20 >>>=20 >>> The following fields of an RREQ message are immutable, i.e., they = MUST NOT be changed during processing or forwarding of the message: = RREQ.addr-length, RREQ.seq-num, RREQ.originator, and RREQ.destination. >>> The following fields of an RREQ message are mutable, i.e., they will = be changed by intermediate routers during processing or forwarding, as = specified in Section 12.2 and Section 12.3: RREQ.metric-type, = RREQ.route-metric, and RREQ.hop-count. >>> Any additional field that is added to the message by an extension to = this protocol, e.g., by way of TLVs, MUST be considered immutable, = unless the extension specifically defines the field as mutable. >>>=20 >>>=20 >>>=20 >>>=20 >>> This allows the protocol to secure the messages by zeroing the = mutable fields.=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> best >>>=20 >>>=20 >>>=20 >>>=20 >>> Jiazi=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> (sorry to Chris if you received multiple copy of this message. I = fixed one typo though :) My previous one was bounced by manet mailing = list because of not using the right sender address) >>> =20 >>> =20 >>> On Nov 2, 2012, at 11:22 AM, "Dearlove, Christopher (UK)" = wrote: >>>=20 >>>=20 >>>=20 >>>=20 >>> There is, superficially at least, an apparent contradiction between = your points: >>>=20 >>> - DYMO cannot be end-to-end secured. Messages are changed in transit >>> (and not just hop-limit or the metric), but rather addresses can be >>> removed from RERRs and RREQs. >>>=20 >>> which implicitly suggests LOADng does not do this >>>=20 >>> and=20 >>>=20 >>> - LOADng uses a Metric message TLV, and it is clearly defined how to >>> update the metric under way. >>>=20 >>> Could you expand on this please? >>>=20 >>> --=20 >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Ulrich Herberg [mailto:ulrich@herberg.name]=20 >>> Sent: 01 November 2012 22:02 >>> To: Dearlove, Christopher (UK) >>> Cc: manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.org) >>> Subject: Re: [manet] Reactive routing protocols, what are the = differences? >>>=20 >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>>=20 >>> Hi Chris, >>>=20 >>> you have seen my review on DYMO. I will try to answer to your >>> question, and focus on the technical differences, not presentation. >>>=20 >>>=20 >>> On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK) >>> wrote: >>>=20 >>>=20 >>>=20 >>> The obviously best people to answer this should be document authors, = but anyone else may have useful additions and comments. Ideally the = different document authors could agree a list. (If they differ in that = one has X and the other doesn't, but one wants to say "we plan to = add/remove X" then X should be listed as a difference with that caveat, = in at least my ideal world.) >>>=20 >>> If we set aside, for the moment (though these things matter): >>> - The presentational quality of the documents, >>> - Any issues of 5444 compliance and other formatting issues, >>> - Issues of internal data organisation, >>> - Minor details such as possible different timeout parameters etc. >>> then what are the technical (and I stress that word) differences = between DYMO and LOADng? (I'm withholding the term AODVv2 for reasons I = may come back to.) >>>=20 >>>=20 >>> First, let's see what is common. Both are reactive protocols, using >>> RREQ, RREP and RERR. So if someone claims that DYMO performs great = and >>> LOADng badly in the same scenario, I cannot understand that. MANET = has >>> understood the scenarios where reactive protocols are useful and = where >>> not. >>>=20 >>> Now, to the differences: >>>=20 >>> - DYMO cannot be end-to-end secured. Messages are changed in transit >>> (and not just hop-limit or the metric), but rather addresses can be >>> removed from RERRs and RREQs. There is also no provision to allow >>> external mechanisms to add additional reasons to reject messages as >>> invalid. >>> - DYMO uses the originator address in an address block, LOADng in = the >>> message header. The sequence number is a TLV value in DYMO, and = LOADng >>> uses the message sequence number. DYMO requires the originator = address >>> to be the first one in the address block, the destination must be = the >>> second one. LOADng uses a TLV to determine the target address. >>> - DYMO can advertise multiple addresses in an RERR; they can be >>> removed in transit of the message. >>> - DYMO allows intermediate routers to reply (as an option). That = makes >>> end-to-end security difficult. In the core DYMO, there is a >>> destination sequence number that may be contained in RREQs in DYMO. >>> - DYMO allows for unicast RREQ, but does not specify in detail how = to use that. >>> - There are four timers for each route entry in DYMO, only one in = LOADng. >>> - LOADng can be used on other layers; DYMO is tied to IP. >>> - LOADng provides a bidirectionality verification using RREP_ACK, a >>> time-out of these, a blacklisted set and a Pending Acknowledgment = Set >>> to verify bidirectional links. DYMO says that other mechanisms can = be >>> used, but does not specify these. >>> - DYMO has several options for expanding ring RREQ, precursor list, >>> adding route information in transit, message aggregation in RFC5444 >>> packets and reporting multiple unreachable addresses in a RERR. = LOADng >>> takes the approach to have a slim core of a basic mechanism that is >>> applicable in all MANET use cases, and companion documents with >>> extensions. In DYMO, it is not clearly specified what happens if = some >>> routers support an option, and others don't. >>> - LOADng uses a Metric message TLV, and it is clearly defined how to >>> update the metric under way. If a router in transit does not = recognize >>> a route metric type, it is reset to a "hop count" tlv extension type >>> of the Metric TLV and the value set to 0xFFFFF... (for the full TLV >>> length). It is specified that security mechanism must ignore the >>> content of the metric TLV value and that the length cannot be = changed >>> under way, so that end-to-end security is possible. DYMO uses an >>> optional "distance" field for the metric, which is not clearly >>> specified how it is updated. Also, since this is optional, it is >>> unclear if routers receiving a message and forwarding it, update the >>> distance field or not. >>> - LOADng allows for (optionally) waiting to reply with a RREP, in = case >>> a "better" RREQ comes a little later. In DYMO, a RREP is always sent >>> immediately. >>>=20 >>> There are probably more differences, but I let other chime in. >>>=20 >>> Best regards >>> Ulrich >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Note that it's a lot more useful to have direct differences than = differences of each from AODV (especially when both have the same = difference). And it would be useful to have the objective differences = separated from the "and now why this is better" discussion - though that = would be a next step. >>>=20 >>> I'm not saying I don't see any of the differences. But I certainly = haven't worked out the complete list. In trying to form my view of how = things should go forward (a view that is coming together, and when it = does, I'll argue for it) and I hope for other people as well, it would = be good to know what the differences are. Regardless of views for or = against each, we should be able to objectively list the significant = differences - if we can't then something is wrong. >>>=20 >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>>=20 >>>=20 >>> ******************************************************************** >>> 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. >>> ******************************************************************** >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> =20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> =20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_FD5153FC-8473-4BF4-8744-850F8AA671F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I agree that = in your A-B-X-C-D example, end-to-end security is not = enough. 
But it can = protect the network from certain attacks. For example, it can prevents X = flooding numerous RREQs, or X spoofing the identify of D to send a = RREP. 

And I think your comments on = metric-type TLV make sense. I'll discuss with other LOADng = authors. 

best

Jiazi

On Nov 2, 2012, at 4:51 PM, Christopher Dearlove <christopher.dearlove@g= ooglemail.com> wrote:

But that still leaves the problem that with = just end to end security, the RREP path is not reported in any message = and hence is not protected, and my A - B - X - C - D = example.

-- 
Christopher Dearlove
I am glad that we finally have some technical = discussions...

I agree that it is more = difficult to provide end-to-end security in a reactive protocol than in = a proactive link-state. The idea in LOADng is that we know exactly the = fields that are mutable, and we know that the length will not change nor = the position of any of the fields (but potentially the value of the = metrics tlv). So it is relatively easy to just zero out the Metric TLV = value field. But I admit it's less straight forward than in = OLSRv2.

Ulrich

On Nov 2, 2012, at 7:01, = "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.co= m> wrote:

Yes, of course there can be malicious routers with = link state protocols. I've even helped implement one. But everything = used is a link, and all links are carried in messages/packets, and if all messages/packets are authenticated, = then all links are authenticated, and hence no malicious routers are = included.

 

But the RREQ/RREP process (at its simplest) uses = information that is not included in any message.

 

Going back to OLSRv2, yes, all routers will have = to agree on a process. But that's another discussion that I won't get = into right now.

 

--

Christopher = Dearlove

Senior Principal = Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 = 242124

chris.dearlove@baesystems.com= | http://www.baesystems.com

BAE Systems = (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: Teco Boot [mailto:teco@inf-net.nl]
Sent: 02 November 2012 13:00
To: Dearlove, Christopher (UK)
Cc: Jiazi YI; manet@ietf.org; Thomas Heide Clausen = (thomas@thomasclausen.org)
= Subject: Re: [manet] Reactive routing protocols, what are the = differences?

 

 

*** WARNING ***

This message originates from outside our = organisation, either from an external partner or the = internet.
Keep this = in mind if you answer this message.
Please = see this process on how to deal with suspicious = emails.

 

Op 2 nov. 2012, om 13:32 heeft Dearlove, = Christopher (UK) het volgende geschreven:



I understand the basics. And I agree I can't see = (except my bracketed aside) how to do it without a mutable field. But = having that mutable field reduces the value of the argument against DYMO from "DYMO is mutable, LOADng is = not" to "DYMO is (uncontrolled?) mutable, LOADng is managed mutable". = I'm not convinced by the argument about having to mutate metric type. If = you can't rely on it being available to your network layer protocol consistently in the one MANET, heterogeneous = though it may be, I'm not sure you have a well-put-together network. You = could always make the metrioc increment when unknown the maximum such = value.

 

But there is, as another post raised, the larger = question of what end to end message authentication buys you. If in a = route A-B-X-C-D, where X is a bad guy, if X relays all RREQs and RREPs flawlessly, but throws all data packets = on the floor, X has done his job, and without needing to forge anything. = You also need B and/or C to authenticate X. Lower layer? (in which case = why can't that do the whole job?).

There could be 2nd order nodes: hosts. Or = the routing protocol security mechanism is implemented in the routing = deamon, which is very similar to the first.



RREP-ACK? Accumulating signature? Something = else?

 

(Note that a link state protocol gets the B-X and = X-C done. Those are, after all, links.)

There can be malicious routers with link = state protocols too. 

Also, there is a requirement that all = routers share the same policy on what to do with failed authentication, = and result of checking must be the same on all nodes. Not easy to = deploy. And missing in olsrv2 core protocol.

 

Teco

 



 

--

Christopher Dearlove

Senior Principal Engineer, Communications = Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 = 242124

chris.dearlove@baesystems.com=  | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI
Sent: 02 = November 2012 12:13
To: Dearlove, = Christopher (UK)
Cc: Ulrich = Herberg; manet@ietf.org; Thomas Heide Clausen = (thomas@thomasclausen.org)
= Subject: Re: = [manet] Reactive routing protocols, what are the = differences?

 

 

*** WARNING ***

This message originates from outside our = organisation, either from an external partner or the = internet.
Keep this = in mind if you answer this message.
Please = see this process on how to = deal with suspicious emails.




The = reason that LOADng needs those fields mutable is to support different = metrics other than hop-count, even routers using different metrics in the same routing domain can at least find a = path. 




To = support different metric types, a metric-type tlv and a route-metric tlv = are needed. The route-metric tlv has to be mutable because it needs to be updated at each = hop. 

Having = metric-type tlv mutable can make supporting different metrics in the = same network possible. 




It's = common that in a heterogenous network, there are various transmission = medias (802.11, 802.15.4, cable, PLC...), therefore possible different metrics.

In = LOADng, if a router A (with metric-A) gets an RREQ message that it = doesn't understand (say, metric-B), router A will change the metric-type to HOP_COUNT, and forward the message (the hop-count = field is always used). For the destination of RREQ, it will first = consider the metrics that it understands, and then HOP_COUNT. Of course, = this will result in "degrading" to HOP_COUNT for certain routes, but at least we can get a usable = route. 




I'm = just introducing the design of LOADng, and would appreciate any good = idea on this issue. 







 

 

On Nov 2, 2012, at 12:42 PM, "Dearlove, = Christopher (UK)" <Chris.Dearlove@baesystems.co= m> wrote:




Having anything other than hop limit and hop count = mutable is not the security mechanism suggested in = 6622/5444.

 

I'm of the view that the current approach of = securing NHDP, securing OLSRv2 etc. is not where things should ideally = be, that the ideal place is at the 5444 multiplexer wherever possible. If doing hop by hop security, then that = is the place, as it's where packets live. But if we could do it once for = all message types, then that's a major gain.

 

Now as soon as LOADng has anything else mutable, = that doesn't help that. OK, it's better than nothing, but those fields = are buried in TLVs (using 5444) and messy.

 

I'm at a disadvantage, I haven't studied why = LOADng needs those fields (other than hop count) mutable - or if it = really does. But it reduces "here's a clear advantage over DYMO" to "here's a more partial advantage over DYMO". = And I think Ulrich's summary could be edited to better present = this.

 

So if we adopted my separate proposal, this would = be on the menu: why are those fields mutable? Do they have to be? Can we = find an alternative? (Unfortunately, I can see why probably not. But it's still a = question.)

 

[Actually I can see an alternative, which is a = much more limited metric, which takes small integer values, and we = increase hop count not by one but by this metric, limiting paths to maximum 255 metric. We could still get hop = count from hop limit if we knew how it started - e.g. in a non-mutable = TLV. But I strongly doubt this is good enough.]

 

--

Christopher Dearlove

Senior Principal Engineer, Communications = Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 = 242124

chris.dearlove@baesystems.com=  | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: Jiazi YI [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI
Sent: 02 = November 2012 10:54
To: Dearlove, = Christopher (UK)
Cc: Ulrich = Herberg; manet@ietf.org; Thomas Heide Clausen = (thomas@thomasclausen.org)
Subject: Re: = [manet] Reactive routing protocols, what are the = differences?

 

 

*** WARNING ***

This message originates from outside our = organisation, either from an external partner or the = internet.
Keep this = in mind if you answer this message.
Please = see this process on how to = deal with suspicious emails.

Hi Chris, 





I think Ulrich is in deep sleep at the moment, so please allow = me to have some words on this. 





For reactive protocols, updating the route information = (hop-count, metric) is inevitable. In the specification of DYMO, the = messages can be changed relatively arbitrarily, including removing addresses from = the messages. The intermediate RREP also makes end-to-end security = impossible. 





LOADng clearly defines which fields in the routing messages = can't be changed, and which fields are mutable. For example, for = RREQ:





The= following fields of an RREQ message are immutable, i.e., they MUST NOT = be changed during processing or forwarding of the message: = RREQ.addr-length, RREQ.seq-num, RREQ.originator, and = RREQ.destination.

The= following fields of an RREQ message are mutable, i.e., they will be = changed by intermediate routers during processing or forwarding, as = specified in Section 12.2<= /a> and Section 12.3<= /a>: RREQ.metric-type, RREQ.route-metric, and = RREQ.hop-count.

Any= additional field that is added to the message by an extension to this = protocol, e.g., by way of TLVs, MUST be considered immutable, unless the = extension specifically defines the field as = mutable.

This allows the protocol to secure the messages by zeroing the = mutable fields. 





best





Jiazi 





(sorry to Chris if you received multiple copy of this message. = I fixed one typo though :) My previous one was bounced by manet mailing = list because of not using the right sender = address)

 

 

On Nov 2, 2012, at 11:22 AM, "Dearlove, = Christopher (UK)" <Chris.Dearlove@baesystems.com> = wrote:





There is, superficially at least, an = apparent contradiction between your points:

- DYMO cannot be end-to-end secured. Messages are changed in transit
(and not just hop-limit or the metric), but rather addresses can be
removed from RERRs and RREQs.

which implicitly suggests LOADng does not do this

and 

- LOADng uses a Metric message TLV, and it is clearly defined how to
update the metric under way.

Could you expand on this please?

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Ulrich Herberg [mailto:ulrich@herberg.name] 
Sent: 01 November 2012 22:02
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; Thomas Heide Clausen = (thomas@thomasclausen.org)
Subject: Re: [manet] Reactive routing protocols, what are the = differences?

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hi Chris,

you have seen my review on DYMO. I will try to answer to your
question, and focus on the technical differences, not presentation.


On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK)
<Chris.Dearlove@baesystems.com> = wrote:



The obviously best people to answer this = should be document authors, but anyone else may have useful additions = and comments. Ideally the different document authors could agree a list. = (If they differ in that one has X and the other doesn't, but one wants to say "we plan to add/remove X" then X should be listed = as a difference with that caveat, in at least my ideal world.)

If we set aside, for the moment (though these things matter):
- The presentational quality of the documents,
- Any issues of 5444 compliance and other formatting issues,
- Issues of internal data organisation,
- Minor details such as possible different timeout parameters etc.
then what are the technical (and I stress that word) differences between = DYMO and LOADng? (I'm withholding the term AODVv2 for reasons I may come = back to.)



First, let's see what is common. Both are reactive protocols, using
RREQ, RREP and RERR. So if someone claims that DYMO performs great = and
LOADng badly in the same scenario, I cannot understand that. MANET = has
understood the scenarios where reactive protocols are useful and = where
not.

Now, to the differences:

- DYMO cannot be end-to-end secured. Messages are changed in transit
(and not just hop-limit or the metric), but rather addresses can be
removed from RERRs and RREQs. There is also no provision to allow
external mechanisms to add additional reasons to reject messages as
invalid.
- DYMO uses the originator address in an address block, LOADng in = the
message header. The sequence number is a TLV value in DYMO, and = LOADng
uses the message sequence number. DYMO requires the originator = address
to be the first one in the address block, the destination must be = the
second one. LOADng uses a TLV to determine the target address.
- DYMO can advertise multiple addresses in an RERR; they can be
removed in transit of the message.
- DYMO allows intermediate routers to reply (as an option). That = makes
end-to-end security difficult. In the core DYMO, there is a
destination sequence number that may be contained in RREQs in DYMO.
- DYMO allows for unicast RREQ, but does not specify in detail how to = use that.
- There are four timers for each route entry in DYMO, only one in = LOADng.
- LOADng can be used on other layers; DYMO is tied to IP.
- LOADng provides a bidirectionality verification using RREP_ACK, a
time-out of these, a blacklisted set and a Pending Acknowledgment = Set
to verify bidirectional links. DYMO says that other mechanisms can = be
used, but does not specify these.
- DYMO has several options for expanding ring RREQ, precursor list,
adding route information in transit, message aggregation in RFC5444
packets and reporting multiple unreachable addresses in a RERR. = LOADng
takes the approach to have a slim core of a basic mechanism that is
applicable in all MANET use cases, and companion documents with
extensions. In DYMO, it is not clearly specified what happens if = some
routers support an option, and others don't.
- LOADng uses a Metric message TLV, and it is clearly defined how to
update the metric under way. If a router in transit does not = recognize
a route metric type, it is reset to a "hop count" tlv extension type
of the Metric TLV and the value set to 0xFFFFF... (for the full TLV
length). It is specified that security mechanism must ignore the
content of the metric TLV value and that the length cannot be = changed
under way, so that end-to-end security is possible. DYMO uses an
optional "distance" field for the metric, which is not clearly
specified how it is updated. Also, since this is optional, it is
unclear if routers receiving a message and forwarding it, update the
distance field or not.
- LOADng allows for (optionally) waiting to reply with a RREP, in = case
a "better" RREQ comes a little later. In DYMO, a RREP is always sent
immediately.

There are probably more differences, but I let other chime in.

Best regards
Ulrich





Note that it's a lot more useful to have = direct differences than differences of each from AODV (especially when = both have the same difference). And it would be useful to have the = objective differences separated from the "and now why this is better" discussion - though that would be a next step.

I'm not saying I don't see any of the differences. But I certainly = haven't worked out the complete list. In trying to form my view of how = things should go forward (a view that is coming together, and when it = does, I'll argue for it) and I hope for other people as well, it would be good to know what the differences are. Regardless = of views for or against each, we should be able to objectively list the = significant differences - if we can't then something is wrong.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687



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

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

 

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

 

_______________________________________________=
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet
_______= ________________________________________
manet mailing = list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet
____________= ___________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= --Apple-Mail=_FD5153FC-8473-4BF4-8744-850F8AA671F4-- From abdussalambaryun@gmail.com Fri Nov 2 09:17:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8641911E809C for ; Fri, 2 Nov 2012 09:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GXhPEvh7K0N for ; Fri, 2 Nov 2012 09:17:20 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F39521F8CC0 for ; Fri, 2 Nov 2012 09:17:20 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4381067vcb.31 for ; Fri, 02 Nov 2012 09:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2dJDrOPlds81gY3ZxY9aWexdC8t+x6006T7c0NbIEKI=; b=h4RLr4hkmLYty0bnCZyzviAxWdYhQCKOxMEblaJ4gXeATDJ2yuQRiyZRQk7Wet6cgL UI2OZbKeexUgbrxJ23sopU3CJtkxltvs/Kf17UAsI3zcMnXtkH0bYDYSoyZDW9FzRwdA c+H+veyqbbqip8W7/uWlXBVsyYtEVuL0BsTtIgFXw5TZEE8QFv7kjEXBR1MwaUtER9c1 JZnCrzaao8l8RkI01an7EoZjjUdX0HyoSN8DajlVP64kPOtrS1ppuVBz+Go6MjRs1j3j BEnwGm3Bd1Z8qC1DSFtG73YZ9+J+se05+xOd9Y4WXJMSm26Yk9ZKqukjbWx0iCF9xCtK 7ymQ== MIME-Version: 1.0 Received: by 10.52.90.99 with SMTP id bv3mr1918390vdb.125.1351873039657; Fri, 02 Nov 2012 09:17:19 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 2 Nov 2012 09:17:19 -0700 (PDT) In-Reply-To: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> Date: Fri, 2 Nov 2012 16:17:19 +0000 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: multipart/alternative; boundary=20cf307f3bcc4f6bf904cd8578b3 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 16:17:21 -0000 --20cf307f3bcc4f6bf904cd8578b3 Content-Type: text/plain; charset=ISO-8859-1 Hi Ulrich, I think that Chris's proposal was not accepted by LOADng co-authors as I understood from following up the WG history (they don't agree to change the name of protocol). As you are one co-author do I understand that you support the Chris's proposal, AB On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg wrote: > Dear Chris, > > personally, what you propose makes sense to me. > > > Regards > Ulrich > > On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" < > Chris.Dearlove@baesystems.com> wrote: > > > Before making a proposal, I'm going to introduce a distinction here > between the DYMO and LOADng documents and protocols. > > > > I'm of the opinion that the LOADng document is a greatly superior > presentation to the DYMO document. (I'm not really interested in why that > has come about.) > > > > I think that regardless of whether one makes design decisions favouring > DYMO or LOADng where they differ - and let's not forget they overlap a lot > - it would actually be easier to modify the LOADng document to specify DYMO > than it would be to modify the DYMO document to achieve that. And in > practice I think if making decisions it is unlikely that all would favour > DYMO over LOADng. > > > > So what I think would be best for the WG is not a simply "option 1" or > even (as it may appear I'm suggesting, but I'm not) "option 2" but rather > to agree to take the LOADng document, and a list of where DYMO and LOADng > differ, and thrash out where they do, what the WG reactive protocol should > do - either as a definite choice, or as an option (but not too many options > please- and some could be separate specifications). > > > > This would not of course be LOADng, so we'd have to change the document > name. And there I suggest we have a candidate name - AODVv2. (Which is why > I have recently taken to saying DYMO when referring to that document.) > After all, the one thing we are agreed on is that the protocol being > developed is derived from AODV. > > > > The editors of this new document would have to agree that what goes in > it is WG consensus (which should follow proper technical consideration of > the issues). If they found it impossible to have other than their way to do > things, they'd have to move on. If that left no one editing it, obviously > we don't have a consensus of people prepared to do the work and option 3 > would win. > > > > So now I'm partly off the fence I've been sitting on. But only partly. I > haven't yet formed a view on e.g. should this AODVv2 have IRREPs as > standard, IRREPs as an option in the main draft, IRREPs as a separate draft > option, no IRREPs. I'd like to move on to those discussions. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > > > ******************************************************************** > > 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. > > ******************************************************************** > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf307f3bcc4f6bf904cd8578b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ulrich,
=A0
I think that=A0Chris's proposal= was not accepted by LOADng co-authors as I understood from following up th= e WG history (they don't agree to change the name of protocol). As you = are one co-author do I understand that you support the Chris's proposal= ,
AB
On Fri, Nov 2, 2012 at 2:= 41 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
Dear Chris,

personally, what you propose makes sense to me.


Regards
Ulrich

On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com= > wrote:

> Before making a proposal, I'm going to introduce a distinction her= e between the DYMO and LOADng documents and protocols.
>
> I'm of the opinion that the LOADng document is a greatly superior = presentation to the DYMO document. (I'm not really interested in why th= at has come about.)
>
> I think that regardless of whether one makes design decisions favourin= g DYMO or LOADng where they differ - and let's not forget they overlap = a lot - it would actually be easier to modify the LOADng document to specif= y DYMO than it would be to modify the DYMO document to achieve that. And in= practice I think if making decisions it is unlikely that all would favour = DYMO over LOADng.
>
> So what I think would be best for the WG is not a simply "option = 1" or even (as it may appear I'm suggesting, but =A0I'm not) &= quot;option 2" but rather to agree to take the LOADng document, and a = list of where DYMO and LOADng differ, and thrash out where they do, what th= e WG reactive protocol should do - either as a definite choice, or as an op= tion (but not too many options please- and some could be separate specifica= tions).
>
> This would not of course be LOADng, so we'd have to change the doc= ument name. And there I suggest we have a candidate name - AODVv2. (Which i= s why I have recently taken to saying DYMO when referring to that document.= ) After all, the one thing we are agreed on is that the protocol being deve= loped is derived from AODV.
>
> The editors of this new document would have to agree that what goes in= it is WG consensus (which should follow proper technical consideration of = the issues). If they found it impossible to have other than their way to do= things, they'd have to move on. If that left no one editing it, obviou= sly we don't have a consensus of people prepared to do the work and opt= ion 3 would win.
>
> So now I'm partly off the fence I've been sitting on. But only= partly. I haven't yet formed a view on e.g. should this AODVv2 have IR= REPs as standard, IRREPs as an option in the main draft, IRREPs as a separa= te draft option, no IRREPs. I'd like to move on to those discussions. >
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44= 1245 242194 | =A0Fax: +44 1245 242124
> chris.dearlove@baesys= tems.com | http= ://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
>
> ******************************************************************** > 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.
> ******************************************************************** >
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf307f3bcc4f6bf904cd8578b3-- From abdussalambaryun@gmail.com Fri Nov 2 09:24:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988D521F8CDD for ; Fri, 2 Nov 2012 09:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyGloT3xT1Ks for ; Fri, 2 Nov 2012 09:24:36 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 73CD921F8B9A for ; Fri, 2 Nov 2012 09:24:29 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4388725vcb.31 for ; Fri, 02 Nov 2012 09:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yBuxvkGgaFOLw2fHEdoYPhBIVAENXNmSUBsoZW44+6Y=; b=thAR28q6kWuq7aHXkclbVPGMgPJ+YEikYUzouehJhG09Qtf+8LXEnCBC9rqxunIr6s RYnAh+G6kHA7D8MH4e5QWkb4IlARAnAj/sloOcXc4TYSFymfDOZzw6LFW454yaf6T/kS JftXH8W813v5PxiQKRhzlMFw58Wgv+Z7dKeGK6017kMXn8QNxOYnYuFoqPJhzZDrh5cy GHFgmVQiF2vDLOFO5IViyz8HdepaKds+XrWhGUozUXqhcPlPxQy0tMcIzHS1rvVsPAP2 YDsn6OeBDiLHqvBQgngn8LNMEhslD60/w01z1Eh+yO8pkpE1DOQJGkQxuqHBvC0Uc+uT FNxQ== MIME-Version: 1.0 Received: by 10.220.8.195 with SMTP id i3mr2249362vci.44.1351873468950; Fri, 02 Nov 2012 09:24:28 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 2 Nov 2012 09:24:28 -0700 (PDT) In-Reply-To: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> Date: Fri, 2 Nov 2012 16:24:28 +0000 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=bcaec54fbbb8e5e78604cd85914f Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 16:24:37 -0000 --bcaec54fbbb8e5e78604cd85914f Content-Type: text/plain; charset=ISO-8859-1 Does All WG, support the proposal stating: Chris>This would not of course be LOADng, so we'd have to change the document name. And there I suggest we have a candidate name - AODVv2. (Which is why I have recently taken to saying DYMO when referring to that document.) After all, the one thing we are agreed on is that the protocol being developed is derived from AODV. I hope we can agree on the above suggestion to go forward, Regards AB On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg wrote: > Dear Chris, > > personally, what you propose makes sense to me. > > > Regards > Ulrich > > On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" < > Chris.Dearlove@baesystems.com> wrote: > > > Before making a proposal, I'm going to introduce a distinction here > between the DYMO and LOADng documents and protocols. > > > > I'm of the opinion that the LOADng document is a greatly superior > presentation to the DYMO document. (I'm not really interested in why that > has come about.) > > > > I think that regardless of whether one makes design decisions favouring > DYMO or LOADng where they differ - and let's not forget they overlap a lot > - it would actually be easier to modify the LOADng document to specify DYMO > than it would be to modify the DYMO document to achieve that. And in > practice I think if making decisions it is unlikely that all would favour > DYMO over LOADng. > > > > So what I think would be best for the WG is not a simply "option 1" or > even (as it may appear I'm suggesting, but I'm not) "option 2" but rather > to agree to take the LOADng document, and a list of where DYMO and LOADng > differ, and thrash out where they do, what the WG reactive protocol should > do - either as a definite choice, or as an option (but not too many options > please- and some could be separate specifications). > > > > This would not of course be LOADng, so we'd have to change the document > name. And there I suggest we have a candidate name - AODVv2. (Which is why > I have recently taken to saying DYMO when referring to that document.) > After all, the one thing we are agreed on is that the protocol being > developed is derived from AODV. > > > > The editors of this new document would have to agree that what goes in > it is WG consensus (which should follow proper technical consideration of > the issues). If they found it impossible to have other than their way to do > things, they'd have to move on. If that left no one editing it, obviously > we don't have a consensus of people prepared to do the work and option 3 > would win. > > > > So now I'm partly off the fence I've been sitting on. But only partly. I > haven't yet formed a view on e.g. should this AODVv2 have IRREPs as > standard, IRREPs as an option in the main draft, IRREPs as a separate draft > option, no IRREPs. I'd like to move on to those discussions. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > > > ******************************************************************** > > 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. > > ******************************************************************** > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --bcaec54fbbb8e5e78604cd85914f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Does All WG, support the proposal stating:
=A0
Chr= is>This would not of course be LOADng, so we'd have to change the do= cument name. And there I suggest we have a candidate name - AODVv2. (Which = is why I have recently taken to saying DYMO when referring to that document= .) After all, the one thing we are agreed on is that the protocol being dev= eloped is derived from AODV.
I hope we can agree on the above=A0suggestion to go forward,
=A0
Regards
AB

On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg <= ;ulrich@herberg.na= me> wrote:
Dear Chris,

personally, what you propose makes sense to me.


Regards
Ulrich

On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com= > wrote:

> Before making a proposal, I'm going to introduce a distinction her= e between the DYMO and LOADng documents and protocols.
>
> I'm of the opinion that the LOADng document is a greatly superior = presentation to the DYMO document. (I'm not really interested in why th= at has come about.)
>
> I think that regardless of whether one makes design decisions favourin= g DYMO or LOADng where they differ - and let's not forget they overlap = a lot - it would actually be easier to modify the LOADng document to specif= y DYMO than it would be to modify the DYMO document to achieve that. And in= practice I think if making decisions it is unlikely that all would favour = DYMO over LOADng.
>
> So what I think would be best for the WG is not a simply "option = 1" or even (as it may appear I'm suggesting, but =A0I'm not) &= quot;option 2" but rather to agree to take the LOADng document, and a = list of where DYMO and LOADng differ, and thrash out where they do, what th= e WG reactive protocol should do - either as a definite choice, or as an op= tion (but not too many options please- and some could be separate specifica= tions).
>
> This would not of course be LOADng, so we'd have to change the doc= ument name. And there I suggest we have a candidate name - AODVv2. (Which i= s why I have recently taken to saying DYMO when referring to that document.= ) After all, the one thing we are agreed on is that the protocol being deve= loped is derived from AODV.
>
> The editors of this new document would have to agree that what goes in= it is WG consensus (which should follow proper technical consideration of = the issues). If they found it impossible to have other than their way to do= things, they'd have to move on. If that left no one editing it, obviou= sly we don't have a consensus of people prepared to do the work and opt= ion 3 would win.
>
> So now I'm partly off the fence I've been sitting on. But only= partly. I haven't yet formed a view on e.g. should this AODVv2 have IR= REPs as standard, IRREPs as an option in the main draft, IRREPs as a separa= te draft option, no IRREPs. I'd like to move on to those discussions. >
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44= 1245 242194 | =A0Fax: +44 1245 242124
> chris.dearlove@baesys= tems.com | http= ://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
>
> ******************************************************************** > 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.
> ******************************************************************** >
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--bcaec54fbbb8e5e78604cd85914f-- From ulrich@herberg.name Fri Nov 2 09:28:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B301F0C44 for ; Fri, 2 Nov 2012 09:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lb0+A4mUR5RZ for ; Fri, 2 Nov 2012 09:28:17 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0852D21F87EA for ; Fri, 2 Nov 2012 09:28:16 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4436755vbb.31 for ; Fri, 02 Nov 2012 09:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OOK8mPnjI8rO8zM/mm/Q+w0S/hF2/TvTvfzP5Dxka7s=; b=co2EnMwBHyuY9Z+uBnm1gx5KQDCtwY3XbvXgu38NIFefWxjTwYaLz62PJR2IzAVVIi Hfsc7r7d5o91C0LnTRzWC7TfzRCtcsP8tsanjP+ectZyk/IKjXcu6u441e2gTizw0RES OL0O1ByKrQRNwj2M46i2aAB9qOk+FPOWB76Ao= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=OOK8mPnjI8rO8zM/mm/Q+w0S/hF2/TvTvfzP5Dxka7s=; b=dBemwBUjAnJnu7JzMkJROSqMk1UrrCWenVCNTfyA7DHR62ypMnoXn4+S8Hpi8hrgD3 rPVGUTOfkfgIi841sL3PwVaiV5eJbaJdN7603QjUDnzLxv79L/insGRYWVigF9XLry4P BuY4Mj6564CDY2UXHt/8ICg7t/11eQRc6f6ZGoBkYC87OXkc96vPhZohneQix4Y2mWTU 7zR08734Q4I6eWTf1G5WnouL0l8DVrYhp51Xnxr+uVQgYAfOijrl5FlQRbffdLW4ujKZ dY3MHB3N7ko+zJmw7L7eKyU3oe1PlROsGiiw0zubT2Drudaf5IKLsw+SjkbsDmJm7IP8 pBoQ== MIME-Version: 1.0 Received: by 10.58.187.234 with SMTP id fv10mr2410478vec.8.1351873696252; Fri, 02 Nov 2012 09:28:16 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Fri, 2 Nov 2012 09:28:16 -0700 (PDT) In-Reply-To: <4FC8B1E4-6747-4C36-A7A3-5991F326EF95@gmail.com> References: <12708D7E-C548-4858-8144-6F04D2750E02@jiaziyi.com> <4F9C6208-78B8-41B1-81D2-C7DAAE9D780D@jiaziyi.com> <4FC8B1E4-6747-4C36-A7A3-5991F326EF95@gmail.com> Date: Fri, 2 Nov 2012 09:28:16 -0700 Message-ID: From: Ulrich Herberg To: Christopher Dearlove Content-Type: multipart/alternative; boundary=047d7b6d91107243ba04cd859fe8 X-Gm-Message-State: ALoCoQnyy0brFZxr/ajk9n2pS97hvAF9twhOysNxMBcLhgF4O520dCDiLZl8N/nKmSnkyWa7cho0 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Thomas Heide Clausen\(thomas@thomasclausen.org\)" Subject: Re: [manet] Reactive routing protocols, what are the differences? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 16:28:20 -0000 --047d7b6d91107243ba04cd859fe8 Content-Type: text/plain; charset=ISO-8859-1 Chris, I agree with you that this is an issue the WG has to work on. For now, I don't have answer to that, but I would like to discuss that with you and other interested people in Atlanta and on the list. Best Ulrich On Fri, Nov 2, 2012 at 8:51 AM, Christopher Dearlove < christopher.dearlove@googlemail.com> wrote: > But that still leaves the problem that with just end to end security, the > RREP path is not reported in any message and hence is not protected, and my > A - B - X - C - D example. > > -- > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) > > On 2 Nov 2012, at 15:00, Ulrich Herberg wrote: > > I am glad that we finally have some technical discussions... > > I agree that it is more difficult to provide end-to-end security in a > reactive protocol than in a proactive link-state. The idea in LOADng is > that we know exactly the fields that are mutable, and we know that the > length will not change nor the position of any of the fields (but > potentially the value of the metrics tlv). So it is relatively easy to just > zero out the Metric TLV value field. But I admit it's less straight forward > than in OLSRv2. > > Ulrich > > On Nov 2, 2012, at 7:01, "Dearlove, Christopher (UK)" < > Chris.Dearlove@baesystems.com> wrote: > > Yes, of course there can be malicious routers with link state protocols. > I've even helped implement one. But everything used is a link, and all > links are carried in messages/packets, and if all messages/packets are > authenticated, then all links are authenticated, and hence no malicious > routers are included.**** > > ** ** > > But the RREQ/RREP process (at its simplest) uses information that is not > included in any message.**** > > ** ** > > Going back to OLSRv2, yes, all routers will have to agree on a process. > But that's another discussion that I won't get into right now.**** > > ** ** > > -- **** > > Christopher Dearlove**** > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124**** > > chris.dearlove@baesystems.com | > http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687**** > > ** ** > > *From:* Teco Boot [ mailto:teco@inf-net.nl] > > *Sent:* 02 November 2012 13:00 > *To:* Dearlove, Christopher (UK) > *Cc:* Jiazi YI; manet@ietf.org; Thomas Heide Clausen ( > thomas@thomasclausen.org) > *Subject:* Re: [manet] Reactive routing protocols, what are the > differences?**** > > ** ** > > ** ** > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.** > Keep this in mind if you answer this message. > Please see this processon how to deal with suspicious emails. > ***** > > ** ** > > Op 2 nov. 2012, om 13:32 heeft Dearlove, Christopher (UK) het volgende > geschreven:**** > > > > **** > > I understand the basics. And I agree I can't see (except my bracketed > aside) how to do it without a mutable field. But having that mutable field > reduces the value of the argument against DYMO from "DYMO is mutable, > LOADng is not" to "DYMO is (uncontrolled?) mutable, LOADng is managed > mutable". I'm not convinced by the argument about having to mutate metric > type. If you can't rely on it being available to your network layer > protocol consistently in the one MANET, heterogeneous though it may be, I'm > not sure you have a well-put-together network. You could always make the > metrioc increment when unknown the maximum such value.**** > > **** > > But there is, as another post raised, the larger question of what end to > end message authentication buys you. If in a route A-B-X-C-D, where X is a > bad guy, if X relays all RREQs and RREPs flawlessly, but throws all data > packets on the floor, X has done his job, and without needing to forge > anything. You also need B and/or C to authenticate X. Lower layer? (in > which case why can't that do the whole job?). **** > > There could be 2nd order nodes: hosts. Or the routing protocol security > mechanism is implemented in the routing deamon, which is very similar to > the first.**** > > > > **** > > RREP-ACK? Accumulating signature? Something else?**** > > **** > > (Note that a link state protocol gets the B-X and X-C done. Those are, > after all, links.)**** > > There can be malicious routers with link state protocols too. **** > > Also, there is a requirement that all routers share the same policy on > what to do with failed authentication, and result of checking must be the > same on all nodes. Not easy to deploy. And missing in olsrv2 core protocol. > **** > > ** ** > > Teco**** > > ** ** > > > > **** > > **** > > --**** > > Christopher Dearlove**** > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124**** > > chris.dearlove@baesystems.com | > http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687**** > > **** > > *From:* Jiazi YI [ mailto:yi.jiazi@gmail.com > ] *On Behalf Of *Jiazi YI > *Sent:* 02 November 2012 12:13 > *To:* Dearlove, Christopher (UK) > *Cc:* Ulrich Herberg; manet@ietf.org; Thomas Heide > Clausen ( thomas@thomasclausen.org) > *Subject:* Re: [manet] Reactive routing protocols, what are the > differences?**** > > **** > > **** > > **** WARNING ******** > > *This message originates from outside our organisation, either from an > external partner or the internet.** > Keep this in mind if you answer this message. > Please see this process > on how to deal with suspicious emails.***** > > Hi,**** > > > > > **** > > The reason that LOADng needs those fields mutable is to support different > metrics other than hop-count, even routers using different metrics in the > same routing domain can at least find a path. **** > > > > > **** > > To support different metric types, a metric-type tlv and a route-metric > tlv are needed. The route-metric tlv has to be mutable because it needs to > be updated at each hop. **** > > Having metric-type tlv mutable can make supporting different metrics in > the same network possible. **** > > > > > **** > > It's common that in a heterogenous network, there are various transmission > medias (802.11, 802.15.4, cable, PLC...), therefore possible different > metrics.**** > > In LOADng, if a router A (with metric-A) gets an RREQ message that it > doesn't understand (say, metric-B), router A will change the metric-type to > HOP_COUNT, and forward the message (the hop-count field is always used). > For the destination of RREQ, it will first consider the metrics that it > understands, and then HOP_COUNT. Of course, this will result in "degrading" > to HOP_COUNT for certain routes, but at least we can get a usable route. * > *** > > > > > **** > > I'm just introducing the design of LOADng, and would appreciate any good > idea on this issue. **** > > > > > **** > > best**** > > > > > **** > > Jiazi**** > > **** > > **** > > **** > > On Nov 2, 2012, at 12:42 PM, "Dearlove, Christopher (UK)" < > Chris.Dearlove@baesystems.com> wrote:**** > > > > > **** > > Having anything other than hop limit and hop count mutable is not the > security mechanism suggested in 6622/5444.**** > > **** > > I'm of the view that the current approach of securing NHDP, securing > OLSRv2 etc. is not where things should ideally be, that the ideal place is > at the 5444 multiplexer wherever possible. If doing hop by hop security, > then that is the place, as it's where packets live. But if we could do it > once for all message types, then that's a major gain.**** > > **** > > Now as soon as LOADng has anything else mutable, that doesn't help that. > OK, it's better than nothing, but those fields are buried in TLVs (using > 5444) and messy.**** > > **** > > I'm at a disadvantage, I haven't studied why LOADng needs those fields > (other than hop count) mutable - or if it really does. But it reduces > "here's a clear advantage over DYMO" to "here's a more partial advantage > over DYMO". And I think Ulrich's summary could be edited to better present > this.**** > > **** > > So if we adopted my separate proposal, this would be on the menu: why are > those fields mutable? Do they have to be? Can we find an alternative? > (Unfortunately, I can see why probably not. But it's still a question.)*** > * > > **** > > [Actually I can see an alternative, which is a much more limited metric, > which takes small integer values, and we increase hop count not by one but > by this metric, limiting paths to maximum 255 metric. We could still get > hop count from hop limit if we knew how it started - e.g. in a non-mutable > TLV. But I strongly doubt this is good enough.]**** > > **** > > --**** > > Christopher Dearlove**** > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124**** > > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687**** > > **** > > *From:* Jiazi YI [mailto:yi.jiazi@gmail.com] *On Behalf Of *Jiazi YI > *Sent:* 02 November 2012 10:54 > *To:* Dearlove, Christopher (UK) > *Cc:* Ulrich Herberg; manet@ietf.org; Thomas Heide Clausen ( > thomas@thomasclausen.org) > *Subject:* Re: [manet] Reactive routing protocols, what are the > differences?**** > > **** > > **** > > **** WARNING ******** > > *This message originates from outside our organisation, either from an > external partner or the internet.** > Keep this in mind if you answer this message. > Please see this process > on how to deal with suspicious emails.***** > > Hi Chris, **** > > > > > > **** > > I think Ulrich is in deep sleep at the moment, so please allow me to have > some words on this. **** > > > > > > **** > > For reactive protocols, updating the route information (hop-count, metric) > is inevitable. In the specification of DYMO, the messages can be changed > relatively arbitrarily, including removing addresses from the messages. The > intermediate RREP also makes end-to-end security impossible. **** > > > > > > **** > > LOADng clearly defines which fields in the routing messages can't be > changed, and which fields are mutable. For example, for RREQ:**** > > > > > > **** > > The following fields of an RREQ message are immutable, i.e., they MUST > NOT be changed during processing or forwarding of the message: > RREQ.addr-length, RREQ.seq-num, RREQ.originator, and RREQ.destination.**** > > The following fields of an RREQ message are mutable, i.e., they will be > changed by intermediate routers during processing or forwarding, as > specified in *Section 12.2* and *Section 12.3*: RREQ.metric-type, > RREQ.route-metric, and RREQ.hop-count.**** > > Any additional field that is added to the message by an extension to this > protocol, e.g., by way of TLVs, MUST be considered immutable, unless the > extension specifically defines the field as mutable.**** > > > > > > **** > > This allows the protocol to secure the messages by zeroing the mutable > fields. **** > > > > > > **** > > best**** > > > > > > **** > > Jiazi **** > > > > > > **** > > (sorry to Chris if you received multiple copy of this message. I fixed one > typo though :) My previous one was bounced by manet mailing list because of > not using the right sender address)**** > > **** > > **** > > On Nov 2, 2012, at 11:22 AM, "Dearlove, Christopher (UK)" < > Chris.Dearlove@baesystems.com> wrote:**** > > > > > > **** > > There is, superficially at least, an apparent contradiction between your > points: > > - DYMO cannot be end-to-end secured. Messages are changed in transit > (and not just hop-limit or the metric), but rather addresses can be > removed from RERRs and RREQs. > > which implicitly suggests LOADng does not do this > > and > > - LOADng uses a Metric message TLV, and it is clearly defined how to > update the metric under way. > > Could you expand on this please? > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Ulrich Herberg [ mailto:ulrich@herberg.name > ] > Sent: 01 November 2012 22:02 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.org) > Subject: Re: [manet] Reactive routing protocols, what are the differences? > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Hi Chris, > > you have seen my review on DYMO. I will try to answer to your > question, and focus on the technical differences, not presentation. > > > On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK) > wrote: > > > > **** > > The obviously best people to answer this should be document authors, but > anyone else may have useful additions and comments. Ideally the different > document authors could agree a list. (If they differ in that one has X and > the other doesn't, but one wants to say "we plan to add/remove X" then X > should be listed as a difference with that caveat, in at least my ideal > world.) > > If we set aside, for the moment (though these things matter): > - The presentational quality of the documents, > - Any issues of 5444 compliance and other formatting issues, > - Issues of internal data organisation, > - Minor details such as possible different timeout parameters etc. > then what are the technical (and I stress that word) differences between > DYMO and LOADng? (I'm withholding the term AODVv2 for reasons I may come > back to.)**** > > > > First, let's see what is common. Both are reactive protocols, using > RREQ, RREP and RERR. So if someone claims that DYMO performs great and > LOADng badly in the same scenario, I cannot understand that. MANET has > understood the scenarios where reactive protocols are useful and where > not. > > Now, to the differences: > > - DYMO cannot be end-to-end secured. Messages are changed in transit > (and not just hop-limit or the metric), but rather addresses can be > removed from RERRs and RREQs. There is also no provision to allow > external mechanisms to add additional reasons to reject messages as > invalid. > - DYMO uses the originator address in an address block, LOADng in the > message header. The sequence number is a TLV value in DYMO, and LOADng > uses the message sequence number. DYMO requires the originator address > to be the first one in the address block, the destination must be the > second one. LOADng uses a TLV to determine the target address. > - DYMO can advertise multiple addresses in an RERR; they can be > removed in transit of the message. > - DYMO allows intermediate routers to reply (as an option). That makes > end-to-end security difficult. In the core DYMO, there is a > destination sequence number that may be contained in RREQs in DYMO. > - DYMO allows for unicast RREQ, but does not specify in detail how to use > that. > - There are four timers for each route entry in DYMO, only one in LOADng. > - LOADng can be used on other layers; DYMO is tied to IP. > - LOADng provides a bidirectionality verification using RREP_ACK, a > time-out of these, a blacklisted set and a Pending Acknowledgment Set > to verify bidirectional links. DYMO says that other mechanisms can be > used, but does not specify these. > - DYMO has several options for expanding ring RREQ, precursor list, > adding route information in transit, message aggregation in RFC5444 > packets and reporting multiple unreachable addresses in a RERR. LOADng > takes the approach to have a slim core of a basic mechanism that is > applicable in all MANET use cases, and companion documents with > extensions. In DYMO, it is not clearly specified what happens if some > routers support an option, and others don't. > - LOADng uses a Metric message TLV, and it is clearly defined how to > update the metric under way. If a router in transit does not recognize > a route metric type, it is reset to a "hop count" tlv extension type > of the Metric TLV and the value set to 0xFFFFF... (for the full TLV > length). It is specified that security mechanism must ignore the > content of the metric TLV value and that the length cannot be changed > under way, so that end-to-end security is possible. DYMO uses an > optional "distance" field for the metric, which is not clearly > specified how it is updated. Also, since this is optional, it is > unclear if routers receiving a message and forwarding it, update the > distance field or not. > - LOADng allows for (optionally) waiting to reply with a RREP, in case > a "better" RREQ comes a little later. In DYMO, a RREP is always sent > immediately. > > There are probably more differences, but I let other chime in. > > Best regards > Ulrich > > > > > > **** > > Note that it's a lot more useful to have direct differences than > differences of each from AODV (especially when both have the same > difference). And it would be useful to have the objective differences > separated from the "and now why this is better" discussion - though that > would be a next step. > > I'm not saying I don't see any of the differences. But I certainly haven't > worked out the complete list. In trying to form my view of how things > should go forward (a view that is coming together, and when it does, I'll > argue for it) and I hope for other people as well, it would be good to know > what the differences are. Regardless of views for or against each, we > should be able to objectively list the significant differences - if we > can't then something is wrong. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > ******************************************************************** > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet**** > > > _______________________________________________ > manet mailing list > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet**** > > **** > > _______________________________________________ > manet mailing list > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet**** > > ** ** > > _______________________________________________ > manet mailing list > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --047d7b6d91107243ba04cd859fe8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Chris,

I agree with you that this is an issue the WG has= to work on. For now, I don't have answer to that, but I would like to = discuss that with you and other interested people in Atlanta and on the lis= t.

Best
Ulrich


On Fri, Nov 2, 2012 at 8:51 AM, Christopher Dearlove <christopher.dearlove@googlemail.com> wrote:
But that still= leaves the problem that with just end to end security, the RREP path is no= t reported in any message and hence is not protected, and my A - B - X - C = - D example.

--=A0
Christopher Dearlove

On 2 Nov 2012, at 15:00= , Ulrich Herberg <ulrich@herberg.name> wrote:

=
I am glad that we finally have some technical discussions...

I agree that it is more difficult to provide end-to-en= d security in a reactive protocol than in a proactive link-state. The idea = in LOADng is that we know exactly the fields that are mutable, and we know = that the length will not change nor the position of any of the fields (but = potentially the value of the metrics tlv). So it is relatively easy to just= zero out the Metric TLV value field. But I admit it's less straight fo= rward than in OLSRv2.

Ulrich

On Nov 2, 2012, at 7:01, "Dearlove, = Christopher (UK)" <Chris.Dearlove@baesystems.com> wrote:

Yes, of course there can = be malicious routers with link state protocols. I've even helped implem= ent one. But everything used is a link, and all links are carried in messages/packets, and if all messages/packets are authenticated, then a= ll links are authenticated, and hence no malicious routers are included.=

=A0<= /p>

But the RREQ/RREP process= (at its simplest) uses information that is not included in any message.=

=A0<= /p>

Going back to OLSRv2, yes= , all routers will have to agree on a process. But that's another discu= ssion that I won't get into right now.

=A0<= /p>

--

Christopher Dearlove

Senior Principal Engineer= , Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124=

chris.dearlove@baesystems.com | http://www.baesystems.com
BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

=A0<= /p>

From: Teco Boot [mailto= :teco@inf-net.nl]
Sent: 02 November 2012 13:00
To: Dearlove, Christopher (UK)
Cc: Jiazi YI; manet@ietf.org; T= homas Heide Clausen (t= homas@thomasclausen.org)
Subject: Re: [manet] Reactive routing protocols, what are the differ= ences?

=A0

=A0

*** WARNING ***<= /b>

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

=A0

Op 2 nov. 2012, om 13:32 heeft Dearlove, Christopher= (UK) het volgende geschreven:



I understand the basics. = And I agree I can't see (except my bracketed aside) how to do it withou= t a mutable field. But having that mutable field reduces the value of the argument against DYMO from "DYMO is mutable, LOADng is n= ot" to "DYMO is (uncontrolled?) mutable, LOADng is managed mutabl= e". I'm not convinced by the argument about having to mutate metri= c type. If you can't rely on it being available to your network layer protocol consistently in the one MANET, heterogeneous though= it may be, I'm not sure you have a well-put-together network. You coul= d always make the metrioc increment when unknown the maximum such value.

=A0<= /p>

But there is, as another = post raised, the larger question of what end to end message authentication = buys you. If in a route A-B-X-C-D, where X is a bad guy, if X relays all RREQs and RREPs flawlessly, but throws all data packets on= the floor, X has done his job, and without needing to forge anything. You = also need B and/or C to authenticate X. Lower layer? (in which case why can= 't that do the whole job?).

There could be 2nd order nodes: hosts. Or the routin= g protocol security mechanism is implemented in the routing deamon, which i= s very similar to the first.



RREP-ACK? Accumulating si= gnature? Something else?

=A0<= /p>

(Note that a link state p= rotocol gets the B-X and X-C done. Those are, after all, links.)<= /u>

There can be malicious routers with link state proto= cols too.=A0

Also, there is a requirement that all routers share = the same policy on what to do with failed authentication, and result of che= cking must be the same on all nodes. Not easy to deploy. And missing in ols= rv2 core protocol.

=A0

Teco

=A0



=A0<= /p>

--

Christopher Dearlove

Senior Principal Engineer= , Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124=

chris.dearlove@baesystems.com=A0|= =A0http://www.baesyst= ems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

=A0<= /p>

From:= =A0Jiaz= i YI [mailto:yi.jiazi@gmail.com= ]=A0On Behalf Of=A0Jiazi YI
Sent:=A002 November 2012 12:13
To:=A0Dearlove, Christopher (UK)
Cc:=A0Ulrich Herberg;=A0manet@ietf.org; Thomas Heide Clausen (thomas@thomasclausen.org)
Subject:=A0Re: [manet] Reactive routing protocols, what= are the differences?

=A0

=A0

*** WARNING ***<= /u>

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see=A0this process=A0on how to deal with suspicious emails= .

Hi,=




The reason that LOADng needs th= ose fields mutable is to support different metrics other than hop-count, ev= en routers using different metrics in the same routing domain can at least find a path.=A0




To support different metric typ= es, a metric-type tlv and a route-metric tlv are needed. The route-metric t= lv has to be mutable because it needs to be updated at each hop.=A0=

Having metric-type tlv mutable = can make supporting different metrics in the same network possible.=A0




It's common that in a heter= ogenous network, there are various transmission medias (802.11, 802.15.4, c= able, PLC...), therefore possible different metrics.

In LOADng, if a router A (with = metric-A) gets an RREQ message that it doesn't understand (say, metric-= B), router A will change the metric-type to HOP_COUNT, and forward the message (the hop-count field= is always used). For the destination of RREQ, it will first consider the m= etrics that it understands, and then HOP_COUNT. Of course, this will result= in "degrading" to HOP_COUNT for certain routes, but at least we can get a usable route.=A0




I'm just introducing the de= sign of LOADng, and would appreciate any good idea on this issue.=A0=




best




Jiazi

=A0=

=A0

=A0

On Nov 2, 2012, at 12:42 PM, "Dearlove, Christo= pher (UK)" <Chris.Dearlove@baesystems.com> wrote:




Having anything other tha= n hop limit and hop count mutable is not the security mechanism suggested i= n 6622/5444.

=A0<= /p>

I'm of the view that = the current approach of securing NHDP, securing OLSRv2 etc. is not where th= ings should ideally be, that the ideal place is at the 5444 multiplexer wherever possible. If doing hop by hop security, then that is = the place, as it's where packets live. But if we could do it once for a= ll message types, then that's a major gain.

=A0<= /p>

Now as soon as LOADng has= anything else mutable, that doesn't help that. OK, it's better tha= n nothing, but those fields are buried in TLVs (using 5444) and messy.

=A0<= /p>

I'm at a disadvantage= , I haven't studied why LOADng needs those fields (other than hop count= ) mutable - or if it really does. But it reduces "here's a clear advantage over DYMO" to "here's a more partial advantage ove= r DYMO". And I think Ulrich's summary could be edited to better pr= esent this.

=A0<= /p>

So if we adopted my separ= ate proposal, this would be on the menu: why are those fields mutable? Do t= hey have to be? Can we find an alternative? (Unfortunately, I can see why probably not. But it's still a question.)<= u>

=A0<= /p>

[Actually I can see an al= ternative, which is a much more limited metric, which takes small integer v= alues, and we increase hop count not by one but by this metric, limiting paths to maximum 255 metric. We could still get hop count= from hop limit if we knew how it started - e.g. in a non-mutable TLV. But = I strongly doubt this is good enough.]

=A0<= /p>

--

Christopher Dearlove

Senior Principal Engineer= , Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124=

chris.dearlove@baesystems.com=A0|= =A0http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

=A0<= /p>

From:= =A0Jiaz= i YI [mailto:yi.jiazi@gm= ail.com]=A0On Behalf Of=A0Jiazi= YI
Sent:=A002 November 2012 10:54
To:=A0Dearlove, Christopher (UK)
Cc:=A0Ulrich Herberg;=A0manet@ietf.o= rg; Thomas Heide Clausen (thomas@thomasclausen.o= rg)
Subject:=A0Re: [manet] Reactive routing protocols, what= are the differences?

=A0

=A0

*** WARNING ***<= /u>

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see=A0this process=A0on how to deal with suspicious= emails.

Hi Chris,=A0





I think Ulrich is in deep sleep= at the moment, so please allow me to have some words on this.=A0





For reactive protocols, updatin= g the route information (hop-count, metric) is inevitable. In the specifica= tion of DYMO, the messages can be changed relatively arbitrarily, including removing addresses from the m= essages. The intermediate RREP also makes end-to-end security impossible.= =A0





LOADng clearly defines which fi= elds in the routing messages can't be changed, and which fields are mut= able. For example, for RREQ:





The = following fields of an RREQ message are immutable, i.e., they MUST NOT be c= hanged during processing or forwarding of the message: RREQ.addr-length, RR= EQ.seq-num, RREQ.originator, and RREQ.destination.

The = following fields of an RREQ message are mutable, i.e., they will be changed= by intermediate routers during processing or forwarding, as specified in= =A0Section=A012.2<= /span>=A0and=A0Section=A012.3: RREQ.metric-type, RREQ.route-metric, and RREQ.hop-count.<= /u>

Any = additional field that is added to the message by an extension to this proto= col, e.g., by way of TLVs, MUST be considered immutable, unless the extensi= on specifically defines the field as mutable.





This allows the protocol to sec= ure the messages by zeroing the mutable fields.=A0<= /u>





best





Jiazi=A0





(sorry to Chris if you received= multiple copy of this message. I fixed one typo though :) My previous one = was bounced by manet mailing list because of not using the right sender address)=

=A0

=A0

On Nov 2, 2012, at 11:22 AM, "Dearlove, Christo= pher (UK)" <Chris.Dearlove@baesystems.com> wrote:





There is, superficially at least, an apparent contra= diction between your points:

- DYMO cannot be end-to-end secured. Messages are changed in transit
(and not just hop-limit or the metric), but rather addresses can be
removed from RERRs and RREQs.

which implicitly suggests LOADng does not do this

and=A0

- LOADng uses a Metric message TLV, and it is clearly defined how to
update the metric under way.

Could you expand on this please?

--=A0
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0| =A0Fax: +44 1245 242124
chris.dearlove@baesystems.com=A0|=A0= http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Ulrich Herberg [mailto:ulr= ich@herberg.name]=A0
Sent: 01 November 2012 22:02
To: Dearlove, Christopher (UK)
Cc:=A0manet@ietf.org; Thomas Heide Clausen (<= a href=3D"mailto:thomas@thomasclausen.org" target=3D"_blank">thomas@thomasclausen.org)
Subject: Re: [manet] Reactive routing protocols, what are the differences?<= br>
----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hi Chris,

you have seen my review on DYMO. I will try to answer to your
question, and focus on the technical differences, not presentation.


On Thu, Nov 1, 2012 at 9:22 AM, Dearlove, Christopher (UK)
<Chris.Dearlove@baesystems.com> wrote= :



The obviously best people to answer this should be d= ocument authors, but anyone else may have useful additions and comments. Id= eally the different document authors could agree a list. (If they differ in= that one has X and the other doesn't, but one wants to say "we plan to add/remove X" then X should be = listed as a difference with that caveat, in at least my ideal world.)

If we set aside, for the moment (though these things matter):
- The presentational quality of the documents,
- Any issues of 5444 compliance and other formatting issues,
- Issues of internal data organisation,
- Minor details such as possible different timeout parameters etc.
then what are the technical (and I stress that word) differences between DY= MO and LOADng? (I'm withholding the term AODVv2 for reasons I may come = back to.)



First, let's see what is common. Both are reactive protocols, using
RREQ, RREP and RERR. So if someone claims that DYMO performs great and
LOADng badly in the same scenario, I cannot understand that. MANET has
understood the scenarios where reactive protocols are useful and where
not.

Now, to the differences:

- DYMO cannot be end-to-end secured. Messages are changed in transit
(and not just hop-limit or the metric), but rather addresses can be
removed from RERRs and RREQs. There is also no provision to allow
external mechanisms to add additional reasons to reject messages as
invalid.
- DYMO uses the originator address in an address block, LOADng in the
message header. The sequence number is a TLV value in DYMO, and LOADng
uses the message sequence number. DYMO requires the originator address
to be the first one in the address block, the destination must be the
second one. LOADng uses a TLV to determine the target address.
- DYMO can advertise multiple addresses in an RERR; they can be
removed in transit of the message.
- DYMO allows intermediate routers to reply (as an option). That makes
end-to-end security difficult. In the core DYMO, there is a
destination sequence number that may be contained in RREQs in DYMO.
- DYMO allows for unicast RREQ, but does not specify in detail how to use t= hat.
- There are four timers for each route entry in DYMO, only one in LOADng. - LOADng can be used on other layers; DYMO is tied to IP.
- LOADng provides a bidirectionality verification using RREP_ACK, a
time-out of these, a blacklisted set and a Pending Acknowledgment Set
to verify bidirectional links. DYMO says that other mechanisms can be
used, but does not specify these.
- DYMO has several options for expanding ring RREQ, precursor list,
adding route information in transit, message aggregation in RFC5444
packets and reporting multiple unreachable addresses in a RERR. LOADng
takes the approach to have a slim core of a basic mechanism that is
applicable in all MANET use cases, and companion documents with
extensions. In DYMO, it is not clearly specified what happens if some
routers support an option, and others don't.
- LOADng uses a Metric message TLV, and it is clearly defined how to
update the metric under way. If a router in transit does not recognize
a route metric type, it is reset to a "hop count" tlv extension t= ype
of the Metric TLV and the value set to 0xFFFFF... (for the full TLV
length). It is specified that security mechanism must ignore the
content of the metric TLV value and that the length cannot be changed
under way, so that end-to-end security is possible. DYMO uses an
optional "distance" field for the metric, which is not clearly specified how it is updated. Also, since this is optional, it is
unclear if routers receiving a message and forwarding it, update the
distance field or not.
- LOADng allows for (optionally) waiting to reply with a RREP, in case
a "better" RREQ comes a little later. In DYMO, a RREP is always s= ent
immediately.

There are probably more differences, but I let other chime in.

Best regards
Ulrich





Note that it's a lot more useful to have direct = differences than differences of each from AODV (especially when both have t= he same difference). And it would be useful to have the objective differenc= es separated from the "and now why this is better" discussion - though that would be a next step.

I'm not saying I don't see any of the differences. But I certainly = haven't worked out the complete list. In trying to form my view of how = things should go forward (a view that is coming together, and when it does,= I'll argue for it) and I hope for other people as well, it would be good to know what the differences are. Regardless of = views for or against each, we should be able to objectively list the signif= icant differences - if we can't then something is wrong.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 | =A0Fax: +44 1245 242124
chris.dearlove@baesystems.com=A0|=A0= http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687



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

_______________________________________________
manet mailing list
manet@ietf.org
<= /a>https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
<= /a>https://www.ietf.org/mailman/listinfo/manet

=A0

_________________________________________= ______
manet mailing list
manet@ietf.org
<= /a>https://www.ietf.org/mailman/listinfo/manet

=A0

___________________= ____________________________
manet mailing list
<= span>manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
= manet mailing list
manet@ietf.org
https://www.ietf.org/ma= ilman/listinfo/manet

--047d7b6d91107243ba04cd859fe8-- From jvasseur@cisco.com Fri Nov 2 09:30:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0187711E80B8 for ; Fri, 2 Nov 2012 09:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.305 X-Spam-Level: X-Spam-Status: No, score=-10.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLJxEPMJxJup for ; Fri, 2 Nov 2012 09:30:51 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA8711E80D9 for ; Fri, 2 Nov 2012 09:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3742; q=dns/txt; s=iport; t=1351873851; x=1353083451; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NOB034vydR/t/PegEzzQ+JhFVexD99US1TrqD1MhP0E=; b=AZWMueyVx9bOjhvjyi1F7TjHJUvYzJrXvST6axe176MRQVp4d/ncsI7B 4Kh9yLV6mTgXIdFf0ph2CSHiSBG4KIlFEUN3r+NT0Nldhy0L4bx9O85Dp H55XRSDwUZhFQ8lRJVHhUSYwdWV+RF6q518V8BZzkkumVHgRhz/+hvMDM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALrzk1CtJV2b/2dsb2JhbABEwzWBCIIeAQEBAwEBAQEPAUIZCwULAgEIIiQnCyUCBA4FCBYEh2IGC5wFoA+MARSFRmEDiCWcLYFrgm+BWwkXHg X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208";a="138007876" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 02 Nov 2012 16:30:46 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA2GUk2N001744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 16:30:46 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 11:30:46 -0500 From: "JP Vasseur (jvasseur)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] A proposal - differentiating the document and the protocol Thread-Index: AQHNuRdo+F/e031UAkadtES7lvZaHA== Date: Fri, 2 Nov 2012 16:30:45 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204C0B9@xmb-rcd-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--62.563300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 16:30:52 -0000 On Nov 2, 2012, at 12:16 PM, Dearlove, Christopher (UK) wrote: > Before making a proposal, I'm going to introduce a distinction here betwe= en the DYMO and LOADng documents and protocols. >=20 > I'm of the opinion that the LOADng document is a greatly superior present= ation to the DYMO document. (I'm not really interested in why that has come= about.) >=20 > I think that regardless of whether one makes design decisions favouring D= YMO or LOADng where they differ - and let's not forget they overlap a lot -= it would actually be easier to modify the LOADng document to specify DYMO = than it would be to modify the DYMO document to achieve that. And in practi= ce I think if making decisions it is unlikely that all would favour DYMO ov= er LOADng. >=20 > So what I think would be best for the WG is not a simply "option 1" or ev= en (as it may appear I'm suggesting, but I'm not) "option 2" but rather to= agree to take the LOADng document, and a list of where DYMO and LOADng dif= fer, and thrash out where they do, what the WG reactive protocol should do = - either as a definite choice, or as an option (but not too many options pl= ease- and some could be separate specifications). >=20 > This would not of course be LOADng, so we'd have to change the document n= ame. And there I suggest we have a candidate name - AODVv2. (Which is why I= have recently taken to saying DYMO when referring to that document.) After= all, the one thing we are agreed on is that the protocol being developed i= s derived from AODV. JP> I would be extremely supportive of this, just do the reverse BUT we wou= ld end up with the same results: * Take the DYMO document * Change the name to AODVv2 * List where both protocol differ * Use options when required. I think that this is also what Charlie proposed. >=20 > The editors of this new document would have to agree that what goes in it= is WG consensus (which should follow proper technical consideration of the= issues). If they found it impossible to have other than their way to do th= ings, they'd have to move on. If that left no one editing it, obviously we = don't have a consensus of people prepared to do the work and option 3 would= win. >=20 > So now I'm partly off the fence I've been sitting on. But only partly. I = haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standar= d, IRREPs as an option in the main draft, IRREPs as a separate draft option= , no IRREPs. I'd like to move on to those discussions. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 >=20 > ******************************************************************** > 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. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Fri Nov 2 09:32:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449BF11E80BA for ; Fri, 2 Nov 2012 09:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.503 X-Spam-Level: X-Spam-Status: No, score=-10.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TR5xyb-A2F+A for ; Fri, 2 Nov 2012 09:32:22 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5EACD11E80B8 for ; Fri, 2 Nov 2012 09:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4305; q=dns/txt; s=iport; t=1351873942; x=1353083542; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yCnA4e50GAIKSJ6Qro2Ufrxsmd8Q2N+vvgmNlGpZGk4=; b=cfly8fuM4IjCHu7hnQ9bAxT7PwM5akQK0Nd39nWRs3ASAerGiOuVjb8s qlWMpU+yVTl5M8p9WV++GPCZT9ZwGXxvjSvYL55zSAPhC9NaL54ozev1U zTzqaqpSbCE8S4XZXg5LOElBp5H12YRFdGcL9IhPrd0taA123P+45PGeD Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAL70k1CtJV2b/2dsb2JhbABEwzWBCIIeAQEBAwEBAQEPAUIZCwULAgEIIiQnCyUCBA4FCBYEh2IGC5wEoA+MARSFRmEDpFKBa4JvgVsJFx4 X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208";a="138227524" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 02 Nov 2012 16:32:22 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA2GWLG4006162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 16:32:21 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 11:32:21 -0500 From: "JP Vasseur (jvasseur)" To: Teco Boot Thread-Topic: [manet] A proposal - differentiating the document and the protocol Thread-Index: AQHNuRehQAldmF7ZtU6krGF1ERjKag== Date: Fri, 2 Nov 2012 16:32:20 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204C109@xmb-rcd-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--68.491300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <3F52C7F9D0B1E043891C0C1B4297C830@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 16:32:23 -0000 On Nov 2, 2012, at 1:04 PM, Teco Boot wrote: > This is more or less what I suggested before, perhaps not as clearly as C= hris. I suggested to use the manet-dymo document track. JP> Same here, agree. > We don't have to, but I do not see any argument for renaming. >=20 JP> There seems to be so much sensitivity =85 renaming would help a lot the= re. > But first, let's get in a cooperative mode. I kindly ask al to cool down = a bit. Seen the energy on this list, my conclusion is that we all want a gr= eat reactive MANET protocol as proposed standard. JP> Indeed. Thanks,. JP. >=20 > Teco >=20 >=20 > Op 2 nov. 2012, om 12:16 heeft Dearlove, Christopher (UK) het volgende ge= schreven: >=20 >> Before making a proposal, I'm going to introduce a distinction here betw= een the DYMO and LOADng documents and protocols. >>=20 >> I'm of the opinion that the LOADng document is a greatly superior presen= tation to the DYMO document. (I'm not really interested in why that has com= e about.) >>=20 >> I think that regardless of whether one makes design decisions favouring = DYMO or LOADng where they differ - and let's not forget they overlap a lot = - it would actually be easier to modify the LOADng document to specify DYMO= than it would be to modify the DYMO document to achieve that. And in pract= ice I think if making decisions it is unlikely that all would favour DYMO o= ver LOADng. >>=20 >> So what I think would be best for the WG is not a simply "option 1" or e= ven (as it may appear I'm suggesting, but I'm not) "option 2" but rather t= o agree to take the LOADng document, and a list of where DYMO and LOADng di= ffer, and thrash out where they do, what the WG reactive protocol should do= - either as a definite choice, or as an option (but not too many options p= lease- and some could be separate specifications). >>=20 >> This would not of course be LOADng, so we'd have to change the document = name. And there I suggest we have a candidate name - AODVv2. (Which is why = I have recently taken to saying DYMO when referring to that document.) Afte= r all, the one thing we are agreed on is that the protocol being developed = is derived from AODV. >>=20 >> The editors of this new document would have to agree that what goes in i= t is WG consensus (which should follow proper technical consideration of th= e issues). If they found it impossible to have other than their way to do t= hings, they'd have to move on. If that left no one editing it, obviously we= don't have a consensus of people prepared to do the work and option 3 woul= d win. >>=20 >> So now I'm partly off the fence I've been sitting on. But only partly. I= haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standa= rd, IRREPs as an option in the main draft, IRREPs as a separate draft optio= n, no IRREPs. I'd like to move on to those discussions. >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >>=20 >> ******************************************************************** >> 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. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Fri Nov 2 09:33:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E3D21F860F for ; Fri, 2 Nov 2012 09:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.511 X-Spam-Level: X-Spam-Status: No, score=-10.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLq1htSuDkCb for ; Fri, 2 Nov 2012 09:33:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 499E721F85E7 for ; Fri, 2 Nov 2012 09:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6066; q=dns/txt; s=iport; t=1351874002; x=1353083602; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nEC9q0Lfo7UJuOaXiOq+0sgOyyKrCwJdoaq3UNMzV1Q=; b=hkcaPVTxyGIfDG+rYb/gRphMZL3cflRsYY5HpvLPg33o7MuB7S82aAAI nkbX/NKioxv338X1PYvZ7L5YT43mfOb6RrQtVShko2zqmNdPWGpc/U3/q N7vd2Tyo7a83UkQMmhncaKdkwC0iRElAsjPrcsBA+3SKB9uxoJTT4hth0 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAP/0k1CtJV2b/2dsb2JhbABEwzWBCIIeAQEBAwEBAQEPAUIZAwgFBwQCAQgRBAEBCwsSBycLFAkIAgQOBQgWBIdiBgubeaAOjAEUDoJpgk9hA6RSgWuCb4FbCRce X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208";a="138271584" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 02 Nov 2012 16:33:21 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA2GXLkk008543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 16:33:21 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 11:33:21 -0500 From: "JP Vasseur (jvasseur)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] A proposal - differentiating the document and the protocol Thread-Index: AQHNuRfF+F/e031UAkadtES7lvZaHA== Date: Fri, 2 Nov 2012 16:33:20 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204C13D@xmb-rcd-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--59.480700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 16:33:23 -0000 On Nov 2, 2012, at 1:11 PM, Dearlove, Christopher (UK) wrote: > As I said, I think the LOADng document will be much easier to adapt. JP> I had the opposite feeling and =85 DYMO is the MANET WG document too. >=20 > Two comments there. First, it's odd reading that document, which I'm not = an author of, as large amounts feel like I did write them. That is of cours= e because it borrows the style of OLSRv2/NHDP, in turn adopted from (but im= proved on) that on RFC 3626. >=20 > Second, is that a good style? Well, I would refer you to Barry Leiba's co= mments on OLSRv2 in the ID tracker as it goes through the IESG. It even got= a YES (not just a no objection) from him on that account. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: 02 November 2012 12:05 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org > Subject: Re: [manet] A proposal - differentiating the document and the pr= otocol >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > This is more or less what I suggested before, perhaps not as clearly as C= hris. I suggested to use the manet-dymo document track. We don't have to, b= ut I do not see any argument for renaming. >=20 > But first, let's get in a cooperative mode. I kindly ask al to cool down = a bit. Seen the energy on this list, my conclusion is that we all want a gr= eat reactive MANET protocol as proposed standard. >=20 > Teco >=20 >=20 > Op 2 nov. 2012, om 12:16 heeft Dearlove, Christopher (UK) het volgende ge= schreven: >=20 >> Before making a proposal, I'm going to introduce a distinction here betw= een the DYMO and LOADng documents and protocols. >>=20 >> I'm of the opinion that the LOADng document is a greatly superior presen= tation to the DYMO document. (I'm not really interested in why that has com= e about.) >>=20 >> I think that regardless of whether one makes design decisions favouring = DYMO or LOADng where they differ - and let's not forget they overlap a lot = - it would actually be easier to modify the LOADng document to specify DYMO= than it would be to modify the DYMO document to achieve that. And in pract= ice I think if making decisions it is unlikely that all would favour DYMO o= ver LOADng. >>=20 >> So what I think would be best for the WG is not a simply "option 1" or e= ven (as it may appear I'm suggesting, but I'm not) "option 2" but rather t= o agree to take the LOADng document, and a list of where DYMO and LOADng di= ffer, and thrash out where they do, what the WG reactive protocol should do= - either as a definite choice, or as an option (but not too many options p= lease- and some could be separate specifications). >>=20 >> This would not of course be LOADng, so we'd have to change the document = name. And there I suggest we have a candidate name - AODVv2. (Which is why = I have recently taken to saying DYMO when referring to that document.) Afte= r all, the one thing we are agreed on is that the protocol being developed = is derived from AODV. >>=20 >> The editors of this new document would have to agree that what goes in i= t is WG consensus (which should follow proper technical consideration of th= e issues). If they found it impossible to have other than their way to do t= hings, they'd have to move on. If that left no one editing it, obviously we= don't have a consensus of people prepared to do the work and option 3 woul= d win. >>=20 >> So now I'm partly off the fence I've been sitting on. But only partly. I= haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standa= rd, IRREPs as an option in the main draft, IRREPs as a separate draft optio= n, no IRREPs. I'd like to move on to those discussions. >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >>=20 >> ******************************************************************** >> 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. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Fri Nov 2 09:34:24 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB9A21F8D39 for ; Fri, 2 Nov 2012 09:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djPC8HyB5Kfc for ; Fri, 2 Nov 2012 09:34:23 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 73BC321F8D36 for ; Fri, 2 Nov 2012 09:34:23 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4399105vcb.31 for ; Fri, 02 Nov 2012 09:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3oXr+KT8whz9ywexpnQDh06GsVP+i7CBKiPaMJFI8MA=; b=ADPaChzE4FYhznld7upeOqByYjrWGxs8z7Y2AfRnkw2eobyJYqAs7+sOAdrj2h9xiU S4sn4DvKvzcmx1noSMpSB4dCYxwDcYXcpZpJqSfTEA8i3D72tenXk/PdD38ghkflH00V 6LfRCog4LdJYynHbqbJtbkzdYIzXJr16ctuSU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=3oXr+KT8whz9ywexpnQDh06GsVP+i7CBKiPaMJFI8MA=; b=QAY+PXbRtdHDsms61a0fsbd9W9untA2PHL6fBab75taJ2wmv1dYF9Tx9xvRVAqqceD TJE+2CGPr1n+QYFkTfULh00E/Yzk9ga09yf+PY04pBnliqSIcDb2sYdr50DYwppuwzuq 42FMcAGHfYMGxRPGo+Fg//lUvf4Qo5e8cx4Hb789P6yvMB3uqvVMTcaFKTQwNWTBlx9V MXwRixJfHNobrZiaUAIJAXHukHI2HEC1tnsgaNM9i1z0L9ZMmccufB3GPkRQxvYhl7P8 aaM1QQ1fJw93ce4nzXgIzusS+nGQ0rZcigRujNPglswMqYGE6VUj5NKuvPies1tZ34QM zK6A== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr2099017vdv.20.1351874062815; Fri, 02 Nov 2012 09:34:22 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Fri, 2 Nov 2012 09:34:22 -0700 (PDT) In-Reply-To: References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> Date: Fri, 2 Nov 2012 09:34:22 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=bcaec50162bd4b925304cd85b54c X-Gm-Message-State: ALoCoQnhtAgygnSLVQMAUannEyG4bS6c/pBQpvO6plmaHklPGkD444mpMNeLwWTRjnQXQMYhKvyl Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 16:34:24 -0000 --bcaec50162bd4b925304cd85b54c Content-Type: text/plain; charset=ISO-8859-1 Hi Abdussalam, there was indeed some hesitance to change the name from some of the authors (not me). I cannot speak for them here. My intuition is that if the name of the protocol is the only factor that avoids the reactive protocol from proceeding in the WG, this can be solved. As far as I can see from the discussions so far, there is a clear consensus that option 3 is not viable. Now, if we want to proceed with the reactive document, the question is from which document to start. Chris mentioned that even if we wanted the specification of 100%, it would be far quicker to start from the LOADng draft. I propose that we can start working based on the LOADng draft (possibly rename it?), look at each item that is in DYMO and consider whether and in which way it should be incorporated in the draft. Best Ulrich On Fri, Nov 2, 2012 at 9:17 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Ulrich, > > I think that Chris's proposal was not accepted by LOADng co-authors as I > understood from following up the WG history (they don't agree to change the > name of protocol). As you are one co-author do I understand that you > support the Chris's proposal, > AB > On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg wrote: > >> Dear Chris, >> >> personally, what you propose makes sense to me. >> >> >> Regards >> Ulrich >> >> On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" < >> Chris.Dearlove@baesystems.com> wrote: >> >> > Before making a proposal, I'm going to introduce a distinction here >> between the DYMO and LOADng documents and protocols. >> > >> > I'm of the opinion that the LOADng document is a greatly superior >> presentation to the DYMO document. (I'm not really interested in why that >> has come about.) >> > >> > I think that regardless of whether one makes design decisions favouring >> DYMO or LOADng where they differ - and let's not forget they overlap a lot >> - it would actually be easier to modify the LOADng document to specify DYMO >> than it would be to modify the DYMO document to achieve that. And in >> practice I think if making decisions it is unlikely that all would favour >> DYMO over LOADng. >> > >> > So what I think would be best for the WG is not a simply "option 1" or >> even (as it may appear I'm suggesting, but I'm not) "option 2" but rather >> to agree to take the LOADng document, and a list of where DYMO and LOADng >> differ, and thrash out where they do, what the WG reactive protocol should >> do - either as a definite choice, or as an option (but not too many options >> please- and some could be separate specifications). >> > >> > This would not of course be LOADng, so we'd have to change the document >> name. And there I suggest we have a candidate name - AODVv2. (Which is why >> I have recently taken to saying DYMO when referring to that document.) >> After all, the one thing we are agreed on is that the protocol being >> developed is derived from AODV. >> > >> > The editors of this new document would have to agree that what goes in >> it is WG consensus (which should follow proper technical consideration of >> the issues). If they found it impossible to have other than their way to do >> things, they'd have to move on. If that left no one editing it, obviously >> we don't have a consensus of people prepared to do the work and option 3 >> would win. >> > >> > So now I'm partly off the fence I've been sitting on. But only partly. >> I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as >> standard, IRREPs as an option in the main draft, IRREPs as a separate draft >> option, no IRREPs. I'd like to move on to those discussions. >> > >> > -- >> > Christopher Dearlove >> > Senior Principal Engineer, Communications Group >> > Communications, Networks and Image Analysis Capability >> > BAE Systems Advanced Technology Centre >> > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> > Tel: +44 1245 242194 | Fax: +44 1245 242124 >> > chris.dearlove@baesystems.com | http://www.baesystems.com >> > >> > BAE Systems (Operations) Limited >> > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> > Registered in England & Wales No: 1996687 >> > >> > >> > >> > ******************************************************************** >> > 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. >> > ******************************************************************** >> > >> > _______________________________________________ >> > manet mailing list >> > manet@ietf.org >> > https://www.ietf.org/mailman/listinfo/manet >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > --bcaec50162bd4b925304cd85b54c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Abdussalam,

=0A
there was indeed some hesitance to change= the name from some of the authors (not me). I cannot speak for them here. = My intuition is that if the name of the protocol is the only factor that av= oids the reactive protocol from proceeding in the WG, this can be solved.

As far as I can see from the discussions so far, there = is a clear consensus that option 3 is not viable. Now, if we want to procee= d with the reactive document, the question is from which document to start.= Chris mentioned that even if we wanted the specification of 100%, it would= be far quicker to start from the LOADng draft.=A0I propose that we can sta= rt working based on the LOADng draft=A0(possibly rename it?), look at each = item that is in DYMO and consider whether and in which way it should be inc= orporated in the draft.=A0

Best
Ulrich



On Fri, Nov 2, 2012 at 9:17 AM, = Abdussalam Baryun <abdussalambaryun@gmail.com> wrot= e:
Hi Ulrich,
=A0
I th= ink that=A0Chris's proposal was not accepted by LOADng co-authors as I = understood from following up the WG history (they don't agree to change= the name of protocol). As you are one co-author do I understand that you s= upport the Chris's proposal,
AB
On Fri, Nov 2, 2012 at 2:41 PM, Ulrich Herberg <ulric= h@herberg.name> wrote:
Dear Chris,

personally, what you propose makes sense to me.


Regards
Ulrich

On Nov 2, 2012, at 4:16, "Dearlove, Christopher (UK)" <Chris.Dearlove@= baesystems.com> wrote:

> Before making a proposal, I'm going to introduce a distinction her= e between the DYMO and LOADng documents and protocols.
>
> I'm of the opinion that the LOADng document is a greatly superior = presentation to the DYMO document. (I'm not really interested in why th= at has come about.)
>
> I think that regardless of whether one makes design decisions favourin= g DYMO or LOADng where they differ - and let's not forget they overlap = a lot - it would actually be easier to modify the LOADng document to specif= y DYMO than it would be to modify the DYMO document to achieve that. And in= practice I think if making decisions it is unlikely that all would favour = DYMO over LOADng.
>
> So what I think would be best for the WG is not a simply "option = 1" or even (as it may appear I'm suggesting, but =A0I'm not) &= quot;option 2" but rather to agree to take the LOADng document, and a = list of where DYMO and LOADng differ, and thrash out where they do, what th= e WG reactive protocol should do - either as a definite choice, or as an op= tion (but not too many options please- and some could be separate specifica= tions).
>
> This would not of course be LOADng, so we'd have to change the doc= ument name. And there I suggest we have a candidate name - AODVv2. (Which i= s why I have recently taken to saying DYMO when referring to that document.= ) After all, the one thing we are agreed on is that the protocol being deve= loped is derived from AODV.
>
> The editors of this new document would have to agree that what goes in= it is WG consensus (which should follow proper technical consideration of = the issues). If they found it impossible to have other than their way to do= things, they'd have to move on. If that left no one editing it, obviou= sly we don't have a consensus of people prepared to do the work and opt= ion 3 would win.
>
> So now I'm partly off the fence I've been sitting on. But only= partly. I haven't yet formed a view on e.g. should this AODVv2 have IR= REPs as standard, IRREPs as an option in the main draft, IRREPs as a separa= te draft option, no IRREPs. I'd like to move on to those discussions. >
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 | =A0Fax: +44 1245 242124
> chr= is.dearlove@baesystems.com | http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
>
> ******************************************************************** > 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.
> ******************************************************************** >
> _______________________________________________
> manet mailing list
> manet@ietf.org=
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--bcaec50162bd4b925304cd85b54c-- From ulrich@herberg.name Fri Nov 2 09:37:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2393F21F8D5D for ; Fri, 2 Nov 2012 09:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RfN8QCkQI6u for ; Fri, 2 Nov 2012 09:37:40 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B25E21F8D5A for ; Fri, 2 Nov 2012 09:37:40 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4402312vcb.31 for ; Fri, 02 Nov 2012 09:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oyh4dakjpfMsF653LyTAPZ6N30fvGYU3gTGp4wQf+Go=; b=WypitGaIdpJ1nIgcc8L0Z4Wcp522beWQeoMTzHLWqJuxuS5fOFCjLPC0tPsCkRqfP5 SttVjKEmDYGwBXVFVWAJ2e2fTlAFPiSiPgJiP+HpMfQx1+4oz2ARgftd/qhaQYqlMQK0 oInMNncK92jOSZlUCVBFoN6voYQYUZB0P3Qbw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=oyh4dakjpfMsF653LyTAPZ6N30fvGYU3gTGp4wQf+Go=; b=TcPHkj4/iz3OohTjPfeZDgnh88AemGtnrvM1DL32AZZGXcp+clvv3KCX04q7LnRoXQ J2bvZmWcADB0jYVftnYl9aY2G4eysb39Y8ikGI6yRag1nUMsG34cd/BnmsbnM3dZR/HM 8DIClJN/ijodKNLOzGCyWjHchKsWM0Ob9ajGDdNssN5DXXS+/k0RYVGY3ZfGt6t3bF+4 pJkl5kP/+94mAYYJ2Ej+3JDJukc4RtMeikMIyj38ggFmf1IMV3CfqpPDP7uUYYn1+OOM wrTc/sJX5USJWo2Lr/Dfp/PDQCrwjrDsvnX7S1ZhJsjUyvsamU2ejMtZ05sDp1p0/Q7y S/qg== MIME-Version: 1.0 Received: by 10.58.145.161 with SMTP id sv1mr2323923veb.52.1351874253852; Fri, 02 Nov 2012 09:37:33 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Fri, 2 Nov 2012 09:37:33 -0700 (PDT) In-Reply-To: References: <8548842F-F5DC-4604-A912-7B7F76A4D5E3@herberg.name> Date: Fri, 2 Nov 2012 09:37:33 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=047d7b67613cae8fe704cd85c070 X-Gm-Message-State: ALoCoQkVqqbJjP5jszBOo4g7PhQL+7BsHXn1y0q1Gd6HB4/TymexAmyVBEXmWm94J1JDvtLk5bjq Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 16:37:41 -0000 --047d7b67613cae8fe704cd85c070 Content-Type: text/plain; charset=ISO-8859-1 typo... On Fri, Nov 2, 2012 at 9:34 AM, Ulrich Herberg wrote: > [...]Chris mentioned that even if we wanted the specification of 100%, it > would be far quicker to start from the LOADng draft. [...] > "100% DYMO" --047d7b67613cae8fe704cd85c070 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable typo...

On Fri, Nov 2, 2012 at 9:34 AM, U= lrich Herberg <ulrich@herberg.name> wrote:
[...]Chris mentioned that even if we wanted the specification of 100%,= it would be far quicker to start from the LOADng draft. [...]

"100% DYMO"=A0
--047d7b67613cae8fe704cd85c070-- From jvasseur@cisco.com Fri Nov 2 09:47:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FA121F8D89 for ; Fri, 2 Nov 2012 09:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.323 X-Spam-Level: X-Spam-Status: No, score=-10.323 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qy+e7oM18jzQ for ; Fri, 2 Nov 2012 09:47:54 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 118F121F8D88 for ; Fri, 2 Nov 2012 09:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1595; q=dns/txt; s=iport; t=1351874874; x=1353084474; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XxiKas8TS4chNhoP7QP7A+LEZhKa3QPt+IQ84JeDmGg=; b=iL6T30FOHsmKhIE8tsFf3z9KkDDuzoH/UtiDJ3FNoSmeGUn6iaxht/jr ed8eVJRpvg4pY9TqaUBnekuDQHcpLCLZxVqrLPqPogM8t+vrGU2ryASAs mq8r581b2MPYvFup4/8MGIne0KYxdwDe7VeETh88PAWROVSJFlacFI4Q1 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMX4k1CtJXG//2dsb2JhbABEwzWBCIIeAQEBAwEBAQEPAVsLEAIBCCIkJwslAgQOBQgah2IGC5t8oAwEjAEghTphA4glnC2Ba4JvgVwfHg X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208";a="138212518" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 02 Nov 2012 16:47:53 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA2Glrgr013331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 16:47:53 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 11:47:53 -0500 From: "JP Vasseur (jvasseur)" To: Martin Heusse Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuRnMLPVi/cSo/ES1hdb7zda62w== Date: Fri, 2 Nov 2012 16:47:52 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204C2D1@xmb-rcd-x02.cisco.com> References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> In-Reply-To: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--36.254900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4F7B94F5BFA8644FA3AFC3F87428B595@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 16:47:54 -0000 On Nov 2, 2012, at 10:01 AM, Martin Heusse wrote: >=20 > I'm standing for option 2 (LOADng). >=20 > I think it's better to agree first on a simple basic (versatile?) protoco= l before proposing extensions to it; instead of starting from a collection = of ideas that can be used or not (and we know today what are the options, t= hank to the huge amount of work done on reactive routing during the past ye= ars). Conversely, it would be certainly easier to reach a consensus on a se= t of variants but we need a good reference point, first.=20 >=20 > Moreover, reactive routing is most probably the approach that one would p= ick for a simple case. So it should be simple...=20 Yes if the use case is simple >=20 > Martin >=20 >=20 > Le 2 nov. 2012 =E0 01:58, Joydeep Tripathi a =E9crit : >=20 >> I can understand that for an LLN it may be beneficial for not maintainin= g a precursor list or having only the destination reply t o a RREQ, there c= an be (and are) other instances of MANETs where having the option of precur= sor list will come handy. This can save on control overhead, using some sto= rage space in the node. LOAD-ng, in most cases does not provide this flexib= ility to the developer to chose between options for specific deployment. So= me MANET deployment may be less harsh than others in nature. Hence, AODVv2 = having more open options than LOAD-ng, in most cases, seem beneficial to me= .=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Fri Nov 2 09:49:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F94D21F8DAC for ; Fri, 2 Nov 2012 09:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.218 X-Spam-Level: X-Spam-Status: No, score=-10.218 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1xLI0DQ88V8 for ; Fri, 2 Nov 2012 09:49:53 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 33C2521F8DAA for ; Fri, 2 Nov 2012 09:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4180; q=dns/txt; s=iport; t=1351874993; x=1353084593; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=x1GRni1P0F8nFBqqjB1Q+zjHKey4TA6B5UtV86x3fjw=; b=VP8qR5+rK+9L/i3aesV21ZwELviGrfbWKy3EaCagua4ZC9yu+U+bxxrH R17sRJxN+Db/pPhhOPOvnW5ZIOFM+WpM4GDu9oO9C3P99oYeZTYgdtZ5x iT4Tv9H68pCjo28t87W4NwR/XY37O5GrKIkq7cLI3tN6GRKgpW3gU0FwS E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFz4k1CtJXG9/2dsb2JhbABEhhe8JHqBCIIeAQEBAwEBAQEPARAROgYFBQsCAQgYAgIGIAICAiULFRACBA4FCBqHYgYLm3yNKZJjBIEgimEVBQaFCDJhA6RSgWuCb4FcCBce X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208";a="135233911" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 02 Nov 2012 16:49:52 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA2GnqF0014355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 16:49:52 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 11:49:52 -0500 From: "JP Vasseur (jvasseur)" To: Yuichi IGARASHI Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuRoTLPVi/cSo/ES1hdb7zda62w== Date: Fri, 2 Nov 2012 16:49:51 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204C304@xmb-rcd-x02.cisco.com> References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> In-Reply-To: <5093DEB4.7000907@hitachi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--48.433800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-ID: <881ED40B36F2654184ED016DD8571B0E@cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 16:49:54 -0000 RGVhciBZdWljaGksDQoNCldlIGFsbCBhZ3JlZSB0aGF0IHRoZSBkb2N1bWVudCBzaG91bGQgYmUg ZWFzeSB0byByZWFkIGFuZCBpbXBsZW1lbnQ7IGlmIGltcHJvdmVtZW50cyBtdXN0IGJlIG1hZGUg dG8gRFlNTy0yMywgYW5kIHRoZXJlIGFyZSDigKYgbGV0J3MgZ28gYWhlYWQgYW5kDQppbXByb3Zl IHRoZSBkb2N1bWVudC4gTm90aGluZyB3cm9uZyB3aXRoIHRoYXQuIFdlIHNob3VsZCBub3QgZ2V0 IG1peCB0aGUgY29tcGxleGl0eSBvZiB0aGUgZG9jdW1lbnQgYW5kIHRoZSBwcm90b2NvbC4NCg0K T24gTm92IDIsIDIwMTIsIGF0IDEwOjU0IEFNLCBZdWljaGkgSUdBUkFTSEkgd3JvdGU6DQoNCj4g SGksDQo+IA0KPiBJIGFncmVlIHdpdGggTWFydGluIGFuZCBJIHdvdWxkIHN1cHBvcnQgb3B0aW9u IDIpIGF0IHRoaXMgc3RhZ2UuDQo+IA0KPiBXZSBMT0FEbmcgY28tYXV0aG9ycyBtYWRlIGVmZm9y dHMgdG8gc2ltcGxpZnkgY29yZSBzcGVjaWZpY2F0aW9uIG9mIHRoZSByZWFjdGl2ZSBwcm90b2Nv bCBhbmQgdG8gaW1wcm92ZSB0aGUgcmVhZGFiaWxpdHkgb2YgdGhlIGRyYWZ0LiBJIHRoaW5rIHRo aXMgYXBwcm9hY2ggaXMgaW1wb3J0YW50IG5vdCBvbmx5IGZvciBhbGwgaW1wbGVtZW50b3IgdG8g c2hvcnRlbiB0aGUgZGV2ZWxvcG1lbnQgdGltZSwgYnV0IGFsc28gZm9yIGJ1c2luZXNzIG9wZXJh dG9ycyB0byBtYWtlIG11bHRpLXZlbmRvciBzeXN0ZW0gZWFzaWVyIHRvIHByb3ZpZGUuIE9mIGNv dXJzZSwgSSBhZ3JlZSB0aGF0LCBhcyBzZXZlcmFsIHBlcnNvbnMgcG9pbnRlZCBvdXQsICJ0aGlz IGRyYWZ0IiBtYXkgbGltaXQgdXNlIGNhc2UuIEJ1dCB3ZSBsZWF2ZSBzdWZmaWNpZW50IHNwYWNl IGZvciBpbXByb3ZpbmcgcGVyZm9ybWFuY2UvYWRkaW5nIGZ1bmN0aW9ucyBieSBjb21wYW5pb24g ZHJhZnRzLg0KPiANCj4gSSBhbSByZWFsbHkgY29uY2VybmVkIGFib3V0IGNvbXBsZXhpdHkvZGlm ZmljdWx0eSBvZiBndWFyYW50ZWVpbmcgb2YgaW50ZXJvcGVyYWJpbGl0eS4gSWYgdGhlIHByb3Rv Y29sIGJlY29tZXMgY29tcGxpY2F0ZWQsIHdlIG5lZWQgbXVjaCB0aW1lKG1hbnkgeWVhcnM/KSBm b3IgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0LiBJIHRoaW5rIHdlIHNob3VsZCBjb25zaWRlciBib3Ro IHRpbWUgcmVxdWlyZWQgZm9yIG1lcmdpbmcgZHJhZnRzIGFuZCBzaGFwZSBvZiBkb2N1bWVudC4N Cj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gWXVpY2hpDQo+ICgyMDEyLzExLzAyIDIzOjAxKSwgTWFy dGluIEhldXNzZSB3cm90ZToNCj4+IA0KPj4gSSdtIHN0YW5kaW5nIGZvciBvcHRpb24gMiAoTE9B RG5nKS4NCj4+IA0KPj4gSSB0aGluayBpdCdzIGJldHRlciB0byBhZ3JlZSBmaXJzdCBvbiBhIHNp bXBsZSBiYXNpYyAodmVyc2F0aWxlPykgcHJvdG9jb2wgYmVmb3JlIHByb3Bvc2luZyBleHRlbnNp b25zIHRvIGl0OyBpbnN0ZWFkIG9mIHN0YXJ0aW5nIGZyb20gYSBjb2xsZWN0aW9uIG9mIGlkZWFz IHRoYXQgY2FuIGJlIHVzZWQgb3Igbm90IChhbmQgd2Uga25vdyB0b2RheSB3aGF0IGFyZSB0aGUg b3B0aW9ucywgdGhhbmsgdG8gdGhlIGh1Z2UgYW1vdW50IG9mIHdvcmsgZG9uZSBvbiByZWFjdGl2 ZSByb3V0aW5nIGR1cmluZyB0aGUgcGFzdCB5ZWFycykuIENvbnZlcnNlbHksIGl0IHdvdWxkIGJl IGNlcnRhaW5seSBlYXNpZXIgdG8gcmVhY2ggYSBjb25zZW5zdXMgb24gYSBzZXQgb2YgdmFyaWFu dHMgYnV0IHdlIG5lZWQgYSBnb29kIHJlZmVyZW5jZSBwb2ludCwgZmlyc3QuDQo+PiANCj4+IE1v cmVvdmVyLCByZWFjdGl2ZSByb3V0aW5nIGlzIG1vc3QgcHJvYmFibHkgdGhlIGFwcHJvYWNoIHRo YXQgb25lIHdvdWxkIHBpY2sgZm9yIGEgc2ltcGxlIGNhc2UuIFNvIGl0IHNob3VsZCBiZSBzaW1w bGUuLi4NCj4+IA0KPj4gTWFydGluDQo+PiANCj4+IA0KPj4gTGUgMiBub3YuIDIwMTIgw6AgMDE6 NTgsIEpveWRlZXAgVHJpcGF0aGkgYSDDqWNyaXQgOg0KPj4gDQo+Pj4gIEkgY2FuIHVuZGVyc3Rh bmQgdGhhdCBmb3IgYW4gTExOIGl0IG1heSBiZSBiZW5lZmljaWFsIGZvciBub3QgbWFpbnRhaW5p bmcgYSBwcmVjdXJzb3IgbGlzdCBvciBoYXZpbmcgb25seSB0aGUgZGVzdGluYXRpb24gcmVwbHkg dCBvIGEgUlJFUSwgdGhlcmUgY2FuIGJlIChhbmQgYXJlKSBvdGhlciBpbnN0YW5jZXMgb2YgTUFO RVRzIHdoZXJlIGhhdmluZyB0aGUgb3B0aW9uIG9mIHByZWN1cnNvciBsaXN0IHdpbGwgY29tZSBo YW5keS4gVGhpcyBjYW4gc2F2ZSBvbiBjb250cm9sIG92ZXJoZWFkLCB1c2luZyBzb21lIHN0b3Jh Z2Ugc3BhY2UgaW4gdGhlIG5vZGUuIExPQUQtbmcsIGluIG1vc3QgY2FzZXMgZG9lcyBub3QgcHJv dmlkZSB0aGlzIGZsZXhpYmlsaXR5IHRvIHRoZSBkZXZlbG9wZXIgdG8gY2hvc2UgYmV0d2VlbiBv cHRpb25zIGZvciBzcGVjaWZpYyBkZXBsb3ltZW50LiBTb21lIE1BTkVUIGRlcGxveW1lbnQgbWF5 IGJlIGxlc3MgaGFyc2ggdGhhbiBvdGhlcnMgaW4gbmF0dXJlLiBIZW5jZSwgQU9EVnYyIGhhdmlu ZyBtb3JlIG9wZW4gb3B0aW9ucyB0aGFuIExPQUQtbmcsIGluIG1vc3QgY2FzZXMsIHNlZW0gYmVu ZWZpY2lhbCB0byBtZS4NCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+IG1hbmV0IG1haWxpbmcgbGlzdA0KPj4gbWFuZXRAaWV0Zi5vcmcN Cj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCj4+IA0KPiAN Cj4gLS0gDQo+IEhpdGFjaGksIEx0ZC4sIFlva29oYW1hIFJlc2VhcmNoIExhYm9yYXRvcnkNCj4g SUdBUkFTSEkgWXVpY2hpDQo+IE1haWzvvJogeXVpY2hpLmlnYXJhc2hpLmhiQGhpdGFjaGkuY29t DQo+IFRlbCDvvJogKzgxLSgwKTQ1LTg2MC0zMDgzDQo+IEZBWCDvvJogKzgxLSgwKTQ1LTg2MC0x NjczDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IG1hbmV0IG1haWxpbmcgbGlzdA0KPiBtYW5ldEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCg== From jvasseur@cisco.com Fri Nov 2 09:55:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0184321F8847 for ; Fri, 2 Nov 2012 09:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.202 X-Spam-Level: X-Spam-Status: No, score=-10.202 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+-MD7XcCdf1 for ; Fri, 2 Nov 2012 09:55:28 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0C021F87E4 for ; Fri, 2 Nov 2012 09:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18624; q=dns/txt; s=iport; t=1351875327; x=1353084927; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=R+4sUURKQo9v6vmLHi6XwpE2U5dn53WKQrDyW7JrqI4=; b=UHzC0+mqYxdIcjJiOR3nrxy5erJ8KGxLslVFN7Ffk0Lh2bgCBkVO2YT0 HX0bTuehNn51sOglEZc/x9Itk5k97ZTVNH30UrE5cfBjuqZkOKe5qoRBX vsdGpd3uUXv4nh0Nk7QgewBW0bNER/dEAOdO7j2ZA5mK+lTTuHMYttkSB M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJ76k1CtJXG//2dsb2JhbABEhhe8JHqBCIIfAQEEAQEBDwEQSwYFEAIBCCIdAwICAiULFBECBA4FCAwOh2gLnAKNKZJojAEVBQEFhQgyYQOXFY09gWuCb4FcCBce X-IronPort-AV: E=Sophos;i="4.80,701,1344211200"; d="scan'208,217";a="138236592" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 02 Nov 2012 16:55:22 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA2GtLY9019758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 16:55:21 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 11:55:21 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] Reactive Protocol Situation Thread-Index: AQHNuRrYLPVi/cSo/ES1hdb7zda62w== Date: Fri, 2 Nov 2012 16:55:20 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> In-Reply-To: <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.78] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--41.489700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204C36Exmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 16:55:33 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772204C36Exmbrcdx02ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBOb3YgMiwgMjAxMiwgYXQgMTE6MDggQU0sIFVscmljaCBIZXJiZXJnIHdyb3RlOg0KDQpJ IHRoaW5rIG9uZSBrZXkgcG9pbnQgdG8gc3RyZXNzIGlzIG9uZSB0aGF0IENocmlzIG1lbnRpb25l ZDoNCkJvdGggcHJvdG9jb2xzIGFyZSBzaW1pbGFyIGluIHRoZWlyIG9wZXJhdGlvbiBhbmQgcGVy Zm9ybWFuY2UuIFNvIGFueW9uZSBhcmd1aW5nIGFnYWluc3QgdGhlIHBlcmZvcm1hbmNlIG9mIExP QURuZyBpcyBhdXRvbWF0aWNhbGx5IGFsc28gbm90IGludGVyZXN0ZWQgaW4gRFlNTy4NCg0KDQpT ZWUgbXkgcG9pbnQgVWxyaWNoIOKApiBhbmQgSSB3cm90ZSBpdCBkb3duIHNldmVyYWwgdGltZXMu IFRoZXJlIGFyZSBtYWpvciBjb25jZXJucyBpbiB1c2luZyBMb2FkLW5nIHdpdGggTExOcy4gUXVv dGluZyBMb2FkLW5nOg0KDQoNCjM8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2xh dXNlbi1sbG4tbG9hZG5nLTA2I3NlY3Rpb24tMz4uICBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudA0K DQoNCiAgIFRoaXMgcHJvdG9jb2w6DQoNCiAgIG8gIElzIGEgcmVhY3RpdmUgcm91dGluZyBwcm90 b2NvbCBmb3IgTW9iaWxlIEFkIGhvYyBORVR3b3Jrcw0KICAgICAgKE1BTkVUcykuDQoNCiAgIG8g IElzIGRlc2lnbmVkIHRvIHdvcmsgaW4gbmV0d29ya3Mgd2l0aCBkeW5hbWljIHRvcG9sb2d5IGlu IHdoaWNoIHRoZQ0KICAgICAgbGlua3MgbWF5IGJlIGxvc3N5IGR1ZSB0byBjb2xsaXNpb25zIG9y IHVuc3RhYmxlIGNoYW5uZWwuICBUaGUgdXNlDQogICAgICBjYXNlcyBpbmNsdWRlIHZlaGljdWxh ciBuZXR3b3JrcywgbG93IHBvd2VyIGFuZCBsb3NzeSBuZXR3b3JrcywNCiAgICAgIGNvbW11bml0 eSBuZXR3b3JrcywgbWlsaXRhcnkgbmV0d29ya3MsIGRpc2FzdGVyIHJlY292ZXJ5IG5ldHdvcmtz LA0KICAgICAgZXRjLg0KDQoNClRoaXMgaXMgd2hlcmUgSSBzdHJvbmdseSBvYmplY3QsIGFzIHNl dmVyYWwgb3RoZXIgb25lcyBvbiB0aGlzIG1haWxpbmcgbGlzdC4gT25lIGNhbm5vdCBzaW1wbHkg Zm9yZ2V0IDQtNSB5ZWFycyBvZiBoYXJkIHdvcmsgZnJvbSBhIFdHIHRoYXQgZm9jdXNzZWQNCm9u IHRoaXMgdXNlIGNhc2UgYW5kIGNvbmNsdWRlZCB0aGF0IHN1Y2ggcHJvdG9jb2wgaXMgbm90IGFw cGxpY2FibGUgdG8gTExOcy4NCg0KSG93ZXZlciwgTE9BRG5nIGlzIGZhciBjbG9zZXIgdG8gYmVj b21lIGFuIFJGQyBpbiB0ZXJtcyBvZiB0aGUgZG9jdW1lbnQgcXVhbGl0eS4gSWYgd2Ugc3RhcnQg dGhlIG5ldyByZWFjdGl2ZSBwcm90b2NvbCBvbiB0aGUgYmFzaXMgb2YgdGhlIExPQURuZyBkcmFm dCAoYW5kIEkgcGVyc29uYWxseSBkb24ndCBjYXJlIHdoYXQgd2UgbmFtZSB0aGF0IHByb3RvY29s IGlzKSwgd2UgY2FuIGNvbnRpbnVlIHRoZSB3b3JrIG9uIHRoZSByZWFjdGl2ZSBwcm90b2NvbCB0 b2dldGhlciBhbmQgZGlzY3VzcyB0aGUgbXVsdGlwbGUgb3B0aW9ucyB0aGF0IGFyZSBjdXJyZW50 bHkgaW4gRFlNTyBhbmQgc2VlIHdoZXRoZXIgdGhleSBzaG91bGQgYmUgZGlzY2FyZGVkLCBwdXQg aW50byBhIGNvbXBhbmlvbiBkb2N1bWVudCBvciBpbiB0aGUgY29yZSBzcGVjLg0KDQpCZXN0DQpV bHJpY2gNCg0KT24gTm92IDIsIDIwMTIsIGF0IDc6NTQsIFl1aWNoaSBJR0FSQVNISSA8eXVpY2hp LmlnYXJhc2hpLmhiQGhpdGFjaGkuY29tPG1haWx0bzp5dWljaGkuaWdhcmFzaGkuaGJAaGl0YWNo aS5jb20+PiB3cm90ZToNCg0KSGksDQoNCkkgYWdyZWUgd2l0aCBNYXJ0aW4gYW5kIEkgd291bGQg c3VwcG9ydCBvcHRpb24gMikgYXQgdGhpcyBzdGFnZS4NCg0KV2UgTE9BRG5nIGNvLWF1dGhvcnMg bWFkZSBlZmZvcnRzIHRvIHNpbXBsaWZ5IGNvcmUgc3BlY2lmaWNhdGlvbiBvZiB0aGUgcmVhY3Rp dmUgcHJvdG9jb2wgYW5kIHRvIGltcHJvdmUgdGhlIHJlYWRhYmlsaXR5IG9mIHRoZSBkcmFmdC4g SSB0aGluayB0aGlzIGFwcHJvYWNoIGlzIGltcG9ydGFudCBub3Qgb25seSBmb3IgYWxsIGltcGxl bWVudG9yIHRvIHNob3J0ZW4gdGhlIGRldmVsb3BtZW50IHRpbWUsIGJ1dCBhbHNvIGZvciBidXNp bmVzcyBvcGVyYXRvcnMgdG8gbWFrZSBtdWx0aS12ZW5kb3Igc3lzdGVtIGVhc2llciB0byBwcm92 aWRlLiBPZiBjb3Vyc2UsIEkgYWdyZWUgdGhhdCwgYXMgc2V2ZXJhbCBwZXJzb25zIHBvaW50ZWQg b3V0LCAidGhpcyBkcmFmdCIgbWF5IGxpbWl0IHVzZSBjYXNlLiBCdXQgd2UgbGVhdmUgc3VmZmlj aWVudCBzcGFjZSBmb3IgaW1wcm92aW5nIHBlcmZvcm1hbmNlL2FkZGluZyBmdW5jdGlvbnMgYnkg Y29tcGFuaW9uIGRyYWZ0cy4NCg0KSSBhbSByZWFsbHkgY29uY2VybmVkIGFib3V0IGNvbXBsZXhp dHkvZGlmZmljdWx0eSBvZiBndWFyYW50ZWVpbmcgb2YgaW50ZXJvcGVyYWJpbGl0eS4gSWYgdGhl IHByb3RvY29sIGJlY29tZXMgY29tcGxpY2F0ZWQsIHdlIG5lZWQgbXVjaCB0aW1lKG1hbnkgeWVh cnM/KSBmb3IgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0LiBJIHRoaW5rIHdlIHNob3VsZCBjb25zaWRl ciBib3RoIHRpbWUgcmVxdWlyZWQgZm9yIG1lcmdpbmcgZHJhZnRzIGFuZCBzaGFwZSBvZiBkb2N1 bWVudC4NCg0KQmVzdCByZWdhcmRzLA0KWXVpY2hpDQooMjAxMi8xMS8wMiAyMzowMSksIE1hcnRp biBIZXVzc2Ugd3JvdGU6DQoNCkknbSBzdGFuZGluZyBmb3Igb3B0aW9uIDIgKExPQURuZykuDQoN CkkgdGhpbmsgaXQncyBiZXR0ZXIgdG8gYWdyZWUgZmlyc3Qgb24gYSBzaW1wbGUgYmFzaWMgKHZl cnNhdGlsZT8pIHByb3RvY29sIGJlZm9yZSBwcm9wb3NpbmcgZXh0ZW5zaW9ucyB0byBpdDsgaW5z dGVhZCBvZiBzdGFydGluZyBmcm9tIGEgY29sbGVjdGlvbiBvZiBpZGVhcyB0aGF0IGNhbiBiZSB1 c2VkIG9yIG5vdCAoYW5kIHdlIGtub3cgdG9kYXkgd2hhdCBhcmUgdGhlIG9wdGlvbnMsIHRoYW5r IHRvIHRoZSBodWdlIGFtb3VudCBvZiB3b3JrIGRvbmUgb24gcmVhY3RpdmUgcm91dGluZyBkdXJp bmcgdGhlIHBhc3QgeWVhcnMpLiBDb252ZXJzZWx5LCBpdCB3b3VsZCBiZSBjZXJ0YWlubHkgZWFz aWVyIHRvIHJlYWNoIGEgY29uc2Vuc3VzIG9uIGEgc2V0IG9mIHZhcmlhbnRzIGJ1dCB3ZSBuZWVk IGEgZ29vZCByZWZlcmVuY2UgcG9pbnQsIGZpcnN0Lg0KDQpNb3Jlb3ZlciwgcmVhY3RpdmUgcm91 dGluZyBpcyBtb3N0IHByb2JhYmx5IHRoZSBhcHByb2FjaCB0aGF0IG9uZSB3b3VsZCBwaWNrIGZv ciBhIHNpbXBsZSBjYXNlLiBTbyBpdCBzaG91bGQgYmUgc2ltcGxlLi4uDQoNCk1hcnRpbg0KDQoN CkxlIDIgbm92LiAyMDEyIMOgIDAxOjU4LCBKb3lkZWVwIFRyaXBhdGhpIGEgw6ljcml0IDoNCg0K SSBjYW4gdW5kZXJzdGFuZCB0aGF0IGZvciBhbiBMTE4gaXQgbWF5IGJlIGJlbmVmaWNpYWwgZm9y IG5vdCBtYWludGFpbmluZyBhIHByZWN1cnNvciBsaXN0IG9yIGhhdmluZyBvbmx5IHRoZSBkZXN0 aW5hdGlvbiByZXBseSB0IG8gYSBSUkVRLCB0aGVyZSBjYW4gYmUgKGFuZCBhcmUpIG90aGVyIGlu c3RhbmNlcyBvZiBNQU5FVHMgd2hlcmUgaGF2aW5nIHRoZSBvcHRpb24gb2YgcHJlY3Vyc29yIGxp c3Qgd2lsbCBjb21lIGhhbmR5LiBUaGlzIGNhbiBzYXZlIG9uIGNvbnRyb2wgb3ZlcmhlYWQsIHVz aW5nIHNvbWUgc3RvcmFnZSBzcGFjZSBpbiB0aGUgbm9kZS4gTE9BRC1uZywgaW4gbW9zdCBjYXNl cyBkb2VzIG5vdCBwcm92aWRlIHRoaXMgZmxleGliaWxpdHkgdG8gdGhlIGRldmVsb3BlciB0byBj aG9zZSBiZXR3ZWVuIG9wdGlvbnMgZm9yIHNwZWNpZmljIGRlcGxveW1lbnQuIFNvbWUgTUFORVQg ZGVwbG95bWVudCBtYXkgYmUgbGVzcyBoYXJzaCB0aGFuIG90aGVycyBpbiBuYXR1cmUuIEhlbmNl LCBBT0RWdjIgaGF2aW5nIG1vcmUgb3BlbiBvcHRpb25zIHRoYW4gTE9BRC1uZywgaW4gbW9zdCBj YXNlcywgc2VlbSBiZW5lZmljaWFsIHRvIG1lLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9y ZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21hbmV0DQoNCg0KLS0NCkhpdGFjaGksIEx0ZC4sIFlva29oYW1hIFJlc2VhcmNoIExh Ym9yYXRvcnkNCklHQVJBU0hJIFl1aWNoaQ0KTWFpbO+8miB5dWljaGkuaWdhcmFzaGkuaGJAaGl0 YWNoaS5jb208bWFpbHRvOnl1aWNoaS5pZ2FyYXNoaS5oYkBoaXRhY2hpLmNvbT4NClRlbCDvvJog KzgxLSgwKTQ1LTg2MC0zMDgzDQpGQVgg77yaICs4MS0oMCk0NS04NjAtMTY3Mw0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlz dA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8 bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tYW5ldA0KDQo= --_000_03B78081B371D44390ED6E7BADBB4A772204C36Exmbrcdx02ciscoc_ Content-Type: text/html; charset="utf-8" Content-ID: <97F9C07F6D7CDD46924F0EDEC86544B9@cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxicj4NCjxkaXY+DQo8ZGl2Pk9uIE5vdiAyLCAy MDEyLCBhdCAxMTowOCBBTSwgVWxyaWNoIEhlcmJlcmcgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9 IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8 ZGl2PkkgdGhpbmsgb25lIGtleSBwb2ludCB0byBzdHJlc3MgaXMgb25lIHRoYXQgQ2hyaXMgbWVu dGlvbmVkOjxicj4NCkJvdGggcHJvdG9jb2xzIGFyZSBzaW1pbGFyIGluIHRoZWlyIG9wZXJhdGlv biBhbmQgcGVyZm9ybWFuY2UuIFNvIGFueW9uZSBhcmd1aW5nIGFnYWluc3QgdGhlIHBlcmZvcm1h bmNlIG9mIExPQURuZyBpcyBhdXRvbWF0aWNhbGx5IGFsc28gbm90IGludGVyZXN0ZWQgaW4gRFlN Ty4NCjxicj4NCjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+U2VlIG15IHBvaW50IFVscmljaCDigKYgYW5kIEkgd3JvdGUgaXQgZG93biBzZXZlcmFs IHRpbWVzLiBUaGVyZSBhcmUgbWFqb3IgY29uY2VybnMgaW4gdXNpbmcgTG9hZC1uZyB3aXRoIExM TnMuIFF1b3RpbmcgTG9hZC1uZzo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPHBy ZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMWVtOyBtYXJnaW4tdG9wOiAwcHg7 IG1hcmdpbi1ib3R0b206IDBweDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsgY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogLXdlYmtpdC1hdXRvOyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7ICI+PHNwYW4gY2xhc3M9ImgyIiBzdHlsZT0ibGluZS1oZWlnaHQ6IDBwdDsgZGlzcGxh eTogaW5saW5lOyB3aGl0ZS1zcGFjZTogcHJlOyBmb250LWZhbWlseTogbW9ub3NwYWNlOyBmb250 LXNpemU6IDFlbTsgZm9udC13ZWlnaHQ6IGJvbGQ7ICI+PGgyIHN0eWxlPSJsaW5lLWhlaWdodDog MHB0OyBkaXNwbGF5OiBpbmxpbmU7IHdoaXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFtaWx5OiBtb25v c3BhY2U7IGZvbnQtc2l6ZTogMWVtOyBmb250LXdlaWdodDogYm9sZDsgIj48YSBjbGFzcz0ic2Vs ZmxpbmsiIG5hbWU9InNlY3Rpb24tMyIgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtY2xhdXNlbi1sbG4tbG9hZG5nLTA2I3NlY3Rpb24tMyIgc3R5bGU9ImNvbG9yOiBibGFj azsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyAiPjM8L2E+LiAgQXBwbGljYWJpbGl0eSBTdGF0ZW1l bnQ8L2gyPjwvc3Bhbj4NCg0KICAgVGhpcyBwcm90b2NvbDoNCg0KICAgbyAgSXMgYSByZWFjdGl2 ZSByb3V0aW5nIHByb3RvY29sIGZvciBNb2JpbGUgQWQgaG9jIE5FVHdvcmtzDQogICAgICAoTUFO RVRzKS4NCg0KICAgbyAgSXMgZGVzaWduZWQgdG8gd29yayBpbiBuZXR3b3JrcyB3aXRoIGR5bmFt aWMgdG9wb2xvZ3kgaW4gd2hpY2ggdGhlDQogICAgICBsaW5rcyBtYXkgYmUgbG9zc3kgZHVlIHRv IGNvbGxpc2lvbnMgb3IgdW5zdGFibGUgY2hhbm5lbC4gIFRoZSB1c2UNCiAgICAgIGNhc2VzIGlu Y2x1ZGUgdmVoaWN1bGFyIG5ldHdvcmtzLCBsb3cgcG93ZXIgYW5kIGxvc3N5IG5ldHdvcmtzLA0K ICAgICAgY29tbXVuaXR5IG5ldHdvcmtzLCBtaWxpdGFyeSBuZXR3b3JrcywgZGlzYXN0ZXIgcmVj b3ZlcnkgbmV0d29ya3MsDQogICAgICBldGMuDQo8L3ByZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PlRoaXMgaXMgd2hlcmUgSSBzdHJvbmdseSBvYmplY3QsIGFzIHNldmVyYWwgb3RoZXIgb25l cyBvbiB0aGlzIG1haWxpbmcgbGlzdC4gT25lIGNhbm5vdCBzaW1wbHkgZm9yZ2V0IDQtNSB5ZWFy cyBvZiBoYXJkIHdvcmsgZnJvbSBhIFdHIHRoYXQgZm9jdXNzZWQmbmJzcDs8L2Rpdj4NCjxkaXY+ b24gdGhpcyB1c2UgY2FzZSZuYnNwO2FuZCBjb25jbHVkZWQgdGhhdCBzdWNoIHByb3RvY29sIGlz IG5vdCBhcHBsaWNhYmxlIHRvIExMTnMuPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPg0KPGRpdj5Ib3dldmVyLCBMT0FEbmcgaXMgZmFyIGNsb3NlciB0byBiZWNv bWUgYW4gUkZDIGluIHRlcm1zIG9mIHRoZSBkb2N1bWVudCBxdWFsaXR5LiBJZiB3ZSBzdGFydCB0 aGUgbmV3IHJlYWN0aXZlIHByb3RvY29sIG9uIHRoZSBiYXNpcyBvZiB0aGUgTE9BRG5nIGRyYWZ0 IChhbmQgSSBwZXJzb25hbGx5IGRvbid0IGNhcmUgd2hhdCB3ZSBuYW1lIHRoYXQgcHJvdG9jb2wg aXMpLCB3ZSBjYW4gY29udGludWUgdGhlIHdvcmsgb24gdGhlIHJlYWN0aXZlDQogcHJvdG9jb2wg dG9nZXRoZXIgYW5kIGRpc2N1c3MgdGhlIG11bHRpcGxlIG9wdGlvbnMgdGhhdCBhcmUgY3VycmVu dGx5IGluIERZTU8gYW5kIHNlZSB3aGV0aGVyIHRoZXkgc2hvdWxkIGJlIGRpc2NhcmRlZCwgcHV0 IGludG8gYSBjb21wYW5pb24gZG9jdW1lbnQgb3IgaW4gdGhlIGNvcmUgc3BlYy4NCjxicj4NCjxi cj4NCkJlc3Q8YnI+DQpVbHJpY2g8YnI+DQo8YnI+DQpPbiBOb3YgMiwgMjAxMiwgYXQgNzo1NCwg WXVpY2hpIElHQVJBU0hJICZsdDs8YSBocmVmPSJtYWlsdG86eXVpY2hpLmlnYXJhc2hpLmhiQGhp dGFjaGkuY29tIj55dWljaGkuaWdhcmFzaGkuaGJAaGl0YWNoaS5jb208L2E+Jmd0OyB3cm90ZTo8 YnI+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5IaSw8YnI+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj5JIGFncmVlIHdpdGggTWFydGluIGFuZCBJIHdvdWxkIHN1cHBvcnQgb3B0 aW9uIDIpIGF0IHRoaXMgc3RhZ2UuPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+V2Ug TE9BRG5nIGNvLWF1dGhvcnMgbWFkZSBlZmZvcnRzIHRvIHNpbXBsaWZ5IGNvcmUgc3BlY2lmaWNh dGlvbiBvZiB0aGUgcmVhY3RpdmUgcHJvdG9jb2wgYW5kIHRvIGltcHJvdmUgdGhlIHJlYWRhYmls aXR5IG9mIHRoZSBkcmFmdC4gSSB0aGluayB0aGlzIGFwcHJvYWNoIGlzIGltcG9ydGFudCBub3Qg b25seSBmb3IgYWxsIGltcGxlbWVudG9yIHRvIHNob3J0ZW4gdGhlIGRldmVsb3BtZW50IHRpbWUs IGJ1dA0KIGFsc28gZm9yIGJ1c2luZXNzIG9wZXJhdG9ycyB0byBtYWtlIG11bHRpLXZlbmRvciBz eXN0ZW0gZWFzaWVyIHRvIHByb3ZpZGUuIE9mIGNvdXJzZSwgSSBhZ3JlZSB0aGF0LCBhcyBzZXZl cmFsIHBlcnNvbnMgcG9pbnRlZCBvdXQsICZxdW90O3RoaXMgZHJhZnQmcXVvdDsgbWF5IGxpbWl0 IHVzZSBjYXNlLiBCdXQgd2UgbGVhdmUgc3VmZmljaWVudCBzcGFjZSBmb3IgaW1wcm92aW5nIHBl cmZvcm1hbmNlL2FkZGluZyBmdW5jdGlvbnMgYnkgY29tcGFuaW9uIGRyYWZ0cy48YnI+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5JIGFtIHJlYWxseSBjb25jZXJuZWQgYWJvdXQgY29tcGxl eGl0eS9kaWZmaWN1bHR5IG9mIGd1YXJhbnRlZWluZyBvZiBpbnRlcm9wZXJhYmlsaXR5LiBJZiB0 aGUgcHJvdG9jb2wgYmVjb21lcyBjb21wbGljYXRlZCwgd2UgbmVlZCBtdWNoIHRpbWUobWFueSB5 ZWFycz8pIGZvciBpbnRlcm9wZXJhYmlsaXR5IHRlc3QuIEkgdGhpbmsgd2Ugc2hvdWxkIGNvbnNp ZGVyIGJvdGggdGltZSByZXF1aXJlZCBmb3IgbWVyZ2luZw0KIGRyYWZ0cyBhbmQgc2hhcGUgb2Yg ZG9jdW1lbnQuPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJy Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+QmVzdCByZWdhcmRzLDxi cj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPll1aWNoaTxicj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPigyMDEyLzExLzAyIDIzOjAxKSwg TWFydGluIEhldXNzZSB3cm90ZTo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+SSdtIHN0YW5kaW5nIGZvciBvcHRpb24gMiAoTE9BRG5nKS48YnI+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+SSB0aGluayBpdCdzIGJl dHRlciB0byBhZ3JlZSBmaXJzdCBvbiBhIHNpbXBsZSBiYXNpYyAodmVyc2F0aWxlPykgcHJvdG9j b2wgYmVmb3JlIHByb3Bvc2luZyBleHRlbnNpb25zIHRvIGl0OyBpbnN0ZWFkIG9mIHN0YXJ0aW5n IGZyb20gYSBjb2xsZWN0aW9uIG9mIGlkZWFzIHRoYXQgY2FuIGJlIHVzZWQgb3Igbm90IChhbmQg d2Uga25vdyB0b2RheSB3aGF0IGFyZSB0aGUgb3B0aW9ucywgdGhhbmsgdG8gdGhlDQogaHVnZSBh bW91bnQgb2Ygd29yayBkb25lIG9uIHJlYWN0aXZlIHJvdXRpbmcgZHVyaW5nIHRoZSBwYXN0IHll YXJzKS4gQ29udmVyc2VseSwgaXQgd291bGQgYmUgY2VydGFpbmx5IGVhc2llciB0byByZWFjaCBh IGNvbnNlbnN1cyBvbiBhIHNldCBvZiB2YXJpYW50cyBidXQgd2UgbmVlZCBhIGdvb2QgcmVmZXJl bmNlIHBvaW50LCBmaXJzdC48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+TW9yZW92ZXIsIHJlYWN0aXZlIHJvdXRpbmcgaXMgbW9zdCBwcm9i YWJseSB0aGUgYXBwcm9hY2ggdGhhdCBvbmUgd291bGQgcGljayBmb3IgYSBzaW1wbGUgY2FzZS4g U28gaXQgc2hvdWxkIGJlIHNpbXBsZS4uLjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJy Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5NYXJ0aW48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj5MZSAyIG5vdi4gMjAxMiDDoCAwMTo1OCwgSm95ZGVlcCBUcmlwYXRoaSBhIMOpY3JpdCA6 PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+SSBjYW4gdW5kZXJzdGFuZCB0aGF0IGZvciBhbiBM TE4gaXQgbWF5IGJlIGJlbmVmaWNpYWwgZm9yIG5vdCBtYWludGFpbmluZyBhIHByZWN1cnNvciBs aXN0IG9yIGhhdmluZyBvbmx5IHRoZSBkZXN0aW5hdGlvbiByZXBseSB0IG8gYSBSUkVRLCB0aGVy ZSBjYW4gYmUgKGFuZCBhcmUpIG90aGVyIGluc3RhbmNlcyBvZiBNQU5FVHMgd2hlcmUgaGF2aW5n IHRoZSBvcHRpb24gb2YgcHJlY3Vyc29yIGxpc3Qgd2lsbA0KIGNvbWUgaGFuZHkuIFRoaXMgY2Fu IHNhdmUgb24gY29udHJvbCBvdmVyaGVhZCwgdXNpbmcgc29tZSBzdG9yYWdlIHNwYWNlIGluIHRo ZSBub2RlLiBMT0FELW5nLCBpbiBtb3N0IGNhc2VzIGRvZXMgbm90IHByb3ZpZGUgdGhpcyBmbGV4 aWJpbGl0eSB0byB0aGUgZGV2ZWxvcGVyIHRvIGNob3NlIGJldHdlZW4gb3B0aW9ucyBmb3Igc3Bl Y2lmaWMgZGVwbG95bWVudC4gU29tZSBNQU5FVCBkZXBsb3ltZW50IG1heSBiZSBsZXNzIGhhcnNo IHRoYW4gb3RoZXJzDQogaW4gbmF0dXJlLiBIZW5jZSwgQU9EVnYyIGhhdmluZyBtb3JlIG9wZW4g b3B0aW9ucyB0aGFuIExPQUQtbmcsIGluIG1vc3QgY2FzZXMsIHNlZW0gYmVuZWZpY2lhbCB0byBt ZS48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPm1hbmV0IG1haWxpbmcgbGlzdDxi cj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3Jn Ij5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4t LSA8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5IaXRhY2hpLCBM dGQuLCBZb2tvaGFtYSBSZXNlYXJjaCBMYWJvcmF0b3J5PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+SUdBUkFTSEkgWXVpY2hpPGJyPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+TWFpbO+8miA8YSBocmVmPSJtYWlsdG86eXVpY2hpLmln YXJhc2hpLmhiQGhpdGFjaGkuY29tIj55dWljaGkuaWdhcmFzaGkuaGJAaGl0YWNoaS5jb208L2E+ PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+VGVsIO+8miAmIzQz OzgxLSgwKTQ1LTg2MC0zMDgzPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+RkFYIO+8miAmIzQzOzgxLSgwKTQ1LTg2MC0xNjczPGJyPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij5tYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9h Pjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGll dGYub3JnPC9hPjxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFu ZXQ8YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_03B78081B371D44390ED6E7BADBB4A772204C36Exmbrcdx02ciscoc_-- From jblack.ietf@yahoo.com Fri Nov 2 09:58:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5DB21F87D1 for ; Fri, 2 Nov 2012 09:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.585 X-Spam-Level: X-Spam-Status: No, score=-1.585 tagged_above=-999 required=5 tests=[AWL=1.013, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWjpyTuEtgJe for ; Fri, 2 Nov 2012 09:58:21 -0700 (PDT) Received: from nm21-vm0.bullet.mail.bf1.yahoo.com (nm21-vm0.bullet.mail.bf1.yahoo.com [98.139.213.137]) by ietfa.amsl.com (Postfix) with ESMTP id C9CCA21F879B for ; Fri, 2 Nov 2012 09:58:20 -0700 (PDT) Received: from [98.139.212.149] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 16:58:17 -0000 Received: from [98.139.212.207] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 16:58:16 -0000 Received: from [127.0.0.1] by omp1016.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 16:58:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 976034.17157.bm@omp1016.mail.bf1.yahoo.com Received: (qmail 59363 invoked by uid 60001); 2 Nov 2012 16:58:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351875496; bh=5Aj3DauDUn1O2ceM+1Xfk0av56QyBIXCYIGPG8Yn090=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=U9ylLKGQjMfNKzhBjOXIwcxCEDkItjrFA3OAhWZETO14bw5nBeNDRKxOYY+GGqlT4fsWRpY+X4IXT4th/5U/xLeEDkMIbo83daRNkPlN+DhsouSJF6Gb2sxcFhS3RS6NNYkJt6+nEbDuqFQZgCVUvy3l2NIND5ffQUb3uZoCWrs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=T026qEC40Nya1GGAzGoMR9RfgJl4fKD5YNTFY/WLOT+lgCekshdEI0Op8LEaUsBBeQ0rTSLUySUTC0eAVQbEbqSyvBpkUnfewlzhF/QsXc1REsYwQKjTjDBk6GaWkK37BgBoHUux6CwbnZVImU5p58SNxJiTqWQmUmqbjtw4fNg=; X-YMail-OSG: PxrmGk0VM1mASi2UzqFIMqaXPbrvTGF4n5HAkmQ4OB8SzCs .nAOhL2vc94sIksveedrvsNRF96uG6VLqXzGEMqFzPsSCYPAh29.0P3oYQum ln2HrZvRrPmQXXdEpnCGWDSxsub1rAryhywCMq1H6.ujr2JYRO8MAn7MSEmV TXQAnDVv58DaxC2Jc5nfV2mVUGJhtyYqRLPpSL4CscXY5QXh14fY69dgEUKW KWD7y7FMZPWHQpqbPZq7d0_kI7ao8bHZadOEvu97MWlnJTpNzyicoAD.J_xF cjs109QdVAae5JYAKo1xGAvHGeZfBI1t4xgcMbQte5NQaQmQ2jp.TBVeP4Xp Rwu3eyy27QebvsmG69Ob27PxgYCME8skCWI.z.bON6PWHuprmUAtboLfxktl VQTjoLfK1sV_PCjgu8fA51Ii9e.vMI4fPBYjQHNYWzICNc2yNfAmpb5LaJe_ XxXKG5us2v5ZHY5AmyStHWHN3u.VMybp7KgKuEUMEGwH9J0e0bMbZAH2PAWD 9GXOmzwPs0bjRc4IKFHw_EmM- Received: from [173.193.202.116] by web160603.mail.bf1.yahoo.com via HTTP; Fri, 02 Nov 2012 09:58:16 PDT X-Rocket-MIMEInfo: 001.001, SSBhZ3JlZSB0aGF0IGZyb20gcmVhZGluZyBib3RoIGRvY3VtZW50cyBpdCB3b3VsZCBtYWtlIG11Y2ggbW9yZSBzZW5zZSB0byBzdGFydCB3aXRoIHRoZSBMT0FEbmcgZHJhZnQgYW5kIGVuaGFuY2UgaXQgd2l0aCB0aGUgaXRlbXMgZnJvbSBEWU1PIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgZmVlbCBhcmUgbmVjZXNzYXJ5LgoKVGhlIExPQURuZyBkcmFmdCBzZWVtcyBsaWtlIGEgbXVjaCBiZXR0ZXIgYmFzaXMgdG8gc3RhcnQgZnJvbS7CoCBJIGRvbid0IHNlZSB3aHkgQ2hhcmxpZSBhbmQgZ3JvdXAgY2FuJ3QBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: Message-ID: <1351875496.58211.YahooMailNeo@web160603.mail.bf1.yahoo.com> Date: Fri, 2 Nov 2012 09:58:16 -0700 (PDT) From: Jon Black To: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1886287700-1225045945-1351875496=:58211" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 16:58:22 -0000 --1886287700-1225045945-1351875496=:58211 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I agree that from reading both documents it would make much more sense to s= tart with the LOADng draft and enhance it with the items from DYMO that the= working group feel are necessary.=0A=0AThe LOADng draft seems like a much = better basis to start from.=A0 I don't see why Charlie and group can't star= t with LOADng as the base.=0A=0AJon=0A=0A=0A=0A=0A=0A______________________= __________=0A From: "Dearlove, Christopher (UK)" =0ATo: "manet@ietf.org" =0ASent: Friday, November 2, = 2012 5:16 AM=0ASubject: [manet] A proposal - differentiating the document a= nd the protocol=0A =0ABefore making a proposal, I'm going to introduce a di= stinction here between the DYMO and LOADng documents and protocols.=0A=0AI'= m of the opinion that the LOADng document is a greatly superior presentatio= n to the DYMO document. (I'm not really interested in why that has come abo= ut.)=0A=0AI think that regardless of whether one makes design decisions fav= ouring DYMO or LOADng where they differ - and let's not forget they overlap= a lot - it would actually be easier to modify the LOADng document to speci= fy DYMO than it would be to modify the DYMO document to achieve that. And i= n practice I think if making decisions it is unlikely that all would favour= DYMO over LOADng.=0A=0ASo what I think would be best for the WG is not a s= imply "option 1" or even (as it may appear I'm suggesting, but=A0 I'm not) = "option 2" but rather to agree to take the LOADng document, and a list of w= here DYMO and LOADng differ, and thrash out where they do, what the WG reac= tive protocol should do - either as a definite choice, or as an option (but= not too many options please- and some could be separate specifications).= =0A=0AThis would not of course be LOADng, so we'd have to change the docume= nt name. And there I suggest we have a candidate name - AODVv2. (Which is w= hy I have recently taken to saying DYMO when referring to that document.) A= fter all, the one thing we are agreed on is that the protocol being develop= ed is derived from AODV.=0A=0AThe editors of this new document would have t= o agree that what goes in it is WG consensus (which should follow proper te= chnical consideration of the issues). If they found it impossible to have o= ther than their way to do things, they'd have to move on. If that left no o= ne editing it, obviously we don't have a consensus of people prepared to do= the work and option 3 would win.=0A=0ASo now I'm partly off the fence I've= been sitting on. But only partly. I haven't yet formed a view on e.g. shou= ld this AODVv2 have IRREPs as standard, IRREPs as an option in the main dra= ft, IRREPs as a separate draft option, no IRREPs. I'd like to move on to th= ose discussions.=0A=0A-- =0AChristopher Dearlove=0ASenior Principal Enginee= r, Communications Group=0ACommunications, Networks and Image Analysis Capab= ility=0ABAE Systems Advanced Technology Centre=0AWest Hanningfield Road, Gr= eat Baddow, Chelmsford, CM2 8HN, UK=0ATel: +44 1245 242194=A0|=A0 Fax: +44 = 1245 242124=0Achris.dearlove@baesystems.com | http://www.baesystems.com=0A= =0ABAE Systems (Operations) Limited=0ARegistered Office: Warwick House, PO = Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK=0ARe= gistered in England & Wales No: 1996687=0A=0A=0A=0A************************= ********************************************=0AThis email and any attachmen= ts are confidential to the intended=0Arecipient and may also be privileged.= If you are not the intended=0Arecipient please delete it from your system = and notify the sender.=0AYou should not copy it or use it for any purpose n= or disclose or=0Adistribute its contents to any other person.=0A***********= *********************************************************=0A=0A____________= ___________________________________=0Amanet mailing list=0Amanet@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/manet --1886287700-1225045945-1351875496=:58211 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I agree that from rea= ding both documents it would make much more sense to start with the LOADng = draft and enhance it with the items from DYMO that the working group feel a= re necessary.

The LOADng draft seems like a much better basis to sta= rt from.  I don't see why Charlie and group can't start with LOADng as= the base.

Jon


Fr= om: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.c= om>
To: "manet@ietf= .org" <manet@ietf.org>
Sent: Friday, November 2, 2012 5:16 AM
Subject: [manet] A proposal - differentiating the docum= ent and the protocol

=0ABefore making a proposal, I'= m going to introduce a distinction here between the DYMO and LOADng documen= ts and protocols.

I'm of the opinion that the LOADng document is a g= reatly superior presentation to the DYMO document. (I'm not really interest= ed in why that has come about.)

I think that regardless of whether o= ne makes design decisions favouring DYMO or LOADng where they differ - and = let's not forget they overlap a lot - it would actually be easier to modify= the LOADng document to specify DYMO than it would be to modify the DYMO do= cument to achieve that. And in practice I think if making decisions it is u= nlikely that all would favour DYMO over LOADng.

So what I think woul= d be best for the WG is not a simply "option 1" or even (as it may appear I= 'm suggesting, but  I'm not) "option 2" but rather to agree to take th= e LOADng document, and a list of where DYMO and LOADng differ, and thrash o= ut where they do, what the WG reactive protocol should do - either as a definite choice, or as an option (but not= too many options please- and some could be separate specifications).
This would not of course be LOADng, so we'd have to change the document n= ame. And there I suggest we have a candidate name - AODVv2. (Which is why I= have recently taken to saying DYMO when referring to that document.) After= all, the one thing we are agreed on is that the protocol being developed i= s derived from AODV.

The editors of this new document would have to = agree that what goes in it is WG consensus (which should follow proper tech= nical consideration of the issues). If they found it impossible to have oth= er than their way to do things, they'd have to move on. If that left no one= editing it, obviously we don't have a consensus of people prepared to do t= he work and option 3 would win.

So now I'm partly off the fence I've= been sitting on. But only partly. I haven't yet formed a view on e.g. should this AODVv2 have IRREPs as standard, IRREPs as an option in th= e main draft, IRREPs as a separate draft option, no IRREPs. I'd like to mov= e on to those discussions.

--
Christopher Dearlove
Senior Pri= ncipal Engineer, Communications Group
Communications, Networks and Image= Analysis Capability
BAE Systems Advanced Technology Centre
West Hann= ingfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 24219= 4 |  Fax: +44 1245 242124
chris.dearlov= e@baesystems.com | http://www.baesystems.com

BAE Systems (Operat= ions) Limited
Registered Office: Warwick House, PO Box 87, Farnborough A= erospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England = & Wales No: 1996687



************************************= ********************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If y= ou 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.
************= ********************************************************

___________= ____________________________________
manet mailing list
manet@ietf.orghttps://www.ietf.org/mailman/listinfo/manet


=
--1886287700-1225045945-1351875496=:58211-- From hrogge@googlemail.com Fri Nov 2 10:00:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC3D21F8E0D for ; Fri, 2 Nov 2012 10:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQXA6PPOT-kz for ; Fri, 2 Nov 2012 10:00:42 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD6B21F8E09 for ; Fri, 2 Nov 2012 10:00:42 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so2593220pbb.31 for ; Fri, 02 Nov 2012 10:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=tf6M2aIfOdL5FkbTrRvd4w0V5qcb/mOy9hAbID++GvQ=; b=qGgtOf6OsDHv30nFxOews9m7Ogas7ImZ3SDFgHej8hA4Bz1fVWg+RYewlnkUMHDKLc jUWxz+ScLw2CBvA8VtXoBhbW4lzKoi+4h2hHKsc9Vs/rTa/aj5LCX3iYAd4MJar8BE6s tPnORbg54YGuK8v5EeH4lM6jD4CwSwbTnXjgUwKQzwbJV9Ifa2Nqsnk2OHw4ZFiV5vPm Rsr95tG0F6IKM5xuv255FZ3gTlstUrxW2iAJ/foWTlI3I7VUniL5vLlHdUTYvGbjA8Qz I6tj5b0IO659b4qGLbsgvnpJycu1mk9U4MfBdC43LyKW+xpaqWfjnB9frvs9VPHhdBYP M/aA== Received: by 10.68.219.163 with SMTP id pp3mr8015402pbc.13.1351875641945; Fri, 02 Nov 2012 10:00:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.6.34 with HTTP; Fri, 2 Nov 2012 10:00:21 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> References: <2142AF50-B02D-4FD0-95FD-E52351D17A57@imag.fr> <5093DEB4.7000907@hitachi.com> <51142AB9-D9F1-4E15-A0BF-DC00D4321114@herberg.name> <03B78081B371D44390ED6E7BADBB4A772204C36E@xmb-rcd-x02.cisco.com> From: Henning Rogge Date: Fri, 2 Nov 2012 18:00:21 +0100 Message-ID: To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Situation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:00:42 -0000 On Fri, Nov 2, 2012 at 5:55 PM, JP Vasseur (jvasseur) wrote: > See my point Ulrich =85 and I wrote it down several times. There are majo= r > concerns in using Load-ng with LLNs. Quoting Load-ng: > > 3. Applicability Statement > > This protocol: > > o Is a reactive routing protocol for Mobile Ad hoc NETworks > (MANETs). > > o Is designed to work in networks with dynamic topology in which the > links may be lossy due to collisions or unstable channel. The use > cases include vehicular networks, low power and lossy networks, > community networks, military networks, disaster recovery networks, > etc. > > > This is where I strongly object, as several other ones on this mailing li= st. > One cannot simply forget 4-5 years of hard work from a WG that focussed > on this use case and concluded that such protocol is not applicable to LL= Ns. This argument doesn't make any sense at all. The work of ROLL is totally irrelevant to the question if LoadNG is useful both for MANET and for LLNs (which I still consider a special case without MANET). Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From jblack.ietf@yahoo.com Fri Nov 2 10:01:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EDA11E80BF for ; Fri, 2 Nov 2012 10:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=0.869, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLS-A89qgTX1 for ; Fri, 2 Nov 2012 10:01:22 -0700 (PDT) Received: from nm35-vm6.bullet.mail.bf1.yahoo.com (nm35-vm6.bullet.mail.bf1.yahoo.com [72.30.238.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0C111E80BA for ; Fri, 2 Nov 2012 10:01:22 -0700 (PDT) Received: from [98.139.212.153] by nm35.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 17:01:21 -0000 Received: from [98.139.212.246] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 17:01:21 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 17:01:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 292899.5221.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 21709 invoked by uid 60001); 2 Nov 2012 17:01:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351875681; bh=QMC+BmuE+3Zb4nXP6mw26Di2imQOzx2zaEBj7p6frHc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gmgA922F8e0PIGZ8tkrCmWLw0b98JWQXD9XnB/XBl1UZbrLDKj6Ml2zOpF5a1Os8ua8pW2clZ4ekYx6z1MWud9ambgP5M/rzDP3GWMvYmWvR1USSYFYoAGmb+U05ME8lIKfv0JZqWSwObbOFyi974QDFvDBQ/6e/NgO3KSV2b7A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=s4/GtfwAt0oZDofeop/RSZ4ZByI/1mqJi9Q/oXXEf6u30g8Axa07YQa1mbPqvFZXC8rnLmrLIjX/mTPRih3txQsFiV9ptGXCeOU77xjU3kI82vSK74fC1++y9/miMSymBs9eFuwntwJykGLp+zliQMjrTH8NRy8IV6x1+EcaEMU=; X-YMail-OSG: z5WhJWEVM1lfa70Df9pjgGrkPknwV3Np.KGDuvU6E_B8blr q_tUQsa1wAB0vGCaRcdmemUuO1s_nF8Dlz8nGdziZlYm9NoZ4b1kJcte1TUo T36tcNQGTroYTtLc.4AkTwFK2AGGdQNoaa.07768kB51Kz_TmSpneEJq7VI2 Y3rLA_PiD5rlB6GyEKtSYg.3xCILGS89mK85XQceSkU1UifOR_VH23HETpXw nnTwbvSBZ0oiw0SxllJ0Rto9Hh0RnD8Sknpr3ErFt38PweWL1aeoCD0YdIJD 0vavgCkOZUQ9Pm_wJiSINU0DMk8UJlqxDnM6mCuEVZoRMoPr6HDr4f3BbumP R7Q.UC3iVnLHNDj4ff.m4Pj6VXUKFkdW1_46G4k0mTHCEy6bB0NzCAB9Lxhv 8.PTYQaFnP2kX0p18eMH9gyR8FIOiYguXrOCPP77WpugoIhrebrpGhp_e4VX lZa6dGSQUF2_xUfSfOpGV8l0zTLuIHSgl.3uQG7rzs7K2kdgztcsraTqPwe0 qDvQWjKfkh8bxnwf61FGiJLFe Received: from [173.193.202.116] by web160604.mail.bf1.yahoo.com via HTTP; Fri, 02 Nov 2012 10:01:21 PDT X-Rocket-MIMEInfo: 001.001, SXQgZG9lcyBoYXZlIGEgZ29vZCBzdHlsZSwgY2xlYXIsIGNsZWFuIGFuZCBkaXN0aW5jdCAoYXMgZG9lcyBPTFNSdjIpLsKgIEl0IGlzIHNvbWV0aGluZyB0aGF0IEkgY2FuIHJlYWQgYW5kIHN0YXJ0IHRvIGltcGxlbWVudC7CoCBJIGNhbid0IHNheSB0aGUgc2FtZSBmb3IgdGhlIERZTU8gZHJhZnQgaW4gaXRzIGN1cnJlbnQgc3RhdGUuCgpKb24KCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiAiRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykiIDxDaHJpcy5EZWFybG92ZUBiYWUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: Message-ID: <1351875681.21009.YahooMailNeo@web160604.mail.bf1.yahoo.com> Date: Fri, 2 Nov 2012 10:01:21 -0700 (PDT) From: Jon Black To: "Dearlove, Christopher \(UK\)" , Teco Boot In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-318397788-1410455737-1351875681=:21009" Cc: "manet@ietf.org" Subject: Re: [manet] A proposal - differentiating the document and the protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:01:23 -0000 ---318397788-1410455737-1351875681=:21009 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable It does have a good style, clear, clean and distinct (as does OLSRv2).=A0 I= t is something that I can read and start to implement.=A0 I can't say the s= ame for the DYMO draft in its current state.=0A=0AJon=0A=0A=0A=0A=0A_______= _________________________=0A From: "Dearlove, Christopher (UK)" =0ATo: Teco Boot =0ACc: "manet@ietf.o= rg" =0ASent: Friday, November 2, 2012 6:11 AM=0ASubject: R= e: [manet] A proposal - differentiating the document and the protocol=0A = =0AAs I said, I think the LOADng document will be much easier to adapt.=0A= =0ATwo comments there. First, it's odd reading that document, which I'm not= an author of, as large amounts feel like I did write them. That is of cour= se because it borrows the style of OLSRv2/NHDP, in turn adopted from (but i= mproved on) that on RFC 3626.=0A=0ASecond, is that a good style? Well, I wo= uld refer you to Barry Leiba's comments on OLSRv2 in the ID tracker as it g= oes through the IESG. It even got a YES (not just a no objection)=A0 from h= im on that account.=0A=0A-- =0AChristopher Dearlove=0ASenior Principal Engi= neer, Communications Group=0ACommunications, Networks and Image Analysis Ca= pability=0ABAE Systems Advanced Technology Centre=0AWest Hanningfield Road,= Great Baddow, Chelmsford, CM2 8HN, UK=0ATel: +44 1245 242194=A0|=A0 Fax: += 44 1245 242124=0Achris.dearlove@baesystems.com | http://www.baesystems.com= =0A=0ABAE Systems (Operations) Limited=0ARegistered Office: Warwick House, = PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK= =0ARegistered in England & Wales No: 1996687=0A=0A=0A-----Original Message-= ----=0AFrom: Teco Boot [mailto:teco@inf-net.nl] =0ASent: 02 November 2012 1= 2:05=0ATo: Dearlove, Christopher (UK)=0ACc: manet@ietf.org=0ASubject: Re: [= manet] A proposal - differentiating the document and the protocol=0A=0A----= ------------------! WARNING ! ----------------------=0AThis message origina= tes from outside our organisation,=0Aeither from an external partner or fro= m the internet.=0AKeep this in mind if you answer this message.=0AFollow th= e 'Report Suspicious Emails' link on IT matters=0Afor instructions on repor= ting suspicious email messages.=0A-----------------------------------------= ---------------=0A=0AThis is more or less what I suggested before, perhaps = not as clearly as Chris. I suggested to use the manet-dymo document track. = We don't have to, but I do not see any argument for renaming.=0A=0ABut firs= t, let's get in a cooperative mode. I kindly ask al to cool down a bit. See= n the energy on this list, my conclusion is that we all want a great reacti= ve MANET protocol as proposed standard.=0A=0ATeco=0A=0A=0AOp 2 nov. 2012, o= m 12:16 heeft Dearlove, Christopher (UK) het volgende geschreven:=0A=0A> Be= fore making a proposal, I'm going to introduce a distinction here between t= he DYMO and LOADng documents and protocols.=0A> =0A> I'm of the opinion tha= t the LOADng document is a greatly superior presentation to the DYMO docume= nt. (I'm not really interested in why that has come about.)=0A> =0A> I thin= k that regardless of whether one makes design decisions favouring DYMO or L= OADng where they differ - and let's not forget they overlap a lot - it woul= d actually be easier to modify the LOADng document to specify DYMO than it = would be to modify the DYMO document to achieve that. And in practice I thi= nk if making decisions it is unlikely that all would favour DYMO over LOADn= g.=0A> =0A> So what I think would be best for the WG is not a simply "optio= n 1" or even (as it may appear I'm suggesting, but=A0 I'm not) "option 2" b= ut rather to agree to take the LOADng document, and a list of where DYMO an= d LOADng differ, and thrash out where they do, what the WG reactive protoco= l should do - either as a definite choice, or as an option (but not too man= y options please- and some could be separate specifications).=0A> =0A> This= would not of course be LOADng, so we'd have to change the document name. A= nd there I suggest we have a candidate name - AODVv2. (Which is why I have = recently taken to saying DYMO when referring to that document.) After all, = the one thing we are agreed on is that the protocol being developed is deri= ved from AODV.=0A> =0A> The editors of this new document would have to agre= e that what goes in it is WG consensus (which should follow proper technica= l consideration of the issues). If they found it impossible to have other t= han their way to do things, they'd have to move on. If that left no one edi= ting it, obviously we don't have a consensus of people prepared to do the w= ork and option 3 would win.=0A> =0A> So now I'm partly off the fence I've b= een sitting on. But only partly. I haven't yet formed a view on e.g. should= this AODVv2 have IRREPs as standard, IRREPs as an option in the main draft= , IRREPs as a separate draft option, no IRREPs. I'd like to move on to thos= e discussions.=0A> =0A> -- =0A> Christopher Dearlove=0A> Senior Principal E= ngineer, Communications Group=0A> Communications, Networks and Image Analys= is Capability=0A> BAE Systems Advanced Technology Centre=0A> West Hanningfi= eld Road, Great Baddow, Chelmsford, CM2 8HN, UK=0A> Tel: +44 1245 242194 |= =A0 Fax: +44 1245 242124=0A> chris.dearlove@baesystems.com | http://www.bae= systems.com=0A> =0A> BAE Systems (Operations) Limited=0A> Registered Office= : Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hant= s, GU14 6YU, UK=0A> Registered in England & Wales No: 1996687=0A> =0A> =0A>= =0A> ********************************************************************= =0A> This email and any attachments are confidential to the intended=0A> re= cipient and may also be privileged. If you are not the intended=0A> recipie= nt please delete it from your system and notify the sender.=0A> You should = not copy it or use it for any purpose nor disclose or=0A> distribute its co= ntents to any other person.=0A> *******************************************= *************************=0A> =0A> ________________________________________= _______=0A> manet mailing list=0A> manet@ietf.org=0A> https://www.ietf.org/= mailman/listinfo/manet=0A=0A=0A____________________________________________= ___=0Amanet mailing list=0Amanet@ietf.org=0Ahttps://www.ietf.org/mailman/li= stinfo/manet ---318397788-1410455737-1351875681=:21009 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
It does have a good s= tyle, clear, clean and distinct (as does OLSRv2).  It is something tha= t I can read and start to implement.  I can't say the same for the DYM= O draft in its current state.

Jon


From: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>= ;
To: Teco Boot <te= co@inf-net.nl>
Cc: = "manet@ietf.org" <manet@ietf.org>
Sent: Friday, November 2, 2012 6:11 AM
Subject: Re: [manet] A proposal - diffe= rentiating the document and the protocol

=0AAs I sai= d, I think the LOADng document will be much easier to adapt.

Two com= ments there. First, it's odd reading that document, which I'm not an author= of, as large amounts feel like I did write them. That is of course because= it borrows the style of OLSRv2/NHDP, in turn adopted from (but improved on= ) that on RFC 3626.

Second, is that a good style? Well, I would refe= r you to Barry Leiba's comments on OLSRv2 in the ID tracker as it goes thro= ugh the IESG. It even got a YES (not just a no objection)  from him on= that account.

--
Christopher Dearlove
Senior Principal Engin= eer, Communications Group
Communications, Networks and Image Analysis Ca= pability
BAE Systems Advanced Technology Centre
West Hanningfield Roa= d, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |&nbs= p; Fax: +44 1245 242124
chris.dearlove@baesystems.co= m | http://www.baesystems.com

BAE Systems (Operations) LimitedRegistered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No:= 1996687


-----Original Message-----
From: Teco Boot [mailto:<= a ymailto=3D"mailto:teco@inf-net.nl" href=3D"mailto:teco@inf-net.nl">teco@i= nf-net.nl]
Sent: 02 November 2012 12:05
To: Dearlove, Christophe= r (UK)
Cc: manet@ietf.org
Subject: Re: [manet] A proposal - differentiat= ing the document and the protocol

----------------------! WARNING ! = ----------------------
This message originates from outside our organisa= tion,
either from an external partner or from the internet.
Keep this= in mind if you answer this message.
Follow the 'Report Suspicious Email= s' link on IT matters
for instructions on reporting suspicious email messa= ges.
--------------------------------------------------------

Thi= s is more or less what I suggested before, perhaps not as clearly as Chris.= I suggested to use the manet-dymo document track. We don't have to, but I = do not see any argument for renaming.

But first, let's get in a coop= erative mode. I kindly ask al to cool down a bit. Seen the energy on this l= ist, my conclusion is that we all want a great reactive MANET protocol as p= roposed standard.

Teco


Op 2 nov. 2012, om 12:16 heeft Dea= rlove, Christopher (UK) het volgende geschreven:

> Before making = a proposal, I'm going to introduce a distinction here between the DYMO and = LOADng documents and protocols.
>
> I'm of the opinion that th= e LOADng document is a greatly superior presentation to the DYMO document. = (I'm not really interested in why that has come about.)
>
> I think that regardless of whether one makes design decisions fav= ouring DYMO or LOADng where they differ - and let's not forget they overlap= a lot - it would actually be easier to modify the LOADng document to speci= fy DYMO than it would be to modify the DYMO document to achieve that. And i= n practice I think if making decisions it is unlikely that all would favour= DYMO over LOADng.
>
> So what I think would be best for the W= G is not a simply "option 1" or even (as it may appear I'm suggesting, but&= nbsp; I'm not) "option 2" but rather to agree to take the LOADng document, = and a list of where DYMO and LOADng differ, and thrash out where they do, w= hat the WG reactive protocol should do - either as a definite choice, or as= an option (but not too many options please- and some could be separate spe= cifications).
>
> This would not of course be LOADng, so we'd = have to change the document name. And there I suggest we have a candidate name - AODVv2. (Which is why I have recently taken to saying DYM= O when referring to that document.) After all, the one thing we are agreed = on is that the protocol being developed is derived from AODV.
>
&= gt; The editors of this new document would have to agree that what goes in = it is WG consensus (which should follow proper technical consideration of t= he issues). If they found it impossible to have other than their way to do = things, they'd have to move on. If that left no one editing it, obviously w= e don't have a consensus of people prepared to do the work and option 3 wou= ld win.
>
> So now I'm partly off the fence I've been sitting = on. But only partly. I haven't yet formed a view on e.g. should this AODVv2= have IRREPs as standard, IRREPs as an option in the main draft, IRREPs as = a separate draft option, no IRREPs. I'd like to move on to those discussion= s.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks = and Image Analysis Capability
> BAE Systems Advanced Technology Centr= e
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
= > Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com | http://www.baesystems.com
>
&g= t; BAE Systems (Operations) Limited
> Registered Office: Warwick Hous= e, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, U= K
> Registered in England & Wales No: 1996687
>
> >
> ***********************************************************= *********
> This email and any attachments are confidential to the in= tended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify th= e sender.
> You should not copy it or use it for any purpose nor disc= lose or
> distribute its contents to any other person.
> ******= **************************************************************
>
= > _______________________________________________
> manet mailing = list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet=


_______________________________________________
manet ma= iling list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet=


---318397788-1410455737-1351875681=:21009-- From jblack.ietf@yahoo.com Fri Nov 2 10:07:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B92511E80A3 for ; Fri, 2 Nov 2012 10:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.760, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGnWSwZ3QtKx for ; Fri, 2 Nov 2012 10:07:44 -0700 (PDT) Received: from nm29.bullet.mail.bf1.yahoo.com (nm29.bullet.mail.bf1.yahoo.com [98.139.212.188]) by ietfa.amsl.com (Postfix) with ESMTP id 9239011E8097 for ; Fri, 2 Nov 2012 10:07:43 -0700 (PDT) Received: from [98.139.215.142] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 17:07:42 -0000 Received: from [98.139.212.227] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 17:07:42 -0000 Received: from [127.0.0.1] by omp1036.mail.bf1.yahoo.com with NNFMP; 02 Nov 2012 17:07:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 803797.9383.bm@omp1036.mail.bf1.yahoo.com Received: (qmail 84279 invoked by uid 60001); 2 Nov 2012 17:07:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351876062; bh=shSoBxgfptWtdCsQLBMBEJVNHQQOk28Q7v7srPl5c3o=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qWEAZ2POQxbgqH6J3t4XgvLps0LgHKPx428rbmBwC0EvJr2tuYid45ioE3tn2WcL4vhk82zSbGKxCNb1ZCXScy3vQrzjnHB9jJ2hApfInUNVDaKluXpj9lIKv+b66eXCfQcbbyYVXugs/uIlJB+I+iDFs1ryXTO9+T/oEN5cF4o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=p2rhnEZHvv8StWI8QA/3ln1NsBsg/G1CAEeKOzNjPrayXMyznf5v/TDhcjw1Wo+cmJ8cc9cCgE6kFJrcp3mHQ7Sd0AbDhCXHd/xu1IUF0kxSMk8DsA7UtQwK2/DZwqQXysJ3EMZjaOz3P18O9LE6rxexslIamecptgNNGNlmW14=; X-YMail-OSG: wRP5sn0VM1n2wYxqCBJlTj_j0HNF.rZwF6knPiS_h93VYLo JHmXnTzHw6UShgG7WcRHb175k0TVIlhU6Q.9yP1eZzkdOmipUAu7bqm8xDVt SHiejk6sf9fAuG3jEMFbBabocjrY8xHjDBYyiKgoGDs0RoGVEsaKM.ajTw4c RA8Tlw7mEeLeeZ7raUkPGaPJzZPqWPL6nNnsvOOnfYJzGomRkABjSqOq5Pet QTXtYEx7VyYRG6g.uoWW1.vybHeYd8T5yNxYUfsUEC19zbxdZDY50D9WrZZN nHN4vHsHV1JMXge24dAv5TDo1U4BbGOoxWc0DMlU6zhbla6BsNAH_Ii1viik 3qeFPtIHWdlOw.1zEzd5OHDRCfbvas2nUQYdprW_9fX4wRbP8oqEnbghSEKW DjAzGy6OBbBWXX8FdjMPNio1NfLgCuql8yK2vzp3CulncsjfSjq_DKPoBqSI npO8mfoHS Received: from [173.193.202.116] by web160602.mail.bf1.yahoo.com via HTTP; Fri, 02 Nov 2012 10:07:42 PDT X-Rocket-MIMEInfo: 001.001, bm8gLSBpIGhhdmUgYSBjb25mbGljdCBuZXh0IHdlZWsgZGVwbG95aW5nIGEgc2Vuc29yIG5ldHdvcmsuCgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogSlAgVmFzc2V1ciAoanZhc3NldXIpIDxqdmFzc2V1ckBjaXNjby5jb20.ClRvOiBKb24gQmxhY2sgPGpibGFjay5pZXRmQHlhaG9vLmNvbT4gCkNjOiAibWFuZXRAaWV0Zi5vcmcgTGlzdCIgPG1hbmV0QGlldGYub3JnPiAKU2VudDogRnJpZGF5LCBOb3ZlbWJlciAyLCAyMDEyIDI6NDcgQU0KU3ViamVjdDogUmU6IFttYW5ldF0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772204AED7@xmb-rcd-x02.cisco.com> Message-ID: <1351876062.61554.YahooMailNeo@web160602.mail.bf1.yahoo.com> Date: Fri, 2 Nov 2012 10:07:42 -0700 (PDT) From: Jon Black To: "JP Vasseur \(jvasseur\)" In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772204AED7@xmb-rcd-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1725615817-1448048242-1351876062=:61554" Cc: "manet@ietf.org List" Subject: Re: [manet] LOADng works X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:07:58 -0000 ---1725615817-1448048242-1351876062=:61554 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable no - i have a conflict next week deploying a sensor network.=0A=0A=0A=0A=0A= ________________________________=0A From: JP Vasseur (jvasseur) =0ATo: Jon Black =0ACc: "manet@ietf.org Li= st" =0ASent: Friday, November 2, 2012 2:47 AM=0ASubject: R= e: [manet] LOADng works=0A =0A=0ADear Jon, =0A=0Awill you be at the next IE= TF meeting in MANET WG so that we can have a technical discussion ?=0A=0ATh= anks.=0A=0AJP.=0A=0AOn Nov 2, 2012, at 4:17 AM, JP Vasseur (jvasseur) wrote= :=0A=0AHi Jon, =0A>=0A>=0A>On Nov 1, 2012, at 11:51 PM, Jon Black wrote:=0A= >=0A>In line [Jon2]=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>_____________________= ___________=0A>> From: JP Vasseur (jvasseur) =0A>>To: J= on Black =0A>>Cc: "manet@ietf.org" = =0A>>Sent: Thursday, November 1, 2012 12:33 PM=0A>>Subject: Re: [manet] LO= ADng works=0A>>=0A>>=0A>>Hi Jon, =0A>>=0A>>=0A>>In line - JP2>=0A>>=0A>>=0A= >>On Nov 1, 2012, at 4:32 PM, Jon Black wrote:=0A>>=0A>>=0A>>>=0A>>>=0A>>>= =0A>>>=0A>>>________________________________=0A>>> From: JP Vasseur (jvasse= ur) =0A>>>To: Jon Black =0A>>>C= c: "manet@ietf.org" ; "thierry.lys@erdfdistribution.fr" =0A>>>Sent: Thursday, November 1, 2012 3:41 = AM=0A>>>Subject: Re: [manet] (no subject)=0A>>>=0A>>>=0A>>>Hi Jon, =0A>>>= =0A>>>=0A>>>On Nov 1, 2012, at 12:39 AM, Jon Black wrote:=0A>>>=0A>>>Yes it= shows that it does work in a rather large deployment.=C2=A0 =0A>>>=0A>>>= =0A>>>JP> This is not just a question of "how large" it is =E2=80=A6 but al= so how dynamic. I could show you few hundreds (if not less number of nodes)= =0A>>>not working if the traffic pattern is too dynamic. This is a fundamen= tal problem.=0A>>>=0A>>>[Jon] Are you saying that their AMI PLC deployment = was not dynamic?=0A>>>=0A>>=0A>>=0A>>JP2> We do not have any details so I c= annot comment on *that* deployment; my point was that you can easily show w= hy the number=0A>>of nodes is NOT the only issues with reactive routing pro= tocols in LLNs. Take actual traces (which I personally did with actual depl= oyed=0A>>networks) and simulate the control plane traffic with moderate use= traffic demand and you will see the issue with such routing approach.=0A>>= In other words, even with a relatively small number of nodes, in contrast w= ith other proactive routing protocols, if the user traffic is moderate=0A>>= (not even very high), you clearly see why this reactive routing is ill suit= ed to LLNs.=0A>>=0A>>[Jon2] There are plenty of well working LLNs that use = reactive protocols such as AODV.=C2=A0 I've built and deployed them so perh= aps you can't but I can and the protocol and network work well.=C2=A0 It de= pends on the type of traffic, nodes, radio, ...=C2=A0 To say that you=0A ca= n only build a working LLN using a proactive protocol is just plain foolish= .=0A>>=0A>=0A>=0A>JP2> Let's try to be gentle and respectful. If you have b= uilt such networks, feel free to share; But this is certainly not the concl= usion the ROLL=0A>WG shared after 4 years of work.=0A>=0A>=0A>>=0A>>=0A>>>= =0A>>>I have heard others say that it works in other deployments as well - = just the same as you say RPL works in some deployments.=0A>>>>=0A>>>>=0A>>>= =0A>>>=0A>>>JP> I do not not think that we should go in a RPL versus Load-N= G debate but rather try to find a good solution for MANET. That being=0A>>>= said, RPL *for* LLNs the the result of a 4-year work with a DT, weekly call= s, interim WG meetings to make it work in LLNs.=0A>>>=0A>>>[Jon] I did not = cast this as a RPL vs LOADng debate - you just did.=C2=A0 I am saying that = LOADng works in some scenarios and proof is the EDF deployment in their AMI= network.=0A>>>=0A>>=0A>>=0A>>JP2> I would be happy to see detailed results= and especially the user traffic profiles for the reason exposed above.=0A>= >=0A>>[Jon2] JP actually it doesn't matter!=C2=A0 You say that you CANNOT b= uild a working LLN using a reactive protocol.=C2=A0 EDF has proved that wro= ng.=C2=A0 They built one.=C2=A0 You can continue to claim that you can't, b= ut there is an existence proof.=0A>>=0A>=0A>=0A>JP3> You keep ignoring my p= oint. Of it matters. I would even make it work with BGP-4. Would you recomm= end the use of BGP in LLN ?=0A>If you deploy a protocol in very specific co= nditions that do not apply to most LLNs, then you may want to know it befor= e making it an RFC.=0A>=0A>=0A>>=0A>>=0A>>>=0A>>>Please share your results.= =C2=A0 You keeps saying you will and you we keep asking you to - where's th= e results so they can be reviewed.=0A>>>>=0A>>>>=0A>>>>=0A>>>=0A>>>=0A>>>JP= > Once again, I would first like to hear chair's decision. PLEASE note that= I would be happy to see Load's results too. And just be=0A>>>patient, I ju= st need to find a bit of time to compile results and you will get many resu= lts backing up my claims. Please also refer to the=0A>>>number of discussio= ns prior to designing RPL that took place on the ROLL mailing list. Believe= me there was a reason not NOT choosing=0A>>>a reactive protocol for LLN (a= gain I am NOT against reactive routing for other use cases at all). Would y= ou ignore the findings of a WG=0A>>>that worked for 4 years on the subject = matter ? I guess not =E2=80=A6 Just trying to raise my voice (as many other= s on this list) to protect the=0A>>>Internet.=0A>>>=0A>>>[Jon] As others ha= ve said - you have it backwards.=C2=A0 If you have data that would show tha= t LOADng or a reactive protocol will not work in MANETs please share it.=C2= =A0=0A>>=0A>>=0A>>JP2> Please reread what I wrote ten times =E2=80=A6 I sai= d "LLNs" not "MANET" in general. On top of that, I do prefer the option 1) = for the reasons exposed=C2=A0=0A>>before (this is the WG document, Charlie = made it compatible + other technical reasons).=0A>>=0A>>You did say LLNs bu= t again you are wrong.=C2=A0 There are plenty of LLNS that have been built = using reactive (and proactive) protocols and will continue to be built usin= g reactive (and proactive protocols).=C2=A0 There is no one size fits all.= =0A>>=0A>>I prefer to have a debate based on facts and not conjecture and b= ased on technical arguments. =0A>>=0A>>=0A>>That would be=0A>>>very insight= ful and would help guide this discussion and decision.=C2=A0 It would not b= e prudent to make a decision and then bring out data that would try to sugg= est that the decision was incorrect.=0A>>>=0A>>>What findings are you refer= ring to?=C2=A0 Where is there a WG document that documents these findings?= =0A>>>=0A>>>=0A[Jon2] I noticed you skipped this.=C2=A0 =0A>>=0A>=0A>=0A>JP= 3> I do not skip anything. I am respectful of the question asked by the cha= ir, knowing that their task is to say the least not easy.=0A>As soon as req= uired, I will provide lots of data, at least the ones that can be shared, i= f authorization is given by the owners of these=0A>networks.=0A>=0A>=C2=A0= =0A>>=0A>>=0A>>>=0A>>>Thanks.=0A>>>=0A>>>=0A>>>JP.=0A>>>=0A>>>Jon=0A>>>>=0A= >>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>________________________________=0A>>>> Fro= m: JP Vasseur (jvasseur) =0A>>>>To: Jon Black =0A>>>>Cc: "manet@ietf.org" ; "thierry.lys@e= rdfdistribution.fr" =0A>>>>Sent: Wednesda= y, October 31, 2012 4:09 PM=0A>>>>Subject: Re: [manet] (no subject)=0A>>>>= =0A>>>>=0A>>>>=0A>>>>=0A>>>>On Oct 31, 2012, at 6:57 PM, Jon Black wrote:= =0A>>>>=0A>>>>On October 31, 2012 Thierry.Lys wrote:=0A>>>>>=0A>>>>>=0A>>>>= >I speak in the name of EDF group. =0A>>>>>=0A>>>>>We started first to use = LOAD as a routing algorithm and deployed 2000 PLC-meters for smart grid pur= poses in 2011. Taking advantage of this field test, we have been actively p= articipating to the working group to adopt enhancements in the LOADng speci= fication. =0A>>>>>We are now extremely pleased with what LOADng is capable = of and are confident that future deployements will be equipped with it.=C2= =A0=0A>>>>>=0A>>>>>=0A>>>>>This would seem to indicate that LOADng does wor= k and in a rather large deployment.=0A>>>>>=0A>>>>=0A>>>>=0A>>>>JP> No this= means that LoadNG works in *a* network. But the major technical difference= here is that reactive routing is highly impacted=0A>>>>by the user traffic= =E2=80=A6 If you poll a meter every 24 hours, it may work perfectly well. = Now if you start having more frequent traffic flows=0A>>>>you can either ca= che paths (ending up with more frequent broken paths considering how flappy= these networks are, thus leading to more=0A>>>>floods =E2=80=A6 very undes= irable =E2=80=A6 especially when you have hundreds of meters sharing a few = Kbits/s) or you use short cache timers and you=0A>>>>keep flooding :-( If y= ou take actual traces of these networks (both using 15.4g and P1901.2) and = you start adjusting the user traffic rate you=0A>>>>immediately see the iss= ues in terms of scalability. Yes you can try to mitigate the undesirable fl= ooding effect to some extends but showing=C2=A0=0A>>>>the limits in terms o= f scalability is easy to show. Note that I MOT against reactive routing by = any means, this is IMO just not applicable to=0A>>>>LLNs unless the traffic= flows are deterministic and very well knows =E2=80=A6 Lessons from the pas= t show us how difficult it is to predict user=C2=A0=0A>>>>applications. We = all started with meter reading to continue with that example and now many u= tilities wants to use these smart metering=C2=A0=0A>>>>networks for a numbe= r of applications which different SLA, =E2=80=A6=C2=A0=0A>>>>=0A>>>>=0A>>>>= Hope this helps. Once again, when/if required I would be happy to share man= y results.=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>>"We believe in rough consensu= s and running code" =0A>>>>>=0A>>>>>rough consensus : Don't you think we ha= ve a rough consensus on LOADng compared to DYMO ? 10 authors and major comp= anies are supporters of LOADng. =0A>>>>>=0A>>>>>running code : interoperabi= lity has been checked with 4 sources and other implementations are in progr= ess. =0A>>>>>=0A>>>>>Obviously from the list we don't have rough consensus.= =C2=A0 We have two alternatives each with proponents.=C2=A0 The WG should w= eigh the technical benefits (design, implementation/running code, maturity)= =C2=A0 of each and the group should choose a path forward.=0A>>>>>=0A>>>>>I= n my opinion option 3 is not an option - this is the working group shirking= its responsibility.=0A>>>>>=0A>>>>=0A>>>>=0A>>>>This is an option =E2=80= =A6 since listed by the chairs. I agree that we should avoid it, especially= when I think we have a very reasonable solution=0A>>>>(option1).=0A>>>>=0A= >>>>=0A>>>>JP.=0A>>>>=0A>>>>=0A>>>>>Jon=0A>>>>> =0A>>>>>=0A>>>>>=0A________= _______________________________________=0A>>>>>manet mailing list=0A>>>>>ma= net@ietf.org=0A>>>>>https://www.ietf.org/mailman/listinfo/manet=0A>>>>>=0A>= >>>=0A>>>>=0A>>>>=0A>>>=0A>>>=0A>>>=0A_____________________________________= __________=0A>>>manet mailing list=0A>>>manet@ietf.org=0A>>>https://www.iet= f.org/mailman/listinfo/manet=0A>>>=0A>>=0A>>=0A>>=0A>=0A___________________= ____________________________=0A>manet mailing list=0A>manet@ietf.org=0A>htt= ps://www.ietf.org/mailman/listinfo/manet=0A> ---1725615817-1448048242-1351876062=:61554 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
no - i hav= e a conflict next week deploying a sensor network.

=
From: JP Vasseur (jvasseur) <jvasseur@cisco.com&g= t;
To: Jon Black <j= black.ietf@yahoo.com>
Cc: "manet@ietf.org List" <manet@ietf.org>
Sent: Friday, November 2, 2012 2:47 AM
<= b>Subject: Re: [manet] LOADng= works

=0A
=0A=0A =0A=0A
=0ADear Jon,=0A
=0A
=0A
will you be at the next IETF meeting in MANET WG so that= we can have a technical discussion ?
=0A

=0A
=0A
Tha= nks.
=0A

=0A
=0A
JP.
=0A

=0A
=0A=0A
=0A
On Nov 2, 2012, at 4:17 AM, JP Vasseur (jvasseur) wrote:<= /div>=0A
=0A=0A
=0AHi Jon,=0A
=0A
=0A
On Nov 1, 2012, at 11:51 PM, Jon Black wrote:
=0A=0A
=0A
=0A
=0AIn line [Jon2]
=0A

=0A
=0A

= =0A
=0A
=0A
=0A
=0A
=0AFrom: JP Vasseur (jvasseur) <jvass= eur@cisco.com>
=0ATo:= Jon Black <jblack.ietf@ya= hoo.com>=0A
=0ACc: "manet@ietf.org" <manet@ietf.org>=0A
=0ASent: Thursday, November 1, 2012 12:33 PM
=0ASubject: Re: [manet] LOADng works
=0A<= /font>
=0A
=0A =0A
=0A
Hi Jon,=0A
=
=0A
=0A
In line - JP2>
=0A

=0A
=0A
On = Nov 1, 2012, at 4:32 PM, Jon Black wrote:
=0A
=0A
=0A
=0A
=0A
<= br>=0A
=0A
=0A

=0A
=0A
=0A
=0A
=0A
=0AFrom: JP Vasseu= r (jvasseur) <jvasseur@cisco.com= >
=0ATo: Jon Black &l= t;jblack.ietf@yahoo.com>= =0A
=0ACc: "manet@ietf.org" <manet@i= etf.org>;=0A "thierry.lys@erdfdistribution.fr" <thierry.lys@erdfdistribution.fr>= =0A
=0ASent: Thursday, N= ovember 1, 2012 3:41 AM
=0ASubject:= Re: [manet] (no subject)
=0A
=0A
=0A
=0A
Hi Jon,=0A

=0A
=0A
On Nov 1, 201= 2, at 12:39 AM, Jon Black wrote:
=0A
=0A
=0A
=0A
=0A
Yes it sho= ws that it does work in a rather large deployment. 
=0A=0A
=0A
=0A

=0A
=0A
JP> This is no= t just a question of "how large" it is =E2=80=A6 but also how dynamic. I co= uld show you few hundreds (if not less number of nodes)
=0A
not wo= rking if the traffic pattern is too dynamic. This is a fundamental problem.=
=0A
=0A[Jon] Are you saying that their AMI PLC deployment was not dy= namic?
=0A
=0A
=0A
=0A
=0A
=0A
=0A
= =0A
=0A
=0A
=0A

=0A
=0A
JP2> We d= o not have any details so I cannot comment on *that* deployment; my point w= as that you can easily show why the number
=0A
of nodes is NOT the= only issues with reactive routing protocols in LLNs. Take actual traces (w= hich I personally did with actual deployed
=0A
networks) and simul= ate the control plane traffic with moderate use traffic demand and you will= see the issue with such routing approach.
=0A
In other words, eve= n with a relatively small number of nodes, in contrast with other proactive= routing protocols, if the user traffic is moderate
=0A
(not even = very high), you clearly see why this reactive routing is ill suited to LLNs= .
=0A
=0A[Jon2] There are plenty of well working LLNs that use reacti= ve protocols such as AODV.  I've built and deployed them so perhaps yo= u can't but I can and the protocol and network work well.  It depends = on the type of traffic, nodes, radio, ...  To say that you=0A can only= build a working LLN using a proactive protocol is just plain foolish.
= =0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=
=0A
=0A

=0A
=0A
JP2> Let's try to be = gentle and respectful. If you have built such networks, feel free to share;= But this is certainly not the conclusion the ROLL
=0A
WG shared a= fter 4 years of work.
=0A
=0A
=0A
=0A<= div style=3D"color:rgb(0, 0, 0);background-color:rgb(255, 255, 255);font-fa= mily:'times new roman', 'new york', times, serif;font-size:12pt;">=0A
=0A
=0A
=0A
=0A

=0A=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A

=0A
=0A
=0A=0A
I have heard others say that it works in other deployments as well - just= the same as you say RPL works in some deployments.
=0A
=0A
= =0A
=0A
=0A
=0A
=0A

=0A
=0A
JP&= gt; I do not not think that we should go in a RPL versus Load-NG debate but= rather try to find a good solution for MANET. That being
=0A
said= , RPL *for* LLNs the the result of a 4-year work with a DT, weekly calls, i= nterim WG meetings to make it work in LLNs.
=0A
=0A[Jon] I did not ca= st this as a RPL vs LOADng debate - you just did.  I am saying that LO= ADng works in some scenarios and proof is the EDF deployment in their AMI n= etwork.
=0A
=0A
=0A
=0A
=0A
=0A
=0A
= =0A
=0A
=0A=0A

=0A
=0A
JP2> I wo= uld be happy to see detailed results and especially the user traffic profil= es for the reason exposed above.
=0A
=0A[Jon2] JP actually it doesn't= matter!  You say that you CANNOT build a working LLN using a reactive= protocol.  EDF has proved that wrong.  They built one.  You= can continue to claim that you can't, but there is an existence proof.
= =0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=


From: JP Vasseur (jvasseur) <jvass= eur@cisco.com>
To: = Jon Black <jblack.ietf@yahoo.com>
Cc: "manet@ietf.org" <manet@ietf.org>; "thierry.lys= @erdfdistribution.fr" <thierry.lys@erdfdistribution.fr>
Sent: Thursday, November 1, 2012 3= :41 AM
Subject: Re: [m= anet] (no subject)

=0A
=0A=0A =0A=0A
=0AHi Jon,= =0A

=0A
=0A
On Nov 1, 2012, at 12:39 AM, Jon Black wrote:=0A
=0A
=0A
=0A
=0A
Yes it shows that it does work in a rather la= rge deployment. 
=0A
=0A
=0A
=0A
=0A
=0A
JP> This is not just a question of "how large" it= is =E2=80=A6 but also how dynamic. I could show you few hundreds (if not l= ess number of nodes)
=0A
not working if the traffic pattern is too= dynamic. This is a fundamental problem.

[Jon] Are you saying that t= heir AMI PLC deployment was not dynamic?
=0A
=0A
=0A
=0A
=0A
I have heard others say that it works in other = deployments as well - just the same as you say RPL works in some deployment= s.
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=
=0A
=0A
JP> I do not not think that we should go in a RPL v= ersus Load-NG debate but rather try to find a good solution for MANET. That= being
=0A
said, RPL *for* LLNs the the result of a 4-year work wi= th a DT, weekly calls, interim WG meetings to make it work in LLNs.

= [Jon] I did not cast this as a RPL vs LOADng debate - you just did.  I= am saying that LOADng works in some scenarios and proof is the EDF deploym= ent in their AMI network.
=0A
=0A
=0A<= div>=0A
= =0A
=0APlease share your results.  You kee= ps saying you will and you we keep asking you to - where's the results so t= hey can be reviewed.
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A

=0A
=0A
JP> Once again, I would fi= rst like to hear chair's decision. PLEASE note that I would be happy to see= Load's results too. And just be
=0A
patient, I just need to find = a bit of time to compile results and you will get many results backing up m= y claims. Please also refer to the
=0A
number of discussions prior= to designing RPL that took place on the ROLL mailing list. Believe me ther= e was a reason not NOT choosing
=0A
a reactive protocol for LLN (a= gain I am NOT against reactive routing for other use cases at all). Would y= ou ignore the findings of a WG
=0A
that worked for 4 years on the = subject matter ? I guess not =E2=80=A6 Just trying to raise my voice (as ma= ny others on this list) to protect the
=0A
Internet.

[Jon] = As others have said - you have it backwards.  If you have data that wo= uld show that LOADng or a reactive protocol will not work in MANETs please = share it.  That would be
very insightful and would help guide this = discussion and decision.  It would not be prudent to make a decision a= nd then bring out data that would try to suggest that the decision was inco= rrect.

What findings are you referring to?  Where is there a WG= document that documents these findings?
=0A

=0A
=0A=
Thanks.
=0A

=0A
=0A
JP.
=0A
=0A=0A
=0A
=0A
=0A
=0A
=0AJon
=0A<= div style=3D"color:rgb(0, 0, 0);font-size:16px;font-family:times new roman,= new york, times, serif;background-color:transparent;font-style:normal;">= =0A
=0A
=0A

=0A
=0A
=0A
= =0A
=0A
=0AFrom: JP Vasseur (jvasseur) &= lt;jvasseur@cisco.com>
=0A= To: Jon Black <jblack.ietf@yahoo.com>=0A
=0ACc: "manet@ietf.org" <manet@ietf.org>= ; "thierry.ly= s@erdfdistribution.fr" <thierry.lys@erdfdistribution.fr>=0A
=0ASent: Wednesday, October 31, 2012 4= :09 PM
=0ASubject: Re: [= manet] (no subject)
=0A
=0A
=0A =0A
=0A

=0A
=0A
On Oct 31, 2012, at 6:57 PM, Jon Black wrote= :
=0A
=0A=0A
=0A
=0A
On October 31, 2012 Thierry.Lys wrote:
=0A<= div>
=0A
=0A
=0AI speak in the name of EDF group.
=0A
=0AWe started first to use LOAD as a routing algorithm and d= eployed 2000 PLC-meters for smart grid purposes in 2011. Taking advantage o= f this field test, we have been actively participating to the working group= to adopt enhancements=0A in the LOADng specification.
=0AWe are now extremely pleased with what LOADn= g is capable of and are confident that future deployements will be equipped= with it. 
=0A
=0A
=0A
=0A
=0AThis would seem to indicate that LOADng does work and in a rather= large deployment.
=0A
=0A
=0A
=0A=0A
=0A
=0A
JP> No this means that LoadNG works in *a* network. B= ut the major technical difference here is that reactive routing is highly i= mpacted
=0A
by the user traffic =E2=80=A6 If you poll a meter ever= y 24 hours, it may work perfectly well. Now if you start having more freque= nt traffic flows
=0A
you can either cache paths (ending up with mo= re frequent broken paths considering how flappy these networks are, thus le= ading to more
=0A
floods =E2=80=A6 very undesirable =E2=80=A6 espe= cially when you have hundreds of meters sharing a few Kbits/s) or you use s= hort cache timers and you
=0A
keep flooding :-( If you take actual= traces of these networks (both using 15.4g and P1901.2) and you start adju= sting the user traffic rate you
=0A
immediately see the issues in = terms of scalability. Yes you can try to mitigate the undesirable flooding = effect to some extends but showing 
=0A
the limits in terms o= f scalability is easy to show. Note that I MOT against reactive routing by = any means, this is IMO just not applicable to
=0A
LLNs unless the = traffic flows are deterministic and very well knows =E2=80=A6 Lessons from = the past show us how difficult it is to predict user 
=0A
app= lications. We all started with meter reading to continue with that example = and now many utilities wants to use these smart metering 
=0Anetworks for a number of applications which different SLA, =E2=80=A6 =
=0A

=0A
=0A
Hope this helps. Once again, when/if req= uired I would be happy to share many results.
=0A

=0A
=0A=
=0A
=0A
=0A
=0A
=0A
=0A"W= e believe in rough consensus and running code"=0A
=0A
=0Arough consensus : Don't you think we have a= rough consensus on LOADng compared to DYMO ? 10 authors and major companie= s are supporters of LOADng.=0A
=0A
=0Arunning code : interoperability has been checked with 4 source= s and other implementations are in progress.=0A
=0A
=0A
= =0AObviously from the list we don't= have rough consensus.  We have two alternatives each with proponents.=   The WG should weigh the technical benefits (design, implementation/r= unning code, maturity)  of each and the group should=0A choose a path = forward.
=0A
=0AIn my opinion option 3 is not an option - this is the= working group shirking its responsibility.
=0A
=0A
=0A=
=0A

=0A
=0A
This is an option =E2=80=A6 since= listed by the chairs. I agree that we should avoid it, especially when I t= hink we have a very reasonable solution
=0A
(option1).
=0A
=0A
=0A
JP.
=0A
=0A
=0A=0A
=0A<= span style=3D"font-family:sans-serif;">
=0AJon
=0A=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A___= ____________________________________________
=0Amanet mailing list
= =0Amanet@ietf.org
=0Ahtt= ps://www.ietf.org/mailman/listinfo/manet
=0A=0A
= =0A
=0A
=0A
=0A =0A
=0A
=0A
=0A
=0A
=0A=0A=0A
=0A
=0A