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
do 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 or use the load of
the outgoing links as selector or even take into account the current
load of the servers which would by 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
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.
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.
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
