Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

["Liguangpeng (Roc, Network Technology Laboratory)" <[e-mail]>]

Hi Brian,

> There is work on supporting shorter address lengths in limited domains where that is sufficient.

I am not sure which work was included here. As the I-D(https://datatracker.ietf.org/doc/draft-jia-intarea-scenarios-problems-addressing/ ) wrote, some scenarios(if not all) are under scope of limited domain. I think a discussion on whether those scenarios were covered by the mentioned work should be valuable. Then, people can get conclusion of sufficient or not. IMO, the uni-size length is not the essence of problem. The absence of semantics except topology address is the bigger one.

Guangpeng Li

-----Original Message-----
From: Brian E Carpenter [mailto:[e-mail]] 
Sent: Tuesday, March 2, 2021 4:08 AM
To: Toerless Eckert <[e-mail]>; Stewart Bryant <[e-mail]>
Cc: [e-mail]; [e-mail]; int-area <[e-mail]>; Jiayihao <[e-mail]>
Subject: Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

Hi Toerless,
On 02-Mar-21 04:33, Toerless Eckert wrote:
> It is somewhat ironic to see how it was IP and IPv6 that where the 
> protocols that where successfully enhanced with additional adress 
> semantics not considered when they where designed (ok, at last IPv4, 
> but arguably also in a more subtle fashion IPv6). Even though as 
> Stewart points out, CLNP would be more easily able to absorb 
> additional semantics because of its flexible address length. But of course new semantics are looking for the best model to see actual deployments, and that best happens with protocols already most widely deployed.
> 
> Which at the time IP Multicast was designed was obviously IPv4 (at 
> least in the USA where it originated), not CLNP.
> 
> So now we're stuck that adopting newer semantics like BIER or ICN 
> natively into IPv6 is primarily not possible because of IPv6 fixed 
> address length. Instead, BIER had to do its own second network 
> hop-by-ho forwarding protocol/header duplicating all of IPv6 as 
> needed, just to have longer addresses, and ICN (hICN) proposing which in by book is really an overlay solution to leave IPv6 pretty much untouched.
> 
> I really don't understand why the IPv6 world has not understood how 
> the most easy way to allow for the applicability of IPv6 to grow 
> (especially beyond "just more addresses thn IPv4") would be to come up 
> with a backward compatible encap on the wire that would support additional address lengths.

There is work on supporting shorter address lengths in limited domains where that is sufficient. I don't think we have a viable use case yet for longer addresses, although we do have a need for 3GPP operators to support prefixes shorter than /64, but that's a deployment issue, not a standards issue.

(BIER doesn't strike me as such a use case; an overlay is the natural solution and it's roughly what Rick Boivie and others proposed in XCAST 20 years ago, as eventually recorded in RFC5058. I'm fairly uninformed about ICN but again it seems to me that an overlay is the natural solution and blending it into the network layer would be spaghetti engineering.)

It would take but a minute to design a longer-address mechanism for IPv6, although I don't have space to include it in the margin of this email**. But it would take many years for it to be widely implemented and deployed, during which time the Internet would be opaque to such addresses.

> We've already seen with SRv6 how more flexible use of addresses can 
> help solutions.

Have we really seen that? How many sites are running production traffic using SRv6? In any case, 128 bits seem to be largely sufficient for SRv6 purposes, since the semantics are local.
 
    Brian

** Basically, use a prefix such as fb00::/8 to indicate an extended address.