[manet] Re: [EXTERNAL] Re: Re: Extended: Call for adoption: draft-templin-manet-inet-05
Lou Berger <[email protected]> Mon, 27 Jul 2026 18:35:37 +0200
| Newsgroups | gmane.ietf.manet |
|---|---|
| Message-ID | <[email protected]> |
--===============6022611781090166674== Content-Type: multipart/alternative; boundary="------------PH8KulTCxiq7uYFgGEkVbqUz" Content-Language: en-US --------------PH8KulTCxiq7uYFgGEkVbqUz Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Fred, See in-line below. On 7/24/2026 10:52 AM, Templin (US), Fred L wrote: > > Hello Lou, follow-ups below: > > Thank you - Fred > > *From:*Lou Berger <[email protected]> > *Sent:* Thursday, July 23, 2026 2:33 PM > *To:* Templin (US), Fred L <[email protected]> > *Cc:* [email protected]; manet <[email protected]> > *Subject:* Re: [manet] Re: Extended: Call for adoption: > draft-templin-manet-inet-05 > > 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]> <mailto:[email protected]> > > Sent: Wednesday, July 22, 2026 3:17 AM > > To: Templin (US), Fred L<[email protected]> <mailto:[email protected]>; Donald Eastlake<[email protected]> <mailto:[email protected]>; manet<[email protected]> <mailto:[email protected]> > > Cc: Mobile Ad-hoc Networks Working Group<[email protected]> <mailto:[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]> <mailto:[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. > > FLT >> OK, I will add the above text in the intro. > Thanks. > ... > > 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. > > >> A couple of things here. First, BGP scaling in the standard Internet is > only able to accommodate O(10**6) > > >> prefixes that rarely change. Second, frequent advertisement and > withdrawal of mobile network prefixes > > >> can cause BGP churn resulting in instability in the global routing > system. In other words, BGP is not > > >> well suited to supporting mobile Internetworking by itself. With an > overlay, the BGP routing service > > >> only needs to cover the addresses of the Mobility Anchor Points > (MAPs) which are stable nodes > > >> not subject to mobility. Within the overlay, the MAPs keep track of > Mobile Network Prefix (MNP) > > >> to MAP associations which may change dynamically. This is accommodated > through a combination > > >> of a hierarchical overlay BGP arrangement of the MAPs in combination > with dynamic updates to the > > >> (reverse) DNS resource records that associate MNPs with MAPs. One > final thing is that there need > > >> not be only one gigantic global overlay – there could be many smaller > overlays operated by > > >> Mobility Service Providers (MSPs). > It may be we have different understanding of the objectives of "MANET internetwoking". For the purposes are, in priority order, (A) manet nodes being able to initiate and maintain communication with nodes on the rest of the Network (B) Nodes on the Internet being able to initiate and maintain communication with nodes in a MANET (C) for nodes in a MANET being able to initiate and maintain communication with nodes in another MANET Do you agree with this list? Do you agree with the priority order? In either (any) case I think the draft needs to clearly state what problem is being solved by MANET Interworking. Then the GAPs can cover the points and limitations above which then can explain why a particular solution architecture is proposed by the document. > 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?) > > >> The gaps apply to any and all of the problem statements and not > necessarily in 1x1 correspondence. > > >> The gaps are technology requirements that are specific to MANET > Internetworking but not currently > > >> addressed by existing Internetworking technologies. Solution > proposals need to explain how they > > >> close the gaps. > Don't the gaps also need to be clear on what problem they are solving? Said another way, a gap that isn't addressing a stated problem really don't belong in this document. > 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 can add this, but I believe this document should be kept as brief as > possible. I am not in > > >> favor of gratuitous expansion that could cause the document to grow > without bounds. > From one perspective it by be obvious and gratuitous, from another it may be irrelevant. If not stated, IMO you can't assume any consensus in the WG. This is making think of the quote "Everything should be made as simple as possible, but not simpler." > 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., > > >> Multilink is solved by configuring a virtual interface over multiple > underlying interfaces > > >> which then applies encapsulation. Data communications can then use an > IP address > > >> assigned to the virtual interface even though the underlying > interfaces use different IP > > >> addresses. > This is a common overlay (aka SD-WAN) solution that is very in vogue today. It isn't the only or even obvious choice to me. (I'm used to seeing 802.1 LACP/LAG, IETF bundling or unnumbered links) > 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. > > >> As above, I don’t favor gratuitous expansion of this document but > will see what I can > > >> do about adding a few more words. > great (and same response as above.) Thanks, Lou > 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 > --------------PH8KulTCxiq7uYFgGEkVbqUz 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 in-line below.</p> <div class="moz-cite-prefix">On 7/24/2026 10:52 AM, Templin (US), Fred L wrote:<br> </div> <blockquote type="cite" cite="mid:BN0P110MB14202B9CA8FCB71E540C82ECA3CFA@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style>@scope { @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face {font-family:Aptos;}@font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; font-size:10.0pt; font-family:"Aptos",sans-serif;}a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;}pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; font-size:10.0pt; font-family:"Courier New";}span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:Consolas; mso-ligatures:none;}span.EmailStyle21 {mso-style-type:personal-reply; font-family:"Aptos",sans-serif; color:windowtext;}.MsoChpDefault {mso-style-type:export-only; font-size:10.0pt; mso-ligatures:none;}@page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1 {page:WordSection1;} }</style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext="edit" spidmax="1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1" /> </o:shapelayout></xml><![endif]--> <div class="WordSection1"> <p class="MsoNormal"><span style="font-size:11.0pt">Hello Lou, follow-ups below:<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt">Thank you - Fred<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> <p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Lou Berger <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> <br> <b>Sent:</b> Thursday, July 23, 2026 2:33 PM<br> <b>To:</b> Templin (US), Fred L <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a><br> <b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>; manet <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a><br> <b>Subject:</b> Re: [manet] Re: Extended: Call for adoption: draft-templin-manet-inet-05<o:p></o:p></span></p> </div> </div> <p>Fred, <o:p></o:p></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" moz-do-not-send="true">draft-ietf-manet-inet-gap-analysis-03</a> assuming it is the same as the PDF you sent to the list...<o:p></o:p></p> <p class="MsoNormal"><span style="font-family:"Times New Roman",serif">On 7/22/2026 12:34 PM, Templin (US), Fred L wrote:<o:p></o:p></span></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre>Hi Lou,<o:p></o:p></pre> <pre><o:p> </o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre>-----Original Message-----<o:p></o:p></pre> <pre>From: Lou Berger <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a><o:p></o:p></pre> <pre>Sent: Wednesday, July 22, 2026 3:17 AM<o:p></o:p></pre> <pre>To: Templin (US), Fred L <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a>; Donald Eastlake <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a>; manet <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a><o:p></o:p></pre> <pre>Cc: Mobile Ad-hoc Networks Working Group <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a>; <a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a><o:p></o:p></pre> <pre>Subject: Re: [manet] Re: Extended: Call for adoption: draft-templin-manet-inet-05 <o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Hi Fred,<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>[in an attempt to revive this discussion...]<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>On 5/26/2026 3:39 PM, Templin (US), Fred L wrote:<o:p></o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre>Lou, please excuse the delayed response and see below for replies to your comments:<o:p></o:p></pre> <pre><o:p> </o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre>-----Original Message-----<o:p></o:p></pre> <pre>From: Lou Berger <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a><o:p></o:p></pre> <pre>...<o:p></o:p></pre> <pre>This said,I do not think the document is clear on the motivation or use<o:p></o:p></pre> <pre>case(s) that necessitates the need for a global MANET overlay, the use<o:p></o:p></pre> <pre>of virtual overlays between MANETs, or if such are required why such<o:p></o:p></pre> <pre>overlay links are unique to MANETs . Said another way, once a MANET is<o:p></o:p></pre> <pre>connected to the Internet is there anything that is uniquely observable<o:p></o:p></pre> <pre>(at the IP layer) outside the MANET. I think this<o:p></o:p></pre> <pre>assumption/architecture should be fully flushed out and agreed upon<o:p></o:p></pre> <pre>prior to this work being submitted for publication.<o:p></o:p></pre> </blockquote> <pre>A MANET should be considered as a mobile network that is either<o:p></o:p></pre> <pre>disconnected from the global Internetwork or only intermittently connected<o:p></o:p></pre> <pre>to the global Internetwork with the ability to move rapidly between different<o:p></o:p></pre> <pre>Internetwork attachment points. Due to the dynamic multilink nature of MANETs,<o:p></o:p></pre> <pre>most do not attempt to represent themselves as a single logical IP subnet to<o:p></o:p></pre> <pre>the outside world meaning that each MANET node may configure a distinct<o:p></o:p></pre> <pre>mobile network prefix unique to itself.<o:p></o:p></pre> </blockquote> <pre>I think this is justification for<o:p></o:p></pre> <pre><a href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#name-problem-1-manet-local-addre" moz-do-not-send="true" class="moz-txt-link-freetext">https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#name-problem-1-manet-local-addre</a><o:p></o:p></pre> </blockquote> <pre><o:p> </o:p></pre> <pre>OK - are you suggesting any changes?<o:p></o:p></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.<o:p></o:p></p> <p><span style="font-size:11.0pt">FLT >> OK, I will add the above text in the intro.</span></p> </div> </blockquote> <p>Thanks.</p> <p><br> </p> <blockquote type="cite" cite="mid:BN0P110MB14202B9CA8FCB71E540C82ECA3CFA@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <div class="WordSection1"> <p><span style="font-size:11.0pt"><o:p></o:p></span></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">... <pre><o:p> </o:p></pre> <pre>The discussion appears in the introduction and throughout the problem statements.<o:p></o:p></pre> <pre>Much of the discussion was added in response to your previous set of comments.<o:p></o:p></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<o:p></o:p></p> <p style="background:white;box-sizing: border-box;margin:3ch;overflow-wrap: break-word;font-variant-ligatures: normal;font-variant-caps: normal;orphans: 2;text-align:start;widows: 2;-webkit-text-stroke-width: 0px;text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;word-spacing:0px" id="section-1-5"> <span style="font-family:Consolas;color:#212529">A widely-accepted axiom at the time of this writing suggests that there are more cellphones than people on the planet [<a href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#STATISTA" moz-do-not-send="true"><span style="color:#0D6EFD">STATISTA</span></a>]. According to Wikipedia, the world population reached 8 billion in 2022 and is expected to reach 10 billion by 2056 [<a href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#WIKI" moz-do-not-send="true"><span style="color:#0D6EFD">WIKI</span></a>]. 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.<o:p></o:p></span></p> <p style="background:white;box-sizing: border-box;margin:3ch;overflow-wrap: break-word;font-variant-ligatures: normal;font-variant-caps: normal;orphans: 2;text-align:start;widows: 2;-webkit-text-stroke-width: 0px;text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;word-spacing:0px" id="section-1-6"> <span style="font-family:Consolas;color:#212529">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. <a href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#manet-inet" moz-do-not-send="true"><span style="color:#0D6EFD">Figure 1</span></a> illustrates an example of 2 distinct MANET local routing regions connected via the NBMA overlay using the Internet as transit:<o:p></o:p></span></p> <div id="manet-inet"> <div style="margin-top:15.6pt;margin-bottom:15.6pt;box-sizing: border-box;flex-wrap: nowrap;align-items: end;display:flex" id="section-1-7.1"> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> .-(::::::::)<o:p></o:p></span></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> .-(::: Global ::)-.<o:p></o:p></span></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> X==+======(===================)======+==X<o:p></o:p></span></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> | `-(: Internet :)-' |<o:p></o:p></span></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> | `-(::::::)-' |<o:p></o:p></span></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> | |<o:p></o:p></span></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> .-(::::::::) .-(::::::::)<o:p></o:p></span></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> .-(::::::::::::)-. .-(::::::::::::)-.<o:p></o:p></span></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> (::::: MANET 1 :::::) (::::: MANET 2 :::::)<o:p></o:p></span></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> `-(::::::::::::)-' `-(::::::::::::)-'<o:p></o:p></span></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> `-(::::::)-' `-(::::::)-'<o:p></o:p></span></pre> </div> <p class="MsoNormal" style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"><a href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#figure-1" moz-do-not-send="true"><span style="text-decoration:none">Figure 1</span></a>: <a href="https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis-03#name-manet-internetworking" moz-do-not-send="true"><span style="text-decoration:none">MANET Internetworking</span></a> <o:p></o:p></span></p> </div> <p style="background:white;box-sizing: border-box;margin:3ch;overflow-wrap: break-word;font-variant-ligatures: normal;font-variant-caps: normal;orphans: 2;text-align:start;widows: 2;-webkit-text-stroke-width: 0px;text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;word-spacing:0px" id="section-1-8"> <span style="font-family:Consolas;color:#212529">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.<o:p></o:p></span></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.<o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> A couple of things here. First, BGP scaling in the standard Internet is only able to accommodate O(10**6)<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> prefixes that rarely change. Second, frequent advertisement and withdrawal of mobile network prefixes<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> can cause BGP churn resulting in instability in the global routing system. In other words, BGP is not<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> well suited to supporting mobile Internetworking by itself. With an overlay, the BGP routing service<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> only needs to cover the addresses of the Mobility Anchor Points (MAPs) which are stable nodes<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> not subject to mobility. Within the overlay, the MAPs keep track of Mobile Network Prefix (MNP)<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> to MAP associations which may change dynamically. This is accommodated through a combination<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> of a hierarchical overlay BGP arrangement of the MAPs in combination with dynamic updates to the<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> (reverse) DNS resource records that associate MNPs with MAPs. One final thing is that there need<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> not be only one gigantic global overlay – there could be many smaller overlays operated by<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> Mobility Service Providers (MSPs).</span></p> </div> </blockquote> <p>It may be we have different understanding of the objectives of "MANET internetwoking". For the purposes are, in priority order, <br> (A) manet nodes being able to initiate and maintain communication with nodes on the rest of the Network<br> (B) Nodes on the Internet being able to initiate and maintain communication with nodes in a MANET<br> (C) for nodes in a MANET being able to initiate and maintain communication with nodes in another MANET</p> <p>Do you agree with this list? Do you agree with the priority order? </p> <p>In either (any) case I think the draft needs to clearly state what problem is being solved by MANET Interworking. Then the GAPs can cover the points and limitations above which then can explain why a particular solution architecture is proposed by the document.</p> <p><br> </p> <blockquote type="cite" cite="mid:BN0P110MB14202B9CA8FCB71E540C82ECA3CFA@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <div class="WordSection1"> <p style="margin:0in"><span style="font-size:11.0pt"><o:p></o:p></span></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre><o:p> </o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre>Another motivation for an overlay that is not yet addressed in the<o:p></o:p></pre> <pre>document is seamless support for MANET nodes with multiple<o:p></o:p></pre> <pre>interfaces. A natural reaction is to dismiss this as a corner case<o:p></o:p></pre> </blockquote> <pre>I agree that this is an important use case to consider in the problem<o:p></o:p></pre> <pre>statement. I note that the document introduces this concept in Gap 1<o:p></o:p></pre> <pre>and not as it's own problem statement.<o:p></o:p></pre> </blockquote> <pre><o:p> </o:p></pre> <pre>Yes, it is listed as a gap that needs to be addressed by solution proposals.<o:p></o:p></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?)<o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> The gaps apply to any and all of the problem statements and not necessarily in 1x1 correspondence.<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> The gaps are technology requirements that are specific to MANET Internetworking but not currently<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> addressed by existing Internetworking technologies. Solution proposals need to explain how they<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> close the gaps.</span></p> </div> </blockquote> <p><br> </p> <p>Don't the gaps also need to be clear on what problem they are solving? Said another way, a gap that isn't addressing a stated problem really don't belong in this document.</p> <blockquote type="cite" cite="mid:BN0P110MB14202B9CA8FCB71E540C82ECA3CFA@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <div class="WordSection1"> <p style="margin:0in"><span style="font-size:11.0pt"><o:p></o:p></span></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre><o:p> </o:p></pre> <pre><o:p> </o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre>until<o:p></o:p></pre> <pre>one considers that vast number of cellphones worldwide have<o:p></o:p></pre> <pre>multiple interfaces (cellular, Wi-Fi, bluetooth, and in some cases<o:p></o:p></pre> <pre>even SATCOM) where at least the cellular and Wi-Fi can be seen<o:p></o:p></pre> <pre>as candidate MANET interfaces when disconnected from or<o:p></o:p></pre> <pre>intermittently connected to infrastructure.<o:p></o:p></pre> </blockquote> <pre><o:p> </o:p></pre> <pre>This line of argument does *not* resonate with me as we already have a<o:p></o:p></pre> <pre>very scalable solution that is widely deployed, and that earlier<o:p></o:p></pre> <pre>attempts at MANETs on cell phones (I'll need to dig a bit on where this<o:p></o:p></pre> <pre>was discussed at the IETF, many years ago) didn't really pan out due to<o:p></o:p></pre> <pre>battery consumption.<o:p></o:p></pre> </blockquote> <pre><o:p> </o:p></pre> <pre>Modern cellphones have both WiFi and 5G interfaces. WiFi can already run<o:p></o:p></pre> <pre>in "ad-hoc" mode (for some flavor of "ad-hoc") and 3GPP is standardizing<o:p></o:p></pre> <pre>SideLink mode for 5G. The cellphone can therefore become be a MANET<o:p></o:p></pre> <pre>router to do multihop forwarding device-to-device when outside the<o:p></o:p></pre> <pre>context of cellular and/or WiFi infrastructure. Battery consumption is<o:p></o:p></pre> <pre>not an issue when the cellphone is connected to a power source such<o:p></o:p></pre> <pre>as when used inside of a vehicle. Even in dismounted scenarios, however,<o:p></o:p></pre> <pre>having a (limited-duration) multi-hop communications capability may be<o:p></o:p></pre> <pre>deemed worthwhile and could provide a safety-of-life capability such as<o:p></o:p></pre> <pre>for emergency response / disaster relief events. For these reasons, I believe<o:p></o:p></pre> <pre>the modern cellphone (of which there are billions worldwide) will become<o:p></o:p></pre> <pre>an important MANET router platform.<o:p></o:p></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.<o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> I can add this, but I believe this document should be kept as brief as possible. I am not in<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> favor of gratuitous expansion that could cause the document to grow without bounds.</span></p> </div> </blockquote> <p>From one perspective it by be obvious and gratuitous, from another it may be irrelevant. If not stated, IMO you can't assume any consensus in the WG.</p> <p>This is making think of the quote "Everything should be made as simple as possible, but not simpler."</p> <p><br> </p> <blockquote type="cite" cite="mid:BN0P110MB14202B9CA8FCB71E540C82ECA3CFA@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <div class="WordSection1"> <p style="margin:0in"><span style="font-size:11.0pt"><o:p></o:p></span></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre><o:p> </o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre>I heard you make a related comment just now at the mic that is not<o:p></o:p></pre> <pre>evident (at least to me) in the document -- I think it would be good to<o:p></o:p></pre> <pre>expand on your thoughts on this and make sure that the concepts are<o:p></o:p></pre> <pre>covered in the document.<o:p></o:p></pre> </blockquote> <pre><o:p> </o:p></pre> <pre>Does the above help?<o:p></o:p></pre> </blockquote> <p>(covered by previous response.)<o:p></o:p></p> <p><o:p> </o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre><o:p> </o:p></pre> <pre><o:p> </o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre>An overlay interface<o:p></o:p></pre> <pre>configured over the MANET interfaces can then be used to<o:p></o:p></pre> <pre>orchestrate communications using a singular IP address that<o:p></o:p></pre> <pre>identifies the node as opposed to a distinct IP address for each<o:p></o:p></pre> <pre>MANET interface.<o:p></o:p></pre> </blockquote> <pre><o:p> </o:p></pre> <pre>Heretoo, this is something that is commonly done in non-manet networks<o:p></o:p></pre> <pre>without requiring a new global overlay.<o:p></o:p></pre> </blockquote> <pre><o:p> </o:p></pre> <pre>This is referring to a capability sometimes termed "multilink". It allows for<o:p></o:p></pre> <pre>carrying some packet flows over link "A" and others over links "B", "C", etc.<o:p></o:p></pre> <pre>but all using the same IP address in the overlay. Multilink is useful for<o:p></o:p></pre> <pre>fault tolerance, load balancing, matching flows to appropriate link<o:p></o:p></pre> <pre>performance profiles, cost optimization, etc.<o:p></o:p></pre> </blockquote> <p>This is not unique to manets and is not generally solved using an overlay.,<o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> Multilink is solved by configuring a virtual interface over multiple underlying interfaces<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> which then applies encapsulation. Data communications can then use an IP address<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> assigned to the virtual interface even though the underlying interfaces use different IP<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> addresses.</span></p> </div> </blockquote> <p>This is a common overlay (aka SD-WAN) solution that is very in vogue today. It isn't the only or even obvious choice to me. (I'm used to seeing 802.1 LACP/LAG, IETF bundling or unnumbered links)</p> <p><br> </p> <blockquote type="cite" cite="mid:BN0P110MB14202B9CA8FCB71E540C82ECA3CFA@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <div class="WordSection1"> <p style="margin:0in"><span style="font-size:11.0pt"><o:p></o:p></span></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre>Another topic that<o:p></o:p></pre> <pre>I think needs to be better explored is the implicit role of DNS ( is<o:p></o:p></pre> <pre>it required or optional, is there complete definition, does it belong in<o:p></o:p></pre> <pre>this document).<o:p></o:p></pre> </blockquote> <pre>Agreed and we can expand on the discussion surrounding the DNS.<o:p></o:p></pre> </blockquote> <pre><o:p> </o:p></pre> <pre>I don't see this discussion in the current document, perhaps the<o:p></o:p></pre> <pre>document needs another section on assumptions/presumed architecture and<o:p></o:p></pre> <pre>rationale for such.<o:p></o:p></pre> </blockquote> <pre><o:p> </o:p></pre> <pre>The document already does discuss expectations of the DNS service in several<o:p></o:p></pre> <pre>places. I think going into a deeper discussion of the DNS architecture would be<o:p></o:p></pre> <pre>subject for a different document. <o:p></o:p></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.<o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> As above, I don’t favor gratuitous expansion of this document but will see what I can<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> do about adding a few more words.</span></p> </div> </blockquote> <p>great (and same response as above.)</p> <p><br> </p> <p>Thanks,</p> <p>Lou</p> <blockquote type="cite" cite="mid:BN0P110MB14202B9CA8FCB71E540C82ECA3CFA@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <div class="WordSection1"> <p style="margin:0in"><span style="font-size:11.0pt"><o:p></o:p></span></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre><o:p> </o:p></pre> <pre><o:p> </o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre>I think these issue can be worked before or after document adoption. In<o:p></o:p></pre> <pre>either case, I support having the WG discuss the topics represented in<o:p></o:p></pre> <pre>the draft.<o:p></o:p></pre> </blockquote> <pre>Thank you for bringing this discussion forward!<o:p></o:p></pre> </blockquote> <pre><o:p> </o:p></pre> <pre>Thank you!<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Lou<o:p></o:p></pre> </blockquote> <pre> <o:p></o:p></pre> <pre>Thanks - Fred<o:p></o:p></pre> </blockquote> <p>Thanks!<o:p></o:p></p> <p>Lou<o:p></o:p></p> </div> </blockquote> </body> </html> --------------PH8KulTCxiq7uYFgGEkVbqUz-- --===============6022611781090166674== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWFuZXQgbWFp bGluZyBsaXN0IC0tIG1hbmV0QGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gbWFuZXQtbGVhdmVAaWV0Zi5vcmcK --===============6022611781090166674==--