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

From: Toerless Eckert <[email-masked]>
Date: Mon, 1 Mar 2021 16:33:00 +0100

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. We've already seen with SRv6 how more flexible use of addresses can help
solutions.

Oh well...

Toerless

Sorry if i intrude with multicast thoughts into a group that in the pas I think it would not be that difficult

On Mon, Feb 08, 2021 at 10:38:54AM +0000, Stewart Bryant wrote:
> 
> 
> > On 8 Feb 2021, at 09:39, Jiayihao <[email-masked]> wrote:
> > 
> > Hi Stewart,
> >  
> > I followed the ISO 8473 specification and find that a ???flexible address structure??? is similar to it.
> >  
> > ISO 8473 has a variable address length with a <len> field, while for the flexibility described in the ???flexible address structure??? draft, the flexibility refer to both a) variable length; 2) new semantics. ISO 8473 do cover the variable length, but semantics is not mentioned in it. So a new semantics carried address could be a main difference compared to ISO 8473.
> >  
> 
> The way that an ISO 8473 address works is that at the protocol level it has the length - so it definitely supports variable length. Within the address itself which I think is covered by a different standard, the address starts with an address family indicator (AFI) which is one octet, though you could of course expand that by creating subfamilies in the following octet. The way you get the additional semantics and multiple address types is through the AFI mechanism. 
> 
> Thus ISO 8473, which as I point out is an international standard and thus avoids a lot of SDO politics is a protocol capable of supporting variable length and variable types and thus variable semantics.
> 
> You mention TRIE, when we built the high performance Decnet routers many years ago we had an ASIC TRIE engine and it used to process, Decnet PhV, Decnet PhIV (native and embedded in PhV), IPv4 and IEEE MAC addresses from the same table. It would have done IPv6 address if they has been invented when we built the product.
> 
> So there is an international standard and a forwarding framework that works for most of what you want to do. Whether you want to take a different approach or not is up to you, but you do have a way of finessing many of the standards issues that you face with a new network layer protocol.
> 
> - Stewart
> 
> 
> > Thanks,
> > Yihao
> >  
> > ?????????: Stewart Bryant [mailto:[email-masked] <mailto:[email-masked]>] 
> > ????????????: 2021???2???3??? 20:50
> > ?????????: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; int-area <[email-masked] <mailto:[email-masked]>>
> > ??????: Stewart Bryant <[email-masked] <mailto:[email-masked]>>
> > ??????: Using ISO8473 as a network layer to carry flexible addresses
> >  
> > Re drafts:
> >  
> > https://datatracker.ietf.org/doc/draft-jia-scenarios-flexible-address-structure/ <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jia-scenarios-flexible-address-structure%2F&data=04%7C01%7Ckiranm%40futurewei.com%7C95b5d102feaf4674ab8408d8c7972448%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637478799262464227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yDi0mFnbU60nFC5PJC%2BAAWVIdSMT%2FY8UO0XIiK3J4iI%3D&reserved=0>
> > https://datatracker.ietf.org/doc/draft-jia-flex-ip-address-structure/ <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jia-flex-ip-address-structure%2F&data=04%7C01%7Ckiranm%40futurewei.com%7C95b5d102feaf4674ab8408d8c7972448%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637478799262464227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XB9VFEQiaa0ZMjG5BuF%2FPeQnvFcmGgfY0%2Bye4s7CSoA%3D&reserved=0>
> > Since the authors are interested in network layer protocols that support multiple address types and multiple address lengths, I wonder if they have considered using ISO8473 as the bearer and developing that to their needs?
> > ISO 8473 is also known as ITU X233 (it costs money to download from ISO, but seems to be free from the ITU-T site). It is an in force and actually well deployed network layer protocol with many similar characteristics to IPv6. The reason that it is deployed is that it is used to support SS7. It also has a very widely deployed link-state IGP since IS-IS was developed to support ISO8474 and later adapted to support IP late run its life. 
> > It was one of the contenders for IPv4 replacement, and so there RFCs that authors may study: RFC994 is a copy of the late version of the spec in RFC format. Then there is RFC1195 where Ross Callon shows how it works in an IETF environment carrying IETF transport protocols and this eventually became RFC1347 (TUBA), which whilst whilst marked Historic in the IETF RFC collection is almost certainly still implementable since the base network layer protocol is still an active standard.
> > It would need some work to determine the applicability of the protocol to your application and the feasibility of adding the necessary new address types (due to crowding of the existing address registry) and any other extensions that you might need.
> > Note BTW that it supports source routing functionality and so ought to be usable in an SR environment should that be needed.
> > There would also need to be work to see how feasible it would be to implement in a modern NPU, though having implemented it in a hardware assisted microcode platform that is quite similar to a modern NPU back in the 90s and having got quite creditable performance I think it is feasible to run this on modern hardware including repurposing the existing longest match engine to look up a number of your new address formats. 
> > There are a bunch of specs here for your convenience although I have not studied the list in detail
> > http://www.networksorcery.com/enp/protocol/clnp.htm <http://www.networksorcery.com/enp/protocol/clnp.htm>
> > Best regards
> > Stewart
> 

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Mar 2021 09:08:10 +1300

