Minutes IETF101: netconf
minutes-101-netconf-01

Minutes for the NETCONF WG Session @ IETF 101
Tuesday, March 20, 2018 13:30-15:30
Afternoon Session I
Room: Sanringham

WG Chairs:
  Mahesh Jethanandani
  Kent Watsen

Available During Session:
  Audio stream:  http://ietf101streaming.dnsalias.net/ietf/ietf1017.m3u
  Etherpad:      http://etherpad.tools.ietf.org/p/notes-ietf-101-netconf
  Meetecho:      http://www.meetecho.com/ietf101/netconf/
  Jabber:        xmpp:netconf@jabber.ietf.org?join
  Slides:        https://datatracker.ietf.org/meeting/101/session/netconf

Available Post Session:
  Recording:     https://www.ietf.org/audio/ietf101/
  YouTube:       https://www.youtube.com/user/ietf/playlists

AC: Alex Clemm
BL: Balasz Lengyel
EV: Eric Voit
FX: Frank Xia Lian
IB: Igor Bryskin
JS: Jason Sterne
JSc: Juergen
KW: Kent Watsen
LB: Lou Berger
MB: Martin Bjorklund
MJ: Mahesh Jethanandani
QW: Qin Wu
RS: Rob Shakir
RT: Rick Taylor
RW: Robert Wilton
TC: Tim Carey
TP: Tom Petch

WG Chair Slides

Chairs: udp-pub-channel - what were the updates, given no recent discussion?
Were these discussion brought to the mailing list.

Chartered items

Kent Watsen (15 min):
Proposal for Refactoring the Keystore Model
https://tools.ietf.org/html/draft-ietf-netconf-keystore-04
https://tools.ietf.org/html/draft-kwatsen-netconf-crypto-types-00
https://tools.ietf.org/html/draft-kwatsen-netconf-trust-anchors-00

Kent presenting.
KW: Any volunteers to help editing keystore docs?
KW: -04 removed global store of public keys; so why is it called a keystore and
how might we fix it FX: Huawei employee, author of several drafts in SACM WG,
generally supports work, from Security Area, Will contribute.  Prefers 3, more
reasonable for time & discuss what should be included, many possibilities.
Should discuss how to work together, need RW: Prefers option 2. Publish now.
Worry about revisions down the line. EV: Supports Option 2 as well, supports
work going forwards. It might be useful to consider the trusted computing
group's definition of trust & anchor TP: Agrees with RW - against refactoring. 
thinks that refactoring is the cause for recent delays. TC: Agrees that we'd
like to move things along; but does'nt understand referencing w/ crypto toward
the anchoring, especially for ssh keys. Support publishing now. KW: It is a
mistake. Module does'nt currently have the trust anchor reference to crypto
types module

Eric Voit and Alex Clemm (20 min):
Update on YANG Push and Related Drafts

https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-10

Review Q #1:
MB: How is option 2 not redundant from the server list.
EV: Using string for receiver name (options 2 & 3) seems appropriate
MB: Prefers option 3. Feels address/port is redundant in option 2.
EV: There is desire for other dests other ports and some want to config it
directly MB: Option 3 is incomplete; relies on augmentation EV: Could have both
AC: how do we close.  Prefers option #2 KW: Please spin each question out as
its own thread email. EV: Will create a separate thread for this on the list. 
The option of doing either address & port as well as a future leafref to drive
the call home mechanism provides a choice.

Review Q #2:
EV: no objection to keeping "subscription-state-notif".  But needs list
confirmation.

Review Q #3:
JS: only takes effect on output of publisher?
EV: yes
JS: So how do you know to use it?
EV: If something is in queue, matches HTTP/2 behavior
JS: So a strict priority mechanism?
EV: yes. whether DSCP is an optional feature on its own, or should it be
optional in the mainline can be closed on the list

Review Q #4:
Option 2 chosen
EV: rename the yang-data containers will be done.

JS: Back several slides. Changes in authorization.  What granularity on auth
(filtering within a notification)? EV: With events do pass/fail test for what
event goes on what stream. JS: If it fails for some portion of an event, the
entire even is filtered? EV: Yes.  Yang push offers greater filtering
granularity JS: If subscription changes, its supposed to be immediate. If the
auth changes, it needs to notify event subsystem.  what happens with an
external auth server that might not do this (e.g., TACACS)? EV: Subscriptions
can either dynamically update or restart subscription to cause the auth to be
updated. JS: Does'nt really answer the question. EV: None of this addresses the
remote/tacacs server auth, external auth is out of scope in this doc, but
useful future work EV: Need to discuss on list.

https://tools.ietf.org/html/draft-ietf-netconf-yang-push-15

JS: What about remote permission reconciliation if off-box capabilities change?
EV: This is out of scope, and has impacts (and requires mechanisms) across all
of NETCONF, not just subscriptions

