Re: New draft: carrying/renumbering assigned prefixes in IS-IS/OSPFv3 (lsr-v6ops-pd-aargh-00)

Hi David, 

I thought that DHCPv6 Prefix Delegation (PD) could have multiple levels of delegation and that mechanism alone could be used for assignment within a domain?  I must admit that it has been a very long time since the home net WG discussions. 


Thanks,
Acee

> On Jul 26, 2023, at 18:08, David 'equinox' Lamparter <[email protected]> wrote:
> 
> 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