Re:[External] Request for information - Challenges in routing related to semantic addressing

[Toerless Eckert <[e-mail]>]

Thanks, Tony, *:

You meantion locator and identifiers as unresolved. Do you think this should be subject to
more work in IETF and/or IRTF (routing) ? If so, how ?

You mention architecture fundamentals and routing / addressing ties. Do you think there
such fundamentals that would transcend what i would call different "address semantics",
e.g.: unicast, multicast, ICN ? I am asking because if there where such fundamenals of
interest, maybe working on them would ease the ability to operate multiple semantics,
add and/or extend them.

You mention protocol field / address overload. I completely agree, but why then have we
not attempted to work to easier extend instead of overload packet header / addresses ?
E.g.: I look at TSVWG L4S carving out even more semantic out of 2 ECN bits and grumble
about printing a t-shirt "40 years of IP and all we have for QoS is still 8 bit".
(alas, corona times are no fun for t-shirt junkies).

Personally, i wish we would never ned to overload semantics of addresses, because we are a) not
wasting address space (as you point out) and can b) amend adress space, when needed for new semantics.
Now: Why do we not amend our protocols to allow for that ?

Cheers
    Toerless

On Mon, Feb 15, 2021 at 09:43:41AM -0800, Tony Li wrote:
> 
> 
> > On Feb 15, 2021, at 8:10 AM, Joel M. Halpern <[e-mail] <mailto:[e-mail]>> wrote:
> > 
> > I can't argue with an effort to define the term "semantic routing".
> > However, I would be very concerned by an effort to define goals for it before we have such a definition.  Depending upon the definition, the answer may be that it is a bad idea.
> 
> 
> 
> I???ll go a bit farther.
> 
> In reading this draft, I???m struck by the lack of clear articulation of some of the fundamentals of the architecture. Routing and addressing are functionally tied together and 
> any discussions of modifications to one requires a clear discussion of how it would affect the other function. We learned long ago that overloading functionality on packet fields is a poor design choice,
> and even the early decision to overload identification onto location has had profound and deleterious effects that we have still not overcome.  In fact, you list the impacts of this architectural error
> as things that you???d like to fix: multihoming, mobility, and multipath routing.
> 
> It???s also somewhat concerning when you list Scalability as one of the goals that you are proposing to fix with semantic overloading. It should be clear that any overloading of the address space
> will reduce, not improve, its flexibility and thereby limit, not enhance Scalability.
> 
> If and when there is a clear definition of ???semantic routing??? and a clear proposal on how to move forward, there must also be a clear discussion of the affects of overloading addressing will
> affect routing.
> 
> The original purpose of giving IPv6 128 bits of address space was to ensure that there was continued scalability for the routing system for the next 20 years (which have now expired ;-). In fact,
> what we???ve learned is that transitioning to a new network layer takes a lot longer than what we had hoped and that the lifetime of a network layer is far more than expected. Thus, we should
> be aiming to preserve IPv6 functionality in perpetuity and not simply for the next generation. To this end, we must be very careful about any unintended side-effects from overloading addressing,
> especially with regards to routing scalability.
> 
> We have a fine example of this when we decided that most end sites would be granted a /64 prefix. This effectively took half of the addressing bits off of the table for global routing and since addressing is
> hierarchical, this was a logarithmic decrease in overall routing scalability. Meanwhile, most of the individual sites are domestic networks that will never ever subnet.
> 
> So, please be very clear about the impacts of any proposal that suggests overloading addressing. The impact to the architecture will definitely be non-trivial and thus it bears careful consideration.
> 
> Regards,
> Tony
> 

-- 
---
[e-mail]