snac 120

SNAC-WG 120 (Thursday 2024-07-25 13:00-14:30 PDT

Administrivia/Chairs Updates (Agenda Bashing) - 13:00

• Duration: 10 mins

• WG Chairs - progress report

• no comments on agenda

• continuation after snac-simple being discussed

Eric Vyncke: if there is no more work/energy, it'd go dormant for 1
IETF, and then end

Ted Lemon: do have further work, e.g. snac-less-simple, would require
recharter to do here. Will definitely continue work, not entirely clear
where, e.g. DNS-SD, some routing stuff. But no reason not to do it here?

Eric Vyncke: was unaware of this, does seem like a reason to continue
this WG.

Eliot Lear: do you have drafts ready?

Ted Lemon: curses

Stuart Cheshire: heroic work to write these drafts, really need some
help.

Ted Lemon: +1

Rough room consensus to continue work.

Automatically Connecting Stub Networks to Unmanaged Infrastructure

• ID: https://datatracker.ietf.org/doc/draft-ietf-snac-simple/
• Document update session:

M/O bit

Lorenzo Colitti: NetworkManager won't do DHCPv6 if M/O=0

Ted Lemon: Hope was that seeing M/O=1 would trump M/O=0

Lorenzo Colitti: First seen may take precedence

Ted Lemon: What if later RA comes in with M/O=1?

Ted Lemon: 4861 just can't be implemented

Lorenzo Colitti: copying from most recently received may be viable?

Ted Lemon: can reflect bits from RAs seen with Stub flag cleared?

Lorenzo Colitti: cache most recent RA we've seen?

Ted Lemon: if network is broken (M/O inconsistent across non-stub
routers) we can't fix it -- good input

Lorenzo Colitti: copying is strictly better than setting 0

L bit

Ted Lemon: we don't know enough about uses, hence out of scope.

Lorenzo Colitti: unlikely to have a link type where RA sending works but
L=1 breaks things?

Tim Winters: DOCSIS does this, but that's irrelevant here.

general discussion

Ted Lemon: note infrastructure router connecting to stub network (among
other things) ⇒ not a snac router

back to M/O

Tim Winters: M/O is a problem now, don't want to try to solve it here.
Limit to doing no harm.

Jen Linkova: (as 6man chair) fundamentally a 6man problem, we may be
able to do something there.

Lorenzo Colitti: maybe things have moved on and we can deprecate the M/O
bits?

general document status

19 open issues, mostly editorial; otherwise:

• mentioning RA guard
• improving definitions

• infra router with snac interfaces is not a snac router

  • text on how to combine a home router with a snac router? may
    need to be excluded though

• unicast RAs

• state machine for NAT64
• how to advertise SRP service

Eliot Lear: lots of conjecture already about possible cases, please keep
compact. Just listing things to declare them out of scope doesn't help.

Ted Lemon: is this about L bit?

Eliot Lear: general

Ted Lemon: had lots of discussion about what is in scope, maybe we move
it to appendix?

Eliot Lear: issue 69 another example, conflicting text; removal would
simplify document a lot -- will take offline

Ted Lemon: how about appendix though?

Eliot Lear: appendix seems fine, especially if removed prior to
publication. Note people don't read appendixes. Wordy introduction is
much more of a problem.

Tim Chown: useful to have a list of things thought about but not
considered. Can come back to that list.

Stuart Cheshire: maybe not a problem to have a large appendix,
especially if people don't read it. If question come up during reading,
people can still consult the appendix.

Discuss and resolve open issues (link below). Propose

revised text for each issue.
link: https://github.com/ietf-wg-snac/draft-ietf-snac-simple

Nothing immediate brought up for working on preferentially.

• #87: no such thing as a "SNAC network"
• #76: RA guard: In appendix, will stay there (even if appendix is
  cut) 6105 reference added.

Some discussion on forwarding selectivity/filtering; router MUST forward
by default but MAY filter?

AOB.