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

[Ted Lemon <[e-mail]>]

On Dec 4, 2020, at 3:57 AM, Toerless Eckert <[e-mail]> wrote:
> 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.

There isn’t really any new protocol work required.

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

Does anybody actually do that? I ask because I don’t know of any routers that support it. I guess some ISPs do custom routers and don’t let the customer choose?

Anyway, best is the enemy of good enough. We already have a solution for the self-configuring mesh; if that’s what we want, HNCP is our best option at present. There’s no need to do additional protocol work here.