https://tools.ietf.org/html/draft-ietf-netconf-netconf-event-notifications-08

<no comments>

https://tools.ietf.org/html/draft-ietf-netconf-restconf-notif

KW: due to the DSCP having a relationship to HTTP/2, should the completion of
the LC on these drafts wait for at least a good review of the restconf-notif
draft to ensure alignment and implementability? EV: Sure that weighting and
dependency are implementable.  Staight mapping to HTTP/2.  There is code that
does this.

KW: When will notification drafts be ready for LC
EV: Waiting to find someone that knows gRPC well enough to ensure it is
interoperable with what we have.  Not sure how long that would take.  After 3
drafts complete WGLC, we can assess if we should wait anymore EV: Author
blockers remain primarily the desire to seamlessly integrate with GRPC.  We
know the QoS works based on HTTP2 behaviors.  Based on that a delay doesn't
seem necessary.

https://tools.ietf.org/html/draft-ietf-netconf-notification-messages

KW: Need to make sure issues are reflected prior to major updates to the draft.
EV: Thought it had been on list.  Look for a dialog from Henk Birkoltz, he is
building a new version and will need to socialize issues he wants to champion

KW: Also please update the import from rc:yang-data to new yang-data-ext
EV: happy to do that

RW: have to looked into the size of the data relative to, e.g., gRPC?  Seems
like a lot of header fields EV: Most is optional. Question of efficiency is
mostly relevant upon CBOR.  Thinks that identifying all the fields and then
determining what to do with them (e.g., bundling) makes sense. RW: Would be
interesting to see the size difference EV: agreed. RS: analysis is key.  we
have refactored a few times to improve.  done analysis about efficiency
(describing ofrmats, path/val w/ compression, etc). Have found a few different
approaches that provide better scalability.  Can share results

RW: Good to do an efficiency measure of different transports of this header
once the specification starts to settle

Non-Chartered items:

Igor Bryskin (10 min):
Generalized Network Control Automation YANG Model
https://tools.ietf.org/html/draft-bryskin-netconf-automation-yang-01

RT: Support work. Work in dtn wg, brought in by some of the space guys. Not
using NETCONF or NETMOD. They are doing it already. There is a whole body of
work. Lots of similarity. There is room for collaboration. We would like to the
work being done on ECAs and make it fit it with NETCONF and NETMOD. Grab me
afters and get some alignment.

TC: Has Juergen seen this?  Because in lmap they have created a YANG model that
does similar stuff. Some duplication of work. And the FSM model might address
some of this stuff. IB: Havent spoken to them.  Talked to Andy Bierman. He
feels this is a reasonable way to push ECAs. TC: I mean; go talk to LMAP WG
before going too deep. Tied into IPPM. KW: Agrees with Tim. Might want to
present it in NETMOD.

RT: Comment to the chairs. Clearly this is needed in more places; someone needs
to drive this work. Possibly in NETMOD.

Mahesh Jethanandani (10 min):
Binary Encoding for NETCONF
https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-00

KW: If it is a dynamic subscription you pass in an encoding format. As a
configured subscription, you pass in both a encoding and a protocol. EV:
Impacts 5277, as it is not used to changes in notifications along the way. So
the breath of what is impacted includes dynamic if there is a change after the
subscription has started. MJ: So the agreement is that we will not be able to
support 5277.

MB: If you just encode just the payload, first of all you have to base encode
with base64. Then you have to open the RPC blob and do decoding of the base64
data. That does not match the XML schema defined in RFC 6241. The xml parser
has to be prepared to parse data that does not match the schema and decode it
to match the schema. The only way it would work would be to put the entire
encoding in a binary encoding including the message layer. And that goes for
notification also. If you change only the payload, it will be tricky. MJ: What
was influencing us is CBOR doesnt handle the messaging layer. So now in
addition, we will have to define CBOR encoding for the messaging layer.

RT: This might be a niave question. But if you are changing the encoding,
including the messaging layer, and I take your point about base64 encoding
within a XML layer, it is no longer NETCONF. It is another YANG supported
encoding. Why have different encodings for NETCONF rather than just say we will
do binary configuration? MJ: Has to do with the need to have a more compressed
format for data. KW: Rather change the encoding, switch the protocol. JS: I was
going to respond to it. You are still encoding NETCONF, just that you are using
binary format to encode them. It is NETCONF, just in a binary encoding. RT:
REST is the same. just different encoding.  keep the shape. Perhaps it is just
semantics. I do not see encoding the payload, but leave the messaging in its
original encoding. RS: Introducing the unmarshalling, what is the performance
of the underlying transport is at the same time. You are going to run into the
througput limit of the underlying transport. Why bother with encoding before
figuring out if it works well enough without KW: Primarily Its about high
througput or large messages for uses like like telemetry which makes me think
about YANG push.

<Lost Audio for remote participants and in the audio stream here for a good 5
min.>

MJ: the draft would have to be updated, so...
KW: whats the level interest for this work:  reason number of hands

<Audio came back, but may have missed comments. If you tried to comment, but
could not please indicate it here.>

Qin Wu (10 min):
NETCONF Base Notifications for NMDA
https://tools.ietf.org/html/draft-wu-netconf-base-notification-nmda-00

RW: worth agging push change is delta operation
QW: yes
TC: Should just be bis to nmda, since datastores missed. Should this be a bis
to that draft? Why would this just be a bis? KW: We do not need to decide this
now. This draft was published end of Feb. and there was no discussion on the
mailing list. It is being presented here, and so this would be something that
would have to be discussed as part of whether we want to adopt it as part of
the WG. RW: Would yang-push be a better generalized mechanism for doing this? I
question whether this is required. KW: It is a notification. And notifications
are pushed through YANG push. RW: Let me clarify. Whether you need a single
notification that something has changed in the operational datastore. Whether
it is better to have a generalized subscription on configuration nodes of the
datastore. That YANG push is a generalized mechanism for getting notification.
TC: To answer RW question, this is a case of a broken RFC. You missed this in
the datastores that are explicit in it. Fix the RFC. Second is you got a new
notification. You want to use the YANG push or use 5277, but that discussion
can go on the mailing list. But fix the RFC. BL: I see value in it. You are
trying to transfer information on who changed it, and other metadata like
origin. On the other hand you are missing the subscription, you will miss lot
of other data. Seems unnecessary to duplicate the functionality QW: Feels it
solves different problems. KW: Please take this to the list and then we can
choose to decide whether we are going to accept this work. QW: Ok.

Rob Shakir (10 min):
gRPC Network Management Interface (gNMI)
https://tools.ietf.org/html/draft-openconfig-rtgwg-gnmi-spec-00

RW: Is the time stamp entered by the hw?
RS: Yes, the target sets the time the data was collected.
LL: You mentioned the models do not have to be in YANG. Do you have other
formats? RS: Yes, we have some models in Protobufs. TC: How are dynamic
elements handled in the yang model conversion RS: Done in yang-aware models,
then serialized TC: So you lose the "meta data" RS: Separate idea of modeling
vs serialization, the modeling is kept ??

Alex Clemm (10 min):
Discrepancy detection between NMDA datastores
https://tools.ietf.org/html/draft-clemm-netconf-nmda-diff-02

LB: What new Proto methods are being defined?
AC: rpc to compare
LB: Should be in NETMOD WG since this is not a new protocol.  But useful.  ie:
move it to NETMOD? KW: ok? AC: Sure. KW: Who has read it?  <fair number> KW:
Here or NETMOD?  <NETMOD prevails>

Balasz Lengyel (10 min)
YANG Push Notification Capabilities
https://tools.ietf.org/html/draft-lengyel-netconf-notification-capabilities-00

BL: Asking for adoption
KW: Too soon; needs to be on the list and authors have too much work. Should
postpone. BL: Authors support it KW: I am sure they do. MJ: will they have
time? BL: suspect i will do majority, but that is a question.

Hauwei emp: Identifying which changes are significant.
BL: use can use parameters; this is about server capabilities to do it
AC: Think its useful and on the question of bandwidth, because this work was
pushed out of YANG push, it is here, and we will make the bandwidth. jabber
(Juergen): Is this right solution for the problem? BL: There was a simpler
solution with YANG extensions, that was not supported. That this is a good
solution to the problem. BC: I want on change notification for every single
variable I have in the router. Even the counters, because some of the counters
are important. I think this is important work. RS: Have same problem in gNMI.
Taken a different approach. Some counter should have notification on change. If
there a notification for a leaf or a set of leafs that it cannot send, it fails
the subscription. You have entered a world where you have a subscription which
cannot be met. That leads to questions of compliance. So I prefer we fail the
subscription. If you ask for a subscription, and the publisher cannot meet the
requirement, just fail the subscription. BL: orginially it was in schema, but
would cost runtime RS: Annotation in the schema is what can be supported. The
question I have is do you want to have the complexity of accepting a RPC that
you cannot meet. BL: i'm saying subscription for everything, but really meaning
for all but with these exception. So I am already limiting. RS: So the contract
of the RPC is not met. So our approach is that you the client get to decide
what you need, and the server can choose not to accept the RPC. It is clear to
the client that the RPC was not accepted. RW: Rob Shakir, what happens if you
cannot change on every change, but are able to do every 50 ms. How do you
indicate that to the client? RS: If you do give that information to the client,
it really does not know what to do with it. So it is better not to give it that
information. RW: So it more about what they are signing up for. RS: Does it
have to be validated. We do not need to carry that as part of the protocol.