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.)
How does multi-infrastructure subnet routing work?
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.
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.)
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.
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.
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.
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.
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.
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".
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.
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.
Eric: do we have other agenda points? I suggest extension of SNAC-simple
- if others have ideas. Discuss this to get feedback.
Ted:
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
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.