Minutes IETF116: snac: Wed 06:30
minutes-116-snac-202303290630-01

IETF 116 SNAC WG Meeting

Date/Time: Wednesday, March 29, 2023, 15:30-17:00 (GMT+09:00 Tokyo)
Slides: https://datatracker.ietf.org/meeting/116/session/snac/
Notes Taking: https://notes.ietf.org/notes-ietf-116-snac
Meetecho:
https://wws.conf.meetecho.com/conference/?group=snac&short=snac&item=1
Jabber: https://zulip.ietf.org/login/#narrow/stream/snac

1. Administrivia/Chairs Intro (Agenda Bashing) - 15:30
   Duration: 05 mins

Soliciting more reviews for draft-ietf-snac-simple.
Agenda was agreed.

1. Automatically Connecting Stub Networks to Unmanaged Infrastructure
   ID: https://datatracker.ietf.org/doc/draft-ietf-snac-simple/
   Duration: -- mins
   Presenter: Ted Lemon

Soliciting more reviews, especially to check whether all implementation
aspects are included in the draft.
Noting that 6man WG adviced SNAC to do the work on
draft-hui-stub-router-ra-flag, then send it to 6man.
Ted notes that (slide 5) "Joiner" model seems to be better.
Esko: need something like a WGLC to be done on
draft-hui-stub-router-ra-flag, and some reviews by people, then send on
to 6man.
Timothy: worried about the "flapping" behavior with multiple stub
routers.
Ted: we should not get "flapping" if stub routers are correctly
implemented.
Timothy: occurs due to packet loss in wireless links.
Ted: we use unicast with probe to tackle such situations.
Masanobu: why don't we have a requirements section?
Ted: agree, useful. Would like to receive text for it.
Masanobu: is global internet reachability also in scope, from stub
network? Firewall (IPv6) needed?
Ted: yes, but it's not guaranteed in all cases. Firewall on CPE router
typically already in place, then not needed on stub router. Maybe as
future work.
Remi: from Android open source project side, we're interested in this.
We might be able to provide implementer's input, if time permits.
Kiran: is SRP mandatory for service discoverability of stubnet devices?

Ted: no, but SRP does seem the right solution here (less reliance on
multicast).
Masanobu volunteers to review the document and provide feedback.

1. IPv6 CE Routers LAN Prefix Delegation
   ID: https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/

   Duration: -- mins
   Presenter: Timothy Winters

Was also presented in v6ops.

David: question on 7084 in figures - was clarified.
Esko: why only /64 length?
Timothy: to avoid the hierarchy problem; only 1 place that distributes
the prefixes - the CE router. Request length hint is basically ignored.

(Also clarified that CE routers in figures are also 7084 compliant.)

Eric V: Please put SNAC in CC on similar drafts, v6ops is very noisy.
Erik Kline: In Homenet when unplugging routers, and plugging them in
differently renumbering will happen magically. In this scenario how is
it handled?
presenter: Original homenet had 2 problems, "what is up and what is
down". In this case, renumbering will work like regular renumbering.
We can also use reconfigure because very 7084 router has that built in.

(Discussion on topology 3: 7084 Router in between.)
Ted: Problem of different states is not as bad as it seems. [...] You
can send a Reconfigure down the path of the original PD. That'd be used
to clear out the old path.
presenter: Problem is with the relay agents learning this.
Ted: The server knows which relay agents it came through. If that path,
or a part of it, remains, the Reconfigure should clear out the old
state.
presenter: Lease Query could help as well.
Ted: How much complexity do we want to add to solve this? "Just use a
routing protocol" is a solution.
presenter: We're trying to avoid having routing protocols, there are low
chances on home vendor boxes having that.
Ted: Never hurts to ask.BABEL did a lot of work towards simplicity.
Ted: router vendors may have experience with ISP's behaviors for prefix
delegation.

Lorenzo: what if the middle 7084 router sends the request before the top
CE router acquires the prefix? (Or bottom router sends before middle
router has it?)
Tim: solution is to only become relay once your delegated /64 comes in.

1. Discussion on related topics and Next Steps
   Presenter: Co-chairs
   Duration: -- mins

No further discussions.