TL;DR: skim the excerpts below, only looking for Yay/Nay.
Hi lsr & v6ops WGs, prompted by some presentations and chats in the past days, I've dug up this old thing that we looked at in some autoconf & multihoming context, made it presentable and uploaded it. On Wed, Jul 26, 2023 at 02:48:34PM -0700, [email protected] wrote: > Name: draft-lamparter-lsr-v6ops-pd-aargh > URL: > https://www.ietf.org/archive/id/draft-lamparter-lsr-v6ops-pd-aargh-00.txt > Html: > https://www.ietf.org/archive/id/draft-lamparter-lsr-v6ops-pd-aargh-00.html Before any LSR people get a heart attack, this is in its entirely separate little world of prefix/address management and explicitly excludes any interaction with routing data/calculation. But first, what it does - it simply puts your assigned prefix(es) into your link-state routing protocol. (*Once*, at the network boundary to your uplink. Not per link/subnet/router/...) From there you can then derive prefixes and addresses. The idea is extremely simple, though it does need a bunch of plumbing. (I've entirely handwaved OSPF areas and IS-IS L1/L2.) Here's some excerpts: "Between large enterprise networks that can reasonably use their own IPv6 address space and small home and office networks that do not utilize a complex routing topology, there is an intermediate space where a network may need to utilize a nontrivial routed topology but still connect to the internet in a plain "customer" role, with IPv6 address space being assigned over e.g. DHCPv6-PD" "This document takes a "router-down" perspective without attempting to take all address management and policy out of the operator's hands. " "Only communicating available prefixes and making subnets or host addresses out of them is considered here. How to apply the results to an innumerable amount of entities that may need reconfiguring or flushing of state [...] is a giant of its own." "At its most basic, to establish IPv6 reachability given a number of (working) lower layer links, two things are needed: addresses and routing information. When the routing domain has come up, the network should work, and if addresses are assigned statically, it hopefully will. This mechanism attempts to not worsen this situation - the network should work after routing has come up." "This document does not attempt any kind of automatic prefix or address assignment in the "second half" of the prefix. It only attempts a mechanism to convey the "first half" of a prefix, and deal with changing it - while keeping the second half firmly under operator control" That said, at this point I'm hoping to just get a bunch of "yay" or "nay"s on whether this might be worth progressing. Even reading it in its entirety might be wasted effort at this point ;) Cheers, -equi (David) P.S.: the title originally ended with "... Handling", hence the document name. _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
