# SNAC BoF @ IETF 114   {#snac-bof--ietf-114}

Monday July 25, 2022  
10am - 12pm (two hour)  
Room: Freedom E/F  
Chairs: Suresh Krishnan suresh.krishnan@gmail.com,  
 Kiran Makhijani kiran.ietf@gmail.com  
AD: Eric Vyncke (evyncke@cisco.com)  
Mailing List: snac@ietf.org.

# Agenda   {#agenda}

## Administrivia - Chairs - 5 minutes   {#administrivia---chairs---5-minutes}

Suresh Krishnan (SK): we will be spending most of the time on
understanding the problem and whether there is work to be done in the
IETF. Try to keep questions to the minimum until the end. At the end
there will be polls to see what the people in the meeting think.

Problem statement, use cases and requirements (50 minutes)

## Stub networks SNAC Overview and Problem Statement(Ted Lemon, 30 minutes)   {#stub-networks-snac-overview-and-problem-statementted-lemon-30-minutes}

      draft-lemon-stub-networks-ps

Ted Lemon (TL) presents the slides. Hosts can connect to the infra
automatically, we now how to do it. But there is no similar way yo
connect a stub network.  
TL presents goals, constraints and topologies in scope, as well as some
assumptions on a potential solution.

Sri Gundavelli (SG): missed the question  
Carlos Bernardos (CB): is dynamicity in the multi-link topologgy in
scope?  
TL: yes, this is like any home device: either this is supported or we
prevent that to happen.

Michael Richardson (MR): how can devices communicate internally in the
multi-link topology? (or something like that)  
TL: this is not a solved problem yet. There are some solutions for some
problems, but this particular problem is not yet solved. Either we find
a solution or do not support this case. MAin goal is to have consisten
behavior.

Stuart Cheshire (SC): example use case, working on home automation, and
other stuff. Home networks are evolving, solutions typically involve
adding new devices to the home network, which behaves as a huge
broadcast domain. This is not scalable.

Erik Kline (EK): whether using Proxy ND was in scope?   
TL: It's in scope, but I'd be surprised if we went that way, and
wouldn't likely implement it if we did. But it's absolutely fine to
depart from the solutions we came up with for Thread if we come up with
better solutions.

Pascal Thubert (PT): this type of problem has been discussed in ROLL.
What we ddidn't do is creating more than one prefix. Is is outr of scope
to manintain the same prefix on multiple links?  
TL: we though about this, this was definitaly in scope. The reason not
to do that is that is not scalable.

Behcet Sarikaya (BS): how is it different from networks today? e.g.
light bulbs can be controlled in garage from the same network?  
TL: It's not always possible to bridge different network media together,
and that was in fact our initial use case.

Someone remote: making changes to the hosts would be difficult.  
TL: in the greenfield scenario, we don't care. In the ordinary scenario,
the manufacturer of the device that connect to the network would not be
motivated to add the changes.

MR: can we assume that the stub routers are greenfield? I think yes.
Refering to the slide #9, I think it's quite reasonably that we do some
kind of election. The situation where people would use this scenario is
a smart speaker that can be used in several rooms, and there are
partitions in the network.

Ran Atkinson (RA): question on deliverables. Is this about writing
routing requirements? I haven't seen analysis of existing solutions that
can be re-usable.

TL: thanks for the questions, slides didn't touch that particular point.
The goal is not to create a whole bunch of new protocols. The goal is to
take what we have and specify whar we need to go to make them work.

SK: we should make it more explicit on the charter that we want to reuse
existing technology.

## Thread Use Case (Jonathan Hui, 10 minutes)   {#thread-use-case-jonathan-hui-10-minutes}

Jonathan Hui (JH) presents the slides.

RA: why the Thread Border router does not have ZigBee connectivity?  
JH: it can have a third radio.

Discussion suggesting that there are more topologies involving
additional radios, like ZigBee.

