IETF 121 snac working group meeting minutes

Chair introduction and overview (Darren)

AD Eric Vyncke thanks Kiran for chairing and welcomes David as new
co-chair. David introduces himself.

Agenda bashing: no changes proposed to agenda.

Darren: presents WG report with PRs done and issues open.
Draft-ietf-6man-snac-router-ra-flag passed WGLC, now with the IESG. 1
interim meeting was held since IETF 120 to process
draft-ietf-snac-simple, 5 issues closed and 2 PRs remained open. Any
comment on closed issues? (None)

Darren: presents topic of next steps after snac-simple. We need topics /
co-authors for that work.

Ted: Esko did some work on the Thread spec related to SNAC-simple.

Esko: Esko volunteer himsself as one of the authors for follow-up
documents (after snac-simple).

Ted: presents some areas/topics to be addressed:

• Connection to (partially) managed enterprise network (unintentional
  connection of SNAC routers, or intentional - allow it to happen.)

  • e.g. IP infrastructure network may get connected some time after
    the lights (IoT devices) have been installed.
  • How do you make it work cleanly? How can they discover it?

• How does multi-infrastructure subnet routing work?

• There was some demand for these topics in Matter (CSA) and Thread
  Group SDOs.

Eric: Fully support this interesting and useful work. We need to think
also about single link managed case that requires a rechartering of the
WG.

Darren: now switching to processing PRs and issues - Ted leads.

Processing PRs and issues

PR #96 add diagram for issue 76 and 91

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/pull/96
Kiran: The newly added text is part of the introduction in the problem
statement, to be reviewed to see whether it fits into the overall
document. It will be good to nail down the figure then the text.

Ted: Agree

Discussion on new diagram: it could show two cases in one; 1 stub
network with 1 stub router or 1 stub network with 2 stub routers.
Option discussed to also show a non-AIL link.
Kiran: it is already done, two SNAC routers for leftmost network
Esko: two figures in one - would be too wide?
Ted: it is not possible
AP: to improve the figure as SVG to make it readable (Kiran)
AP: to review the newly added text (SNACers)

it's already done, two SNAC routers for leftmost network. (Action: to
improve as SVG so that's readable.)

PR #94 Clarify that a SNAC router cannot be a CE router

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/pull/94
Text reviewed.
Esko: this PR is not yet sufficient; we also need to remove 'home
router' in two more places. We need to use our terminology also "Home
Gateway". The RFC reference is not needed.
Tim: Per RFC 7084 terminology, it is CE router, not Home gateway. Not
try to make a new term.
Ted: agree we should use "CE router". Our goal was (I think) to address
the RFC 7084 CE router. (People agree.)
Ted updates definition of home gateway to "CE Router" as commented by
Tim and removes the incorrect reference.

Issue #62 What icmpv6 RA behavior to expect when same device is both ipv6 Router and Stub Router?

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/62
Last comment by Esko reviewed.
Ted: solution is to change SHOULD NOT into MUST NOT and remove 2nd
sentence.
Ted makes PR change for this.

Issue #75 Outline general solution

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/75
Discussed last comment.
Ted: It is essentially resolved by the added figure.
Ted: our implementation will send RA unicasts if there was a recent
beacon already.
Esko: ok, no need to change any text in snac-simple. We can close.

Issue #65 Are the RA requirements for SNAC router only for RA beacons, or also unicast Ras?

https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/75
Ted: Current draft goes to unicast to avoid too many multicast. No
change is required here.
Esko: agree.

Issue #25 Add a state machine for NAT64

Ted: state machines - we have different state machines for AIL and stub
network.
(Should work on this offline. No time yet to do.)

Ted: we seem to be done (only editorial items and future items left as
issues.)
Darren: we could move to new topics beyond snac-simple.
Esko: agree, only editorial issues left open. People can comment there
directly if they want. We then make PRs for these.

Constants section and relation to other RFCs

Darren: (reads comment from Fernando in chat)
"One comment: The "constants" section kind of contains definitions as
if they were new parameters... whereas in many cases (most? all?) they
seem to be values for existing IPv6 parameters."

Ted: checks constants to see if they would be defined in other docs.
RA_BEACON_INTERVAL is one that we shouldn't define here in
snac-simple, arguably. Is it copied from RFC 4861?
Esko: I think we settled on a simpler copy-flag solution earlier, which
is not 100% correct for all cases but in most common cases is correct.

