Re: [v6ops] Updating RFC 7084 - alternate logic

[Ole Troan <[e-mail]>]

Hi Tim,

Regarding the comment below. If two routers are attached to the same link, they will both request a prefix for the link. That’s not what you want.

Regarding relaying, as you say that will work when there are multiple upstream routers. You just need to know where to relay to. Don’t think we can assume site-wide multicast. 

Regarding multihoming. MPMH is unlikely to ever work well, so I am also (unhappily) accepting to drop that. 

O. 

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=[e-mail]> 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=[e-mail]> 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 <[e-mail]>
> Sent: 01 December 2022 13:40
> To: Olorunloba Olopade <[e-mail]>
> Cc: Olorunloba Olopade <loba.olopade=[e-mail]>; IPv6 Operations <[e-mail]>
> Subject: Re: [v6ops] Updating RFC 7084 - alternate logic
>  On Thu, Dec 1, 2022 at 8:34 AM Olorunloba Olopade <[e-mail]> 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 http://www.virginmedia.com/netreport" rel="noreferrer nofollow" target="_blank">www.virginmedia.com/netreport, or for Telefonica UK Limited (O2), please report it to http://www.o2.co.uk/help/safety-and-security" rel="noreferrer nofollow" target="_blank">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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/v6ops