Hi Roland > -----Original Message----- > From: Int-area <int-area-boun...@ietf.org> On Behalf Of Bless, Roland (TM) > Sent: Tuesday, 4 October 2022 18:08 > To: Luigi Iannone <g...@gigix.net>; int-area <int-area@ietf.org> > Subject: Re: [Int-area] Rebooting Addressing Discussion > > Hi Luigi, > > a related question would also be: > how much addressing semantics/context is required for performing (a) the > forwarding and/or (b) the routing decision inside a node?
Excellent questions ;-) For a) I think it depends where you are. Keeping the drone example, in the connecting infrastructure you might not care whether the address in the packet identifies a link or the drone itself, that is the power of the IP model. Certainly some semantics/context is necessary in some places if you do operations that are beyond the IP model (like identifying a link...). I would translate the question to: How to define a general framework that allows us to define additional semantics/context when and where necessary? For b) routing to me is about providing the necessary information to "forward" a packet. Now, we have the routing infrastructure which works very well if you are "semantic agnostic", meaning that no special semantics/context is associated to an address/prefix. When there is a special semantic/context that needs to be considered in order to do forwarding, IMO you already have a few options to distribute that information: LISP Mapping system, PCE, BGP-EVPN, to cite a few. In essence, to me have know how to distribute semantics/context, the real issue is to define The general framework that allows to easily associate semantics/context to addresses/prefixes so to clearly define the what, the when, and the where. Coming back to the original question, I think that such framework can be used to define What and address identifies, Where this specific identification matters, and When to apply it. Ciao L. > > Regards, > Roland > > On 30.09.22 at 10:36 Luigi Iannone wrote: > > Hi All, > > > > During the last INTArea meeting the discussion on the two drafts > > related to Internet addressing had three the clear outcomes: > > 1. The issue seems to go beyond what the INTArea has been > > chartered for. > > 2. The pain points (aka the problem) have to be scoped in a > > better way. In the current form, the scope is so broad that we risk > > ending up trying to boil the ocean without achieving any relevant result. > > 3. Incremental deployability remains a MUST. No revolution. > > Evolution is the only option. > > > > Concerning point 1. The documents have been taken out from INTArea > > (new naming). We still continue the discussion on the INTArea mailing > > list, at least temporarily with the option to have a dedicated mailing > > list in the future. > > > > I would like to restart discuss on point 2: the scope. > > > > The considerations draft > > (https://datatracker.ietf.org/doc/draft-iannone-internet-addressing-co > > nsiderations/) > > highlighted three properties, namely: > > Property 1: Fixed Address Length > > Property 2: Ambiguous Address Semantic Property 3: Limited Address > > Semantic Support > > > > But before going to the discussion of which property we should/want > > change the first question the comes up is: what does an address > > identify exactly? > > > > A simple answer would be: an Interface. > > > > But we all know that reality is far more complex, as pointed out with > > the many existing examples in the considerations draft. > > What is even more complex is how to provide a wealth of answers to the > > above question within a framework for evolved addressing that does not > > rely on the continued point-wise approach we see in the Internet today. > > > > In order to start specifying what this evolved addressing framework > > could be, the first steps are: > > - paraphrasing Lixia Zhang’s question from the recent RTG WG > > interim meeting as “What should we identify through an address?” > > - scope the work around those answers we believe are most > > desirable to avoid the boiling the ocean issue > > > > Do you believe this is a reasonable approach to move forward? > > > > > > Luigi > > > > _______________________________________________ > > 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
