Re: [v6ops] Updating RFC 7084

Flat vs hierarchical prefix assignment.

Hierarchical assignment does route summarisation "naturally". That's not very important in such a small network. Even a /48 has only 64K subnets. That's a small RIB/FIB.

Hierarcihcal uses the prefix space inefficiently. If the prefix space is split equally at each level, then in an unbalanced tree, you end up with an unoptimal use of prefixes. That matters when a user is allocated just a /60 for example.

Not all networks are built with a hierarchical topology.

In a hierarchical toplogy, addressing follows the hierarchy. In a flat approach you could imagine not having to renumber a link, just because there was a topology change.

There are some differences in ther mechanics, but I think the underlaying problems are the same:

- you need to build a spanning tree of DHCP relays (flat) and DHCP servers (in hierarchical)
- you need to have a mechanism to negotiate the owner of a link in the case of multiple routers attached
- you need to figure out how to deal with multiple sources of information. i.e. multiple prefixes provided by multiple edge routers (aka multi-homing)

Because of these problems, I don't think this work is something that can/should be done within v6ops. It requires protocol work.

O.

> On 2 Dec 2022, at 10:47, Olorunloba Olopade <loba.olopade=40virginmediao2.co.uk@dmarc.ietf.org> wrote:
> 
> By topology, I’m referring to layer 3 topology of the infrastructure. Sorry, but I didn’t get your explanation. With respect to the later 3 infrastructure, you would have the routers being dhcp servers. Hence, the resulting tree is representative of how the routers in the network are interconnected. That will always happen, not by accident. In the case of a flat structure, it would only happen if the underlying layer 3 topology is flat.
>  Another advantage of this is that you have address summarisation at the right places.
>  The limitation I’m referring to is not 64 bit boundary for SLAAC. But the inability to do any form of address summarisation on the network.
>  As per example, I would refer you to the one I gave previously.
>  To address some of the other points you raised
> No, it is not about the single DHCP server vs multiple. In the flat model, you could still choose to turn on DHCP server on the LAN interfaces behind the routers. In which case, you still end up with multiple DHCP servers. I’m assuming here that you are not thinking of relaying IA-NA request to the ISP CE. If this is the case, it over-complicates the implementation of the DHCP server on the CE, as it has to include the processing of dhcpv6 link-address.
>  Continuing from previous point, similar argument for the flat system having a single source of truth.
>  Disagree with notification being less complex. You still have the same amount of routers to reprogramme, but a whole lot more routes.
>  Loba
>  From: Ted Lemon <mellon@fugue.com> 
> Sent: 01 December 2022 13:40
> To: Olorunloba Olopade <loba.olopade@virginmediao2.co.uk>
> Cc: Olorunloba Olopade <loba.olopade=40virginmediao2.co.uk@dmarc.ietf.org>; IPv6 Operations <v6ops@ietf.org>
> Subject: Re: [v6ops] Updating RFC 7084 - alternate logic
>  On Thu, Dec 1, 2022 at 8:34 AM Olorunloba Olopade <loba.olopade@virginmediao2.co.uk> wrote:
> Yes, I recognised that point was subjective, and did not try to make it look different.
>  Were these not technical points, that were previously stated? I could go on as well.
>     • Resulting tree mirrors topology
> 
>  If you allocate /64s one at a time, then the resulting tree will always exactly mirror the topology of the network. If you subdivide prefixes and have multiple servers, then allocation may sometimes accidentally mirror topology, but e.g. in the case of stub networks will never match topology except when resources are so scarce that the delegating router coincidentally allocates /64s—the behavior that I am arguing should be the default behavior, and not an accident.
>  
>     • Removes limitation on a specific prefix size
> 
>  This limitation is baked into the internet addressing architecture. We can't remove it by using an inefficient allocation model.
>  
>     •  
>     • More flexible design
> 
>  Can you give an example of how the multiple-server approach is "more flexible"? 
> 
> 
>  
> Save Paper - Do you really need to print this e-mail?
>  This email contains information from Virgin Media and/or Telefonica UK Limited (O2) and may be confidential and legally privileged. Statements and opinions expressed in this email or any attachment may not represent either those of Virgin Media or Telefonica UK Limited. Any representations or commitments in this email or any attachment are subject to contract.  The information in this email is intended solely for the attention of the addressee(s) and if you are not the intended recipient please delete it (including any attachment) from your system, and be aware that any disclosure, copying distribution or use of any of this information is not permitted.
>  If you are in receipt of a suspicious email or you have received an email in error from Virgin Media, please report it to www.virginmedia.com/netreport, or for Telefonica UK Limited (O2), please report it to www.o2.co.uk/help/safety-and-security. 
>   Registered offices:
>   Virgin Media Limited, 500 Brook Drive, Reading, RG2 6UU. Registered in England and Wales: 2591237
>   Telefonica UK Limited, 260 Bath Road, Slough, Berkshire SL1 4DX. Registered in England and Wales: 1743099
>   VMED O2 UK Limited, Griffin House, 161 Hammersmith Road, London, United Kingdom, W6 8BS. Registered in England and Wales: 12580944
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops