Re: [Iotops] Automatically connecting to stub networks...

[Toerless Eckert <[e-mail]>]

On Fri, Dec 04, 2020 at 09:19:13AM +0100, [e-mail] wrote:
> Question, what are the requirements here?

Indeed. Lets first focus on that.

> A) Stub network. Is it possible to restrict the topology to a single root/single level of leafes?

I would fear the current business cases might be fine with such a limitation,
but i for once would find it dissatisfactory if the protocol solution
would be limited to just one level.

> It prohibits multi-homing. What about the case where a node is attached to the stub with a hypervisor and VMs requiring addressing?
> Is sending all traffic via the root acceptable? Instead of short-cutting between stub routers?
> 
> B) Is it possible to restrict the solution to the site having been delegated enough address space?
> Or do you need to handle the cases where the site has:
> a) not received enough /64s to number all links
> b) have only been delegated a single /64
> c) have only a shared /64
> d) have only a single address

Not trying to answer all these points, but:

To me the most simple model is around the following constraints/requirements:
  
      stub-router ----link --- infra-router

a) stub-router and infra-router are potentially different admin, aka:
   we do not want to use signaling between them such as a typical
   link-state-routing protocol where you can not create good trust-domain
   boundries within the topology. Dijkstra protos are a bit better, but
   i think no one has tried to come up with good definitions for "internal"
   trust boundaries.

b) infra-router hands out prefix(es) to stub-router. It shouldn't have
   anything to say about how stub-router uses them. So stub-router could
   subtend sub-prefixes as it sees fit. Infra router does NOT accept
   prefixes back from stub-router. 

Not sure yet about similar rules for the naming / services for DNS-SD,
but there may need to be some similar rules.

And from service provider use cases, i remember various other DHCP options
that infra-router may need to see proxied across stubb-router to clients
if/when clients rely on DHCP opions instead of DNS-SD to discover specific
services. Which for example in the home a lot of the service-provider
equipment such as IPTV STBs expects to be able to do.

Cheers
    Toerless

> 
> Cheers,
> Ole
> 



-- 
---
[e-mail]