Hi Roland, Please, see inline. > -----Original Message----- > From: Int-area <int-area-boun...@ietf.org> On Behalf Of Bless, Roland (TM) > Sent: Thursday, 6 October 2022 13:03 > To: int-area@ietf.org > Subject: Re: [Int-area] Rebooting Addressing Discussion > > Hi Luigi, > > sorry, I messed up the text in the first paragraph somehow, now corrected. > > On 06.10.22 at 11:32 Bless, Roland (TM) wrote: > > Hi Luigi, > > > > see inline. > > > > On 05.10.22 at 10:14 Luigi IANNONE wrote: > >> -----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? > > > > Just to clarify: to me routing is about finding paths to a destination > > (or destinations) and selecting those that should be currently used > > for forwarding (usually written down into a FIB). > > Forwarding is then about deciding which of the eligible forwarding > > entries should be used when a packet arrives to a certain destination, > > or maybe you have only one matching entry, but it may contain a set of > > outgoing interfaces for different next hops. Let's assume you have an > > anycast address and you have multiple destinations that are all > > equally eligible. Now your forwarding decision may simply apply some > > simple load balancing, use the load of the outgoing links as selector, > > or even take into account the current load of the servers, which would > > require some dynamic state that must be reported to the router > > (leaving the question aside for now whether this is > > useful/scalable/reasonable). So the forwarding decision may depend on > > information in the packet as well as on local state (and thus > > indirectly some remote state like the server load). In case a packet > > contains a source route there is nearly no degree of freedom left for > > the router's forwarding decision. > > In this context, I also find Dave Clark's distinction helpful (from > > his book 'Designing an Internet'): > > > > > > Destination-based > > Path-based > > Forwarding directive in packet > > Encapsulation > > Source route > > Forwarding state in router > > Classic Internet > > Label Switching
[LI] Nothing to add, we are aligned here ;-) > > > > > >> 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. > > Ok, see my definition above: the routing decision may happen at a > > different time scale, whereas forwarding decisions usually have to be > > performed per packet. So, yes, I agree that routing protocols may > > carry additional context information transparently that could be used > > by the routers as context for their forwarding decisions. However, it > > is a question how dynamic that information can be. For example, it may > > be feasible to report weights to indicate general server > > capacity/performance in the above example as these are rather static > > attributes, but it may not be feasible/useful to report the current > > server load this way. [LI] I agree as well on this point. Note, I was not suggesting to put everything on routing, rather to use different solutions/protocols depending on the specific requirements. I guess that the main point was that we do not necessarily have to design a new protocol to distribute additional context information, we should first look at what we already have. > >> 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. > > > > This sounds interesting. Let's see whether one can come up with a > > framework that you have in mind. [LI] Let's say that this is my opinion of what we should aim at. We certainly need to discuss to clarify and details this idea ;-) 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
