John, Interfaces of a host carry enough information to be used to make routing decisions - that's the core idea of host and router-side VRF implementations. Network spaces as of now do not help you to solve routing problems in any way unless you have one big L2 network and "routing" is done without routers: via ARP/NDP in a single broadcast domain.
Static routes are not flexible enough and are a workaround for the lack of VRF support. They require many additional steps from a deployer's perspective to worry about: one should just take a set of VLANs and subnets to configure in MAAS and assign them to a network space. With a default gateway per subnet there is always a next hop to delegate a routing decision to for a given network space from a host's perspective. Charms and potentially applications do need to be VRF-aware (discussed above on how). BGP on a host, while feasible in some scenarios, is not always doable in practice: not every network and/or security department will give you an ability to deploy something and set up peering with their BGP-enabled routers. I'd be happy to discuss scenarios in-depth here or out of band but the idea is that Network Spaces need to learn how to assist with Routing and Forwarding parts - currently they solve only end-end discovery via relation data. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1737428 Title: VRF support to solve routing problems associated with multi-homing To manage notifications about this bug go to: https://bugs.launchpad.net/juju/+bug/1737428/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