Esko: do we need to randomize the RA_BEACON_INTERVAL - now it's
exactly 3 minutes.
Ted: our implementation doesn't randomize it.
Darren: RFC 4861 mentions it should be randomized. Between configured
max and min intervals.
Tim: we can re-use the same name from 4861, and do a different default
value for SNAC (e.g. max/min).
Fernando: confirms on chat this is what he intended - re-use same name
where possible.
Darren: looks like beacon interval is not the only case where this
applies. It is worth to go back to RFC4861 to check other constants.
Tim: Just look at section 10 of 4861
Ted: needs a new issue for the tracker, "Constants in sync with RFC
4861".

Created new issue #98 Sync constant names with RFC 4861 reword text as appropriate

Kiran: so, just to confirm - these values will only be
changed/configured on SNAC router not infrastructure router.
Ted: Right
Eric: concerns about the term Beacon, beacon is for wifi, not in IPv6
Ted: We will change it.

Finalizing snac-simple

Darren: a revision 7 might be the last version (with all final changes
in). Asking for some ML discussion. The update to the state machine will
be a large one.
Ted: proposing to discuss state machine on ML.

Future documents after snac-simple

Eric: do we have other agenda points? I suggest extension of SNAC-simple
- if others have ideas. Discuss this to get feedback.
Ted:

• Connecting to a (partially) managed infrastructure, as discussed in
  the beginning of this SNAC meeting.
• How does a CE router with SNAC(-like) functionality looks like,
  though, we already have RFC 7084. No IETF action item for that. We
  do have one in Thread group.
• what we do need: ability to discover SRP service on infrastructure.
  Currently snac router acts as DNS Discovery Proxy. But if the
  infrastructure network already defines a discovery proxy, we don't
  want SNAC router to provide it -> rather it should be provided by
  the 'home router' in infrastructure. This would lead to functions
  that need to end up in CE routers.
  • 6man WG may need to review this work, rather than do it in 6man.
    Bob?
    Bob: that's reasonable.
    Ted: overall, next document should describe how to put things
    together.
    Eric: do you envision this in another document?
    Ted: yes

David: would that require a charter update?
Ted/Darren: (discuss) for SNAC multi-link document, we don't need a
charter update.
Ted: for the CE router related functions, we may need a charter update.
On DHC: what's missing is a document that when you do DHC PD, you need
to update routes as well.
Tim: we tried but did not get very far.
Ted: due to lost interest.
Tim: it's horribly hidden in a docsys spec somewhere. There's a v6-ops
doc which is open for updates for CE routers. Happening now and in
charter. Now's the time to provide input!
Ted: it's a big lift to include SRP service and DNS proxy into that doc.

Tim: maybe not a MUST for that functionality, rather a SHOULD/MAY. In
some years, vendors may want to put these functions in.
Ted: 7084-bis may need to talk about prefix delegation and routing.
Tim: routing issues are more complicated.
Ted: charter of DHC is worded carefully to avoid work landing there :)
Tim: it's routers (infra) doing things, not clients.
Ted: 7084-bis is open, maybe we should do this kind of work. So don't
wait.
Eric: many routers already snoop DHCP message to update router tables.
Already doing this.
Ted: only thing is there's no spec, in IETF.
Eric: should be in v6ops.

Eric: talking about SRP and dns-sd, we have a new chair Florian.
Esko: so I missed the first bullet we discussed at the beginning of the
meetingmixed managed/unmanaged is in scope?
Ted: it is about the managed network
David: it was mentioned “managed and partially managed” network

Closing

Darren: any other business?
Eric: ask audience whether we like this format of WG?
Darren: yes, this is the 4th WG meeting that we do in this format (group
editing).

Esko: yes, useful to have discussions not just status updates. Sometimes
editing is a bit hard to follow. It goes a bit fast.
Darren: Any other tools might be useful for this format?
Kiran: Markdown is better
Ted/Esko: agree

Ted: live discussions are useful for solving issues.
Discussion on better tools? Markdown is mentioned as better than XML.

Darren: we sent a request for 2 shepherds for snac-simple. If you're
interested, contact chairs.
Tim: volunteered as shepherd!

Wrapping up at 14:43, 16 minutes early.