Skip to main content

Minutes IETF110: netconf
minutes-110-netconf-02

Meeting Minutes Network Configuration (netconf) WG
Date and time 2021-03-08 12:00
Title Minutes IETF110: netconf
State Active
Other versions plain text
Last updated 2021-03-22

minutes-110-netconf-02
Introduction

   Chairs (10 minutes)
   Session Intro & WG Status

Chartered items:appleds

   Network Telemetry with BMP and YANG Push @ IETF 110 Hackathon (5 min)
   https://github.com/IETF-Hackathon/ietf110-project-presentations/blob/main/ietf-110-hackathon-bmp-yang.pdf
   https://tools.ietf.org/html/draft-ietf-netconf-udp-notif-01
   https://tools.ietf.org/html/draft-ietf-netconf-distributed-notif-01
   Discussion Leader: Thomas Graf

Kent: Performance was much better, was that latency or throughput.
Thomas: Focus on throughput not latency.  Hard to compare with gRPC.  About 10
or 20 times faster than gRPC.  Want to add HTTPS notif with UDP notif. Kent:
Would get HTTPs is likely to be slower than gRPC. Thomas: Encoding is JSON,
will change ... Kent: It is possible for CBOR to be encoded as well.

   Status and Issues on Client-Server Suite of Drafts (10 min)
   https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-9000
   https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-14
   https://tools.ietf.org/html/draft-ietf-netconf-keystore-21
   https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-09
   https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-23
   https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-23
   https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-06
   https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-22
   https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-22
   Discussion Leader: Kent Watsen

Rob: If crypto types requires changes due to SECDIR review, then will that
impact the other drafts? Kent: Yes, potentially, but we plan to ask the AD to
hold the drafts in their queue before sending them to the IESG as a batch.

Kent: Should we move the next tranche of drafts to WGLC together or two batches.
Mahesh: Two batches might be better.
Rob: Agrees with Mahesh

   An HTTPS-based Transport for Configured Subscriptions (10 min)
   https://tools.ietf.org/html/draft-ietf-netconf-https-notif-08
   Discussion Leader: Mahesh Jethanandani

Rob: What other codes might need to be defined?
Mahesh: I don't think that any more need to be documented in the draft.
Kent: We would not define any. HTTP is a published standard, and an
implementation can respond with any of the published responses, including 401.
Publisher which is an HTTP client, and would be able to handle the responses. 
Expectation other responses. Rob: What is a publisher expected to do handling
these codes? Are they expected to have a handler for those codes, or are they
expected to be handled in a standard fashion. Mahesh: The draft is not
expecting any special handlers for the codes the publisher is expected to
recieve. Kent: Http status codes are grouped into categories.  5xx are server
errors. Perhaps the backend server database is full, so returns a 500x error.
Are you suggesting that those errors be documented by this draft? Rob: Worth
specifying behaviour if some specific action needs to be taken, otherwise not.
Kent: As an author, makes sense to define how 500x errors are handling (i.e.,
no buffering is required.) Rob: That makes sense.

Non-Chartered items:

   Telemetry Data Export capability (10 min)
   https://tools.ietf.org/html/draft-tao-netconf-data-export-capabilities-03
   Discussion Leader: Peng Liu

Tim Carey: Looked at multiple transport/encodings?  Also some outstanding
issues related to online discussion.  Where those issues resolved? Qin: For the
second issue, we have already addressed to handle multiple transport/encodings.
 For Issue 2, advertising the capabilities increases the likelyhood of success.
