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

[[e-mail]]

>> 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.

Right, I already gave an example where that topology fails.

>> 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.

Yes, I believe this was also discussed in homenet.
In Ted's case as well as many others devices are controlled with umbilical cords to other administrative domains.
They should in theory not be more trusted inside the network than a host from the outside.
This is a hard one.

> 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.

Routing is of course tightly coupled with prefix assignment.
I also believe Ted's use case involves a stub network coming with it's own ULA that it wants to advertise routing for within the rest of the site(?).

> 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.

There has to be a way of distributing configuration information (from multiple sources).

Cheers,
Ole