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

[Toerless Eckert <[e-mail]>]

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 <[e-mail]> 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:[e-mail] <mailto:[e-mail]>] 
> > ????????????: 2021???2???3??? 20:50
> > ?????????: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; int-area <[e-mail] <mailto:[e-mail]>>
> > ??????: Stewart Bryant <[e-mail] <mailto:[e-mail]>>
> > ??????: 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area


-- 
---
[e-mail]