TL: even if the router has the additional radio, that does not solve the
problem, as devices might not be in radio coverage. The idea is that the
mesh router can solve the problem if you have more devices in the
network you can connect to.

SC: we need some transition where very home gateway has thread
connectivity.

Chris Morrow (CM): it's about having multiple radios.

PT: what you have done for service discovery is exactly what we have
done for ND-proxy. Referring to slide #10. We looked at this in 6LOWPAN.
If you are doing with different addressing in the networks.

## Building Use Cases (Michael Richardson, 10 minutes)   {#building-use-cases-michael-richardson-10-minutes}

      draft-richardson-snac-building-use-case

MR presents the slides.

Open Mic/Discussions (20 minutes)

SC: on proxy ND, that might work. To make the broadcast domain bigger
and bigger.

(some discussion missed)

TL: if we say that a host need same functionality if connected to a stub
or a infrastructure network, the sub router would have to do extra
functionality. There are cases in which it makes sense to isolate, you
might not want any device at your home to communciate with any other
device.

PT: reply to TL. We have done this even with networks with 20 hops. We
need to see what 6lo has done.

TL: what I'm talking about is multicast in the backbone, to avoid having
20k devices doing multicast in the backbone.

SK: what some people have said is that if there is a better solution,
let's explore it.

Philipp S. Tiesel (PS): will group look into about limitations and
scalability based on the addressing in virtualized infrastructuressuch
as multiple prefix delegations.

TL: the risk to boil the ocean. We should try to avoid starting with too
many difficult things.

SK: the idea is to start with something tightly scoped, and useful. We
can add things to the sharter, this can be discussed.

PS: with the cloud use cases, we sacrifice things if we scope the work
for the stub networks to something smaller than /64.

SK: there are some issues with SLAAC if we go for something different
than /64. We can talk with 6man.

## Charter Discussion (15 minutes)   {#charter-discussion-15-minutes}

Chairs share the current version of the charter.

SK asks for feedback and/or questions on the current version of the
charter.

MR comments on the third paragraph. Maybe we need to be more explicit on
what it means. The sentence is "\[...\] but hosts on the
infrastructure..."

SK agrees that it makes sense to clarify.

TL will edit the text.

Juan Carlos Zúñiga (JZ): I'm not sure if we are considering also the
onboarding part (authentication, authorization and things like that).

TL: interesting problem, but specific of the type of network. Not sure
we can add to the charter.

Tom Hill (TH): if we don't consider basic security at the borders of the
stub and the infra, then it would be down to each individual vendor on
what needs to be done. We should be more descriptive. Something on
security should be added to the charter.

SK: you don't want default connectivity to the stub network, is that
right?

TH: this is just one example.

TL: do you want the same type of control than over devices on the
infrastructure?

SK: looking at the deliverables, there are 4 proposed ones. Questions
about the clarity, scope, etc of the charter.

MR: asks about the security point made earlier, it is not clear if it is
n the scope or note.

SK: asks TL to make a note to discuss in the mailing list about the
security part. And also about network splitting and healing.

Gabriel Montenegro (GM):; not sure I guet the difference between the 2nd
and 3rd deliverables. Can you clarify?

TL: I'll clarify that in the charter document. Problems on connecting to
the global Internet or to adjacente devices are different and might
imply different solutions.

Questions & Next Steps (15 minutes)

SK asks if anybody things the problem is too ambitious to solve. No one
objects.  
SK asks about the usability of the problem. Nobody questions that.

SK asks about willingness to contribute with documents. Around 15 people

SK asks about reviewing documents. Some humming.

SK asks about interest to form a WG, pending the edits to the charter
that have been discussed. Quite some support.

SK asks if there is somebody that the WG should not be formed. No one
objects (locally or remote).

SK says that it seems that there is support to form a WG.

Eric Vyncke (EV, AD): happy to see the WG formed if it does not attempt
to boil the ocean.

Meeting adjourned.