Tim: But did you directly respond to Andy, who raised questions/concerns. Qin:
No, we haven't gone back publicly, but have updated the document. Mahesh: We
can check with Andy. Tim: Wanted to check concerns were. Mahesh: What is the
scenario, where the publisher wants to choose which transport. Qin: Allows
clients can choose which transport Kent: Mentioned establish subscription ...
Qin: Will discuss with Thomas, don't really want to define two way messages for
this. Kent: Any new notif would want to follow the approach of the notif draft.
??? Would that be an overlap on what is being described here? Qin: No. ???
Kent: Does this mean that http-notif should not define the capabilities, and
instead point to this draft? Qin: Maybe.  Your mechanism provides receiver
discovery. Kent: We are in WGLC in that draft.  As a contributor, it makes
sense for each notif transport to define its own mechanism. Tim: Follow up on
Kent's question.  What is the value of this draft, if the other drafts define
their own mechanisms? Kent: ??? With https, uses the same mechanism to get the
capabilities.  Intuiting is to allow each transport to define its own
mechanism. Mahesh: What is a new transport draft comes along, does it need to
define a new capabilty? Qin: Yes, we support UDP notif and HTTP notif. Rob:
Capabilities ??? Kent: If RFC 8639, for each subscription, ... which ever draft
that defines a transport, it can choose whether that leaf is configurable. 
This was discussed by the authors, statically configuring XML vs JSON was less
helpful that a dynamic response.  HTTPS notif draft does not define the
identity in a way that enabled that when statement.  Also note, that there
other capabilities, e.g., bundled messages. Rob: Concern is that we defining
capabilities in an adhoc fashion, and perhaps need to take a holistic view of
how to handle capabilities, rather than doing it individually for each
protocol. Mahesh: Benoit agrees to have discovered capability. Benoit:
Important to have discovered capabilities.  Solving the next step of network
management, will require a more holisitic view. Kent: Dynamic discovery is
better than static discovery? Is that right, Benoit? Benoit: This is correct.

   Adaptive Subscription to YANG Notification (10 min)
   https://tools.ietf.org/html/draft-tao-netconf-data-export-capabilities-03
   Discussion Leader: Qiufang Ma

Kent: Are you assuming that the receiver would have a secondary connect to the
publisher, so that it can then sent these message? Qiufang: Allows ... Kent: By
dynamic subscription, receiver is already connected, then it makes sense to
send these over the existing channel, but when the subscription is configured
then a separate connection will be required. Qin: For dynamic, we won't have a
second connection, but for configured, I agree with you. Kent: ??? Qin: For
server, it automatically switches the data rate.  Send a notification that the
collect rate has changed.  Do you think that additional capabilities are need?
Kent: Not necessarily, just wanted to check that my understanding is correct.
Qin: Didn't see an issue. Mahesh: With a chairs hat on, Authors suggested
having converstaion with Thomas, would recommend that the authors post their
questions/discussions to the mailing list so that other parties can contribute.
Qin: That makes sense.

   With System Capability for NETCONF (10 min)
   https://tools.ietf.org/html/draft-ma-netconf-with-system-01
   Discussion Leader: Qiufang Ma

Balazs: We already have an RFC about factory default configuration, that should
be included in the initialization usecase. I don't find the report-all,
explicit mode to be inituitive in this case, that should be use for reporting
rather than initializating. Although, not popular in our circles, there are
other organizations that do write configuration into running. Qin: In reply to
Rob.  The question is how would the client know that System configuraiton has
changed, and the RPC is necessary. Rob: A client could have a subscription on
the system datastore. Tim: If that is the case, then what is the value of
System rather than just reading operational.  I'm missing what a system
datastore will provide. Qiufang: ... Tim: Why wouldn't I just use a
subscription ... I missed documenting the rest of this discussion that I was
participating in. Kent: I think that the same issue was discussed/envisaged
with dynamic datastores.  I think that system datastore would have to be viewed
in that way as well. Kent: As chair, there has been discussion on adoption of
the drafts. At the moment, the chairs thin that further discussion on the list
is required first. Qin: We will discuss on the list. Kent: It would be good if
we could have discussion of issues on the list for each of these drafts.

   NETCONF Next and RESTCONF Next (30 min)
   Discussion Leader: Mahesh Jethanandani

Kent: Would/should we wait for YANG Next?
Mahesh: At least one item to do with YANG Next.
Rob:
Benoit: Plenty of features.  Lots of things that we can be doing.  Are these
features coming from operators? Mahesh: Agreed, that getting operator feedback
would be good.  If there are any operators, it would be good to get their
input. Kent: Don't know of any pain points that are being expressed by
operators.  Have certain work in flight, and other work in progress, they are
updating existing NETCONF/RESTCONF RFCs.  Hope that we can continue doing that.
Rob: There is a NETCONF over QUIC, but this probably does not make use of the
features of QUIC. Kent: Might require allocating a new port for running over
QUIC. Tim: A couple of the standards bodies: We come up against questions about
the utilation of YANG with gRPC and GPB.  I don't know if that fits into
RESTCONF, or whether that is a separate protocol.  Particularly as we get into
telemetry or control plane, and want to use YANG as a way of conveying the data
model, then encoding gRPC and GPB becomes more relevant.  Not clear whether
that is a new binding for an existing protocol or a new protocol. Mahesh:
Summarize: Agree with Benoit to get more operator input.  Also agree with Rob
that we should consider the impact of QUIC, and we might want to come back and
look at what it takes for NETCONF and RESTCONF.

Remaining 25 min.