It looks like almost nobody cares about CLNP anymore. On Tue, Jul 13, 2021, 6:27 PM Toerless Eckert <[email protected]> wrote:
> On Wed, Jul 14, 2021 at 10:25:02AM +1200, Brian E Carpenter wrote: > > > From a background POV it is worth noting ISO 8473 which is in > deployment with multi-type variable length address. > > > > Pretty ugly and limited though, and as I understand it the major > (unclassified) deployment, in the airline trade, is trying to migrate away. > I have no idea if there are classified deployments, but if so, I expect > they use the non-variable GOSIP format. > > Maybe a side-thread better moved over to intenet-history ? > At least let me change the subject. But i am curious, > because before IPv6 came along i was very > much hoping to see benefits of CLNP to go into IP-NG. > > I am specifically a fan of routing host-addresses within a domain > because i think its the mayor reason for Ethernet subnets to eat IP > for breakfast (displaying more and more L3 at the edge). Even back > in the beginning of the 90th i did do IP host routing with RIP for > multi-homed hosts. So i had hoped IPv6 to include this benefit > of CLNP. Or at least a decade later MIF. > > No memory of the specific of variable length addressing in CLNP though > I know i had different length addresses in CLNP deployment in the 90th, > but within a university i did (of course?) not recognize any of the > extension/operational benefits that much. > > Btw: Completely agree the administrative decision for IETF not to invest > into CLNP given the ownership of the protocol by a politicised SDO, > but re-using good idea instead of NIH would really be nice. > > Cheers > Toerless > > > I think ISO 8473 is a pretty good model of how not to do it. > > > > > It is also worth noting that SA is different from DA to the extent > that > > it may not belong in the network layer header of the outgoing packet. > The > > SA is arguably a function of the payload and the application. Indeed > some > > MPLS OAM solutions do just that by making the return address implicit in > the arrival LSP, or a parameter in a payload TLV. SA as in IP is arguably > > just a convenience for a simplified method of operating an application. > > > > My favourite article on that topic is > https://www.cl.cam.ac.uk/techreports/FUCAM-CL-TR-849.pdf > > > > Brian > > > > > > > > Stewart > > > > > > Sent from my iPad > > > > > >> On 13 Jul 2021, at 00:05, Toerless Eckert <[email protected]> wrote: > > >> Dear Int-area > > >> > > >> As attached below, i have written up an idea about why and how > variable-length > > >> addresses in the network layer would be useful for many limited > domain > > internetworks, > > >> but also how they could provide a simple and easily extensible > framework to > > >> add additional semantics (the likes of multicast, BIER, ICN), and > also > > make it easier > > >> to express the programmability that SRv6 introduced. > > >> > > >> Would very much welcome discussion/feedback, and will be asking for a > slot > > >> to present/discuss this int-area 111. > > >> > > >> Note that the -00 writeup is mostly inspirational for what i think > the > > cool > > >> things one could do with it are and to explain the concepts. > > >> > > >> Obviously, if/when there is interest in this > > >> direction, the harder work of figuring out how to best introduce this > > >> incrementally, and ideally backward compatible into existing networks > wold > > >> be the next big set of items to work out. > > >> > > >> Cheers > > >> Toerless > > >> > > >> On Mon, Jul 12, 2021 at 01:00:25PM -0700, [email protected] > wrote: > > >>> A new version of I-D, > draft-eckert-intarea-functional-addr-internets-00.txt > > >>> has been successfully submitted by Toerless Eckert and posted to the > > >>> IETF repository. > > >>> > > >>> Name: draft-eckert-intarea-functional-addr-internets > > >>> Revision: 00 > > >>> Title: Functional Addressing (FA) for internets with > Independent Network Address Spaces (IINAS) > > >>> Document date: 2021-07-12 > > >>> Group: Individual Submission > > >>> Pages: 30 > > >>> URL: > https://www.ietf.org/archive/id/draft-eckert-intarea-functional-addr-internets-00.txt > > >>> Status: > https://datatracker.ietf.org/doc/draft-eckert-intarea-functional-addr-internets/ > > >>> Htmlized: > https://datatracker.ietf.org/doc/html/draft-eckert-intarea-functional-addr-internets > > >>> > > >>> > > >>> Abstract: > > >>> Recent work has raised interest in exploring network layer > addressing > > >>> that is more flexible than fixed-length addressing as used in IPv4 > > >>> (32 bit) and IPv6 (128 bit). > > >>> > > >>> The reasons for the interest include both support for multiple and > > >>> potentially novel address semantics, but also optimizations of > > >>> addressing for existing semantics such as unicast tailored not for > > >>> the global Internet but to better support private networks / > limited > > >>> domains. > > >>> > > >>> This memo explores in the view of the author yet little explored > > >>> reasons for more flexible addresses namely the problems and > > >>> opportunities for Internetworking with Independent Network Address > > >>> Spaces (IINAS). > > >>> > > >>> To better enable such internetworks, this memo proposes a framework > > >>> for a Functional Addressing model. This model also intends to > > >>> support several other addressing goals including programmability > and > > >>> multiple semantics. > > >>> > > >>> > > >>> > > >>> > > >>> The IETF Secretariat > > >> > > >> -- > > >> --- > > >> [email protected] > > >> > > >> _______________________________________________ > > >> Int-area mailing list > > >> [email protected] > > >> https://www.ietf.org/mailman/listinfo/int-area > > > > > > _______________________________________________ > > > Int-area mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/int-area > > > > > > > _______________________________________________ > > Int-area mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/int-area > > -- > --- > [email protected] > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
