[manet] Re: Extended: Call for adoption: draft-templin-m anet-inet-05
Lou Berger <[email protected]> Thu, 23 Jul 2026 23:33:10 +0200
| Newsgroups | gmane.ietf.manet |
|---|---|
| Message-ID | <[email protected]> |
--===============7216452380452756243== Content-Type: multipart/alternative; boundary="------------dwsfia06jp9ckM2a04FuYo7A" Content-Language: en-US --------------dwsfia06jp9ckM2a04FuYo7A Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Fred, See inline below -- also for ref I'll use draft-ietf-manet-inet-gap-analysis-03 <https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03> assuming it is the same as the PDF you sent to the list... On 7/22/2026 12:34 PM, Templin (US), Fred L wrote: > Hi Lou, > >> -----Original Message----- >> From: Lou Berger<[email protected]> >> Sent: Wednesday, July 22, 2026 3:17 AM >> To: Templin (US), Fred L<[email protected]>; Donald Eastlake<[email protected]>; manet<[email protected]> >> Cc: Mobile Ad-hoc Networks Working Group<[email protected]>;[email protected] >> Subject: Re: [manet] Re: Extended: Call for adoption: draft-templin-manet-inet-05 >> >> Hi Fred, >> >> [in an attempt to revive this discussion...] >> >> On 5/26/2026 3:39 PM, Templin (US), Fred L wrote: >>> Lou, please excuse the delayed response and see below for replies to your comments: >>> >>>> -----Original Message----- >>>> From: Lou Berger<[email protected]> >>>> ... >>>> This said,I do not think the document is clear on the motivation or use >>>> case(s) that necessitates the need for a global MANET overlay, the use >>>> of virtual overlays between MANETs, or if such are required why such >>>> overlay links are unique to MANETs . Said another way, once a MANET is >>>> connected to the Internet is there anything that is uniquely observable >>>> (at the IP layer) outside the MANET. I think this >>>> assumption/architecture should be fully flushed out and agreed upon >>>> prior to this work being submitted for publication. >>> A MANET should be considered as a mobile network that is either >>> disconnected from the global Internetwork or only intermittently connected >>> to the global Internetwork with the ability to move rapidly between different >>> Internetwork attachment points. Due to the dynamic multilink nature of MANETs, >>> most do not attempt to represent themselves as a single logical IP subnet to >>> the outside world meaning that each MANET node may configure a distinct >>> mobile network prefix unique to itself. >> I think this is justification for >> https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#name-problem-1-manet-local-addre > OK - are you suggesting any changes? If this text exists in the document or a reference used by the document, then no. If it does not, then sounds like it should be. > >>> So, when the MANET Internetwork >>> attachment point changes, without an overlay it would require a large >>> number of prefix advertisements and withdrawals in the global BGP routing >>> system for every change. With an overlay, no churn is seen in the global >>> BGP routing system as only the Internetwork attachment points appear >>> there while the mobile network prefixes are managed in the overlay. >> A global overlay may be one solution - another is simply to combine2 >> instance of standard manet to Internet interworking >> (https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#name-problem-4-manet-peer-to-int) >> . This is generally what's done in the rest of the Internet (consider >> an enterprise network, with it's own "VPN" overlay and multiple >> attachment points to the Internet for both clients and servers). >> >> Independent of our discussion here, I don't see a discussion in the >> latest draft justifying the MANET-specific overlay approach. > The discussion appears in the introduction and throughout the problem statements. > Much of the discussion was added in response to your previous set of comments. For me the design choice of a global overly is so significant it should be covered explicitly. to be clear, the following text A widely-accepted axiom at the time of this writing suggests that there are more cellphones than people on the planet[STATISTA <https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#STATISTA>]. According to Wikipedia, the world population reached 8 billion in 2022 and is expected to reach 10 billion by 2056[WIKI <https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#WIKI>]. Each mobile node that connects to the global public Internet can in some sense be regarded as a singleton "MANET" with the potential to connect still larger MANETs. MANET Internetworking therefore regards the global Internet as a "network of (mobile ad-hoc) networks" with unrestricted dynamic relationships between distinct MANET local routing regions joined by a Non-Broadcast Multiple Access (NBMA) virtual overlay link manifested through encapsulation.Figure 1 <https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#manet-inet>illustrates an example of 2 distinct MANET local routing regions connected via the NBMA overlay using the Internet as transit: .-(::::::::) .-(::: Global ::)-. X==+======(===================)======+==X | `-(: Internet :)-' | | `-(::::::)-' | | | .-(::::::::) .-(::::::::) .-(::::::::::::)-. .-(::::::::::::)-. (::::: MANET 1 :::::) (::::: MANET 2 :::::) `-(::::::::::::)-' `-(::::::::::::)-' `-(::::::)-' `-(::::::)-' Figure 1 <https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#figure-1>:MANET Internetworking <https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#name-manet-internetworking> While the figure depicts just 2 MANET local routing regions, many others worldwide will also want to connect to the virtual link. Since a sustained increase in both the world population and number of mobile wireless devices is certain, MANET Internetworking must therefore accommodate populations on the order of O(10**10) or more. This includes address duplication avoidance through operational assurance since statistical properties alone may be insufficient to avoid duplication in such large populations. appears to be used to justify the global overlay, but to me it does the opposite, i.e. why would we want an overlay that accommodates O(10**10) or more vs just using the standard Internet. > >>> Another motivation for an overlay that is not yet addressed in the >>> document is seamless support for MANET nodes with multiple >>> interfaces. A natural reaction is to dismiss this as a corner case >> I agree that this is an important use case to consider in the problem >> statement. I note that the document introduces this concept in Gap 1 >> and not as it's own problem statement. > Yes, it is listed as a gap that needs to be addressed by solution proposals. a gap for which of the problem statements? I suspect you are missing one and it should be added. (IMO you can't have a gap without a defined problem, do you see it differently?) > >>> until >>> one considers that vast number of cellphones worldwide have >>> multiple interfaces (cellular, Wi-Fi, bluetooth, and in some cases >>> even SATCOM) where at least the cellular and Wi-Fi can be seen >>> as candidate MANET interfaces when disconnected from or >>> intermittently connected to infrastructure. >> This line of argument does *not* resonate with me as we already have a >> very scalable solution that is widely deployed, and that earlier >> attempts at MANETs on cell phones (I'll need to dig a bit on where this >> was discussed at the IETF, many years ago) didn't really pan out due to >> battery consumption. > Modern cellphones have both WiFi and 5G interfaces. WiFi can already run > in "ad-hoc" mode (for some flavor of "ad-hoc") and 3GPP is standardizing > SideLink mode for 5G. The cellphone can therefore become be a MANET > router to do multihop forwarding device-to-device when outside the > context of cellular and/or WiFi infrastructure. Battery consumption is > not an issue when the cellphone is connected to a power source such > as when used inside of a vehicle. Even in dismounted scenarios, however, > having a (limited-duration) multi-hop communications capability may be > deemed worthwhile and could provide a safety-of-life capability such as > for emergency response / disaster relief events. For these reasons, I believe > the modern cellphone (of which there are billions worldwide) will become > an important MANET router platform. Where is this discussed in the document? If it isn't then I think it should be covered in a problem statement. > >> I heard you make a related comment just now at the mic that is not >> evident (at least to me) in the document -- I think it would be good to >> expand on your thoughts on this and make sure that the concepts are >> covered in the document. > Does the above help? (covered by previous response.) > >>> An overlay interface >>> configured over the MANET interfaces can then be used to >>> orchestrate communications using a singular IP address that >>> identifies the node as opposed to a distinct IP address for each >>> MANET interface. >> Heretoo, this is something that is commonly done in non-manet networks >> without requiring a new global overlay. > This is referring to a capability sometimes termed "multilink". It allows for > carrying some packet flows over link "A" and others over links "B", "C", etc. > but all using the same IP address in the overlay. Multilink is useful for > fault tolerance, load balancing, matching flows to appropriate link > performance profiles, cost optimization, etc. This is not unique to manets and is not generally solved using an overlay., >>>> Another topic that >>>> I think needs to be better explored is the implicit role of DNS ( is >>>> it required or optional, is there complete definition, does it belong in >>>> this document). >>> Agreed and we can expand on the discussion surrounding the DNS. >> I don't see this discussion in the current document, perhaps the >> document needs another section on assumptions/presumed architecture and >> rationale for such. > The document already does discuss expectations of the DNS service in several > places. I think going into a deeper discussion of the DNS architecture would be > subject for a different document. Do you see providing "the global DNS which returns a (stable) globally-routable IP address for the [mobile] correspondent." to be a solved problem? If so can you add a reference to the solution to the document? If not, I think it should be called out as its own problem. > >>>> I think these issue can be worked before or after document adoption. In >>>> either case, I support having the WG discuss the topics represented in >>>> the draft. >>> Thank you for bringing this discussion forward! >> Thank you! >> >> Lou > > Thanks - Fred Thanks! Lou --------------dwsfia06jp9ckM2a04FuYo7A Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html><html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> <p>Fred, </p> <p>See inline below -- also for ref I'll use <a href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03">draft-ietf-manet-inet-gap-analysis-03</a> assuming it is the same as the PDF you sent to the list...</p> <div class="moz-cite-prefix">On 7/22/2026 12:34 PM, Templin (US), Fred L wrote:<br> </div> <blockquote type="cite" cite="mid:BN0P110MB1420B00C41F70313F6B30CD4A3C1A@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <pre wrap="" class="moz-quote-pre">Hi Lou, </pre> <blockquote type="cite"> <pre wrap="" class="moz-quote-pre">-----Original Message----- From: Lou Berger <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> Sent: Wednesday, July 22, 2026 3:17 AM To: Templin (US), Fred L <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>; Donald Eastlake <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>; manet <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> Cc: Mobile Ad-hoc Networks Working Group <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>; <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> Subject: Re: [manet] Re: Extended: Call for adoption: draft-templin-manet-inet-05 Hi Fred, [in an attempt to revive this discussion...] On 5/26/2026 3:39 PM, Templin (US), Fred L wrote: </pre> <blockquote type="cite"> <pre wrap="" class="moz-quote-pre">Lou, please excuse the delayed response and see below for replies to your comments: </pre> <blockquote type="cite"> <pre wrap="" class="moz-quote-pre">-----Original Message----- From: Lou Berger <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> ... This said,I do not think the document is clear on the motivation or use case(s) that necessitates the need for a global MANET overlay, the use of virtual overlays between MANETs, or if such are required why such overlay links are unique to MANETs . Said another way, once a MANET is connected to the Internet is there anything that is uniquely observable (at the IP layer) outside the MANET. I think this assumption/architecture should be fully flushed out and agreed upon prior to this work being submitted for publication. </pre> </blockquote> <pre wrap="" class="moz-quote-pre">A MANET should be considered as a mobile network that is either disconnected from the global Internetwork or only intermittently connected to the global Internetwork with the ability to move rapidly between different Internetwork attachment points. Due to the dynamic multilink nature of MANETs, most do not attempt to represent themselves as a single logical IP subnet to the outside world meaning that each MANET node may configure a distinct mobile network prefix unique to itself. </pre> </blockquote> <pre wrap="" class="moz-quote-pre">I think this is justification for <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#name-problem-1-manet-local-addre">https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#name-problem-1-manet-local-addre</a> </pre> </blockquote> <pre wrap="" class="moz-quote-pre"> OK - are you suggesting any changes?</pre> </blockquote> <p>If this text exists in the document or a reference used by the document, then no. If it does not, then sounds like it should be. </p> <p><br> </p> <blockquote type="cite" cite="mid:BN0P110MB1420B00C41F70313F6B30CD4A3C1A@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <pre wrap="" class="moz-quote-pre"> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="" class="moz-quote-pre">So, when the MANET Internetwork attachment point changes, without an overlay it would require a large number of prefix advertisements and withdrawals in the global BGP routing system for every change. With an overlay, no churn is seen in the global BGP routing system as only the Internetwork attachment points appear there while the mobile network prefixes are managed in the overlay. </pre> </blockquote> <pre wrap="" class="moz-quote-pre"> A global overlay may be one solution - another is simply to combine2 instance of standard manet to Internet interworking (<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#name-problem-4-manet-peer-to-int">https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#name-problem-4-manet-peer-to-int</a>) . This is generally what's done in the rest of the Internet (consider an enterprise network, with it's own "VPN" overlay and multiple attachment points to the Internet for both clients and servers). Independent of our discussion here, I don't see a discussion in the latest draft justifying the MANET-specific overlay approach. </pre> </blockquote> <pre wrap="" class="moz-quote-pre"> The discussion appears in the introduction and throughout the problem statements. Much of the discussion was added in response to your previous set of comments.</pre> </blockquote> <p>For me the design choice of a global overly is so significant it should be covered explicitly. to be clear, the following text</p> <p id="section-1-5" style="box-sizing: border-box; margin: 20.8px 0px 20.8px 3ch; overflow-wrap: break-word; color: rgb(33, 37, 41); font-family: "Noto Sans Mono", SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">A widely-accepted axiom at the time of this writing suggests that there are more cellphones than people on the planet<span> </span><span style="box-sizing: border-box;">[<a href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#STATISTA" class="cite xref" style="box-sizing: border-box; color: rgb(13, 110, 253); text-decoration: underline; hyphens: none; white-space: nowrap;">STATISTA</a>]</span>. According to Wikipedia, the world population reached 8 billion in 2022 and is expected to reach 10 billion by 2056<span> </span><span style="box-sizing: border-box;">[<a href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#WIKI" class="cite xref" style="box-sizing: border-box; color: rgb(13, 110, 253); text-decoration: underline; hyphens: none; white-space: nowrap;">WIKI</a>]</span>. Each mobile node that connects to the global public Internet can in some sense be regarded as a singleton "MANET" with the potential to connect still larger MANETs.</p> <p id="section-1-6" style="box-sizing: border-box; margin: 20.8px 0px 20.8px 3ch; overflow-wrap: break-word; color: rgb(33, 37, 41); font-family: "Noto Sans Mono", SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">MANET Internetworking therefore regards the global Internet as a "network of (mobile ad-hoc) networks" with unrestricted dynamic relationships between distinct MANET local routing regions joined by a Non-Broadcast Multiple Access (NBMA) virtual overlay link manifested through encapsulation.<span> </span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#manet-inet" class="auto internal xref" style="box-sizing: border-box; color: rgb(13, 110, 253); text-decoration: underline; hyphens: none; white-space: nowrap;">Figure 1</a><span> </span>illustrates an example of 2 distinct MANET local routing regions connected via the NBMA overlay using the Internet as transit:</p> <span id="name-manet-internetworking" style="box-sizing: border-box; color: rgb(33, 37, 41); font-family: "Noto Sans Mono", SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"></span> <div id="manet-inet" style="box-sizing: border-box; color: rgb(33, 37, 41); font-family: "Noto Sans Mono", SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"> <figure id="figure-1" style="box-sizing: border-box; margin: 0px;"> <div class="alignLeft art-text artwork" id="section-1-7.1" style="box-sizing: border-box; margin-top: 20.8px; margin-bottom: 20.8px; flex-wrap: nowrap; align-items: end; display: flex;"> <pre style="box-sizing: border-box; font-family: "Noto Sans Mono", SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; font-size: 1em; margin: 0px; display: block; overflow: auto clip; padding: 0px; flex: 0 0 content; max-width: 72ch;"> .-(::::::::) .-(::: Global ::)-. X==+======(===================)======+==X | `-(: Internet :)-' | | `-(::::::)-' | | | .-(::::::::) .-(::::::::) .-(::::::::::::)-. .-(::::::::::::)-. (::::: MANET 1 :::::) (::::: MANET 2 :::::) `-(::::::::::::)-' `-(::::::::::::)-' `-(::::::)-' `-(::::::)-' </pre> </div> <figcaption style="box-sizing: border-box; text-align: center; margin-top: 20.8px;"><a href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#figure-1" class="selfRef" style="box-sizing: border-box; color: inherit; text-decoration: none;">Figure 1</a>:<span> </span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#name-manet-internetworking" class="selfRef" style="box-sizing: border-box; color: inherit; text-decoration: none;">MANET Internetworking</a></figcaption></figure> </div> <p id="section-1-8" style="box-sizing: border-box; margin: 20.8px 0px 20.8px 3ch; overflow-wrap: break-word; color: rgb(33, 37, 41); font-family: "Noto Sans Mono", SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">While the figure depicts just 2 MANET local routing regions, many others worldwide will also want to connect to the virtual link. Since a sustained increase in both the world population and number of mobile wireless devices is certain, MANET Internetworking must therefore accommodate populations on the order of O(10**10) or more. This includes address duplication avoidance through operational assurance since statistical properties alone may be insufficient to avoid duplication in such large populations.</p> <p>appears to be used to justify the global overlay, but to me it does the opposite, i.e. why would we want an overlay that accommodates O(10**10) or more vs just using the standard Internet.</p> <blockquote type="cite" cite="mid:BN0P110MB1420B00C41F70313F6B30CD4A3C1A@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <pre wrap="" class="moz-quote-pre"> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="" class="moz-quote-pre">Another motivation for an overlay that is not yet addressed in the document is seamless support for MANET nodes with multiple interfaces. A natural reaction is to dismiss this as a corner case </pre> </blockquote> <pre wrap="" class="moz-quote-pre">I agree that this is an important use case to consider in the problem statement. I note that the document introduces this concept in Gap 1 and not as it's own problem statement. </pre> </blockquote> <pre wrap="" class="moz-quote-pre"> Yes, it is listed as a gap that needs to be addressed by solution proposals.</pre> </blockquote> <p>a gap for which of the problem statements? I suspect you are missing one and it should be added. (IMO you can't have a gap without a defined problem, do you see it differently?)</p> <p><br> </p> <blockquote type="cite" cite="mid:BN0P110MB1420B00C41F70313F6B30CD4A3C1A@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <pre wrap="" class="moz-quote-pre"> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="" class="moz-quote-pre">until one considers that vast number of cellphones worldwide have multiple interfaces (cellular, Wi-Fi, bluetooth, and in some cases even SATCOM) where at least the cellular and Wi-Fi can be seen as candidate MANET interfaces when disconnected from or intermittently connected to infrastructure. </pre> </blockquote> <pre wrap="" class="moz-quote-pre"> This line of argument does *not* resonate with me as we already have a very scalable solution that is widely deployed, and that earlier attempts at MANETs on cell phones (I'll need to dig a bit on where this was discussed at the IETF, many years ago) didn't really pan out due to battery consumption. </pre> </blockquote> <pre wrap="" class="moz-quote-pre"> Modern cellphones have both WiFi and 5G interfaces. WiFi can already run in "ad-hoc" mode (for some flavor of "ad-hoc") and 3GPP is standardizing SideLink mode for 5G. The cellphone can therefore become be a MANET router to do multihop forwarding device-to-device when outside the context of cellular and/or WiFi infrastructure. Battery consumption is not an issue when the cellphone is connected to a power source such as when used inside of a vehicle. Even in dismounted scenarios, however, having a (limited-duration) multi-hop communications capability may be deemed worthwhile and could provide a safety-of-life capability such as for emergency response / disaster relief events. For these reasons, I believe the modern cellphone (of which there are billions worldwide) will become an important MANET router platform.</pre> </blockquote> <p>Where is this discussed in the document? If it isn't then I think it should be covered in a problem statement.</p> <blockquote type="cite" cite="mid:BN0P110MB1420B00C41F70313F6B30CD4A3C1A@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <pre wrap="" class="moz-quote-pre"> </pre> <blockquote type="cite"> <pre wrap="" class="moz-quote-pre">I heard you make a related comment just now at the mic that is not evident (at least to me) in the document -- I think it would be good to expand on your thoughts on this and make sure that the concepts are covered in the document. </pre> </blockquote> <pre wrap="" class="moz-quote-pre"> Does the above help?</pre> </blockquote> <p>(covered by previous response.)</p> <p><br> </p> <blockquote type="cite" cite="mid:BN0P110MB1420B00C41F70313F6B30CD4A3C1A@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <pre wrap="" class="moz-quote-pre"> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="" class="moz-quote-pre">An overlay interface configured over the MANET interfaces can then be used to orchestrate communications using a singular IP address that identifies the node as opposed to a distinct IP address for each MANET interface. </pre> </blockquote> <pre wrap="" class="moz-quote-pre"> Heretoo, this is something that is commonly done in non-manet networks without requiring a new global overlay. </pre> </blockquote> <pre wrap="" class="moz-quote-pre"> This is referring to a capability sometimes termed "multilink". It allows for carrying some packet flows over link "A" and others over links "B", "C", etc. but all using the same IP address in the overlay. Multilink is useful for fault tolerance, load balancing, matching flows to appropriate link performance profiles, cost optimization, etc.</pre> </blockquote> <p>This is not unique to manets and is not generally solved using an overlay.,</p> <blockquote type="cite" cite="mid:BN0P110MB1420B00C41F70313F6B30CD4A3C1A@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="" class="moz-quote-pre">Another topic that I think needs to be better explored is the implicit role of DNS ( is it required or optional, is there complete definition, does it belong in this document). </pre> </blockquote> <pre wrap="" class="moz-quote-pre">Agreed and we can expand on the discussion surrounding the DNS. </pre> </blockquote> <pre wrap="" class="moz-quote-pre"> I don't see this discussion in the current document, perhaps the document needs another section on assumptions/presumed architecture and rationale for such. </pre> </blockquote> <pre wrap="" class="moz-quote-pre"> The document already does discuss expectations of the DNS service in several places. I think going into a deeper discussion of the DNS architecture would be subject for a different document. </pre> </blockquote> <p>Do you see providing "the global DNS which returns a (stable) globally-routable IP address for the [mobile] correspondent." to be a solved problem? If so can you add a reference to the solution to the document? If not, I think it should be called out as its own problem.</p> <p><br> </p> <blockquote type="cite" cite="mid:BN0P110MB1420B00C41F70313F6B30CD4A3C1A@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <pre wrap="" class="moz-quote-pre"> </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="" class="moz-quote-pre">I think these issue can be worked before or after document adoption. In either case, I support having the WG discuss the topics represented in the draft. </pre> </blockquote> <pre wrap="" class="moz-quote-pre">Thank you for bringing this discussion forward! </pre> </blockquote> <pre wrap="" class="moz-quote-pre"> Thank you! Lou </pre> </blockquote> <pre wrap="" class="moz-quote-pre"> Thanks - Fred </pre> </blockquote> <p>Thanks!</p> <p>Lou</p> </body> </html> --------------dwsfia06jp9ckM2a04FuYo7A-- --===============7216452380452756243== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWFuZXQgbWFp bGluZyBsaXN0IC0tIG1hbmV0QGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gbWFuZXQtbGVhdmVAaWV0Zi5vcmcK --===============7216452380452756243==--