These are not user requirements. They are what a network engineer thinks should be supported. That's fine. But no user gives a damn about MTU. And they don't care about multicast. They care about user group communication (like group texting on iOS and Android).
And 1, 2, 3 and 5 are covered under my user requirement definition. In other words, just keep the network up all the time no matter how my physical connections change. Dino > On Dec 1, 2021, at 2:27 PM, Templin (US), Fred L <fred.l.temp...@boeing.com> > wrote: > > My input is that we will want the "6 M's of Modern Internetworking", namely: > > 1. Multilink - a Client's ability to coordinate multiple diverse > underlying data links as a single logical unit (i.e., the OMNI > interface) to achieve the required communications performance and > reliability objectives. > > 2. Multinet - the ability to span the OMNI link over a segment > routing topology with multiple diverse administrative domain > network segments while maintaining seamless end-to-end > communications between mobile Clients and correspondents such as > air traffic controllers, fleet administrators, etc. > > 3. Mobility - a Client's ability to change network points of > attachment (e.g., moving between wireless base stations) which > may result in an underlying interface address change, but without > disruptions to ongoing communication sessions with peers over the > OMNI link. > > 4. Multicast - the ability to send a single network transmission > that reaches multiple Clients belonging to the same interest > group, but without disturbing other Clients not subscribed to the > interest group. > > 5. Multihop - a mobile Client vehicle-to-vehicle relaying capability > useful when multiple forwarding hops between vehicles may be > necessary to "reach back" to an infrastructure access point > connection to the OMNI link. > > 6. MTU assurance - the ability to deliver packets of various robust > sizes between peers without loss due to a link size restriction, > and to dynamically adjust packets sizes to achieve the optimal > performance for each independent traffic flow. > > Fred Templin > >> -----Original Message----- >> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Dino Farinacci >> Sent: Wednesday, December 01, 2021 2:18 PM >> To: Dirk Trossen <dirk.trossen=40huawei....@dmarc.ietf.org> >> Cc: int-area@ietf.org >> Subject: [EXTERNAL] Re: [Int-area] Side meeting follow-up: What exact >> features do we want from the Internet? >> >> EXT email: be mindful of links/attachments. >> >> >> >> Here's my single feature request the network layer should provide: >> >> (1) I want to be connected ALL THE TIME, I want my computer to use all its >> links, either cabled or radio, ALL THE TIME. >> >> (2) I do not want to turn on and off wifi to get my device/computer to >> connect when it is currently not connected. The network layer should >> do all this for me. >> >> (3) I want it easy for people to find me (my IP address), so I don't want >> multiple addresses from the user level. I want one device ID, EID, >> host address, whatever you want to call it. I want you to "ping >> <dino's-computer>". >> >> Yes, I want host multi-homing and mobility. And I want it to work seamlessly. >> >> Speaking as a user, >> Dino >> >>> On Dec 1, 2021, at 12:52 AM, Dirk Trossen >>> <dirk.trossen=40huawei....@dmarc.ietf.org> wrote: >>> >>> Dear all, >>> >>> Many thanks for those participating in the side meeting on Internet >>> addressing during the IETF 112 week. As suggested during the >> meeting, we want to take various points of discussion during the meeting >> onto the mailing list to continue discussion here on possible ways >> forward. >>> >>> Specifically, we wanted to come back on the issue that a larger >>> architectural discussion may be needed, a point that we make towards the >> end of the GA draft >> (https://datatracker.ietf.org/doc/draft-jia-intarea-internet-addressing-gap-analysis/), >> but which was also core to Dirk >> K’s main point that only such architecture discussion may lead to possibly >> needed changes to addressing. We will be looking into such >> possibly larger discussion along different possible avenues. >>> >>> For our discussion here on the INT area list, we found Dino’s related >>> suggestion particularly useful in that we may need a discussion on >> what we (as users) may want from a network. We feel that our current GA >> draft may contribute to this question by observing that the many >> extensions to Internet addressing that we have gathered so far may be seen >> as an expression of a desired feature that those proposing the >> extension may want to see from the network. Hence, in addition to >> positioning those extensions as identified gaps to Internet addressing, >> we may want to formulate those extensions as desired features towards an >> extended Internet system, not just addressing; this can be done >> through suitably extending the GA draft with another section. >>> >>> Why is this useful? We think that such view provides an observational input >>> into the question that Dino suggests to answer, which in turn >> links to the larger architectural discussion that Dirk K suggests to have. >> While the overall architectural discussion may (and likely will) touch >> on more than ‘just’ addressing, we as a community may contribute to the >> discussion by rationalizing the work that has been done in this >> space. >>> >>> We would like to solicit thoughts on this proposed way forward as concrete >>> steps for the community here on the list. Also, anybody >> wanting to provide concrete input and contribution to this proposed revision >> of the draft is more than welcome. >>> >>> Best, >>> >>> Dirk >>> (on behalf of the co-authors) >>> >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
