Subject: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif

From: Kent Watsen <[email-masked]>
Date: Wed, 5 Aug 2020 22:14:18 +0000

NETCONF WG,

Per the previous email sent moments ago, the chairs would like to solicit input on the following draft:

   Title: Subscription to Distributed Notifications
   Link: https://tools.ietf.org/html/draft-unyte-netconf-distributed-notif
   Abstract:

      This documents describes extensions to the YANG notifications
      subscription to allow metrics being published directly from
      processors on line cards to target receivers, while subscription is
      still maintained at the route processor in a distributed forwarding
      system.

In particular, please discuss adoption-suitability as it regards to the following questions:

    1) is the problem important for the NETCONF WG to solve?
    2) is the draft a suitable basis for the work?

PS: this message is itself not an adoption poll, but rather an attempt to gauge interest/support for a potential future adoption poll.

NETCONF Chairs

---

From: Kent Watsen <[email-masked]>
Date: Fri, 7 Aug 2020 20:16:00 +0000

[as a contributor]

>     1) is the problem important for the NETCONF WG to solve?

I believe that it is important to enable publishers to send notifications directly from line cards.   This belief is based on my experience from when at Juniper dealing with very high-end firewalls with enormous log output.

I believe that the NETCONF WG is the appropriate WG for this work, having defined RFC 8639 (SN), RFC 8640 (NN), and RFC 8650 (RN).

>     2) is the draft a suitable basis for the work?

I have read the current version of the draft and find it to be a reasonable start.

Presuming the ability to use a transport outside of SN, as described by http-motif, is maintained, it may be useful if this draft could describe how to do that also.  That said, if all equipment having a multiplicity of publisher-agents will uses SN, then this isn’t needed.  [Note: the “https-notif” draft’s intention is to enable simple implementations, e.g., no multiplicity of publisher-agents.]

3) regarding Juergen’s questions:

  a) I am willing to substantially review the drafts.
  b) I am willing to contribute to the discussion of any issue.
  c) I do NOT plan to implement the technology defined.

Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Aug 2020 12:38:42 -0700

Hi,

I am trying to understand what problem this draft attempts to solve.
It appears from the solution proposal is that the problem to be solved is
the lack of message generator identifiers associated with configured
subscriptions.
These identifiers could presumably help a client understand some
implementation details
related to a subscription.  The solution seems to rely on the
message-generator-id
field in the notification message (which does not exist in current RFCs).

I do not understand why the client needs this feature.

Andy

On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen <[email-masked]> wrote:

> PS: this message is itself not an adoption poll, but rather an attempt to
> gauge interest/support for a potential future adoption poll.
>
> NETCONF Chairs
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 11 Aug 2020 03:28:02 +0000

Hi Andy,

Thanks for your review.
Basically your understanding is correct.
The background is about the distributed notif, which the global subscription will be decomposed to several component subscriptions.
And the client need to compose the data from multiple publishers. It need to know if all the pieces of one data are received.
Current solution depends on ietf-netconf-notification-messages. I just found it’s expired!
I would like to discuss with authors about the plan on that draft. Fortunately you are one coauthor. Could you please help on the answer?
Otherwise, we can seek other way.

Best,
Tianran

From: netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Tuesday, August 11, 2020 3:39 AM
To: Kent Watsen <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif

Hi,

I am trying to understand what problem this draft attempts to solve.
It appears from the solution proposal is that the problem to be solved is
the lack of message generator identifiers associated with configured subscriptions.
These identifiers could presumably help a client understand some implementation details
related to a subscription.  The solution seems to rely on the message-generator-id
field in the notification message (which does not exist in current RFCs).

Andy

On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:
NETCONF WG,

NETCONF Chairs
_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 10 Aug 2020 21:10:32 -0700

Hi Tianran,

> On Aug 10, 2020, at 8:28 PM, Tianran Zhou <[email-masked]> wrote:
> 

In IETF 108, the chairs mentioned that this draft is on hold till https-notif draft goes into publication, at which time it will also go for publication.

Thanks.

Mahesh Jethanandani
[email-masked]

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 11 Aug 2020 04:22:49 +0000

Hi Mahesh,
Thanks for your clarification.
I am sorry I did not know this.
So I think we can still depend on ietf-netconf-notification-messages. Right?

Cheers,
Tianran

From: Mahesh Jethanandani [mailto:[email-masked]]
Sent: Tuesday, August 11, 2020 12:11 PM
To: Tianran Zhou <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif

Hi Tianran,

On Aug 10, 2020, at 8:28 PM, Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:

Thanks.

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 12 Aug 2020 11:46:37 +0800

Hi WG,
 
With regard to the 2 questions for this draft:

I think it’s valuable for the WG to solve. As mentioned in the other mail, for core devices with large amount of data to export,  distributed exporting mechanism could relieve the device work load.
Directly export from the line cards can avoid the bottle neck when exporting data from mainboard.

Yes. I’ve read this document and think it’s a good basis for the work.

[email-masked] & [email-masked]
 
From: Kent Watsen
Date: 2020-08-06 06:14
To: [email-masked]
Subject: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif
NETCONF WG,

NETCONF Chairs