Hi Toerless,
On 02-Mar-21 04:33, Toerless Eckert wrote:
> 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.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 1 Mar 2021 14:46:25 -0600

On Mon, Mar 1, 2021 at 2:08 PM Brian E Carpenter <
[email-masked]> wrote:

> 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.
>
>
Well said :)

Behcet

> 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
>

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 2 Mar 2021 10:20:33 +0100

Hi Brian,

> (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 fa…

How do you come to that conclusion ? IP Multicast where it is business relevant is
also not deployed as an overlay, and neither is BIER in the SP deployments where
the original use-cases come from.

But IMHO underlay vs. overlay is just a red herring: Any hop-by-hop forwarding protocol
ultimately is some form of overlay/underlay to some other and overlays are always
an important tool for early adoption. That does not change the need to support
flexible addrss length in one hop-by-hop protocol so that it can become a common
framwork for multiple semantics.

Of course, if i only use CPU-forwarding overlays, the cost of duplicating system
infrastructure by reinventing the whole protocol stack goes down. E.g.: if i
could build a service out of let's say only BIER, and forwarder and end-points
is all software i own, i could clone everything from IPv6, change length to 256
and call it a day. But we do know that actual solutions need access to all semantics,
as is also obvious from unicast + multicast example.

Whereas BIER duplicated the network header and is therefore a bit like the VM 
approach DCs, where 90% of code is duplicated (OS/libs), the integrated multi-semantic
network protocol is like the container approach in DC.

> 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 i…

Sure. And i think like the VM/container comparison, duplicating everything
at network layer when you need a new semantic might even get you 
started quicker, but over the long term the duplication cost outweights
this. I would argue this is exactly what we also see in the duplication
between IPv6 and IPv4. Of course, no one is to blame for this because there
was a rightfull hope for IPv4 to go away, when we look back at our more
naive selfs of the 1990th (at least thats what i believed, but that was before
i was exposed mayorly to all those 90% of limited domain networks you don't
see if you only "live on the Internet").

> 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.

I think we need to distinguish a bit between the enabling of opportunities
that a technology offers and the ability of specific business models of
operators to absorb and utilize those. Of course we do have more fundamental issues
wrt. to creating new revenue through new technologies than simply building beter
network protocols. But better network protocols are IMHO a key building block.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Liguangpeng (Roc, Network Technology Laboratory)" <[email-masked]>
Date: Tue, 2 Mar 2021 10:50:07 +0000

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:[email-masked]] 
Sent: Tuesday, March 2, 2021 4:08 AM
To: Toerless Eckert <[email-masked]>; Stewart Bryant <[email-masked]>
Cc: [email-masked]; [email-masked]; int-area <[email-masked]>; Jiayihao <[email-masked]>
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.

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

    Brian

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 2 Mar 2021 12:32:48 +0000

