https://datatracker.ietf.org/meeting/121/materials/agenda-121-netmod
https://datatracker.ietf.org/meeting/121/session/netmod
Sessions:
Monday, 4th November 13:00-15:00 UTC
Thursday, 7th November 17:30-18:30 UTC
WG Chairs:
Lou Berger (lberger at labs dot net)
Kent Watsen (kent plus ietf at watsen dot net)
WG Secretary:
James Cumming (james.cumming at nokia dot com)
Session 1 : 2024-11-04 13:00-15:00 GMT
Notes: https://notes.ietf.org/notes-ietf-121-netmod?both
Materials: https://datatracker.ietf.org/meeting/121/session/netmod
Zulip (chat): https://zulip.ietf.org/#narrow/stream/netmod
Drafts (TGZ):
https://datatracker.ietf.org/meeting/121/agenda/netmod-drafts.tgz
Drafts (PDF):
https://datatracker.ietf.org/meeting/121/agenda/netmod-drafts.pdf
Datatracker: https://datatracker.ietf.org/group/netmod/about/
ICS: https://datatracker.ietf.org/meeting/121/session/33378.ics
Recording:
https://meetecho-player.ietf.org/playout/?session=IETF121-NETMOD-20241104-1300
YouTube: https://www.youtube.com/watch?v=07PiOsYZEKg
Jabber Logs: https://www.ietf.org/jabber/logs/netmod
Start 00:00:30
Duration: 10 mins
Discussion Leaders: WG Chairs
No discussion
Start: 00:08:15
Duration: 10 mins
Discussion Leader: Qiufang Ma (remote)
Draft:
https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/09
Kent Watsen: As shepherd for this document it is in WGLC. There was
significant comments received. Thank you for addressing the comments
from Jergen and Andy. I would suggest that we run another WGLC and then
move to publication.
Lou Berger: Just to be clear, we are going to run another working group
last call and then move it to publication. We're not skipping a step.
Rob Wilton: Sounds like a good direction, but haven't had a chance to
read latest version. Another WGLC sounds good.
Start: 00:14:17
Discussion Leader: Scott Mansfield
Drafts:
https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/11
https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/14
Lou Berger: As this was part of the last call comment and there has been
no objection, once the draft has been updated based on the last call
comments, we will submit the draft.
Start: 00:18:10
Discussion Leader: Mohamed Boucadair
Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/20
Kent Watsen: RFC8792 says handling long lines, but it really means wide
lines (many columns). We also have similar terminology for the length of
the model. We should clean up the language.
Mohamed Boucadair: Will you volunteer to propose some text for this one?
Kent Watsen: I can
Lou Berger: The coment on the list from Kent was about the wide lines.
He also had the point about referencing that RFC. That RFC does not have
the same text as the tree doc you're tryint to update. As far as I can
see, the only thing you've added in this update is (1) following the
recommendations in the Tree RFC, and (2) don't follow what the tree
diagram doc says for long lines, but rather use Kent's RFC. I think the
section needs to be cleaned up to (1) Reference the long lines RFC, and
(2) SHOULD follow guidelines in tree diagram RFC. The only difference
between this document and the tree diagram RFC is the capitalization of
the word should.
Mohamed Boucadair: It is more subtle. We characterise what we mean
between long trees and too-long trees. We really characterized this now.
More that 2 pages for long trees and more than 5 pages for very long
trees. We don't leave it open for the authors whether to put it in the
main document or the appendix. My understanding is that Kent volunteered
to provide some text.
[New topic]
Joe Clarke: If you thought wide trees vs. long tree is a can of worms.
Both semver and YANG versioning update RFC 8407. I don't know if we
finally progress these docs, does this go into this bis and we add some
text here or not?
Mohamed Boucadair: I looked into this. Want to remind of the scope of
what we wanted to do, otherwise the bis will be endless. If you want to
do updates for semver, do the update there. I prefer separating these
rather than linking them.
Joe Clarke: Timing has come closer together, hence why bringing it up
now. I defer to the WG. I don't have a strong opinion either way.
Kent Watsen: I'd like to hear more comments
Mahesh Jethanandani: RFC 8407 is updated regularly, should this be a
living document.
Lou Berger: I think we agreed just to publish every couple of years. We
should get better at publishing documents quickly. I'm not opposed to
using RFC 8407 as that testcase/prod to publish more quickly.
Mehesh Jethanandani: What I gather from all the edits that are dribbling
in, there are fairly regular updates happening. It is up to authors to
say whether you are willing to make more edits as they come in or are
you done. I am more than happy to have a page hosted for this if that is
the way the working group feels about it. My feeling is that it would be
useful to have a page to update without having to update an RFC.
Mohamed Boucadair: Just one question for you Mehesh. Did you check the
web page for the YANG doctors. What was the last time this page was
updated.
Mahesh Jethanandani: I will have to go and check. Back to the point
about being explicit. You say the practice so far is to remain silent.
Is this in general for the template or is this in the document that use
the template. I have seen in the documents it is all over the place.
Mohamed Boucadair: I think this is the random and a function of the
reviewers. Do we see a value in having something that is consistent
here.
Mehesh Jethanandani: This is really for the WG to decide but I think it
is better to be explicit.
Rob Wilton: When I was an AD we had some security template questions
come up. When I was reviewing Kent's documents there was a difference in
understanding about what was a security consideration. I intended to
bring this back to the WG but I haven't done so. I think we should
refine or update the security templates section. I think Kent's approach
was better.
Lou Berger: Trying to remember. I thought we had a website that Benoit
set up? He ran the experiment of whether part of the document could be
in a webpage. Have you looked at the webpage and thought about how to
update that?
Rob Wilton: Yes, ages ago. Not recently. I have a feeling that the
migration of a webpage into this document has evolved. What was created
and what it's ended up being has deviated.
Lou Berger: If you could suggest how the text could be fixed, that
addresses the specific comment. For the general comment on whether we
should look at the security template web page and see if that's a better
way...my impression is the website suffers the same problem as the RFC,
but with the extra problem of there's no process for updating. I'm
hesitant to lean to a wiki/webpage as the definitive way to capture
things. The list is the right way to propose the text. If its really
quick, we as a group can decide whether to get it into the document.
Mohamed Boucadair: One addition on the security part. We circulated this
a few times and one of the comments was that we should leave this to the
authors to define. We received some comments, one of the comments was
that we should leave it to the authors should focus on only the key
ones. We don't need every sensitivity or privacy to be included in the
document. This is why we modified in the template whether this is major
or not and we circulated this at least two times with the security
teams. If there are any additional comment please let me know what to
fix.
Rob Wilton: I thought I was checking the latest document but this wasn't
clear to me.
Mohamed Boucadair: If there is something that is missed we don't have
any procedure, we to leave it to the AD change any text or do we expect
this instead to come to the WG.
Benoit Claise: You mention that there is no speecific process for that.
What we did is we got the input from the YANG doctors and the mailing
list, and went to the IESG to see if it's the right thing to do. In the
end we put the security considerations for the other ADs. It's not
formally written anywhere; we need to see if there's something broken
that needs to be fixed here. Maybe there is nothing broken.
Mohamed Boucadair: Want the template to be flexible. Up to the authors
to do their homework and fill in the appropriate sections.
Rob Wilton: The risk there is that when it comes to other ADs eg SEC
ADs, they will flag if some parts are missing. Everyone needs to be
reviewing with the same set of rules.
Mahesh Jethanandani: I went and looked at the wiki page was last updated
on the 7th Feburary this year by Cindy Morgan. Benoit is right, the
process is that it goes to the IESG for whatever the WG has agreed is
the current set of guidelines. I can reaffirm this in the IESG. The wiki
seems quite up to date except for the latest changes proposed by Kent,
perhaps these need to be added. I checked the language and it says IF
there is any RPC operations then you can document it.
Lou Berger: Who initiated the request for the wiki update? Who was in
the approval chain for the latest update? It wasn't anyone in this room,
including chairs and [current and past] ADs. We should decide if this
is a good thing or not.
Mehesh Jethanandani: I am in favour of the WG saying these are the
latest set of changes, can the AD have it updated.
Lou Berger: I am all for a process that the WG has input and we
understand how changes happen and get approved. To my knowledge the only
approach we have is an RFC. If the IESG gives us a different tool then
OK but to my knowledge the only one available is the RFC process.
Mohamed Boucadair: The change we're talking about was to fix a broken
wiki URL. This was dicussed on the mailing list. The change wasn't about
the template itself.
Lou Berger: We should probably move on
Kent Watsen: Now that RFC8407bis is doing this should the IESG not be
doing this and we defer to RFC 8407bis?
Mahesh Jethanandani: Or we update the page with whatever updates are
made by RFC8407bis publishes?
Lou Berger: Next steps for the document, is to follow up on the list on
the next version and then go through each one of the open points.
Start: 00:42:45
Discussion Leader: Joe Clarke
Drafts:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/12/
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/17/
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-filename/00/
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-versioning-reqs/10/
On file naming:
Lou Berger: Speaking as the shepherd. My hope is that any comment that
adds clarification you just accept and address just like any other last
call comment. Any comment that has a technical change we discuss and get
a feeling from you and from the room as the right way forward. I would
like this to be the foundation for discussion on the list. This will
help the process go faster.
Joe Clarke: I agree. Per has also replied today on the file naming point
as well. (Continues presentation)
Rob Wilton: Reason we pulled this out initially is because we dind't
want to slow down the versioning work. Key thing here is knowing whether
we want to go forward with this (file naming) or delay it and progress
the other work.
Per Andersson: I said on the list that we could include this in another
draft but I agree with Joe's comment that this should probably be a
separate draft.
Joe Clarke: There is probably two questions. 1) is Rob's point, should
we continue to progress this as part of versioning work? We as the
authors think yes we were told not to shy away from this. 2) should this
be the form we encourage people to use.
** Poll **: Should we just use foo#1.2.3.yang long term? [almost
all participating say yes, a couple of no responses]
Lou Berger: There is an implicit response to the first question, yes, so
lets move to the second one. We don't have a heavy participation in the
poll. The fact we're getting some "no's" it would be helpful to know why
you're saying no and what you'd prefer.
Andy Bierman: I think it's been brought up before that doing this on top
of YANG 1.1 is the problem. If there was a NBC change and it's YANG 2.0
and you change the filenames, that's something else. But this does
impact existing YANG 1.1 tooling that go looking for the filenames. I'd
also note that openconfig didn't feel a need to change the filenames
even though they have the semver in the modules.
Kent Watsen: The poll question was about "long term" meaning what is our
long term aspiration, i.e. should this be part of YANG-next?
Lou Berger: This is for use until we have YANG-next.
Joe Clarke: Our concern was that there might naturally be multiple ways
of doing this if we didn't standardise this now. We think that if we do
this now and write SHOULD that it wouldn't break tooling because you
could still use the @revision syntax.
On module versioning:
Rob Wilton: I thnk we've discussed this issue a lot and we do have a
future extension that could do node-level version. Don't want to re-open
a can of worms here. I see this as a closed issue. Just my opinion.
Reshad Rahman: Like Rob, I remember that we discussed this extensively.
One issue we discussed and I don't remember how we closed on it is what
happens when you remove a node. You have no node to tag to say there has
been an NBC change so you need to go one level up and it starts loosing
it's appeal.
Balázs Lengyel: I think this whole topic of semver is extremely urgent
because I've heard two other SDOs considering implementing their own
solution. Big items like this node extension should be avoided.
Kent Watsen: Node-level should be deferred. Module-level is sufficient.
Lou Berger: As shepherd, I think our prior discussions have been covered
before and from a simplification perspective we should consider this
item closed and in the future we should expect a node-level draft and we
can discuss it in that context (in future).
On yang semver:
Andy Bierman: I like a lot of the semver except these modifiers. I think
you'rte trying to pack too much in a version string. There's already
yang extensions in the module that already show the backwards
compatibility chain. This is hard to understand and handing this to the
community at large, this is the part that's really going to confuse
people. I would prefer this a lot better if this was just left out.
Joe Clarke: This is where we had the most discussion and tried to do the
most clarification. We feel that most of the time these won't be used.
But we do feel like there's a use for them. If we reopen this and the WG
says "no we can't have them in there" then ok, but every time we've
talked about this ourselves, this becomes a sticking point. People keep
bringing up use cases ("how do we do this particular thing for our
customers?")
Rob Wilton: I feel like this is going around in circles. We have to
support people with previous releases who need bug fixes. That is where
this is coming from and there is a strong market requirement to support
this. I know you may not like it but we've had this discussion many
times and I feel we should close and move on otherwise we won't publish
anything.
Lou Berger: If there's an opportunity to help clarify in the current
document, that would be great. I think it is confusing and will lead to
confusion. Anything we can do to help avoid that would be great. Taking
the different viewpoints on the list and trying to address them would be
good.
Rob Wilton: Happy to try and clarify but I am opposed to changing the
direction now.
Joe Clarke: I would really appreciate if there is other suggestions on
how we might clarify this. We have tried by example. We even tried a
tree form. If there are suggestions they would help.
Lou Berger: I have an example to give you offline.
Start: 01:06:00
Duration: 15 min
Discussion Leader: Rob Wilton
Draft:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-packages/04/
Lou Berger: Please reannounce this work on the list to remind people.
Mahesh Jethanandani: I want to support this effort. The fact that this
set of packages validates and works together is very valid. It should
contain some amount of schema mount effort. We have the combination of
network-instance and routing-protocols as one package, maybe the first
package.
Rob Wilton: I think that makes sense. What this leads to is the IETF
creates smaller packages.
Mahesh Jethanandani: On deviations, I think the vendors should be able
to add their own deviations
Rob Wilton: What about flagging that? Should it have a flag saying I
have deviations or not?
Mahesh Jethanandani: I have to look into that
Balázs Lengyel: In 3GPP, schema mount is used heavily. It would be good
to have it.
Joe Clarke: You know that I agree. On the checksum I think the version
is enough.
** Poll **: Do you agree with the general approach to simplify the
focus to get packages out of the door? [Majority positive response with
no no's]
Start: 01:18:30
Duration: 10 mins
Discussion Leader: Qiufang Ma (remote)
Draft:
https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/02
Kent Watsen: (as chair) we think that this is a process issue and we
think the document should update the base protocol document. Also, this
document has a liaison items on this and I believe that Rob Wilton
volunteered to create some text which he did but that conversation has
not concluded. We will try to do this as quickly as possible after this
meeting. We also said that when we do the WG last call we will also send
the liaison response.
Lou Berger: (as chair) This discussion happened off-list. I would like
this back on the list for review before it is sent. In the future,please
proposed liaison text to be done on the list in future. We would like
the WG to have an opporuntity to comment.
Start: 01:23:30
Duration: 5 mins
Discussion Leader: Qiufang Ma (remote)
Draft:
https://datatracker.ietf.org/doc/draft-ietf-netmod-schedule-yang/03
Authors request WG last call and request sending the last call to the
following other working groups: TVR, OPSAWG, CALEXT
Kent Watsen: As chair, we can ask for reviews from the relevant
directorates and initiate WGLC.
Lou Berger: Would you like early reviews in all the listed areas?
Normally they get reviewed as part of WGLC.
Quifang Ma: No, just WGLC would be good.
Joe Clarke: As OPSAWG co-chair, I think a last call review in OPSAWG is
good. Have you updated the ACL draft to accomodate some of these
changes?
Quifang Ma: Yes, I have
Start: 01:28:00
Duration: 15
Discussion Leader: Kent Watsen
Reference: https://github.com/netmod-wg/yang-next/issues
Lou Berger: Can you describe how this team was selected and how it
operated?
Kent Watsen: I mentioned in the IETF 120 session I asked people to send
me emails and I reached out to a few people. I also sent to the list.
Lou Berger: So this announced, open to all and self selected. Of course
the working group will have to bless any work that comes out of it. Can
you describe what you see for the future?
Kent Watsen: Being a member of the scoring team does not mean that you
need to be a member of the review team. Also, if the WG wishes for the
review team to be a formal (or informal) design team, that's possible.
Lou Berger: I personally like the informal self-organizing approach and
it should come back to the WG.
Rob Wilton: Thank you Kent for organising this. It's a big amount of
work -- we need to be careful. When scoring the issues, it felt like a
scattergun of issues. And was sometimes hard to score them on
importance/backwards-compatibility. For me, it would be better to come
up with a view of what YANG-next is solving, these are the goals it will
achieve and have some concrete proposals of we want to include x y z,
and exclude a b c. Might be good to have a couple of these proposals,
e.g. a heavy version and a light version, and then get consensus around
which direction we want to go. It would be useful to see the direction
that this is going before we start making lots of changes. For the
vendors, I would like to see if we did this, whether they would use it.
Andy Bierman: I put a lot of hours into going through every single issue
in the list. There are a lot of improvements in store. Many of the issue
were related to YANG is too difficult to use. We have already done what
Rob asked and the high/medium issues are in scope - the ones with low
importance are being left out. I agree we need to see a high level view
of what is going into YANG next but I think it needs to be developed on
its own and is subject to change and review along the way.
Rob Wilton: My concern with that is we could spend 4 years building
something that in the end there's no consensus to publish. With the
versioning work, spent ages on it and then at WGLC it was rejected and
back to square one. I would like some consensus from the WG on the high
level details / direction. Take the existing set of issues and
summarise/categorise them and get consensus around that summary list.
Lou Berger: What I hear is that you would like to take the result of the
scoring and get these into a draft and get this adopted as a WG document
so that the WG gives it's buy-in into the work.
Rob Wilton: Yes. Some way of checking "does the WG agree this is the
right direction?" If we add another 100 pages to the YANG spec, which is
possible, is that going to be something people want to deploy and use?
Lou Berger: I think thats an excellent suggestion. I think Kent's
question was what is the right process. I think that the WG provides
buy-in is important. It's essentially a mini charter of a design team
without the heavyweight process of a design team.
Kent Watsen: (as contributor) I almost question, what choice do we have?
If we don't do this, we should close the WG.
Rob Wilton: I disagree on that. Two choices here: (1) build a lighter
YANG 1.2; not backwards compatible, but with a small number of
high-priority changes. Make the language a little bit better and solve
the top pain points. (2) go the other way, and say we're going to
address a lot of these issues, make YANG quite a different language, and
say that this larger change is much more significant. The risk is we end
up with second system syndrome and the language becomes too unwieldy.
The same reason why we use xpath 1.0 instead of 2.0/3.0 is that those
languages came from something small and imperfect to languages that were
much much larger. We need to be careful to know the direction we want to
go and get consensus around that direction.
Start: 01:41:45
Duration: 15
Discussion Leader: Andy Bierman (remote)
Reference: https://yangpp.yumaworks.com/en/latest/yangpp/index.html
Lou Berger: Do you see any issues working with the YANG-next team on
this?
Andy Bierman: No, I see no issue working with a formal design team that
is open to anybody and meets bi-weekly.
Start: 01:53:10
Duration: 10
Discussion Leader: Balázs Lengyel (remote)
Reference: Slides only
Mahesh Jethanandani: I couldn't agree with you more on the need to
somehow have a quicker way to update models. Errata probably isn't the
right place as errata is very targeted and focused. I wouldn't push the
errata envelope to try to fix this. We need to look from a process
perspective to understand what needs to be done to update a model and do
we need to update the corresponding RFC and where should the model be
kept. The only currrent way to rev. it is to create a bis version of the
RFC and we know how long that takes. I'm open to the community to say
that we need a faster process and does the YANG model belong in an RFC
or should it be in a location where it can be updated more easily.
Balázs Lengyel: I'm trying to propose something that's a relatively
small change to our processes and re-uses the verification process of
the erratas already. Maybe this can be agreed faster?
Scott Mansfield: I agree that this is an issue. The ability to download
the YANG models from the git repository is fantastic. I would like to
see some tooling that sticks the errata into the YANG github repository.
We do a lot with github now, we could simply put the YANG in a github
repo and just point to it. This would enable consistency between SDOs
and other WGs within the IETF.
Lou Berger: We had decided when Rob was AD to run an experiment to see
how fast we could get a minor revision through the process. We had a lot
of discussions of could we do this quickly? The problem was that the
authors couldn't agree on the change. So what looked like a quick thing
dragged out because the authors kept saying "we're not ready yet". So if
we could have an experiment or automated process where someone wants to
-bis an RFC and see how fast we can run the process. One of the key
points was that we were going to ask the IESG to focus on just the
changes rather than the whole document.
Mahesh Jethanandani: We did try this with a -bis to a BFD RFC. It took 1
year.
Thomas Graf: This is not just a YANG module issue, it is a general IETF
issue. We need incremental development capabilities. I would like to
address this more holistically not just to YANG modules.
Balázs Lengyel: I think as YANG modules are versioned this is more
relevant here.
Per Andersson: This is a great suggestion. To be clear you suggest to
use the erratas and then update the YANG model in code in the YANG
parameters registry. We would need a new revision but otherwise this is
good.
Rob Wilton: I think we should do something else. I think we should solve
this problem properly down the line. I think we should either do this or
have a tool that generates a minimal diff document. I think trying to
update the erratas might be a reasonable way. Balázs I think you should
write a document for this and give it to Mahesh to present to the IESG
and see if there is any concensus.
Italo Busi: There are two issues here: 1) creating a patch errata is a
good idea, 2) creating a minor revision. The experiment failed because
people are scared to do a bis for a small change as a lot of small
changes all together become a big bunch of changes. A fast bis process
for small changes is important.
Kent Watsen: I think when the RFC editor applies the errata it creates
something, there should be a reminder or something for authors to create
a bis.
End: 02:06:20
Session 2 : 2024-11-07 17:30-18:30 UTC
Notes: https://notes.ietf.org/notes-ietf-121-netmod?both
Materials: https://datatracker.ietf.org/meeting/121/session/netmod
Zulip (chat): https://zulip.ietf.org/#narrow/stream/netmod
Drafts (TGZ):
https://datatracker.ietf.org/meeting/121/agenda/netmod-drafts.tgz
Drafts (PDF):
https://datatracker.ietf.org/meeting/121/agenda/netmod-drafts.pdf
Datatracker: https://datatracker.ietf.org/group/netmod/about/
ICS: https://datatracker.ietf.org/meeting/121/session/33394.ics
Recording:
https://meetecho-player.ietf.org/playout/?session=IETF121-NETMOD-20241107-1730
YouTube: https://www.youtube.com/watch?v=1VMm7PYf2Bw
Jabber Logs: https://www.ietf.org/jabber/logs/netmod
Start: 00:00:10
Duration: 10 min
Discussion Leaders: WG Chairs
Strart: 00:10:25
Duration: 10
Discussion Leader: Robert Peschi
Draft:
https://datatracker.ietf.org/doc/draft-rajaram-yang-config-template-framework/00
Lou Berger: Does your presentation differ from what is in the draft in
any way.
Robert Peschi: No
Lou Berger: Thank you for giving us a draft.
Robert Wilton: Am I right in thinking that you modified the models to
fit this technique. The models would have to follow this new structure?
Is that correct?
Robert Peschi: There is a very generic model. What we will show in a
future draft is what to do when we want to reuse data models in current
standards (interface YANG or hardware YANG). We are thinking to have
these data nodes in groupings and use them when we define the list of
instances. The data node of list A could just be a uses statement of the
grouping.
Robert Wilton: Would you plant this generically through the YANG schema
tree or would this be specifically applied at parts of the tree.
Robert Peschi: The template method is very powerful but we took a simple
example.
Robert Wilton: I worry about memory here because you might increase the
size of the schema on the device and this increase might outweigh the
benefits.
Robert Peschi: Where would you see this memory being spoilt?
Robert Wilton: If you took the example here, you have the schema under
the template and the instance so you have double the schema.
Robert Peschi: Schema yes, but not the data itself. The issue is the
data.
Robert Wilton: We would then expand the data so for our (Cisco) device
you would end up using more memory.
Oscar de Dios: Does this solution require a complete copy of the YANG
schema under the template?
Robert Peschi: Yes
Oscar de Dios: What happens if the template changes after?
Robert Peschi: Good point. This helps management because when you change
a template all instances originating from that template are changed. You
could as an example change the reference template on an instance from
'silver' to 'gold'.
Start: 00:21:05
Duration: 10
Discussion Leader: Qin Wu
Draft:
https://datatracker.ietf.org/doc/draft-ma-netmod-yang-config-template/
Robert Wilton: The last slide says that the template definition may not
be present in operational if it is not used. If the template was being
used would the unexpanded template appear in intended as well or would
it not?
Qin Wu: Just the expanded template would be present in operational but
we didn't restrict the unexpanded version. Do you think this is useful?
Robert Wilton: I'm not any judgement.
Kent Watsen: On your previous slide you had the running on the left hand
side and the intended on the right hand side.
Robert Peschi: Wanted to know whether you needed standardisation
activity for this new metadata?
Qin Wu: There is already and RFC specifying this metadata.
Start: 00:31:30
Duration: 10
Discussion Leader: Rob Wills
Reference: Slides only
Jason Sterne: Is the regex matching for list keys only?
Rob Wills: Yes
Lou Berger (clarifying question): If you're explicitly applying the
template then why do you need the regex?
Rob Wills: So you can use it to apply at a higher point in the tree
(e.g., all 100 interfaces), but then exclude the template from applying
to one interface.
Robert Peschi: This metadata is also subject to standardisation I
understand?
Rob Wills: Yes
Start: 00:38:30
Duration: 10
Discussion Leader: Jan Linblad
Reference: Slides only
Kent Watsen (contributer): Can you explain more the brands, the
looping mechnaism, and the if statement?
Jan Linblad: In the templating language you can use $ and if statements
to insert variables and work with loops.
Start: 00:45:40
Duration: 10
Discussion Leader: Kent Watsen
Kick off questions:
What’s the Purpose for the Next Hour
• Decide if important
Kent Watsen: Is this important? I perceive that there is a lot of
interest and several implementations. There are often even multiple
implementations within a specific company.
Robert Peschi: YANG models do not scale for large devices. This is what
we have seen in the BBF. When devices become very large it consumes much
memory and the footprint becomes very large. The time to manipulate this
data becomes prohibitive. Whatever can reduce the size of the running
datastore would help and that is astrong motivation templates.
Oscar de Dios: I think having templates expanded later into
configuration is important. We have solutions that are not doing the
same thing. Some expand and some modify the service if you modify them
later. I would like to step back a little to define what we want.
Kent Watsen: The question is, is it important for the WG to define a
standardized templating solution.
Lou Berger: We are going to have a poll that asks just that question in
a few minutes.
Jan Lindblad: I heard the comment from Robert Peschi that large systems
have a problem with this today. I would say that if you are not
modelling this properly then you can get into trouble however I would
argue that there are many systems with extremely large configurations
using templates today in a good way that are not getting into problems.
Even with what we have today in YANG you can solve this problem well. I
want to mention two things to look at for these solutions, some are
fire-and-forget and some are persistent, i.e. if the template concept
stays within the configuration or not. In some systems you apply a
template but the system will not know that the template has been applied
afterwards. That is an important thing to know. Some are based on
key/value pairs and these loose the type system and the other YANG
concepts in order to understand the data. This is worth noting when
evaluating solutions.
Robert Wilton: You said lots of systems are using templates and don't
run into problems. That seems to be the same as what Robert Peschi was
saying. Are you saying that this can also be solved without templates.
Jan Lindblad: There are already template mechanisms out there in the
field today solving this for large systems. If you are a careful
designer it works but if you didn't think through your modelling before
you went live you can get into trouble for sure.
Robert Wilton: Back to your question Kent, "is this important". I don't
know, obviously we have survivied without having to standardise this for
a long period of time. I do think there is a benefit in trying. If we
tried for a bit and failed that would also be OK.
Robert Peschi: Jan, a template is a solution to a problem, if you have
templates then you have no problem. Without templates you may have a
problem, is that what you meant?
Jan Lindblad: Sure, but templates exist today without further need for
anything.
Robert Peschi: Should we standardise templates? The solution I proposed
doesn't ask anything from standardisation. It is really an application
note of YANG not a standards proposal. The second suggestion is
interesting to standardise and can get included in tooling but it needs
standardisation so is a more long term solution. It depends when you
want this solution to be deployed.
Haomian Zheng: I agree with Jan's point, templates are already in use
today. But what does it mean if we standardise a template? There could
be multiple templates co-existing with each other. If we standardise
only one or a few of these does it mean we don't allow the others, that
could be problematic.
Kent Watsen: In my intro I alluded to this question. It may be possible
to support many and indicate which one you're using.
Xueyan Song (BBF Liaison officer): This work is very important for BBF
and is raised by the BBF liaison. I find after this discussion there is
interest in resolving this question. At BBF when we deploy large scale
ONU we didn't find existing RFCs and YANG models that can achieve or
resolve the large scale question. If the IETF can discuss this question
and find a resolution with some standardisation it will be very helpful.
** Poll **: Is finding a standard approach to templates important?
Majority of those in attendence said yes, only one said no (and ask for
them to say why on list)
• Compare/contrast existing solutions
Kent Watsen: I saw similarities. Most of the implementation have the
ability to define a list of templates and the ability for the data tree
to reference the templates. Some explained how to reference the
template. Some had hierarchical templates. Some had a list of templates
(presumably in some order). There were some unique distinctions, one had
the ability to specify operations such as deleting a node from a
template. One had the ability to order lists. Some had regex/macros. One
had a programming language with loops and variables.
Robert Wills: There is a difference in power between the approaches.
Approach #1 and #3 are additive. Approach #2 also includes deletion and
reordering. Approach #4 is general purpose. Rhetorical question: Does
additive-only get you 80% there or do the users want more power than
that?
Lou Berger: An important distinction is are we adding nodes to every
model or are we taking an approach that adds an annotation/capability
that does not require updating every model.
James Cumming: There was similarity between them. A key difference
seemed to be whether the template was validatable and if it isn't
validatable, what should a system do when you apply it and how does the
operator know that it's been successfully/unsuccessfully applied. That
is a consideration to look at as we move forward. Question for
consideration - should templates be validatable?
Deepak Rajaram: Three solutions have same issues with defaults and
mandatories.
Jason Stern: It will be tricky given the proposals and implementations
out there. There may need some flexibility. Some implementations may not
be able to apply a template at every single node so perhaps that should
be flexible. We may need some SHOULD and MUSTs if we're going to
reconcile vendor implementations.
Kent Watsen: Closing:
1) Clear interest in a standards-based template solution
2) Bring proposals to the wg (as drafts)
3) Discuss proposals on list
4) Based on level of discussion/interest we'll consider to schedule an
interim or have an extra session in Bangkok
Lou Berger: If you have an idea on this we really want to see drafts so
please bring drafts.
Open time: 0 mins
Close: 01:02:00
James Cumming
Robert Wills