Re: [v6ops] Updating RFC 7084

Hi Ole,

Thanks for the summary, as I think it does an excellent job breaking it
down.  I have two small comments which are below.

~Tim

On Fri, Dec 2, 2022 at 5:56 AM <otroan=40employees.org@dmarc.ietf.org>
wrote:

> 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
>
[Tim] I think in the flat model with DHCPv6 Relay's that they can both
relay until it gets the server and the right thing will happen, so I don't
think this a problem.

> - 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)
>
[Tim] Multi-homing is a problem for both models, and while I would love to
solve that problem I'm starting to wonder if we should take it out of scope
of the current work.

>
> 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
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>