> On 1 Mar 2021, at 20:08, Brian E Carpenter <[email-masked]> wrote:
> 
> 

Hi Brian

Basically I think that this fails the backwards compatibility text.

It is perfectly legitimate to write an IPv6 forwarder as follows:

If MACaddress == me and MACtype == IPv6 pass packet to IPv6 forwarder

In IPv6 forwarder:

If version == IPv6 and Hop Limit not exceeded send bytes 24 to 39 to address lookup engine

Wait for address result and forward packet accordingly

Except that this forwarder would have sent a bunch of random junk to the ALE consisting of some of the SA and maybe some of the DA depending on their sizes.

So to stop an old and legitimately designed parser being fooled you really have to use a new MAC type and a new version and as soon as you do that you might as well design the packet optimally for the job at hand.

If the IPv6 designers had followed the strategy of both the Ethernet designers and the ISO8473 designers and put DA before SA then the elegant approach that you and others have  proposed at various times would have worked nicely.

Best regards

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 2 Mar 2021 13:53:12 +0000

> On 1 Mar 2021, at 15:33, Toerless Eckert <[email-masked]> wrote:
> 

Toerless

I don’t think there is a simple backwards compatible approach, but we can probably do more than we do today.

Backwards compatible means that you could put your new packet into a IPv6 parser and it would correctly forward the packet as if nothing had changed.

You could I suppose put a well known IPv6 address in the IPv6 header and put the real address in an extension header, perhaps including the pointer to the address in the suffix of the IPv6 address to make finding the EH much faster, but I am not sure that is backwards compatible.

I suppose it might be able to do a bit better if the address in the IPv6 DA was the DA of the egress router and old routers did best effort to the egress and newer routers knew to take a look at the extension header for more detail.

I think that it is worth thinking about how we could do better than we do today, but I think we need to be careful with the term backwards compatible.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 2 Mar 2021 14:07:08 +0000

> 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.

Answering this separately.

You are correct that it would take years for it to be deployed on the big I internet, and it is a rollout of staggering proportions,

However more and more traffic is going to flow between the client and a server embedded close to the edge. Furthermore there is a world developing where IP/UDP is used to tunnel from client application to server, and where there is no fixed constraint on what actually runs over that UDP/IP tunnel - it is a private matter for the application designer. If and it is a big if, there was a compelling competitive advantage in say mobile networks in using a new packet design to get from the application to the MEC server, then you could see a new design rolling out in a series of well controlled restricted domains. The point being that in such domains the overwhelming scale issues associated with the big I internet may not apply.

The driver for this would need to be an application that had an overwhelming advantage if it used such a change. I am not yet sure I know what that application is, but given the huge network and application transitions we see I would not bet that such an application would never emerge,

- Stewart

---

From: "Liguangpeng (Roc, Network Technology Laboratory)" <[email-masked]>
Date: Tue, 2 Mar 2021 14:21:56 +0000

Hi Stewart,

Backwards compatible should be always good thing for investment protection. Except “could put your new packet into a IPv6 parser”, another possible approach is the last new forwarder translate new packet to IPv6 packet (may encapsulate new fields in extension header), and passthrough in IPv6 domain. Then the first new forwarder adjacent to IPv6 forwarder must recognize IPv6 encapsulation and traversing all extension headers to form new packets if next hop is new forwarder.

Guangpeng Li

From: Stewart Bryant [mailto:[email-masked]]
Sent: Tuesday, March 2, 2021 9:53 PM
To: Toerless Eckert <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; Jiayihao <[email-masked]>; [email-masked]; int-area <[email-masked]>; [email-masked]
Subject: Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

On 1 Mar 2021, at 15:33, Toerless Eckert <[email-masked]<mailto:[email-masked]>> wrote:

Toerless

- Stewart

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 2 Mar 2021 15:42:54 +0100

Thanks, Stewart, inline..

On Tue, Mar 02, 2021 at 01:53:12PM +0000, Stewart Bryant wrote:
> I don???t think there is a simple backwards compatible approach, but we can probably do more than we do today.
> 

Lets say for the sake of argument, IPv6 multicast routing would have been added after IPv6 (unicast)
was first specified, as it actually was in IPv4 (but nobody wants to hear IPv4 stories now *sob* ;-).

Adding IPv6 multicast would then also not have been a backward compatible
extension in your definition. As would likely be any interesting new semantic to be added - whether
or not that semantic requires packet header changes or not. So i think your definition of
backward compatible is too constraining:

In my definition, IPv6 multicast was backward at the system level because it allowed/allows IPv6
unicast to continue to exist and evolve as if IPv6 multicast didn't exist. With the only
limitation that some address planning was/is needed to be able to carve out unused address
space for new semantics.

With this definition of backward compatibility i can equally introduce in a backward
compatible fashion new addresses longer or shorter than 128 bit through arbitrary packet
header enhancemeents, because all i need is to observe that the format on the wire of
consenting subnet adjacent routers is nobodies business but theirs - as long as they
manage to stay backward compatible in my definition. And when we utilize additional
packet header fields or different addrss lengths, we would not even have to carve
out more from existing IPv6 address space like we logically had to do for IP multicast
and avoid further overloading of this address space (as Tony i think observed to be a problem).

That all being said: Of course, we can and should try to promote more fundamental
enhancements to the definition of forwarding machineries to allow future extensions
of semantics to be possible in-line with your definition of backward compatibility, but
that i think a lot more ambitious.

Cheers
    Torless

