Have you seen AERO and OMNI? You should really take a look before embarking on another draft.
Fred > -----Original Message----- > From: Dirk Trossen [mailto:dirk.tros...@huawei.com] > Sent: Thursday, December 02, 2021 12:34 AM > To: Templin (US), Fred L <fred.l.temp...@boeing.com>; Dino Farinacci > <farina...@gmail.com> > Cc: int-area@ietf.org > Subject: RE: [Int-area] Side meeting follow-up: What exact features do we > want from the Internet? > > Fred, > > I tend to agree with Dino's reply in that the 6Ms may be the consequence (as > technical requirements) to what end users want. I think in the > extensions of the GA draft, we will mainly see those "what we need the > technology to do to deliver on user demands". > > My suggestion to use the GA draft as a starting point for this wider > discussion is to possibly link back to the underlying user demands by > explicitly outlining what the technology extensions intend to achieve (most > of which is likely aligned with your 6Ms). > > Best, > > Dirk > > -----Original Message----- > From: Templin (US), Fred L [mailto:fred.l.temp...@boeing.com] > Sent: 01 December 2021 23:28 > To: Dino Farinacci <farina...@gmail.com>; Dirk Trossen > <dirk.tros...@huawei.com> > Cc: int-area@ietf.org > Subject: Re: [Int-area] Side meeting follow-up: What exact features do we > want from the Internet? > > 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-addressin > > g-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
