[manet] Re: Extended: Call for adoption: draft-templin-m anet-inet-05
Lou Berger <[email protected]> Wed, 29 Jul 2026 17:14:24 +0200
| Newsgroups | gmane.ietf.manet |
|---|---|
| Message-ID | <[email protected]> |
--===============8089436533140574092== Content-Type: multipart/alternative; boundary="------------8v7xdJdd8SQONjIp4gCPuF1E" Content-Language: en-US --------------8v7xdJdd8SQONjIp4gCPuF1E Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Fred see below. Dropping closed topics. On 7/27/2026 2:09 PM, Templin (US), Fred L wrote: > > Hi Lou, see responses marked with “>>” below: > > Thank you - Fred > > *From:*Lou Berger <[email protected]> > *Sent:* Monday, July 27, 2026 9:36 AM > *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 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]> <mailto:[email protected]> > *Sent:* Thursday, July 23, 2026 2:33 PM > *To:* Templin (US), Fred L <[email protected]> > <mailto:[email protected]> > *Cc:* [email protected]; manet <[email protected]> > <mailto:[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, > > > ... > > 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. > > >> done > > ... > > > > 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? > > >> I do not agree with a priority order for these, because the requirement > is very much use-case > > >> specific. For a MANET of nodes that want to browse the Internet, (A) > might be a higher priority. > > >> For a MANET consisting of sensor nodes, (B) might be the higher > priority. For people and their > > >> cellphones wanting to call each other, (C) might be the higher > priority. I therefore do not want > > >> to assign priorities to the problems. I want for any solution proposals > to completely address > > >> all of the problems while also explaining how they address the gaps. > > 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. > > *//* > > >> New text in the draft clarifies what is meant by a “problem” and what > is meant by a “gap” > > >> and I do not think it is going to be productive to have endless > arguments about whether > > >> something is a “problem” vs a “gap”. Please do not try to read too > much into these terms. > I'm sorry, I completely disagree. An RFC should stand on its own without having to see the email history to understand it. I'm saying I don't understand the current text as it stands, and that delineating what is the problem, from the existing solutions, from the gaps is needed in this document. I may be in the rough on this, but we'll need to see if others agree or disagree to know this. > > > 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?) > > *//* > > >> As above, please see the new text I will add to the draft. I do > not think an endless > > >> argument about what is a problem vs what is a gap will be productive. > > >> 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. > > >> Lots of solutions both new and existing can claim to already address > some or all > > >> of the problems but the gap analysis should identify which solutions do > so most > > >> correctly, completely and/or efficiently. > I think you missed my point -- the document should only have topics in the gaps that are first introduced in the problem statements. I suspect we disagree on this. > > > > > 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 have added the above text, but in the introduction and not the > problem statement. > > >> I am willing to consider adding more gaps if someone identifies them, > but I do not > > >> want to add more problems. > Well this is now a working group document, so each of our voices represent one WG contributor. Document editors have a lot of leeway in document consensus, but it is incumbent on the editor to document WG consensus - not the opinion of the authors. > > > 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) > > >> I should have started my response with: “Within the context of MANET > Internetworking, > > >> multilink is solved by configuring a virtual interface over multiple > underlying interfaces > > >> which then applies encapsulation.”. There may be other point solution > approaches to > > >> multilink, but the one I am referring to is “within the context of > MANET Internetworking”, > > >> i.e., when the solution also addresses all of the MANET > Internetworking problems while > > >> best closing the technological gaps. > Where are the details substantiating this perspective? I think the document needs references to support this position.(and I'd really like to understand them, since I don't understand the assertion being made.) Lou > 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 > --------------8v7xdJdd8SQONjIp4gCPuF1E 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 below. Dropping closed topics.</p> <div class="moz-cite-prefix">On 7/27/2026 2:09 PM, Templin (US), Fred L wrote:<br> </div> <blockquote type="cite" cite="mid:BN0P110MB1420DB4F0C7F94859E99D600A3CCA@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:12.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">Hi Lou, see responses marked with “>>” 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> Monday, July 27, 2026 9:36 AM<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> <table class="MsoNormalTable" border="0" cellspacing="3" cellpadding="0" width="100%" style="width:100.0%"> <tbody> <tr> <td style="background:white;padding:.75pt .75pt .75pt .75pt"><br> </td> </tr> </tbody> </table> <p>Fred,<o:p></o:p></p> <p>See in-line below.<o:p></o:p></p> <p class="MsoNormal"><span style="font-family:"Times New Roman",serif">On 7/24/2026 10:52 AM, Templin (US), Fred L wrote:<o:p></o:p></span></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt">Hello Lou, follow-ups below:</span><o:p></o:p></p> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt"> </span><o:p></o:p></p> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt">Thank you - Fred</span><o:p></o:p></p> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt"> </span><o:p></o:p></p> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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 href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a> <br> <b>Sent:</b> Thursday, July 23, 2026 2:33 PM<br> <b>To:</b> Templin (US), Fred L <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a><br> <b>Cc:</b> <a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>; manet <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a><br> <b>Subject:</b> Re: [manet] Re: Extended: Call for adoption: draft-templin-manet-inet-05</span><o:p></o:p></p> </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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Times New Roman",serif">On 7/22/2026 12:34 PM, Templin (US), Fred L wrote:</span><o:p></o:p></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> </blockquote> </div> </blockquote> ... <blockquote type="cite" cite="mid:BN0P110MB1420DB4F0C7F94859E99D600A3CCA@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <div class="WordSection1"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <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><o:p></o:p></p> </blockquote> <p>Thanks.<o:p></o:p></p> <p><span style="font-size:11.0pt">>> done<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"> <p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Times New Roman",serif">... <o:p></o:p></span></p> <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.</span><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-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:</span><o:p></o:p></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"> .-(::::::::)</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> .-(::: Global ::)-.</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> X==+======(===================)======+==X</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> | `-(: Internet :)-' |</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> | `-(::::::)-' |</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> | |</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> .-(::::::::) .-(::::::::)</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> .-(::::::::::::)-. .-(::::::::::::)-.</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> (::::: MANET 1 :::::) (::::: MANET 2 :::::)</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> `-(::::::::::::)-' `-(::::::::::::)-'</span><o:p></o:p></pre> <pre style="background:white"><span style="font-size:12.0pt;font-family:Consolas;color:#212529"> `-(::::::)-' `-(::::::)-'</span><o:p></o:p></pre> </div> <p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;background:white"> <span style="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> </span><o:p></o:p></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.</span><o:p></o:p></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)</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> prefixes that rarely change. Second, frequent advertisement and withdrawal of mobile network prefixes</span><o:p></o:p></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</span><o:p></o:p></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</span><o:p></o:p></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</span><o:p></o:p></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)</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> to MAP associations which may change dynamically. This is accommodated through a combination</span><o:p></o:p></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</span><o:p></o:p></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</span><o:p></o:p></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</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> Mobility Service Providers (MSPs).</span><o:p></o:p></p> </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<o:p></o:p></p> <p>Do you agree with this list? Do you agree with the priority order?<o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> I do not agree with a priority order for these, because the requirement is very much use-case<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> specific. For a MANET of nodes that want to browse the Internet, (A) might be a higher priority.<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> For a MANET consisting of sensor nodes, (B) might be the higher priority. For people and their<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> cellphones wanting to call each other, (C) might be the higher priority. I therefore do not want<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> to assign priorities to the problems. I want for any solution proposals to completely address<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> all of the problems while also explaining how they address the gaps.<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt"><o:p> </o:p></span></p> <p style="margin:0in">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.<o:p></o:p></p> <p style="margin:0in"><b><i><span style="font-size:11.0pt"><o:p> </o:p></span></i></b></p> <p style="margin:0in"><span style="font-size:11.0pt">>> New text in the draft clarifies what is meant by a “problem” and what is meant by a “gap”<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> and I do not think it is going to be productive to have endless arguments about whether<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> something is a “problem” vs a “gap”. Please do not try to read too much into these terms.</span></p> </div> </blockquote> <p>I'm sorry, I completely disagree. An RFC should stand on its own without having to see the email history to understand it. I'm saying I don't understand the current text as it stands, and that delineating what is the problem, from the existing solutions, from the gaps is needed in this document. I may be in the rough on this, but we'll need to see if others agree or disagree to know this. </p> <p><br> </p> <blockquote type="cite" cite="mid:BN0P110MB1420DB4F0C7F94859E99D600A3CCA@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"> <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 style="margin:0in">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="mso-margin-top-alt:0in;margin-right:.5in;margin-bottom:0in;margin-left:0in"> <b><i><span style="font-size:11.0pt"><o:p> </o:p></span></i></b></p> <p style="margin:0in"><span style="font-size:11.0pt">>> As above, please see the new text I will add to the draft. I do not think an endless<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> argument about what is a problem vs what is a gap will be productive.<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt"><o:p> </o:p></span></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.</span><o:p></o:p></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</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> addressed by existing Internetworking technologies. Solution proposals need to explain how they</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> close the gaps.</span><o:p></o:p></p> </blockquote> <p><o:p> </o:p></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.<o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> Lots of solutions both new and existing can claim to already address some or all<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> of the problems but the gap analysis should identify which solutions do so most<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> correctly, completely and/or efficiently.</span></p> </div> </blockquote> <p>I think you missed my point -- the document should only have topics in the gaps that are first introduced in the problem statements. I suspect we disagree on this.</p> <p><br> </p> <blockquote type="cite" cite="mid:BN0P110MB1420DB4F0C7F94859E99D600A3CCA@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"> <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</span><o:p></o:p></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><o:p></o:p></p> </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.<o:p></o:p></p> <p>This is making think of the quote "Everything should be made as simple as possible, but not simpler."<o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> I have added the above text, but in the introduction and not the problem statement.<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> I am willing to consider adding more gaps if someone identifies them, but I do not<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> want to add more problems.</span></p> </div> </blockquote> <p>Well this is now a working group document, so each of our voices represent one WG contributor. Document editors have a lot of leeway in document consensus, but it is incumbent on the editor to document WG consensus - not the opinion of the authors. </p> <p><br> </p> <blockquote type="cite" cite="mid:BN0P110MB1420DB4F0C7F94859E99D600A3CCA@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <div class="WordSection1"> <p style="margin:0in"><span style="font-size:11.0pt"><o:p></o:p></span></p> <p><o:p> </o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <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</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> which then applies encapsulation. Data communications can then use an IP address</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> assigned to the virtual interface even though the underlying interfaces use different IP</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> addresses.</span><o:p></o:p></p> </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)<o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> I should have started my response with: “Within the context of MANET Internetworking,<o:p></o:p></span></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.”. There may be other point solution approaches to<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> multilink, but the one I am referring to is “within the context of MANET Internetworking”,<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> i.e., when the solution also addresses all of the MANET Internetworking problems while<o:p></o:p></span></p> <p style="margin:0in"><span style="font-size:11.0pt">>> best closing the technological gaps.</span></p> </div> </blockquote> <p>Where are the details substantiating this perspective? I think the document needs references to support this position.(and I'd really like to understand them, since I don't understand the assertion being made.)</p> <p>Lou</p> <blockquote type="cite" cite="mid:BN0P110MB1420DB4F0C7F94859E99D600A3CCA@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM"> <div class="WordSection1"> <p style="margin:0in"><span style="font-size:11.0pt"><o:p></o:p></span></p> <p><o:p> </o:p></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"> <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</span><o:p></o:p></p> <p style="margin:0in"><span style="font-size:11.0pt">>> do about adding a few more words.</span><o:p></o:p></p> </blockquote> <p>great (and same response as above.)<o:p></o:p></p> <p><o:p> </o:p></p> <p>Thanks,<o:p></o:p></p> <p>Lou<o:p></o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <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> </blockquote> </div> </blockquote> </body> </html> --------------8v7xdJdd8SQONjIp4gCPuF1E-- --===============8089436533140574092== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWFuZXQgbWFp bGluZyBsaXN0IC0tIG1hbmV0QGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gbWFuZXQtbGVhdmVAaWV0Zi5vcmcK --===============8089436533140574092==--