-- 
---
[email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 2 Mar 2021 15:29:04 +0000

Hi Toerless

I believe that IPv6 multicast comes in on its own MAC address so the multicast engine run rather than the unicast address.

In any case if the parser got an IPv6 packet, it would know from the DA that it was multicast.

So I think you actually have a new packet, but with the same packet layout for both m/c and u/c.

I am still struggling to see what a compatible packet looks like, thought I did not a couple of ideas in my other reply.

- Stewart

> On 2 Mar 2021, at 14:42, Toerless Eckert <[email-masked]> wrote:
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 2 Mar 2021 16:50:57 +0100

Le 01/03/2021 à 21:08, Brian E Carpenter a écrit :
[...]

> 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.

Hi, Brian,

I am very happy to see this problem mentioned here!

I would like to help progress on this deployment issue.

I might tend to agree that the problem of shorter-than-64 at cellular
operator is more a deployment issue, rather than a standards issue.
It's a deployment issue in that it would be sufficient that a 3GPP
operator sets a parameter in the big router facing the smartphone.  That
parameter sets the prefix length to be e.g. /56 and then that's it.
It's like when somebody configures an address on an interface or sets a
routing table entry - a mostly local matter.

However, there might be benefit from looking closer at this deployment
issue.

This deployment issue affects principally the 3GPP organisation.  An
oppinion explains that it might be sufficient to do something at 3GPP
about shorter-than-64 prefixes and subsequently all operators
implementing these 3GPP standards might permit allocation of
shorter-than-64 prefixes to end users.  It sounds natural.

But there are several aspects of the problem that were revealed in the
past about this kind of standards work:

- the positive: there would be a need of an Internet Draft (something
   that one might qualify as standards work at IETF) that 3GPP could
   refer to.  This draft might need to explain the requirement.  Then,
   3GPP could refer to this I-D, and make it a 3GPP requirement on its
   own.  It is probably that 3GPP document that the cellular operators
   might abide to.  And these two documents can easily be qualified as
   'standards work', I suspect.

- the negative: one should worry that in the past the 3GPP has written
   documents in which DHCPv6 Prefix Delegation is required on the UE and
   in the Core.  However, that 3GPP document is not implemented at any
   cellular operator.  As such, this could be considered a sort of
   'mistake', if I can say so.  This should not be repeated, if I can say
   so.

- there is a second negative, this time at IETF.  There is an RFC 7849
   "IPv6 Profile for 3GPP Mobile Devices" which
   clearly sets a requirement that the mobile must support DHCPv6-PD.
   That requirement is completely overlooked - no smartphone supports
   DHCPv6-PD.  Not only it's extremely rare to see a DHCPv6 PD client in
   a smartphone but their modems block DHCPv6 outright.  This again can
   be considered to be a sort of 'mistake' that should be avoided.

   We should not write another RFC or I-D that says something that nobody
   implements.

Alex

> 
> (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
> 
> _______________________________________________ Int-area mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 2 Mar 2021 15:51:00 +0000

> On 2 Mar 2021, at 14:21, Liguangpeng (Roc, Network Technology Laboratory) <[email-masked]> wrote:
> 
> Hi Stewart,
>  
> Backwards compatible should be always good thing for investment protection. Except “could put your new packet into a IPv6 parser”,

> another possible approach is the last new forwarder translate new packet to IPv6 packet (may encapsulate new fields in extension header), and passthrough in IPv6 domain.

> Then the first new forwarder adjacent to IPv6 forwarder must recognize IPv6 encapsulation and traversing all extension headers to form new packets if next hop is new forwarder.

If you could write down the two formats and describe the mappings that would make people reading this thread feel a lot more comfortable that this is feasible. It would also enable everyone to understand any limitations and constraints with the approach you propose.

- Stewart

> Guangpeng Li
>  
> From: Stewart Bryant [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Toerless Eckert <[email-masked] <mailto:[email-masked]>>
> Cc: Stewart Bryant <[email-masked] <mailto:[email-masked]>>; Jiayihao <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; int-area <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On 1 Mar 2021, at 15:33, Toerless Eckert <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Mar 2021 09:15:04 +1300

On 03-Mar-21 01:32, Stewart Bryant wrote:
> 
> 
>> On 1 Mar 2021, at 20:08, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>

Short answer: that's why the Internet would be opaque to it for many years.

Longer answer: change every router in the universe (exactly what we did to achieve the universal deployment of IPv6). At that point, changing the ethertype/IP version is really not that different than demultiplexing packets by looking at the first byte of the source address.

But I am not seriously advocating any of this. If I'd believed this was a viable approach, I would have advocated one of the IPng proposals that extended IPv4 addressing in that way.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Mar 2021 09:25:49 +1300

> the original use-cases come from.

Sure. I co-authored the "limited domains" RFC, right? But when you look at Internet-wide deployment (which is surely the target for ICN, and was the original target for multicast), an overlay seems to impose itself.

> framwork for multiple semantics.

When 128 bits runs out, yes. 

Oh, I should point out that we did have a run at this topic a few years ago: https://tools.ietf.org/html/rfc1888, especially sections 4 and 5.

    Brian

---

From: "Liguangpeng (Roc, Network Technology Laboratory)" <[email-masked]>
Date: Wed, 3 Mar 2021 02:42:52 +0000

Hi Stewart,

Your suggestion is absolutely right. Here, I do not mean to propose any solution, but just to share an understanding of ‘backwards compatible’. If some people interest much about this approach, I’d like to join the creation of a draft on this. It should not be so hard to design the core algorithm.

Guangpeng
From: Stewart Bryant [mailto:[email-masked]]
Sent: Tuesday, March 2, 2021 11:51 PM
To: Liguangpeng (Roc, Network Technology Laboratory) <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; Toerless Eckert <[email-masked]>; Jiayihao <[email-masked]>; [email-masked]; int-area <[email-masked]>; [email-masked]
Subject: Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

On 2 Mar 2021, at 14:21, Liguangpeng (Roc, Network Technology Laboratory) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Stewart,

- Stewart

Guangpeng Li

From: Stewart Bryant [mailto:[email-masked]]
Sent: Tuesday, March 2, 2021 9:53 PM
To: Toerless Eckert <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; Jiayihao <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; int-area <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

Toerless

- Stewart

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 3 Mar 2021 08:46:09 +0100

On 2021-03-03, at 03:42, Liguangpeng (Roc, Network Technology Laboratory) <[email-masked]> wrote:
> backwards compatible

I would suggest not to center the discussion on terms that are so overloaded that they are essentially meaningless.

Some believe “backwards compatible” means “does not break existing applications”. That is a low bar (but not trivial either).  It does not imply any form of deployability in the sense of actually making the scheme work.

Some believe “backwards compatible” means “seamlessly integrates existing infrastructure” (maybe with the exception that certain benefits do not accrue until that is upgraded).  That has essentially been the basis for all major innovation that has happened in the Internet, with the exception of IPv6 (and you know how long that took and still is taking in some parts of the world).

Terms like “backwards compatible” are, however, useful for derailing the discussion if that is one’s intention, because quickly the discussion will be about the terms and no longer about the subject.

Grüße, Carsten

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 3 Mar 2021 10:48:39 +0100

Le 03/03/2021 à 08:46, Carsten Bormann a écrit :
> On 2021-03-03, at 03:42, Liguangpeng (Roc, Network Technology 
> Laboratory) <[email-masked]> wrote:
>> 
>> backwards compatible
> 
> I would suggest not to center the discussion on terms that are so 
> overloaded that they are essentially meaningless.
> 
> Some believe “backwards compatible” means “does not break existing 
> applications”. That is a low bar (but not trivial either).  It does 
> not imply any form of deployability in the sense of actually making 
> the scheme work.

I agree.

The 'backwards compatibility' concept has many facets.

I could say that using an ISO network layer is backwards compatible in
that it does not break existing IP network layers.  The EtherType in the
layer below makes sure there is a right distinction.

But, has this been tried in practice against many systems?  Have people
sent ISO network layer packets to computers that only implement IP and
that might not have an EtherType value for ISO in their link layer of
their stacks?  What happens them?  Maybe it is just an error reported,
or maybe the system segfaults outright.

This can be looked up closer.

> Some believe “backwards compatible” means “seamlessly integrates 
> existing infrastructure” (maybe with the exception that certain 
> benefits do not accrue until that is upgraded).  That has
> essentially been the basis for all major innovation that has happened
> in the Internet, with the exception of IPv6 (and you know how long
> that took and still is taking in some parts of the world).
> 
> Terms like “backwards compatible” are, however, useful for derailing 
> the discussion if that is one’s intention, because quickly the 
> discussion will be about the terms and no longer about the subject.

If one is to derail discussion, one would also point to 'future proof'
aspects of newly designed protocols.  Designing something today that
might not work in the future is not advantageous.

Putting an IPv6 implementation in a computer that only does IPv4 makes
sure that computer is future proof for when IPv6 arrives.

But can one say that putting an ISO network layer in a computer that
only does IPv4 and IPv6 is future proof for when ISO arrives?  Is there
a plan for deployment of ISO network layer?  Like IPv6 had a plan with
the 6bone, 3ffe prefixed addresses, and the 'island' concept?

Alex

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 3 Mar 2021 10:14:48 +0000

> On 2 Mar 2021, at 20:15, Brian E Carpenter <[email-masked]> wrote:
> 

Fundamental to moving this discussion forward is an understanding of what the future structure of the Internet will be.

Will it be the classical model of client-edge-aggregation-core-agregarion-edge-server with large quantities of traffic going through the core, or will it be client-edge-server for the majority of traffic with server-server to build the application running in a private network and only a minority of traffic still running using the classical model?

If the Internet evolves to the client-edge-server model there is an opportunity to migrate away from the worst effort model that currently constrains us, to a model that provides the service that the customers are prepared to pay for.

If there is a viable commercial case for higher quality services provided at the edge, then than will happen, regardless of any decisions we took 20 years ago which currently limit our ability to evolve the network layer, and regardless of any position that the IETF takes to block it. At the end of the day it all comes down to economics, and it is currently unclear whether the classical model will prevail or a new model will develop, or indeed if there is a change, when and how fast it will transition.

- Stewart

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 3 Mar 2021 11:05:42 +0000

Hello Stewart, Brian and Toerless:

Interestingly RFC 8138 took one step in that direction. Yes you’re going to need a new Ethertype but it’s still IPv6 I. That is is expressed as a compression not a modification of IPv6.

 In the compressed form the header starts with the next hops, the destination and SRH being indiscriminated, the destination is just the first of the list. The size is variable but each hop is at most 128 bits. Because the SRH could encode SRv6 you can already go a long way with this.

If that can help you do what you want, I m happy to explain more...

Keep safe.

Pascal

Le 2 mars 2021 à 13:33, Stewart Bryant <[email-masked]> a écrit :

On 1 Mar 2021, at 20:08, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

Hi Brian

In IPv6 forwarder:

Best regards

Stewart

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 3 Mar 2021 13:51:09 +0100

Hi,

> On 3 Mar 2021, at 12:05, Pascal Thubert (pthubert) <pthubert=[email-masked]> wrote:
> 
> Interestingly RFC 8138 took one step in that direction. Yes you’re going to need a new Ethertype but it’s still IPv6 I.

IMHO, from an architectural point of view I would argue that it is a different L3 protocol: different header; different forwarding machinery;

The fact that has been designed to be « compatible » with IPv6, where a simple method exists to translate one in the other, basically having a one-to-one mapping,  is a different thing. 

Yet, I would also add that the real objective of the discussion is whether or not it exists a sufficiently general mechanism that enables the same feature (as for RFC 8138)  among different limited domains.

If it exists, what is the general addressing « model » (for lack of a better term) that would accommodate such a requirement or allow to create such a general solution?

Ciao

L.

> That is is expressed as a compression not a modification of IPv6.
>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 3 Mar 2021 14:18:09 +0100

Carsten:

Thank you, fully agree. The first time i saw "backward compatibity" pop up in
these discussions was in questions from ISOCI people in discussions
about future evolution of IP/Internet - of course without any clear
specification or reference as to what they actually meant with it.

Would be good to come up with more precise terminology around
characerizations of relationships between stages of an evolutionary
path in networking though.

Then again, IETF isn't particularily fond of creating
output that can not be hacked into C (oops: these days javascript).

But noting how NMRG is doing a fine jobs on trying to write down
what Intent is (terminology/taxonomy), maybe there is a job
for an IRTF group to do a similar job creating a better terminology
to describe such evolutionary characteristics as they relate to
networking. Otherwise it will continue to be hard to even talk about
such networking evolution without being, as you said just be sidelined.

Cheers
    Toerless

On Wed, Mar 03, 2021 at 08:46:09AM +0100, Carsten Bormann wrote:
> Some believe ???backwards compatible??? means ???does not break existing applications???. That is a low bar (but not trivial either).  It does not imply any form of deployability in the sense of actually making the scheme work.
> 
> Some believe ???backwards compatible??? means ???seamlessly integrates existing infrastructure??? (maybe with the exception that certain benefits do not accrue until that is upgraded).  That has essentially been the basis for all major innovation that has happened in the Internet, with the exception of IPv6 (and you know how long that took and still is taking in some parts of the world).
> 
> Terms like ???backwards compatible??? are, however, useful for derailing the discussion if that is one???s intention, because quickly the discussion will be about the terms and no longer about the subject.
> 
> Grüße, Carsten
> 

-- 
---
[email-masked]

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 4 Mar 2021 07:03:04 +0100

> On 3 Mar 2021, at 14:18, Toerless Eckert <[email-masked]> wrote:
> 
> Carsten:
> 

+1

I think is a good idea. Would be nice to have something like that.
To be complete it should not look only at the “backward” part but also to the “forward” part, covering things like incremental deployability.

Ciao

L.