Re: [Netconf] a joint discussion on dynamic subscription

"Eric Voit (evoit)" <> Wed, 13 June 2018 22:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3995F130E96 for <>; Wed, 13 Jun 2018 15:01:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eVeVllvNhh2f for <>; Wed, 13 Jun 2018 15:01:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2BE7B130EE8 for <>; Wed, 13 Jun 2018 15:01:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2474; q=dns/txt; s=iport; t=1528927268; x=1530136868; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=vJ815XVPaKSagI0G3Y86HHBUZiKQChoWMprMubIdGY8=; b=hyfj2NGdqn16y2zaZmrHdwqtss9caBMxJA1jS1Ptpbe12HU0+RBCvnDR yKVDlrJgkZxHkXtuL7Yr9bG2aHq2TXcI2gIkHa6ULZNwYqycb3eBRZ67B bI2S2KdlFQzR405EJ106IH9sLsOjIvd6tZAKv7vExDbGO7qN1IQMvH7+n c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAABskyFb/4oNJK1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNIYn8oCotzjmeUaYF4CyWERwKCNyE0GAECAQEBAQEBAm0?= =?us-ascii?q?cDIUoAQEBAwE6RAsCAQgVEBEQMiUBAQQBGoMcgXcID683g3oBhEyBYwWIS4F?= =?us-ascii?q?UP4QbgxEChzYCmQoJAoVyiH+NPIoKhwwCERMBgSQdOIFScBWCfoV9ihwBNW+?= =?us-ascii?q?PRIEaAQE?=
X-IronPort-AV: E=Sophos;i="5.51,220,1526342400"; d="scan'208";a="129288071"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jun 2018 22:01:07 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w5DM17ta029546 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Jun 2018 22:01:07 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 13 Jun 2018 18:01:06 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Wed, 13 Jun 2018 18:01:06 -0400
From: "Eric Voit (evoit)" <>
To: Tianran Zhou <>, Alexander Clemm <>, "Zhengguangying (Walker)" <>, Martin Bjorklund <>, "" <>
Thread-Topic: a joint discussion on dynamic subscription
Thread-Index: AdQCx01ede4gaRHPTgG2WyMdkd0r2gARka+A
Date: Wed, 13 Jun 2018 22:01:06 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Netconf] a joint discussion on dynamic subscription
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Jun 2018 22:01:14 -0000

Hi Tianran,

> From: Tianran Zhou, June 12, 2018 11:47 PM
> Hi Eric,
> When we are discussing the draft-ietf-netconf-udp-pub-channel, we find a
> conflict with current dynamic subscription design.
> 1. The dynamic subscription requires notification to use the same channel as
> the subscription.

This is true when you look at the NETCONF transport draft.  However this is *not* required by the base subscribed-notification draft.  And in fact, the HTTP transport draft might not use the same logical channel.  E.g., see how the URI is returned within: 

So if you wanted to define some transport session independence for a UDP transport, subscribed-notifications should permit that.   And if you believe there is something in the text which prohibits this, let me know.

> 2. The RPC does not have the input information about the receiver because the
> above assumption.
> However, when we talk about the distributed data collection (multi data
> originators), the publication channel is always different from the subscription
> channel.

While it likely isn't what you want, even with NETCONF, the single NETCONF session doesn't means that distributed line card generation of the notification messages is impossible.  For example, the inclusion of the header object message-generator-id (as defined within draft-ietf-netconf-notification-messages) allows the notification message generation to be distributed onto linecards even if the messages themselves are still driven back to a central transport session.  Note that I am not recommending this, but the specifications would support this.

> So either the distributed data collection does not support dynamic
> subscription, or current dynamic subscription definition may need
> modification.

I think for UDP, you will want to define a way to bind the lifecycle of the dynamic subscription's channels across multiple line cards.  This will require some thinking as well as coordination within the publisher.

Perhaps returning multiple URIs (one for each linecard) might be something which could make this easier.  If you go down this path, you still will need to fate-share the lifecycle of the subscription across all of those line cards.

> What's your thoughts?
> Regards,
> Tianran