> Yes, I agree but I am not convinced we need to solve this by adding the > complexity in L3 and hence through out the whole of the Internet > rather than further up the protocol stack.
AERO and OMNI do not solve this at L3; they solve it in the adaptation layer (i.e., lower down the protocol stack). Fred > -----Original Message----- > From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Stewart Bryant > Sent: Thursday, December 02, 2021 3:45 AM > To: Dino Farinacci <farina...@gmail.com> > Cc: int-area@ietf.org; Dirk Trossen <dirk.trossen=40huawei....@dmarc.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. > > > > The key question that I would ask Dino is whether these need to be addressed > at the network layer? > > > On 1 Dec 2021, at 22:18, Dino Farinacci <farina...@gmail.com> wrote: > > > > 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. > > It can do this by treating these as independent links with different > addresses and bind them in the application or through some OS service. > > > > > (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. > > Is that a network layer problem or an OS problem? > > > > > (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>". > > It is important that people can find you/your device, but I am not convinced > they need to find you by historic IP address. > > “Pinging” Dino’s computer does not have to happen directly at the network > layer to find out that it is alive. To test *a* path to Dino’s > computer sure you need the address that that path responds to, but I am not > convinced that it is simpler if the address on that network is > the same as the address on all of the other networks to which it is attached. > > > > > Yes, I want host multi-homing and mobility. And I want it to work > > seamlessly. > > > > Yes, I agree but I am not convinced we need to solve this by adding the > complexity in L3 and hence through out the whole of the Internet > rather than further up the protocol stack. > > Stewart > > > > > 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 _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
